This is the reference card for governing an AML or payments AI agent. If you run financial crime at a bank, a payments firm, or a fintech, you do not need another essay on whether agentic AI is "high-risk." You need to know, action by action, exactly where the control gate sits, who signs off, and what evidence has to be sealed when the agent acts. That is what this page is: a single Control & Evidence Map that takes each thing an AML agent actually does — alert triage, sanctions-hit clearance, SAR/STR drafting, payment screening, onboarding and KYC, transaction monitoring — and maps it to (a) the control gate that must run at the moment of action, (b) the accountable human who signs off, and (c) the sealed, tamper-evident record that proves it happened, cross-referenced to DORA, the AMLR, and the Wolfsberg Principles.\n\nThe thesis behind the map is simple and it does not change row to row: govern by execution, not paperwork. At machine speed, a control that lives in a policy PDF is not a control. The gate has to run inside the agent's execution path, the accountable human has to be a named person in an approval queue and not a signature collected next quarter, and the evidence has to be sealed at the moment of decision — not reconstructed the morning an examiner asks. For the full regulatory argument behind this map, read the companion piece, Governing AML and payments agents. This page is the hub: bookmark it, and use the per-action tools linked throughout to operationalize each row.
How to read the map: gate, human, evidence
Three columns in the map do the real work, and each maps onto a concrete runtime primitive. Get these three definitions right and the rest of the page is a lookup table.
The control gate is a checkpoint inside the agent's execution path, expressed as policy-as-code, that decides what the agent may do at the moment it tries to act. It resolves to one of four decisions, in precedence order: allow (the action proceeds autonomously), warn (it proceeds but is flagged for later review), require_approval (it pauses and routes to a named human before anything executes), and block (it is stopped outright). The whole discipline of governing an agent is choosing the right decision for each action and each risk band — a routine low-value alert can be allow, a sanctions hit above a confidence threshold must be require_approval or block. These are the same four decisions you author in a Policy Builder gate.
The accountable human is not an abstraction. Where a gate resolves to require_approval, the action enters a two-person, maker-checker review: the agent (or a first-line analyst) is the maker, and a named, suitably-authorised human is the checker who must approve before execution. That is a Decision Desk function — a real person in a real queue, with the authority to approve, reject, or send back, and whose identity is captured. Wolfsberg is explicit that this accountability stays with the firm whether the system is built in-house or bought from a vendor; it does not transfer to the model provider.
The sealed evidence is the record produced at the moment of decision and locked so it cannot be quietly altered afterward. It captures the inputs the agent saw, the policy applied, the decision reached, and the human who approved it, as one contemporaneous, tamper-evident unit — an Evidence Room record. This is the property a dashboard and a log file do not have, and it is precisely what an FIU under AMLR Article 69, a DORA supervisor, or an AMLA examiner needs to see.
The Control & Evidence Map
This is the centre of the page. Each row is one thing an AML or payments agent does. Read across: what goes wrong if it runs ungoverned, the control gate that must fire (mapped to allow / warn / require_approval / block), the accountable human who signs off at the Decision Desk, the sealed Evidence Room record, and the regulation that anchors the obligation.
No row relies on a fabricated metric or an invented case. Every regulatory anchor is a real, public instrument: the AMLR (Regulation (EU) 2024/1624), AMLD6 (Directive (EU) 2024/1640), DORA (Regulation (EU) 2022/2554), the Wolfsberg Principles, and, where it lands case-by-case, the EU AI Act (Regulation (EU) 2024/1689, Article 14 on human oversight).
| Agent action | Risk if ungoverned | Control gate (allow / warn / require_approval / block) | Accountable human (Decision Desk) | Sealed evidence (Evidence Room) | Reg anchor |
|---|---|---|---|---|---|
| Transaction-monitoring alert triage / auto-close | False auto-close of a true alert buries suspicious activity; an unreviewed model silently sets the firm's risk appetite | allow for defined low-risk alert types within threshold; warn for borderline scores; require_approval / block for high-value or high-risk typologies the agent may not auto-close | First-line investigator as checker on escalated alerts; the auto-close policy itself owned by the MLRO / Head of Financial Crime | Captured inputs and reasoning for every auto-close, plus the policy version applied — the auditable process made real and reconstructable on demand | AMLR Art. 69 (FIU reconstruction, 5 working days); DORA Art. 3(22) critical-function resilience |
| Sanctions / PEP hit clearance | A false auto-clear of a true hit is a sanctions breach; a false auto-block freezes a legitimate payment — neither is reversible by a next-morning dashboard | allow only below a tightly-set confidence threshold; require_approval above it; block on designated-list exact matches pending review | Named sanctions reviewer as checker before any clear or block executes | Every clear/block decision sealed with the reviewer identity, the threshold applied, and the underlying match evidence | AMLR sanctions/CDD obligations; Wolfsberg firm accountability; EU AI Act Art. 14 oversight (where in scope) |
| SAR / STR drafting and filing | An autonomously-filed narrative becomes a legal record with no human accountable for its content or accuracy | Draft autonomously (allow); *filing is always require_approval*** — a mandatory maker-checker gate with human sign-off | MLRO or delegated nominated officer as checker; the agent (or analyst) as maker | The filed narrative plus its source evidence sealed for the FIU and an AMLA examiner, with the approving human on record at the moment of filing | AMLR / AMLD6 reporting duties; Wolfsberg firm accountability (in-house or sourced) |
| Payment screening / release / blocking | A released payment cannot be unwound by a later log entry; the decision executes in real time and is final | Inline approval authority at the point of action: allow within policy, require_approval above value/risk thresholds, block on screening exceptions — never downstream-only monitoring | Payments-operations approver with release authority as checker on flagged transactions | Real-time decision record: who or what authorised release/block, against which policy version, with which inputs, sealed as it happens | DORA operational resilience (Art. 3(22)); payments and sanctions obligations |
| Customer onboarding / KYC and KYB acceptance | An agent that accepts a high-risk customer without review creates a CDD failure that surfaces only at the next exam | allow for low-risk acceptances within policy; require_approval on acceptance above defined risk thresholds; block on prohibited categories | Onboarding / first-line acceptance officer as checker above threshold | Lineage of what the agent checked (CDD data, screening, risk scoring), what it concluded, and the human acceptance decision above threshold | AMLR customer due diligence (from 10 July 2027); Wolfsberg explainability |
| Beneficial-ownership (UBO) investigation | A wrong UBO determination understates risk and propagates into every downstream decision about the relationship | allow for straightforward ownership chains; require_approval where ownership is opaque, layered, or crosses high-risk jurisdictions | Enhanced-due-diligence analyst as checker on complex structures | Sealed record of the ownership structure the agent reconstructed, the sources used, and the human determination where review was required | AMLR beneficial-ownership transparency; AMLD6 register dates (staggered, from 10 July 2027) |
Mapping the map to runtime primitives
The map is deliberately product-neutral in its columns, but it is built to be operationalized by three runtime primitives that have to act together. If any one of the three is missing, the row is not governed — it is documented, which is not the same thing.
Policy Builder gates turn the third column into running code. The decisions in the map — allow, warn, require_approval, block — are not adjectives; they are the literal outcomes a policy gate emits when the agent reaches a checkpoint. You author the threshold ('above 0.85 sanctions-match confidence, require_approval'), the gate enforces it inline, and the agent cannot route around it. This is the difference between a control that runs and a control that is described in a binder.
The Decision Desk turns the fourth column into a named, two-person reality. Every require_approval outcome routes to a maker-checker queue where a real, authorised human approves, rejects, or sends the action back before it executes. This is what satisfies the Wolfsberg requirement that the firm — not the vendor, not the model — remains accountable, and what gives an examiner a name to put against every consequential decision.
The Evidence Room turns the fifth column into a sealed artifact. At the moment each gate resolves, the inputs, the policy version, the decision, and the approving human are written as one contemporaneous, tamper-evident record. Because it is sealed at the point of action, it answers the AMLR Article 69 reconstruction test and the DORA resilience expectation without a forensic scramble. See a sample execution-lineage export for what one of these records contains.
Why a dashboard fails this map
The most common way agentic AML deployments fail their first serious examination is by confusing observability with evidence. A dashboard shows you the present; a log file shows you what a system chose to record about itself. Neither satisfies a single row of this map, because evidence in the regulatory sense has three properties a dashboard lacks.
It is contemporaneous — produced at the moment of the decision, not assembled after the FIU request arrives. It is complete — capturing inputs, the policy applied, the decision, and the approving human as one sealed unit, not four systems an analyst has to stitch together under deadline. And it is tamper-evident — an examiner can verify it was not altered after the fact, without taking your word for it. A five-working-day FIU clock under AMLR Article 69, compressible to under 24 hours in urgent cases, is not a reporting feature you bolt on later; it is a test of whether the lineage in the fifth column was sealed at the moment it happened.
This is also where vendor self-attestation runs ahead of what it can prove. A core financial-crime platform may describe its agent's trail as 'traceable and auditable,' but that trail is self-attested inside the vendor's own platform — an auditor is asked to trust the vendor's record of the vendor's agent. A real institution runs a core vendor, a separate screening point vendor, and in-house agents elsewhere; three self-attested trails in three formats are not an evidence strategy. The map assumes a single, neutral control-and-evidence layer across all of them.
Operationalizing each row: the AML tool cluster
Each row of the map has a corresponding tool to help you operationalize it. Use these to turn the reference card into a live programme, action by action.
SAR / STR filing (row 3). The maker-checker gate on suspicious-activity reporting is the cleanest case of require_approval in the whole map. Our SAR/STR maker-checker generator drafts the narrative and routes it through a mandatory two-person sign-off, so the agent never files without a named human on record.
Transaction-monitoring triage (row 1). Deciding which alert typologies an agent may allow-close versus must escalate starts with knowing your red flags cold. The transaction monitoring red-flags library is the typology reference that should sit behind your auto-close policy — if a pattern is in the library, the gate should not let the agent close it silently.
Onboarding, UBO, and CDD (rows 5 and 6). The thresholds that decide require_approval on acceptance and ownership review come out of your enterprise-wide risk picture. The AML enterprise-wide risk assessment tool helps you set those risk bands deliberately rather than by default.
Programme readiness across all rows. Because the binding deadline is the AMLR's 10 July 2027 application date and not a moving AI Act date, the AMLR 2027 readiness tool checks your agent governance against the single rulebook the whole map is anchored to. Run it to see which rows you can already evidence and which are still paperwork.
The three regimes behind every anchor
The final column of the map cites three regimes that already converge on the same operational demand, and only one of them is the EU AI Act. Knowing which regime drives which obligation tells you why the gate is where it is.
DORA — in force now, and the lead. Regulation (EU) 2022/2554 has applied since 17 January 2025. An AML, sanctions, or payments system can qualify as a critical or important function under Article 3(22) on a documented, entity-specific assessment — a function whose disruption would materially impair the firm's financial performance, the soundness of its services, or its continuing compliance with authorisation. That is why the payment-screening and triage rows carry resilience and reconstruction obligations today, not in 2027.
The AMLR — binding from 10 July 2027, and the substance. Regulation (EU) 2024/1624 is the directly-applicable single rulebook for customer due diligence, PEPs, and beneficial-ownership transparency. Its Article 69(1) five-working-day FIU response clock, compressible to under 24 hours, is the reconstruction test the Evidence Room column is built to pass. AMLA in Frankfurt has operated since 1 July 2025 and begins direct supervision of a first wave of selected firms from 2028.
The EU AI Act — the nuance, not the panic. For most standalone AML monitoring, classification as high-risk is neither settled nor decisive, and the Annex III application date is provisionally set to move to 2 December 2027. Where a system is in scope, Article 14 requires meaningful human oversight including the ability to intervene and override — which is exactly the require_approval and block discipline the map already encodes. Build to the map and the AI Act obligation, where it lands, is already satisfied. The full classification argument is in the companion article.
Frequently Asked Questions
What is the AML Agent Control & Evidence Map?
It is a reference table that maps each thing an AML or payments AI agent does — alert triage, sanctions-hit clearance, SAR/STR drafting, payment screening, onboarding and KYC, beneficial-ownership investigation — to three things: the control gate that must run when the agent acts (resolving to allow, warn, require_approval, or block), the accountable human who signs off in a two-person Decision Desk review, and the sealed, tamper-evident Evidence Room record produced at the moment of decision. Each row is anchored to a real public regulation: DORA, the AMLR, AMLD6, the Wolfsberg Principles, or the EU AI Act.
How do the control gates map to allow, warn, require_approval, and block?
Each gate resolves to one of four decisions in precedence order. Allow lets a routine, low-risk action proceed autonomously. Warn lets it proceed but flags it for later review. Require_approval pauses the action and routes it to a named human before anything executes — this is the maker-checker gate for sanctions hits above a confidence threshold, SAR filing, and high-risk onboarding. Block stops the action outright. Choosing the right decision for each action and risk band is the core discipline of governing the agent.
Who is the accountable human for each agent action?
Where a gate resolves to require_approval, a named, suitably-authorised human becomes the checker in a two-person, maker-checker Decision Desk review: a sanctions reviewer for hit clearance, the MLRO or a delegated nominated officer for SAR filing, a payments-operations approver for payment release, an acceptance officer for onboarding. The Wolfsberg Principles are explicit that this accountability stays with the firm whether the agent is built in-house or sourced from a vendor; it does not transfer to the model provider.
What counts as sealed evidence, and why is a log file not enough?
Sealed evidence is a record produced at the moment of decision and locked so it cannot be quietly altered, capturing the inputs, the policy version, the decision, and the approving human as one unit. A log file or dashboard lacks three properties an examiner needs: it must be contemporaneous (made at the moment, not reconstructed after a request), complete (one sealed unit, not four systems stitched together), and tamper-evident (verifiable without taking your word for it). The AMLR Article 69 five-working-day FIU clock, compressible to under 24 hours, is a direct test of whether the lineage was sealed when it happened.
Which regulations anchor the map, and which applies now?
Three regimes converge. DORA (Regulation (EU) 2022/2554) applies since 17 January 2025 and can make an AML or payments system a critical or important function under Article 3(22). The AMLR (Regulation (EU) 2024/1624) applies from 10 July 2027 and sets the customer due diligence, beneficial-ownership, and FIU-response obligations. The EU AI Act (Regulation (EU) 2024/1689) applies case-by-case; where it lands, Article 14 requires human oversight with the ability to intervene and override. The Wolfsberg Principles (1 December 2022) set the firm-accountability baseline today.
Can an AI agent file a SAR or clear a sanctions hit on its own?
It can draft a SAR autonomously, but filing must always be a require_approval maker-checker gate with mandatory human sign-off, with the approving officer on record. For sanctions hits, the agent may auto-clear only below a tightly-set confidence threshold; above it, clearance must route to a named reviewer, and exact matches on designated lists should block pending review. In both cases a false autonomous decision is effectively irreversible — a filed narrative is a legal record, a wrongly cleared hit is a sanctions breach — which is why the gate sits before the action, not in a dashboard afterward.
Key Takeaways
Treat this page as the reference card you return to whenever you stand up, buy, or extend an AML or payments agent. The discipline never changes: for every action the agent takes, decide the control gate (allow, warn, require_approval, block), name the human who signs off at the Decision Desk, and seal the evidence in the Evidence Room at the moment of decision. Anchor each one to the regulation that actually binds you — DORA since January 2025, the AMLR from July 2027, Wolfsberg today — and not to a moving EU AI Act deadline. The firms that win their next supervisory conversation will not be the ones with the thickest policy binder; they will be the ones whose evidence was sealed at machine speed, in the execution path, one row at a time. Govern by execution, not paperwork — and use the tools on this page to make every row of the map real before an examiner ever asks.