No. Strong customer authentication exists to prove the customer is present and agrees, and an AI agent completing it would defeat that purpose. The agent can prepare a payment or a change, explain what the customer is approving and hand the authentication step to them. It must never hold the customer's passwords, one-time codes or biometric data, or relay them.
What is strong customer authentication for?
Strong customer authentication asks the customer to prove who they are with at least two independent factors: something they know, something they have and something they are. In the EU, PSD2 requires it for many electronic payments and for accessing accounts online. The details are in what strong customer authentication is.
The point is that the factors belong to the customer and cannot easily be used by anyone else. A code sent to their phone proves they have the phone. A fingerprint proves they are present. If someone else can supply those factors, the authentication proves nothing about the customer's consent.
Why can't the agent authenticate on the customer's behalf?
An agent that holds or relays authentication factors becomes a single point that can approve anything. If it is compromised, manipulated by an injected instruction or simply wrong about what the customer wanted, it can authorise payments the customer never agreed to. And once the payment settles, it may be gone.
There is also a fraud pattern to avoid. Scammers often persuade customers to read out a one-time code "to verify their identity". If customers learn that a bank's own agent asks for codes, the scam becomes easier. The agent should never ask for a code, a password or a PIN, and the bank should say so plainly.
The questions raised when an agent initiates a payment are covered in PSD2 strong customer authentication when an AI agent initiates a payment.
What may the agent do, and where must it stop?
| Task | The agent | Where it stops |
|---|---|---|
| Preparing a payment | Drafts payee, amount and reference | Approving it |
| Explaining the authentication | Tells the customer what they are about to approve | Completing the step |
| Triggering the authentication | Sends the request to the customer's device through the bank's own flow | Receiving or seeing the factors |
| Acting after authentication | Carries out the action the customer approved, exactly as approved | Changing any detail after approval |
| Recovering access | Guides the customer through the bank's recovery process | Resetting credentials itself |
| Onboarding | Collects identity evidence for KYC | Treating KYC checks as a substitute for authentication |
Note the last row. Identity checks at onboarding, covered in what KYC is, confirm who the customer is once. Authentication confirms the customer is present each time. An agent may help with the first; the second always needs the customer.
A worked example
Take a bank's app agent. A customer asks it to pay their council tax bill of 160 to an existing payee.
The agent prepares the payment and shows it: payee, amount, reference and date. It tells the customer they will be asked to approve the payment in the app. The bank's authentication flow prompts the customer for a fingerprint. The customer approves, and the agent submits the payment exactly as shown.
Later, the customer receives a call from someone claiming to be the bank's "AI assistant", asking them to read out a code to stop a suspicious payment. Because the bank's agent never asks for codes, and the app says so, the customer hangs up and reports the call.
What controls make it safe?
- Factors never reach the agent. Authentication runs in the bank's own flow, between the customer and the bank's systems. The agent sees only the result: approved or not.
- What was approved is what runs. What the customer approved is what is executed. The agent cannot change the amount or payee after approval.
- No requests for codes. The agent's instructions, tested before go-live, refuse to ask for or accept passwords, codes or PINs.
- Clear customer messaging. The bank tells customers that its agent will never ask for authentication details.
- A record per approval. Each prepared action, the authentication result and the executed action are filed together.
Business customers present a related case, because authority depends on the mandate; see whether an AI agent can onboard a business customer. The wider limits are in AI agents in banking: what they may and may not do.
Where Pryme fits
In Pryme, an agent can be certified to prepare a payment, but authenticating for the customer is not a capability any agent holds. Requests for codes or passwords fall outside the role scope and are refused, and the refusal is filed. The customer's approval arrives as a signed result from the bank's own flow, never as a factor the agent handled.
Questions people ask
Can a customer delegate authentication to an agent they trust?
Not by handing over their factors. Where payment schemes or banks offer formal delegation, such as a mandate for recurring payments or a consent for a regulated provider, the customer authenticates once to set it up, and the delegation has defined limits.
Are there payments where authentication is not required?
Rules allow exemptions in some cases, such as some low-value or trusted-payee payments. The bank decides when exemptions apply; the agent does not.
What if the customer cannot complete authentication?
The agent explains the bank's recovery options and passes the customer to a person if needed. It never offers a workaround.