How banks can innovate without replacing the core

Every few years an institution concludes that its core banking platform is the thing holding it back, and launches a replacement programme. Some succeed. Many run for years, consume the entire change budget, and deliver a system that does roughly what the old one did.

The uncomfortable observation is that the core is rarely the actual constraint. The constraint is usually the absence of a stable boundary in front of it.

The real bottleneck

Ask why a new product takes eighteen months and the answer is seldom "the ledger cannot represent it". It is that every new product requires a bespoke integration into a system nobody wants to touch, negotiated with a small team who are the only people who understand it, scheduled around a release train that runs quarterly.

That is a coupling and throughput problem. Replacing the core does not fix it — it just gives you a newer system to couple badly to.

Put a contract in front of it

The higher-leverage move is to define a stable, well-documented service boundary in front of the core: accounts, balances, payments, customers, expressed as your institution's domain rather than the vendor's schema. Product teams build against that contract. The core becomes an implementation detail behind it.

• New products integrate once, against a contract that does not change when the core does.
• The core team's work becomes a queue of well-specified capability requests instead of a series of bespoke negotiations.
• Replacement, if it ever happens, becomes an incremental migration behind a stable facade rather than a big-bang cutover.

A stable boundary buys you most of the benefit of a new core, at a fraction of the risk — and it is a prerequisite for replacement anyway.

Read paths and write paths are different problems

Most of what a modern experience needs from the core is reads: balances, transactions, product terms, customer detail. Most of the risk lives in writes. Separating them lets you move fast where it is safe and stay careful where it is not.

A read model fed by change events from the core can serve an app in milliseconds without adding load to the system of record. Writes continue to go through the core's own controls, at the core's own pace. This asymmetry is where a surprising amount of perceived "core slowness" actually disappears.

What good looks like after a year

You have not replaced anything. You have a documented domain API, a read model that serves customer-facing surfaces, an event stream the rest of the organisation can build on, and two or three products shipped against it by teams who never had to open the core.

If the replacement conversation comes back after that, it will be a far better conversation — grounded in a specific capability the core genuinely cannot provide, rather than a general sense that it is old.