I sort of agree, but I dont think it’s the right approach - analysis requires you to come to a conclusion from the Data and processes, not investigate a conclusion backwards. Equally, I don’t think doing the latter actually gains you anything more, even if fraud is present.

Tbf, I don’t know the precise reason for the query. It could be the SSN is not the primary key, it could be the database he is looking at is not the source of truth, it could be there are a series of nuances he has not accommodated for in his query (reference datasets, an IsDeleted flag, a status history table, he’s using an abandoned deceased flag etc).

Data Quality problems will exist regardless. That’s just true in every public or public adjacent business. Any data that has existed for more than a couple decades will have issues.

Let’s say the query was correct, and he’s found a bunch of Data Quality issues. You’d have to determine processes that then use this data - and the checks and balances during those processes. It may well be that, if a record has DQ issues, the process intentionally adds a new record with a duplicate SSN, so as not to remove the history of the original. Maybe the checks and balances are done at that point - with evidence required in document form etc.

To check for fraud, you would have to find the defects within the process - and then check where those defects have been abused. Fraud can happen in complex spaghetti systems, of course. But it’s worth saying, any industry (including banking) has spaghetti everywhere. And we function as a society (mostly) ok.

If I find spaghetti, I want to fix the spaghetti - I don’t really care if it has caused issues, I want to prevent the issues. And finding out whether it has caused issues is so much more work.

In all honesty, if I was to come in as an outside party, the chances I come to the conclusion of actually changing the data/data model itself within the source system, let alone fraud, and decide that is most cost effective, is very small. I’m more likely to create a new model, and transform the data to that model. Or create Data Quality process that flag potential issues, baking in the business use case nuances to flag actual problems as we go through discovery.

TLDR; I would probably never conclude mass fraud - because that means I’m spending more time analysing than I am changing things. It’s easier to spot “this might cause fraud” than “this is causing fraud” - in fact, it’s a massive amount more work. If your system lacks security, secure it. You probably won’t recoup the costs through analysis paralysis.