The £330 Million Aftermath: How TSB's Core Banking Migration Failed

The April 2018 core banking migration at TSB Bank stands as one of the most instructive enterprise software failures in modern British financial history — not because TSB failed to test, but because its testing and assurance regime generated confidence that the production system could not justify.

TSB entered the final main migration event on April 20, 2018 after more than four years of planning, extensive testing, nine successful dress rehearsals, and a pilot involving over 1,600 employees. The customer data migration itself was completed successfully — every account was transferred to the penny. (TSB) What collapsed was not the data migration, but the new platform’s operational stability when exposed to the scale and conditions of live customer traffic.

For weeks, millions of customers were locked out of digital banking, businesses failed to make payroll, and some customers reportedly saw the account details of entirely different holders.

The Slaughter and May independent review documented what the assurance process failed to reveal: the two data centres supporting the new platform had been configured inconsistently in certain areas despite having been specified to be identical, and thousands of defects remained open at the moment of go-live. The incident ultimately generated £330.2 million in post-migration costs and foregone income and resulted in £48.65 million of regulatory penalties. CEO Paul Pester subsequently resigned in September 2018 amid sustained scrutiny of the crisis.

The cost was larger than the outage. The £330.2 million figure captures the post-migration service disruption, not the entire cost of the migration programme. TSB reported £417.3 million of operating expenses associated with delivering the migration programme itself. The distinction matters: the £330.2 million represents the financial aftermath of the failure, while the £417.3 million represents the cost of executing the programme.

What Was TSB Bank?

TSB Bank plc is a retail and commercial bank in the United Kingdom. It originally operated under the umbrella of Lloyds TSB but was spun off as a standalone entity in 2013 to comply with European Commission state aid rules following the 2008 financial crisis. In 2015, TSB was acquired by the Spanish banking group Banco Sabadell.

Following the acquisition, Sabadell initiated a large-scale integration project to migrate TSB’s entire operational backend off the rented Lloyds Banking Group infrastructure and onto a new, customised version of Sabadell’s in-house banking software platform, known as Proteo4UK. This migration was a strategic requirement for Sabadell to achieve long-term cost synergies and operational independence from its predecessor.

The Forensic Discrepancy Matrix

Act I: The Assurance Programme That Could Not See Production

By early 2018, TSB was under significant commercial pressure. Renting the IT infrastructure from Lloyds was costing the bank hundreds of millions annually. The mandate from Banco Sabadell was unambiguous: move all customer accounts, transaction histories, direct debits, and mortgage ledgers onto Proteo4UK.

The programme that followed was, by documented measures, substantial. TSB and its IT delivery contractor SABIS (Sabadell Information Systems) ran an integration effort spanning more than four years. The programme included extensive testing, nine successful transition events and dress rehearsals, a pilot involving more than 1,600 employees, and significant third-party scrutiny. (TSB) These are not the hallmarks of a programme that ignored testing.

The new Proteo4UK infrastructure was designed to operate across dual data centres, providing high availability through simultaneous processing and continuous state synchronisation. Moving a core banking ledger is fundamentally different from updating a consumer application. Financial ledgers require strict transactional integrity, and the new platform’s behaviour under real customer load — across those data centres — was a condition the testing regime failed to fully model.

What the evidence establishes: TSB’s testing and assurance programme was extensive. Despite this, the programme failed to expose critical production failure modes — specifically, inconsistent configuration between the two data centres supporting the new platform. (Slaughter & May) Thousands of defects remained open at the point of go-live.

What the evidence does NOT establish: There is no documented evidence that TSB or SABIS deliberately skipped testing. The failure was one of assurance — the testing programme generated confidence that production conditions did not validate. There is also no documented evidence of malicious interference by any individual.

Act II: A Successful Migration, and a Platform That Could Not Stand

On the evening of Friday, April 20, 2018, TSB took its digital banking channels offline to begin the final main migration event. The bank carried out the migration of its customer data over the weekend of April 20–22.

By Sunday evening, internal systems confirmed what TSB later publicly acknowledged: the data migration had succeeded. Every customer account had been transferred to the penny. (TSB) The bank opened its digital channels.

Critical Distinction — Data Migration vs. Platform Operation: TSB’s data migration was completed successfully. The catastrophe that followed was not a failure of the data migration. It was a failure of the new platform’s operational stability under production conditions — a more sophisticated and instructive failure mode than a simple botched data transfer.

The catastrophe was immediate. When customer traffic began reaching the new platform on Sunday, severe service instability emerged. The Slaughter and May independent review identified that the two data centres, despite having been designed to be configured identically, had inconsistencies in their configuration that had not been detected before migration. This discrepancy became consequential under real production load.

Customers attempting to check their balances were met with perpetual loading screens, generic error codes, and forced timeouts. In a significant subset of cases, some customers reported seeing the account information of other customers — a particularly serious consequence of the platform’s instability.

Defect Accumulation Around Go-Live

The Slaughter and May report documents the defect universe around the migration event in extraordinary detail. TSB did not enter production with a clean defect register. Slaughter and May identified 4,424 defects still open on April 18, although TSB disputed the report’s treatment of the wider JIRA population and argued that only 98 outstanding defects were directly relevant to the main migration event.

The critical distinction is not that TSB skipped testing. It is that the testing programme and assurance process produced confidence that the production system did not validate — and that thousands of open defects accompanied the platform into its first live customer encounter.

Act III: The Cascading Operational Collapse

The technical platform instability immediately triggered a human operational collapse. Unable to access their funds digitally, hundreds of thousands of customers turned to telephone contact centres and physical branches.

The contact centres, however, were dependent on the same underlying Proteo4UK platform. Internal teller portals suffered from the identical instability that had crippled the mobile application. Call queues stretched to multiple hours. Branch staff were forced to turn away customers because their terminal screens would not load balance information.

As TSB confirmed in its own disclosures, the surge in customer contacts far exceeded existing contingency capacity. (TSB) The distributed technical problems were compounded by the difficulty of diagnosing and resolving platform failures in a new environment with limited production-scale observability. While the bank deployed rolling capacity expansions, instability persisted for weeks.

The crisis dominated national headlines and drew immediate scrutiny from the Treasury Committee. The FCA and PRA subsequently imposed a combined £48.65 million penalty for operational resilience failings, confirmed in December 2022.

Systems Prevention Playbook

The TSB migration failure reframes the standard argument about enterprise platform cutovers. The lesson is not simply “test more.” The lesson is that testing regimes must be designed to reveal production failure modes — not merely to generate confidence.

As seen in similar high-coupling enterprise platform failures — such as the Knight Capital Trading Glitch — the most dangerous failure mode is one that passes all pre-production checks and only manifests at full production scale.

Engineering Evolution

FAQ

What caused the TSB IT failure in 2018?

The 2018 TSB failure resulted from multiple technical and governance weaknesses surrounding the migration to Proteo4UK. The Slaughter and May independent review identified shortcomings in planning, testing, supplier oversight, and technical configuration — including inconsistent configuration between the two supporting data centres that was not detected before migration, despite extensive testing. These problems caused severe service instability after go-live, which was then amplified by a customer demand surge that overwhelmed existing contingency resources.

How much was TSB fined for the IT failure?

TSB received a combined £48.65 million penalty. The Financial Conduct Authority (FCA) levied £29.75 million and the Prudential Regulation Authority (PRA) levied £18.9 million for operational resilience failings. The FCA Final Notice was published in December 2022, more than four years after the incident.

How long did the TSB IT disruption last?

Severe outages began on April 22, 2018. While basic access was restored incrementally over the following weeks, widespread instability, missing payments, and severe customer service delays persisted for an extended period, with full platform stabilisation taking months.

What was the Proteo4UK migration programme?

Proteo4UK was a customised version of Banco Sabadell’s in-house core banking platform, adapted for the UK market. The migration programme was an approximately £800 million, multi-year integration project to move TSB’s customer accounts and operations off legacy Lloyds Banking Group infrastructure and onto the new platform. TSB’s own account describes it as a programme spanning more than four years.

Who resigned after the TSB IT crash?

CEO Paul Pester resigned in September 2018 following sustained public, media, and parliamentary scrutiny — fuelled in part by TSB’s initial communication about the severity of the disruption, which was widely considered inadequate.

Why did the TSB IT migration fail?

The failure was not caused by an inability to transfer customer data. TSB confirmed that the customer data migration was completed successfully — every account was transferred to the penny. (TSB) The problem was severe platform instability after go-live. Reviews identified weaknesses in testing, supplier oversight, and technical configuration, including inconsistencies between the two supporting data centres that escaped detection during an extensive testing programme. The resulting disruption was then amplified when large numbers of customers shifted to telephone and branch channels, overwhelming capacity that had not been scaled for the volume.

The Archivist’s Verdict

The Archivist’s Assessment: TSB’s 2018 failure is not a story about a company that failed to test. It is a story about what happens when an assurance process becomes structurally incapable of revealing the failure modes that matter.

The documented record is striking precisely because it contradicts the simplest retelling. Four years of planning. Extensive testing. Nine dress rehearsals. Board-level confidence. A successful data migration that transferred every account to the penny. And then — platform collapse.

The Slaughter and May independent review establishes what the testing regime failed to find: the two data centres were inconsistently configured despite having been specified to be identical. That discrepancy escaped every dress rehearsal and every assurance review. It only became consequential when real customers — in real numbers, conducting real transactions — put the platform under conditions that the testing environment had not reproduced.

Sitting alongside that configuration finding is the defect accumulation record: 4,424 open defects four days before go-live, 395 new defects still unresolved on April 22, and thousands more generated in the weeks immediately after. TSB did not enter production with a clean system. It entered production with a system that had accumulated enough complexity and known fragility that the combined weight of those weaknesses, under production load, caused collapse.

The regulatory fines and Paul Pester’s resignation reflect a failure that exceeds any single software bug. The more important lesson for systems engineering is architectural: testing without production fidelity is not assurance. A testing programme that generates confidence without validating configuration parity, realistic concurrent load, and full-stack operational behaviour does not eliminate risk — it conceals it.

Primary Sources

• FCA Final Notice 2022 - TSB Bank plc
• Slaughter and May Independent Review of the TSB IT Migration
• TSB — Response to FCA and PRA Findings (December 2022)
• Treasury Committee Oral Evidence: TSB IT Failure