Banks have spent a decade building APIs. Many can return a balance, a transaction list or a product catalogue in clean JSON. That is necessary for agent-mediated banking, and it is nowhere near enough.
An agent that receives "rate": 9.25 still has to know whether the rate is nominal or effective, fixed or variable, how long it holds and what conditions apply. An agent that receives a balance still has to know whether that balance is available or ledger, and whether it includes pending card authorisations. Part 3 showed what happens when it guesses: Kestrel's own early test confused a ledger balance with an available one. The data was technically correct and the decision was wrong.
Machine-readable banking means an agent can interpret what the bank tells it, not only parse it.
Kestrel Bank and its customers are fictional, and their products, figures and systems are illustrative. Part 5 left Kestrel with a puzzle: its 32-day notice deposit paid a competitive rate but kept losing agent comparisons, because its conditions lived in a PDF that agents treated as an unknown risk. This part follows the fix.
APIs are necessary and insufficient
Machine-readable banking needs three layers:
- Technical contract: endpoints, schemas, status codes and versions.
- Business semantics: the exact meaning, timing, conditions and authoritative source of every value.
- Trust evidence: identity, reliability, security, disputes and proof of outcome.
Most banks are strong on the first layer, patchy on the second and have barely started on the third. Agents need all three. A schema tells an agent that a field exists. Semantics tell it what the field means. Trust evidence tells it whether to believe it.
The product passport
Every product offered to agents should have a governed product passport: one authoritative, versioned description that an agent can rely on.
| Field group | Examples |
|---|---|
| Identity | Product, provider, version and jurisdiction |
| Eligibility | Age, income, residency, account and affordability rules |
| Pricing | Fixed and variable fees, rate, tiers and calculation |
| Conditions | Minimum balance, notice, term, rewards and exclusions |
| Risk | Credit, liquidity, market or operational considerations |
| Service | Channels, availability, settlement and support |
| Trust | Licences, disclosures, complaints and protection |
| Validity | Effective date, expiry and source timestamp |
| Actions | Enquire, quote, apply, prepare, approve and execute |
The passport has to be generated from governed product and pricing sources. Marketing copy should not become the machine contract. The product page can say "earn more on your savings". The passport has to say how much, on what balance, calculated how, for how long, and under which conditions.
Kestrel's first passport was for the deposit that had been losing. An illustrative extract:
product_passport:
product_id: "kestrel-notice-32"
name: "32-Day Notice Deposit"
provider: "Kestrel Bank (fictional)"
version: "2026-10-01.3"
jurisdiction: "ZA"
pricing:
rate_type: "variable"
rate_basis: "nominal annual, compounded monthly"
tiers:
- min_balance_zar: 1000
rate_percent: 8.90
- min_balance_zar: 100000
rate_percent: 9.25
monthly_fee_zar: 0
conditions:
notice_days: 32
notice_cancellable: true
partial_withdrawal: "allowed on notice; minimum balance must remain"
minimum_balance_zar: 1000
rate_during_notice: "variable; giving notice does not fix the rate"
service:
open_channels: ["app", "branch", "partner_quote_api"]
settlement_on_withdrawal: "same day after notice period ends"
validity:
effective_from: "2026-10-01"
quote_valid_hours: 24
source: "product-and-pricing-master"
source_timestamp: "2026-10-01T06:00:00+02:00"
actions: ["enquire", "quote", "apply"]
The figures are illustrative. What matters is that every condition the PDF used to bury now has a field, and every field has a source. One line deserves attention: rate_during_notice. In the PDF, the fact that the rate stays variable during the notice period was in a footnote. In the passport, an agent can't miss it. The passport doesn't make the product look better. It makes it understandable, and in this case understandable was what the product had been missing.
Building it was harder than writing it. Three teams had slightly different views of how interest on a partial withdrawal was calculated. The passport forced them to agree on one, and the product-and-pricing master now holds that answer. That is the real value of the exercise. The machine contract exposes disagreements that human-readable documents had quietly carried for years.
Make trust verifiable
An agent can't sense that a bank is trustworthy. It needs evidence it can inspect.
Potential trust signals include:
- verified provider identity;
- authorised product and jurisdiction;
- service and settlement status;
- published fees and conditions;
- how fresh the product data is;
- security and privacy claims, with evidence;
- the complaint and dispute process;
- transaction confirmation and reconciliation;
- the ability to revoke access and recover.
Not every measure should become a public score. Some evidence belongs with regulators, participants or audited assurance schemes. The principle is that a claim an agent might rely on should be backed by something it, or someone acting for the customer, can check.
Part 2 noted that version 1.0 of the A2A protocol supports signed agent cards. A signature proves who published a description. It doesn't prove the description is accurate, current or complete. That remains the bank's governance job.
Agent discoverability
Banks once optimised websites for search engines and apps for app stores. Being discoverable by agents requires something different:
- clear capability descriptions;
- standard product semantics;
- predictable schemas;
- accurate examples;
- version and deprecation policies;
- test environments;
- clear eligibility rules and error responses;
- machine-readable terms linked to human-readable disclosures.
Poor tool descriptions are a quiet source of failure. A vague description can lead an agent to choose the wrong capability or pass the wrong parameters, and in banking the wrong parameter can be an amount or an account. Govern descriptions the way you govern API contracts: owned, reviewed, versioned and tested. The gateway is a control point, not a trust boundary covers how tool descriptions fit into the wider control picture. Part 7 shows how an altered description becomes an attack.
At Kestrel, the deposit's descriptions now live in the same repository as the API specification, and a change to either needs the product owner's approval. The team also built a small test set: a few dozen realistic customer requests, run against a handful of assistants whenever the passport or descriptions change. That is the same evaluation discipline described in evals that gate real work, applied to discoverability. If a change makes agents misunderstand the product, the test set catches it before customers do.
Separate information, recommendation and transaction
The path from a question to a completed transaction has distinct steps:
Each step needs its own permissions and evidence. An agent allowed to compare savings products should not automatically gain permission to move funds. An agent allowed to request a quote should get a quote that is clearly marked as an offer, with an expiry, and that is distinguishable from general product information. An agent allowed to prepare a transaction still needs the customer's exact approval before anything executes.
This is the capability ladder from Part 3 seen from the product side. Kestrel exposes the first three steps for the notice deposit to partner assistants. Applying still requires the customer to authenticate in Kestrel's own app, and nothing beyond that is automated.
Machine-readable does not mean agent-owned
The bank remains responsible for authoritative data and for enforcement. An agent may cache or summarise what it receives, so the bank's design has to make sure that:
- time-sensitive values carry an expiry;
- product changes are versioned;
- revoked consent takes effect;
- a quoted offer can be distinguished from general information;
- transaction state comes from the authoritative processor, not from the agent's memory of it;
- customer corrections propagate.
These rules come from data governance, and they apply to an agent's memory just as they apply to any copy of the bank's data. Agent memory is a governed data product treats the same problem from the agent operator's side. The bank's passport makes the operator's job possible by publishing validity and version alongside every value. Under POPIA, the bank stays a responsible party for the client data it releases. An agent operator processing that data under the client's authorisation has its own obligations, so the passport is no place for client data. It describes products, not people.
After Kestrel published the passport to its test environment, its notice deposit began appearing in the test assistants' shortlists. Nothing about the product had changed. Its conditions had simply become readable.
The short version
Three layers, not one. Technical contract, business semantics and trust evidence. Most banks stop at the first.
Give every product a passport. Generate it from governed sources, not from marketing copy, and give every field a source and a timestamp.
Expect the passport to expose disagreements. Agreeing on one answer is the real work.
Govern descriptions like contracts. They are owned, versioned, reviewed and tested against realistic requests.
Separate inform, compare, quote, prepare, approve and execute. Each step needs its own permission and evidence.
Machine-readable is not agent-owned. The bank stays authoritative for data, state and enforcement.
Previous: Part 5, the bank competes product by product. Next: Part 7, agentic banking expands the fraud surface. All parts are on the series page.
How CloudNala can help
We help banks make their products and services usable by agents without giving up control: designing product passports from your governed product and pricing sources, settling the semantic disagreements they expose, setting up description governance alongside your API contracts, building discoverability test sets, and separating information, quote, preparation and execution into capabilities with their own permissions and evidence.
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