5 Million Locked Accounts: What TSB's Migration Failure Teaches About Banking QA

In April 2018, TSB Bank moved 5 million customer accounts to a new banking system. Within hours, things went badly wrong.

Customers couldn't log in. Some customers could see other people's account balances. Online and mobile banking stopped working for weeks, not hours. By the time regulators finished their investigation, TSB was fined £48.6 million.

This is one of the clearest examples in banking of what happens when a system migration isn't tested properly before it goes live.

What Caused the TSB Bank IT Failure?

TSB was moving customer data from an old banking platform to a new one built by its parent company at the time, Sabadell. The plan was to move everything over one weekend.

It didn't go as planned.

• Customers were locked out of their own accounts within hours of the switch
• Some customers logged in and saw other customers' account details and balances
• Online banking and the mobile app went down for an extended period
• Call centers were overwhelmed and couldn't handle the volume of complaints
• The disruption continued for weeks, not a single bad day

UK regulators later found the migration suffered from serious failings. Their report pointed to poor planning and weak governance around the whole project. A separate independent review, commissioned after the fact, concluded that TSB had rushed the switch and hadn't tested it properly before turning it on for real customers.

In simple terms: TSB tried to move millions of live accounts to a new system without being sure the new system actually worked correctly first.

Why Do Data Migrations Fail in Financial Services?

Bank data migrations are harder than most other kinds of software changes, and there are a few clear reasons why.

The data is enormous and messy. Years of customer records, transaction history, account settings, and linked products all need to move over correctly, with nothing lost and nothing duplicated.

Mistakes affect real money. A bug in a shopping app might show the wrong product image. A bug in a banking migration can show the wrong account balance, or let one customer see another customer's money.

There's no easy way to test at full scale beforehand. Testing with a small sample of accounts doesn't tell you what happens when 5 million real accounts hit the new system at once, under real load, with real edge cases nobody thought to account for.

Timelines get compressed. Migrations are expensive to run, so there's constant pressure to do it once, do it fast, and move on. That pressure is often exactly what causes teams to skip steps.

This isn't unique to TSB. It's a pattern that shows up across the banking industry whenever a migration gets treated as a one-time technical event instead of an ongoing testing process.

Reference: https://www.fca.org.uk/news/press-releases/tsb-fined-48m-operational-resilience-failings

https://www.bankofengland.co.uk/news/2022/december/tsb-fined-for-operational-resilience-failings

How Do You Test a Banking System Migration?

Done properly, a migration needs to be tested in stages, not just checked once right before launch.

• Test with real data patterns, not sample data. Fake test accounts rarely capture the messy edge cases hiding in real customer records built up over years.
• Run the new system and the old system side by side. Compare the results for the same accounts before fully switching over, so any mismatch shows up before customers ever see it.
• Test at full volume, not a small slice. A system that works fine for 10,000 test accounts can still fail badly at 5 million real ones.
• Test the rollback plan, not just the migration itself. If something goes wrong, the team needs a tested way to reverse the change quickly, not figure it out live.
• Test access controls specifically. One of TSB's worst problems was customers seeing other people's data. That's not a performance issue, it's a fundamental testing gap around who can see what.

Most of this isn't unusual advice. The harder part is actually doing it under time and budget pressure, which is exactly where TSB's process reportedly broke down.

What Is the Cost of Skipping Migration Testing?

The £48.6 million fine is only part of the real cost. The fuller picture includes:

• Weeks of reputational damage, with the failure covered widely in national news
• Customer trust that takes far longer to rebuild than the system took to fix
• Regulatory scrutiny that continues well after the immediate crisis is resolved
• The cost of the emergency fix itself, on top of whatever the original migration budget was

Skipping proper testing to save time or money almost always ends up costing far more than the testing would have.

How Could AI Have Prevented the TSB Bank Outage?

A modern, AI-assisted testing approach could have caught several of TSB's problems before go-live.

Automated comparison testing could check the old and new systems against each other continuously, flagging any mismatch in account data automatically, instead of relying on manual spot checks.

Requirement-driven testing ties every requirement, like "a customer must never see another customer's account," directly to a test that verifies it. If that specific requirement had been tracked and tested explicitly, the access control failures TSB experienced become much harder to miss.

This connects to the same underlying idea behind the Knight Capital trading failure, a different industry, a different kind of bug, but the same root problem: a system change went live without every affected path being properly retested first.

For banks specifically, this kind of testing needs to be built into how QA works day to day, not treated as a one-off project before a big migration. That's the broader case for AI testing in banking, where the stakes of a missed bug are measured in real customer money, not just inconvenience.

Where TestMax Fits Into This

This is the exact problem TestMax is built to catch. Instead of writing test cases by hand and hoping they cover the important paths, TestMax starts from the actual requirements, things like "a customer must never see another customer's account", and keeps every one of those requirements tied to a test that verifies it, automatically, every time something changes.

For a migration like TSB's, that means the access control requirement doesn't just live in a document somewhere. It's an active, traceable test that has to pass before anything ships. If a change breaks it, TestMax flags it before go-live, not after 5 million customers find out the hard way.

The Simple Takeaway

TSB's failure wasn't caused by one bad piece of code. It was caused by treating a massive, high-risk migration like a project with a deadline, instead of a process that needed to be proven safe before millions of real customers depended on it.

Any bank, or any company handling sensitive customer data, planning a similar migration should ask one honest question before going live: has this actually been tested at full scale, under real conditions, including what happens if something goes wrong? If the honest answer is no, that's the problem to fix first.

Frequently Asked Questions

What caused the TSB Bank IT failure? 

TSB moved 5 million customer accounts to a new banking platform in April 2018. The migration wasn't properly tested at scale beforehand, which caused customers to be locked out, some to see other customers' data, and online banking to go down for weeks.

How much was TSB fined? 

UK regulators fined TSB £48.6 million after investigating the migration failure and finding serious weaknesses in planning and governance.

Could this have been prevented? 

Yes. Testing the migration at full scale, comparing old and new systems side by side, and specifically testing access controls before go-live would likely have caught the major issues before real customers were affected.