Part 4 of 8 of Building the Bank from the Top Down. The main paper makes the argument; this part holds the detail.
C1. The response: one platform, two products
The bypass is real but bounded. The response is one AI-native banking platform with two products. Market A is the customer's interface: the bank offers its own agent, starting with the PFA. Market B is the trust layer beneath every agent: identity, verified claims, consent, delegation and liability. A bank should play both. Market B pays off even if market A is lost, so the strategy does not depend on predicting which AI interface wins.
C1.1 Two markets
Figure: Exhibit 3, Section 3.1.
| Market A: the bank's own agent | Market B: trusted infrastructure for any agent | |
|---|---|---|
| What the bank offers | Advice and action through its own interface | Identity, verified claims, delegation checks and liability |
| Who the customer talks to | The bank's agent | Any agent: the bank's, a general assistant or a fintech |
| Depends on | Winning the interface | Being the trusted source behind the interface |
| Worked in this paper | The PFA (Appendix C3) | Verified financial claims (C1.5); several product North Stars (C4) |
| Main risk | Customers prefer general-purpose assistants | Claims become a standard anyone can issue |
C1.2 Why trust may become the scarce good
- The information age made content abundant. Publishing became nearly free, so information lost value while verified relevance and trusted provenance gained it. A false claim takes seconds to produce; a credible rebuttal takes days.
- The AI age makes cognition abundant. South Korea will give every resident general-purpose AI free of charge and without usage limits, with a beta from October 2026 and full launch in December 2026 (Korea Times). When answers cost nothing, the question becomes which answer a person can safely act on (hypothesis).
- The old filters are weakened. Editors, professional bodies, universities and banks once decided what could be relied on. Digital channels bypassed them without building trusted replacements. That gap is the opportunity for new filters, and banks already run one at scale.
C1.3 The trust stack
Institutional trust gives banks a head start, not a guarantee. Trusting a bank with money is not the same as trusting its AI to interpret, advise or act. The stack below separates what banks already hold from what they must earn.
The ten layers answer three different questions, and a bank starts in a different place on each:
- Trustworthiness: is the system actually reliable?
- Assurance: can the customer, or a relying party, verify that it is?
- Liability: who bears the loss if it is not?
| Question | Layer | The question asked | What the bank already runs | Starting position |
|---|---|---|---|---|
| Trustworthiness | Model reliability | Is the AI's answer right? | Model risk management and validation | To be earned: no track record yet |
| Trustworthiness | Decision | Should I follow its advice? | Advice and suitability processes | To be earned; advice rules apply |
| Trustworthiness | Execution | Will it act only as I authorised? | Mandates and payment controls | Strong for payments; untested for agents |
| Assurance | Identity | Who is this person, firm or agent? | KYC, strong customer authentication | Head start for people; to be earned for agents |
| Assurance | Data and provenance | Where did this data come from, and is it used only as agreed? | Books of record, security, GDPR controls | Moderate: few data-sharing products yet |
| Assurance | Authenticity | Has it been altered or faked? | Fraud detection on payments, voice and documents | Head start |
| Assurance | Compliance | Does it meet the rules? | AML, sanctions, conduct and AI Act controls | Head start |
| Assurance | Reputation | Should I trust this actor over time? | Credit history, counterparty risk | Head start |
| Liability | Institutional | Will my money be safe? | Licence, deposit protection, supervision | Head start |
| Liability | Liability | Who pays if it goes wrong? | Audit trails, reimbursement and dispute regimes | Head start |
Banks start ahead on assurance and liability, which is what market B sells: verified facts, and a party that pays if they are wrong. They start behind on trustworthiness for AI, which is what the bank's own agent must prove, release by release.
C1.4 The bank account becomes a filter
Legacy products will not disappear; they are likely to become regulated, trusted primitives inside larger AI-run services. The bank account becomes the financial primitive the customer's agent uses. What customers will value is the filter around it:
- Delegation control. What may the agent do, up to what amount, with which counterparties? When must a human approve, and can the action be reversed?
- Verified claims instead of raw data. Proof of a fact, issued for one purpose, rather than a full statement history (C1.5).
- Liability-backed trust. "We verified this, and if we were wrong, we compensate you." Banks already make this promise for unauthorised payments, and the PSR extends reimbursement to certain impersonation frauds.
The bank's promise becomes: we protect your money, recognise authorised instructions, detect manipulation, and resolve disputes when your AI agent makes a mistake. That is a trust product, not a payment product.
Three design rules keep the filter credible. Trust must be contextual and contestable, never a single universal score. Friction should appear only where the risk justifies it. Open standards and appeal routes stop the filter from becoming a gatekeeper that customers and regulators resent.
C1.5 Verified financial claims: from data holder to fact issuer
Map 1 (Exhibit 2) placed assurance and trust at Genesis in the AI wave: it is the one uncharted capability where banks start ahead. Verified claims turn that head start into a product. A bank issues signed, purpose-bound, revocable claims to any agent the customer authorises, without exposing raw transaction history. The bank's role shifts from holder of financial data to issuer of trusted financial facts, which makes this a new infrastructure product rather than an AI feature. That this is the bank's lasting edge is the paper's central hypothesis (Appendix D4, claim 14). Even when another agent owns the interface, the bank that issues the claims stays in the path of every action. Outside agents must also be able to verify and complete tasks through the bank, or it becomes invisible to them (The Answer Layer).
| Claim | Typical use |
|---|---|
| Verified identity and age | Onboarding, age-restricted services |
| Verified account ownership | Payouts, direct debits, marketplace onboarding |
| Verified income and recurring income | Rental applications, affordability checks |
| Verified affordability | Credit and mortgage pre-qualification by other lenders |
| Verified balance range | Deposits, travel and visa applications |
| Verified payment authority | Confirming an agent may pay up to a limit |
| Verified business turnover | SME lending, supplier onboarding |
Each claim uses what the bank already has (KYC, books of record, fraud controls) and sells it as reduced uncertainty to the party relying on it. For the bank's own agent, the same machinery becomes a claim-and-evidence graph behind every answer: which claims support a decision, how reliable they are, what contradicts them, and who is accountable.
Infrastructure, not a feature. Claims are a lasting edge only if other parties come to depend on them. If any licensed party can issue them on equal terms, or regulation turns them into a mandated utility, market B commoditises too (Appendix C6). Four conditions guard against that:
- Shape the schema and the revocation protocol. Help set the claim formats and how a claim is withdrawn, inside open standards such as the EU Digital Identity Wallet's attestations, rather than waiting to implement someone else's.
- Make verification effortless. Any agent can check a claim by machine, in one call, without a bilateral contract.
- Price the liability. The bank pays if a claim is wrong, and prices that promise per claim, like insurance.
- Sit in the high-value path. Mortgages, credit and large payments should run through the bank's claim service, so an outside agent cannot complete them without it.
The edge is being the most reliable issuer that pays if it is wrong, not owning a proprietary format; a closed format would work against the open-standards rule in C1.4 (interpretation). The test is whether outside agents call the bank's claim service in high-value journeys (Appendix D4, claim 19).
C1.6 One journey end to end: mortgage affordability
The customer from Appendix C3.1 earns €3,420 a month net and asks their agent: "Can I afford this flat?" The lender never sees 12 months of transactions. It sees one signed fact, used for one purpose, and every step leaves evidence. Figures are illustrative.
| Step | What happens | Who acts | Control |
|---|---|---|---|
| 1. Goal | The customer states the goal to an agent: the bank's own or an outside one | Customer, agent | Agent restates the goal and confirms it before acting |
| 2. Consent | The customer approves one request: income and commitments, for mortgage affordability, valid 30 days | Customer | Purpose-bound consent router; the PSR permission dashboard shows it |
| 3. Legacy data | The bank reads salary credits and loan repayments from its core and card systems, read-only | Bank | Semantic control plane nets reversals and own-account transfers (Technical annex, T6) |
| 4. Claim issued | "Net income above €3,000 a month, recurring for 12 months" is signed, limited to this purpose, dated and revocable | Bank | Provenance record behind the claim |
| 5. Claim checked | The lender, the bank itself or another, verifies the signature and the purpose | Lender | No raw history shared; claim refused outside its purpose |
| 6. Affordability | The lender runs its own affordability model | Lender | AI credit scoring is high-risk under the AI Act: human oversight and logging |
| 7. Explanation | The agent explains the result and the claims it rests on | Agent | Maths verifier on every number; evidence attached |
| 8. Recommendation | "This loan is affordable; borrowing 10% less keeps your €4,000 buffer intact" | Agent | Advice and credit rules; autonomy rung 3 (recommend) |
| 9. Approval | The agent prepares the application; the customer confirms with strong authentication | Customer | Rungs 4 and 5 (prepare, ask approval) |
| 10. Execution | The application goes to the lender, which decides | Lender | Lender's licence and credit policy |
| 11. Audit | One log links goal, consent, claim, decision and approval | Bank and lender | Append-only audit trail (Technical annex, T1) |
The bank earns in both markets. If its own agent runs the journey, it holds the relationship (market A). If an outside agent runs it, that agent still needs the bank's signed claim at step 4 (market B).
C2. Setting the North Star: the method
The platform needs a direction: which outcomes to build first, and what to stop funding. A North Star is a customer outcome that AI makes possible, stated plainly enough to veto a programme. Without one, every modernisation project looks necessary; with one, most of them have to justify themselves against it.
C2.1 Five steps
-
Write the outcome in the customer's words. Test it: would a customer notice the day it came true? Examples:
- "Every customer has a trusted agent that runs their financial life, across every provider."
- "Every household knows, every day, whether it is on track for its goals."
- "No small-business owner spends more than an hour a month on financial admin."
- Map the value chain beneath it. List the components the outcome needs, from what the customer sees down to what they never see, as Map 2 does for the PFA in Appendix C3.4.
- Place each component on the evolution axis. Decide for each: build and own, buy or partner, rent, or contain.
- Re-sort the change portfolio. Give every running programme one label (table below). Shrink or stop anything labelled legacy drag.
- Fund in quarterly releases. Measure each release by what customers can do that they could not before, not by foundations laid.
C2.2 The portfolio test
| Label | Test | Funding rule |
|---|---|---|
| Apex | Builds an uncharted component the North Star needs | Fund first; small teams, quarterly releases |
| Enabler | Modernisation that a named apex component depends on | Fund, scoped to that dependency only |
| Mandatory | Required by DORA, AML, PSR or the AI Act | Fund; design it to serve the apex where possible |
| Economic | Core work with its own business case: cost reduction, capacity, vendor end-of-life, M&A integration | Fund on its business case; never as a gate for customer value |
| Legacy drag | None of the above: no customer outcome, legal duty or business case | Stop, shrink or fold into the above |
The author's Enterprise Digital Office framework gives the Apex label a working target: at least 40% of change spend on differentiating capabilities.
Resilience, compliance and core work with its own business case continue. What stops is modernisation for its own sake, and any programme that makes customer value wait for it.
C2.3 Bend the drift
Track two numbers every quarter at board level: the run-versus-change split of the technology budget, and the share of change spend going to apex components. The drift in Appendix A1.2 bends only when the second number rises.
Previous: Appendix B: Complication evidence · Next: Appendix C3: The Personal Finance Agent
Top comments (0)