The provider at step 6 has verified an anchor. It knows which agent sent the instruction and it has a mandate it can read. Under European payments law that is still not enough on its own, because the law asks a question the protocols do not: was the customer strongly authenticated?
The rule, as written for people
Under PSD2 a payment is authorized when the payer gives consent, and for most electronic payments the payer must be strongly authenticated: two or more factors from knowledge, possession and inherence. The Deutsche Bundesbank's footnote cites Article 64(1) of PSD2 and Section 675j(1) of the German Civil Code for the principle that each payment is generally authorized by a natural person with the proper credentials.
In the low-autonomy case this is unproblematic. The person is present, authenticates, and the agent only transmits. The Bundesbank says these models will generally already be compatible with PSD2, possibly with licensing requirements. The hard case is the one this course follows: the customer gave a mandate at step 0 and is not present at step 6.
The two questions, asked again at step 6
Module 1 introduced the Bundesbank's two open questions. They sit squarely on this step.
Is the mandate the authorization? If a mandate granted to an agent counts as the payer's consent under Article 64, the step 6 check is a check that the instruction falls within the consent already given. If it does not count, the agent is doing something that requires authorization each time, perhaps a payment initiation service within the meaning of Article 4(15), with a licensing requirement attached to whoever operates it.
Can the agent satisfy strong customer authentication? The Bundesbank asks whether largely autonomous agents can meet the SCA requirements at all, and whether existing exemptions can carry the load. It names three: low-value payments, whitelisting of merchants, and transaction risk analysis. A footnote adds a fourth route: depending on the situation, payments could be classified as merchant-initiated transactions, which fall outside the SCA requirement.
Now put those exemptions next to the mandate's five fields.
Two of the Bundesbank's three exemptions are the mandate's scope and limits fields by another name. That is not a coincidence. The exemptions were written for situations where a person had expressed, in advance, a bounded trust: a small amount, a known payee. A mandate is a general form of exactly that expression. The design conclusion is that a mandate written with the exemptions in mind is one a provider can rely on at step 6 without demanding a person authenticate.
Write the limits so they fall inside the low-value regime where you can. Write the scope as a whitelist. The provider then has an exemption to point at, not an argument to make.
The burden of proof, and what it does to providers
The Bundesbank's third point from Module 1 now has teeth. PSD2 governs compensation for payments not executed in accordance with its requirements, and the burden of proof lies with the payment service provider. Where a payment initiation service provider is involved, it must also demonstrate that the transaction was authenticated, accurately recorded, and not affected by a technical breakdown.
Read that as the provider at step 6 would. If it executes an agent-initiated payment and the customer later disputes it, the provider has to show the payment was authorized and authenticated. Its evidence is whatever it verified at step 6 and whatever it logged. A provider that cannot produce the mandate, the anchor and the record is a provider that loses the dispute. So it will not execute without them, which is the Bundesbank's prediction, and the reason the mandate has to be verifiable rather than merely sincere.
The report adds what else it expects to see: clear contractual and liability agreements between all parties, reliable documentation of the mandates granted, effective risk mitigation, easy and unique identification of trusted and legally compliant agents, and documentation standards for agent-based transactions for anti-money-laundering, fraud analysis and incident management. Every item on that list is a step 6 artifact.
Two things the law does not yet do
The Bundesbank is candid about the gaps. PSD2 is being revised into PSD3 and the Payment Services Regulation, the European legislative process is largely complete, and as things stand neither contains any specific provision governing agentic payments. The rules that apply are the general ones, applied by interpretation. And specific liability issues arising from agent error, whether a payment without a mandate, an unwanted purchase or a fraudulent merchant, might not yet be conclusively clarified by existing legislation.
The principle the Bundesbank wants applied in the meantime is "same business, same risks, same rules", with prudential proportionality for efficiency-improving innovation. For the US side of the same question, where Regulation E already allocates loss for unauthorized electronic transfers, see Who Pays When the Agent Pays Wrong? from Module 1's reading.
Practical exercise: the step 6 check
Allow 30 minutes. Take the household mandate from Module 1 and the deterministic check you wrote at the end of Module 3.
- Add the identity rows (10 minutes). Above your existing yes-or-no lines, add the checks the provider runs before it reads the mandate at all: the anchor verifies; the agent instance is one the provider recognizes; the principal named in the mandate is the account holder. Write each as something the provider can do without contacting the agent's operator.
- Pick the exemption (10 minutes). Decide which SCA route your household flow relies on for a routine €40 grocery order and for the €165 promotion case. Write the one-line justification the provider would record. If the honest answer is "none applies, a person must authenticate", say so and mark where in the flow that happens.
- Write the evidence line (10 minutes). For each row, note what the provider stores so that it can show, in a dispute six months later, that the row passed. If a row leaves no evidence, that row is a liability, not a control.
Keep the table. Module 5 follows the instruction it approves onto the rail.
Key takeaways
Step 5 derives, step 6 verifies. The instruction is derived from the mandate at execution; the provider tests it, and the agent's identity, at step 6, the first check by a party that did not write the mandate.
Identity built for people does not transfer. Biometrics, possession and passwords assume a person. The agent needs an identity unique to an instance and verifiable without a human.
Three anchors, two mechanisms. AP2 signs a credential; TAP and Agent Pay sign the request, and Agent Pay binds it to a network token. Each depends on a registry someone runs.
Interoperability is a hand-off problem. The provider, the merchant and the framework must all verify the same anchor, or the flow fails between them.
The exemptions are the mandate. Low-value and whitelisting map to limits and scope. A mandate written for them is one a provider can rely on.
The provider carries the proof. With the burden of proof on providers, no verifiable mandate and no record means no execution.
Sources and further reading
- Deutsche Bundesbank: Agentic payments: when payments learn to think, Monthly Report, September 2026, the architecture box (identity and authorization, including the footnote on mechanisms) and the box on regulatory treatment.
- European Parliament and Council: Directive (EU) 2015/2366 (PSD2), Articles 4(15), 64 and 97.
- Google: Announcing the Agent Payments Protocol (AP2), September 2025, and the AP2 specification.
- Visa: Trusted Agent Protocol, October 2025.
- Mastercard: Agent Pay, April 2025, and the German pilot release, May 2026.
- IETF RFC 9421: HTTP Message Signatures, the web standard behind signed requests.
Next: Module 5, Execution and Settlement. Steps 7a to 10: the money moves, the confirmations travel back, and the goods arrive. ACP, UCP and x402.
Charlie Major is a Product Development Manager at Mastercard. The views and opinions expressed in Major Matters are his own and do not represent those of Mastercard.