Where the mandate sits in the architecture
The Bundesbank's second chart describes six layers. Agentic payments operate mainly in the layers upstream of clearing and settlement; the settlement layer itself is expected to be complemented rather than replaced. The mandate lives in the authorization layer, but it touches three others directly.
The Bundesbank calls the communication layer strategically important because it is the gatekeeper: an agent can only use a payment instrument that has been exposed to it. I would put the authorization layer alongside it, for the reason the Bundesbank gives in the same paragraph. Whoever sets the standard for mandates effectively shapes the conditions for every other layer, because they decide which agents may initiate transactions and under what conditions.
The key question is not only which technology will prevail, but who will shape the decision-making and authorisation layers of payment systems in the future.
That is a central bank saying, in its own publication, that the mandate standard is a sovereignty question. I come back to the market structure argument in Module 6. For now, hold the practical consequence: the mandate is not a feature of a product. It is a position in the architecture.
The protocols that carry mandates today
Three protocols are currently positioned at the authorization layer, and the same three reappear at the identity layer. That overlap is not an accident; the Bundesbank's point is that authorization and identity are inseparable, so any protocol that does one is pulled into doing the other.
What follows is descriptive. For each protocol I give who published it, what it is designed to do, and how it treats the mandate. I do not score them and I do not say which will win. The Bundesbank's view on relative position is reported in its own paragraph at the end of the section.
AP2: Agent Payments Protocol
Published by Google in September 2025 as an open protocol, with a launch list of more than 60 payments and technology partners. AP2's central idea is the mandate as a signed object. The user's intent is captured as an intent mandate, the specific cart the agent assembles is captured as a cart mandate, and both are cryptographically signed verifiable credentials that travel with the transaction. The design goal is a tamper-evident chain from what the person asked for to what was paid for, so that each party can prove what it was authorized to do.
Mapped to the five fields: principal and agent are bound through the signature; scope is the intent mandate; limits are expressed inside the intent mandate; lifecycle is handled by the credentials' own validity. AP2 is designed to be payment-method agnostic, covering cards, account-to-account and stablecoin rails.
TAP: Trusted Agent Protocol
Published by Visa in October 2025, developed with web infrastructure partners including Cloudflare. TAP's starting problem is the merchant's: how does a website tell a legitimate shopping agent apart from a scraper or a bot, and how does it receive the agent's intent and payment credentials in a form it can trust? TAP uses signed HTTP requests so the agent can present its identity and intent to the merchant's existing infrastructure at checkout.
Mapped to the five fields: TAP concentrates on the agent field and on presenting scope and intent to the merchant. It is an identity-first design that carries mandate information, rather than a mandate-first design that implies identity.
Agent Pay
Published by Mastercard in April 2025. Agent Pay introduces agentic tokens, an extension of Mastercard's existing tokenization, so that an agent transacts with a token tied to the agent and the consumer rather than with raw card credentials. The design intent is that the consumer's authority to the agent, and the agent's identity, are both carried through the network's existing token and authentication infrastructure. Mastercard's May 2026 release describes the first live, authenticated agentic transaction in Germany under this model, with cards from Deutsche Bank, DZ Bank and N26 as the issuers in the pilot.
Mapped to the five fields: principal, agent and limits are bound through the token and the network's authorization rules; scope and lifecycle are managed through the token's provisioning and revocation.
What the Bundesbank says about relative position
The Bundesbank's own assessment, in its September 2026 Monthly Report, is that AP2 has already taken a particularly prominent position among authorization protocols, and that TAP and Agent Pay are attempting to establish themselves as trusted alternatives. At the identity layer it names TAP, Agent Pay and AP2 together as emerging agent identity verification solutions. It describes the whole landscape as early and fragmented, with several approaches competing and no certainty about which standards will prevail.
That is the Bundesbank's view, reported as theirs. I do not add a ranking of my own.
The practical reading
All three protocols accept the Bundesbank's premise that a mandate has to be verifiable without a human. They differ on where the verification anchors: a signed credential (AP2), a signed web request (TAP), or a network token (Agent Pay). For a product team the question is not which is best but which anchor your payment service provider, your merchants and your agent framework can all verify. I return to that interoperability problem in Module 4.
Disclosure: 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. Mastercard's Agent Pay is covered on the same factual basis as every other protocol in this course, with no ratings, rankings or comparative positioning.
Next lesson: the three failure modes that originate at step 0, the PSD2 questions they raise, and the exercise.