A formal control framework for preventing money laundering and terrorist financing. In regulated crypto environments it defines who approves customers, how risk is assessed, what gets monitored, and how evidence is retained for audit and regulator review.
Expanded Definition
An AML/CFT Program is the governance and control structure used to detect, prevent, escalate, and evidence activity linked to money laundering or terrorist financing. In regulated crypto, it reaches beyond customer due diligence to include transaction monitoring, sanctions screening, alert triage, suspicious activity reporting, record retention, and ongoing risk-based reviews. Guidance varies across jurisdictions and regulators, but the core expectation is consistent: the program must prove that decisions are risk-based, traceable, and reviewable under audit.
For NHI and agentic systems, the term matters because many AML/CFT workflows are now executed or assisted by software agents, API-driven controls, and automated case systems. That creates an identity problem as much as a compliance problem: if a service account can submit alerts, access customer risk data, or trigger case closures, its permissions, provenance, and logging become part of the control evidence. NHI Management Group treats this as a governance boundary, not just an operations issue, because weak machine identity controls can undermine the integrity of the entire program. The most common misapplication is treating AML/CFT as a reporting exercise, which occurs when organisations preserve outputs but cannot prove who or what system made each decision.
Examples and Use Cases
Implementing an AML/CFT Program rigorously often introduces more workflow friction and evidence burden, requiring organisations to weigh faster onboarding and automated monitoring against stronger review and recordkeeping.
- A crypto exchange uses risk scoring at onboarding, then routes higher-risk customers to enhanced due diligence before a wallet is activated.
- An automated monitoring agent flags unusual transfer patterns, but a human compliance analyst must approve any escalation before a suspicious activity report is filed.
- A case management platform ingests sanctions screening results from external services, with service account access limited and logged as part of the audit trail.
- An internal control team reviews API key use for transaction monitoring jobs, because the approval chain is only defensible if the system identity is tightly governed.
- The Hugging Face Spaces breach illustrates how exposed machine access can turn automation into a governance liability when secrets and permissions are not tightly controlled.
Standards-oriented teams often map these workflows to the NIST Cybersecurity Framework 2.0 to ensure monitoring, logging, and access control are not treated as separate activities.
Why It Matters in NHI Security
AML/CFT Programs depend on trustworthy non-human execution. If a compliance workflow is driven by over-privileged service accounts, hard-coded tokens, or poorly governed automation, the organisation may be unable to show whether a risk decision was legitimate, complete, or tamper-resistant. That is especially dangerous in crypto environments, where regulators expect durable evidence, clear accountability, and consistent control operation across rapidly changing tooling and transaction volumes. NHI Management Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which makes machine identity control a direct AML/CFT concern.
The same risk pattern appears when transaction monitoring or sanctions screening is outsourced to automated pipelines without strong credential governance. If those systems are altered, bypassed, or impersonated, the organisation may still appear compliant until an audit, investigation, or enforcement action exposes the weakness. The operational lesson is that a compliant AML/CFT Program must be able to prove not only what was reviewed, but which identity performed the review and under what authority. Organisations typically encounter this consequence only after a false negative, failed audit, or suspicious transfer review, at which point AML/CFT Program controls become 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.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret sprawl and access governance for machine identities used in compliance workflows. |
| NIST CSF 2.0 | PR.AA-01 | Identity governance and access enforcement are central to proving automated AML/CFT actions are authorized. |
| NIST AI RMF | AI governance guidance applies where agentic systems support risk scoring or alert triage in compliance programs. |
Bind every AML/CFT automation to a named machine identity and enforce least privilege with reviewable logs.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
