When Replacing the System Is the Biggest Risk
A study of TSB Bank's 2018 migration from the public record: the decision at stake, the options a lender in that position has, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study: a public case, not an IOanyT client. TSB Bank was not an IOanyT client, and IOanyT had no part in the events described. Everything about TSB comes from the public record.
| Organisation type | A retail bank |
| Size band | Large: about 5.2 million customers |
| Region | United Kingdom |
| The decision at stake | How to move every customer from an old IT platform to a new one |
| The public outcome | The April 2018 migration failed. 225,492 complaints, £32.7 million in redress, a £48.65 million regulatory fine, and about eight months to return to business as usual |
| Why it matters to a mid-size lender | The same decision, on a smaller system, sits on many lenders’ board agendas every year |
2. The Business Problem, in the Buyer’s Words
“We all agree the loan system has to go. It was built twelve years ago, two people understand it, and the auditor is asking about software that is no longer supported. But every time we look at replacing it, someone mentions the bank that moved everyone in one weekend. So the item is carried forward to next year.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The board is caught between two risks. Keeping the system carries one. Replacing it carries another, and the replacement risk feels larger because it lands on a single day.
3. What We Found
Method. We went through the public record of system replacements and IT enforcement in financial services in India and the UK: regulators’ notices, company statements and press reports from 2018 to 2026.
What happened at TSB. In April 2018, TSB Bank moved its customers to a new IT platform, and the migration failed.
| What | Figure |
|---|---|
| Customers affected | ”A significant proportion of its 5.2 million customers” |
| Complaints received | 225,492 |
| Redress paid to customers | £32.7 million |
| Regulatory fine (December 2022) | £48.65 million |
| Time to return to business as usual | About eight months (December 2018) |
| Earlier reported total cost | £330 million, and 80,000 customers lost |
The regulators found that TSB had failed to manage its “IT outsourcing arrangements with its critical third-party supplier”. The work was done by a supplier. The bank was held responsible.
It is not only TSB. Fino Payments Bank in India reported “a temporary moderation in business volumes” in the quarter it replaced its core banking system, a replacement that went ahead as planned. When one group of more than 40 credit unions had to replace a core system its vendor was retiring, the work meant rebuilding more than 200 screens and more than 500 interfaces to other systems.
Standing still is not safe either. The RBI’s direction on IT governance, in force since April 2024, says regulated entities “shall avoid using outdated and unsupported hardware or software”. In April 2024 the RBI barred Kotak Mahindra Bank from taking new customers online and issuing new credit cards, over IT risk management. The restrictions lasted about ten months.
Our reading of why replacements fail. Three of these are our reasoning from the cases above. Only the fourth is the regulators’ own finding about TSB.
- Nobody has a written record of what the old system does. The rules are in the code, and the new system is built from memory and old documents.
- Everything moves at once. A single cutover leaves no way to stop part-way.
- There is no proof of parity: nobody can show, function by function, that the new system does what the old one did.
- The supplier is not overseen closely enough (the regulators’ finding).
What this record does not show. It does not show why TSB’s migration failed in terms of testing or specification; the regulators’ published finding is about supplier management. Nearly every named case is a bank, most are large, and the TSB case is from outside India. We found no public case of a mid-size NBFC, broker or insurer with this problem. We use the large cases as lessons and do not say mid-size firms have had the same events.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Keep the system and contain it | The system is stable, changes are rare, and it has a planned end date | The regulator’s direction on unsupported software; skills keep leaving; growth plans wait | Right only with a dated exit plan |
| Buy a packaged product and move on one date | The need is standard and a product covers it | Everything moves at once; custom rules must fit the product or be dropped | Usually right for core banking itself, which is not work we do |
| Rebuild the whole system and switch over on one date | The system is small and well documented | One date carries all the risk, and the new system is specified from memory | We would advise against this for an old, customised system |
| Replace it in stages, one module at a time | The system was built in-house and customised for years | Two systems run side by side for a time; the work takes longer on the calendar | Our recommendation for the systems around the core |
What we would have advised against: a single cutover of every customer and every function, and a supplier contract that left the bank without its own record of what the old system did.
5. Our Recommendation, and the Decision It Asks of the Board
For the systems a lender has built around its core (loan origination, collections, agent and branch portals, reporting): first write down what the old system does, from the system itself, then replace it in stages, one module at a time, while the old system keeps running.
The decision it asks of the board: approve a fixed-price assessment now, separately from any replacement budget. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops making one large bet every year and starts making small, checkable ones.
6. Benchmark: Where You Are Now, and Where You Should Be
These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| A written record of what the system does | The original specification, years out of date | Every function in scope has its own numbered line | The record is compared with the system |
| The largest single go-live | Every function and every customer, on one weekend | One module | The plan, stage by stage |
| The way back if a go-live fails | A second migration, done under pressure | The old system is still running, so a failed stage never reaches customers | Rehearsed before each stage |
| Evidence that new matches old | A test report against an incomplete list | Each old function linked to its replacement and compared | A traceability matrix for each module |
| Oversight of the supplier | Reports from the supplier about its own work | The firm holds the specification, the risk register and the matrix, and accepts each module | Signed acceptance for each module |
| The decision in front of the board | One large bet, deferred each year | One stage at a time, each approved on evidence | Board papers |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the system, the decision that keeps being deferred, and what it is holding up. You leave with a short written note of what we found.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This study is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. It produces a written specification of what the system does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. We never do a single cutover. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
8. What the Client Would Own
- The specification: a written record of what the old system does, portable to any supplier.
- The risk register: the unknowns, listed before any price is set.
- The traceability matrix: every old function linked to its replacement, with how it was checked.
- The code: the new modules are the client’s. No runtime or platform fee.
- The filled-in benchmark: each measure, where it started and where it stands.
9. What This Approach Does Not Cover
- IOanyT does not implement packaged core banking products.
- IOanyT does not state that it maintains or patches the old system while it is being replaced. The client’s current team or vendor keeps it running.
- Taking a plan to the regulator is the firm’s own job. Our assessment gives it the evidence to do so.
- This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a bank.
10. Sources
| Source | Used for |
|---|---|
| Bank of England, 20 December 2022 | TSB: customers, redress, fine, supplier finding, return to business as usual |
| FCA Final Notice, TSB Bank plc, 2022 | TSB: 225,492 complaints, 22 April 2018 to 7 April 2019 |
| IEEE Spectrum, 25 March 2019 | TSB: £330 million and 80,000 customers |
| Angel One, 16 April 2026 | Fino Payments Bank |
| A vendor’s case study | The credit union group |
| RBI Master Direction | The rule on unsupported software |
| TechCrunch, 24 April 2024; News On AIR | Kotak Mahindra Bank restrictions and their end |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The specification is yours to keep, whoever does the building.
Read the research notes on this issue
Fear of a failed system replacement
Research note 1
Lenders Do Not Fear Their Old Systems. They Fear One Weekend.
We reviewed the public record of system replacements in financial services: what lenders fear, what waiting costs in growth, and the benchmark we would set.
Research note 2
Before You Ask What a Replacement Costs, Ask What It Is Worth.
Three quotes to replace an old lending system, far apart. Why they differ, what they leave out, the ways to buy, and the benchmark for the budget decision.
Research note 3
"Nothing Will Be Lost" Is a Promise. A Benchmark Is Something You Can Check.
No one can honestly promise a new system does all the old one did. Here is the benchmark we would set before go-live, checked function by function.