What Goes Wrong at Step 0

Every failure in an agentic payment can be traced back to a step. Three of them originate at the mandate, before a single product has been chosen.

Three failure modes

1. No mandate. The agent initiates a payment it was never authorized to make. The Bundesbank lists this first among the errors that liability agreements will need to cover. It is the agentic equivalent of an unauthorized transaction, except that the thing that acted was software the customer chose to run.
2. Mandate exceeded. The agent stays inside its scope but breaches a limit, or stays inside its limits but strays outside scope. Whether this is the agent's fault, the mandate's fault for being ambiguous, or the provider's fault for not checking is exactly the question the five fields exist to make answerable.
3. Mandate misread. The agent acts within scope and limits but misinterprets the principal's preferences, buying the wrong thing or paying the wrong way. The Bundesbank names misinterpretation of user preferences and hallucination among the sources of flawed decisions. The mandate was fine; the probabilistic system reading it was not.

The third one is the hard one, and it explains why the Bundesbank spends so long on the difference between probabilistic and deterministic systems. A mandate is deterministic: it says what is allowed. The agent reading it is probabilistic: it produces a likely interpretation. Their proposed answer is a governance framework that translates probabilistic decisions into binding, deterministic processes before execution. In mandate terms, that means the check against the five fields happens in deterministic code, not inside the model.

I have measured the second and third failure modes directly. On the Bench, a local model running under a signed mandate took a planted nudge toward an out-of-scope payment in a minority of runs, and its own summary of what it had done disagreed with the signed record in others. The write-up is The Agent Said It Updated Six Companies. The Signed Record Shows Three. The point for this lesson: a mandate check that lives outside the model catches what the model's own account of itself does not.

The PSD2 questions

The Bundesbank's regulatory annex asks two questions that sit squarely on step 0. Neither has a settled answer yet.

• Is a mandate payment authorization? Under PSD2 a payment is authorized when the payer gives consent. The open question is whether a mandate granted to an agent counts as that consent under Article 64, or whether the agent is instead performing a regulated activity such as payment initiation each time it acts, with the licensing that implies.
• Does a largely autonomous agent satisfy strong customer authentication? SCA assumes a person authenticating. The annex asks whether autonomous agents can meet the SCA requirements at all, and whether the existing exemptions for low-value payments, whitelisted merchants and transaction risk analysis can carry the load. Notice that two of those three exemptions map directly onto mandate fields: limits and scope.

There is a third point that is not a question but a prediction. Because PSD2 places the burden of proof on payment service providers, the Bundesbank expects PSPs to execute agent-initiated payments only when they are assured the payments meet the statutory requirements. In practice that means a PSP will want to see the mandate, or a verifiable proof of it, before it moves money. A mandate that cannot be shown to a PSP is a mandate that will not get paid.

The US has an older answer to a neighboring question. Regulation E already decides who pays when an electronic transfer the consumer did not authorize goes out, and I set out how far it stretches to agents in Who Pays When the Agent Pays Wrong?. The European annex and the American rule converge on the same practical demand: show the authority, or carry the loss.

Build the mandate so that a payment service provider could verify it without talking to the agent. If the five fields are encoded in a form the PSP can check against the payment instruction, the liability question has a document to point at. If they live only in the agent's context window, it does not.

Practical exercise: write a mandate

Allow 30 to 40 minutes. You will need a blank document and nothing else.

Scenario. A household wants an agent to keep the kitchen stocked. They shop at two supermarkets and one online pharmacy. They want the agent to reorder staples when they run low, to prefer an instant credit transfer over card where the merchant accepts it, and never to spend more than €150 in a week without asking.

1. Draft the mandate (15 minutes). Write one entry for each of the five fields. Be concrete: name the merchants, state the ceiling, state the instruments in order of preference, state when the mandate expires and how the household revokes it.
2. Stress-test it (15 minutes). Run these three cases against your draft and write down what the mandate says should happen, or admit that it is silent. Case A: one supermarket runs a promotion that pushes a normal weekly order to €165. Case B: the pharmacy stops accepting instant credit transfer and only takes card. Case C: the household revokes the mandate on Tuesday evening while an order placed Tuesday afternoon is still being fulfilled.
3. Make it verifiable (10 minutes). Rewrite the mandate as a structured record, a table or key-value list, that a payment service provider could check a payment instruction against without reading any prose. If a field resists being structured, that is a finding: note which one and why.

Keep your mandate. You will reuse it in Module 4, where the agent has to prove it holds the mandate, and in Module 6, where it goes wrong.

Key takeaways

Step 0 is new. Agentic payments add a step in front of the purchase: the grant of authority. Every downstream step inherits its limits from it.

Autonomy is a dial. Low, bounded or high. The Bundesbank expects bounded, with amount and instrument limits, as in a direct debit mandate. Choose your setting deliberately.

Five fields. Principal, agent, scope, limits, lifecycle. Scope and limits are different things; lifecycle is the one most often left out.

The mandate is a position, not a feature. Whoever sets the mandate standard shapes the conditions for every other layer. The Bundesbank calls this a sovereignty question.

Three protocols, three anchors. AP2 anchors on a signed credential, TAP on a signed web request, Agent Pay on a network token. Described, not ranked.

Verifiable or it does not get paid. PSPs carry the burden of proof under PSD2. A mandate they cannot verify is one they will not execute against.

Glossary

Sources and further reading

• Deutsche Bundesbank: Agentic payments: when payments learn to think, Monthly Report, September 2026. The reference text for this course. Read the supplementary box on architecture and the box on regulatory treatment first.
• Google: Announcing the Agent Payments Protocol (AP2), September 2025, and the AP2 specification.
• Visa: Trusted Agent Protocol announcement, October 2025.
• Mastercard: Agent Pay announcement, April 2025, and the German pilot release, May 2026.
• European Parliament and Council: Directive (EU) 2015/2366 (PSD2), Article 64 on consent and Article 97 on strong customer authentication.
• Monetary Authority of Singapore: Safeguards for Agentic Finance at Runtime, July 2026, for a supervisor's view of runtime controls on agent mandates.

Next: Module 2, Communication. Steps 1 and 2: how an agent that holds a mandate actually reaches a merchant and a gateway, and why the Bundesbank calls the communication layer the gatekeeper.

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.