Module 4: Authorization and Identity
Steps 5 and 6 in the Bundesbank flow. Layers: transaction execution, authorization and identity. Actors: the AI agent and the payment service provider of the payer.
Modules 1 to 3 happened on the customer's and the merchant's side of the flow. Nothing has yet been asked of a bank. Step 5 changes that. The agent, having chosen a product and an instrument, initiates an instant credit transfer with the payer's payment service provider. Step 6 is the provider's reply, and the Deutsche Bundesbank draws it in two colors at once: authorization and identity. This module is about that double-colored arrow.
By the end of this module you will be able to:
- Describe what passes at steps 5 and 6, and why the provider's check is the first point in the flow where the mandate is actually tested
- Explain why identification and authentication built for people do not transfer to agents, and what the identity layer has to provide instead
- Describe the three anchors the protocols use to make an agent verifiable (a signed credential, a signed request, a network token) and what infrastructure each depends on
- Set out the strong customer authentication problem and the three exemptions the Bundesbank says may carry the load
- Turn the mandate from Module 1 into the check a payment service provider runs at step 6
Step 5: the instruction
Initiation is the moment the probabilistic decision of Module 3 has to become the deterministic instruction of Module 3's last lesson. The agent sends the payer's provider a payment order: amount, payee, instrument, timing. In the Bundesbank's stylized case the instrument is an instant credit transfer, which is why the rail that matters in this course is the one most European banks already run.
The transaction execution layer is where the Bundesbank locates this. Its job is to translate the mandate from the authorization layer into an executable payment instruction. Note the direction of that sentence. The instruction is derived from the mandate, not just checked against it. A product that builds the instruction first and looks for a mandate afterwards has the layer backwards.
Step 6: the demand
The provider does not simply execute. The chart shows a two-way arrow back to the agent, labeled authorization and validation. The provider is asking two questions, and they map onto the two layers the arrow is colored with.
Who are you? This is identity. The provider needs to know that the thing sending the instruction is a specific, uniquely identifiable agent, and that it is the agent it claims to be. The Bundesbank's reason for putting identity at the heart of the system is that actions are attributable only once agents are clearly identified. No attribution, no liability, no audit.
What may you do? This is authorization. The provider needs to know that this agent holds a mandate from this customer that covers this instruction: in scope, within limits, not expired, not revoked. Module 1's five fields are the checklist. Module 3's deterministic check is the test. Step 6 is where someone outside the agent runs it.
Step 6 is the first point in the flow where the mandate is tested by a party that did not write it and does not run the agent.
That is why the Bundesbank's prediction from Module 1 bites here. Because PSD2 places the burden of proof on payment service providers, they will execute agent-initiated payments only when assured those payments meet the statutory requirements. The provider at step 6 wants the mandate, or a verifiable proof of it, in its hands.
Why the old identity does not transfer
The Bundesbank's account of traditional identification is worth setting against what an agent needs.
In today's systems identification is often implicit: an account number, card data. Authentication is a password, a possession, a biometric, singly or in combination. Every one of those mechanisms assumes a natural person. A biometric belongs to a body. A possession factor is a phone in a hand. A password is something a person remembers. The Bundesbank's conclusion is flat: these mechanisms are tailored to people and are not directly applicable to autonomous agentic systems.
What the identity layer has to provide instead is a way for an agent to identify and authenticate itself to a payment service provider with no human action involved. Two properties follow. The identity must be unique to an agent instance, not to a product or a vendor, because the Bundesbank's rule is that mandates can only be issued to uniquely verifiable agents. And the proof must be checkable by the provider without calling the agent's operator, because the provider is the party carrying the burden of proof.
Two layers, one arrow
The Bundesbank says the authorization layer is closely linked to the identification layer because mandates can only be issued to uniquely verifiable agents. The chart agrees: the same three protocols sit in both boxes. That is the single most useful thing to understand about Module 4. A protocol that proves identity without carrying authority answers half of step 6. A protocol that carries authority without proving identity answers the other half. The provider needs both, from something it can verify, before it moves a cent.
I have written about the convergence from the payments side in The Identity-Payment Convergence. Here the convergence has a step number.
Next lesson: the three anchors. A signed credential, a signed web request, a network token.