TSB, April 2018: the weekend a bank could not go back

On Sunday, April 22, 2018, at about one in the afternoon, a UK bank approved the final step of a project almost three years in the making. Over that weekend it had moved most of its operation onto a new technology platform: its systems, its services and its customers' data. By six in the evening, telephone banking and internet banking were back online. The mobile app took a little longer: it came up at 6:45 p.m. [1].

Fifteen minutes later, the bank switched off all of its digital channels.

About 40 customers had reported something no bank wants to hear: on logging in to their account they saw someone else's money, almost always a relative's. It was later confirmed that this happened to 440 customers [1]. The bank was TSB, it had around 5.2 million customers [1], and that night began a crisis that, according to the regulator, did not fully end until December 10, 2018 [1].

This article is for whoever signs the decision to change a core system: general management, finance, operations or IT. It is not a technical story. It is the story of a committee decision that left the bank without a viable rollback, with incomplete readiness signals on the table, and of the questions that should have demanded clearer evidence before the launch was approved.

One clarification before we start: Hábil did not take part in this case. We tell it from what the regulators (the FCA and the PRA) reported publicly and from the independent review that TSB published.

First, four terms

So that everyone at the table means the same thing:

• Core system: the system where the accounts, balances, transactions and business rules live. In a bank, it is what decides whether a payment was applied.
• Migration: moving the operation and the data from one system to another.
• “Big bang”: concentrating most of a migration in a single event, almost always a weekend. There may be earlier steps, but the main risk sits in that moment.
• Rollback: the ability to return to the previous system if the new one fails.

Keep the last one in mind. It explains everything else.

The Monday when it all showed

On Monday, April 23, at two in the morning, the bank switched internet banking and the app back on. But part of the new platform was consuming enormous amounts of memory, and the bank had to limit logins so that the app would not crash [1].

That day there were close to 900,000 attempts to log in to online banking. Only about 10% of the internet attempts succeeded. Of the payments customers tried to make, 48% failed to complete in the app and 59% online [1].

Customers who could not get in did the logical thing: they called. By two in the afternoon, the call center had already received 69,000 calls. The bank had prepared for up to 50% more calls than usual, but a configuration problem left only about a quarter of the line capacity it should have had. The wait was around 90 minutes, and seven out of ten people hung up before being answered [1].

Those who got nowhere by phone went to a branch. There, the teller application kept crashing and the card readers did not work. Long lines formed [1].

The regulator describes it as a cascade: the digital failure pushed people to the phone, the phone lines became saturated and people arrived at branches that were also failing [1]. The phones and the branches had their own problems, so no channel could absorb the demand from the others.

The digital channels remained “unstable and almost unusable” until Thursday, April 26 [1]. By then, the bank had logged 10,315 complaints, against the 1,146 it expected [1]. Some defects lasted until June [1].

The cost of the crisis

What followed can be counted in numbers, all of them from official documents:

• 225,492 complaints between April 22, 2018 and April 7, 2019, from about 4.3% of its customers [1].
• £32.7m paid to customers in compensation over that same period [1].
• Almost 12 months to handle the migration complaints [1].
• £48.65m in fines on December 20, 2022: £29.75m from the Financial Conduct Authority (FCA) and £18.9m from the Prudential Regulation Authority (PRA), the UK's two regulators. Without the 30% discount for settling, they would have been £69.5m [1][2][3].
• A personal fine in April 2023: the PRA fined the bank's former chief information officer £81,620 for not taking reasonable steps to make sure the bank properly supervised its provider during the migration [5].

And one fact changes how everything above reads: the data migration was successful [1]. That did not prevent the access and operating failures, or the cases of customers who saw someone else's information. The lesson is an uncomfortable one: migrating the data well does not prove that a platform is ready to serve millions of customers at the same time. According to the FCA, the direct causes had to do with the platform's configuration, capacity and code [1].

How it got to that Sunday

To understand the night of April 22, you have to go back almost three years.

TSB was born in 2014, when it separated from the Lloyds group, and it kept using Lloyds' technology platform under contract. In 2015 it was bought by Spain's Sabadell for £1.7 billion, according to Reuters [7]. Sabadell had experience migrating banks onto its own platform, called Proteo [1]. TSB's migration onto that platform was part of the business case for the purchase [1].

After the crisis, TSB's board commissioned the law firm Slaughter and May to carry out an independent review. The report, dated October 2019 and published by TSB in November of that year, reconstructs the story [4][6]. Three of its findings explain that April Sunday.

1. The date came before the plan

By July 1, 2015, the day after the offer to buy the bank became final, a date had already been chosen to switch on the new system: Sunday, November 5, 2017 [4]. The first formal plan, completed nine months later, kept that same date.

The report calls it “ambitious and unrealistic” and points out something more serious than the date itself: a pattern had taken hold of fixing the desired date and then building a plan to fit it, realistic or not [4].

In September 2017 the bank postponed the launch and redid the plan, without examining in depth why it had slipped, and nine days later it publicly announced a new date. By January 2018, the project had already veered off course again [4].

2. The main migration, in one weekend and without a thorough discussion

How to migrate is one of the most important decisions in a project like this: in stages or in one stroke. The report puts it plainly: doing it in one stroke is “the fastest, cheapest and least complex way to proceed”, but it requires understanding its risks and testing the platform thoroughly before putting it in front of all customers [4].

And it adds an important nuance: going that way “would not necessarily have been the wrong approach had the right mitigants been put in place” [4]. The problem was a different one: the choice was not discussed in depth by the board, the board was not presented with the options and their risks, and no external advice was sought on that point [4].

The bank did move some pieces beforehand: Faster Payments, the app and the ATMs [1]. But the report concludes that those earlier stages covered only a small part of the platform, and that the pilot with real users was not large enough to show what would happen with all customers [4].

The reasons the bank gave for doing nearly everything in a single event are reasonable, which is why they are worth reading: how hard it is to move in stages from one provider to another, the cost of doing it in stages, the idea that the previous provider would not make it easy, and the advantage of customers seeing all their products in one place [1].

3. What the board did not get to see

Here is the heart of the story. Several signals existed, but they did not reach the decision-makers complete:

• The defects. The board was told of “around 800 defects” that would carry over into the live system. The report concluded that there were in fact 3,317: the 800 were groups of functionality that each bundled several defects, and those found in other tests were missing [4]. The problem was not only the number, but that the report did not say what it counted and what it left out.
• The test targets. In the load tests for internet banking and the app, the targets were lowered after the tests failed against the original load. The summary did not make the change clear, and actual use after launch exceeded even the reduced targets [4].
• The real configuration was not fully tested. The operation depended on two data centers working together, but the performance tests were run in only one. The configuration problems between the two, which hit digital customers from the very first moment, could not show up in those tests [4]. The FCA adds that a decision taken outside the body that should have taken it, in late February 2018, cut a test that would probably have found the problem [1].
• The provider. The provider that built and would operate the platform, a Sabadell subsidiary, itself depended on 85 third parties [1]. A report by an audit firm, commissioned by that provider, which found deficiencies in its internal controls, was not shared with TSB [4].

The report sums up its conclusion in two statements: “the new platform was not ready to support TSB's full customer base” and “SABIS was not ready to operate the new platform” (SABIS being the Sabadell subsidiary just mentioned) [4]. On the board, it says that it asked pertinent questions but that some “common sense challenges” were missing, and that its meeting of April 10, 2018 was a missed opportunity to stop and think [4].

In fairness, it must be said that TSB's board did not agree with everything in the report. It maintained that a key cause was that the two data centers ended up configured differently, even though they had been specified as identical, and that it decided to go ahead on the basis of extensive testing, readiness reports and assurances from the provider [6]. The findings in this section come from the independent report; the board's position is the one TSB published.

The missing word: rollback

Of everything that failed, one decision turns a bad launch into a crisis of eight months.

The FCA explains it this way: when almost all customers are migrated at the same time, a serious problem can harm a very large number of people. That is why a plan to return to the previous system is sometimes prepared. For TSB, that plan was not possible [1]. Under its contract, by notifying Lloyds that it would exit through a migration, TSB gave up its other exit option: a copy of the platform operated by a third party (the “carve-out”). And after the data was migrated, there was only a very short window before the previous platform was switched off. In practice, going back was technically almost impossible [1].

The risk was no secret. In December 2015, the minutes of TSB's board recorded the following: “the Board could not be put in a position where they gave up the carve-out option, migration ‘stalled’ or was found to be unworkable leaving the bank in a position without an IT infrastructure.” [1].

And the preparation for a crisis was not up to the size of that bet. The incident-management playbooks were designed for the first 48 hours [1]. The drills assumed that incidents would be resolved within a few days; many took weeks [1]. The FCA concludes that, with no rollback and relying on a single provider to fix several problems at once, the bank should have prepared far more [1].

What a director takes from this story

TSB is not a case of bad technology. It is a case of risk concentrated in a single moment, with no exit and with incomplete information on the table. It can happen to any company that changes its core system, its ERP (the system that brings together finance, purchasing, inventory and operations) or its policy system, whatever the brand. Six lessons, in business language.

1. If the date overrides the evidence, the plan is a wish. When every delay is resolved by tightening the plan instead of moving the date, risk builds up in silence. Ask for measurable criteria to launch, and for the committee to be able to move the date without it looking like a failure.

2. The question is not “will it work?” but “what happens if it doesn't?” A one-stroke launch can be the right option. But if there is no rollback, the cost of being wrong is no longer a bad weekend: it is the entire operation for months. Before approving, ask what the rollback exit is, how long it is available and who decides to use it.

3. Insist on seeing the options, not just the recommendation. TSB's board was not shown the ways of migrating with their risks [4]. A committee that sees only one proposal is not deciding: it is approving.

4. The number that matters is the one nobody wants to present. Defects counted low, test targets adjusted without notice, a test cut without going through the right body. None of them looks serious on its own. Ask for the raw number, who changed each criterion and when, and for an independent third party to confirm it before the launch meeting.

5. Your critical provider must show that it can operate, not just build. They are two different capabilities. If your provider depends on dozens of third parties, so do you. Ask for evidence of operation, not just letters of assurance.

6. Prepare for weeks, not for 48 hours. Ask what happens on day ten: who answers the calls, how customers are compensated and how the most vulnerable are identified.

And a seventh, which the case makes clear: responsibility reaches individuals. The fine on the former chief information officer was for not taking reasonable steps to make sure the bank adequately supervised its provider [5]. A provider's assurance does not replace the evidence that the company itself must obtain and review.

The alternative: modernize in parts, living alongside the core

The TSB case does not prove that every core change fails, or that modernizing in parts is possible in every context. It does show what a committee should demand when it concentrates critical changes, all of its customers and the lack of a rollback in a single moment.

If TSB's risk was concentrating everything in a single moment with no exit, the alternative is to spread it out: modernize in parts, with the current system operating in the meantime, and with a rollback exit at each stage.

In business terms, it looks like this:

• The current core keeps operating. It is not switched off on Friday so that another can be switched on Sunday. Around it, a layer is built that connects it to channels, partners and new functions, without touching its rules from the inside.
• One function changes at a time. For example, first balance inquiries for a small group of customers; then payments; then another product. Each part is accepted before the next one begins.
• Each stage has its agreed rollback. Before starting, it is agreed how that function returns to the previous path if something goes wrong, without dragging the rest of the operation along.
• Old and new are reconciled. While they coexist, what one says is compared against what the other says. The new function earns its place with evidence, not with a date.
• Growth is gradual. First one group of customers, then another. Problems tend to appear when they affect few people and are easier to correct.

This path is not free: while the two worlds coexist, you have to sustain connections, reconciliation and two teams. It usually takes longer, and it demands discipline so that the coexistence is not left open forever.

Nor does it eliminate risk: it changes what must be demonstrated before widening the scope, and its viability depends on each company's systems, data and contracts. But it changes the nature of the risk. In a one-stroke launch, almost everything is bet on the first day going well. In a modernization in parts, each stage mainly exposes what is being changed in it. When your core decides whether a customer receives their money, that difference is worth more than the weeks saved.

Scenario (illustrative, no client). An insurer wants to renew how its agents quote and issue policies, but its policy system is old and nobody wants to touch it. Instead of replacing it in one stroke, a new layer is connected to it. First, only the quoting of one product goes through that layer, for a small group of agents. For an agreed period, each new quote is compared with the one from the previous system. When they match, more agents are added; then, issuing. If something does not match, that function goes back to the usual path through the rollback that was agreed before starting. The policy system remains the one in charge.

Five questions for your next committee

1. If the new system fails on the first day, how do we go back, in how long, and who decides? If the answer is “we can't,” does the board know?
2. Which implementation options were evaluated, with the cost and risk of each, and why were the others discarded?
3. Which measurable criteria must be met in order to launch, and who can move the date if they are not met?
4. How many open defects are there today, and has any test target changed since the plan was approved? Who authorized it?
5. What evidence do we have that the provider can operate the system at scale, not just build it, and which third parties does it depend on?

If you answer “I don't know” to two or more, your risk may be there.

Where to start this week

Take the modernization project you have under way, or the one about to be approved, and draw on a single sheet its moment of greatest risk: the day on which the most customers, the most functions and the most money change at the same time. Next to it, write what would happen if that day goes badly and how you would go back. If that moment covers all your customers and has no exit, you already know what conversation to have with your committee.

What Hábil does

Hábil is a Mexican engineering consultancy, founded in 2006, that integrates with the core systems your company already has. We do not replace your core: we build around it the layer that makes it possible to modernize in parts, with the current system operating, with reconciliation between old and new, and with an agreed rollback exit at each stage. That way each new function earns its place with evidence, and the modernization is designed so that your operation carries on in the meantime. See the page Modernize the core without slowing the business.

Request your first conversation, at no cost. It starts from your current project: where the risk is concentrated, what has a rollback exit today and what does not. Write to us on WhatsApp.

Frequently asked questions

What happened to TSB in April 2018?

From April 20 to 22, 2018, TSB moved most of its operation to a new platform. The data migrated well, but the platform failed across all channels, and the bank did not return to normal until December [1].

How large were the fines, and who imposed them?

On December 20, 2022, the FCA fined TSB £29.75m and the PRA £18.9m: £48.65m in total, with a 30% discount for settling [1][2][3]. In April 2023, the PRA fined the former chief information officer £81,620 [5].

So is a one-stroke migration always a mistake?

No. The independent report says it “would not necessarily have been the wrong approach had the right mitigants been put in place” [4]. What cannot be defended is choosing it without evaluating the alternatives, without testing at real scale and without an exit if something fails.

Doesn't modernizing in parts cost more?

It can cost more in calendar time and in keeping two systems running at once. In return, each stage exposes less. TSB shows the other side of the ledger: compensation, fines and almost a year handling complaints [1].

Does this apply only to banks?

No. It applies to any company that changes the system that runs its operation: an insurer's policy system, an industrial company's ERP, a retailer's order system. The size changes; the risk of concentrating everything in a single moment with no exit does not.

When is modernizing in parts not advisable?

When the functions cannot be separated from one another, when the data cannot be reconciled between the old system and the new one, or when a contract forces you to leave the previous system on a fixed date. In those cases the conversation changes: which part of the risk can be reduced and which has to be accepted with eyes open.

Does Hábil replace our core?

No. Hábil integrates with your current core and builds around it the layer that makes it possible to modernize in parts. The core keeps operating and each stage has its agreed rollback.

Quotations are taken verbatim from the original English-language sources. Figures, dates and penalties come from the FCA and PRA decisions; the analysis of the project's decisions comes from the independent Slaughter and May report, published by TSB; the board's position comes from TSB's press release. Sources consulted on October 20 and 21, 2026.