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.
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
Top comments (0)