MCP, A2A and AP2 often appear in the same sentence, as if together they formed one finished stack for agent-mediated commerce. They don't. Each addresses a different boundary, comes from a different starting point, sits at a different level of maturity and needs different security controls.
For a bank, the distinction matters because each protocol answers a different question. MCP answers "how does an AI application reach this capability?" A2A answers "how do two independently operated agents work on a task together?" AP2 answers "what evidence shows that a person authorised this payment?" None of them answers the question a bank most needs answered: should this action be allowed, for this client, right now?
Kestrel Bank and its customers are fictional, and their products, figures and systems are illustrative. After the executive discussion in Part 1, Kestrel's payments architect was asked a direct question by the Head of Digital Channels: "Which of these do we need to support, and what does each one buy us?" This part follows the answer.
Three protocols, three different jobs
| Protocol | Plain-language job | Banking example | What it does not prove |
|---|---|---|---|
| MCP | Connect an AI application to tools, resources and prompts | An assistant discovers a fee-explanation tool | That the caller is authorised to move money |
| A2A | Let independently operated agents discover each other's capabilities and coordinate tasks | A personal agent asks a bank's agent for a savings offer | That either agent's judgement or data is trustworthy |
| AP2 | Carry signed, verifiable mandates for agent-mediated payments | A client signs approval of a specific purchase, or of rules for later ones | That the agent understood the client's need before the signature |
Kestrel's architects found it useful to sort the three by the boundary each one crosses: from an agent into a tool, from one agent to another, and from a person's authority into a payment.
MCP: agent-friendly access to capabilities
The Model Context Protocol standardises how an AI application talks to servers that expose tools, resources and prompts. Instead of every assistant building a bespoke integration to every service, a service can publish its capabilities once in a form any compliant AI application can discover and call. The current specification is dated 28 July 2026. Anthropic, which created MCP, donated it in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation.
For a bank, an MCP server might expose carefully bounded capabilities such as:
- retrieve the available balance;
- retrieve categorised transactions;
- explain fees and product terms;
- list a client's existing beneficiaries;
- prepare, but not submit, a payment instruction;
- request a human approval challenge.
MCP is not a replacement for the bank's API management, authentication, authorisation, fraud, transaction processing or audit. The specification says so itself. It warns that MCP "enables powerful capabilities through arbitrary data access and code execution paths", and acknowledges that the protocol cannot enforce security principles on its own; implementers must. In other words, MCP makes a capability easy to reach. Whether reaching it is safe is still the bank's problem.
Kestrel's first decision was modest. A read-only MCP server for public product and fee information only: what each account costs, how the notice deposit works, which documents a loan application needs. No client data and no transactions. It lets the bank learn how agents actually use its descriptions before anything sensitive sits behind them.
This is not hypothetical abroad. Some banks have already put MCP servers in front of their APIs. Danske Bank, for example, began piloting one for corporate clients in September 2026, letting them reach the bank's existing APIs from AI assistants under their own credentials. We are not aware of any South African bank offering one publicly.
A2A: communication between independent agents
The Agent2Agent protocol is aimed at a different boundary: two agents, operated by different organisations, that need to work on a task together. Google launched it in April 2025 and handed it to the Linux Foundation in June 2025. Since August 2026 it has been hosted by the same Agentic AI Foundation as MCP. The current specification is version 1.0.
The key A2A concept is the Agent Card: a machine-readable description, published at a well-known address, of what an agent is, which skills it offers, where to reach it and how to authenticate. Version 1.0 supports signed Agent Cards, so a caller can check that the description really came from the organisation it claims to.
In a banking scenario, an A2A exchange might run like this:
- Naledi's personal finance agent identifies her need for a 12-month savings product.
- It discovers the Agent Cards of several banks that offer such products.
- Each bank's agent returns a structured offer, subject to identity, eligibility and validity rules.
- Naledi's agent compares the offers against her stated preferences.
- Naledi approves an application, or asks for revised terms.
Kestrel's architects sketched exactly this: an Agent Card describing a "request a savings offer" skill. They also wrote down what it would not do. A2A can carry the conversation. It does not create a regulated marketplace, guarantee that ranking is fair, establish whether the client is eligible, or settle who is liable when an offer is misrepresented. Each of those has to come from somewhere else.
AP2: evidence of authority in agent-mediated payment
Google Cloud announced the Agent Payments Protocol in September 2025, with more than 60 partners, to address a specific gap: when an agent takes part in a payment, how does anyone later prove what the person authorised? Its answer is the mandate, a cryptographically signed record backed by verifiable digital credentials.
The original model distinguished two flows:
- Human-present: the client approves the specific cart, price and terms, and that approval is signed.
- Human-not-present (delegated): the client signs an intent mandate in advance, defining the conditions under which the agent may act later.
A further mandate signals to the payment network and the card issuer that an agent was involved, so they can apply their own risk controls.
AP2 has since moved. In April 2026 Google donated it to the FIDO Alliance and released version 0.2, and FIDO set up a payments working group co-chaired by Mastercard and Visa. It remains early: version 0.x, with a sample reference implementation rather than a mature product. Kestrel's architects treated it accordingly, as one mandate design worth evaluating, not as a standard to adopt. Other approaches exist, including Visa Intelligent Commerce, Mastercard Agent Pay, and the Agentic Commerce Protocol developed by OpenAI and Stripe, and the bank will need to see which ones its card schemes and payment partners actually support.
Mandates can strengthen evidence about authority. They do not make the surrounding systems secure, and they do not prove that the agent understood what the client needed before the client signed. Part 4 is about that gap.
The layered model
Put the three protocols into a bank's architecture and they occupy only part of it. The conversation travels over A2A or MCP at the top. Everything that decides whether an action is allowed sits lower down, inside the bank.
Reading from the top: the client expresses intent; an agent experience interprets it; A2A coordinates with other agents and MCP reaches tools; both arrive at the bank's API and policy gateway; identity, consent and fraud controls decide; payment and banking services execute; the ledger, settlement and dispute records prove what happened. Mandate evidence attaches to the decision and the execution. It does not replace either.
The diagram does not prescribe AP2, or any other protocol, as South Africa's future standard. It shows the responsibilities any implementation must cover, whichever protocols end up carrying the messages. The gateway is a control point, not a trust boundary explains why the gateway alone cannot carry all of them.
Protocol questions for banks
Before supporting any protocol, Kestrel's architects worked through these questions. The answers became the basis of their architecture decisions.
- Which specification version do we support, and how will we handle the next one?
- How is the client authenticated?
- How is the agent, or the workload running it, identified?
- How are permissions scoped, and how are they revoked?
- Which tools are read-only, which are preparatory and which are transactional?
- Who governs the product and tool descriptions agents will read?
- How is a mandate tied to the exact transaction it authorises?
- Which record is authoritative during a dispute?
- What happens when the assistant, the protocol endpoint or the provider is unavailable?
- Could we switch platforms without rebuilding our core services?
The last question shaped the design most. Kestrel decided that its own capability layer, the APIs and policy decisions that actually do the work, would stay independent of any one protocol. MCP and A2A became adapters in front of it. If a protocol changes, or a better one arrives, the adapter changes and the bank does not.
Protocol compatibility enables communication. Trust still comes from identity, policy, evidence, secure execution and accountable institutions.
The short version
Three protocols, three boundaries. MCP connects an agent to tools, A2A connects agents to each other, and AP2 carries evidence of payment authority.
None of them decides whether an action is allowed. That stays with the bank's gateway, identity, consent and fraud controls.
Respect maturity. MCP and A2A sit under the Agentic AI Foundation; AP2 is version 0.2 under the FIDO Alliance and still early.
Start with public information. A read-only server for product and fee information teaches a bank how agents behave before anything sensitive is exposed.
Keep protocols at the edge. Build the capability layer once and put protocol adapters in front of it, so switching is cheap.
Previous: Part 1, when the bank app becomes optional. Next: Part 3, one agent, five banks, one permission problem. All parts are on the series page.
How CloudNala can help
We help banks and payment teams separate protocol choices from trust decisions: mapping which capabilities could sit behind MCP or A2A, evaluating mandate approaches such as AP2 against card-scheme and partner reality, and designing a protocol-independent capability layer with adapters at the edge, so the bank can support new channels without rebuilding its core services each time a standard moves.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Agent-Ready Banking Review or write to us at consult@cloudnala.co.za