DEV Community: Lawrence

Building the Bank from the Top Down, Technical annex: Agent control, liability and failure

Lawrence — Sat, 26 Sep 2026 13:10:06 +0000

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).

Previous: Appendix D: Glossary, sources and claims register

Building the Bank from the Top Down, Appendix D: Glossary, sources and claims register

Lawrence — Sat, 26 Sep 2026 13:09:05 +0000

Part 7 of 8 of Building the Bank from the Top Down. The main paper makes the argument; this part holds the detail.

D1. Glossary

Term	Meaning
AISP / PISP	Account information and payment initiation service providers: the licensed third parties allowed to read accounts or initiate payments
Apex	The customer-facing point where intent, context and value are coordinated. Related to, but not the same as, the upper tiers of Bain's pyramid and the top of a Wardley value chain (Section 2.1; Appendix A2)
Autonomy ladder	Seven rungs from observe to execute autonomously; each action's rung depends on risk, reversibility, value and confidence (Appendix C3.3)
Baggage disintermediation	Risk scenario: an agent captures the relationship while the bank retains much of the ledger, capital and compliance cost
Claims register	Appendix D4: each load-bearing claim with its status (fact, evidence, interpretation or hypothesis), basis and test
Core-led / outcome-led	Transformation where customer value waits for core modernisation to finish, versus transformation that starts from a customer outcome and invests in the core only where a named need requires it
Cost-to-income ratio	Operating costs divided by operating income; lower is more efficient
DORA	EU Digital Operational Resilience Act, applied from 17 January 2025
FiDA	Proposed EU Financial Data Access regulation extending open banking to open finance
Kill criteria	Pilot thresholds that trigger a shift of weight from market A to market B if missed at month 9 (Appendix C3.1)
Market A / market B	The two products of one platform: A is the bank's own agent, competing for the customer's interface; B is the trust layer beneath every agent (Section 3.1; Appendix C1)
North Star	A customer outcome, enabled by AI, used to decide which programmes get funded
PFA	Personal Finance Agent: an AI agent that plans and acts on a customer's finances with their consent
PSD3 / PSR	The EU's third Payment Services Directive and the Payment Services Regulation, replacing PSD2
SCA	Strong customer authentication: two-factor authentication required for account access and payments
Semantic control plane	The controlled chain that turns raw legacy data into canonical concepts, evidence and verified claims
Technical annex (T1 to T7)	The second tab: agent control architecture, autonomy ladder, authentication, liability, failure scenarios, semantic control plane and a stress test against legacy cores
Trust layer	Identity, verified claims, consent, delegation and liability, offered to the bank's own agent and to any other agent the customer authorises
Trustworthiness / assurance / liability	The three questions trust answers: is the system reliable, can that be verified, and who pays if it is not (Appendix C1.3)
Verified financial claim	A signed, purpose-bound, revocable statement from the bank, such as "income above €3,000", issued instead of raw data

D2. Sources

Accenture, 2026 Banking Trends, via Orbograph: 70% of IT spend on maintenance; technology costs rising four times faster than revenue.
European Banking Authority, Risk Dashboard Q1 2026: cost-to-income by country; costs and income index.
Almquist, Senior and Bloch, The Elements of Value, HBR 2016.
Bain & Company, In Search of Customers Who Love Their Bank, 2018.
Simon Wardley, Wardley Maps.
Konsentus, The Unfinished Story of European Open Banking, November 2025.
Juniper Research, Open Banking API Call Volume to Surpass 720bn, February 2025.
Norton Rose Fulbright, PSD3 and PSR: from provisional agreement to 2026 readiness.
Morrison Foerster, PSD3 and the Payment Services Regulation: key developments, April 2026.
Council of the EU, FiDA non-paper, April 2026.
Regulation-AI.eu, Annex III high-risk AI, updated September 2026.
Korea Times, Can AI be a public utility? World watches Korea's bold experiment, September 2026.
KPMG Belgium, Belgian banks are most cost-effective.
Fitch Ratings, Dutch bank cost savings to narrow efficiency gap, January 2026.
Wave examples: Euromoney on Boursorama, bunq, Adyen, Finovate on Ohpen.
Author's working analysis: the FOB-analysis workbook (Wardley matrix, PFA decomposition); research notes on the modernisation trap, the five waves and outcome-led PFA architecture; and notes on information abundance, trust infrastructure and the future of legacy products (Appendix C1 and C4).
Sopra Steria, Payment Services Regulation in 2026: the state of play for banks, August 2026.
European Banking Authority, Final report on the amendment of the RTS on SCA and CSC, 2022.
W3C, Verifiable Credentials Data Model 2.0, 2025.
European Commission, European Digital Identity Wallet.

D3. Author's related work

Article	What it adds to this paper
Enterprise Digital Office (EDO), July 2025	The operating system behind the method: Wardley maps to start every initiative, backlogs tagged to Bain's value tiers, five immutable gates and spend targets (Appendix B1, C2 and C7)
The Answer Layer, September 2026	How AI answer engines form a new layer between firms and customers, and how to test whether agents can complete tasks through a firm (Appendix C1)
Bespoke Platform Engineering (BPE), July 2025	Hypergraph and ontology patterns for reading legacy data, agents as first-class clients of platform services, and inspectable audit trails (Appendix C3 and C5)

D4. Claims register

Every load-bearing claim in the paper carries one of four labels. Fact: verifiable from law or published data. Evidence: supported by published data, with limits on scope or interpretation. Interpretation: the author's reading of facts or law. Hypothesis: a claim about causes or the future that the paper cannot yet support. Each claim below names its basis and the test that would confirm or overturn it.

#	Claim	Status	Basis	Test	Where (main section; appendix)
1	Nearly 70% of bank IT spend goes to running existing systems and regulation	Evidence (global figure)	Accenture, 2026 Banking Trends	The bank's own run-versus-change split	1; A1.1
2	Banking technology costs grew about four times faster than revenue over 15 years	Evidence	Accenture	The bank's own cost and revenue series	1; A1.2
3	Cost-to-income is about 65% in France, 58% in Belgium, 53% in the Netherlands	Fact (read from a chart, approximate)	EBA Risk Dashboard Q1 2026	None needed	1; A1.3
4	The run burden limits what incumbents can redirect to new customer value	Hypothesis	Consistent with claims 1 to 3; not shown causally	Apex share of change spend over time (Appendix C2.3)	A1.1
5	PSD3 and the PSR require dedicated interfaces, list banned obstacles and introduce permission dashboards	Fact	Final texts agreed April 2026; Norton Rose Fulbright, Morrison Foerster	None needed	2.3; B2.1
6	AI Act high-risk rules apply from December 2027; PSR core obligations around H1 2028	Evidence (planning assumption)	Regulation-AI.eu; Sopra Steria	Re-check at each roadmap gate	2.4; C5.2
7	Agent-initiated payments collide with SCA, which needs a known amount and payee	Evidence	RTS on SCA; Sopra Steria	Final PSR technical standards on delegated payments	2.3; B2.2
8	In past technology waves, challengers rented the new commodity and built above it	Interpretation	Five cases in Appendix B1.4; illustrative, not proof	Not testable in advance	2.2; B1
9	An outside agent could capture the relationship while the bank keeps the cost	Hypothesis	Seven-step chain; steps 1 to 3 technically possible	Share of interactions in bank channels; third-party API calls	2.3; B2.4
10	Customers reward multi-element and upper-tier value with loyalty	Evidence (general, not AI-specific)	Bain, 2018	Retention of pilot users against a control group	1; A2.1
11	An AI agent can deliver emotional value such as reduced anxiety at scale	Hypothesis	Chain in Appendix A2.3	Perceived control and anxiety in the first release; behaviour over 6 to 12 months	2.1; A2.3
12	As AI makes answers nearly free, an answer a person can safely act on becomes scarce	Hypothesis	Reasoning in Appendix C1.2	Whether relying parties pay for verified claims	C1.2
13	Banks start ahead on assurance and liability, behind on AI trustworthiness	Interpretation	Trust stack, Appendix C1.3	Pilot trust score; model incident rate	3.1; C1.3
14	A bank's lasting edge is vouching for facts and paying if they are wrong	Hypothesis: the paper's central claim	Appendix C1.4 and C1.5	Share of relying parties accepting non-bank claims on equal terms; price per claim; claims per consented customer	3.2, 3.5; C1.5, C6
15	The consent router and permission dashboard are a likely moat	Interpretation	PSR dashboard obligation; Map 2	Share of customer consents managed through the bank	C3.4
16	Customers will choose the bank's agent over a free general assistant	Hypothesis	Six advantages, Appendix C3.1	Active and repeat use; the month-9 kill criteria against a general assistant	C3.1
17	Outcome-led delivery reaches first customer value in quarters, not years	Hypothesis (working estimate)	Dependency analysis, Appendix C3.6	Time to first customer value in the first release	3.4; C3.6
18	An agent customer can be worth more than they cost	Hypothesis (illustrative model only)	Appendix C3.7	Pilot economics against a matched control group; the Scale gate	3.4; C3.7
19	Verified claims stay an edge only if they become infrastructure outside agents must call	Hypothesis	Four conditions, Appendix C1.5	Share of outside agents' high-value journeys that call the bank's claim service; relying parties integrated	3.2; C1.5

Previous: Appendix C4–C7: Product lines, guardrails and roadmap · Next: Technical annex: Agent control, liability and failure

Building the Bank from the Top Down, Appendix C4–C7: Product lines, guardrails and roadmap

Lawrence — Sat, 26 Sep 2026 13:08:27 +0000

Part 6 of 8 of Building the Bank from the Top Down. The main paper makes the argument; this part holds the detail.

C4. Beyond the PFA: a North Star for every product line

The PFA is one worked case, not the only one. Every classic banking and insurance product was designed around what an institution could deliver at the time: a branch visit, a form, an annual statement. AI changes what can be delivered, so every product line should face the same question: what job does the customer really hire this product for, and what could AI let us promise?

C4.1 Products become primitives

Legacy products will not disappear. Their core functions persist: storing value, pooling risk, financing a home, funding retirement. But they are becoming regulated, trusted primitives inside larger AI-run services, and customers may meet them only through an agent. The real question is not whether the product survives, but who owns the promise wrapped around it.

Four questions to ask of every product:

What fundamental promise does this product make?
Which parts of its delivery are just historical administration?
Which trust guarantees must stay human and institutional?
Which customer decisions could safely be delegated to an agent?

C4.2 Retail and household products

Product today	The customer's real job	AI-unlocked North Star (to test)	The incumbent belief it challenges
Current account and payments	Pay and get paid without thinking about it	"Bills and transfers run themselves within limits I set, and my balance never surprises me."	The account is a place customers come to check
Savings	Have enough, when I need it	"Every saver has a goal-based plan that moves money to the best safe home for it, even at another provider."	We win by holding the deposit and quoting a rate
Consumer credit and overdrafts	Smooth out uneven cash flow	"No customer pays for high-cost credit or fees they could have avoided."	Penalty fees and revolving balances are a revenue line
Mortgages	Own a home, safely	"From 'can I afford it?' to an offer in days, assembled from verified claims, then re-checked for the customer every year."	A mortgage is a one-off sale followed by 25 years of silence
Property and casualty insurance	Avoid loss, and recover fast when it happens	"We help prevent, contain, document and compensate loss; most claims are settled in hours."	Insurance pays out after things go wrong
Life and protection	Know my family is covered	"Every household can see its protection gap, and cover adjusts as life changes."	Protection is sold once, at a life event, by an adviser
Pensions and retirement	Retire with enough, on time	"Every customer sees one retirement income figure across all their pensions, with a monthly nudge that keeps it on track."	A pension is a statement once a year
Wealth and investment management	Grow wealth and pass it on	"Private-banking-quality advice for the mass affluent, explained and suitable." "Every family has a plan for passing wealth to the next generation."	Personal advice only pays above a minimum portfolio

C4.3 Business and corporate products

Product today	The customer's real job	AI-unlocked North Star (to test)	The incumbent belief it challenges
SME cash management	Never run short of cash	"Every SME has a 13-week cash forecast, and financing is arranged before the gap appears."	Lending reacts to an overdraft request
SME lending	Fund growth quickly	"Credit decisions in minutes from verified turnover and invoices, with a limit that follows the business."	Lending needs annual accounts and a relationship manager
Corporate treasury and cash management	Keep liquidity, currency risk and payments within policy	"Treasury runs itself within the board's policy; people handle only the exceptions."	Treasury is a dashboard plus spreadsheets
Trade finance	Trade across borders without paper risk	"Documents are verified as claims, not checked by hand; funding is released when the evidence is complete."	Trade finance is document processing

C4.4 Reading the tables

The promise moves up the pyramid. Most North Stars shift a product from functional value (rate, fee, speed) towards emotional or life-changing value: reduces anxiety, provides hope, heirloom.
Several challenge today's revenue. Penalty fees, deposit margin and mortgage inertia all depend on customers not optimising. If the bank will not make the promise, an outside agent using open finance may make it instead.
Many are skills of one agent. Savings, credit, protection and pension goals all run on the same context graph and consent router. Build one AI-native platform, with product skills on the bank's agent (market A) and claims on the trust layer (market B), not ten separate programmes.
Some sit mainly in market B (Appendix C1). Verified turnover for SME lending and verified documents in trade finance can win even when another agent owns the interface.
Each row is a hypothesis. Test it with its own first release, using the method in Appendix C2.

C4.5 Feasibility in large groups

Large networked groups such as BNP Paribas, Crédit Agricole, BPCE, Société Générale and KBC face four technical problems that a single-entity bank meets in milder form. The strategy does not solve them; each has a design answer to test in the first release.

Problem	Why it is hard in a group	Design answer	Detail
A semantic control plane over different cores	Mainframes and several vendors' cores, each with its own data model	Map only high-risk fields; read through change-data capture or APIs with provenance; no new central warehouse	C3.3; Technical annex T6, T7
Purpose-bound consent across entities and countries	Each entity is a separate GDPR controller, and rules differ by country	Consent records per controller; one permission dashboard for the customer	Technical annex T1, T7
Agent identity and delegated authority under SCA	Payment authentication needs a known amount and payee; PSR technical standards on delegation are not final	One group registry for agent identity and delegation; confirmation by deep link into the entity's app; rung 7 out of scope for payments	C3.3; Technical annex T3
Model risk and explainability for two sets of rules	The AI Act (from December 2027, planning assumption) and supervisors' model-risk expectations both apply	Evidence behind every answer, maths verifiers and one audit trail, built on existing model risk management	C5.1; Technical annex T1, T5

A fifth problem is organisational rather than technical, and probably the hardest: protecting the outcome-led team from the core programme (C5.3).

C5. Guardrails: regulation, risk and the window

The strategy, the method and the cases all operate inside rules that are still being written. This section separates what regulation requires from what it enables and from how this paper reads it, sets out the timing window, and names the new risks.

C5.1 What regulation requires, what it enables, and how we read it

Rule	Regulation requires	Regulation enables	Interpretation
EU AI Act	AI used for creditworthiness and credit scoring is high-risk: risk management, data governance, human oversight and logging, from 2 December 2027 (planning assumption) (Regulation-AI.eu)	Reuse of existing model risk management	Explained answers and graduated autonomy double as compliance evidence
DORA	ICT third-party risk management: a register, testing and exit plans for critical providers	Governing model providers like other critical ICT vendors	Renting models is viable if exit plans exist
GDPR	Purpose limitation, data minimisation, a lawful basis	Narrow, purpose-specific data sharing	The consent router turns these principles into product features
PSR	Dedicated interfaces with performance parity, no listed obstacles, permission dashboards, payee-name verification, reimbursement for certain impersonation frauds (Morrison Foerster)	A regulated surface where customers manage who acts for them	The dashboard is a product surface; liability experience is a trust advantage

C5.2 The window: December 2027 to 2028, on current planning assumptions

On current planning assumptions, the AI Act's high-risk rules apply from December 2027 and the PSR's core obligations around H1 2028: 15 to 21 months from September 2026. Both dates can move, and some obligations depend on technical standards that are not yet final, so re-check them at each roadmap gate. A bank that ships a PFA with purpose-bound consent, explained answers and graduated autonomy by then turns compliance into the product. A bank that arrives late complies anyway, and may pay for an interface its customers use through someone else.

C5.3 New risks to manage

Outcome-led delivery does not remove risk; it moves it. Model errors, answers that cannot be explained, and liability for actions an agent takes are the risks to manage. The PFA design answers each: deterministic maths verifiers for any number the agent quotes, evidence behind every answer, and autonomy that grows only as risk, reversibility and confidence allow. The Technical annex sets out a liability matrix and failure scenarios.

The largest execution risk is probably organisational (interpretation): the core programme absorbs the outcome-led team's people, budget and release slots. Protect the team explicitly: its own budget line tied to the North Star, its own release cadence, a sponsor on the executive committee, and a rule that core-programme priorities cannot reassign its engineers. Dependencies on the core go through the semantic control plane under agreed service levels, not through the core programme's backlog.

C6. What would prove us wrong

This paper is a strategic hypothesis, not a forecast. Appendix D4 lists each load-bearing claim with its status and the test that would check it. The thesis weakens if the signals below appear, and each has a leading indicator a bank can track from its first release.

The thesis weakens if…	Leading indicator to track
Customers do not adopt financial agents	Monthly active use and repeat use among pilot customers
Customers prefer general-purpose assistants to financial ones	Share of agent traffic reaching the bank via outside assistants rather than its own; the PFA against a general assistant on the C3.1 kill criteria at month 9
Open-finance usage stays low	Consented connections per customer; third-party API calls per month
Agent liability proves too expensive	Error, dispute and reimbursement cost per thousand actions
Regulators restrict autonomous financial actions	Final PSR technical standards on authentication for delegated payments
Banks keep strong control of the interface	Share of customer interactions in bank-owned channels
AI economics do not support a mass-market agent	Cost per active user against revenue per user
AI guidance produces no measurable customer value	Buffer, debt and savings outcomes against a control group
Verified claims become a commodity anyone can issue, so a bank's liability backing earns no premium	Share of relying parties that accept non-bank claims on equal terms; price per verified claim; claims issued per consented customer

If several indicators move the wrong way, the right response is to shift weight from market A (the bank's own agent) to market B (trusted infrastructure for other agents), not to abandon the outcome-led approach.

C7. Roadmap, board resolutions and metrics

The first 90 days set how the bank competes: with its own agent at the apex, as the trusted layer beneath other agents, or both. The roadmap lands the first PFA releases, and the trust layer beneath them, as the AI Act high-risk rules (December 2027) and the PSR (around H1 2028) are expected to take effect; both dates are planning assumptions.

Roadmap · three phases and two gates · phase widths not to scale · regulatory dates are planning assumptions

The two gates condense the five gates of the author's Enterprise Digital Office framework. "North Star signed off" corresponds to its G1, where the C-suite ratifies the opportunity and success measures. "Usage and consent targets met" corresponds to G3, customer validation of the first release. A hard condition also sits between them: no release that can move money or prepare a regulated application ships until the board has approved the autonomy policy and liability matrix (C7.1).

C7.1 Board resolutions

The resolutions land in sequence over the first 90 days (the days are working targets). The North Star comes by day 45. The PFA envelope and a protected team for a 90-day read-only pilot follow by day 60, and the consent and trust layer starts in parallel. The portfolio is relabelled by day 90, aiming for at least 40% of change spend on apex components within 12 months. The Risk resolution is a gate rather than a date: it must pass before any release that can move money or prepare a regulated application. The AI Act and PSR dates are re-checked at every gate.

Decision	The board approves	Evidence required
North Star	The customer outcome	Baseline and target for the outcome metric
PFA	An investment envelope for three releases	The economics template in C3.7, filled with pilot data; kill thresholds for the month-9 decision (C3.1)
Consent and trust layer	Product strategy for the dashboard and verified claims	Regulatory and legal assessment (PSR, GDPR)
Architecture	Build, buy, rent and contain boundaries	Wardley map with evidence per component
Core	Core investment tied to named needs: resilience, regulation, economics or an outcome	Dependency map from apex components to core systems; business case for economic core work
Risk	An autonomy policy: which rungs of the ladder, for which actions, approved before any release that can move money or prepare a regulated application	Risk appetite statement; liability matrix
Data	The context and evidence model	Data architecture for the semantic control plane
AI	Model strategy and exit plans	Vendor and open-model analysis under DORA

C7.2 Measure customer outcomes, not foundations laid

Category	KPIs
Customer	Active agent users; task completion; customer effort; trust score; retention
Agent	Task success rate; error rate; escalation rate; share completed autonomously; explanation quality; numeric-hallucination rate (numbers the maths verifiers reject)
Financial	Revenue per customer; products per customer; share of wallet; servicing cost; lifetime value
Risk	Incorrect-action rate; fraud; policy violations; model incidents; liability events; consent-revocation latency; share of executed actions that are reversible; kill-switch activations
Transformation	Time to first customer value; apex share of change spend; run-versus-change split (from ~70%); legacy dependencies removed; API reuse

C7.3 The call to action

Core systems will always need investment, and regulation will make sure they get it. The question for every board in France and Benelux is what the rest of the change budget builds. If it goes mainly to rebuilding foundations, an outside agent may use open finance to reach the bank's customers on top of them. If it goes to the trust layer and an agent customers choose, the bank increases its ability to remain in the customer relationship as AI changes the interface, whichever agent the customer uses.

Previous: Appendix C3: The Personal Finance Agent · Next: Appendix D: Glossary, sources and claims register

Building the Bank from the Top Down, Appendix C3: The Personal Finance Agent

Lawrence — Sat, 26 Sep 2026 13:08:21 +0000

Part 5 of 8 of Building the Bank from the Top Down. The main paper makes the argument; this part holds the detail.

C3. Case in point: the Personal Finance Agent

Applying the method of Appendix C2 to one outcome, the Personal Finance Agent (PFA), market A's first product, makes the difference between core-led and outcome-led transformation concrete. Same bank, same ambition, same legacy estate: core-led, customers wait for the foundations; outcome-led, the first release can reach them in quarters rather than years. The principle: don't modernise the core as a prerequisite for AI; invest in it where resilience, regulation, economics or a named customer outcome requires it.

C3.1 The customer need, and why they would choose the bank

The customer's words: "Help me feel in control of my money, across every account I have, without having to manage it."

Take a salaried customer earning €3,420 a month net, building a €4,000 emergency buffer and saving for a home in 44 months. The question that matters to them is not "what is my balance?" It is: "If our household income drops 20%, what happens to the home?" Answering it well aims at the upper tiers of Bain's pyramid: reducing anxiety, providing hope, a sense of control.

Trust alone will not win this customer. A general-purpose assistant is free and already on their phone. The bank's agent has to offer things that assistant cannot easily match, and each one is a claim for the first release to test:

Advantage	What the customer gets	How the first release tests it	Kill threshold at month 9 (illustrative)
Deeper financial context	Answers built on every consented account, goal and commitment, with pending, booked and reversed items read correctly	Answer accuracy against a general assistant on the same questions	Not ahead of a free general assistant on a fixed test set of customer questions
Trusted execution	An agent that can act, within limits, not only advise	Share of recommendations the customer completes	Fewer than 1 in 5 recommendations completed
Cross-provider orchestration	One view and one plan across banks, pensions and insurers	Providers linked per active user	Median active user links no provider beyond the bank
Transparent evidence	Every number traceable to the data and claims behind it	Customer rating of explanation quality	Rated no better than the general assistant's answers
Controllable autonomy	The customer sets what the agent may do alone, and can take it back	Share of users who raise or lower autonomy	Fewer than 1 in 10 active users ever change a setting
Liability protection	The bank compensates if its agent errs within the mandate	Trust score; dispute and reimbursement rates	Trust score not above the general assistant's; disputes above the bank's card-payment rate

These are kill criteria, not reporting metrics. The clock starts with the first read-only release: review at month 6, decide at month 9. The deciding test is control and trust, the last three rows, because that is where a free general assistant is weakest. If the PFA misses those thresholds at month 9, that is the signal in Appendix C6 to shift weight and budget from market A to market B. The thresholds are illustrative; the board sets the real ones with the PFA investment envelope (Appendix C7.1).

C3.2 Core-led delivery

Few banks run this sequence in pure form; most modernise selected domains alongside digital journeys. Core-led here means the variant where customer value is gated by the sequence: stabilise the core, harmonise the data in a warehouse, build APIs, then put an agent on top.

Value arrives last. Customers see nothing until the foundation steps are done; on typical plans that is two to three years (a working estimate).
The view is narrow. The agent sees one bank's data. The customer's other banks, pensions and insurers are invisible.
Risk is concentrated. Large core refactoring brings regressions, outages and compliance breaks.
The window may close. By launch, a challenger may already hold the customer's conversation.

C3.3 Outcome-led delivery

The outcome-led programme starts from the customer outcome and works backwards. It builds three apex components first:

Personal context graph. Models the customer's goals and constraints (income, dependants, home target, buffer) rather than account tables.
Purpose-bound consent router. Turns each approval into a narrow, time-limited, revocable claim, such as "income above €3,000, for mortgage affordability only."
Semantic control plane. AI reads legacy and open-finance data where it sits, through a controlled chain: raw data, semantic mapping, canonical financial concepts, evidence and provenance, verified claims, then agent reasoning. Fields where a misreading is costly (pending items, reversals, currencies, interest, product definitions) get canonical definitions first; the rest are interpreted on demand.

Around these sits an agent control architecture: identity for people and agents, delegated authority, policy, independent verification, transaction limits and idempotency, audit, monitoring, human escalation and recovery. Autonomy climbs a seven-rung ladder. Each step is gated by risk, reversibility, value and confidence, not by customer permission alone. The Technical annex sets out the full stack, a liability matrix and failure scenarios.

The ladder becomes policy once each class of action has a ceiling. The rungs are 1 observe, 2 explain, 3 recommend, 4 prepare, 5 ask approval, 6 execute within limits and 7 execute autonomously. The ceilings below are a starting position for the board's autonomy policy, not a legal view:

Risk class	Example	Reversible?	Highest rung today
Information only	Spending summary, cash-flow forecast	No money moves	2: explain
Guidance on regulated products	Savings, credit or investment suggestion	No money moves	3: recommend, under advice rules
Transfers between the customer's own accounts	Sweep €100 to savings	Yes	6: execute within limits
Payments to known payees	Recurring utility bill	Partly	5: ask approval; 6 once PSR standards on delegated payments settle
New payees or one-off payments	First payment to a new merchant	No	5: ask approval
Mandate changes	Change a standing order or direct debit	Partly	4: prepare
Credit and investment decisions	Loan application, fund purchase	No	4: prepare; the lender or adviser decides

Rung 7 is out of scope for payments until the PSR technical standards settle (Technical annex, T3).

Full detail: Technical annex

The legacy core stays in place. Core investment continues where resilience, regulation, economics (cost, capacity, vendor end-of-life) or a named customer outcome requires it. It is no longer the gate for customer value.

Five architecture principles. Both products run on one platform, so these hold for market A and market B alike:

A control plane, not a new warehouse. Map only the high-risk fields canonically; interpret the rest on demand, with provenance (Technical annex, T6 and T7).
Consent as a product. The PSR permission dashboard is the customer's control surface for every agent, the bank's and outside ones, not a compliance screen. It is where the bank can keep the relationship even when the conversation happens elsewhere.
One agent control plane. Identity for people and agents, policy, independent verifiers, limits and idempotency, append-only audit, escalation and recovery are shared services, used by the PFA and by the claim service alike.
Conversation-first, app for confirmation. The agent lives where the customer talks: in the app, in messaging and in system assistants. High-stakes steps deep-link into the bank's app, which already holds strong authentication.
Observable and stoppable from day one. Every claim, recommendation and action is traceable, reversible where possible, and can be switched off per action class. The board sees the resulting metrics (C7.2).

Core-led versus outcome-led delivery of the PFA · timings are working estimates

C3.4 Map 2: what to build, buy, rent and contain

Placing each PFA component on a Wardley map turns the architecture into an investment decision. Placements use the test in Appendix B1.2. The bank builds what is uncharted and customer-facing, buys what is maturing, rents what is commodity, and contains the core.

Wardley Map 2 · PFA components by layer and evolution · from the FOB-analysis workbook

Component	Stage	Evidence for the placement	Action	Bain element served
Financial autonomy and confidence	Genesis	No mass-market product delivers it; no agreed measure of financial confidence	Own: this is the North Star	Provides hope, self-actualisation
Explained answers	Genesis	No standard for evidence-linked financial answers; AI Act explainability practice still forming	Build: every answer traceable to evidence, never a bare model output	Reduces anxiety, informs
Graduated autonomy	Genesis	Authentication for delegated payments is unsettled under the PSR (Appendix B2.2)	Build: clear guardrails for what the agent may do alone	Reduces effort, avoids hassles
Personal context graph	Custom	Budgeting apps and aggregators build their own; no product models household goals across providers	Build: model goals and constraints, not products	Integrates, organises
Consent router	Custom	PSR permission dashboards are required but not yet built; purpose-bound consent is not sold as a product	Build: a likely moat, because it sits where the PSR dashboard lands	Reduces risk, reduces anxiety
Revocable memory	Custom	Retrieval tooling is productised; memory the customer can edit and revoke is not	Build: the customer edits what the agent remembers	Organises
Maths verifiers, credential standards, saga orchestration	Product	Several vendors and open standards exist (W3C Verifiable Credentials, EU Digital Identity Wallet). The standard is a product; the bank's claim-issuing service (Appendix C1.5) is not	Buy or adopt standards	Quality, simplifies
LLM engine, open finance APIs, cloud	Commodity	Sold per token, per call or per hour by several interchangeable suppliers	Rent: do not train foundation models or build bespoke connectors	Connects
Core ledger	Commodity	Several vendors sell core banking; ledgering adds no difference the customer sees	Contain: invest where resilience, regulation, economics or a named outcome requires it	Reduces risk

C3.5 Side by side

	Core-led	Outcome-led
Starting point	The core system	The customer outcome
Data	Harmonise everything first, in a warehouse	Scoped data read through a semantic control plane
Scope	The bank's own accounts	Every provider the customer consents to
First customer value	Years (working estimate)	Quarters (hypothesis, see C3.6)
Where the money goes	Mostly on core and data foundations	Mostly on context, consent, control and experience
Delivery risk	High: core refactoring, regressions, outages	Contained: core largely untouched, new layer isolated
New risks to manage	Few new ones	Model errors, explainability, agent liability (Technical annex)

C3.6 Where the time goes

Outcome-led delivery does not skip controls. It takes some dependencies off the critical path, shrinks others and runs the rest in parallel. The first table answers the question a sceptical CTO will ask: which dependencies go away?

Dependency	Core-led	Outcome-led	What changes
Core replacement or refactoring	Early, before the agent	Only where a named outcome depends on it	Off the critical path
Full API modernisation	Before the agent	Only the APIs the first journeys use	Scoped
Canonical data model	Before the agent	Canonical concepts for costly fields only	Off the critical path, not eliminated
Data cleansing	Broad programme	Targeted semantic translation of the fields used	Scoped
Legacy data access	Multi-year harmonisation	Read-only connectors to two or three systems	Scoped
Consent	After the APIs	First capability, built as a product	Moves to the start
Risk controls	A later platform phase	Embedded in each capability, per release	Earlier and smaller

The second table shows the activities that remain, and which of them are still long poles.

Activity	Core-led	Outcome-led	What changes
Customer discovery	After the foundations	First, then continuous	The outcome sets the scope
Agent MVP	Last	Early and read-only (observe, explain)	Starts at the lowest-risk rung
Security assessment	Once, at the end	Per release, on a smaller surface	Scoped, not skipped
Model validation	Late	Early and continuous	Long pole: not faster, run in parallel
Legal and privacy review	Late	Early, on the consent design	Run in parallel
Operational readiness	Big-bang	Per release	Smaller increments
Production deployment	One large release	Quarterly releases	Smaller batches

The remaining long poles are model validation, security and the semantics of the fields the agent uses. That is why the first release should be read-only: it proves value without touching payment authentication. Each bank should test these timings against its own portfolio.

C3.7 The economics to prove

The paper does not claim a business case; each bank must build its own. The model below lists the drivers and the evidence each needs.

The board's test is one number: net economic value per active agent customer, per year.

\text{Net value} = \underbrace{(R + P + W + S + K)}_{\text{value}} - \underbrace{(I + E + D + G + L + H)}_{\text{cost}}

Value is retention (R), product penetration (P), deposits and share of wallet (W), servicing cost avoided (S) and risk reduction (K). Cost is inference (I), engineering and integration (E), data (D), governance and compliance (G), liability and fraud (L) and human oversight (H).

Side	Driver	Evidence the bank must supply
Value	Retention uplift among agent users	Churn of pilot users against a matched control group
Value	Product penetration: savings, lending, investment, insurance	Conversion from agent recommendations
Value	Deposits held and share of wallet	Balance movement across providers the customer links
Value	Lower servicing cost	Contact-centre and branch demand avoided
Cost	Inference and infrastructure	Cost per active user per month at pilot scale
Cost	Engineering, data and integration	Team cost of the first three releases
Cost	Model governance, validation and compliance	Validation effort per model change
Cost	Liability, fraud and human oversight	Error, dispute and escalation rates in the pilot

An illustrative example. Every number below is an assumption chosen to show how the model works. None is an estimate for any bank.

Side	Driver	Illustrative assumption	€ per active user per year
Value	Retention (R)	Churn falls from 8% to 6% on €900 annual revenue per customer	18
Value	Product penetration (P)	5% of users add one product earning €400 a year	20
Value	Deposits and share of wallet (W)	€1,000 more average balance at a 1.5% net margin	15
Value	Servicing cost avoided (S)	Two fewer contacts a year at €4 each	8
Value	Risk reduction (K)	Fewer arrears as buffers grow	4
Value	Total value		65
Cost	Inference (I)	€0.50 per user per month	6
Cost	Engineering and integration (E)	Three releases, amortised over the user base	12
Cost	Data (D)	Semantic control plane and data feeds	3
Cost	Governance and compliance (G)	Model validation, AI Act and advice controls	6
Cost	Liability and fraud (L)	Errors, disputes and reimbursements	3
Cost	Human oversight (H)	One escalation a year at €5	5
Cost	Total cost		35
Net	Net value per active user		30

On these inputs the case survives a halving of the retention and penetration effects (net value €11). It fails if that happens and engineering cost also doubles (net value −€1). So the pilot must measure retention and product take-up first; they carry most of the value.

The first release is designed to produce these numbers. The Scale gate in Appendix C7 should depend on them.

Previous: Appendix C1–C2: One platform, two products, and the method · Next: Appendix C4–C7: Product lines, guardrails and roadmap

Building the Bank from the Top Down, Appendix C1–C2: One platform, two products, and the method

Lawrence — Sat, 26 Sep 2026 13:07:42 +0000

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

Building the Bank from the Top Down, Appendix B: Complication evidence

Lawrence — Sat, 26 Sep 2026 13:07:35 +0000

Part 3 of 8 of Building the Bank from the Top Down. The main paper makes the argument; this part holds the detail.

B1. A recurring pattern: efficiency pushes value upward

Several technology waves since 1980 show a recurring pattern: once a capability becomes a commodity, new value appears above it, and the firm that rents the commodity often captures that value. Simon Wardley describes this as higher-order systems creating new sources of value (Wardley Maps).

B1.1 How to read a Wardley map

Vertical axis: the value chain. What the customer sees sits at the top; what they never see sits at the bottom.
Horizontal axis: evolution. Every component moves left to right over time, from Genesis (new, uncertain) to Custom, Product and finally Commodity (standard, cheap, rented).
The strategic rule. Build and own on the left, where advantage is still possible. Buy or rent on the right, where it no longer is. The author's Enterprise Digital Office framework makes this map the first step of every initiative.

B1.2 Wardley notation and the placement test

Stage	Meaning	Test for placing a capability here	Default action
Genesis	New, uncertain, poorly understood; high potential	No market standard, few live examples, and the bank cannot reliably buy the outcome today	Build and own; experiment
Custom	Built bespoke by a few; practices still forming	Several firms have built it, but each built its own; no product delivers it end to end	Build where it differentiates
Product	Available from several vendors; features compared	At least three vendors or an open standard offer it; buyers compare features	Buy or partner
Commodity	Standard, cheap, expected; differences no longer matter	Interchangeable suppliers sell it per unit; buyers choose on price and switching is cheap	Rent as a utility

Both maps in this paper use a grid form of Wardley mapping: rows are capability layers ordered by visibility to the customer, columns are evolution stages.

B1.3 Map 1: nine capabilities across five waves

The map places nine banking capabilities by where each wave left them. The placements are the author's classification, made with the test in Appendix B1.2, and the table below gives the evidence and uncertainty behind each. In this reading, AI does something the earlier waves did not: it reopens most capabilities on the left, while infrastructure stays a commodity.

Map: Exhibit 2, Section 2.2.

Between five and seven of the nine capabilities reopen as uncharted ground, depending on how fast coordination and interaction productise. Nobody owns that ground yet, and the customer relationship is likely to be decided there.

Capability	AI-wave position	Evidence for the placement	Uncertainty	Implication
User outcome	Genesis	Few live outcome-based financial agents; no settled design	High: general-purpose assistants could productise it fast	Explore with small, measured bets
Assurance / trust	Genesis	Provenance, evaluation and machine-mediated trust practices are still forming	High	Build: banks hold adjacent capability
Identity / authority	Custom	Human identity (eID, KYC) is productised; agent identity and delegated authority are not	Medium to high	Build delegation; adopt identity standards
Execution	Custom	Tool-using agents exist, but agent-initiated payments collide with SCA rules (Appendix B2.2)	High	Build with graduated autonomy
Records / memory	Custom	Retrieval tooling is productised; revocable financial memory is not	Medium	Build the financial layer, buy the tooling
Coordination	Custom	Agent orchestration frameworks are multiplying	Medium: likely to productise soon	Buy frameworks, own the policies
Interaction	Custom	Conversational interfaces are productising quickly	Medium to low	Buy; differentiate on content
Decision / interpretation	Product	General-purpose models and copilots are widely sold	Low	Rent
Infrastructure	Commodity	Model APIs and inference are sold as utilities	Low	Rent

B1.4 Five waves in France and Benelux

Each wave produced local challengers that rented the new commodity and took a slice of the incumbents' business. The cases are not symmetrical: bunq is a licensed bank, Adyen a payments platform, Ohpen a software vendor, and Boursorama's growth had many causes beyond the web. They illustrate the pattern; they do not prove the AI wave will follow it.

Wave	What became a commodity	Local challenger	What incumbents lost
ICT (1980–1995)	Electronic ledgers and clearing	None: banks built the rails (Bancontact, PIN, Cartes Bancaires)	Nothing yet, but the custom cores built then are today's legacy
Web (1995–2005)	Information distribution	Boursorama (FR), ING Direct, BinckBank (NL)	Brokerage fees and savings deposits
Mobile (2007–2015)	Always-on connectivity and app stores	bunq (NL), Nickel (FR), Lydia (FR)	Onboarding, peer-to-peer payments, daily visibility
Cloud (2012–2022)	Compute, storage, managed services	Adyen (NL), Ohpen (NL)	Merchant acquiring volume; core processing
AI (2024–)	Reasoning, language, code	AI agents over open finance	The customer relationship itself

B1.5 The lesson for boards

In these cases, incumbents kept investing in the layer that had just become a commodity, while challengers rented it and built above it. Wardley calls this inertia: past success makes the old investment feel like the moat.

Interpretation: the 70% maintenance share and the drift in Appendix A1 are consistent with that inertia. If the pattern holds in the AI wave, the stakes are higher: what is at risk is not a product line but the relationship.

B2. The bypass: how AI-native challengers reach customers without a core

Open finance lets a licensed challenger read a customer's accounts and initiate payments without owning a ledger, a legacy core or a branch. It needs a licence, the customer's consent and strong authentication. Within those limits, EU law is strengthening the right of access, and the limits themselves shape what an agent can do.

B2.1 The rails are being hardened

PSD2 opened the door. By September 2025 there were 537 authorised third-party providers across the EEA and UK, and about 60% operated beyond their home market (Konsentus).
The PSR reduces the friction. Regulation requires: dedicated interfaces with performance parity, a list of obstacles banks may not impose, and customer permission dashboards (Norton Rose Fulbright). General application is expected around H1 2028, a planning assumption to verify against the final text (Sopra Steria).
FiDA would widen the scope. The Financial Data Access regulation would extend access from payment accounts to savings, investments, pensions and insurance. It was still in trilogue in April 2026 (Council of the EU).
Traffic is compounding. Juniper Research forecasts global open-banking API calls rising from 137 billion in 2025 to 720 billion in 2029, and names generative-AI personalisation as the strategy that works in Europe (Juniper Research).

There is no EU requirement to report API calls, transactions or active users (Konsentus). Each bank sees only its own slice of third-party traffic, so none of them can see how much of its customer base is already being served through someone else's interface.

B2.2 What an agent can legally and technically do

Read access is broad; the right to act is narrow. The table sets out today's position for an outside agent working through open banking. The Technical annex holds the detailed version.

Capability	Consent needed	Regulatory status needed	Bank dependency	Realistic autonomy today
Read balances and transactions	Customer consent to an account information service	AISP registration	Dedicated API; strong authentication at least every 180 days (RTS 2022/2360)	High: read-only
Categorise and forecast cash flow	Covered by the account-information consent; GDPR purpose limits apply	AISP	Quality of the data feed	High
Recommend an action	Customer engagement	Depends on the product: investment advice and consumer credit carry their own rules	Data only	Medium: suggestions with explanations
Initiate a payment the customer confirms	Explicit consent per payment	PISP authorisation	API; strong authentication linked to amount and payee	Medium: agent prepares, customer authenticates
Execute payments autonomously	A standing mandate	PISP; authentication must be linked to a known amount and payee, which an agent often lacks. Workarounds are under discussion (Sopra Steria)	High	Low today
Apply for credit	Explicit consent; creditworthiness assessment	Lender's licence; AI credit scoring is high-risk under the AI Act from December 2027 (planning assumption)	Full	Low: agent prepares, lender decides
Change standing orders or mandates	Explicit consent	Usually requires authentication at the bank	High: few open APIs	Low

Today the disintermediation risk is mainly about who holds the customer's attention, intent and advice. The risk to execution grows as rules on delegated and recurring payments settle.

B2.3 What the challenger builds

The challenger does not build a bank. It builds one layer: an agent that understands the customer's goals, holds their consent, and reads and acts across every provider within the limits above.

B2.4 Baggage disintermediation: a hypothesis

The risk scenario: the agent could capture the relationship while the bank retains much of the underlying cost and regulatory burden (the ledger, the capital, the AML obligation and the DORA bill).

Risk scenario · an agent above several banks via open finance

Getting there takes a chain of steps, and each is an assumption to test:

An agent becomes the customer's primary financial interface.
It captures the customer's intent: what they want to achieve.
It aggregates context across providers.
It initiates decisions and actions.
The customer interacts with the agent more than with any bank.
The bank's own interface loses importance.
Margin migrates to whoever holds the relationship.

Steps 1 to 3 are technically possible today. Steps 4 to 7 depend on customer adoption and on the authentication rules above. Appendix C6 lists the indicators to watch.

Interpretation: the PSR's permission dashboard is a legal obligation, but it is also the surface where customers see and control who acts for them. A bank that builds it as a product, rather than a compliance form, has a chance to win the relationship there.

Part C sets out the response: one platform with two products.

Previous: Appendix A: Situation evidence · Next: Appendix C1–C2: One platform, two products, and the method

Building the Bank from the Top Down, Appendix A: Situation evidence

Lawrence — Sat, 26 Sep 2026 13:06:56 +0000

Part 2 of 8 of Building the Bank from the Top Down. The main paper makes the argument; this part holds the detail.

A1. The modernisation trap

Banks in France and Benelux do not lack technology spend. They lack spend a customer can see: most of the budget keeps existing systems running.

This is not an argument against core modernisation. Sophisticated programmes already modernise selected domains while building digital journeys and AI in parallel. The trap is narrower: making customer value depend on finishing the core programme.

A1.1 Run versus change

Nearly 70% of bank IT spending goes to maintaining existing systems and meeting regulatory demands (Accenture, 2026 Banking Trends). Less than a third is left for anything a customer would notice.

Three different costs are easy to blur, so this paper keeps them apart: IT run spend (the 70%), regulatory spend (part of that 70%) and total bank operating cost (the cost-to-income ratio in A1.3). The 70% is a global figure; no national split for France or Benelux is published.

Evidence: bank IT carries a large run and maintenance burden.
Hypothesis: that burden limits how much incumbents can redirect towards new customer value. The drift below supports it; a bank's own run-versus-change split is the test.

A1.2 The drift: costs outrun revenue

Over the past 15 years, banking technology costs rose about four times faster than banking revenue, and software costs have grown about 8% a year since 2017 (Accenture). If the trend holds, each euro of maintenance buys less than the one before.

Boards have not felt the drift because interest rates masked it. Across EU banks, income rose about 40% from 2021 as rates climbed, while costs rose about 22%.

EBA Risk Dashboard Q1 2026, p.13 · values read from the chart, approximate

The ECB started cutting rates in June 2024. The income line is flattening; the cost line is not. As the rate windfall fades, the drift is likely to show in the cost-to-income ratio.

A1.3 Where France and Benelux stand

France has the third-highest cost-to-income ratio of 30 EU/EEA countries, at about 65%. Belgium is about 58%. The Netherlands sits at the EU average of 53%. Nordic banks run at 39% to 48%.

Chart: Exhibit 1, Section 1.

Cost-to-income shows efficiency pressure; it does not by itself show that legacy IT causes it. Staff, branches, AML and the rate cycle all contribute. The claim here is narrower (interpretation): where the ratio is high, there is less room to fund the apex, so every euro of change spend has to be chosen more carefully.

A1.4 Regulation adds to the run burden

DORA, applied since 17 January 2025, requires ICT risk management, incident reporting, resilience testing and oversight of third-party providers.
PSD3 and the PSR were agreed in final form in April 2026. The PSR is expected to enter into force in H2 2026 and to apply generally around H1 2028 (a planning assumption to verify against the final text and technical standards), including stricter open-banking API performance and customer permission dashboards (Sopra Steria).
Anti-money laundering keeps rising: the new EU authority (AMLA) takes on direct supervision of the largest risk-exposed entities from 2028.

None of this is optional, and most of it lands on the same legacy cores. Much of the change budget goes to compliance before strategy is funded.

A1.5 Why each market is exposed

Market	Cost-to-income (Mar 2026)	Structural feature	Exposure
France	~65%	Large networked groups (BNP Paribas, Crédit Agricole, BPCE, Société Générale); long fixed-rate mortgage books; dense branch and staff costs	Most exposed: the least free capital for new customer value.
Belgium	~58%	Concentrated market (BNP Paribas Fortis, KBC, Belfius, ING Belgium); among the cheapest banking packages in Europe (KPMG)	Price squeeze. Fees cannot rise to fund modernisation without losing customers.
Netherlands	~53%	Smallest branch footprint in Europe, very high mobile adoption, heavy AML spend (ING, Rabobank, ABN AMRO) (Fitch)	Easiest to wrap: clean digital channels are what an outside agent needs.

Where to pilot (interpretation). The features that expose the Netherlands also make it the best test-bed. Clean digital channels and very high mobile adoption are what an outside agent needs to wrap a bank, and what an incumbent needs to ship a good PFA quickly. Belgium is a strong second, since the fee squeeze makes the agent's retention value matter most. France is the hardest place to start, with the highest cost-to-income and the most complex group structures (Appendix C4.5). A single-country bank starts where it is, with the same kill criteria (C3.1). A group present in several of these markets should pilot in the Netherlands or a progressive Belgian franchise, then industrialise the platform for its French entities.

A2. The apex: Bain's Elements of Value

The upper tiers of Bain's Elements of Value pyramid are where customer relationships become hard to replace. AI may be the first technology that lets a bank deliver those tiers to every customer, not just private-banking clients.

What "apex" means here. The apex is the customer-facing point where intent, context and value are coordinated: where a customer says what they want, and someone decides how to deliver it. Two frameworks describe it from different sides. On Bain's pyramid it is the upper tiers of value; on a Wardley map (Appendix B1) it is the top of the value chain, the part the customer sees. They coincide when the interface that holds the customer's intent also delivers upper-tier value, but they need not.

Bain sorts what customers value into 30 elements across four tiers: functional, emotional, life changing and social impact (Almquist, Senior and Bloch, HBR 2016). The higher the tier, the harder the relationship is to replace.

Bain Elements of Value, B2C pyramid · selected elements per tier

A2.1 Why the tiers matter for banks

More elements, more loyalty. Companies that score well on four or more elements have more than twice the Net Promoter Score of those strong on just one, and more than five times that of those strong on none (Bain, 2018).
Banking customers already reward the upper tiers. The five elements with the most impact on a bank's NPS are quality, saves time, reduces anxiety, simplifies and heirloom (Bain, 2018). Two of the five sit above the functional tier.

A2.2 Where banks compete today

Most bank change-the-bank programmes target functional value: faster payments, lower fees, fewer clicks, better uptime. These are now table stakes. Instant payments, open-banking APIs and cloud make them cheap for anyone to copy.

A2.3 What AI makes deliverable

Emotional and life-changing value used to need a human adviser who knew the customer's whole situation. That is why only wealthy clients got it. An AI agent with consented access to a customer's full financial picture could offer it to everyone, at close to zero marginal cost:

Reduces anxiety: "Yes, you can afford this, and here is why."
Provides hope: "At this rate you can buy a home in 44 months."
Self-actualisation: the customer feels in control of their financial life.

Calculating "44 months" does not by itself provide hope. Reducing anxiety depends on accuracy, explanation, appropriate uncertainty, the customer's financial literacy and whether their behaviour changes. So the paper treats this as a chain to test, not a given:

Link in the chain	Status
AI can build a personalised picture of a customer's finances	Evidence: technically feasible over consented data today
That picture improves decision support	Evidence: the advice-quality literature, plus the bank's own pilots
Better support raises perceived control and lowers anxiety	Hypothesis: measure in the first release
Lower anxiety changes behaviour (saving, debt, buffers)	Hypothesis: measure over 6 to 12 months
Changed behaviour raises retention and share of wallet	Evidence for multi-element value in general (Bain, 2018); unproven for AI agents

Hypothesis: the provider that reliably delivers the upper tiers is best placed to hold the relationship, and a provider that delivers only functional value risks becoming a supplier. Appendix C6 names the signals that would disprove it.

Previous: Main paper · Next: Appendix B: Complication evidence

Building the Bank from the Top Down

Lawrence — Sat, 26 Sep 2026 13:06:49 +0000

How banks in France and Benelux can stay in the customer relationship as AI agents compete for the interface

Executive summary

Myth: to compete in the AI era, a bank must first modernise its core, then put AI on top.

Reality: AI moves value to whoever holds the customer's intent and can be trusted to act on it. A bank that builds down from the customer outcome can hold that position in two ways: through its own agent, and as the trust layer other agents rely on.

Situation. Banks in France and Benelux spend most of their technology budget standing still. Nearly 70% of bank IT spend runs existing systems, and France's cost-to-income ratio is the third-highest in the EU/EEA.

Complication. AI agents can now deliver the advice and sense of control once reserved for private banking. Open finance lets them reach a bank's customers without owning a core. On current planning assumptions, the rules that shape this market take effect in 15 to 21 months.

Resolution. Build one AI-native platform with two products: the bank's own agent (market A) and a trust layer beneath every agent (market B), built around verified financial claims. Market B pays off whichever agent the customer chooses.

The board's first 90 days:

Approve an AI North Star within 30 to 45 days: a customer outcome, not a system.
Launch a 90-day, read-only PFA pilot with a protected team and explicit kill criteria.
Start the trust layer in parallel, as infrastructure: the permission dashboard and verified claims.
Relabel the change portfolio and target at least 40% of change spend on the apex within 12 months. Keep funding the core where a named need requires it.
Approve an autonomy and liability policy before any release can move money.

This is a strategic hypothesis, not a forecast. Section 3.5 names the signals that would disprove it.

1. Situation: banks spend to stand still

Banks in France and Benelux do not lack technology spend. They lack spend a customer can see.

Nearly 70% of bank IT spending goes to running existing systems and meeting regulation (evidence; a global figure from Accenture). Banking technology costs have grown about four times faster than revenue over 15 years. Rising rates hid this drift: EU bank income rose about 40% from 2021, costs about 22%. As rates fall, the drift is likely to show in the cost-to-income ratio (interpretation).

France already has the third-highest ratio of 30 EU/EEA countries, at about 65%. Belgium is at about 58% and the Netherlands at 53%, against 39% to 48% for Nordic banks. Staff, branches and AML all contribute to the ratio. The narrower point is that where it is high, there is less room to fund anything new.

Exhibit 1. Cost-to-income ratio by country, March 2026

EBA Risk Dashboard Q1 2026, p.13 · country weighted averages read from the chart, approximate

Regulation adds to the run burden. DORA has applied since January 2025, PSD3 and the PSR were agreed in April 2026, and the new EU anti-money-laundering authority starts direct supervision in 2028. Most of it lands on the same legacy cores.

What the rest of the change budget buys is mostly functional value: faster payments, lower fees, fewer clicks. Instant payments, open APIs and cloud make these cheap for anyone to copy. On Bain's Elements of Value pyramid, the value that makes a relationship hard to replace sits higher: reducing anxiety, providing hope, a sense of control. Two of the five elements that most drive a bank's Net Promoter Score already sit above the functional tier (evidence; Bain, 2018).

This is not an argument against modernising the core. The trap is narrower: making customer value wait for the core programme to finish.

Detail: Appendix A1 (the modernisation trap) and A2 (Bain's Elements of Value).

2. Complication: AI moves value above the bank

2.1 AI makes the apex deliverable to everyone

Emotional and life-changing value used to need a human adviser who knew the customer's whole situation, so only wealthy clients got it. An AI agent with consented access to a customer's full financial picture could offer it to everyone, at close to zero marginal cost: "Yes, you can afford this, and here is why." Whether that lowers anxiety and changes behaviour is a hypothesis to measure, not a given.

The apex is the customer-facing point where intent, context and value are coordinated. The provider that reliably delivers upper-tier value there is best placed to hold the relationship (hypothesis).

Detail: Appendix A2.3.

2.2 The pattern has happened before

Each technology wave since 1980 turned a capability into a commodity, and value moved above it. The web, mobile and cloud waves each produced local challengers that rented the new commodity: Boursorama, bunq, Adyen. Incumbents kept investing in the layer that had just become a commodity. Wardley calls this inertia, and the 70% maintenance share is consistent with it (interpretation).

In this reading, the AI wave does something the earlier waves did not: it reopens most banking capabilities as uncharted ground, while infrastructure stays a commodity. Nobody owns that ground yet.

Exhibit 2. Map 1: nine banking capabilities after each technology wave

Wardley Map 1 · position of each capability after each wave · from the FOB-analysis workbook

Detail: Appendix B1.

2.3 The bypass: agents reach customers without a core

Open finance lets a licensed third party read a customer's accounts and initiate payments without a ledger, a core or a branch. By September 2025 there were 537 authorised third-party providers across the EEA and UK. The PSR requires dedicated interfaces with performance parity, bans listed obstacles and introduces permission dashboards. FiDA would extend access to savings, pensions and insurance.

Read access is broad, but the right to act is still narrow: strong authentication needs a known amount and payee. So today the risk is mainly about who holds the customer's attention, intent and advice. The scenario to guard against is baggage disintermediation: an agent captures the relationship while the bank keeps the ledger, the capital, the AML duty and the DORA bill (hypothesis). No bank can see how far this has gone, because third-party API traffic is not reported.

Detail: Appendix B2.

2.4 The window: 15 to 21 months

On current planning assumptions, the AI Act's high-risk rules apply from December 2027 and the PSR's core obligations around H1 2028: 15 to 21 months from September 2026. A bank that ships purpose-bound consent, explained answers and graduated autonomy by then turns compliance into the product. A bank that arrives late complies anyway, and may pay for an interface its customers use through someone else. Both dates can move, so re-check them at each roadmap gate.

Detail: Appendix C5.

3. Resolution: one platform, two products

The bypass is real but bounded. The response is one AI-native banking platform with two products, built outcome-led rather than core-led.

3.1 Two markets

Market A is the customer's interface: the bank offers its own agent, starting with a Personal Finance Agent (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.

Exhibit 3. One platform, two products

One platform, two products · A: the bank's own agent · B: the trusted layer beneath every agent

Banks start ahead on what market B sells: assurance, and a party that pays if something is wrong. They start behind on the trustworthiness of their AI, which the bank's own agent must prove release by release (interpretation).

Detail: Appendix C1.1 to C1.4.

3.2 Verified claims: from data holder to fact issuer

Instead of sharing raw statements, the bank issues signed, purpose-bound, revocable facts to any agent the customer authorises: income, affordability, account ownership, payment authority. When an agent applies for a mortgage, the lender does not need 12 months of transactions. It needs one fact, "net income above €3,000 a month, recurring for 12 months", signed by a party that pays if it is wrong. Whoever runs the journey, the bank stays in the path of every action. That this is the bank's lasting edge is the paper's central hypothesis. It holds only if claims become infrastructure that outside agents must call in high-value journeys, not a feature of the bank's own agent.

Detail: Appendix C1.5 and C1.6; claim 14 in Appendix D4.

3.3 Set a North Star and fund the apex

A North Star is a customer outcome that AI makes possible, stated plainly enough to veto a programme. For example: "Every customer has a trusted agent that runs their financial life, across every provider." Map the components it needs, and place each on the evolution axis: build, buy, rent or contain. Then give every running programme one label: apex, enabler, mandatory, economic or legacy drag. Stop or shrink legacy drag.

A working target is at least 40% of change spend on apex components. Track two numbers each quarter at board level: the run-versus-change split and the apex share. The drift bends only when the apex share rises.

Detail: Appendix C2; North Stars for every product line in C4.

3.4 Proof point: the Personal Finance Agent

The PFA answers one need in the customer's words: "Help me feel in control of my money, across every account I have, without having to manage it."

	Core-led	Outcome-led
Starting point	The core system	The customer outcome
Data	Harmonise everything first	Read scoped data through a semantic control plane
Scope	The bank's own accounts	Every provider the customer consents to
First customer value	Years (working estimate)	Quarters (hypothesis)

Outcome-led delivery builds three apex components first: a personal context graph, a purpose-bound consent router and a semantic control plane over legacy data. Autonomy climbs a seven-rung ladder gated by risk and reversibility, and the first release is read-only. The core keeps its investment where resilience, regulation, economics or a named outcome requires it, but it no longer gates customer value.

An illustrative model, not an estimate, nets €30 per active user per year. Retention and product take-up carry most of that value, so the pilot must measure them first. Its metrics are kill criteria: if by month 9 the PFA does not beat a free general assistant on control and trust, the bank shifts weight to market B.

Detail: Appendix C3.

3.5 Guardrails, and how we would know we are wrong

Outcome-led delivery moves risk rather than removing it: model errors, answers that cannot be explained, and liability for agent actions. The design answers each with maths verifiers, evidence behind every answer and graduated autonomy.

This paper is a strategic hypothesis, not a forecast. Two signals would weaken it most: customers do not adopt financial agents, or verified claims become a commodity anyone can issue. If the indicators turn, shift weight from market A to market B rather than abandon the outcome-led approach.

Detail: Appendix C5 and C6; every load-bearing claim is in D4. The control stack, liability positions and a stress test against legacy cores are in the Technical annex.

3.6 Roadmap and board decisions

The first 90 days set how the bank competes: with its own agent, as the trust layer beneath other agents, or both. The roadmap has two gates, "North Star signed off" and "usage and consent targets met", and lands the first PFA releases, piloted where digital channels are cleanest, before the regulatory window closes. The board approves eight resolutions, from the North Star and the PFA investment envelope to an autonomy policy and model exit plans. Progress is measured in customer outcomes, not foundations laid.

Core systems will always need investment, and regulation will make sure they get it. The question for every board in France and Benelux is what the rest of the change budget builds.

Detail: Appendix C7; where to pilot in A1.5.

The appendix

The evidence and working behind this paper are published as separate parts:

Appendix A: Situation evidence: The modernisation trap and Bain's Elements of Value: the evidence behind the situation.
Appendix B: Complication evidence: Wardley maps of five technology waves, and how AI-native challengers reach customers without a core.
Appendix C1–C2: One platform, two products, and the method: The trust stack, verified financial claims, and how to set a North Star.
Appendix C3: The Personal Finance Agent: Core-led versus outcome-led delivery of a Personal Finance Agent, with kill criteria and economics.
Appendix C4–C7: Product lines, guardrails and roadmap: North Stars for every product line, feasibility in large groups, regulation, falsifiers and the roadmap.
Appendix D: Glossary, sources and claims register: Glossary, sources, the author's related work and the register of every load-bearing claim.
Technical annex: Agent control, liability and failure: Agent control architecture, autonomy ladder, liability positions, failure scenarios and a legacy-core stress test.

Next: Appendix A: Situation evidence

CitePulse: Auditing the Answer Layer

Lawrence — Thu, 24 Sep 2026 12:37:35 +0000

CitePulse: Auditing the Answer Layer

CitePulse is a local-first, open-source AEO audit instrument (MIT): it runs on your own machine against a free local model (llama3.1:8b via Ollama) and assesses a site's AI answer readiness against five derived principles — a machine must be able to read the site, cite it truthfully, share it against competitors in real prompts, act on it when an autonomous agent attempts a task, and be told honestly when a score cannot be measured ("not determined" rather than a guessed number). It drives a real browser as an autonomous agent instead of just parsing an API. This case study runs it against three real commercial targets on the same day — an AI search-monitoring SaaS, a European staffing and recruitment firm, and a cooperative bank — and walks the reasoning behind every value in the resulting audit reports (run 2026-09-24, CitePulse v1.7.0).

Anonymization note. The three targets are real, named companies that were audited without prior arrangement from their public sites. Their identities are withheld here; each is described only by category. Every figure is exactly as the tool reported it.

Disclosure. The author is the maintainer of CitePulse, the tool used for these audits.

1. Three tests, three verdicts

One instrument, one model, one prompt-scheme version, one day. Only the targets differ — and so do the verdicts, each for a different reason.

Target (anonymized)	Category	Verdict	KPIs measured	Task runs	Duration	Audit ID
Target A	AI search-monitoring SaaS	Needs attention	9 of 9	6	~34 min	`50a7b1fb…`
Target B	European staffing & recruitment	High risk	6 of 9	4	~37 min	`eaedd414…`
Target C	Cooperative bank	Needs attention	5 of 9	5	~11 min	`ff7f499c…`

Three failure profiles, visible before reading a single KPI:

Target A fails where agents act. Fully measured (9/9) — best-in-class readability, 100% citation correctness, 91.3% share — and then collapses the moment an autonomous agent tries to do something.
Target B is invisible. Crawl infrastructure is best-in-class, yet the model never quotes it at all — a retrieval/content failure, not a technical one.
Target C is refused. Nearly half its metrics (4 of 9) are not determined: its crawler-facing surface blocks measurement outright and every agent task hits an authentication wall. The tool declines to score what it cannot verify.

The verdict band is never the average of nine numbers; it is the report's statement of the weakest load-bearing principle. That is the framing all three scorecards below sit on.

2. The scorecards: nine KPIs across the three targets

KPI (ID)	Principle	Target A (SaaS)	Target B (staffing)	Target C (bank)
AI Crawl Accessibility (#1)	1	3.0 / 3 — Best in class	3.0 / 3 — Best in class	Not determined (blocked)
Schema Markup Coverage (#3)	1–2	3.0 / 3 — Best in class	2.0 / 3 — Good	Not determined (blocked)
llms.txt Readiness (#46)	1	3.0 / 3 — Best in class	Not determined (404 / 403)	2.0 / 3 — Good
Citation Correctness (#45)	2	100.0% (N=10) — Best in class	Not determined (0 citations to judge)	100.0% (N=5) — Best in class
Citation Rate (#22)	2–3	55.6% (N=18) — Good	0.0% (N=18) — Critical	33.3% (N=18) — Needs improvement
AI Share of Voice (#24)	3	91.3% (N=18) — Best in class	0.0% (N=18) — Critical	86.5% (N=18) — Good
SoV (Weighted) (#62)	3	89.1% (N=18) — Good	91.7% (N=18) — Best in class	91.2% (N=18) — Best in class
Interaction Readiness (#58)	4	74.3% (N=35) — Needs improvement	85.7% (N=7) — Good	Not determined (gated)
Task Completion (#48)	4	33.3% (N=3) — Needs improvement	Not determined (sample below floor)	Not determined (gated)

Read the rows twice: once for the values, once for what the empty cells are saying. The not-determined cells are not voids — they are the instrument refusing to guess. Target B's citation and SoV at 0% with crawl at 3.0 is the purest demonstration in this dataset that readability and retrievability are different things. Target C's four not-determined cells are the instrument correctly distinguishing "we can't verify this" from "this failed."

3. The underpinning logic: from principle to the audit values

A score is only as good as the chain between the readiness claim and the number. This section walks that chain principle by principle, across all three targets.

3.1 Principle 1 — the read layer

Claim operationalized: a machine must traverse every layer of the estate — robots policy, structure index, machine-readable summary — before any other readiness question is addressable. If principle 1 fails, every later metric is uninterpretable because you can't tell "missing" from "unread."

Target A: 3.0 / 3.0 / 3.0. All three gates fully pass — robots allows known AI crawlers, valid schema is present, llms.txt has section headers and live links. Analytically this is the most valuable row: because the read layer is perfect, A's later failure cannot be blamed on blocking. Attribution, secured.
Target B: crawl 3.0, llms.txt not determined. The crawler can traverse the site and a sitemap exists, but the documented llms.txt paths return 404 and 403 — the probe cannot conclude whether an index is present or absent, so it does not invent an answer. A partial read of the intended index layer.
Target C: none of it. robots.txt and the schema probe both come back blocked. The audit cannot conclude whether AI crawlers are disallowed or whether structured data exists — it reports exactly that.

3.2 Principle 2 — correctness vs. rate

Claim operationalized: readability ≠ citability. Two separate things must be true: a fetched page must contain claims a model can quote accurately (correctness), and those pages must actually be surfaced in answers (rate).

Target A: 100% correctness, 55.6% rate. Ten of ten judgeable citations were supported by the cited pages' own content — the pages, once found, are truthful sources. But fewer than two-thirds of answers cite A at all, and the segment split makes the mechanism explicit: ~100% citation on capability-level queries, ~0% on category-discovery queries. The pages are answer-shaped but not question-matched. Because correctness is 100%, this is a placement problem, not a truthfulness problem — and the remediation differs accordingly.
Target B: 0% rate, correctness not determined. There are no citations to judge — the correctness probe literally has an empty input. The model prefers a competing professional network and a job board on the queries tested. This is the signature of content that exists but is not retrievable as quotable facts: "indexed but never quoted."
Target C: 100% correctness, 33.3% rate. Five of five judgeable citations check out, but only 6 of 18 answers cite the bank. Notably, it is not cited on the most basic question in the set — "What is ?" — while specialty topics are well covered. Uneven topical coverage, not weak content.

3.3 Principle 3 — share

Claim operationalized: presence isn't share; share must be competitive. Being citable in principle isn't being chosen against whoever surfaces in the same prompts.

Target A: 91.3% raw, 89.1% weighted. Dominance in the retrieval layer, with a two-point weighted gap pointing at where a competitor edges into comparison queries — the place where buying decisions concentrate.
Target B: 0% share. Not cited, not chosen, across all five tested query stages. This KPI is the numeric cost of the principle-2 failure.
Target C: 86.5% raw, 91.2% weighted. High and broad — a peer bank still beats it on brand-identity queries ("What is …?"), a narrow authority gap rather than a systemic one.

One anomaly worth reading against principle 5: Target B shows 0% unweighted SoV yet a 91.7% weighted SoV banded best-in-class. Both numbers come from the same N=18 sample; the apparent contradiction is a reminder that a business-impact-weighted score can offset a tiny, dominated share — precisely the situation where a confidence flag earns its keep.

3.4 Principle 4 — action (the layer almost no tool tests)

Claim operationalized: being mentioned isn't being useful. When an autonomous agent tries a real task, can it finish? This requires actually driving a browser, which is why nearly every other tool in the category stops at principle 3.

Target A: 33.3% completion, 74.3% interaction readiness. Of the three site-attributable tasks, one succeeded and two were site failures (an API task was blocked as a policy restriction and is counted separately, not as a failure). The interaction reading is a transcript — 9 of 35 low-level actions failed:

Page.click: Element is not visible
Call log:
  - waiting for locator("[data-aeo-idx=\"7\"]")
    - locator resolved to 2 elements. Proceeding with the first one:
      <a tabindex="0" data-aeo-idx="7" href="/features/ads-tracking"
         class="navbar2_dropdown-link w-dropdown-link">Ads Tracking</a>
  - attempting click action
    - scrolling into view if needed

Three engineering-grade signals in one trace: a non-unique selector resolving to two elements, an occluded target that cannot be brought into view, and a click that never completes so the agent stalls until exhaustion. The value → mechanism → fix chain is complete: unstable selectors and hidden dropdown targets are a diffable code change, not a strategy problem.

Target B: 85.7% interaction, task completion not determined. The only site-attributable task run succeeded, but the sample fell below the minimum, so completion is honestly not scored. Interaction is close to best-in-class — a single failed action, where the agent tried to type a location into an element that is a link:

Page.fill: Error: Element is not an <input>, <textarea>, <select> or [contenteditable]
  - waiting for locator("[data-aeo-idx=\"3\"]")
    - locator resolved to <a href="/" data-aeo-idx="3" class="…logo-link…">
  - fill("location")

Target C: entirely refused. All five agent tasks — checking a balance, paying a bill, applying for a card — were correctly classified as gated boundary: they terminate at an authentication wall and an error page. The bank's real tasks are behind login, and an instrument without credentials cannot test them. The taxonomy does not call an HTML login page a "site failure," so task completion and interaction readiness are reported not determined.

3.5 Principle 5 — the governance rule every value stands on

Principle 5 is not a score; it is the enforcement layer that makes 3.1–3.4 trustworthy:

Not determined is a designed output across all three runs. Target B: llms.txt, correctness, task completion. Target C: crawl, schema, task completion, interaction. Where a clean measurement was impossible — blocked fetch, no citations to judge, an auth wall, a sub-floor sample — the report said so instead of interpolating.
Below-floor samples are declared, not smoothed. The limitations sections name the exact KPIs measured under the confidence floor: A → #22, #24, #45, #62, #48; B → #22, #24, #62, #58; C → #22, #24, #45, #62.
The model's proxy status is stated up front. Citation and SoV metrics come from a local llama3.1:8b synthesizing over live web-search results — "a proxy for AI-answer-engine behavior, not a live query to ChatGPT, Perplexity, Gemini, or Copilot."
Deltas refuse to overclaim. Across the runs, every change is either "within noise — not a significant change" (e.g. C's citation rate −16.7% band Good → Needs improvement) or "no confidence interval available — not checked for significance" (e.g. A's SoV +14.2%).
The tool even audits its own history. Target C's 18-run trend carries an explicit warning that the series spans multiple models (qwen2.5:7b, llama3.1:8b, granite3.2-vision:2b, gemma2:9b, llava:7b), so an apparent change may be a model difference, not a change on the site.

3.6 The composed verdicts

Target A is "Needs attention" despite a best-in-class read layer and 100% citation correctness, because the report treats actionability as load-bearing. Readable, citable, and cited — and still one-third usable when an agent acts.
Target B is "High risk" because it fails at the retrieval boundary itself: a technically healthy estate that no answer engine quotes.
Target C is "Needs attention" because nearly half of readiness is unverifiable behind its defenses, and — where it could be verified — the readings are strong.

Three verdicts, three different load-bearing principles. That is the entire argument against blended scoring.

4. Epistemics in practice

One run's full accounting, per target:

Discipline	Target A	Target B	Target C
Confidence attached	N=3/35/18/10, low–medium	N=7/18, low–medium	N=5/18, low–medium
Declared below floor	#22 #24 #45 #62 #48	#22 #24 #62 #58	#22 #24 #45 #62
Not determined	—	3 KPIs	4 KPIs
Excluded task outcomes	policy_restriction ×1, invalid_task ×2	invalid_task ×2, policy_restriction ×1	gated_boundary ×5
Proxy stated	llama3.1:8b over live web search	same	same
Taxonomy honored	API task ≠ failure	invalid tasks & policy restrictions ≠ failure	auth wall ≠ failure (gated)

5. Measurement as a standing capability

The reports are explicitly built for cadence, not one-off snapshots:

Target A compares against the 2026-09-22 run and shows a 5-run trend (2026-09-15 → 09-24): citation rate 50 → 27.8 → 50 → 50 → 55.6; SoV 52.4 → 11.7 → 94.7 → 77.1 → 91.3; interaction 66.7 → 74.3. The SoV series — spanning 11.7% to 94.7% on low-confidence N=18 samples — is exactly why principle 5 exists: without per-delta significance disclaimers, that noise would be read as a trend.
Target B compares against 2026-09-19: only 2 runs so far; crawl and citation flat, weighted SoV 100 → 91.7.
Target C is the strongest cadence example: 18 completed runs since 2026-09-04, for which the report itself flags the multi-model caveat. Citation rate has swung between 0% and 61% across that history — a genuinely noisy market signal that any single-point measurement would misrepresent.

6. Reproducibility, auditability, and zero data egress

Two properties keep the instrument credible for governance use:

The runs are re-verifiable. Each manifest embeds audit_id, start/finish timestamps, model/provider, coverage counters, requested_kpi_ids, and generation-scheme versions (task_generation: 1.0.0, citation_prompts: 1.0.0). A skeptic can re-run instead of trusting a slide-deck screenshot.
Nothing leaves the machine. Default execution is local (Ollama + a local model), and every report footer states: "Generated locally by CitePulse — no data leaves your machine." The scoring logic is MIT-licensed and public — a metric you cannot explain to your own risk committee is disqualifying for governance purposes.

The design notes are candid about limits: a WAF returning a "just a moment" challenge page with HTTP 200 can slip through the crawl probe — "a known limitation, not a solved one." Naming the failure mode and tracking it is part of principle 5.

7. What each audited firm should do next

Target A (AI search-monitoring SaaS):

Fix Task Completion (P1): 1 of 3 site-attributable tasks succeeded. Re-run and confirm it leaves "Needs improvement."
Fix Interaction Readiness (P1): 9 of 35 actions fail on unstable selectors and occluded targets — stable selectors (test-ids, roles), unique and present before any action.
Close the citation-rate gap (P2): ~100% capability-level vs ~0% category-discovery — content-vs-query alignment, not a crawl problem.
Guard weighted SoV where a competitor edges into comparison queries.

Target B (staffing & recruitment):

Fix citation rate and SoV (P0): 0% across 18 answers. Publish clear, structured, quotable content (FAQs, comparison content, a valid llms.txt) and confirm the site is indexable by the engines answer engines draw from.
Complete Organization schema (P2): structured data present but missing required fields.
Add a reachable llms.txt (P2): documented paths return 404/403.

Target C (cooperative bank):

Unblock basic measurement: public robots.txt and schema probes were blocked — if deliberate, confirm this trade-off is acceptable; the tool can report nothing about crawler access.
Improve quote reliability (P1): 6 of 18, including a miss on "What is the bank?" — structured FAQs and clearly named entities.
Add section headers to llms.txt (P2): present but not a navigable index.
Expect the gated boundary: banking tasks sit behind auth — run agent task tests with credentialed sessions to measure what matters where it happens.

8. Lessons for practitioners

Separate the failure modes; never blend them. This dataset is a complete proof: one target is cited-but-unactionable, one is technically clean but invisible, one is defensively unverifiable but strong where measurable. A blended score exists to hide exactly these distinctions.
The value is only as good as its derivation chain. Every KPI here can be walked from claim → principle → measurement → fix. That is what makes the numbers defensible in a room where someone says "prove it."
Test principle 4 or you are not measuring the answer layer. Querying an API tells you what a model says; attempting the task tells you what the site does. Across three audits, the action layer showed a real failure, a near-pass, and a refusal — only a browser could tell you which.
"Not determined" is a measurement, not a caveat. Target C's four refused KPIs are more informative than any guessed number would be.
Demand the confidence. A rate without a sample size and a confidence floor is a vibe.
Scorecards should come with diffs — "within noise," "not checked for significance," "not comparable" — or the measurement cannot compound.
The epistemology is the product. A tool that never says "I don't know" is telling you more about its incentives than about your visibility.

9. Sources

CitePulse reports, run 2026-09-24, CitePulse v1.7.0, model llama3.1:8b, targets anonymized: Audit 50a7b1fb… (AI search-monitoring SaaS, 9/9 KPIs), Audit eaedd414… (staffing & recruitment, 6/9 KPIs), Audit ff7f499c… (cooperative bank, 5/9 KPIs).
Lawrence Sanjay, "The Answer Layer" — design article for CitePulse (dev.to, 2026-09-18).
CitePulse (open source, MIT): github.com/alsanjayllm/CitePulse-public

The Answer Layer

Lawrence — Fri, 18 Sep 2026 13:13:01 +0000

Search rewarded the firm that ranked. The answer economy rewards the firm that gets cited, synthesized, and acted on — by a model, not a person. Most companies don't yet have a function that owns this, and most of the tools built to measure it can't be trusted to tell you the truth when the truth is "we don't know."

Every platform shift makes a firm re-externalize itself in a new grammar. The web forced companies to become HTML — to exist as pages a browser could render. Mobile forced them to become responsive layouts and native apps. The API economy forced them to become machine-callable endpoints, whether or not the org chart had caught up. Each time, the firms that treated the shift as a marketing checkbox lost ground to the ones that treated it as an architecture problem.

We are two or three years into the next one, and most digital strategy decks still haven't updated the org chart for it. Conversational AI systems — ChatGPT, Perplexity, Gemini, Copilot, the AI Overview box sitting on top of a Google search — have inserted themselves between the firm and the customer's decision. Increasingly, the customer never reaches the firm's website at all. They ask a question, the model answers, and somewhere inside that answer is either your name or it isn't. If it is, you had no control over the sentence. If it isn't, you don't know why, because you were never in the room.

This is not "SEO for chatbots." It is a new layer of the digital estate — sitting between the firm's content and infrastructure on one side, and an AI system's synthesis and action on the other — and it needs the same architectural seriousness that firms eventually gave the web, mobile, and APIs. I'll call it, for lack of a better name, the answer layer.

Three ways a firm disappears

Strip away the vendor jargon (AEO, GEO, "share of voice") and there are exactly three failure modes a firm can suffer in the answer layer, and they compound:

Invisibility. The model never cites you at all, because its crawlers can't reliably read your site, or your content doesn't contain the kind of clearly-stated, attributable facts a model likes to lift and cite.
Misrepresentation. The model cites you, but gets you wrong — stale pricing, a discontinued product, a competitor's claim mistakenly attributed to you — because nothing in your content architecture makes the current, authoritative version of a fact easy for a machine to find and prefer.
Non-actionability. The model cites you correctly, and it still doesn't matter, because when an autonomous agent tries to actually do something on your site on the user's behalf — check a price, start a form, complete a booking — it can't. You were describable but not usable.

That third failure mode is the one strategy decks miss most often, because it's the newest. 2024–2025 was the year firms noticed they should worry about being cited. 2026 is the year the same conversational systems started acting — filling forms, comparing options, completing purchases — on the user's behalf. A site optimized to be quoted by a model but unusable by an agent has solved yesterday's problem.

Non-actionability, in numbers

This isn't a hypothetical third failure mode — it's the current, measured state of agentic web use, on both sides of the transaction.

Human baseline, multi-step web tasks: 78% vs. best published AI web agent, same benchmark family: ~71%. Task-completion rates on WebArena, the standard realistic-website benchmark for autonomous agents, rose from roughly 14% two years ago to the low-70s today — real progress, and still short of the human baseline on the same tasks. On harder, open-web tasks the gap is starker: OpenAI's BrowseComp benchmark put a basic LLM-plus-browsing setup at 1.9% accuracy, versus 51.5% for a purpose-built research agent — a 27x gap that tracks almost entirely to how deliberately the site and the task were engineered for an agent, not a human, to complete.
17% of shoppers are comfortable letting an AI complete a purchase, vs. 58% who already use AI to research one — Checkout.com, 2026.
$15T in B2B purchases Gartner expects AI agents to intermediate by 2028 — 90% of all B2B buying — Gartner, via Digital Commerce 360.
40%+ of agentic AI projects Gartner expects to be canceled by 2027, over cost and unclear ROI — Gartner, via MarTech.

Read together, these don't cancel out — they describe exactly the gap principle 4 is meant to catch: the volume of agent-mediated transactions is about to be large regardless of whether any given site is ready for it, and the readiness gap on both the buyer-trust side and the agent-capability side is still wide open. A firm that waits for the benchmarks to fully close before treating this as a strategy problem will be solving it under a deadline it didn't choose.

Being findable and being usable used to be nearly the same problem, because the entity doing the finding and the entity doing the using were both a human with a browser. The answer layer splits them. You now have to design for two readers that don't share a nervous system.

Why this belongs on the strategy agenda, not the SEO backlog

Three things make this a governance-level problem rather than a channel-level tactic.

First, the economics are winner-take-most, not winner-take-share. A search results page shows ten blue links and lets the user pick. An AI answer typically names two or three sources, sometimes one. If a competitor's content is more citable than yours — better structured, more current, more explicit about entities and facts — the model doesn't split the difference. It picks them. Ad spend doesn't fix this; content architecture does.

Second, it cuts across every function that already owns a piece of the digital estate — marketing owns the content, IT owns the infrastructure and crawl policy, product owns whatever an agent would need to transact, legal and brand own what "correct" means when a model paraphrases you. No single function can fix the answer layer unilaterally, which is exactly the pattern that historically needed an enterprise architecture response (a digital office, a platform team, a center of excellence) rather than a point solution bought by one department.

Third, the tooling that's sprung up to measure this is largely proprietary and unauditable — which for a governance-level metric is close to disqualifying. You cannot put a number on a board slide if you can't explain, to your own risk committee, how it was computed. That problem is serious enough that it deserves its own section, because it's where most of the current market gets the answer layer wrong.

Building the score from first principles

Before asking which vendor's dashboard to buy, it's worth asking a more basic question: what would a rigorous "AI answer readiness" score even have to measure, if you derived it from scratch rather than copying whatever the market currently ships? Five principles fall out, each one a precondition for the next — if a firm fails an earlier principle, scoring the later ones produces a number that looks precise and means nothing.

1. You can't manage what a machine can't read.
Before anything else, can an AI crawler or agent actually fetch and parse your site at all? This is the floor: robots policy, crawl accessibility, and increasingly a machine-readable index of your own content — an llms.txt equivalent of the sitemap — telling an agent what exists and where. Increasingly this floor sits one layer below the app entirely: a CDN or WAF (Cloudflare, Akamai, and similar) can bot-challenge or block a crawler before a request ever reaches your server, which your own team may never see in application logs. A firm that fails this test fails everything downstream by construction, not by bad luck.
Fails silently as: "why don't we show up anywhere?"

2. Being readable isn't being citable.
A machine can fetch your page and still have nothing worth quoting, if your facts are buried in marketing prose instead of stated as clear, attributable claims a model can extract and cite with confidence. Citability is a content-structure property, not a crawl property — it's the difference between a page that contains the answer and a page that is the answer.
Fails silently as: "we're indexed but never quoted"

3. Presence isn't share.
Being citable in principle doesn't mean you're chosen in practice, against the specific competitors who show up in the same prompts your buyers actually type. This is where "citation rate" and "AI share of voice" belong — measured across a representative set of real queries, not a single anecdotal chat transcript someone screenshot for a deck.
Fails silently as: "we got cited once, so we're fine"

4. Being mentioned isn't being useful.
The newest and least-measured principle: when an autonomous agent, acting for a user, tries to complete a real task on your site — get a price, start an application, book a slot — can it actually finish? A citation with no working path to action is a compliment with no revenue attached. Almost nothing in the market tests this directly; most tools stop at principle 3.
Fails silently as: "we're cited constantly and conversion hasn't moved"

5. A score that lies about its own confidence is worse than no score.
This one isn't a KPI, it's a constraint on all four above: when a measurement can't be made cleanly — a blocked fetch, a rate-limited request, an ambiguous model answer — the honest output is not determined, not a plausible-looking guess averaged in to keep the dashboard tidy. A methodology that always produces a number, no matter how thin the evidence, has optimized for a confident-looking board slide over an accurate one.
Fails silently as: a beautiful trend line built on interpolated noise

Notice what this derivation rules out. It rules out a single blended "AI visibility score" that averages crawl accessibility with citation rate — those measure different failure modes and collapsing them hides which one is actually broken. And it rules out any methodology proud enough of its own coverage that it never admits uncertainty; principle 5 is the epistemic check on principles 1 through 4, not an optional nicety.

Illustrative evidence — identity withheld

Here's why principles 1 and 4 have to be scored separately rather than blended into one number. This is an anonymized extract from a real audit run against a large, well-known consumer-facing platform — the name isn't the point, so it's withheld; the pattern is what matters, and it's a pattern I've now seen repeat across very different sites.

KPI	Result	Band
AI Crawl Accessibility	3.0 / 3	Best in class
llms.txt Readiness	Not determined	One path blocked, one 404 — not measurable
Citation Rate	16.7% (N=18)	Needs improvement
AI Share of Voice	20.1% (N=18)	Needs improvement
Task Completion Success Rate	0.0% (N=5)	Critical
Interaction Readiness	86.7% (N=60)	Good

An autonomous agent failed to complete any of 5 attempted tasks on this site (0 succeeded, 0.0%) — for example, a core "explore the catalog" journey failed outright. The same site scores a clean 3/3 on crawl accessibility: robots.txt is open and a sitemap is published.

That gap is the whole argument in one row: a site can be perfectly readable by a crawler (principle 1, best-in-class) and still be zero-percent usable by an agent trying to act (principle 4, critical) — two different failure modes that a single blended score would have quietly averaged into a reassuring "pretty good." And llms.txt Readiness landed on "not determined," not a guessed 0 — one supported path returned a 401, the other a 404, which isn't proof of absence, so principle 5 says stop there rather than round it down.

Worth being precise about what a 401 there does and doesn't tell you: it means a layer of the stack blocked the request, not necessarily the application — a CDN or WAF sitting in front of the origin will bot-challenge or block a request before it ever reaches the site's own code. Principle 5's discipline applies here too: "blocked" isn't "absent," so the honest answer stays "not determined" rather than being rounded down to "no llms.txt."

Where most of the market gets the epistemics wrong

The answer-engine-optimization category that's formed around this problem over the past two years is mostly cloud SaaS: send the vendor your brand and your competitors' names, they run queries against commercial AI APIs on your behalf, and you get a dashboard back. That model has a structural incentive problem that has nothing to do with any individual vendor's competence.

A vendor selling continuous monitoring is not incentivized to tell you "not determined" — an incomplete data point looks like a product bug, not an honest result, so the pressure runs toward always returning a confident number. The scoring methodology is usually proprietary, which is defensible commercially and indefensible if you're trying to cite the number in a governance document. And because the category grew out of SEO tooling, almost none of it tests principle 4 — whether an agent can actually complete a task on your site — because that requires actually attempting the task, not just querying an API and parsing the response.

None of this makes those tools useless — for a marketing team that wants directional trend data and is comfortable with a black box, they're a reasonable buy. It makes them the wrong instrument for a board-level claim about the firm's exposure, because you can't audit what you can't see.

By the way — I ended up building a small instrument for my own audits, mostly because I wanted principles 1–5 above operationalized honestly rather than just described in a slide. CitePulse is an open-source, local-first AEO audit tool — it runs on your own machine against a free local model by default, so nothing about your brand or your prompts is sent to a third party, and the scoring logic is readable in the repo rather than hidden behind an API. Its six KPIs map directly onto the principles above — crawl accessibility, citability structure, citation rate and share of voice, and, unusually for the category, a task-completion test that actually drives a browser to see whether an agent can complete something on the site, not just describe it. When something can't be measured cleanly — a blocked path, a rate-limited request — it reports "not determined" instead of guessing; the crawl-accessibility check goes a step further and falls back to a real headless-browser navigation when a plain fetch looks bot-blocked, the same principle-5 discipline in code. It doesn't yet fully close every CDN-layer gap either — a WAF that returns a "just a moment" challenge page with an HTTP 200 rather than a clean 401 can still slip through undetected, which is a known limitation, not a solved one (tracked here). It's incidental to the argument here, not the point of it — but if you want to see the principles as running code rather than prose, the repo is public and MIT-licensed.

Where CitePulse sits, by principle — scored 0–3 against Profound, AthenaHQ, and Scrunch AI:

Scores are this author's illustrative 0–3 reading of the feature comparison below, not a third-party benchmark. Note the chart is deliberately not a clean sweep: the SaaS platforms score higher on citation-rate rigor (they query real commercial engines directly; CitePulse's own-model proxy says so in every report) and on published enterprise compliance — the two axes where a mature, funded SaaS product should be expected to lead.

Property	Typical AEO SaaS	CitePulse (illustrative)
Where data lives	Vendor cloud	Your machine, by default
Methodology	Proprietary, black-box	Open source, auditable
Unmeasurable result	Interpolated / hidden	Reported as "not determined"
Tests agent task completion	Rare	Yes, by design
Pricing model	$99–$300+/mo, per-query	$0, local model

The comparison isn't "which tool wins" — a privacy-conscious solo team and an enterprise marketing org buying prompt-volume depth are solving different problems and will reasonably choose differently. The point of putting it in a table is narrower: it shows that principles 1 through 5 aren't hypothetical design goals, they're a methodology you can actually ship, at zero marginal cost, without asking anyone to trust a vendor's black box.

What a firm should actually do with this

Treat the answer layer the way the better-run firms eventually treated mobile and APIs: as a standing capability with an owner, not a quarterly audit that produces a PDF nobody reopens.

Give one function — a digital office, a platform team, whoever already owns the site's information architecture — explicit accountability for all five principles, not just the content team owning citability while nobody owns task-completion.
Publish and maintain a machine-readable index of your own site (an llms.txt, kept current) the same way robots.txt and a sitemap became routine twenty years ago.
Put citation rate and share of voice on the same competitive-intelligence cadence as any other market-share metric — because that's what it now is.
Before your next redesign or checkout flow ships, ask explicitly whether an autonomous agent could complete it on a customer's behalf. If nobody can answer that, you've found the gap.
When you evaluate a measurement tool — any of them — ask what it does when it can't get a clean answer. A tool that never says "not determined" is telling you more about its incentives than about your visibility.

The firms that treated the web, mobile, and APIs as architecture problems rather than marketing checkboxes are, unsurprisingly, the same firms that aren't scrambling now. The answer layer is the same test again, with a shorter runway and a less forgiving audience — the audience this time is a model, and it doesn't scroll past you out of habit or brand loyalty. It just doesn't mention you.

CitePulse (open source, MIT) — github.com/alsanjayllm/CitePulse-public