Module 6: The Paradox
Steps 0 to 10 in the Bundesbank flow. Layers: all six. Actors: everyone who appeared in Modules 1 to 5, plus the central bank.
The Deutsche Bundesbank does not use the word paradox. I do, because it is the shortest way to name the tension the article describes without naming. Agentic payments are sold as simplification: fewer taps, no saved cards, a payment the person never sees. The architecture that delivers that simplification is the most elaborate the Bundesbank has ever drawn for a retail transaction. Complexity did not disappear. It moved, and risk moved with it.
By the end of this module you will be able to:
- State what the Bundesbank says agentic payments simplify for the person, and list what had to be added to the system to do it
- Map each risk the Bundesbank names to the step where it originates and the party who carries it
- Explain why the Bundesbank says lock-in loses its significance, and what that does to the revenue of every intermediary on the dearer rail
- Describe the four groups competing to shape the decision-making and authorization layers, and what each stands to gain
- Set out the three roles the Bundesbank assigns central banks, and the conditions it says agentic payments should be used under
- Write the conditions sheet for a product of your own: mandate, anchor, rail, checkpoint, record, route back
Simpler outside
Start with what the Bundesbank promises. Its retail section is the most optimistic part of the article. Many transactions in everyday life can be simplified. The use cases are not especially complex, and the high standardization of payment instruments gives a good basis for simple implementation. By minimizing the required user interactions and integrating search, purchase and payment, the whole purchasing process can be made efficient, error susceptibility reduced and the user experience improved.
Then the sentence that gives the module its first half. Agentic commerce applications delegate the settlement process itself to an agentic payments application, without the conscious awareness of the customer. The Bundesbank calls these "invisible" payments. A simplified process, it adds, would no longer depend on means of payment saved and authorized in various customer accounts. That is the outside view: one instruction at step 1, one parcel at step 10, and nothing in between the person has to do.
More complex inside
Now count what the course added between those two steps to make the outside view true.
The Bundesbank's own account of the inside is in its architecture box. Delegating decisions to agents requires decision-making to be considered an independent technical layer for the first time. Mandates need a layer of their own, and so does identity, because the mechanisms that authenticate people are not directly applicable to autonomous systems. The result is a multi-layered architecture with, in some cases, different protocols and market players at each layer. Eight named protocols. Four groups of actors. Two charts.
The person's part of the payment got shorter. The system's part got a new step at the front, a new layer in the middle, and an identity problem it had never had to solve.
None of this is a criticism of the design. Every piece exists for a reason the earlier modules gave. It is a description of where the work went, and work that moves is risk that moves.
Where the risk landed
The Bundesbank's challenges section lists the risks without allocating them. Allocating them is the useful exercise, because every risk it names has a step it originates at and a party who holds it when it materializes.
Read the holder column top to bottom. The customer appears in six of the nine rows. The payment service provider appears in one, and the Bundesbank's prediction for that one is that providers will decline to execute until they are assured. The system appears in two, and those are the rows the Bundesbank treats as systemic.
That distribution is the paradox stated as a ledger. The person for whom the payment was simplified is the party on whom most of the named risks land, with a liability framework the Bundesbank says is not yet conclusively clarified. The provider has a burden of proof and a way to refuse. The system has the two risks no single transaction can see.
The Bundesbank's footnote on auditability makes the customer's position sharper. Audit logs of an agent's inputs and outputs improve auditability by documenting tool usage, input values and outcomes. But because of the models' probabilistic architecture, the auditability of the reasons why a decision was made remains limited. The record can show what the agent did. It cannot reliably show why, and the why is what a dispute turns on.
The household mandate, where it goes wrong
Module 1 said you would reuse the household mandate in Module 6, where it goes wrong. Here are its three cases against the whole stack.
Case A, the €165 promotion against a €150 weekly ceiling. The limits field catches it if the step 6 check runs outside the model, as Module 3 required. The customer holds no risk. The provider has a record. This is the stack working.
Case B, the pharmacy that stopped accepting instant transfer. The agent falls back to card, inside the mandate's preference order. The payment is now on the one rail with a dispute right. If the agent bought the wrong item, the customer's route back exists because of a fallback the mandate happened to permit, not because anyone designed it. Risk landed on the customer and was, by luck, insured.
Case C, revocation on Tuesday evening with an order in flight. Module 1 said lifecycle is the field most often left out. If revocation reaches the agent but not the gateway, step 9 fires anyway. If it reaches the gateway but not the payee's provider, step 7c has already happened on an instant rail. The risk lands on the customer, and the instrument that could have stopped it was a field nobody wrote.
I have run the first of those cases on real models. On the Bench, which keeps the signed record of what an agent was allowed to do and what it did, a 20-billion-parameter model on a laptop under a bank mandate took one of 45 planted nudges and left six jobs undone; the write-up is I Put a 20B Model on My Laptop Under a Bank Mandate, and the standing entries are on the Bench. The nudge was caught by the check outside the model. The undone jobs were not a payment risk. They were a delivery risk, step 10, which the chart does not color at all.
For the general view of why agents fail the way they do, Software That Acts is the hub this course hangs off. For the specific question of who pays, Who Pays When the Agent Pays Wrong? is the answer so far.
Next lesson: who shapes the layers. If an agent can switch rails at zero cost, what happens to the margin of everyone on the dearer one, and which four groups are fighting over the layers where that choice is made?
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.