Written by: Agata Wojtas, Chief Commercial Officer, Digital Colliers
Your AML rating isn't really a rating of your controls. It's a rating of whether you can answer questions about transactions that happened 18 months ago, using the customer record as it existed then, with the sanctions list as it existed then, and reconstruct why the alert fired or didn't. If your data model can't do that cleanly, no amount of policy documentation saves you.
The pattern I keep seeing at mid-market banks and payments firms is the same. Compliance leads chase controls uplift. Audit findings keep landing on the same soft spots. Nobody in the room is saying the quiet part, which is that the underlying data model was built for operational reporting, not for regulatory reconstruction.
The audit question pattern nobody plans for
Regulators and external auditors don't ask you if you have a policy. They ask you to prove a specific thing happened, or didn't, on a specific date. The questions cluster into a shape:
- Show me every alert generated for this customer between these two dates, and the disposition of each.
- Reconstruct the customer risk score as it stood on the day this transaction cleared.
- Which version of the sanctions list was your screening engine using at 14:07 UTC on this date.
- Why was this transaction not escalated when a similar one two weeks earlier was.
Every one of those questions is a point-in-time join across systems that were probably not designed to be joined that way. If your team is exporting to CSV and reconciling in spreadsheets, you're going to give the auditor an answer that's directionally right and forensically wrong. That's how ratings slip.
Why controls-focus misses the real issue
Most remediation programs I see after a soft rating go straight to the controls layer. New tuning thresholds. More typology rules. A second-line QA sample doubled in size. All defensible, none of it addressing the root cause.
The root cause is usually that transaction monitoring is running on a data model where customer, counterparty, product, and screening history are joined at query time by analysts, not modelled as slowly-changing dimensions with proper effective-dating. False-positive rates in AML transaction monitoring already run 85 to 95 percent at typical mid-market banks. When your analysts are drowning in noise and also can't cleanly reconstruct history, alert quality decays in ways the audit will find.
The controls aren't wrong. They're sitting on sand.
What a good data model actually looks like
If you're rebuilding for regulatory-grade reconstruction, a few things are non-negotiable. This isn't exotic. It's just discipline the operational stack usually skipped.
- Every dimension is bi-temporally versioned. You store both when the fact was true in the real world and when your system learned about it. These are different, and audits care about both.
- Sanctions and PEP lists are versioned as first-class data assets, with the exact vendor payload persisted, not just the current state.
- Alert outcomes carry the full feature vector at the moment of decision, including model version, threshold set, and reference data snapshot IDs.
- Customer risk scores are event-sourced. You can replay the score for any date without recomputing from current data.
The test is simple. Pick a transaction from 14 months ago. Can an engineer, without asking anyone, produce the complete state of the world your monitoring saw when that transaction cleared? If the answer is no, the audit will eventually find that out.
The point-in-time joins problem
This is the specific failure mode worth naming. When your team runs SQL by hand to answer audit questions, they almost always join current dimension tables to historical fact tables. It looks right. It's silently wrong. You get the customer's current risk band, not the one that applied when the transaction cleared. You get today's beneficial ownership, not the one on file at screening.
The fix is architectural, not procedural. As-of joins, effective-dated dimensions, and reference data snapshots need to be the default query pattern, not a special favour requested from the data team.
This matters more now because the regulatory perimeter around financial services keeps widening. DORA has been in force since January 2025 and pushes hard on data lineage and operational resilience evidence. GDPR exposure on automated decisioning is real after the SCHUFA ruling in late 2023. Fines for GDPR violations reach up to 20 million euros or 4 percent of global turnover. The teams that ride this out are the ones who fixed the data before the audit, not after.