Part 8 of 8 of Building the Bank from the Top Down. The main paper makes the argument; this part holds the detail.
This annex holds the operating detail behind Appendix B2, C3, C4.5 and C5 of the main paper. A bank-grade agent needs more than a model and a consent screen. It needs a control architecture, a rule for how much autonomy each action gets, clear liability positions, and a plan for each way it can fail. Sections are numbered T1 to T7 to keep them apart from the Appendix. T7 tests each section against the core landscapes most large groups actually run.
T1. Agent control architecture
| Layer | What it governs | PFA design choice |
|---|---|---|
| Identity | Who the person is, and which agent acts for them | Bank KYC, plus agent credentials bound to the customer |
| Authority | Who delegated what, to which agent | A delegation record per agent and per purpose |
| Policy | What the agent may do | Machine-readable policies per action type |
| Consent | Purpose, scope, duration, revocation | Purpose-bound consent router |
| Context | Customer goals and constraints | Personal context graph |
| Knowledge | Product and regulatory knowledge | Curated, versioned knowledge base |
| Retrieval | Trusted data access | Semantic control plane (T6) |
| Reasoning | Planning and decision logic | Language model plus deterministic maths verifiers |
| Verification | Independent checks on numbers and claims | Evidence graph; second-line checks for high-risk actions |
| Execution | Payments and other actions | Through bank or licensed payment-initiation rails only |
| Transaction control | Idempotency, limits, rollback | Idempotency keys, per-action limits, compensation logic |
| Audit | An immutable decision and action trail | Append-only log linking claim, evidence, approval and action |
| Monitoring | Agent behaviour over time | Error, drift and escalation dashboards; regression tests on every model update |
| Human control | Escalation and approval | Approval steps on the autonomy ladder (T2); human review queues |
| Liability | Who is accountable | Liability positions (T4) |
| Recovery | What happens when the agent fails | Read-only safe mode, reversal procedures, customer notification |
T2. The autonomy ladder
Autonomy is granted per action, not per customer. The rung an action may reach depends on four factors: risk × reversibility × value × confidence. Customer permission is necessary but not sufficient.
| Rung | The agent… | Example | Typical gate |
|---|---|---|---|
| 1. Observe | Reads and summarises | "You spent €420 on groceries this month." | Consent |
| 2. Explain | Explains, with evidence | "Your buffer fell because two annual bills landed together." | Evidence attached |
| 3. Recommend | Suggests, with alternatives | "Move €200 to savings, or wait until the 28th." | Advice rules |
| 4. Prepare | Drafts the action | A pre-filled transfer | Customer reviews |
| 5. Ask approval | Requests confirmation | "Confirm €200 to savings?" | Strong authentication |
| 6. Execute within limits | Acts under a mandate | Sweeps up to €100 a month between the customer's own accounts | Mandate, limits, reversibility |
| 7. Execute autonomously | Acts without per-action approval | Only for low-risk, reversible, high-confidence actions | Autonomy policy approved by the board |
An example policy: moving small amounts between the customer's own accounts can reach rung 6. Paying a new payee stays at rung 5 or below.
T3. Authentication and delegated payments
- Read access through an account information service needs strong authentication at least every 180 days (RTS 2022/2360).
- Payment authentication must be linked to a specific amount and payee. When a customer delegates to an agent, these are often unknown at the moment of delegation (Sopra Steria).
- Workarounds under discussion include merchant-initiated transactions, transaction risk analysis and trusted-beneficiary lists. Until the PSR technical standards settle, autonomous payment execution (rung 7) should be treated as out of scope.
T4. Liability positions to settle
These are design positions for the bank to test with its legal team and regulators, not legal advice.
| Event | Decides | Executes | Default position to test | Evidence needed |
|---|---|---|---|---|
| Wrong recommendation, customer acts on it | Customer, on agent advice | Customer | Agent provider if advice rules were breached or evidence was missing; otherwise the customer | Evidence graph of inputs and explanation |
| Wrong transaction within the mandate | Agent | Bank or payment initiator | Agent provider reimburses; bank recovers from it | Audit trail, mandate record |
| Fraudulent instruction via a manipulated agent | Attacker | Bank | Start from the existing unauthorised-payment rules | Authentication and agent input logs |
| Wrong number quoted by the model | Agent | None | Agent provider; mitigated by maths verifiers | Verifier logs |
| Bad source data | Data provider | None | Data provider for its data; agent provider if it failed to flag an inconsistency | Provenance record |
| Customer overrides a clear warning | Customer | Bank | Customer, if the warning was clear and recorded | Recorded warning and override |
| Duplicate payment | System | Bank | Operator of the failing component | Idempotency and reconciliation logs |
T5. Failure scenarios
| Scenario | Control | Owner |
|---|---|---|
| Agent misreads the customer's objective | Restate intent and confirm before acting; stay at rung 4 or below | Product |
| Two accounts show contradictory information | Flag the conflict with both sources; never resolve it silently | Semantic control plane |
| Open-banking connection is down | Fall back to last known data, time-stamped; no actions | Platform |
| Instruction is ambiguous | Ask a clarifying question; never guess on money movements | Agent policy |
| Payment executed twice | Idempotency keys, reconciliation, automatic reversal | Payments |
| Customer disputes the agent's authority | Signed delegation record and audit trail | Operations and legal |
| Model behaviour changes after an update | Regression suite, staged rollout, version pinning | Model risk |
| Agent or model provider exits | DORA exit plan; portable context and consent records | Vendor management |
| Customer asks for risky tax or credit optimisation | Refuse with an explanation; escalate to a human | Compliance |
T6. Semantic control plane
The control plane lets AI read legacy data where it sits without inventing meaning. The chain runs: raw data, semantic mapping, canonical financial concepts, evidence and provenance, verified claims, agent reasoning. Canonical rules come first for the fields where a misreading is costly:
| Field | How it misleads | Canonical rule |
|---|---|---|
| Pending versus booked items | Double counting | Keep pending separate from booked balances |
| Reversals and chargebacks | Inflated spend or income | Net against the original transaction |
| Currencies | Mixed amounts | Convert at dated rates; keep the original |
| Interest and fees | Product-specific terms | Take from product definitions, never infer |
| Transfers between own accounts | Look like income or spend | Match across the customer's accounts |
| Product definitions | Same name, different terms | A versioned product catalogue |
T7. Stress test against legacy landscapes
Most large French and Benelux groups run a mainframe ledger in at least one entity, and several vendors' cores across entities and countries. The table asks what breaks in T1 to T6 on each. It is a desk exercise, not a tested result; a bank should repeat it against its own systems before the Scale gate.
| Section | On a mainframe core (batch posting, nightly extracts) | Across a multi-vendor, multi-entity group | Design response |
|---|---|---|---|
| T1 Control architecture | No real-time hook to enforce agent limits in the core | Each entity has its own identity, KYC and entitlements | Enforce limits and policy in the control plane before any call reaches a core; one group registry for agent identity and delegation, federated to each entity's KYC |
| T1 Consent layer | Consent is not modelled in the core at all | Each entity is its own GDPR controller; rules differ by country | Consent records held per controller, each naming the entity and purpose; one permission dashboard shows them all to the customer |
| T2 Autonomy ladder | Batch posting delays reversal, so "reversible" is weaker than it looks | Product rules and limits differ by entity | Rung 6 only on rails with real-time reversal (e.g. instant payments between own accounts); ceilings set per action class at group level, tighter per entity where needed |
| T3 Authentication | SCA sits in the channel layer, not the core: little change | Different SCA solutions by country and brand | High-stakes confirmation by deep link into the entity's own app, which already holds SCA |
| T4 Liability | The audit trail spans the agent log and core batch records | Which legal entity is "the agent provider" is unclear | Reconcile agent and core records daily; name one group entity as the agent provider, with recovery agreements across entities |
| T5 Failure | Batch windows and planned outages | An outage in one entity must not stop the agent elsewhere | Time-stamped last-known data and no actions during windows; circuit breakers per entity |
| T6 Semantic control plane | Pending items live in authorisation systems, not the ledger; data arrives as extracts | Same product name, different terms across entities | Read pending items from authorisation systems; read through change-data capture or APIs with provenance rather than copying into a new warehouse; a versioned product catalogue per entity mapped to shared canonical concepts |
The pattern: controls move out of the cores into the shared control plane, and only the high-risk fields in T6 are mapped canonically. That is what stops the platform from becoming a new monolith (interpretation).
Top comments (0)