AI Agent Payments in Europe: Who Bears the Risk?
An AI assistant may approve an invoice, pick a payment route and move money in seconds. But when the beneficiary is wrong, who pays? This guide unpacks Europe’s rules on delegated authority, bank liability, token transfers and operational controls—showing why faster payments must still leave responsibility firmly traceable to institutions.
Frankfurt, Germany
Oct 5, 2026
An AI agent instructed to pay an invoice could choose the account, convert the currency and send the money before its owner reviews the transaction. If it pays the wrong beneficiary, the central question is not how autonomous the software appeared. It is whose authority the agent used—and which institution was responsible for checking and executing the instruction.
For European banks and payment firms, agentic payments introduce a new decision-making layer into an existing legal structure. They do not create an accountability-free category of finance. The difficult work is identifying where a customer’s mandate ends, where a regulated service begins and who must absorb a loss when the two diverge.
The payment function matters more than the AI label
“Agentic payment” is not a legal classification. It can describe software that prepares a transfer for approval, a service that initiates payments from an account held elsewhere, or a system that selects beneficiaries and executes transactions within pre-agreed limits.
Those differences matter under the EU’s Second Payment Services Directive, or PSD2. Payment initiation is a regulated service. Execution of payment transactions can also be a regulated activity. Whether an agent’s operator needs authorisation depends on the service it actually provides, not on whether it describes itself as an AI platform.
A model developer supplying software to a bank is not automatically a payment-service provider. Conversely, a firm cannot avoid payment-services obligations merely by presenting a regulated function as a technological feature. Technical-service exclusions have limits; payment initiation, in particular, cannot simply be reclassified as technical support.
The practical starting point is therefore a transaction map: who receives the customer’s instruction, who accesses the account, who submits the payment order, who holds funds and who executes the transfer.
A mandate is not unlimited consent
Consider a company that tells an agent to pay a supplier before Friday. The instruction may leave several choices open: which account to use, whether to convert currency and which payment route offers the lowest cost.
It should not necessarily leave the agent free to replace the supplier’s bank details, pay a different legal entity or move funds through an unfamiliar token network.
PSD2 distinguishes consent to a payment from the technical process used to authenticate it. Under Article 64, consent must be given in the form agreed between the payer and its payment-service provider. Article 72 also makes clear that recorded use of a payment instrument is not necessarily sufficient, by itself, to prove authorisation or customer fraud or gross negligence.
That distinction becomes particularly important when an agent has valid credentials but acts outside its mandate. A technically successful login does not settle whether the resulting payment was authorised.
Delegated authority should consequently specify more than a spending ceiling. It should define permitted beneficiaries, accounts, currencies and payment methods, along with the circumstances requiring fresh approval. Applicable strong customer authentication requirements and exemptions still need to be assessed; an AI-generated instruction does not remove them.
Who pays when the agent gets it wrong?
There is no single answer. An unauthorised transaction, an incorrectly executed payment and an authorised transfer induced by deception are different legal problems.
For unauthorised payments, PSD2 generally requires the payer’s payment-service provider to refund the amount immediately and, at the latest, by the end of the following business day after becoming aware of or being notified of the transaction. There are qualifications, including a specified procedure where the provider has reasonable grounds to suspect fraud. Customer liability also depends on the circumstances, including fraud or intentional or grossly negligent breaches of security obligations.
An agent that faithfully sends money to an account the customer approved presents a different case from one that independently substitutes a beneficiary. Neither should be confused with a bank executing a valid instruction incorrectly.
The customer’s status matters too. PSD2 permits contractual departures from certain protections for non-consumer users. A corporate treasury deploying an autonomous agent should not assume that its refund rights are identical to those of a retail customer.
Contracts between banks, customers and technology suppliers can allocate losses and establish rights of recourse. They cannot simply override mandatory protections. Nor does a supplier’s promise to indemnify a bank remove the bank’s obligations to its customers.
Operational control must survive delegation
The supervisory concern is broader than reimbursement. A system capable of issuing thousands of valid-looking instructions can turn a small configuration error into a large operational incident.
Controls should therefore sit outside the model as well as inside its instructions. Approved-beneficiary lists, transaction and aggregate limits, restricted credentials and independent checks on changed account details can constrain the consequences of a mistaken or manipulated recommendation.
Human intervention is most useful at meaningful decision points: a new beneficiary, an unusual amount or a change in settlement asset. An approval screen provides little protection if the reviewer cannot inspect the underlying instruction or challenge the proposed action.
Firms also need records sufficient to reconstruct events: the customer’s mandate, relevant inputs, policy checks, software version, payment instruction and any intervention. A model’s narrative explanation is not a substitute for a reliable transaction trail.
The Digital Operational Resilience Act, or DORA, applicable since 17 January 2025, supplies an important part of this framework for covered financial entities. Its requirements address ICT risk management, incident handling, resilience testing and third-party risk. Outsourcing a function does not outsource the financial entity’s responsibility for compliance.
Tokens change the risk, not the need for accountability
An agent moving a bank deposit through conventional payment infrastructure is not doing the same thing as an agent transferring a stablecoin to a blockchain address. The claim being transferred, the settlement arrangements and the available remedies can all differ.
The Markets in Crypto-Assets Regulation, or MiCA, regulates specified crypto-asset issuers and services. It does not provide a universal legal framework for every tokenised instrument. Tokenised deposits and tokens qualifying as financial instruments require separate classification. E-money tokens also raise questions about the interaction between crypto-asset and payment-services rules.
Smart contracts can coordinate exchanges, including delivery-versus-payment arrangements. But reducing one form of settlement exposure does not eliminate defective code, compromised signing keys, unreliable external data or shortages of the asset needed to settle.
Nor is a blockchain’s technical irreversibility synonymous with legally recognised settlement finality. Firms must establish what happens when an automated transfer succeeds technically but fails commercially or legally.
The AI Act is an additional layer
The EU AI Act does not classify every AI system used in finance as high-risk. Classification depends on the intended purpose and the Act’s categories; certain creditworthiness assessments, for example, receive specific treatment. Obligations also have phased application dates.
Payment firms therefore need a combined assessment of payment law, operational resilience, asset classification and applicable AI requirements—not an assumption that compliance with one regime resolves the others.
The governing principle is straightforward: software may receive discretion, but the institutions deploying it must retain control over the money and evidence of the authority under which it moves. Before making payments faster, an agent must make responsibility no less traceable.
Source note: The supplied draft attributes an analysis to a Deutsche Bundesbank Monthly Report dated 21 September 2026. That specific publication and its contents have not been independently verified here and are not relied upon in this article. The analysis above draws on the EU legislation linked in the text.