Agentic commerce under EU payments, crypto and AML law

The state of the law

Nothing in the payments, crypto or AML acquis mentions AI agents. That does not keep the regimes from applying: they are activity-based and technology-neutral, so an agent's transactions fall inside them the moment the activity does. The most explicit work is in the UK: HM Treasury's July 2026 consultation on modernising payment services regulation asks how consent, authentication and liability rules should adapt to agentic payments, the FCA's perimeter report and May 2026 initiatives grid flag the same question, and the ICO has agentic-AI data-protection guidance in preparation. The EU's general frameworks arrive on their own clocks, including the 2027 AML rulebook. Until tailored guidance exists, the practical protection is a documented mapping of the existing rules onto the agent's activity; what follows is ours.

Who is the customer? The AML answer

Under EU AML law, obliged entities identify customers, natural or legal persons, and beneficial owners, who are always natural persons. An agent is neither; it is a tool, and the customer is the person in whose name the account is held, with the natural persons on whose behalf the agent transacts as beneficial owners where those differ. Operationally the analysis disturbs three assumptions.

Onboarding assumes the counterparty can hold documents and answer questions; an agent-operated account needs the principal established at onboarding and the agent's mandate documented: whose agent, what authority, what limits. Monitoring assumes human behavioural baselines; an account transacting at machine cadence will either drown a rules-based system in alerts or be whitelisted and escape review, so monitoring logic needs an agent-aware profile that is itself a documented, justified decision, the same calibration discipline we described for CASP screening. And accountability assumes someone to call; the file should name the human who answers for the agent. For banks and crypto-asset service providers (CASPs), agent-operated accounts will arrive whether or not the institution has built for them, and an institution that defines an onboarding category for them is better placed than one that improvises refusals.

The travel rule with no one at the keyboard

Under Regulation (EU) 2023/1113, transfers of funds carry payer and payee information, and transfers of crypto-assets originator and beneficiary information: again, persons. An agent initiating a transfer does not become the originator; its principal, the holder of the account or address, does, and the transfer must carry that person's data. The duty sits with the payment service provider for a transfer of funds and with the crypto-asset service provider for a transfer of crypto-assets. For crypto-assets, Article 14(4) requires the originator's provider to submit the data in advance of, or together with, the transfer, securely and in line with the GDPR, and states that they need not be attached to or included in the transfer itself; so agent frameworks that touch payments have to be built to supply the provider with the principal's data through its channels, and the sound design keeps personal data off the chain.

Where an agent's wallet is not linked to a CASP, a transfer between it and a CASP's customer falls within the self-hosted-address provisions of the Regulation and the EBA's travel-rule guidelines: for the CASP's own customer's wallet above EUR 1,000, an assessment that the customer owns or controls it; for a third party's wallet, collection of the originator or beneficiary details from the customer and risk-based measures; and documented handling throughout. Where the agent transacts through a CASP account, the ordinary rules apply, and a transfer between two self-hosted wallets with no CASP involved is outside the Regulation altogether. Under current rules, a design in which an agent's wallet cannot be attributed to an identified principal produces an unserviceable counterparty, because a CASP may not execute a transfer whose parties it cannot identify.

The licensing perimeter for agent operators

The perimeter question needs care, because the Payment Services Directive (PSD2) and MiCA define regulated activity by what is done and for whom; whether software or staff does it is irrelevant. An agent that executes payments for its operator's own account raises no perimeter issue. An agent platform that executes payments or crypto transactions for third parties, holding their funds, initiating their transfers, trading their assets, is doing what payment institutions and CASPs are licensed to do, and the operator should expect to need the authorisation.

The nearest official signpost is the EBA's PSD2/MiCA interplay opinion, which shows how supervisors reason when new rails meet old perimeters: by reference to function. For stablecoin rails the EBA has gone further: since 2 March 2026 it advises national authorities to treat transfers and custody of e-money tokens for clients as payment services requiring PSD2 authorisation alongside the MiCA licence, or a partnership with an authorised provider, and to require unauthorised providers to cease (opinions of 10 June 2025 and 12 February 2026). Exchange services remain MiCA-only. That is supervisory advice; legislation will follow in PSD3/PSR, not yet adopted, which is expected to settle it.

The design questions that shape the outcome are custody (who controls keys and funds), discretion (who decides transactions), interposition (does value pass through the operator) and, decisively, the specific service performed: initiating payment orders on a user's account at another payment service provider (PSP) is itself a regulated payment initiation service without any custody, and receiving, transmitting or executing crypto orders for clients is a MiCA service without any discretion. Acting as a registered agent of an authorised institution can substitute for a licence of one's own; a partnership does not exempt a platform that independently performs a regulated service. These questions should be answered at the architecture stage, before a supervisor asks them.

One thing the documented mandate does not do is authorise payments. Under PSD2 a transaction is authorised only with the payer's consent in the form agreed with the provider (Article 64), and an agent that initiates electronic payments triggers strong customer authentication, dynamically linked to amount and payee for remote payments (Article 97), unless an exemption applies, such as trusted beneficiaries, recurring payments of the same amount or secure corporate payment processes; agent payment flows have to be designed around those exemptions or a human authentication step, and a payment outside the mandate raises the unauthorised-transaction rules.

The AI Act applies already

One duty applies now, and one discipline follows from it. Under Article 50(1), a natural person interacting with an AI system must be informed of that fact, unless it is obvious to a reasonably well-informed, observant and circumspect person that they are interacting with one; the obligation is a design duty on the provider of the system, and deployers carry disclosure duties only for specified uses. It reaches agents that negotiate or transact with humans, and leaves machine-to-machine flows outside: where a person sits at the counterparty's end, that person is, absent that obviousness, entitled to know they are dealing with a machine, clearly and at the first interaction (Article 50(5)), so terms alone do not suffice.

The second is a matter of governance: the deployer-governance logic we set out in the agent-incidents update applies with full force to transacting agents: scoped credentials, spending limits, logging and human override are simultaneously risk management, the future attribution evidence when a counterparty disputes what the agent agreed, and the file your insurer will ask for.

On attribution itself, existing contract law generally reaches the result without amendment: in Switzerland, declarations generated by software are treated as the operator's own declarations under the ordinary rules on intent and reliance, with the agency provisions left aside, and the Federal Office of Justice saw no current need for legislation in its 2024 analysis; in the EU the question is one of each Member State's national law, since contract formation and agency are not harmonised. Within the limits the operator set, the mandate documentation and the logs are therefore the legally load-bearing artefacts of the whole architecture; outside them, the rules on mistake and unauthorised acts take over.

What this means for you

• Building agent platforms: run the perimeter analysis first. Custody, discretion, interposition and the service performed decide whether you are a tech vendor or an unlicensed PSP/CASP; design against the answer.
• Deploying transacting agents: document the mandate. Whose agent, what authority, what limits, who answers; that document is part of your onboarding file and of your liability defence; it does not by itself authorise a payment.
• Banks and CASPs: create the onboarding category. Agent-operated accounts with verified principals, agent-aware monitoring profiles and named accountable humans, all of it documented.
• Build identity into the payment path. Travel-rule data means the principal's data; agent wallets outside a CASP fall under the self-hosted rules, and a wallet with no identifiable person behind it is unserviceable.
• Disclose the machine. Article 50 applies today where a human is on the other side of the agent, unless the machine is obvious; put the disclosure in the interface as well as the terms.

Isak Legal advises technology companies, financial institutions and crypto businesses on agentic AI architectures, perimeter analysis and the interaction of AI, payments and AML regulation across the EU and Switzerland. See our AI, Data & Technology, Digital Assets and Sanctions and AML pages, or get in touch.

This client update is provided for general information only, reflects the position as at 27 September 2026 and does not constitute legal advice or create a lawyer-client relationship. No agent-specific financial regulation has been issued in the EU, Switzerland or the UK as at this date; the application of existing frameworks to AI agents set out above is our analysis and should be verified against guidance as it emerges. For advice on a specific matter, please contact us.