TL;DR: Institutions are penalized when AML programs exist on paper but fail in execution, with cases like TD Bank, Danske Bank, HSBC and Standard Chartered illustrating gaps in monitoring, escalation, and due diligence, according to Unit21 analysis. Coverage, not policy volume, is the control that determines whether AML governance actually works.
At a glance
What this is: This is a review of how AML programs fail in practice, using enforcement cases to show that written policies, monitoring rules, and escalation paths do not matter if coverage is incomplete or unmanaged.
Why it matters: It matters because identity and compliance teams need to understand that KYC, transaction monitoring, and case escalation are operational controls, not documents, and regulators punish gaps in coverage as failures of governance.
By the numbers:
- TD Bank paid $3.09 billion in 2024, the largest penalty ever imposed under the Bank Secrecy Act.
Context
AML programs often fail at the point where documentation ends and operations begin. A policy can describe responsibility, escalation, and monitoring, yet still leave large parts of customer or transaction activity unreviewed if the control is not continuously maintained.
This article is about the governance gap between having a program and having a working program. That gap matters to identity and access teams because KYC, customer lifecycle review, and transaction monitoring all depend on reliable identity decisions and enforceable controls.
Key questions
Q: What breaks when an AML program exists on paper but not in operations?
A: The program loses its ability to prevent, detect, and escalate suspicious activity. In practice, that means policies may look complete while transaction volume, customer relationships, or high-risk corridors remain effectively ungoverned. Regulators then treat the gap between declared coverage and actual coverage as a control failure, even if the institution has written procedures and formal ownership.
Q: Why do banks get fined even when they have AML policies and staff in place?
A: Because regulators assess whether the control works, not whether it exists. A written policy, trained staff, and a compliance function do not matter if monitoring is incomplete, escalation stalls, or the baseline for expected activity is never set. The enforcement cases in this article show that operational effectiveness is the standard, not organizational intent.
Q: How do teams know whether AML monitoring is actually effective?
A: They should test both alerted and non-alerted activity, then compare outcomes against the institution’s risk exposure and typologies. Above-the-line testing shows whether alerts and investigations are working, while below-the-line testing checks for suspicious activity that never triggered detection. Effectiveness is proven by coverage, consistency, and documented tuning rationale, not by alert volume.
Q: When should an organisation re-evaluate its AML controls after a business change?
A: Any time the risk profile changes materially, including new products, new customer segments, new jurisdictions, acquisitions, or major volume growth. Those changes alter the expected-activity baseline and can invalidate older monitoring logic. If controls are not updated quickly, the institution may continue operating against a risk picture that no longer exists.
Technical breakdown
Why AML policies fail when they are only documented
An AML policy is meant to define roles, escalation paths, and expected control behavior, but a policy alone does not create enforcement. The control only exists when staff outside compliance can use it, interpret it, and act on exceptions. In the cases discussed, the documented policy often remained disconnected from daily operations, so the institution could claim a program while still failing to detect or respond to risk. That disconnect is a governance failure, not a paperwork failure, because regulators assess whether the control operates in practice, not whether it exists in a binder.
Practical implication: Treat policy maintenance as an operating control, not a documentation exercise.
How KYC and transaction monitoring work together
KYC establishes the expected customer profile at onboarding, while transaction monitoring checks whether behavior remains consistent with that baseline over time. If the baseline is weak or never updated, monitoring has nothing meaningful to compare against. If monitoring only covers part of the flow, the institution may still miss suspicious patterns even when alerts exist. The article’s examples show that failure often comes from incomplete lifecycle coverage, not from the absence of a single tool. In other words, identity verification and ongoing surveillance have to function as one control chain.
Practical implication: Link onboarding data to monitoring rules so changes in behavior are visible against a defined baseline.
Why coverage gaps matter more than rule tuning
Coverage is the share of relevant activity actually examined by a monitoring program. A finely tuned rule set cannot compensate when major parts of volume are never screened at all. The TD Bank case is the clearest illustration in the article: the problem was not merely false positives or weak thresholds, but the fact that most transaction volume was outside monitoring. That means the first question for practitioners is not whether the model is sophisticated, but whether the program sees the full population it claims to govern. Without complete coverage, tuning becomes a distraction from the real exposure. See the SIEM Guide.
Practical implication: Measure monitored volume against total volume before investing in more rule complexity.
Threat narrative
Attacker objective: The objective is to move illicit funds through the financial system while avoiding detection, reporting, and escalation controls.
- Entry occurs through customer onboarding, correspondent relationships, or branch activity that enters the institution with insufficient scrutiny.
- Escalation happens when weak KYC, incomplete monitoring, or ignored internal warnings allow suspicious activity to continue without intervention.
- Impact is regulatory enforcement, large financial penalties, and long-term remediation obligations after the control gap is exposed.
NHI Mgmt Group analysis
AML failure is usually a governance failure before it becomes a compliance failure. The article’s core pattern is not that institutions lacked policies, but that the policies did not translate into operational coverage. When monitoring logic, escalation, and ownership do not reach the business, the program becomes defensible only on paper. Practitioners should evaluate whether the control exists in practice, not whether it is described in a document.
Coverage, not sophistication, is the decisive AML control. Several of the cases show that banks were penalized for activity that was never examined at all, which is a stronger failure than a poorly tuned alert. That means transaction monitoring design must be judged by completeness across customer types, corridors, and volumes, not by how advanced the detection language sounds. Practitioners should measure the proportion of activity actually governed.
KYC is an identity control with downstream compliance consequences. The article makes clear that expected customer behavior must be established at onboarding or monitoring has no baseline to test against. That is an identity governance problem as much as an AML one, because a weak customer profile undermines every later decision about risk. Practitioners should treat customer identity quality as a control dependency, not a preprocessing step.
Escalation failure is the recurring human weakness in AML programs. Internal audit, whistleblowers, and regulators often identified the issue before enforcement, but the warning did not reach someone with authority to change the program. That means governance cannot stop at detection or reporting lines on a chart. Practitioners should test whether findings actually trigger action, not just whether they are recorded.
Read next: SIEM Guide
What this signals
Coverage drift is the hidden failure mode in AML programs. The most dangerous gap is not a bad rule, but a rule set that stops matching the institution’s current business mix. Once transaction volume, jurisdictions, or customer segments change faster than control updates, the program begins governing yesterday’s risk. Practitioners should watch for this mismatch as a standing operational signal, not a periodic audit issue.
AML and identity governance are converging at the onboarding boundary. KYC quality determines whether later monitoring has a credible baseline, which means identity confidence is now part of financial crime control design. That makes onboarding data quality, ownership, and review cadence directly relevant to AML effectiveness. Practitioners should align customer identity controls with transaction surveillance, not treat them as separate workstreams.
For practitioners
- Define monitoring coverage as a measurable control Track the percentage of transaction volume, customer segments, and payment rails that are actually screened, and review it as a board-level risk metric rather than a tuning detail.
- Tie KYC data to alerting logic Use onboarding attributes, expected activity, and customer risk ratings to drive the scenarios that monitor future behavior so the baseline remains meaningful.
- Test escalation paths with real cases Run internal audit and compliance findings through the actual decision chain to confirm they reach a person who can change rules, staffing, or thresholds.
- Review detection logic after business change Reassess monitoring rules whenever you add products, enter new jurisdictions, acquire an entity, or change customer mix, because static logic will drift out of date.
- Document ownership for AML control updates Assign named owners for policy changes, rule changes, and exception handling so control drift cannot hide behind shared responsibility.
Key takeaways
- The article shows that AML enforcement usually follows a gap between documented controls and actual coverage, not a lack of policy language.
- The strongest evidence in the cases is operational scale, including unmonitored transaction volume, missed escalation, and repeated remediation failure.
- Practitioners should measure coverage, baseline quality, and escalation effectiveness together because any one of them can collapse the program.
Related NHI Mgmt Group resources: Segregation of Duties (SoD) Guide · Zero Trust Identity Guide · SIEM Guide · SOAR and Security Automation Guide
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on who can see, approve, and act on AML-relevant activity across the control chain. |
| DE.CM-03 — Detect anomalous activities and events | Transaction monitoring is the article's core detection mechanism for suspicious financial activity. | |
| GV.RM-01 — Risk management strategy is established and agreed to by organisational stakeholders | The article stresses risk-based AML governance and board-visible control ownership. | |
| Recommendation — Use PR.AA-05 to align access, approval, and escalation rights with AML control ownership. Map monitoring coverage to DE.CM-03 and verify that suspicious activity is actually being detected. Tie AML thresholds and review cadence to GV.RM-01 so governance matches the institution's risk appetite. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | AML alerting and case escalation depend on reviewing activity records and acting on anomalies. |
| Recommendation — Use AU-6 to ensure transaction anomalies are reviewed, analyzed, and escalated promptly. | ||
Key terms
- Anti Money Laundering Programme: An Anti Money Laundering Programme is the set of policies, controls, monitoring, and reporting processes used to detect, prevent, and respond to money laundering risk. It combines customer due diligence, transaction monitoring, sanctions screening, escalation, recordkeeping, and governance to identify suspicious activity and meet legal obligations across the organization.
- Customer Risk Rating: A structured assessment of how likely a customer is to present financial crime risk based on identity, behavior, geography, product use, and relationship context. It is the baseline that should shape due diligence depth and monitoring sensitivity, and it must be updated when circumstances change.
- Transaction Monitoring: Transaction monitoring is the process of detecting, reviewing, and escalating activity that may indicate fraud, money laundering, or other financial crime. It combines rules, investigation workflows, and documentation so organisations can explain why a case was flagged and what was done next.
- Escalation Path: An escalation path is the sequence of approvers or managers who receive a pending review when the original owner does not act. It is meant to preserve control continuity, but if it is too broad or too shallow, it can create noise, fatigue, and avoidable operational strain.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational risks that arise when governance breaks down.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org