The Deutsche Bundesbank names two standards as emerging at the communication layer: the Model Context Protocol and the Agent2Agent Protocol. It is careful to say that neither is specific to payments. That is not a weakness. The communication layer is general by design; it is the pipe through which payment operations are exposed, not the operations themselves.
MCP: the agent and its tools
The Model Context Protocol was published by Anthropic as an open standard. The Bundesbank's description is the right one: it provides a general foundation for how AI agents interact with external tools, services and data sources. An MCP server exposes a set of named operations, with a description of what each one does and what inputs it takes. An agent connects, reads the list, and calls what it needs.
For a payment, MCP is the mechanism by which a gateway, a bank or a merchant can make an operation callable by an agent at all. "List payment methods", "create a transfer", "check a balance" are the kinds of operations a provider would expose. I covered the protocol itself in The Protocol That Turns AI from Chat into Infrastructure, and there is a full free course on it, MCP as a Product Strategy Multiplier, if you want the product view.
Two consequences for payments.
The description is the contract. An agent decides what to call from the server's own description of its tools. If a gateway describes "pay" loosely, the agent will use it loosely. The mandate from Module 1 sets the agent's limits; the tool description sets what the agent believes the tool does. Both have to be right.
Exposure is a security decision. Every operation exposed through MCP is an operation a manipulated or confused agent can call. My weekly sweep of public MCP servers, which runs on the Major Labs side, has found more than a third carrying a risky code pattern and nearly three in four network-facing, sensitive-action servers showing no authentication in source. I Told Nine Maintainers Their MCP Servers Were Risky is the account of trying to get that fixed. A payment operation exposed through a server like that is a payment operation anyone can reach.
A2A: the agent and other agents
The Agent2Agent Protocol was published by Google in 2025 for multi-agent scenarios. Where MCP connects an agent to tools, A2A connects an agent to another agent: a way for one agent to discover what another can do, hand it a task, and get a result back. An A2A agent publishes an agent card, a machine-readable description of its capabilities at a well-known address.
The Bundesbank's reason for naming A2A is in its definition of agents. They are task-specific, so complex payment processes with several sub-processes generally use multiple agents at once. The shopping agent that holds the mandate may hand the checkout to a merchant's agent, which hands payment acceptance to a gateway's agent. Step 3 in the flow, delegation of checkout, is an A2A-shaped hand-off even where the implementation is something else.
In October 2026 the readiness scan found the first A2A agent card among the 92 largest US storefronts, AT&T's shopping assistant. I read the card and the instructions behind it, and the striking thing was what it did not do: it handed the payment back to a human. That is a legitimate design on the autonomy dial from Module 1, the low setting, and it shows that publishing an agent card and accepting an agentic payment are different decisions.
What neither protocol does
Neither MCP nor A2A carries a mandate, proves an agent's identity, or moves money. They are how the agent reaches the places where those things happen. The Bundesbank's chart makes this visible: MCP and A2A sit in the outer communication frame; AP2, TAP, Agent Pay, ACP, UCP and x402 sit in the layers inside it.
The merchant's side of the pipe
Protocols only matter where someone has implemented them. For a merchant, the question is whether an agent can find and read its catalog and reach its checkout. There are four routes a merchant can publish today, and the readiness scan checks all four: a robots.txt that does not block agents, an llms.txt describing the site for models, a UCP profile (Module 5 covers the protocol), and an A2A agent card. A merchant that has done none of these is reachable only by an agent that scrapes, and scraping is exactly what the identity protocols in Module 4 exist to distinguish from legitimate traffic.
The web is also changing underneath this. Browser-level proposals such as WebMCP aim to let a site expose its functions to an agent directly from the page, which I looked at in The Web Just Got an API. If that lands, step 2 stops depending on the merchant running a server at all.
Next lesson: who controls the integration point, and why the Bundesbank expects market power to collect there.