Data, Technology and Model Risk in AML
Domain 9 tests the systems backbone of AML: data quality, model lifecycle and governance, tuning, list hygiene, and the risks introduced by automation and machine learning.
Data quality and lineage
AML outcomes depend on complete, accurate, timely and consistent data. Common failures include missing occupation or nationality fields, transactions booked under generic codes, mismatched customer identifiers across systems, and delayed feeds from payment channels. Data lineage shows where each field originates and how it is transformed, which is essential when defending an alert decision or a model change.
Model lifecycle and governance
A model moves through development, independent validation, implementation, ongoing monitoring, tuning and decommissioning. Governance requires an inventory, documented purpose and assumptions, version control, change approval, and periodic review. Vendor models remain the institution's responsibility: they must be validated and calibrated to the institution's own data.
Tuning, AI and explainability
Tuning changes thresholds or logic to reduce false positives without materially increasing missed risk. Any tuning proposal should show alert volume, true-positive impact, coverage effects and back-testing results. Machine learning models raise specific issues: explainability of the reason for an alert, bias in training data, drift over time, and the need for human review before adverse action.
List and screening quality
List data needs currency, deduplication and correct versioning. Matching parameters (fuzzy thresholds, transliteration, date-of-birth weighting) determine both false positives and missed matches and must be documented and tested.
Worked example
A team proposes raising a cash-deposit threshold to cut alerts by 30%. Validation replays 12 months of data: alert volume falls 30%, but true positives fall 15%, including a structuring cluster. The proposal is rejected and a segmented approach is adopted instead. Reasoning: a volume reduction is not a benefit if detection degrades, and the impact must be measured before, not after, implementation.
Traps that cost marks
- Tuning to reduce workload without measuring detection loss.
- Treating a vendor model as validated by the vendor.
- No documentation of model assumptions, version or change rationale.
- Ignoring data gaps that make coverage claims unreliable.
- No human review before an automated action affects a customer.
Emerging Risks and Typologies
Domain 10 tests your awareness of how laundering and financing methods evolve, and whether you can apply typology knowledge to unfamiliar facts rather than recalling headline cases.
Technology-enabled risks
Virtual assets and VASPs bring cross-border, pseudonymous value transfer risk, including mixers and tumblers, chain-hopping between assets, and unhosted wallets. Decentralised finance adds layering through smart contracts. Non-fungible tokens can be used to move value through inflated sales. Ransomware payments create sanctions exposure when a crypto address is designated. Identity fraud is amplified by synthetic identities and deepfake video in remote onboarding.
Trade-based and professional-enabler risks
Trade-based money laundering uses mispricing, over- and under-invoicing, phantom shipments and multiple invoicing. Red flags include documentation inconsistent with the goods or route, unusual third parties, and shipping through conflict or sanctioned areas. Professional enablers, including lawyers, accountants and trust providers, can supply the structures that obscure ownership, and real estate remains attractive for integration of proceeds.
Channel and product risks
Alternative remittance and informal value transfer systems operate outside formal reporting. Mule networks recruit students or low-income individuals to receive and forward funds. Authorised push payment fraud creates laundering exposure through beneficiary accounts. Embedded finance and agent networks expand reach while weakening visibility.
Worked example
A crypto exchange onboards a customer whose funds arrive from a mixer-linked address, then move through three exchanges and convert to a privacy coin before withdrawal to a newly created wallet. The customer describes trading profits, but there is no trading history. Correct reasoning: the pattern is layering, mixers indicate intent to obscure provenance, the conversion to privacy assets is a red flag, and the unsupported explanation is inconsistent with the profile. Escalate to EDD, consider whether a sanctions nexus exists, and file a report.
Traps that cost marks
- Treating new technology as automatically high risk without evidence or risk assessment.
- Confusing fraud with money laundering and missing the predicate offence or the third-party account.
- Ignoring trade documentation red flags because the customer is long-standing.
- Overlooking professional enablers who structure ownership.
- Relying on old typologies without updating scenarios when supervisors issue new guidance.