Data Integrity, Completeness Testing, and Root-Cause Analysis

Underneath every AML control is data, the customer records, the transaction feeds, the reference lists that monitoring and screening depend on. And here's the quiet killer: bad data breaks good controls invisibly. A perfectly tuned monitoring scenario can't catch what it never receives, so if a feed silently drops a category of transactions, the system shows green while sitting blind.

SR eleven dash seven flags data quality as part of model risk for exactly this reason. Data-integrity testing underpins everything else we've covered, because a clean-looking output built on incomplete or inaccurate input is a false comfort. Auditors who test only the logic and never the data miss this whole class of failure.

The first data test is completeness, and it asks a different question than accuracy. Completeness asks: did everything that should have reached the AML system actually reach it? You reconcile the source systems, the core banking platform, the payment rails, against what landed in the monitoring and screening tools.

Count records, sum amounts, and look for the gap. Did a feed silently drop overnight? Is a product's activity filtered out before it ever reaches monitoring?

Completeness is about what's missing, and missing data is the most dangerous kind, because nobody sees an alert that was never possible. This reconciliation, source to platform, is one of the highest-value tests an AML auditor performs.

The second data test is accuracy, with its companion, lineage. Accuracy asks whether the data that did arrive is correct and well-formed, are amounts right, are country codes valid, are names intact rather than truncated? Lineage means tracing a field from its origin through every transformation to where the AML system consumes it, so you can see where it might get corrupted.

Common defects include truncation, where long names or account numbers get cut off, mismapping, where a field lands in the wrong column, and silent defaults, where a missing value is filled with a placeholder that fools the logic. Since every conclusion rests on these inputs, inaccurate data quietly undermines monitoring, screening, and reporting alike.

Finding a problem isn't enough; the auditor must understand why it happened, and that's root-cause analysis. The symptom is what you observed, late SARs, missed alerts, a data gap. The root cause is the underlying driver.

A classic technique is to keep asking why: SARs were late, why; because the queue was backed up, why; because volume doubled and staffing didn't, why; because the risk assessment never flagged the growth that drove the volume. Now you've reached something systemic. This matters because fixing only the symptom, hiring temps to clear today's backlog, invites the finding to recur next quarter.

Root-cause analysis is what separates durable remediation from a cosmetic patch, and a recurring finding is often a sign the root cause was never addressed.

Data testing is where Computer-Assisted Audit Techniques really earn their keep, so let's connect them here. Instead of pulling a small sample, CAATs let you analyze the entire population: every customer missing a risk rating, every wire just below a reporting threshold, every alert closed in under sixty seconds. You can re-perform a monitoring rule's logic against the raw data and compare it to what the system actually produced, which directly tests whether the system is doing what it claims.

And you can surface anomalies a human sample would never catch, statistical outliers, duplicate records, impossible values like future-dated transactions or negative ages, each of which hints at a data-integrity problem. The caveat we raised earlier still holds, though: your analytics are only as trustworthy as the data feeding them and the logic you wrote, so validate the analytics themselves before trusting their output. A confident, automated conclusion drawn from flawed data or a buggy query is more dangerous than no analysis, because it carries an unearned air of authority.

Used carefully, CAATs turn data testing from a sample into a near-complete examination.

Recapping: data integrity underpins every other control, because a system starved of complete, accurate data shows green while sitting blind. Completeness testing reconciles source systems to the AML platform to catch what's missing, accuracy and lineage testing trace fields for truncation and mismapping, and root-cause analysis drives past the symptom to the systemic driver so remediation actually sticks. That closes the heavy fieldwork module.

Next, we open the final module, reporting, recommendations, and follow-up, starting with how to write a finding and rate the issue by risk. Take the data and root-cause practice questions first.