Governing AML and Payments Agents: Oversight, Audit Trails, and the Three Regimes That Already Apply

The question AML teams are asking about AI agents — and why it is the wrong one¶

Walk into any financial crime function in 2026 and you will hear two questions about agentic AI. Is our AML AI "high-risk" under the EU AI Act? And do we have until August 2026 to sort it out? Both are reasonable, and both are the wrong place to start.

They are the wrong place to start because the EU AI Act's high-risk classification is, for most AML and payments use cases, neither settled nor decisive, and because the obligations that genuinely bite your agent are already in force under a different regime entirely. A Head of Financial Crime who spends Q2 2026 building an AI Act high-risk programme for transaction monitoring may discover that the classification does not apply, that the deadline has moved, and that meanwhile the obligations under DORA, live since January 2025, went unaddressed.

The honest framing is this. Your AML or payments agent is usually not high-risk on its own, but it is governed regardless. The substance of what "governed" means does not come from the AI Act's classification debate. It comes from operational-resilience law you are already subject to, anti-money-laundering law arriving in 2027, and the standards your supervisors and the Wolfsberg Group already expect. If you want to test classification for your own systems, our EU AI Act risk classifier walks the Annex III logic step by step, but classification is the footnote here, not the headline.

What an AML and payments agent actually does in 2026¶

To govern an agent you have to be precise about what it does. An AML or payments agent in 2026 is not a chatbot bolted onto a case manager. It reads, reasons, and acts across the financial crime lifecycle, and increasingly it acts with meaningful autonomy.

The market is moving fast and publicly. On 4 May 2026, FIS announced a Financial Crimes AI Agent built with Anthropic, describing it as compressing anti-money-laundering investigations "from hours to minutes" by assembling evidence across core systems, evaluating activity against known typologies, and surfacing the highest-risk cases for investigator review. FIS named BMO and Amalgamated Bank among early institutions, with general availability planned for the second half of 2026. A roster of specialist vendors also markets agentic financial-crime capabilities of its own: Unit21, Sardine, ComplyAdvantage, and Lucinity on the investigation side, with Sumsub centred more on identity verification and KYC plus AML screening. The build-or-buy decision is real, and most large institutions will do both.

Across these products, the agent's job spans a recognisable set of actions, each with a different blast radius when it goes wrong.

• KYC and KYB onboarding reviews — gathering and assessing customer and counterparty information at acceptance.
• Sanctions and PEP screening — generating and adjudicating hits against watchlists and politically-exposed-person lists.
• Adverse media and entity research — synthesising open-source and counterparty intelligence into a risk view.
• Transaction-monitoring alert triage — the highest-impact deployment today, where the vast majority of alerts are false positives and only a small fraction warrant escalation or a SAR.
• Beneficial-ownership investigation — untangling ownership structures for UBO determinations.
• Alert summarisation and SAR/STR narrative generation — drafting the suspicious-activity narrative that, once filed, becomes a legal record.
• Payment release and blocking — the most time-sensitive action of all, where a decision executes in real time and cannot be unwound by a later log entry.

Three regimes already converge for AML and payments agent governance: DORA, the AMLR, and the AI Act¶

The reason "is it high-risk" is the wrong question is that three separate European regimes already converge on the same operational requirement for AML and payments agents, and only one of them is the AI Act. Here is each, dated precisely.

DORA: in force now, and this is the lead. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, was adopted on 14 December 2022, entered into force on 16 January 2023, and has applied since 17 January 2025 under Article 64. It binds credit institutions, payment and e-money institutions, investment firms, insurers, crypto-asset service providers and other financial entities, and it reaches their ICT third-party service providers. Cloud and AI vendors (OpenAI, Anthropic, Microsoft Azure OpenAI, Google) generally fall within DORA's broad Article 3 definition of an ICT third-party service provider. The obligations, though, sit with you, the financial entity: pre-contractual due diligence and concentration-risk assessment, maintaining the register of information on all ICT contractual arrangements (Article 28), and reporting major ICT-related incidents (Article 19). It is worth noting that, in the first ESA designation of critical ICT third-party providers on 18 November 2025, no standalone generative-AI model provider (OpenAI, Anthropic, Mistral, Cohere) was named, so the direct Oversight regime does not yet bite them; they are reached only indirectly through your contractual and risk-management duties. The connective insight that makes DORA an AML story is this: a transaction-monitoring, screening, or SAR-filing system can qualify as a "critical or important function" under Article 3(22), a function whose disruption would materially impair your financial performance, the soundness of your services, or your continuing compliance with your authorisation. DORA does not assign that label automatically; it is a documented, entity-specific self-assessment. But because AML and sanctions are legal duties, the systems supporting them frequently meet the test. So your AML agent can already be a critical-ICT function under a regime in force today.

The EU AML package: binding from 2027, and the substance the agent operates inside. The AMLR (Regulation (EU) 2024/1624), adopted 31 May 2024, is the directly-applicable single rulebook covering customer due diligence, politically-exposed persons, beneficial-ownership transparency, and a Union-wide EUR 10,000 limit on large cash payments under Article 80 (Member States may set lower limits), and it applies from 10 July 2027. AMLD6 (Directive (EU) 2024/1640) carries the same general transposition deadline of 10 July 2027, with staggered earlier and later dates for certain provisions. The new EU Anti-Money Laundering Authority, AMLA (Regulation (EU) 2024/1620), is seated in Frankfurt, started operations on 1 July 2025, and will begin direct supervision of up to roughly 40 of the highest-risk cross-border firms in its first wave in 2028, after a 2027 selection. AMLA develops draft regulatory and implementing technical standards (which become binding only once adopted by the Commission) and issues guidelines on a comply-or-explain basis. One AMLR provision sharpens the point for agents: Article 69(1) requires obliged entities to answer a financial intelligence unit's request for information within five working days, and FIUs can shorten that to under 24 hours in urgent cases (and may extend it where justified). A five-working-day clock, compressible to a day, presumes you can reconstruct exactly what your systems did, and why.

The EU AI Act: the nuance, not the panic. Regulation (EU) 2024/1689 matters, but for AML it is a footnote with caveats, which the next section unpacks. Treat it as the place to be precise, not the place to be afraid.

Why the EU AI Act high-risk debate is a distraction for AML transaction monitoring¶

The AI Act high-risk story for AML is genuinely shaky ground in June 2026, for two independent reasons: the classification itself, and the deadline.

On classification, the key development is recent and still in draft. In draft guidelines published on 19 May 2026, open for stakeholder consultation until 23 June 2026 and not yet adopted, the European Commission set out how it reads the Annex III high-risk categories under Article 6 of the AI Act. Two points matter for financial crime, and both should be read as the Commission's draft interpretation rather than settled law (the guidelines note that only the Court of Justice of the EU can give an authoritative interpretation of the Act). First, the statutory text of Annex III point 5(b) carves out fraud detection from the creditworthiness category ("except where they are used for the purpose of detecting financial fraud"); the Commission's draft reading of that text, at paragraph 309, is that AML/CFT systems fall outside the fraud-detection exception for two stated reasons: AML/CFT is regulated by other EU legislation, and it is not related to financial fraud. Second, and more consequential, the same paragraph treats AML/CFT systems as out of scope of point 5(b) so long as their intended use does not cover the assessment of creditworthiness.

Here is the test that matters, stated plainly: under the draft guidance, an AML system becomes high-risk under point 5(b) only where it is functionally linked to and simultaneously intended to be used for evaluating creditworthiness or establishing a credit score. Read that conjunctive test carefully, because it has architectural consequences. If your institution shares model infrastructure across AML monitoring and credit decisioning, you may inadvertently pull your AML capability into high-risk scope. Clean architectural separation between financial-crime and creditworthiness functions is the practical mitigation. This is not a reason to declare AML AI "never" high-risk: the creditworthiness linkage is real, other Annex III routes (such as law-enforcement contexts under point 6) are debated elsewhere though not adopted in these Commission draft guidelines, and the test is genuinely case by case. Since only the CJEU can authoritatively interpret the Act, treat your own classification as a documented judgement rather than a settled fact.

The same draft guidelines close two escape hatches that AML teams sometimes assume protect them. On agentic systems, paragraph 75 confirms a holistic assessment: where several AI systems form a more complex system so that their combined intended purpose or joint outputs materially influence an individual decision, the combined configuration is treated as a single AI system, and split architectures are assessed as a whole, a principle the guidance expressly extends to agentic setups that coordinate through linked actions. Paragraph 90 adds that even a narrow procedural component can still be high-risk where it forms part of such an interconnected, agentic system. On human oversight, paragraphs 70 and 71 are blunt: human involvement has no effect on high-risk classification under Article 6(2), and a provider cannot make a system "low risk" simply by adding a human-in-the-loop. Human involvement can matter only narrowly, to support an Article 6(3) exemption for a genuinely narrow procedural or preparatory task, and never where profiling is involved.

On the deadline, the ground is moving under everyone's feet. Under the AI Act as originally enacted, Article 113 sets 2 August 2026 as the application date for Annex III (use-case) high-risk systems, with 2 August 2027 for high-risk AI embedded in products under Annex I. But the Commission's Digital Omnibus on AI, proposed on 19 November 2025, reached a provisional political agreement between Parliament and Council in early May 2026 (announced 7 May per the Council's press release, endorsed by Member State ambassadors on 13 May 2026). That deal would push standalone Annex III high-risk obligations to 2 December 2027 and product-embedded high-risk obligations to 2 August 2028. As of 8 June 2026 this is a provisional agreement, not yet formally adopted by the Parliament plenary and Council and not yet published in the Official Journal, so it is not yet law, and the original 2 August 2026 date legally remains in force until adoption. The honest position: for AML, the August 2026 framing is in flux both because the date itself is set to be postponed and because whether a given system is in scope is a case-by-case Annex III question in the first place.

Net of all this: do not build your AML governance programme around an AI Act deadline that is both moving and, for most AML use cases, case-by-case at best. Build it around what is already binding. If you want the technical-documentation scaffolding for the cases where classification does land, our KYC/AML Annex IV template and Article 14 human-oversight playbook are the right starting points.

What the obligation demands: human oversight, explainability, and auditable execution for AML agents¶

Strip away the regime-by-regime detail and a small set of operational requirements recurs across DORA, the coming AMLR, supervisory expectations, and the Wolfsberg principles. These are what "governed" actually means for an AML or payments agent.

The non-vendor anchor this audience trusts is Wolfsberg. On 1 December 2022, the Wolfsberg Group published its Principles for Using Artificial Intelligence and Machine Learning in Financial Crime Compliance, built on five elements: Legitimate Purpose; Proportionate Use; Design and Technical Expertise; Accountability and Oversight; and Openness and Transparency. The exact wording matters, because this reader will check it. Under Accountability and Oversight, the Principles state that "FIs are responsible for their use of AI/ML, including for decisions that rely on AI/ML analysis, regardless of whether the AI/ML systems are developed in-house or sourced externally" — a notably direct statement that buying a vendor model does not offload accountability. Under Design and Technical Expertise, design should ensure that results can be adequately explained or proven given the data inputs, and the Introduction calls for fair, effective and explainable outcomes that are monitored for consistent and stable performance after deployment. Note that Wolfsberg itself does not use the word "robust," nor require a literal right to intervene in and override automated decisions; that override duty sits in Article 14 of the EU AI Act, and the two should not be conflated. Beyond Wolfsberg, FATF, in its 2021 report Opportunities and Challenges of New Technologies for AML/CFT, treats explainability, human supervision, and firm responsibility as good-practice expectations, noting that human input remains important to catch residual risk.

Put the sources together and the requirements line up.

• Firm accountability, with intervention where the AI Act applies. Accountability stays with the firm under Wolfsberg's Accountability and Oversight element, whether the system is built in-house or sourced externally, and this applies always. Separately, where a system is in AI Act high-risk scope, Article 14 requires meaningful human oversight including the ability to intervene and override. A human-in-the-loop that cannot actually stop or reverse an action is decoration, not oversight.
• Explainability and traceable decisions. Results must be explainable given their inputs (Wolfsberg), and the practical demands of AMLR supervision, in particular the Article 69 FIU response clock, point toward traceable, auditable processes. An auto-closed alert with no captured reasoning is not an auditable process.
• Auditable, reconstructable execution. DORA's incident-reporting and resilience duties, and the AMLR's five-working-day FIU response clock under Article 69, both presume you can reconstruct precisely what a system did and why, long after the fact, to an examiner's standard.
• Third-party model risk. Because accountability does not transfer to the vendor (Wolfsberg) and AI vendors are ICT third-party providers under DORA, you must govern bought-in agents (FIS+Anthropic or any other) to the same standard as ones you build.

Where the sanctions, SAR, and payments control gates go: an AML agent lifecycle-to-evidence map¶

This is the operational centre of the argument. The requirement is not "add governance"; it is to place specific control gates at specific points in the agent's lifecycle, and to produce specific evidence at each one. The table below maps the five highest-stakes AML and payments agent actions to the regulatory hook, the runtime control gate that satisfies it, and the evidence the gate must seal.

The pattern in every row is the same. The control is a checkpoint inside the execution path, policy-as-code that decides what the agent may do autonomously versus what requires a named human, and the evidence is a sealed record produced at the moment of decision, not reconstructed afterward. For the two highest-volume cases, we have published governed-workflow blueprints: AML transaction-monitoring alert triage and sanctions-screening hit adjudication.

Read the sanctions row first, because it is the clearest illustration of why monitoring is not enough. A false auto-clear of a true sanctions hit is a sanctions breach; a false auto-block freezes a legitimate payment. Neither can be corrected by a dashboard the next morning. The gate has to sit before the action, with named-reviewer approval required above a confidence or risk threshold.

Dashboards and logs are not an AML agent audit trail: what an FIU or AMLA examiner needs¶

Here is where most agentic AML deployments will fail their first serious examination. A dashboard shows you the present. A log file shows you what a system recorded about itself. Neither is evidence in the sense an FIU, a DORA supervisor, or an AMLA examiner means it.

Evidence has three properties a dashboard lacks. It is contemporaneous, produced at the moment of the decision, not assembled after a request arrives. It is complete, capturing the inputs, the policy applied, the decision, and the human who approved it, as one sealed unit. 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; it is a test of whether your execution lineage was sealed at the moment it happened.

This is exactly where vendor positioning runs ahead of what it can prove. FIS, for instance, describes its agent as operating in an "agent-first governed environment" where "every agent decision is traceable and auditable." Take that at face value as a design goal. The structural limitation is that such a 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. That is a meaningfully weaker assurance than an independently verifiable one, and it does not solve the buyer's real problem. A real bank runs a core financial-crime vendor, a separate point vendor for screening, and in-house agents elsewhere. Three self-attested audit trails in three formats are not an evidence strategy. What an examiner wants is one neutral control-and-evidence layer across all of them. See our sample evidence export, the evidence-pack checklist of what auditors actually ask for, and the tamper-proof evidence methodology for how independent verifiability is achieved in practice. This is also where governance tooling differs from compliance-automation suites built for questionnaires rather than runtime, a distinction we draw out in our comparisons with Vanta and OneTrust.

A governed AML and payments agent in practice — and a four-week pilot¶

So what does governing by execution look like as a pattern, independent of any one vendor? It is a runtime control plane that wraps the agent you build or buy, in four moves.

Govern. You express your policy as code (which alert types the agent may auto-close, the confidence threshold above which a sanctions hit needs a named reviewer, the maker-checker rule for SAR filing) and that policy lives at the checkpoint, not in a binder. Operate. The agent runs, and at each gate the control plane enforces the policy in line: it lets routine actions through and routes the consequential ones to a named-reviewer approval queue before anything executes. Assure. Every decision, autonomous or human-approved, is sealed as it happens into an execution-lineage record with inputs, policy, and approver. Prove. When the FIU, your DORA supervisor, or an AMLA examiner asks, you produce an independently verifiable lineage package, not a screenshot of a dashboard and not the vendor's self-attestation. The decisive property is that this layer is vendor-neutral: one control and evidence plane across the FIS+Anthropic agent, the screening point vendor, and your in-house agents, mapped to DORA, the AMLR, and, where it applies, the AI Act. You can see how those controls map to each framework on our control-mapping page, and the broader picture on our financial services solution and financial-crime blueprints hub.

If this is the year you put an AML or payments agent into production, do not start with a classification memo. Start with one real workflow. Our four-week governed pilot instruments a single live AML workflow, alert triage or sanctions adjudication, and hands back governed execution metrics plus a signed lineage package you can put in front of an examiner. That is the test of whether you are governing by execution or just by paperwork. As of June 2026, with DORA already live and the AMLR two years out, the firms that win their next supervisory conversation are the ones whose evidence was sealed at machine speed, in the execution path, from day one.