A signed mandate is not proof of good judgement

A cryptographically valid mandate can show that a client approved an intent or a specific transaction. It cannot show that the agent interpreted the client's situation well, presented every material option, or resisted manipulation before the approval was given.

Authority and wisdom are different questions. Payment protocols are getting good at the first one. The second is still the bank's problem, the agent operator's problem and, if nobody solves it, the client's.

Kestrel Bank and its customers are fictional, and their products, figures and systems are illustrative. Naledi's instruction to her assistant is the kind of sentence real people say:

Move my spare money to the best savings account every month.

It sounds precise. It isn't.

What "spare" and "best" hide

Before any mandate is signed, the agent has to decide:

• What amount is genuinely spare?
• Which upcoming debit orders and emergencies matter?
• Whether "best" means the highest rate, easiest access, most certainty or most total value.
• Whether moving the money affects benefits or fees on the account it leaves.
• Whether an offer is suitable for her, and still available.
• Whether tax, term or notice conditions apply.

Each of those is a judgement. A signature on the final instruction does not validate any of them.

Kestrel saw this in a controlled test of the sweep, run in its test environment with accounts built on Naledi's pattern: a salary, a medical-aid debit order on the 1st, savings at Bank B. A tester played Naledi. Three days before month end, the assistant calculated that R4,800 was spare and prepared a transfer to the savings account. The amount was within the R5,000 limit, between the client's own accounts, and the tester approved it as Naledi would have. Every check in the policy decision point from Part 3 passed, correctly.

On the 1st, the medical-aid debit order ran against an account that no longer held enough to cover it. The assistant had looked at her balance and her recent spending. It had not looked at her scheduled debit orders, because nobody had told it that "spare" meant "after the commitments that are already coming".

The mandate was valid. The transfer was exactly what was approved. The judgement was wrong.

The intent chain

A transaction initiated by an agent is the end of a chain, and each link needs its own evidence.

1. Customer goal: what the client wants, in their own words.
2. Agent interpretation: what the agent took that to mean.
3. Evidence and options: the data and alternatives it considered.
4. Recommendation: what it proposed, and why.
5. Exact approval: what the client agreed to.
6. Bank authorisation: the bank's decision to allow it.
7. Execution and settlement: what actually moved.
8. Reconciliation and dispute: how errors are found and corrected.

A payment mandate strengthens link 5. It does not secure links 2, 3 or 4, which is where Naledi's test failed. Security research on AP2 makes the same structural point: one systematic analysis published in August 2026 found that signed mandates protect the data after signing, while the inputs that shape the decision before signing fall outside that protection. Its conclusion was that valid mandate signatures alone do not ensure a transaction reflects the user's intent. Part 7 looks at how attackers exploit that gap deliberately.

Human-present approval should show the material facts

If the client's attention is the control, the approval screen has to give that attention something to work with. For a payment, it should show:

• the payer account;
• the payee and their verified details;
• the amount and currency;
• fees;
• timing and settlement type;
• whether it recurs;
• whether it can be reversed, and the dispute route;
• why the agent recommends it;
• any warning or uncertainty.

For a savings or credit product, the client also needs the rate, term, total cost, conditions, penalties, eligibility and material risks.

After the test, Kestrel added one line to its own confirmation screen for agent-prepared transfers: "Upcoming debit orders before your next salary: R…", drawn from Kestrel's own records rather than from the agent. The bank cannot make the agent's judgement better, but it can put the facts it holds in front of the client at the moment of approval. In the test rerun, the line showed the medical-aid debit order, and the tester reduced the transfer.

The rest of the screen matters too. An approval that shows only "Transfer R4,800 to savings? Approve" invites the reflexive tap that human oversight that shows its work warns about.

Delegated authority needs narrower rules

In a delegated flow, the client signs rules in advance and the agent acts later without asking again. The limits now have to carry the weight that the client's attention carried in the human-present flow.

Delegated payments should begin with small, repeatable and reversible cases, where the limits can be expressed clearly:

• pay a known utility bill up to a maximum amount;
• top up prepaid services within a monthly budget;
• move a capped surplus between the client's own accounts;
• renew a known subscription if the price has not risen beyond a threshold.

High-value payments, new beneficiaries, credit, investments and irreversible decisions should require stronger human involvement until regulation, evidence and operating practice mature.

Kestrel's sweep pilot stayed human-present for exactly this reason. When it later designed the delegated version, the rule was written as "surplus above the sum of scheduled debit orders before the next salary, plus a reserve the client sets", not "spare money". The words the client uses and the rule the agent applies are allowed to differ; the difference just has to be explicit, shown to the client and recorded.

Liability questions

Before launch, the ecosystem has to decide:

1. Who is liable if the agent misunderstands the instruction?
2. Who is liable if product data is stale or incomplete?
3. What if the assistant ranks a commercial partner above a better offer?
4. What if malware alters the context before the mandate is signed?
5. What if the mandate is valid but the interface hid a condition?
6. What if the bank executes outside the mandate?
7. Which party handles the complaint and any provisional relief?
8. Can the client reconstruct the recommendation and the approval later?

In Naledi's test case, the answer to the first question was not obvious. Tally Labs' assistant made the judgement. Kestrel executed exactly what was approved. Had it been live, Naledi would have approved it too. A contract between the bank and the agent operator can allocate some of this, but contract terms cannot replace fair outcomes for consumers or the law that applies to the product. Kestrel's conduct and legal teams treated these eight questions as a launch gate, not a footnote.

The mandate evidence pack

The answer to question 8 depends on what was kept. Subject to privacy and legal requirements, Kestrel's design retains:

• the client and agent identities;
• the mandate content and signature;
• specification and policy versions;
• product information and its timestamp;
• the options considered and the ranking criteria;
• the material disclosures shown;
• the exact approval interaction;
• the bank's authorisation decision;
• the fraud and risk outcome;
• the transaction and settlement record;
• any later correction or dispute.

As a structured record, with references in place of sensitive payloads:

agent_transaction:
  customer_reference: "kestrel-customer-ref"
  assistant_operator: "Tally Labs"
  agent_workload_id: "tally-labs-workload-ref"
  bank_reference: "kestrel-gateway-ref"
  task_id: "monthly-sweep-test-ref"
  consent_reference: "signed-consent-ref"
  mandate_reference: "human-present-approval-ref"
  requested_capability: prepare_own_account_transfer
  product_or_account_scope: ["account-token-1"]
  recommendation_evidence: ["balance-snapshot-ref", "spend-summary-ref"]
  disclosures_presented: ["amount", "accounts", "settlement-timing"]
  human_present: true
  approval_timestamp: "2026-09-28T18:42:10+02:00"
  policy_decision: challenge_then_allow
  fraud_decision: low_risk
  transaction_reference: "kestrel-txn-ref"
  settlement_status: settled
  protocol_versions: {}
  dispute_reference: null

This record made Naledi's test case reconstructible. The recommendation_evidence showed a balance snapshot and a spending summary, and nothing about scheduled debit orders. The missing input was visible in the evidence, not inferred after an argument. That is the difference an evidence layer makes, and why the agent spent the money: prove why treats it as part of the product, not an audit afterthought.

The mandate should prove what was authorised. The evidence pack must help explain how that authorised action was reached.

The short version

Authority is not judgement. A valid signature proves approval, not that the approval was well informed.

Evidence every link. Goal, interpretation, options, recommendation, approval, authorisation, execution and dispute each need their own record.

Put the bank's facts on the approval screen. Kestrel shows upcoming debit orders from its own records at the moment of confirmation.

Delegate narrowly first. Small, repeatable, reversible cases with explicit limits; keep new beneficiaries and credit human-present.

Settle liability before launch. Eight questions, answered in contracts and in fair client outcomes.

Keep the evidence pack. It turns a dispute into a lookup.

Previous: Part 3, one agent, five banks, one permission problem. Next: Part 5, the bank competes product by product. All parts are on the series page.

How CloudNala can help

We help banks and payment providers design for the gap between authority and judgement: mapping the intent chain for agent-initiated transactions, designing approval screens that surface the bank's own facts, writing narrow delegated-authority rules, structuring the liability questions for legal and conduct teams, and building the evidence pack that lets an operations team reconstruct any disputed agent transaction.

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