Core banking programs rarely die at go-live. They slow down instead, and they do it gradually enough that nobody calls it failure until the third replan.
The first year usually looks good. Architecture gets designed, a vendor gets selected, environments come up, a pilot proves the thing works, and the board updates are a pleasure to write. Then, somewhere around month fifteen or sixteen, the program starts missing dates it set for itself. Not by much at first. A sprint here, a release window there. Nobody can name the decision that caused it, because there wasn’t one.
The explanation offered is almost always technical, or it is about the vendor. Sometimes that is right. More often the architecture never changed at all. The real shift was in the monthly workload placed on the bank, and whether it could keep up.
IBM’s 2026 report found that 94% of banking modernization projects finish late. Delays are now the norm, not a surprise risk. If your plan assumes you’ll be on time, it’s wrong from day one.
Year One Is Architecture. Year Two Is Absorption
In Year 1, a small team works in isolation: designers design, engineers build, and business experts help when needed. The rest of the bank is unaffected, progress is clear, and the team moves fast on its own.
Year 2 is when the work leaves the program and enters the institution. Reconciliation has to run in parallel. Controls must be tested, then evidenced, then re-evidenced when someone changes a field. Operations staff have to learn a second way of doing a task they already perform eighty times a day, without abandoning the first way, because the first way is still live and still serving customers.
Velocity stops belonging to the program at that point. It belongs to the bank. And the bank has a throughput that was fixed years before anyone opened a vendor pitch deck.
Three Queues Set Your Real Pace
Stalled programs are almost never stuck in the building phase. They are stuck in the waiting phases.
First, the approval queue: Risk, compliance, model validation, third-party oversight, and change advisory. Every release passes some subset of these, and under elevated supervisory attention the subset grows. Teams measure sprint length and report it as delivery speed, which is a comfortable number but the wrong one. The number that governs the program is the gap between “ready” and “approved.” Very few banks have anyone who owns that gap.
Second, the reconciliation queue. Parallel running is a safety measure, and it is also a second full-time job. Two systems produce two answers; every difference has to be explained rather than merely noticed, and the people qualified to explain them are usually the same people the program needs for design decisions. Programs start borrowing from their own future at this point, quietly, and months before anyone notices the debt.
Third, and this is the one that surprises people: the definition queue. At some point in the second year a program discovers that two departments have spent a decade using different definitions of the same thing. What counts as an active account? Which of the three dates is the effective date? Whether a suspended relationship is still a relationship and whether it should appear in a count that a regulator sees. These arguments were never settled because they never needed settling. Manual handling absorbed them. Someone in operations knew which rule applied on a Tuesday, and the exception report was short enough that nobody asked why. A new system will not absorb any of it, so all of it surfaces at once, and it gets resolved at the speed of governance rather than the speed of engineering. Which is to say slowly, and in meetings.
None of that is a technology problem. All of it sets the delivery date.
What is the TSB Bank Migration?
In April 2018, TSB Bank moved 5.2 million customer accounts from Lloyds Banking Group infrastructure to a new platform called Proteo4UK, built by its new owner, Banco Sabadell. The disastrous rollout locked millions out of online banking, exposed other users’ data, and cost over £300 million.
What TSB Actually Demonstrated?
People often use TSB’s 2018 migration as a warning against “big-bang” tech cutovers. But that misses the bigger lesson: the project was almost certainly doomed long before launch day.
Source: Financial Conduct Authority
TSB moved to a new platform in April 2018. The data migrated fine. The platform did not hold. A significant proportion of the bank’s 5.2 million customers were affected, and it took until December to get back to business as usual. The Financial Conduct Authority and the Prudential Regulation Authority fined the bank £48.65 million between them, and that figure already reflects a 30% settlement discount. A further £32.7 million went to customers in redress. TSB posted the largest net loss of customers of any participant in the Current Account Switch Service across the second, third, and fourth quarters of that year.
Slaughter and May, in the independent review, called the scale and pace unprecedented in UK retail banking and found performance testing insufficient to surface the problems before go-live. Reporting on that review notes the program leaned on more than seventy third-party suppliers, and that the board approved the cutover on evidence indicating readiness.
The board was not reckless. It was shown something that looked like readiness. What it did not have in front of it was any measure of whether the organisation could take what was about to happen, which is a different question from whether the software worked, and a much harder one to put on a slide.
Replace or Wrap Does Not Answer This
The industry has settled into a binary. Replace the core or wrap it in APIs and defer the decision. Both are real options and the argument is worth having. Neither one touches absorption capacity. Replacement concentrates change into a stretch of elevated operational risk. Wrapping spreads it thinner, though the legacy processing underneath keeps running and the wrapper turns into a dependency of its own soon enough.
The middle path is gaining ground: run a modern core beside the legacy one for a defined set of products or customers. IDC projects roughly 40% of global banks pursuing this kind of sidecar approach by 2026, rising to somewhere between 70% and 80% by 2028. It builds competence without a single cutover event, and for most mid-market institutions it is probably the right instinct.
In the short term it is also more change to absorb, not less. Two cores means two operating models, two control sets, and two versions of the truth to reconcile every night. It works when a migration path is defined at the outset. Without one, the parallel core stops being a transition and becomes a permanent second system, which is the thing the program existed to prevent.
Measuring Absorption Before You Commit
The useful part: this is measurable, and it is measurable with data the bank already holds. Five questions, answered honestly, before a multi-year program gets approved.
- How many changes reached production last year, and how many were rolled back? Demonstrated throughput, demonstrated quality. A plan assuming three times either number is a wish with a Gantt chart attached.
- What is the median elapsed time from change request to production, and how much of that time was the item in queue rather than being worked on? If most of it is queued, adding delivery capacity will do nothing for you.
- How many people can approve a change, and how many of those are also needed for design decisions? Heavy overlap means the program will compete with itself for the same calendars.
- How many operational exceptions does the current process throw off each month, and who clears them? Exceptions are undocumented business logic. Each one becomes a rule before it can be automated.
- What else is already in flight? Regulatory remediation, an audit response, a cloud migration running on a separate budget line. Same approvers, same operations staff.
Uncomfortable answers are useful answers, and month three is a considerably cheaper place to have them than month nineteen. The fix is rarely a different platform. It is a narrower first domain, a longer runway, and real investment in approval throughput before the program starts depending on it.
To be fair to the technology argument, there are cases where the core genuinely is the blocker. Some legacy platforms cannot support event-driven extraction under load, and no amount of governance maturity changes that. Those cases exist. They are just a lot less common than the number of programs currently blaming them.
Conclusion: Capacity Comes Before Architecture
Banks evaluate platforms well. Selection is rigorous, references get called, and architecture gets picked over by people who know what they are looking at. The assessment that rarely gets the same treatment is whether the institution can take on the volume of change the plan quietly assumes it can.
The programs that hold their dates tend to look slower at the start. Narrower first domain, more time spent on definitions nobody finds interesting, an unglamorous quarter spent fixing the approval process before anything depended on it. They finish closer to the plan because they were sized against what the organization could actually do rather than what it hoped to do.
At Krasan Consulting, an assessment along these lines is often where an engagement begins, ahead of any recommendation about platforms. It usually changes the sequence. The sequence is usually what decides it.
Frequently Asked Questions
Why do core banking modernization projects usually run late?
Delivery speed in year two is governed by the institution’s approval, reconciliation, and data-governance throughput rather than by the engineering team. IBM’s 2026 Global Outlook for Banking and Financial Markets found 94% of modernization projects exceed their original timelines.
Is a parallel or sidecar core safer than full replacement?
A parallel or sidecar deployment is safer than a full replacement. It lowers cutover risk and builds operational competence gradually, and IDC expects 40% of global banks to use the approach by 2026. It also raises short-term change load, and without a migration path defined at the start, it can settle into a permanent second system.
What was the real lesson of the TSB migration?
The problems were present before go-live. Testing did not surface them, the program carried heavy third-party dependency, and the board approved on evidence that looked like readiness. TSB was fined £48.65 million and paid £32.7 million in customer redress.
How do you measure whether an organization can absorb a modernization program?
With operational data already on hand: production change volume and rollback rate, median request-to-production time split into queue and work, the size and overlap of the approver pool, monthly exception volume, and whatever else is already competing for the same people.
References
1. IBM Institute for Business Value. 2026 Global Outlook for Banking and Financial Markets. https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/2026-banking-financial-markets-outlook
2. Financial Conduct Authority. TSB fined £48.65m for operational resilience failings. Press release, December 2022. https://www.fca.org.uk/news/press-releases/tsb-fined-48m-operational-resilience-failings
3. Bank of England / Prudential Regulation Authority. TSB fined for operational resilience failings. News release, December 2022. https://www.bankofengland.co.uk/news/2022/december/tsb-fined-for-operational-resilience-failings
4. Cheiffetz, A. Core Banking Modernization: Why Replace or Wrap Is the Wrong Question. BizTech Magazine, 29 June 2026. https://biztechmagazine.com/article/2026/06/core-banking-modernization-why-replace-or-wrap-wrong-question
5. Everest Group. Core banking technology outlook 2026: modernization, intelligence, and the path forward. https://www.everestgrp.com/blogs/core-banking-technology-outlook-2026-modernization-intelligence-and-the-path-forward/
6. Deloitte Insights. 2026 Banking and Capital Markets Outlook. https://www.deloitte.com/us/en/insights/industry/financial-services/financial-services-industry-outlooks/banking-industry-outlook.html
