How to Test Data Quality Controls for AML

A client record can appear complete while still being unsuitable for a regulatory decision. An expired identity document may remain marked as valid, a beneficial owner may be missing from a linked entity, or a high-risk geography may have been entered as free text and bypassed screening. Knowing how to test data quality controls is therefore central to an effective AML framework. It establishes whether the information used to onboard, assess, monitor and exit clients is accurate enough to support defensible decisions.

For compliance officers, MLROs and operational leaders, data quality testing is not an IT exercise carried out in isolation. It is a control assessment that connects source information, system behaviour, staff actions and governance. The objective is to identify whether poor data could cause a failure in customer due diligence, sanctions screening, risk rating, transaction monitoring or regulatory reporting.

Start with the decisions the data supports

Testing should begin with the regulatory and operational decisions that rely on each field. This keeps the exercise proportionate and aligned to risk. Not every item in a customer relationship file carries the same consequence if it is inaccurate or unavailable.

For example, a missing client telephone number may affect operational contactability, but an incorrect country of residence, source of wealth rationale or beneficial ownership percentage can materially alter the CDD outcome. Similarly, a risk-rating field is only meaningful if the underlying inputs – such as geography, product risk, occupation, delivery channel and adverse media findings – are complete and correctly applied.

Create a data inventory that records the critical data elements, their source, the system or register in which they are held, the process owner and the control intended to protect them. In an AML environment, this commonly includes customer identification data, legal entity details, beneficial ownership information, screening results, risk classifications, review dates, documentation expiry dates and enhanced due diligence evidence.

The inventory should also define what “good” means for each element. That definition may cover completeness, validity, accuracy, consistency, timeliness and uniqueness. A field can be complete but inaccurate; it can be accurate when collected but no longer current. Testing must distinguish between these failure types rather than treating data quality as a single pass-or-fail measure.

How to test data quality controls in practice

A credible test considers both control design and operating effectiveness. Design testing asks whether the control, if performed as intended, addresses a defined data risk. Operating effectiveness asks whether it was actually performed consistently during the period under review.

Take an automated mandatory-field rule for beneficial owners. The design may be sound if a corporate client cannot progress to approval without recording ownership and control details. Yet operating effectiveness may be weak if users can enter placeholder values, use an “unknown” status without a documented exception, or approve a file after an unauthorised override.

Testing should trace data through the full lifecycle, from collection to use. Select records from the relevant population and compare the information in the onboarding platform against authoritative evidence, such as identification documents, company registry extracts, trust deeds, declarations or independently obtained verification results. Then confirm that the same information has transferred correctly to screening tools, risk engines, review queues and management information.

This source-to-system approach exposes common breakpoints. Manual rekeying can introduce transcription errors. Interfaces may truncate names, fail to transfer diacritics or map a country code incorrectly. A workflow may allow a record to be approved before documents are verified. Each issue should be assessed against its practical AML impact, not merely logged as a technical defect.

Test completeness, validity and accuracy separately

Completeness testing establishes whether mandatory information and supporting evidence are present. A useful test is to identify all active customers within the population and measure the proportion with completed fields and documents required by their risk category. High-risk relationships should be tested against their enhanced due diligence requirements rather than the baseline CDD standard.

Validity testing checks whether values conform to established rules. Dates should be plausible and in the correct format; legal entity numbers should meet the relevant registry standard; countries should be selected from a controlled list; and document expiry dates should not precede issue dates. Validity rules are especially valuable where free-text fields have historically been used for information that should be structured.

Accuracy testing goes further by comparing the stored value with trusted evidence. A name that is formatted correctly may still differ from the passport or company extract. An ownership percentage may total 100 per cent across a record but misstate the interest held by an individual. For high-risk fields, accuracy testing should usually involve direct inspection of source evidence rather than reliance on system reports alone.

Test timeliness and change management

AML data deteriorates over time. Customer circumstances change, legal entities appoint new directors, ownership structures evolve and documents expire. A control framework needs to show that it identifies and addresses those changes at the right point.

Test whether periodic reviews are triggered according to the assigned risk rating, whether overdue cases are escalated, and whether the information refreshed during review is reflected across connected systems. Examine a sample of event-driven reviews too, such as changes to ownership, adverse media alerts, transaction activity or a revised risk assessment.

It is equally necessary to test the controls applied when systems, forms or data rules change. A revised onboarding questionnaire can create a gap if its new fields do not map to downstream screening or monitoring systems. Change controls should require data impact assessment, testing before release, documented approval and post-implementation validation. The level of scrutiny should reflect the potential effect on regulatory obligations.

Use sampling that can withstand scrutiny

The appropriate sample depends on population size, control frequency, customer risk profile, error history and the purpose of the review. A small random sample may be suitable for a stable, low-risk automated validation. It will be less persuasive where a control applies to high-risk clients, politically exposed persons, complex ownership structures or manual exceptions.

Risk-based sampling should deliberately include records most likely to reveal control weakness: recent system migrations, files approved under time pressure, cases with overrides, dormant relationships reactivated for new business, customers with non-standard documents and records handled by new teams. Include both successful and failed cases where possible. A control cannot be judged only by reviewing records that moved smoothly through a workflow.

Document the population, selection method, sample rationale, test steps, evidence reviewed and exceptions identified. Reperformance is particularly valuable for key controls. If a team member has recorded a risk rating or cleared a data-quality alert, the tester should independently recalculate or validate the result using the policy and source material available at the time.

Reconcile systems and challenge exceptions

Reconciliations are often the most direct way to detect data loss or inconsistency. Compare active customer populations between the onboarding platform and screening tool, risk-rating engine and periodic-review register. Reconcile high-risk flags, PEP indicators, document expiry dates and review statuses. Investigate records that appear in one system but not another, as well as records with conflicting values.

Exception reports are only effective when ownership and escalation are clear. Test whether reports are complete, generated at the expected frequency, reviewed by an authorised person and followed through to closure. An exception marked as resolved should have evidence of correction, validation and, where necessary, a reassessment of the client’s risk or approval status.

Tolerance levels require judgement. A zero-tolerance threshold may be appropriate for missing sanctions-screening status or unknown beneficial ownership in an active relationship. For lower-impact fields, management may set a measured tolerance, provided it is justified, monitored and does not conceal a recurring process weakness. A high volume of apparently minor errors can indicate inadequate training, poor workflow design or weak supervisory review.

Turn findings into accountable remediation

A useful test report does more than state that records were incomplete. It explains the control objective, the population tested, the nature and extent of exceptions, the root cause, the associated regulatory risk and the action required. This enables senior management to prioritise remediation based on exposure rather than the number of findings alone.

Root-cause analysis should distinguish between one-off human error and a systemic control failure. If relationship managers repeatedly select an incorrect risk category, the issue may be unclear guidance, inadequate training, incentives that favour speed over challenge, or a system design that makes the correct choice difficult. Remediating only the sampled files will not resolve the underlying risk.

Actions need named owners, realistic deadlines and a method for validating closure. Where data defects affect screening, risk classification or due diligence decisions, consider whether a broader remediation exercise is required. That may involve a retrospective review of the affected population, temporary restrictions on onboarding or enhanced second-line oversight until the control performs reliably.

The strongest data quality controls make good decisions easier and poor decisions harder. When testing is tied to the real points at which client risk is assessed and accepted, it provides more than audit evidence: it gives the business a clearer basis for protecting its regulatory standing and reputation.