TL;DR: AML failures are costly and operational, according to SumSub’s Finance AML Compliance 101 Guide for 2026, which cites Starling Bank’s £28.9 million penalty and outlines obligations for banks, payments, wallets, and BNPL providers. The real lesson is that monitoring, screening, and reporting controls only work when they are treated as governed identity and risk processes, not paperwork.
At a glance
What this is: This guide frames AML/CTF compliance as an operational control problem, highlighting the cost of weak monitoring, screening, and reporting with Starling Bank’s £28.9 million penalty as the example.
Why it matters: It matters because finance teams need AML controls that are auditable, governed, and resilient across products and channels, not ad hoc processes that fail under regulator scrutiny.
By the numbers:
- Starling Bank paid £28.9 million in 2024 for compliance failures.
Context
AML compliance in finance is the discipline of detecting, screening, and reporting suspicious activity across regulated products and customer journeys. In this guide, the problem is not theory: weak controls can lead to financial penalties, regulator distrust, and operational disruption when monitoring does not keep pace with growth.
The article focuses on banks, payments, wallets, and BNPL providers, where compliance obligations differ in execution but not in consequence. The central governance issue is that AML cannot be treated as a one-time policy exercise; it has to function as a live control environment with evidence, reviewability, and escalation paths.
Key questions
Q: What breaks when AML controls are treated as paperwork instead of an operating process?
A: The control stops being testable. Monitoring, screening, and reporting may exist in policy form, but without ownership, decision logs, and consistent case handling, the organisation cannot prove that suspicious activity was actually detected, escalated, and reported. That is where regulator trust erodes and penalties become more likely.
Q: Why do weak AML controls increase both financial and legal risk for private institutions?
A: Weak AML controls create risk because they allow illicit funds to move with less detection, which can expose a business to fines, criminal prosecution, and reputational damage. The article points to substantial enforcement action in Europe, showing that regulators expect institutions to verify customers, monitor transactions, and maintain evidence. Poor controls also make it harder to prove compliance when scrutiny increases.
Q: What are the signs that an AML monitoring programme is failing?
A: Common warning signs include excessive false positives, delayed alert handling, weak coverage of cross-border activity, and repeated suspicious patterns that are never escalated. A failing programme also depends too heavily on batch processing or isolated systems that cannot correlate customer behaviour, source of funds, and transaction history. If staff cannot distinguish real risk from noise, the control is not working well.
Q: How should finance teams prioritise AML controls across banks, payments, wallets, and BNPL?
A: They should prioritise the controls that are most exposed to growth, product variation, and regulator scrutiny. In practice, that means focusing first on monitoring quality, screening data integrity, and escalation evidence, then expanding to coverage gaps created by new channels or jurisdictions.
Technical breakdown
Why weak AML monitoring becomes a control failure
AML monitoring is the ongoing review of transactions, counterparties, and behavioural patterns for suspicious activity. In practice, it fails when rules are too narrow, alerts are not triaged consistently, or thresholds are tuned for convenience rather than risk. The issue is not just false positives. It is the loss of defensible detection coverage across channels, products, and customer segments, which leaves compliance teams unable to show that controls are operating as intended.
Practical implication: align monitoring rules to the actual risk profile of each product line and verify alert handling as a governed process.
How screening and reporting depend on identity data quality
Screening only works when identity data is complete, current, and consistently matched against watchlists, sanctions, and internal risk signals. Reporting depends on the same data integrity, because a weak join between customer records, transaction records, and case management produces gaps that are hard to defend during review. Finance AML programmes often fail at the edges, where onboarding data, ongoing due diligence, and case escalation do not share a single lifecycle model.
Practical implication: treat identity and case data as part of the control plane, not as separate operational systems.
Why regulators care about evidence, not intent
AML programmes are judged by outcomes and artefacts, not by policy language. A firm can have documented controls and still fail if it cannot prove who reviewed an alert, what was escalated, why a decision was made, and when exceptions were closed. That is why audit readiness is inseparable from governance: the evidence trail is the control, because it shows whether screening, investigation, and reporting were actually performed.
Practical implication: make case notes, review logs, and escalation records part of the minimum compliance evidence set.
Threat narrative
Attacker objective: The objective is to move illicit funds or activity through the financial system without detection long enough to avoid intervention.
- Entry occurs through weak transaction monitoring or incomplete customer screening that fails to surface suspicious behaviour early.
- Escalation follows when bad actors move through the financial flow without triggering meaningful review or reporting.
- Impact appears as regulatory penalties, reputational damage, and the operational burden of remediation after the failure is discovered.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AML compliance is a governed control system, not a documentation exercise. The article shows that monitoring, screening, and reporting only matter when they are run as operational controls with clear ownership and evidence. Finance teams that treat AML as a paper trail rather than a live control plane create the conditions for both regulatory findings and avoidable business cost.
The decisive failure mode is not lack of policy, but lack of control integrity. A firm can write the right rules and still fail if its alert logic, review workflow, and case escalation are inconsistent across products. The practical lesson is that AML governance has to be measured by whether it produces defensible decisions, not by whether a policy exists.
Finance AML now sits at the intersection of identity governance and regulatory accountability. Banks, payments, wallets, and BNPL providers each introduce different identity and transaction patterns, but the governance expectation is the same: identify risk, retain evidence, and close the loop. That makes AML a lifecycle problem as much as a compliance one, especially when customer data and transaction behaviour evolve quickly.
Audit readiness is the named concept this guide reinforces. The guide’s underlying message is that regulators do not reward intent, they reward evidence of control operation. For practitioners, that means the question is not whether controls exist on paper, but whether the organisation can prove they worked when the risk surfaced.
High-growth financial products amplify control debt faster than manual compliance can absorb it. The guide’s references to 2024 to 2025 regulatory traps point to a familiar pattern: product expansion outruns monitoring maturity. Teams should read that as a signal that scale changes the governance burden, not just the transaction volume.
What this signals
AML programme maturity is visible in the evidence trail. Finance teams should expect regulators to judge control quality by what can be demonstrated in alerts, case notes, and escalation records, not by the elegance of the policy library. That shifts attention from policy publication to control operation, where most programmes are weakest.
High-growth financial products create control drift faster than manual governance can track. When banks, payments, wallets, and BNPL offerings grow on different timelines, AML rules often age unevenly and lose relevance. Practitioners should watch for monitoring thresholds and review workflows that no longer reflect the current risk model.
Audit readiness is the practical bridge between AML policy and regulator confidence. A team that can consistently explain who reviewed what, why exceptions were accepted, and when reporting occurred is in a different posture from one that merely asserts compliance. That is the standard finance AML programmes now have to meet.
For practitioners
- Strengthen monitoring coverage across product lines Map transaction monitoring rules to banks, payments, wallets, and BNPL flows separately, then test whether alert logic still captures behaviour after product changes and new risk scenarios.
- Validate screening data quality end to end Check whether onboarding data, watchlist screening, and case records use the same identity attributes and matching logic, because fragmented data breaks traceability.
- Make escalation evidence audit-ready Require every alert disposition to record reviewer identity, rationale, and closure status so the organisation can demonstrate control operation under review.
- Re-test controls after growth events Reassess monitoring thresholds, reporting queues, and exception handling after new products, jurisdictions, or volume spikes so control drift does not go unnoticed.
Key takeaways
- Weak AML controls become expensive when monitoring, screening, and reporting no longer function as governed operational processes.
- The Starling Bank penalty cited in the guide is the clearest signal that compliance gaps can turn into direct financial and reputational harm.
- Finance teams need evidence-rich AML workflows that can survive growth, review, and regulator challenge, not just written policies.
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 CIS Controls v8 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 — Oversight of Cybersecurity Risk Management | AML governance depends on oversight, evidence, and accountable control operation. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Screening and case workflows rely on correct authorisation and controlled review access. | |
| Recommendation — Use OV-01-style oversight to verify AML controls produce auditable decisions and exception handling. Restrict AML case and review access to authorised staff with clear accountability. | ||
| CIS Controls v8 | CIS-5 — Account Management | AML operations depend on tracked ownership for review, escalation, and investigation roles. |
| Recommendation — Maintain accurate account ownership for all AML review and reporting roles. | ||
| GDPR | Art.32 — Security of Processing | Finance AML processing handles personal data and needs appropriate security and evidence. |
| Recommendation — Apply processing safeguards that preserve integrity, access control, and traceability in AML workflows. | ||
Key terms
- AML monitoring: AML monitoring is the ongoing review of transactions, behaviour, and exceptions to detect suspicious activity. In practice, it combines rules, triage, escalation, and evidence capture so the organisation can explain why a case was opened, closed, or reported.
- Screening: Screening is the matching of customer, counterparty, and transaction data against sanctions, watchlists, and internal risk signals. Its value depends on data quality and matching logic, because poor inputs or weak thresholds create blind spots that are hard to justify during audit or regulatory review.
- Reporting Obligations: Reporting obligations are the requirements to notify the relevant authorities about cybersecurity incidents within defined timelines and formats. In NIS2, they are part of the compliance framework and sit alongside preventive and detective controls, making incident handling a governance as well as a technical responsibility.
- Audit Readiness: Audit readiness is the state where an organisation can produce current, traceable evidence that controls are designed and operating as intended. In practice, it depends on timely identity data, clean ownership, and workflows that preserve proof as changes happen, not after the fact.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org