Image © Adobe Images
A bank's core is the ledger that never sleeps. Every withdrawal, loan, and card swipe runs through it, yet most of these systems were built decades before mobile banking existed.
By 2026, the gap between what customers expect and what the back end can deliver has turned core banking into a board-level problem, not just an IT one. Cloud-native rivals move faster, regulators move slower, and somewhere in between sits every CIO with a mainframe upgrade on the calendar.
Why this is suddenly urgent
That gap shows up in the numbers banks would rather not publish. Insufficient modularity in legacy systems is already hurting business strategy at a majority of financial institutions, and the modernisation of the core banking system underneath day-to-day operations is no longer optional — it's the difference between shipping a feature in weeks or in years.
Real-time payments make the point sharply: only a small slice of US banks both send and receive them, while PayPal offers it as the default.
Customers notice: roughly three in ten say they've switched providers over a poor digital experience.
So why now? Three pressures collided at once. AI adoption needs clean, API-accessible data — something a 1980s COBOL core simply won't hand over without a fight.
Real-time payment rails (FedNow, the EU's instant payments regulation) demand always-on processing, not nightly batch windows.
And talent that can maintain forty-year-old systems is retiring faster than it's being replaced. None of this is new exactly, but 2026 is the year it stopped being theoretical for a lot of institutions.
The market in 2026: who's building what
The core banking software market sits north of $19 billion globally and keeps climbing at a brisk pace, with North America holding the largest regional share. That money is going somewhere specific.
Cloud-native challengers have stopped being experiments. Mambu, founded in Berlin, now counts N26 and ABN AMRO among its SaaS core customers. Thought Machine's Vault Core runs smart-contract-style product logic at Lloyds Banking Group and Standard Chartered. 10x Banking — started by a former Barclays CEO with the explicit goal of killing off legacy cores — powers Chase UK and Westpac. Visa bought Pismo to get a foothold in Latin American cloud cores, particularly strong in Brazil.
Incumbent vendors are racing to catch up. Temenos still runs more deployments worldwide than anyone, but it now ships a SaaS path alongside Transact. Fiserv pushed out CoreAdvance and is quietly sunsetting older platforms. FIS and Jack Henry followed with similar nudges toward their cloud-ready modules. Oracle FLEXCUBE and Infosys Finacle remain dominant across the Middle East and Asia-Pacific, where regulatory comfort with on-prem control still runs deep.
What's actually being tested on the ground right now:
- AI-assisted code migration tools that read COBOL, map dependencies, and flag which modules are safe to touch first — Microsoft and several systems integrators are piloting this for mainframe estates
- Event-driven architectures replacing nightly batch jobs with real-time streaming, often built on Kafka, so a balance update happens the moment a transaction clears
- Composable "wrap and extend" layers that sit on top of a legacy core and expose modern APIs without ripping out the ledger underneath — a cheaper first step than a full rebuild
- Digital twins of the core, used to simulate a migration weekend before it actually happens, catching reconciliation breaks in a sandbox instead of in production
- Quantum-resistant cryptography pilots, prompted by regulation like the EU's DORA and the UK's Cyber Security and Resilience Bill, anticipating that today's encryption won't hold forever
A few tier-one banks have gone further and built greenfield cores for specific product lines — a digital-only brand, business banking, sometimes wealth management — while the legacy core keeps humming along underneath decades of retail deposits nobody wants to touch yet. It's a hedge, basically. Keep the engine running, build the new wing next door.
Picture a community bank CIO a few years back, scheduling the mainframe core upgrade for the third weekend of every quarter and hoping nothing broke before Monday morning. Today, that same CIO might push a configuration change to a cloud-native core on a random Tuesday at ten a.m., watch an automated test suite pass, and move straight on to the next ticket. The rails behind that shift are exactly what's being built and stress-tested across the industry right now.
Satisfaction with existing core providers, for what it's worth, isn't exactly glowing. Surveys of US banks and credit unions consistently put core providers near the bottom of vendor satisfaction rankings — which explains why even institutions with near-zero appetite for risk are quietly running proof-of-concepts on the side, just in case the board asks.
Picking a modernisation path: the real options
There isn't one correct route here, and any vendor who says otherwise is selling something. Banks generally choose among:
- Big bang migration — switch off the old core, switch on the new one over a single weekend. Fast, but the risk is catastrophic if something breaks; reverting mid-migration is brutally hard.
- Progressive migration — move customer segments or product lines one at a time, running old and new in parallel until the legacy core is empty. Slower, safer, more expensive to run two systems at once.
- Greenfield buildout — stand up a new core for new products only, leaving the legacy core to manage existing accounts until they naturally run off. Low risk, but it delays the real benefit for years.
How do you choose? Honestly, it depends on appetite for risk and how much technical debt is already baked into the existing stack.
What actually moves the needle
Forget the slide decks for a second. Banks that pull off modernization without a six-month outage tend to share a few habits.
Start with the data, not the interface
A shiny new mobile app on top of a broken ledger fixes nothing. Map every dependency the core has — fraud engines, AML checks, the general ledger, third-party integrations — before writing a line of migration code. Skip this step and you'll find out about the missing dependency during a live cutover. Not fun.
Treat compliance as architecture, not paperwork
DORA in the EU and similar resilience rules elsewhere aren't just checklists anymore. They shape how a system has to be built: resilient by design, auditable by default, recoverable within hours rather than days. Bake this in early, because retrofitting compliance into a finished system costs more than building it in from day one.
Choose modularity over a monolith, even with a familiar vendor
A modular, API-first core lets a bank swap a lending engine without touching deposits. That flexibility matters more in 2026 than brand loyalty to a legacy provider ever will.
Don't underestimate the talent question
The people who understand a forty-year-old COBOL core are mostly near retirement. Pair them with engineers learning the new stack before that institutional knowledge walks out the door. AI-assisted code analysis helps here too — it can't replace the judgment, but it speeds up the grunt work of mapping what a given module actually does.
Run the numbers before promising savings
Modernisation is sold on cost reduction, and it can deliver that — but rarely in year one. Running parallel systems during a progressive migration costs more in the short term. Budget for that honestly, instead of pretending the savings start immediately.
What success looks like in practice
A handful of patterns separate the modernisation projects banks talk about proudly from the ones quietly buried in a postmortem:
- Customer-facing changes ship in weeks, not quarterly release cycles
- New product launches don't require touching the core's underlying ledger logic
- Fraud detection runs on live transaction streams, not overnight batch reports
- Regulatory reporting pulls from one source of truth instead of three reconciled spreadsheets
- Developers can actually find people who know how the system works — internally or through a delivery partner
Sounds simple written out like that. Getting there usually isn't. The difference between the banks that get there and the ones still stuck three years into a "modernisation roadmap" often comes down to one unglamorous thing: whether leadership treated this as an engineering project with a deadline, or a perpetual transformation initiative with no deadline at all. The first kind ships. The second kind funds consultants indefinitely.
A note on vendor lock-in
One thing that gets underestimated: switching from one rigid legacy core to one rigid cloud vendor isn't modernisation, it's just relocation. The real win comes from API-first, composable architecture that lets a bank swap individual components — a lending engine here, a fraud module there — without re-platforming everything every five years. Ask any vendor pitching a "modern core" how easy it actually is to leave them later. The honest ones will tell you straight.
Where this is heading
The trend lines all point the same direction: open banking, hyperpersonalized products, real-time fraud detection — none of these run well on a rigid, batch-driven core. Expect modernisation to keep accelerating rather than slow down, with AI-assisted development chipping away at the cost and time it used to take. The constraint isn't really technology anymore. It's the organisational appetite for risk and how much a bank is willing to spend now to stop paying interest on technical debt later.
Worth asking yourself, if you're inside one of these institutions: is the core banking system the thing holding the bank back, or is it the comfortable excuse everyone's stopped questioning? Sometimes those are the same problem wearing different names.
