One agent, five banks, one permission problem

Reading balances across several accounts is already a sensitive integration problem. Letting an agent move money, ask for offers or apply for products adds authority, intent and liability on top of it. The headline scenario, one agent working across five banks, is mostly a permission problem: who is allowed to do what, on whose behalf, for how long, and how anyone proves it afterwards.

This part sets out what the architecture would need. None of it depends on which protocol carries the messages; Part 2 explained why the protocols leave these questions open.

Kestrel Bank and its customers are fictional, and their products, figures and systems are illustrative. Kestrel's architects used a single test case throughout. Naledi wants her personal finance assistant, operated by a fictional fintech called Tally Labs, to watch her Kestrel balance and move surplus to her own savings account at Bank B. What would Kestrel need before saying yes?

Aggregation is easier than delegated action

The architecture has to distinguish four capability classes, because each carries different authority and needs a different control posture.

Naledi's request sits in the first and third rows. Tally Labs' assistant needs to read her available balance and prepare a transfer between her own accounts. Analysis is the assistant's own work, on data it was allowed to read. Execution, in Kestrel's first design, stays with Naledi: she confirms each transfer herself.

Keeping these classes separate is what allows a bank to say yes to something useful without saying yes to everything. An agent permitted to compare savings products should not, as a side effect, gain permission to transfer funds.

Reference architecture

The components an agent-mediated request passes through look like this:

1. Customer channel: where Naledi talks to her assistant.
2. Personal agent: interprets her intent and plans the steps.
3. Consent and preference store: what she has allowed and what she prefers.
4. Agent orchestration: sequences calls across banks.
5. Bank agent or API gateway: Kestrel's front door for agents.
6. Identity and delegated authority: who is asking, and on whose behalf.
7. Fraud and transaction policy: whether this action should proceed.
8. Banking services: the systems that actually do the work.
9. Payment and settlement rails: where money moves.
10. Evidence and evaluation: a record that orchestration, the gateway, the policy decision and settlement all write to.

The tenth component is easy to leave out and expensive to add later. Without it, nobody can reconstruct why an agent did what it did. The Agent Evidence Layer series covers what that record needs to hold.

Identity has several actors

A single request from Naledi's assistant involves more identities than it first appears. The system must distinguish:

• the human client, Naledi;
• the client-facing agent application;
• the agent workload, or runtime, actually making the call;
• the organisation operating the agent, Tally Labs;
• Kestrel's agent gateway;
• the downstream banking service;
• the approving human, or the delegated mandate standing in for her.

One shared API key cannot express these relationships safely. If Tally Labs' assistant authenticated with one credential for all its users, Kestrel could not tell Naledi's request from anyone else's, could not limit it to her accounts and could not revoke her consent without revoking everyone's. Identity before intelligence covers the same principle for internal AI services: establish who is calling, on whose authority, before any intelligence is applied.

Consent is not a checkbox

Useful consent specifies far more than "allow access". It should state:

• the institution and the accounts;
• the data or capability allowed;
• the purpose;
• whether the permission is to read, prepare or execute;
• transaction limits;
• beneficiary or merchant restrictions;
• the time period and expiry;
• whether further delegation is allowed;
• how the client reviews and revokes it;
• what evidence is retained.

Kestrel's architects wrote Naledi's grant as a structured record. The format below is illustrative, not a regulatory standard:

delegated_authority:
  customer_id: "kestrel-customer-ref"
  agent_id: "tally-labs-registered-agent-ref"
  operator: "Tally Labs"
  institution: "Kestrel Bank"
  permissions:
    - read_available_balance
    - prepare_own_account_transfer
  prohibited:
    - create_beneficiary
    - execute_external_payment
  account_scope:
    - "account-token-1"
  amount_limit_zar: 5000
  valid_until: "2026-11-12T23:59:59+02:00"
  confirmation_required: true
  consent_record: "signed-consent-ref"

Two points in it carry most of the weight. The grant expires after 30 days, so a forgotten permission does not live for ever. And it prohibits creating beneficiaries, which closes the most common route by which a manipulated agent could send money somewhere new.

This consent is about authority to act. It is related to, but distinct from, consent or another lawful basis for processing personal information under POPIA, where Kestrel is a responsible party and Tally Labs is, depending on the arrangement, a responsible party in its own right or an operator. The two need to be designed together and kept apart in the record, because revoking one does not automatically revoke the other. Our article on what POPIA means for your data and AI strategy covers the data side.

The bank needs an agent policy decision point

Whatever arrives at Kestrel's gateway, a policy decision point outside the language model decides whether it may proceed. It asks:

• Is this agent registered and allowed?
• Does the client have an active relationship with us?
• Is the token valid for this account and this operation?
• Does the mandate cover the amount, payee and timing?
• Is step-up authentication required?
• Does fraud scoring permit continuation?
• Has a daily or behavioural limit been exceeded?
• Must a person confirm the action?

The decision has three outcomes: allow, challenge with step-up authentication, or deny and investigate. Whichever it is, the decision is bound to the transaction and recorded. For Naledi, a transfer within her limit between her own accounts goes to challenge: Kestrel's app, on the device the bank has bound to her identity, asks her to confirm. That is the "high-risk steps" route from Part 1.

Data semantics matter

An agent can make a wrong recommendation using technically correct data. Kestrel found this in its own test environment before any client was involved.

In an early test, the assistant prepared a transfer using Naledi's ledger balance rather than her available balance. A card authorisation from the day before was still pending, so the ledger showed more money than she could actually spend. The data was accurate. The meaning was wrong, and the transfer it prepared would have pushed her account into an overdraft fee once the card transaction settled. The fix was not a smarter model. It was a field definition: Kestrel's balance capability now returns only the available balance to agents, labelled as such, with a timestamp.

The same class of error appears elsewhere:

• a pending card authorisation treated as settled;
• a promotional interest rate shown without its expiry;
• a "free transaction" shown without the monthly account fee;
• an instant payment treated as guaranteed settlement;
• a credit instalment compared without insurance or initiation fees.

Machine-readable banking needs definitions, conditions, timestamps and provenance, not only JSON. Part 6 returns to this.

Resilience and fallback

If Naledi's assistant fails, she must still be able to reach Kestrel directly. If one bank's endpoint is unavailable, the assistant must not conclude that the bank has no product or that her balance is zero. And if a transaction's status is uncertain, retrying can duplicate a payment.

Kestrel's design includes:

• idempotency keys on every prepare and execute call, so a retried request cannot create a second transfer;
• authoritative transaction identifiers returned to the agent;
• explicit pending, accepted, rejected and settled states;
• reconciliation between what agents requested and what the ledger shows;
• the rule that a timeout is not a failure: an agent that hears nothing must ask for the status, not resubmit;
• safe retry rules written down per operation;
• bank-owned fallback channels;
• limitation messages the client can actually understand.

The timeout rule mattered in testing. A slow response from the core banking platform made the test assistant resubmit a transfer. The idempotency key caught it, and the second request returned the first transfer's status rather than creating a new one.

Controls before production

Each of these elements answers one question an architecture board should ask before any agent capability reaches production: can the bank tell the actors apart, is authority specific and revocable, is every operation checked outside the model, is the data's meaning explicit, and can uncertain or duplicate actions be handled safely? Part 7 gathers these questions, and the fraud and dispute ones, into a single control matrix.

The short version

Separate read, analyse, prepare and execute. Each class needs its own permission and control posture.

Count the identities. Client, agent application, workload, operator, gateway, service and approver are all different actors.

Make consent specific and expiring. Scope, limits, prohibitions, expiry and revocation belong in the record.

Decide outside the model. A policy decision point allows, challenges or denies, and records why.

Define what the data means. Available is not ledger; pending is not settled.

A timeout is not a failure. Idempotency and status checks stop duplicate payments.

Previous: Part 2, MCP, A2A and AP2 are not the same thing. Next: Part 4, a signed mandate is not proof of good judgement. All parts are on the series page.

How CloudNala can help

We help banks design delegated authority that holds up in production: classifying capabilities into read, analyse, prepare and execute, separating client, agent, operator and workload identity, writing consent records that expire and revoke cleanly, placing a policy decision point outside the model, and defining the data semantics and retry rules that stop an accurate number from producing a wrong payment.

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