Several PSD2 exemptions from strong customer authentication could apply to an AI agent's payment: low-value payments, trusted beneficiaries, recurring payments, transfers to yourself and transaction risk analysis. Each was designed around human behaviour, and an agent can stretch every one. The payer's provider decides whether an exemption applies, and agents must never be built to engineer one.
What do the SCA exemptions allow?
PSD2 requires strong customer authentication when a payer accesses their account online, initiates an electronic payment or acts remotely in a way that could carry fraud risk. The technical standards then set out exemptions where the provider may skip it. In substance they cover:
- Low-value payments, with cumulative limits that force authentication after a run of small payments.
- Trusted beneficiaries, where the payer has added a payee to a list of trusted payees, which itself requires authentication.
- Recurring payments of the same amount to the same payee, after the first is authenticated.
- Transfers between accounts held by the same person at the same provider.
- Transaction risk analysis, where a provider with low enough fraud rates assesses a remote payment as low-risk in real time.
- Secure corporate processes used by businesses through dedicated protocols.
- Certain unattended terminals, such as transport fares and parking.
Separately, merchant-initiated card transactions under a prior agreement are treated as outside the scope of SCA rather than exempt from it. Two principles govern all of this. Exemptions are optional: the payer's provider may always ask for authentication. And they reduce friction for low-risk payments; they are not a route around authentication for risky ones.
Who applies the exemptions?
The payer's payment service provider decides, and for card payments the acquirer can request some exemptions on the merchant's behalf. Neither the agent nor the payer chooses. An agent that prepares a payment can at most present it in a way that might qualify. If you are designing agent payments, the provider's rules are the constraint you build to.
Why does each exemption need care when an agent acts?
Every exemption assumes a person paying at human speed with human habits. An agent pays at machine speed with machine habits.
Low value. An agent can split a large payment into many small ones. That might look like efficiency, but it is structuring, and the cumulative limits exist to catch it. The agent's own bounds must prevent splitting, not rely on the provider's counter to trip.
Trusted beneficiaries. Adding a payee to the trusted list requires authentication by the payer. An agent must never add trusted payees itself, and must never present a request to add one as part of an ordinary payment approval. That is the exact pattern fraudsters use.
Recurring payments. The exemption covers the same amount to the same payee. An agent that adjusts the amount each month to match an invoice falls outside it, and the provider will rightly ask for authentication. Design the agent to expect that.
Transfers to self. The lowest risk, provided both accounts truly belong to the payer at the same provider. An agent should confirm ownership from the provider's record, not from a name on an invoice.
Transaction risk analysis. Fraud models were trained on human patterns. Agent-initiated payments may look unusual, or worse, look normal while being driven by a manipulated instruction. Providers should know which payments came from agents.
Merchant-initiated transactions. An agent shopping for a payer under a stored card mandate is close to this pattern, but the mandate must cover the agent's choices. "Buy what I need" is not a mandate a card scheme recognises.
Our piece on SCA when an agent initiates a payment sets out the baseline these exemptions depart from.
How do you keep agents inside the exemptions' purpose?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| No structuring under low-value limits | Agent bound forbids splitting a payable amount into several payments | Rule configuration and blocked attempts |
| Trusted list changes only by the payer | Agent has no capability to add trusted beneficiaries | Permission records; change log on the list |
| Recurring exemption used as intended | Variable amounts flagged as needing authentication, not forced to match | Payment records showing exemption claimed or not |
| Providers can see agent traffic | Agent-initiated payments marked as such to the provider where the channel allows | Payment metadata |
| High-value payments to new payees checked | New payees above a threshold held for a named person | Hold records; see how to verify new payees on high-value payments |
| Mandate covers the payment | Each payment checked against the payer's mandate | Verdict record naming the clause relied on |
The mandate itself matters as much as the exemption. Our piece on consent and authority when an agent acts for the payer covers how to write one.
What will a supervisor or auditor ask?
- Which exemptions do agent-initiated payments rely on, and who decided?
- Can the agent split payments, add trusted payees or alter recurring amounts?
- Does your fraud monitoring distinguish agent-initiated payments?
- Show us a payment where an exemption was refused and authentication followed.
- How do you stop a manipulated instruction from passing as a low-risk payment?
What do the exemptions not cover?
Exemptions answer one question: may the provider skip authentication for this payment? They do not make a payment authorised if the payer never consented. They do not override instant payment checks such as verification of payee, and they do not reduce a provider's fraud obligations. Agents in banking also face conduct, operational and model risk expectations beyond PSD2; see our guide to 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.
Where Pryme fits
Pryme enforces bounds at the moment of action, so an agent's limit on splitting payments, adding payees or altering amounts is checked before the payment leaves, and the verdict names the bound that decided. Changes to trusted payee lists can be withheld from every agent at every depth, leaving them with the payer.
Questions people ask
Can an agent ask the payer to approve a trusted beneficiary once to save time later?
It can suggest it, but the payer must add the payee through the provider's own authenticated process. The agent should not bundle that step inside another approval.
Does transaction risk analysis cover agent payments automatically?
Only if the provider's risk analysis judges them low-risk. Agent behaviour may differ from the patterns the analysis was built on, so providers should treat agent traffic as a distinct segment.
Are agent subscriptions merchant-initiated transactions?
They can be if the merchant charges under a stored mandate that covers the charges. An agent choosing new purchases each time does not fit that pattern.