Cloud-Native Core Banking: Why the Migration Wave Is Finally Accelerating

For most of the 2010s, cloud for banking meant putting the customer-facing app in AWS while keeping the actual ledger on a 1990s IBM mainframe in a basement in Canary Wharf. That arrangement is finally, substantively changing.

The drivers are familiar: the economics of cloud at scale, the talent drain from legacy stack maintenance, and growing pressure from regulators who want resilient, auditable, and rapidly updatable systems.

The platform vendors making it possible

Thought Machine's Vault, Mambu, and 10x Banking have spent the better part of a decade building cloud-native core platforms. The turning point came when Lloyds Banking Group partnered with Thought Machine to move its retail estate toward a cloud-native ledger — a UK tier-1 committing its core, rather than a side-brand experiment.

Each vendor occupies a distinct position. Vault is built around smart contracts that define products in code, which suits large banks wanting deep configurability. Mambu pioneered the SaaS model and wins on speed — lenders and SMB-focused banks can stand up products in weeks. 10x Banking, founded by former Barclays chief executive Antony Jenkins, powered Chase UK's entry into British retail banking, which remains the strongest proof that a greenfield bank on a modern core can scale to millions of customers.

Why the dam finally broke

Three pressures converged. The first is cost: mainframe capacity is priced in ways that punish growth, and the engineers who can safely change forty-year-old COBOL are retiring faster than they are being replaced. The second is change velocity — a legacy core ships changes quarterly through change-control boards; a cloud-native core ships daily. In a market where deposit pricing and product features move weekly, that is a commercial weapon, not an IT metric. The third is regulatory: guidance like the EBA's outsourcing guidelines and the UK's operational-resilience regime gave risk committees a defensible path to approve what they had been blocking for a decade.

The migration patterns that actually work

Almost nobody does a big-bang cutover any more — the industry has internalised the cautionary tales of weekend migrations gone wrong. Two patterns dominate. The greenfield "speedboat" launches a new brand or product line directly on the new core (Chase UK, Mox in Hong Kong) and migrates nothing at all initially. Progressive migration moves one product book at a time — typically starting with savings, the simplest ledger — while the mainframe keeps running everything else. Both approaches trade programme length for risk, and both depend on the composable architecture these platforms offer: rather than replacing everything in a single high-risk programme, banks can swap individual modules — savings, payments, lending — independently over time.

What regulators want to see

Supervisors are no longer asking whether the ledger can live in public cloud; they are asking how it is governed there. The recurring demands: a credible exit plan from the cloud provider, evidence that concentration risk is understood (most of these platforms run on AWS or GCP), data-residency clarity, and tested recovery within stated impact tolerances. In the EU, DORA folds all of this into a single enforceable regime, and core-banking programmes are now routinely scoped with DORA evidence requirements from day one.

The economics in practice

Published numbers are scarce, but practitioner estimates consistently put cloud-native cost-per-account at a fraction of mainframe equivalents once migration is amortised. The bigger prize is what finance directors call optionality: when launching a new savings product costs days of configuration rather than a six-month programme, the bank can compete on product in a way its legacy estate simply forbids. That, more than infrastructure savings, is what is funding the current wave of programmes.

What can still go wrong

The failure modes have shifted rather than disappeared. Data migration remains the graveyard of these programmes — decades of account records with undocumented edge cases do not map cleanly onto a new ledger, and reconciliation tooling deserves more budget than it ever gets. Scope creep is the second killer: programmes that try to fix every adjacent system at once (payments, channels, general ledger) inflate until they collapse under their own governance. And the talent question cuts both ways — banks need engineers who understand both the old world and the new, a combination the market prices accordingly.

There is also a quieter strategic risk: a bank that modernises its core but keeps its old operating model — annual planning, project-based funding, six-layer sign-off — has bought a Ferrari to sit in traffic. The banks getting full value from these platforms changed how they ship product, not just where the ledger runs.

For a step-by-step view of how these programmes are being sequenced, costed and de-risked this year, see our cloud core banking migration playbook for 2026.