TSB 2018: The Core-Banking Migration That Locked Out Millions of Customers
TSB's 2018 migration moved customer data successfully to Proteo4UK, but the new platform immediately suffered severe technical failures that disrupted banking for millions.
TSB wanted to leave its inherited Lloyds platform and move to Proteo4UK
After separating from Lloyds Banking Group and being acquired by Sabadell, TSB undertook a major program to move corporate systems, customer services, and customer data onto a new platform called Proteo4UK. The main migration event occurred over the weekend of April 20–22, 2018.[3] The business logic was compelling: operating on a group-owned platform promised greater control and lower long-term dependency. But the cutover concentrated years of design and testing risk into one weekend.
Core-banking migrations combine technical and institutional change
The bank was not simply copying rows between databases. It was changing service providers, infrastructure, interfaces, operating procedures, and the software through which customers accessed money.
The data migration succeeded, but the platform immediately failed operationally
The FCA and PRA later emphasized a crucial distinction: customer data migrated successfully, yet the new platform experienced technical failures immediately afterward.[1] Branch, telephone, online, and mobile banking were disrupted. All branches and a significant proportion of TSB’s 5.2 million customers were affected in the initial incident, and some problems persisted for months.
Data correctness is only one migration acceptance criterion
A migration can move every record accurately and still fail if authentication, capacity, middleware, payments, channels, or recovery procedures do not operate at production scale. Go-live criteria have to test service outcomes, not just row counts.
Regulators found weaknesses in testing, governance, and outsourcing oversight
The FCA’s final notice described a program heavily reliant on Sabadell IT subsidiaries and further external suppliers.[2] TSB retained responsibility for managing those outsourced risks. Regulators concluded that governance of the migration and operational-risk arrangements were insufficient for a program whose success was critical to continuity of banking services.
Outsourcing transfers work, not accountability
A bank can contract another organization to build and operate systems, but customers and regulators still look to the bank for continuity. Contracts therefore need measurable service obligations, transparent testing evidence, and escalation rights.
Independent reviewers saw capacity and configuration concerns after go-live
TSB brought IBM in after the incident, and the UK Parliament later published IBM’s early assessment of the problems.[4] The Treasury Committee also published contemporaneous correspondence and evidence from TSB and staff representatives documenting the disruption and concerns around the migration.[5] The need for emergency external expertise highlighted a common migration weakness: the same organization that designed the cutover may lack independent challenge during readiness decisions. Large go-lives benefit from technically empowered reviewers who can stop the migration if non-functional evidence is incomplete.
Non-functional requirements deserve veto power
Performance, resilience, failover, monitoring, and security are not secondary qualities for a bank. If they are unproven, functional feature completion should not be enough to authorize cutover.
The regulatory penalty focused on operational resilience rather than one bug
In 2022, the FCA and PRA fined TSB a combined £48.65 million, citing widespread and serious failings in operational risk management and governance.[1] TSB also paid substantial customer redress. The enforcement record matters because it rejects the comforting explanation that a complex migration simply had ‘teething problems.’ A regulated bank is expected to design and govern change so customers can continue accessing critical services.
A big-bang migration reduces the number of escape routes
When an institution moves most critical services together, rollback becomes harder once new transactions begin accumulating on the new platform. The old environment may no longer represent current truth. Safer strategies can include phased populations, parallel reconciliation, feature-level cutovers, and clear fallback points. Not every core system can be migrated gradually, but the architecture should maximize reversible checkpoints.
Customer support is part of migration resilience
During a banking outage, customers need to know balances, payment status, and whether repeated actions will create duplicates. Technical teams therefore need synchronized communications, branch procedures, call-center tooling, and incident status. If support channels depend on the same failing platform, uncertainty becomes another form of outage.
Why TSB 2018 belongs in software-failure history
TSB 2018 belongs in software history because it demonstrates that migration success cannot be defined as ‘the data moved.’ The database transfer worked, while the service built around that data failed at production scale. Testing, governance, outsourcing oversight, non-functional readiness, and recovery planning all contributed to the operational outcome. The enduring lesson is that core-banking migration is a service-continuity exercise before it is a data project. Go-live should occur only when the organization can prove the entire customer journey, resilience model, and rollback strategy under realistic load. Financial software also needs recovery objectives expressed in business terms: which obligations can be delayed, which positions must remain visible, which customer actions must still be possible, and how operators prove that replayed state has not duplicated or omitted transactions. These questions turn disaster recovery from an infrastructure exercise into a control system for legal and economic commitments. Another migration lesson is that exit criteria should be tied to customer-facing service levels rather than project milestones. A program can complete code delivery, data migration, and contractual acceptance while still lacking evidence that authentication, payments, mobile sessions, call-center tools, monitoring, and disaster recovery work together under production demand. A go-live board needs authority to delay launch when those integrated service tests remain weak, even if the technical migration window is expensive to move.
Works Cited
- 01
- 02FCA — Final Notice: TSB Bank plc fca.org.uk
- 03Bank of England/PRA — Final Notice to TSB Bank bankofengland.co.uk
- 04UK Parliament Treasury Committee — IBM Report on TSB IT Problems committees.parliament.uk
- 05UK Parliament Treasury Committee — Correspondence and Evidence on TSB IT Problems committees.parliament.uk
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.