This is where things get fun.
Defining what "correct" results look like is very entertaining. I've worked with people who put WITH NO_LOCK on every single query in the system. When they finally start using RCSI, they also start getting "incorrect" data. In fact, they were eliminating duplicate rows and adding back in missing rows, not to mention getting more consistent results. However, the business wasn't seeming the same results so they got very concerned.
Assuming you're already using the default isolation level, your results shouldn't change at all. You're still only seeing committed rows from a query. It'll be the same with RCSI. The difference is that instead of being blocked while uncommitted transactions complete, you can still read that data. Now, again, that could lead to what a business considers incorrect results if they expected to see the data only after the commit is complete. However, that's the dance. You have to wait for the commit to complete, which means blocking, or, you can see the already committed data immediately.
I too came out of the financial industry. When I changed from the default isolation level to RCSI, the only word I heard was how much faster things were. My business people didn't expect to see the uncommitted data, but only the committed data. If yours expect to see the uncommitted data, then you have an issue.
However, none of this is directly related to the code, nor would changing the code change what's being returned by the queries. It is down to committed vs. uncommitted data and what the expectations around that are.
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore RooseveltThe Scary DBA
Author of: SQL Server 2017 Query Performance Tuning, 5th Edition
and SQL Server Execution Plans, 3rd Edition
Product Evangelist for Red Gate Software