Core Banking Modernization, Progressively: Build on Top of What Runs

For many banks, the question is no longer whether to modernize the core. It is how to do it without staking the institution on a single cutover, and without staying on systems that hold everything else back.

Supervisors and analysts point to a third way: smaller changes, made more often. The safest place to make them is on top of what already runs, so modernization doesn’t have to start with replacement.

What is core banking modernization?

Core banking modernization is the work of changing the systems that hold a bank’s accounts, balances, and products, and the way its people and processes work with them, so the bank can do what it can’t today. A modern core banking system has to open accounts digitally, post instant payments as they happen, decide on credit faster, launch new deposit products, and give risk models and AI live data, not last night’s. McKinsey describes the shift as moving from systems built to record what happened to systems that help decide what should happen next.¹

There is more than one way to get there. Financial institutions take one of four routes:

• Full replacement. Every product and customer moves to a new system, usually in a single cutover.
• One component at a time. Lending, deposits, or payments move separately, where the bank’s systems let them be pulled apart.
• A new system alongside the old. New products or customer segments launch on a new platform, and existing books move later, or never.
• Building on top of what runs. New capabilities launch above the existing systems, and pieces of the old estate retire over time. Done well, each existing system is connected once, so every new capability reuses the work.

All four modernize. What differs is what has to happen first, and how much risk lands on a single day.

Why are banks modernizing their cores now?

Because the demands on the core changed faster than the core did. Four pressures are now landing at the same time.

AI needs live data. AI needs one live picture of the bank to act well, and most banks can give it only last night’s batch, split across systems that were never designed to work together. Whether AI moves beyond pilots depends less on the model than on whether those systems can act while the transaction is still moving, a constraint McKinsey finds institutions often underestimate.¹

Instant payments don’t wait for batch cycles. Banks are adding instant rails, not choosing between them: the Richmond Fed found that 70 percent of RTP participants also hold FedNow membership.² On every one of them, a payment that settles in seconds has to be screened, approved, and posted in seconds too. Most cores were built to close the day overnight, so every new instant rail widens the gap between the rail’s clock and the ledger’s.

The provider’s roadmap sets the pace. When the core, and often the digital products built on it, come from one provider, the bank’s roadmap becomes the provider’s roadmap. Running that estate absorbs the budget meant to change it: McKinsey estimates that 60 to 80 percent of technology spending at many large banks still goes to maintaining and operating existing systems.¹ New capabilities wait for the provider’s next release, and anything it hasn’t planned becomes a custom request, priced on its terms until the contract comes up for renewal.

Regulators set outcomes, not architecture. In the US, interagency guidance from June 2023 expects rigorous oversight of every critical third party a bank relies on.³ Europe and the UK set similar bars, under DORA and the UK’s operational resilience rules.^4,5 Either way, a change that goes wrong stops being an IT problem, because an outage means an incident to report, a supervisor to answer to, and possibly a fine.

None of these rules prescribes an architecture. All of them make fragile change expensive.

Why does a full core replacement go wrong so often?

Because it concentrates years of work, and most of the risk, into one cutover. McKinsey’s 2026 analysis judges a big-bang replacement too risky for most institutions, large global banks above all.¹

In a 2022 review of more than 50 core banking transformations, McKinsey found that only about 30 percent managed to move all ledgers and products to a new system. It had also seen banks overspend by 100 percent, with timelines stretching by 50 to 100 percent.⁶

TSB’s 2018 migration in the UK shows that concentration at work. The data moved across successfully, but the new platform failed as soon as it went live, and because everything had moved at once, branch, telephone, online, and mobile banking all went down together. It took until December 2018 to return to business as usual, and regulators later fined the bank £48.65 million.⁷

Bank mergers bring the same cutover risk with every deal. When an acquired bank’s customers move onto the acquirer’s core, the conversion bill keeps growing after the deal is announced, and the roadmap stops while the conversion runs, as The Merger Tax Nobody Models shows.

A replacement also changes only the systems, so the people and processes around them must be rebuilt at the same time.

Replacement can still be the right call for some institutions. When everything changes at once, though, everything depends on one day going right.

Is keeping the legacy core the safe option?

Not on the evidence. Standing still can feel safe, because nothing visibly breaks, but the risk compounds quietly. The same McKinsey analysis describes legacy cores as the wall that new AI initiatives keep hitting.¹

Supervisors see the same risk. In the UK, the FCA’s 2021 review of technology change linked reliance on high levels of legacy technology to more failed and emergency changes.⁸

So the two familiar answers fail in opposite directions. Replacement puts everything on one cutover. Standing still lets risk build until something gives.

The supervisory record points to a third answer: smaller changes, made more often.

What is progressive modernization in core banking?

It means replacing one big cutover with a sequence of smaller changes, each live and proven before the next begins. People adopt each change as it arrives, not all at once over one weekend.

McKinsey’s 2026 analysis describes three progressive renewal patterns that leading banks use:¹

• Strangler fig. Wrap the existing core, move products to a new core step by step, and switch old components off.
• Segmented greenfield core. Run a new core for selected businesses, and move other books across later.
• Core renovation with heavy decoupling. Keep the existing core, and decouple products, pricing, and channels from it.

Two of the three still end on a new core, and for some banks that is the right destination. The difference is who decides the end state, and when. On a progressive path, that decision can wait until the first changes have proven themselves. Visa Consulting & Analytics puts the principle in one line: “Modernise progressively around business capabilities, not around systems alone.”⁹

That is the shift. Replacement isn’t the precondition for modernizing. A bank can start on what runs, and retire by choice, piece by piece.

What makes progressive core modernization work?

Mostly groundwork. Five things make each step safer, and one pattern keeps the ledger accurate while old and new run together.

• The dependencies are mapped first

  Every legacy estate carries integrations nobody wrote down, such as file transfers, scheduled jobs, and reports other teams rely on. Mapping them first keeps a retired component from taking something with it.

• Each system is connected once

  One integration per system, to a shared model of customer, account, and transaction, so every new capability reuses it. McKinsey’s 2026 playbook asks for the same groundwork.¹

• People work from one live picture

  During the transition, operators, approvers, and compliance teams shouldn’t check two systems for one answer. Working from one live picture of the bank, each change reaches their day-to-day work one capability at a time.

• Governance travels with the process

  Approvals, controls, and evidence belong to the process, not to each product. With every step recorded with its actor, timestamp, and decision, a new capability arrives already governed.

• Releases stay small and frequent

  Each is easier to test, undo, and explain to a supervisor. The FCA found that smaller, more frequent releases had higher change success rates.⁸

The real-time position and the general ledger stay in sync

New capabilities run in real time, while many cores still post in batches. One pattern keeps the two in sync:

1. 1Reserve. A temporary posting reserves the funds, and the real-time position updates straight away.
2. 2Confirm or reverse. The posting becomes final when the payment rail confirms, and is reversed if the rail rejects the payment, releasing the funds.
3. 3Post. The core takes the posting into the general ledger on its own cycle, so the real-time position and the general ledger agree.

What Is Banking Orchestration? follows the same pattern through a full payment, step by step.

What are the risks of progressive core modernization?

The progressive path has risks of its own. Each one also has a known way to keep it in check.

• Two systems of record at once. While old and new run side by side, balances and positions can drift apart, and staff end up checking both. Reconciliation designed in from the start keeps them aligned, with one agreed system of record for each piece of data.
• Programs that never finish. A sequence of small steps can lose momentum, and supervisors penalize stalled change as well as failed change. In July 2024, the OCC and the Federal Reserve fined Citi a combined $135.6 million because its remediation of data management weaknesses, which they had ordered in 2020, was not progressing fast enough.¹⁰ An owner, a date, and a clear statement of what each step retires keep the sequence moving.
• More vendors to oversee. Each new provider adds third-party risk that US supervisors expect the bank to oversee.³ Connecting each provider once, to one shared model and behind its own contract, keeps its failures contained where it connects, and makes it easier to replace.

The risks of the progressive path are known, and each one can be managed. The risk of standing still only grows.

Where should a bank start with core banking modernization?

With one capability the business needs now, not with the system. That might be a digital account customers can open on their phone, instant payments, a faster credit decision, or a deposit product that attracts new funding. Instant payments are often the most time-sensitive, with more than 1,800 financial institutions already live on FedNow.¹¹

The work begins by naming what the core stops the bank from doing today, and choosing a first product where fixing that would show, to customers and staff. McKinsey’s road map follows the same order, aiming for visible value within 12 to 24 months.¹ If the first step connects each system once, every capability after it can reuse those connections.

Timing matters as well, because switching core providers is rare. In the American Bankers Association’s 2025 survey, 35% of banks said they were dissatisfied with their core processor, yet only 1 in 5 expected to switch.¹² A bank that starts before its next contract renewal negotiates with options in hand.

How does XYB approach core banking modernization?

The Modernizing path of Adaptive Digital Banking is built for this sequence: start without replacing what runs your bank. A financial institution launches the Capabilities its customers ask for, Hold, Move, Lend, and Grow, above the systems it already has, and retires pieces of the old estate later, one at a time, when it decides. That is the Deploy, Expand, Modernize path, with 10 weeks to first production value. Commercial banking teams start the same way, with Faster Payables in the Commercial Treasury Solution.

Both run on banking orchestration, which runs a bank’s systems, people, and processes as one operation. What Is Banking Orchestration? explains how it works.

Frequently asked questions

Sources cited

1. McKinsey & Company. Core banking in the age of AI: Crafting intelligent financial engines, 27 August 2026.
2. Federal Reserve Bank of Richmond. FedNow and the Development of U.S. Fast Payments, Economic Brief No. 26-28, August 2026.
3. Federal Register. Interagency Guidance on Third-Party Relationships: Risk Management, 9 June 2023.
4. European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), applied from 17 January 2025.
5. Prudential Regulation Authority. SS1/21, Operational resilience: Impact tolerances for important business services, March 2021, with FCA PS21/3; firms within impact tolerances by 31 March 2025.
6. McKinsey & Company. How to get a core banking transformation right: Eight mistakes to avoid, February 2022.
7. Bank of England. TSB fined £48.65m for operational resilience failings, 20 December 2022.
8. Financial Conduct Authority. Implementing Technology Change, multi-firm review, 5 February 2021.
9. Visa Consulting & Analytics. Digital Behaviour, Legacy Backbone: The infrastructure modernisation imperative for Baltic banking and payments, whitepaper, September 2026.
10. Baird Holm LLP. Citigroup Fined $136 Million, Totaling $536 Million Since 2020, July 2024.
11. Federal Reserve Financial Services. Soaring volume, participation mark three years of the FedNow Service, 15 July 2026.
12. American Bankers Association. ABA Survey: 53% of Banks are Satisfied with Their Core Platform Provider, 18 February 2025.