Strong customer authentication still applies when an AI agent starts a payment. The agent may prepare it and request authentication, but the customer must complete it with their own factors, on their own device, against the exact amount and payee. An agent that holds a customer's password, device or one-time code is not authenticating the customer. It is impersonating them.
What does strong customer authentication require?
PSD2 requires a payment service provider to apply strong customer authentication when a payer accesses their account online, initiates an electronic payment, or does anything remotely that could carry a risk of fraud. Authentication must use at least two elements from three categories: knowledge (something only the user knows), possession (something only the user has) and inherence (something the user is). The elements must be independent, so that breaching one does not compromise the others. Our explainer on what strong customer authentication is covers the basics.
For remote electronic payments there is a further requirement known as dynamic linking. The authentication code must be tied to the specific amount and payee, and the payer must be shown both when they authenticate. Change either and the code no longer works.
Who does it apply to?
Payment service providers in the EU that hold payers' accounts or issue their cards: banks, e-money institutions and payment institutions. The payer's provider is responsible for applying it. Merchants, payment initiation providers and others in the chain must support it but do not decide it. Agents that initiate payments meet SCA through whichever provider holds the payer's account.
Why can an agent never be the authenticating factor?
The whole point of SCA is to prove that the person consenting is the payer. Each element is defined by its link to the user: something only the user knows, has or is. An agent is none of those things.
Consider the ways teams are tempted to get round this:
- Storing the password. The agent now knows the knowledge element. So does anyone who compromises the agent.
- Holding a device binding. The agent's server now has the possession element. It is no longer something only the user has.
- Relaying one-time codes. The agent asks the customer to read out a code sent to their phone. This is the same pattern social engineering fraudsters use, and it trains customers to hand codes to whoever asks.
- Approving on the customer's behalf. The agent clicks "confirm" in an authentication flow. There is no customer in the loop at all.
Each turns two independent factors into one point of failure, the agent. If the agent is manipulated by a prompt injection or a false instruction, it can authenticate any payment. Our short answer to whether an agent can complete SCA for a customer is no, for these reasons.
The design that works is a hand-off. The agent prepares the payment with amount and payee. The provider sends an authentication request to the customer's own device. The customer sees what the agent prepared, exactly, and approves or refuses. Dynamic linking then guarantees that what was approved is what executes, so an agent cannot alter the payment after the customer approved it.
How do you meet SCA with an agent in the flow?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Two independent elements from the customer | Authentication happens only on the customer's own enrolled device and factors | Authentication record from the provider |
| Agent holds no credentials | Agent has no access to passwords, device keys or one-time codes | Secret scans and access reviews of the agent's environment |
| Customer sees what they approve | Authentication screen shows the amount and payee the agent prepared | Screen content captured with the authentication result |
| Dynamic linking holds | Any change after approval invalidates the code and needs new authentication | Failed and repeated authentication records |
| No code relaying | Agent brief forbids asking for codes; conversations scanned for requests | Transcript scans and findings |
| Agent intent is visible | Payment marked as agent-prepared in provider records where possible | Payment metadata |
Exemptions may reduce how often authentication is needed, but they bring their own risks for agents. See our piece on SCA exemptions and agent payments.
What will a supervisor or auditor ask?
- Where in the agent's flow does authentication happen, and on whose device?
- Can the agent access any authentication element, directly or indirectly?
- Show us what the customer sees when approving an agent-prepared payment.
- What happens if the agent changes the amount after the customer approves?
- Have you seen agent conversations asking customers for codes? What did you do?
- How do you tell agent-prepared payments from customer-initiated ones?
What does SCA not cover?
SCA proves that the payer authenticated. It does not prove the payer understood or intended the payment if the agent misled them, and it does not check the payee is who the payer thinks; that is verification of payee in euro payments. It does not settle the scope of the payer's mandate to the agent, which we cover in consent and authority when an agent acts for the payer. And it says nothing about whether a bank's own operations agents should move money; see what AI agents in banking may and may not do.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Can a customer give an agent standing permission so they do not authenticate every payment?
They can give the agent a mandate, and some exemptions such as recurring payments may reduce prompts. The provider still decides when authentication is required, and the agent cannot authenticate in the customer's place.
What about biometrics on a shared device the agent runs on?
The inherence element must belong to the customer and be captured on a device they control. An agent environment that can trigger biometrics without the customer present defeats the purpose.
Does this apply to business payments made by a finance agent?
Yes, for payments from accounts at EU providers. Businesses may use dedicated secure corporate processes, but a named person, not the agent, still controls the authentication.