PSD2 treats a payment as authorised only if the payer consented in the form agreed with their provider. An AI agent acting for the payer changes nothing. The agent needs a written, scoped and revocable mandate, and the payer still consents through the agreed channel, usually with strong customer authentication. Without both, the payment can be challenged as unauthorised.
What does PSD2 say about consent?
The revised Payment Services Directive sets the rules for payments in the EU. A payment transaction counts as authorised only if the payer has given consent to execute it, in the form agreed between the payer and their provider. Consent can be given directly, through the payee, or through a payment initiation service provider that is itself authorised. The payer can withdraw consent up to the point the payment becomes irrevocable.
The rest of the regime hangs on that definition. If a payment was not authorised, the payer's provider must refund it promptly, and the payer's own liability is limited unless they acted fraudulently or with gross negligence. Where a payer denies authorising a payment, the provider must show it was authenticated and recorded correctly. Strong customer authentication is the main way providers show that consent came from the payer.
Who does it apply to?
PSD2 places duties on payment service providers: banks, e-money institutions, payment institutions and the account information and payment initiation providers it regulates. It protects payment service users, consumers and businesses, with some protections that businesses can agree to waive.
The agent itself has no status under PSD2. It is either the payer's own software, a feature of a regulated provider's service, or part of a merchant's checkout. Which of these it is decides who carries the risk, so settle it before the agent touches a payment. Our guide to what AI agents in banking may and may not do sets the wider boundaries.
What changes when an agent acts for the payer?
Consent was designed for a person pressing "pay". An agent introduces a gap between the payer's intention and the moment of execution, and three questions follow.
What did the payer actually authorise? "Pay my bills" is not consent to a specific payment. The payer's mandate to the agent is a grant of delegated authority, and it must be precise: which payees, which amounts, how often, until when. A mandate that says "manage my payments" is an invitation to dispute.
Was the specific payment within the mandate? Every payment the agent prepares must be checked against the mandate at the moment of action. If the agent pays a new payee because an email asked it to, the payment is outside the mandate even if the payer once said "handle invoices". Our answer on stopping an agent acting on false information covers why provenance of instructions matters here.
Did consent pass through the agreed form? The payer's provider agreed a form of consent with the payer, usually authentication on the payer's own device. An agent that holds the payer's credentials and authenticates as the payer has not obtained consent in that form; it has borrowed the payer's identity. We explain why the agent can never be the authenticating factor in our piece on strong customer authentication when an agent initiates a payment.
Authority also compounds. An orchestrating agent that hands a payment task to another agent must pass on no more authority than it holds, a point we develop in orchestration without authority sprawl.
How do you meet consent and authority requirements?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Clear mandate from the payer | Written mandate listing payees, amount limits, frequency and expiry | Signed mandate with version history |
| Each payment within the mandate | Every prepared payment checked against the mandate before submission | Verdict record naming the mandate clause relied on |
| Consent in the agreed form | Payer completes authentication on their own device for each payment or approved series | Authentication result linked to the payment |
| Instructions are genuine | New payees and changed details accepted only from verified sources | Provenance of each instruction recorded |
| Withdrawal works | Payer can revoke the mandate at once; pending payments cancelled where still possible | Revocation timestamp and cancelled items |
| Disputes can be resolved | Full record of what the agent saw, prepared and submitted | Append-only record per payment |
What will a supervisor or auditor ask?
- When an agent prepares a payment, in what legal capacity is it acting?
- Show us the payer's mandate and how a payment was checked against it.
- Who completes authentication, and on what device?
- What happens if the agent receives an instruction from an unverified source?
- How does a payer revoke the agent's authority, and how fast does it take effect?
- In a disputed payment, what evidence shows the payer consented?
What does PSD2 not cover?
PSD2 governs payment services and consent to payments. It does not regulate the agent's software, the model behind it or how the agent reasons. It does not set rules for the payer's own internal approvals in a business, which are a matter of the business's controls. Exemptions from strong customer authentication are a separate question; see SCA exemptions and agent payments. And instant payments add a further layer: once an instant transfer settles, the payer cannot practically withdraw consent.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Is a customer's instruction to an agent the same as PSD2 consent?
No. It is a mandate to the agent. PSD2 consent is given to the payer's provider in the form they agreed, and the agent's mandate does not replace that.
Who bears the loss if the agent pays the wrong person?
It depends on whether the payment was authorised, whether the provider met its duties and whether the payer was negligent. A clear mandate and a full record make that question answerable.
Does the agent need to be a licensed payment initiation provider?
If a third party offers the agent as a service that initiates payments from a payer's account at another provider, it may need authorisation. A payer's own tool, or a bank's own feature, sits differently. Take advice on your model.