AI Agents Under MiCA, DORA and EU AML Rules 

• MiCA, DORA and the EU AML package never mention AI, and they bind AI agents from day one with no phase-in because obligations attach to the authorized entity performing the regulated act.
• The Digital Omnibus on AI, in force 27 July 2026, pushed Annex III high-risk duties to 2 December 2027, but AML and fraud detection were never in Annex III and Article 50 transparency landed on 2 August 2026 regardless.
• Six of the nineteen critical ICT third-party providers designated by the ESAs on 18 November 2025 are the same entities selling model capacity to European finance, and nobody has published whether model-serving APIs were assessed in those decisions.
• The practical explainability obligation reaches EU firms through AML justification duties and MiFID conduct rules, both already applying, well before the AI Act’s high-risk transparency and human oversight requirements come into force.
• The EBA found that over half of the serious compliance failures in its EuReCA database involved improper use of RegTech tools, while 70% of competent authorities reported high or rising ML/TF risk in the sector.

Three days ago the EU AI Act’s transparency obligations started applying to anyone running a customer-facing chatbot in Europe, and six days before that, a regulation amending the AI Act entered into force and pushed the high-risk obligations that would have covered credit scoring out to December 2027. A month before either of those, MiCA’s transitional cover expired across the Union and left unauthorized crypto-asset service providers with no legal basis to serve EU clients at all. Anyone running AI agents inside a European financial institution and waiting for the rulebook that governs them has spent six weeks watching the answer arrive from three directions at once, and none of the three instruments doing the binding mentions artificial intelligence anywhere in its operative text.

The framing error is treating “AI agents” as a regulatory category that either exists or does not. It does not exist in MiCA, in DORA, or in the EU AML Regulation, and its absence is not a gap. All three regimes attach their obligations to the authorized entity performing a regulated act, which means the agent inherits every duty its deployer already carries, from the moment it is switched on, with no phase-in and no transitional relief. The one instrument written specifically for AI is also the one that has been giving out lead time, and it just gave out more.

Technology neutrality took away your phase-in

What a firm gets from the AI Act is a schedule. What it gets from MiCA, DORA and the AML package is a set of obligations that were already running when the agent was deployed, because those regimes never described the technology in the first place. DORA governs ICT systems, and a machine-learning model that scores transactions is an ICT system in exactly the way a rules engine is. MiCA governs the provision of crypto-asset services, and an execution algorithm placing client orders is providing a crypto-asset service on behalf of an authorized firm. The AML rules govern customer due diligence and transaction monitoring, and an automated screening tool is the means by which the obliged entity discharges those duties rather than a substitute for them.

New Scam Prevention Course. Never make a rushed crypto decision again.

Deploying a new agent therefore starts no compliance clock, because it lands inside a framework that was already applying, and the supervisory question on day one is whether the control it just replaced is still being performed to the same standard. The AI Act itself reinforces this by deferring to the sectoral acquis, allowing limited derogations for financial institutions where equivalent internal governance and quality management requirements already sit in EU financial services law, which is the legislature conceding that the sectoral rules do most of the work. Firms treating an agent rollout as a project with a compliance workstream running alongside it are describing a sequence the law does not recognize.

What the Digital Omnibus moved, and what it left standing

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published on 24 July 2026 and entered into force three days later rather than after the customary twenty, on the reasoning that the application date it was amending fell on 2 August. It defers the high-risk obligations for standalone Annex III systems to 2 December 2027 and for AI embedded in regulated products to 2 August 2028, and it softens the Article 4 AI literacy duty from a requirement to achieve a level of competence into a requirement to support its development.

Annex III captures creditworthiness assessment and credit scoring of natural persons, and risk assessment and pricing in life and health insurance, so those use cases got eighteen extra months of runway on the AI Act’s documentation, logging, human oversight and accuracy requirements. It does not capture AML and fraud detection, which sit outside the credit-scoring entry by an express carve-out, so the single most common AI deployment in European banking was never going to be high-risk under the AI Act and gained nothing at all from the omnibus. And the transparency obligations that landed on 2 August were untouched, which means every deployer of a customer-facing conversational agent now has a disclosure duty that arrived on schedule while the substantive risk-management duties slid off into next year.

A firm whose AI governance program is organized around AI Act readiness has just been handed relief on the obligations it can most easily document and none on the obligations its supervisor will ask about first. Model documentation is a deliverable. Explaining why an automated system declined a transaction is a supervisory conversation, and that conversation is governed by AML and conduct rules that have no deferral mechanism.

DORA makes your model vendor the interesting problem

Under DORA an AI agent is an ICT asset, which means it belongs in the register of information, inside the ICT risk management framework, in scope for the incident reporting regime when it fails, and eligible for inclusion in threat-led penetration testing under Article 26 where it supports a critical or important function. None of that is controversial and most of it is administratively dull. The part that has changed materially is the third-party layer.

On 18 November 2025 the ESAs published the first list of designated critical ICT third-party providers, nineteen entities assessed against DORA’s criteria for systemic importance, role in supporting critical functions, and substitutability. The list includes Amazon Web Services EMEA, Google Cloud EMEA, Microsoft Ireland Operations, Oracle Nederland, IBM and SAP, which is to say it includes the contracting entities through which most European financial institutions buy frontier model capacity. Those providers now sit under direct oversight by a Lead Overseer, and Article 35 gives that Lead Overseer the power to impose periodic penalty payments of up to 1% of the provider’s average daily worldwide turnover, running for up to six months.

DORA designates the provider, and the oversight engagement assesses whether that provider manages ICT risk soundly across the services it delivers to financial entities. The criticality assessments themselves are not published in a form that shows whether model-serving APIs were weighed alongside cloud infrastructure in reaching those decisions, and there is no public supervisory statement resolving it. A firm buying inference capacity from a designated entity should not assume the model layer has been separately assessed, and should not assume it has been excluded either. The perimeter was drawn for infrastructure and the model layer arrived inside it by corporate structure rather than by deliberate supervisory design, and nobody has said out loud yet whether that was intended.

The European Parliament noticed the same thing from the other end. In the Economic and Monetary Affairs Committee report it adopted on 25 November 2025, Parliament asked the Commission and the ESAs to assess whether DORA’s exit strategy and transition provisions can be applied at all to AI models hosted on third-party infrastructure, flagging the sector’s heavy reliance on third-country providers for AI services. That is a legislature telling supervisors it does not know whether one of DORA’s core third-party protections functions in this context, nine months after the regulation started applying. The same report warns that concentration among AI providers serving investment advice could produce herd behavior across firms running similar models on similar data.

And when four or five providers supply the model capacity behind most of the sector’s automated controls, a degradation at one of them is not a vendor incident at one bank, and DORA’s oversight framework exists precisely because sectoral dependencies of that shape are hard to unwind through individual contracts. Article 28 keeps the financial entity fully responsible for compliance regardless of what it has outsourced, which is a sentence worth rereading before signing a model-serving agreement that disclaims liability for output quality.

The future of finance is here. Trade crypto and more

Incident reporting is the other place where the fit is imperfect, because DORA’s classification criteria were built around disruption, and the characteristic failure mode of a deployed model is not disruption. A screening model whose accuracy drifts as customer behavior shifts stays available, stays responsive, and keeps returning outputs that look exactly like the outputs it returned last quarter, while the control it implements quietly stops working. Nothing in that sequence trips a duration or downtime threshold, and a firm relying on availability metrics to tell it when to report will report nothing at all. The obligation to detect that failure exists, since DORA requires mechanisms to promptly detect anomalous activities, but the detection has to be built into model monitoring rather than inherited from infrastructure alerting.

Under MiCA, an agent cannot hold what its operator is not licensed to hold

For crypto firms the operative fact is that the transitional period ended on 1 July 2026 with no extension anywhere in the Union, and ESMA spent the preceding week telling unauthorized providers to wind down in an orderly manner while continuing to run full AML controls throughout the exit, including customer due diligence, transaction monitoring, sanctions screening, suspicious activity reporting and transfer traceability. Buried in the same statement is a line that should reshape how agent-mediated services are structured, because ESMA reminded firms that MiCA prohibits CASPs from outsourcing or delegating certain services, notably custody, to entities that are not themselves authorized as CASPs.

Any architecture where an autonomous agent holds keys, initiates transfers, or sits between a client and their assets on behalf of an unlicensed operator runs straight into that prohibition, and the fact that the intermediary is software rather than a subsidiary changes nothing. MiCA also reaches ICT directly through Article 68(7), which requires CASPs to maintain resilient and secure ICT systems in accordance with DORA, so the two regimes are not parallel tracks that a firm can satisfy separately. The crypto license carries an operational resilience obligation defined by reference to the cross-sectoral regime.

Agents also create record-keeping work nobody budgeted for, since MiCA requires CASPs to keep records of all services, orders and transactions in a form accessible to competent authorities, and an agent that generates thousands of decisions an hour produces a volume of reconstructable events that a manual review function was never sized for. Keeping the log is straightforward. Being able to explain, eighteen months later, which model version, which input state and which parameter produced a specific execution is a different engineering problem, and it is the one supervisors will test.

An AI agent cannot be a customer, and AML law assumes one

The AML Regulation brings crypto-asset service providers fully into scope as obliged entities from 10 July 2027, alongside the Directive whose transposition deadline lands the same day, while the Travel Rule regulation has required originator and beneficiary information on crypto transfers since 30 December 2024. None of these instruments contemplates a non-human customer, which reflects an assumption rather than an oversight. An AI agent has no legal personality, cannot be a customer, and cannot be a beneficial owner, so the natural or legal person operating it is the customer and carries the entire due diligence relationship.

That resolves the identification question and leaves the harder one untouched. Transaction monitoring works by establishing a behavioral baseline for a customer and flagging departures from it, and an agent’s baseline is generated by a prompt and a strategy rather than by a person with habits. A customer who instructs an agent to rebalance continuously produces a pattern that looks, to a monitoring model calibrated on human behavior, like structuring. A customer who changes the agent’s instructions produces a discontinuity that looks like account takeover. Firms are going to spend the next two years recalibrating for a class of legitimate behavior that their existing typologies read as suspicious, and the same period defending the false negatives that recalibration introduces.

Running underneath that, the EBA’s 2025 Opinion on money laundering and terrorist financing risks reported that over half of the serious compliance failures logged in its EuReCA database involved improper use of RegTech tools, attributing the pattern to poor implementation, missing expertise and thin oversight rather than to the tools themselves. The same Opinion records criminals using AI to automate laundering, forge documents and evade detection, and 70% of competent authorities reporting high or rising ML/TF risk in the sector. Both findings point the same direction, because the technology is being deployed on the attack side faster than the institutions deploying it on the control side can validate their own models, and the EBA’s own casework says the control side is where the documented failures are accumulating.

Article 69 of the AML Regulation adds a response clock on top of all this, obliging entities to reply to FIU requests for information within five working days, with the FIU free to compress that to under twenty-four hours in urgent cases. An agent-driven monitoring stack that produces alerts faster than a compliance officer can reconstruct the reasoning behind them fails on the ability to answer a regulator inside a deadline written for a smaller volume of better-understood decisions, and detection quality has nothing to do with it.

The explainability duty arrives from the side

Neither MiCA nor DORA imposes a model explainability requirement in terms. The AI Act does impose transparency and human oversight obligations on high-risk systems, and those are precisely the ones the omnibus moved to December 2027. A firm reading only those three instruments would reasonably conclude it has eighteen months before anyone can demand an account of why a model reached a decision.

In crypto, one bad click is final. Learn to verify before you lose.

That reading fails on contact with the AML and conduct regimes. Filing a suspicious activity report requires a rationale that survives supervisory review, retained under the AML Regulation’s five-year retention period. Refusing a customer, exiting a relationship or freezing a transaction generates a defensible-reasons obligation regardless of what produced the decision. And ESMA’s May 2024 statement on AI in investment services set the conduct expectation early, telling firms that MiFID II organizational and best-interest duties apply to AI-assisted processes, that they need controls over data accuracy, sufficiently frequent ex-post monitoring of AI-driven client interactions, and control over employee use of AI systems including third-party tools adopted without senior management’s knowledge. That last point is the shadow-AI problem stated by a regulator two years before most firms had a policy on it.

So the practical explainability obligation for a European financial institution runs through conduct and financial crime rules that already apply, and it will bite well before the AI Act’s Article 13 and Article 14 duties come into force. Firms sequencing their AI governance work off the AI Act calendar have the order backwards.

Where the exposure sits

DORA does not set fines on financial entities directly, leaving enforcement to national supervisory regimes, which makes its headline number the 1% of average daily worldwide turnover the Lead Overseer can impose on a designated critical provider. The AML Directive raised the ceiling for serious, repeated or systematic breaches to the higher of €10 million or 10% of total annual turnover, up from €5 million and 5%. MiCA leaves sanctions to national competent authorities, with license withdrawal available and, since 1 July 2026, the simpler position that operating without authorization is a straightforward breach of EU law.

The AML Authority takes over direct supervision of up to forty selected obliged entities from 1 January 2028, with selection beginning by 1 July 2027 and expected to include payment institutions, e-money institutions and crypto-asset service providers alongside the large banking groups. ESMA’s June statement on the MiCA wind-down noted that ESMA and national authorities will work together with the EBA and AMLA on unauthorized cross-border providers, which is four supervisory bodies coordinating on a single population of firms. An AI deployment that touches crypto services, ICT resilience and financial crime controls at once is visible to all four of them, and none of them is waiting for an AI-specific mandate to ask about it.

What a serious firm does now

Inventory every agent, classify it by the regulated function it touches rather than by the technology it uses, and accept that classification determines which of the three regimes governs it. Assume the AI Act is your least binding constraint and build the governance program around AML justification duties, MiFID conduct expectations and DORA’s ICT framework, because those are the obligations with no deferral and the supervisors with existing enforcement histories. Read your model-serving contracts against DORA’s third-party requirements on the assumption that your provider is either already designated or plausibly will be, and price the possibility that oversight-driven contractual changes arrive from your vendor rather than from your regulator. Retain the decision trail at a granularity that lets someone reconstruct a specific automated outcome years later, since that capability is what every one of these regimes converges on when it stops being theoretical.

Parliament’s own conclusion, in that same November report, was that sectoral financial legislation is mainly sufficient to cover AI deployment as it currently stands, and that additional legislation would add complexity and uncertainty rather than protection. In the next breath it complained about regulatory overlaps and a lack of guidance on how they interact, which introduces legal uncertainty and slows adoption. Both things are true at once, and the combination describes where a compliance function sits right now, fully covered by rules it has no authoritative reading of.

The gap in European law is coverage of a different kind. Three regimes reach AI agents fully, and they do it by binding the licensed entity behind the agent to the standard it always carried. What none of them has is a worked answer for how a named accountable person supervises a system that acts thousands of times an hour without producing a moment where anyone signs anything, and that question is being settled inside supervisory dialogues and inspection findings rather than in legislation.