My friend Dharmesh Mistry’s Franken-core series is one of the sharper diagnoses of banking’s structural problem that I have read in some time. He is right to argue that this is no longer just a legacy cost story. It is becoming a strategic fitness test for a world of programmable money, tokenised deposits, always-on settlement and AI agents acting on behalf of customers and firms.
His series is strong on diagnosis and strong on future direction. Where I want to add something is around the method: how a bank gets from today’s brittle estate to that future without blowing itself up along the way.
The central line running through all five is simple. Banks did not end up with legacy cores because they were foolish. They got there through decades of rational, incremental decisions that made sense locally and, over time, created an estate that no longer makes sense globally.
Banks have also ended up where they are, in part, through what I call the Duct Tape Economy in my book Rip Out the Core. When strategic transformation is delayed, short-term fixes become easier to justify. New functionality is bolted onto old platforms. Another integration is created to work around an existing limitation. Manual controls are introduced to compensate for missing capabilities. Each decision solves an immediate problem, but also makes the next change more difficult and expensive.
In We built the monster, Dharmesh is at his best because he refuses the lazy caricature. The old estate was assembled through decisions that were often reasonable in the context in which they were made. He also makes a point many boards still underweight. The problem is not only technical debt, but human dependency. When critical integrations and business rules survive primarily in the heads of a few experienced specialists, the bank is not merely complex. It is operationally fragile.
His additional sting is that this eventually turns into what he calls “AI impotence”. Fractured data, hidden logic and undocumented dependencies make serious machine-led decisioning unreliable. AI can only be as trustworthy as the information, processes and control environment around it. Placing an intelligent interface over an incoherent estate does not make the underlying bank intelligent.
In The transplant, Dharmesh moves from diagnosis to the pragmatic middle ground. His second-core strategy is not sexy, but it is recognisable. Banks are effectively learning to quarantine parts of the old core while establishing new infrastructure beside it for capabilities such as tokenised deposits and programmable money.
In A billion reasons why the monster won’t scale, he shifts from architecture to load. He argues that streaming money becomes plausible when tokenisation meets AI agents, and that advisory agents will increasingly become transactional. His thought experiment is deliberately provocative. Fifty million UK adults, each generating twenty micro-transactions a day, creating a billion daily interactions with the payment infrastructure.
Whether the timing and exact volumes prove correct is less important than the architectural implication. A system built around batch processing, end-of-day reconciliation and predominantly human-initiated flows is a poor fit for continuous, conditional and machine-driven movement of value.
In The plan to end the monster, the argument becomes especially useful for boards. Dharmesh says, bluntly, that banks need a plan, but not another big-bang fantasy. He identifies four essential components: a target architecture, sequencing logic, migration triggers, and a realistic assessment of budget and risk.
Crucially, his target architecture is not a vendor pitch, and his sequencing logic is driven by strategic priority rather than technical convenience. That is a far better board conversation than another beauty parade of core vendors promising salvation.
Then, in The endgame beyond the monster, he describes the future state. The destination is not merely a better version of the existing core, but a different kind of bank built around an intelligent ledger, where value and deterministic financial logic sit closer together, settlement can become atomic, and money can move continuously and conditionally.
He also points towards industry initiatives involving organisations such as UK Finance, the Hong Kong Monetary Authority, J.P. Morgan, The Clearing House and EnsembleTX as evidence that programmable money is moving beyond theoretical PowerPoint material and into practical experimentation and production learning.
If you want a future-facing strategic provocation for a banking leadership team, this is it.
Where Dharmesh and my thinking meet
My own view, and the argument behind Rip Out the Core, starts from almost the same place. Core transformation is no longer a peripheral technology project. Banks need to move from brittle monoliths towards modular, platform-enabled and eventually coreless forms of banking, while continuing to process payments, protect balances, serve customers, support employees and satisfy regulators throughout the transformation.
By coreless, I do not mean a bank without a ledger, financial records or a controlled transactional centre. I mean a bank in which the traditional core no longer dictates the structure, speed and ambition of the entire institution. The core becomes smaller and sharper, while the capabilities around it can change independently.
The real art is therefore not dramatic demolition. It is careful and methodical transformation. That is the foundation of Platform-Enabled Banking Transformation, or PEBT. Progressive transformation, step by step and capability by capability, with strategy, sanity and staying power.
In this context, the distinction between modernisation and transformation matters.
Modernisation improves the machinery of the bank. A platform, data centre, payment rail or core system may be made faster, cleaner, cheaper, safer and easier to operate. Modernisation is often necessary, but it is not always the right answer for every part of the estate. Some components should be modernised. Others should be isolated, progressively emptied or allowed to run off.
Transformation changes the business the machinery exists to serve.
The automobile was not a modernised horse and cart. It changed mobility. In the same way, the future of banking will not be created simply by modernising yesterday’s core. In a world of agentic AI, programmable money, embedded finance, tokenised assets and rapidly changing customer expectations, the real question is not whether some elements of the core estate need to be modernised. They almost certainly do.
The question is whether that modernisation serves a wider transformation agenda, or whether the bank is polishing the old machine while the market moves on.
That is why Dharmesh’s series complements the book so well. He strengthens the burning platform and sharpens the urgency. He pulls the conversation away from the comfortable belief that the bank can probably continue patching the estate for another few years. AI will not save bad architecture. Programmable money is not merely another payment feature, and a bank that cannot separate what must remain stable from what must become adaptable will struggle to respond.
My book is deliberately more method-led and less thesis-led. It pushes executives to begin with business strategy, Business Capabilities, decision rights, architectural boundaries and sequencing logic before disappearing into technology selection. It describes a route from monolithic core structures towards modular, multi-core and event-driven banking, using a Business Capability Model to align strategy, architecture and delivery.
Dharmesh is particularly strong on why the old model is being overtaken. PEBT is concerned with how a bank stages the move.
Where the argument needs nuance
This is not because Dharmesh and I are pulling in different directions. We are looking at the same problem through slightly different lenses. Dharmesh leans deliberately into the future-state provocation. My own bias, shaped by years of working around real banking estates, is to keep asking how a bank gets there without creating the next generation of the same problem.
Take the idea of a second core. Dharmesh is right to warn that it can become another limb of the monster if it is allowed to grow without discipline. If teams use it to justify shortcut integrations, unclear ownership, duplicated logic and another collection of exceptions, it does not resolve the problem. It gives the old problem a newer interface.
But that warning should not become a rejection of multi-core thinking. In the right architecture, a second core, thin core or specialised ledger can form a valid part of the future state. The important question is not how many cores the bank has. It is whether those cores have clear purposes, clean capability boundaries, explicit contracts, controlled event flows and governance strong enough to stop new sprawl from creeping in through the side door.
Some banks may establish a second core to support a digital proposition. Some may move towards a thinner central core surrounded by platform capabilities. Some may operate specialised cores for different books, markets or customer segments. Others may progressively extract product logic, pricing, workflow, servicing, data and decisioning until the old core becomes smaller, simpler and less strategically dominant.
The same qualification applies to tokenised deposits and intelligent ledgers. Banks should not ignore these developments or assume they can be dealt with at some undefined point in the future. But recognising their significance does not mean every institution must immediately rebuild itself around a single architectural thesis.
For use cases such as digital asset settlement, programmable treasury, conditional marketplace payments and continuous liquidity movement, tokenised deposits may become relevant quickly. For other parts of banking, the more immediate value may come from modern ledgers, event-driven orchestration, cleaner data, stronger APIs and modular platform capabilities.
A regional retail bank may rationally decide that tokenised deposits are not its first investment priority. What would be irresponsible is failing to understand the direction of travel or making architecture decisions that remove the bank’s ability to participate later.
The future may also arrive unevenly. It may move faster in wholesale banking, treasury and capital markets than in everyday retail accounts. Regulation, customer consent, identity, liability, fraud controls, reversibility, liquidity management and operational resilience will all shape the pace of adoption.
Boards should therefore resist turning plausible future scenarios into fixed-date predictions. The point is not that one precise version of the future will arrive on one precise date. The point is that the direction of travel is now clear enough that banks can no longer justify architecture decisions based solely on yesterday’s transaction model.
That is where Dharmesh’s argument and PEBT meet. His series exposes why the Franken-core cannot simply be patched into the next era. The next challenge is turning that recognition into an executable transformation agenda.
From provocation to execution
The uncomfortable consequence of accepting Dharmesh’s diagnosis is that bank leadership can no longer hide behind the complexity of the problem. Once the Franken-core is understood as an accumulation of products, processes, integrations, data structures, operating practices and human dependencies, it becomes clear that neither another tactical upgrade nor another abstraction layer will be enough.
Dharmesh is right that banks need a plan. But a plan in this context cannot simply be a target architecture, a vendor shortlist and a series of milestones spread across a five-year roadmap. Banks have produced plenty of those. Some have been beautifully presented, meticulously governed and almost entirely disconnected from how the institution makes money, serves customers and operates day to day.
A credible plan must explain how the bank moves from the institution it is today to the institution it needs to become, while continuing to process payments, protect customer balances, meet regulatory obligations and keep thousands of interconnected activities running throughout the transformation.
It must describe not only the destination, but the difficult and often politically inconvenient journey between the current and future states.
This is the execution gap that Rip Out the Core sets out to address.
Despite its deliberately provocative title, the book does not argue that every bank should switch off its existing core and replace it with a more fashionable piece of technology. The industry has already experienced enough large-scale replacement programmes to understand that changing the central machinery of a bank through a single high-risk event is rarely as simple as it appears in the early programme presentations.
The idea behind the title is more fundamental. Before banks can rip out the core technology, they must rip out the assumption that the core has to remain at the centre of every product, process, decision and customer interaction.
For decades, banks have allowed the limitations of their existing platforms to shape the businesses they operate. Products are designed around what old product processors can support. Customer journeys are adjusted to accommodate batch windows and ageing workflows. Data is duplicated because underlying systems cannot share it cleanly. Manual controls are introduced to compensate for system limitations and gradually become embedded in the operating model.
Over time, the bank stops designing the business it wants and begins designing the business its systems will tolerate.
That is the real strategic danger of the Franken-core. Its impact is not limited to technology cost or operational risk. It gradually removes freedom of movement from the institution. It makes products slower to launch, partnerships harder to establish, customer journeys more difficult to change and innovation more expensive to scale.
When an attractive opportunity appears, the first question is no longer whether the bank should pursue it. The first question becomes whether the existing estate will allow it.
Starting with the future business
A credible burial plan cannot begin with a core system selection. It has to begin by defining what the bank needs to become.
The Blueprint phase of PEBT connects transformation directly to business strategy. What markets does the bank intend to serve? Where does it genuinely want to differentiate? Which customer relationships does it need to own? Which services could increasingly be delivered through partners, platforms or intelligent agents? What must the bank become good at if programmable money, embedded distribution, tokenised assets and agentic AI develop in the directions Dharmesh describes?
These questions may sound obvious, but they are often skipped. Banks recognise that the existing core has become a problem and move almost immediately into a discussion about replacement platforms. Vendors are invited, requirements are collected and demonstrations begin before the leadership team has agreed what kind of bank the new technology is supposed to enable.
The result may be a technically modern platform, but it can still reproduce the same institution. The products remain broadly the same. The operating model remains broadly the same. The existing organisational boundaries are encoded into newer workflows, and the same complexity begins accumulating around a new centre.
The monster receives a transplant, but the underlying condition remains untreated.
The future state should therefore be expressed first through the Business Capabilities the bank will require, rather than the systems it expects to buy. A Business Capability describes what the institution must be able to do independently of the organisation, application or supplier currently providing it.
This shift can appear academic, but it changes the transformation conversation. Instead of asking how a particular system should be replaced, or what domain first, the bank can ask how a particular capability should be provided in the future.
Should it be built because it creates meaningful differentiation? Should it be bought as a specialised product? Should it be consumed from a partner as a service? Can it remain in the existing estate for longer without constraining the wider transformation? Does the existing business need to be migrated, or can part of the old product book be allowed to run off naturally?
These questions create choices that an application-led modernisation does not. They also make it possible to dismantle the Franken-core progressively, rather than treating it as an indivisible object that must be removed through a single programme.
The reality is that the Franken-core is no longer one system. It is a network of product processors, ledgers, integration platforms, workflow engines, data stores, reporting solutions, operational procedures and undocumented dependencies. Attempting to replace all of that in one movement is not evidence of ambition. It is usually evidence that the scale of the problem has not been properly understood.
A capability-led approach allows the bank to identify which parts of the estate create the greatest strategic constraint, operational risk or cost and then address them in a deliberate sequence. Some capabilities may be introduced through a greenfield platform. Some may coexist with legacy for several years. Others may require products, customers and balances to be migrated before the old capability can be switched off.
There is no single migration pattern that will be correct for every part of the bank.
Governing coexistence and removal
A second core can provide a practical route towards new products, markets, tokenised deposits or programmable forms of money without forcing the bank to wait for the complete transformation of its existing estate. In the right context, it can create space to learn, build and generate value while the old core continues to provide stability for products that are not yet ready to move.
The danger is not the existence of a second core. The danger is introducing one without clarity about its architectural role and long-term purpose.
Is it intended to become the destination for all new products, or only for a specialised set of propositions? Is it a permanent component of a multi-core architecture, or a transitional platform that will eventually absorb part of the old estate? Which customers and balances should move? What business or operational conditions will trigger that movement? How will servicing, financial reporting, liquidity management and regulatory obligations work while the environments coexist?
Without answers, coexistence becomes accumulation. The old core remains, the new core grows and an orchestration layer is introduced to make them appear consistent. Data must be reconciled between the two. Customer service processes must span both. Regulatory reporting must combine information from multiple sources. Temporary integrations become permanent.
The monster does not disappear. It grows another organ, or a new conjoined twin.
PEBT treats coexistence as an intentional architectural state rather than an undefined period between old and new. That means naming systems of record, defining ownership of data and business logic, establishing explicit contracts between capabilities and being clear about how information and events move across the estate.
It also means defining the conditions under which legacy capabilities will be retired.
This is frequently neglected. Transformation programmes are normally very clear about what will be introduced, but far less precise about what will be removed. The implementation of a new platform becomes the major milestone, while the migration, simplification and decommissioning work that creates the economic and architectural benefit is pushed into later phases or future budgets.
A new platform that carries no meaningful volume has not transformed the bank. A second core running beside an untouched legacy estate may be a valuable first step, but it is not the end state. An API layer may make the old estate easier to access, but it does not remove the complexity beneath it.
The Franken-core only begins to shrink when products, customers, volumes, processes and business logic actually move away from it.
Coexistence also carries a financial and control cost. The bank may have to fund duplicated platforms, reconciliation processes, operational teams, reporting flows and control environments. These costs are sometimes described as temporary, but without explicit migration triggers they can become embedded in the permanent operating model.
The business case must therefore extend beyond the launch of the new platform. It should be based on meaningful business movement and the eventual removal of legacy cost, risk and complexity.
This has direct consequences for how boards govern transformation. Progress cannot be measured only through delivery milestones, programme budgets and the implementation of new technology. Leadership teams need to see whether the strategic balance of the bank is changing.
How much new business is being originated on the target architecture? How quickly can the bank introduce or alter products and pricing? How many legacy interfaces, product variants and manual controls have been retired? How much business logic has been removed from the old estate? Is the bank becoming less dependent on scarce knowledge held by a shrinking number of specialists? Are operating economics and resilience improving as activity moves?
These measures reveal whether the monster is genuinely being dismantled rather than merely hidden behind newer technology.
Defining the future core
Dharmesh’s intelligent ledger and my description of a smaller, sharper core are not opposing ideas. Both challenge the bloated role that traditional cores have gradually acquired.
The core should not attempt to be the entire bank. It should provide a compact, deterministic and explainable financial nucleus responsible for agreements, balances, postings and the events that change them. It should produce reliable financial facts and expose governed points through which products, platforms, partners and eventually AI agents can act.
Some logic does belong close to the ledger. Deterministic financial rules, settlement conditions, accounting treatments and controls that directly affect the integrity of the financial record must remain precise, transparent and enforceable.
Product design, pricing strategy, customer journeys, workflow, servicing and broader decisioning should remain independently adaptable around it. The objective is to keep financial truth close to the ledger without allowing every changing aspect of the bank to become trapped inside it.
This distinction becomes increasingly important as agentic AI develops. AI agents may discover products, compare offers, negotiate conditions, initiate payments and manage liquidity on behalf of customers or the bank. But the fact that more activity becomes intelligent and autonomous does not reduce the need for certainty at the centre. It increases it.
Banks will still need to explain why money moved, which instruction authorised it, which agreement governed it and which controls were applied. Boards will remain accountable, and regulators will continue to demand provenance, transparency and control.
Allowing opaque intelligence to disappear into the financial record would simply replace undocumented legacy code with undocumented model behaviour. The technology would be newer, but the governance failure would be remarkably familiar.
The aim of becoming coreless is therefore not to create a bank without a core. It is to create a bank in which the core no longer dictates the structure, speed and ambition of the entire institution. The surrounding capabilities can change, new forms of value can be introduced, partners can be connected and intelligent agents can act, while the financial nucleus remains controlled and explainable.
The burial plan belongs in the boardroom
This cannot remain an IT programme.
Technology leaders can design platforms, establish architectural principles and manage engineering execution, but they cannot independently simplify the product portfolio, change the operating model or decide where the bank should compete. Those are business decisions, and many will require difficult trade-offs.
A product that still generates revenue may need to be closed because the cost and complexity it creates are no longer defensible. A customer segment may need to migrate earlier than some business leaders would prefer. Capabilities historically built internally may need to be consumed from partners, while others may require greater investment because they create real strategic differentiation.
The CIO and CTO may carry much of the execution responsibility, but the chief executive and board must own the destination. Otherwise, the organisation will continue asking technology to simplify an institution that the business refuses to change.
The hardest part of the transformation will not be selecting technology. It will be sustaining executive commitment while the bank passes through an extended period in which old and new must coexist.
Benefits will not arrive evenly. Some investments will create strategic optionality rather than immediate cost savings. Decommissioning may occur several years after the capability enabling it has been delivered. This makes transformation vulnerable to annual budgeting, changing leadership priorities and the understandable temptation to declare victory when the new platform goes live.
But going live is not the same as changing the bank.
Boards need to maintain focus on the destination, the migration of real business and the eventual removal of what the new architecture was intended to replace. Without that commitment, a transformation programme can deliver every platform it promised and still leave the bank with a larger, more expensive and more complicated estate than the one with which it started.
The next part of the conversation
Dharmesh has given the industry an important and necessary provocation. He has exposed how the Franken-core was created, why it will struggle to support what is coming and why another generation of tactical extensions will not resolve the underlying problem.
His articles deserve to be discussed in bank leadership teams because they challenge the comfortable belief that legacy can always be dealt with later.
The next question is practical. How does a bank turn its strategy into a future Business Capability Model? How does it define an architecture that does not recreate the dependencies of the past? How does it decide what to build, buy or consume? How does it choose between greenfield development, progressive coexistence and migration? How does it govern new boundaries, manage partners, move customers and eventually remove the parts of the old estate that are no longer required?
That is the execution problem addressed by PEBT.
Dharmesh has described why the monster must eventually be buried. Rip Out the Core is about organising the burial while the bank remains open for business.
The two ideas belong together. Provocation without execution may create an important industry conversation, but it will not change the bank. Execution without provocation is equally dangerous, because it can produce another carefully governed technology programme that gradually loses sight of why it was started.
Banks need the urgency to accept that the existing model is reaching its limits, but also the discipline to dismantle it progressively without creating the next generation of the same problem.
The monster was built through decades of rational decisions that accumulated into something no one deliberately designed. Burying it will require persistence, but this time with a clear destination, an executable plan and the discipline to avoid rebuilding it along the way.
Join us for the Helsinki launch of Rip Out the Core: A DIY Guide to Platform-Enabled Banking Transformation:
When: Thursday 13 August 2026, 16:30 to 19:00 Where: Maria 01, Helsinki Hosted by Digital Banking Academy & Fintech Farm. Spaces are limited, so sign up early via this link.
