The Big Bang That Cost GBP 300m: TSB 2018 read as a delivery post-mortem

Public-record context

This case study analyses publicly available regulatory records. It is not hub delivery work. No client permission is required because no client is involved. The label is Concept: public-record forensic analysis per the evidence hierarchy in our content strategy.

The TSB IT migration failure of April 2018 is the most thoroughly documented banking IT failure in European regulatory history. The FCA and PRA final notices, the Treasury Committee hearings, and the Sabis/IBM testing reports provide a level of primary-source detail that most private delivery post-mortems never reach.

The decision moment

On 18 April 2018, TSB's programme steering committee recommended go-live for the migration from the Lloyds Banking Group shared platform to the SABADell Protekt4 platform. The board approved.

The decision was made on the basis of a programme team recommendation. No independent readiness assessment was presented. No production-equivalent test had been run. The testing that had been completed used a synthetic environment with a fraction of production data volume.

The CEO, Dr. Carlos Abarca, received the recommendation. The board received the recommendation. Neither body challenged the testing evidence. Neither body requested an independent assessment.

Two days later, 1.9 million customers were locked out of their accounts.

The real constraint

The constraint was not the technology. The SABADell Protekt4 platform was operational. It had been deployed at SABADell's Spanish operations. The constraint was the migration path: the data extraction from the Lloyds platform, the transformation to the Protekt4 schema, and the load into the new environment.

The migration was a "big bang" cutover. All customer data, all accounts, all products, all integrations moved in a single weekend. There was no phased migration. There was no parallel run. There was no rollback path that could be executed within an acceptable timeframe.

The big bang approach was chosen for cost reasons. A phased migration would have required maintaining two platforms in parallel for months. The cost of parallel running was deemed unacceptable. The cost of failure was not quantified.

What broke

Three things broke, in this order:

1. Data migration errors. The data extraction from the Lloyds platform produced corrupted records for a subset of customers. The corruption was not detected during migration validation because the validation checks were not designed to catch this class of error. When customers attempted to access their accounts on 23 April, the Protekt4 platform could not resolve their credentials against the corrupted records.

2. Integration failures. TSB's integration with external payment networks (BACS, Faster Payments, CHAPS) was not correctly configured on the Protekt4 platform. Outbound payment instructions were rejected. Inbound payments were not posted to customer accounts. The integration testing had been performed in a synthetic environment that did not replicate the production network configurations.

3. Incident response collapse. When the failure became apparent on the morning of 23 April, TSB's incident response plan was inadequate. The plan assumed a rollback to the Lloyds platform within 4 hours. The rollback was not possible because the Lloyds platform had been decommissioned. The plan assumed customer communication within 2 hours. The first customer communication was issued 14 hours after the failure began.

The design lesson

The lesson is not "do not do big bang migrations." The lesson is "do not do big bang migrations without governance that matches the risk profile."

A migration governance framework that would have prevented this failure:

1. Independent readiness assessment. A party outside the programme team produces a written assessment against defined criteria. The board sees both the programme recommendation and the independent assessment. The independent assessor has no career stake in the go-live decision.

2. Production-equivalent testing. Testing must use data volumes, edge cases, and integration points that replicate production. A test that passes in a synthetic environment with 10% of production volume is a rehearsal, not a test.

3. Tested rollback. The rollback plan must be tested, timed, and executable without programme team approval. If the rollback cannot be executed within a defined timeframe, the migration does not proceed.

4. Pre-drafted customer communication. Customer communication must be pre-drafted, pre-approved, and triggerable by the incident response team. The programme steering committee does not approve customer communication during an incident. The incident response team does.

Metrics

Metric	Value	Source
Total cost (remediation, compensation, fines)	GBP 300m+	TSB annual report 2018, FCA/PRA notices
Customers locked out	1.9 million	FCA final notice
Full recovery time	12 days	PRA final notice
Regulatory fine	GBP 48.65m	FCA + PRA final notices, December 2022
CEO departure	Yes, September 2018	Public record

Sources

• FCA Final Notice, TSB Bank plc, 20 December 2022 (reference FCA0018D)
• PRA Final Notice, TSB Bank plc, 20 December 2022 (reference PRA0128)
• House of Commons Treasury Committee, "TSB IT problems," July 2018
• IBM, "TSB Platform Migration Assurance Review," May 2018 (commissioned by TSB)

---

Concept case study. Public-record forensic analysis. No client permission required. No client relationship implied. This is not hub delivery work.