Anti-Money Laundering is the set of controls used to detect and prevent financial crime by identifying suspicious activity and prohibited parties. In practice it depends on reliable identity data, screening quality and governance over how decisions are made and reviewed.
Expanded Definition
Anti-Money Laundering, often abbreviated as AML, refers to the policies, processes, and monitoring controls used to prevent the movement and concealment of criminal proceeds through financial systems and related services. In practice, AML covers customer due diligence, ongoing transaction monitoring, sanctions and watchlist screening, suspicious activity review, escalation, and recordkeeping. The term is often used alongside Know Your Customer, but they are not identical: KYC focuses on establishing and verifying identity, while AML is the broader control discipline that detects patterns, counterparties, and behaviours that may indicate laundering or other financial crime.
For organisations that rely on digital onboarding, automated decisioning, or delegated workflows, AML also depends on identity assurance and governance over the evidence that supports each decision. This is why NHI Management Group treats AML as both a compliance discipline and a control assurance problem. The global baseline most commonly referenced is the FATF Recommendations — AML and KYC Framework, which shapes how jurisdictions expect institutions to manage risk, beneficial ownership, and monitoring obligations. The most common misapplication is treating AML as a one-time onboarding check, which occurs when organisations fail to connect ongoing monitoring, case review, and identity evidence quality into a continuous control lifecycle.
Examples and Use Cases
Implementing AML rigorously often introduces operational friction, requiring organisations to weigh faster customer experiences against stronger review, evidence, and escalation controls.
- Retail banking screening that flags unusual transaction patterns, such as structuring, layering indicators, or rapid movement across accounts, for analyst review.
- Business onboarding that verifies beneficial ownership and screens owners, directors, and counterparties before account activation.
- Payment providers that monitor velocity, geography, and device or identity anomalies to identify potentially suspicious payment flows.
- Cryptoasset firms that apply sanctions screening, wallet risk checks, and customer risk scoring to address exposure to illicit finance.
- Case management workflows that preserve evidence, reviewer notes, and decision timestamps so that outcomes can be defended during audit or regulator review.
AML controls are often implemented through policy-backed technical guardrails mapped to security governance standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where auditability, access control, and logging are required. In practice, the quality of the input identity data matters as much as the detection rule itself, because weak entity resolution can generate false positives or allow risky relationships to go unnoticed.
Why It Matters for Security Teams
For security and governance teams, AML is not just a finance function concern. It intersects with identity verification, fraud prevention, privileged workflows, and the integrity of automated decisions. If screening data is stale, ownership structures are opaque, or analyst overrides are not governed, organisations can miss prohibited parties, fail to escalate suspicious activity, or produce records that do not withstand examination. That creates regulatory exposure, operational disruption, and reputational harm, especially where multiple systems make linked decisions without a shared evidence model.
AML also has a direct relationship to NHI and agentic automation when non-human workflows initiate transfers, approvals, or account actions. If an AI agent or service account can trigger customer-facing or financial actions, then the organisation needs strong identity binding, scoped authority, and traceable decision logs so that AML outcomes remain attributable. Guidance from frameworks such as the FATF Recommendations and NIST SP 800-53 Rev 5 Security and Privacy Controls helps define the governance baseline, but operational risk still depends on how well those controls are implemented in real workflows. Organisations typically encounter AML control failures only after an investigation, a blocked payout, or a regulatory request, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while DORA and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 | AML relies on governed third-party and entity-risk oversight across the enterprise. |
| NIST SP 800-53 Rev 5 | AU-2 | AML monitoring depends on logs and evidence needed to review suspicious activity. |
| NIST SP 800-63 | IAL2 | AML uses identity proofing strength to support reliable customer due diligence. |
| DORA | AML operations depend on resilient, governed systems handling regulated financial workflows. | |
| PCI DSS v4.0 | 10.2 | Where payment environments are involved, AML evidence overlaps with logging and traceability. |
Collect and retain audit logs that support transaction review, escalation, and regulator inquiries.
