Summary

Why this case belongs in a risk and accountability file

TSB's migration is an accountability case because it shows the point at which a banking technology programme stops being a private programme and becomes a public access system. A retail bank may describe a migration as a strategic platform move, an outsourcing change, a cost plan, a data transfer, or an enterprise-software programme. Customers experience it differently. They experience account balances, payments, debit cards, standing orders, mortgage servicing, business cash flow, branch queues, call waiting, fraud warnings, and compensation claims.

When the platform fails after cutover, the governance evidence is no longer an executive slide. It is whether people can reach their money and whether the bank can prove what happened.

The FCA press release at source: fca.org.uk is the clean public entry point. It says the FCA and PRA fined TSB 48.65 million pounds for operational risk management and governance failures, including management of outsourcing risks, related to the bank's IT upgrade programme. It says the data migrated successfully, but the platform immediately experienced technical failures. It also says the disruption affected branch, telephone, online, and mobile banking, all branches, and a significant proportion of TSB's 5.2 million customers, with some issues continuing until business-as-usual was restored in December 2018.

That statement matters because it distinguishes data movement from service readiness. A migration can move records and still fail customers. The hard question is not whether bytes crossed from one platform to another. It is whether customer-facing services, authentication flows, payment journeys, branch systems, call-centre tools, fraud controls, supplier runbooks, and incident escalations were proven to operate under real load after the old path was no longer available.

The accountability issue is therefore practical control: who could stop the cutover, who could demand better testing, who could see supplier readiness, who owned fallback decisions, and who could prove that customers would not become the test environment.

The FCA Final Notice at source: fca.org.uk and the PRA Final Notice at source: bankofengland.co.uk give the case its regulatory shape. They frame the migration as a high-risk change programme, not a routine technology refresh. They also connect the failure to outsourcing governance and operational resilience. TSB was not simply operating a self-contained system. Its migration involved Banco Sabadell group technology and a supplier chain that the bank had to manage while remaining accountable to UK customers and UK regulators.

The timeline starts before the weekend of cutover

The public chronology should not begin only with customers failing to log in after the April 2018 migration weekend. It begins with the strategic reason TSB wanted to leave the Lloyds Banking Group platform, the design of the new Proteo4UK platform, the supplier structure around Sabadell Information Systems, the sequencing of testing, the readiness evidence given to executives and the board, and the decision to proceed. A cutover weekend is only the visible moment. The risk is built earlier.

The TSB Bank Annual Report and Accounts 2018 at source: tsb.co.uk gives TSB's own public account. It says 2018 was a challenging year, records service disruption after the migration, and describes work to put things right. The TSB Banking Group report at source: tsb.co.uk records the wider group consequences, including the scale of costs and the impact on performance. These reports are useful because they show the incident as a business event, not only a technology event.

The independent review announced by TSB at source: tsb.co.uk and published at source: tsb.co.uk adds a second public layer. It reviews the migration, the governance around the programme, the technology and supplier arrangements, the incident response, and customer consequences. It does not give the public every system log, test case, supplier workpaper, or board pack. It does, however, make clear that the readiness file must include governance, design, testing, assurance, service capacity, communications, and remediation.

Parliament's report on IT failures in financial services at source: publications.parliament.uk puts TSB in a sector pattern. It says financial-services customers increasingly depend on digital channels while branches and cash access change, and it identifies TSB and Visa as prominent incidents in a wider concern about operational resilience. TSB's own written evidence to that inquiry at source: committees.parliament.uk is important because it shows how the bank explained the event, its remediation, and its lessons to legislators.

A bank's post-incident explanation to Parliament is part of the accountability file because it is a public account given after the first emergency narrative has cooled.

The first lesson is that migration accountability is front-loaded. If a bank waits until the failed login storm to build evidence, it is too late. The evidence must exist before go-live: which services are critical, what tests represented real customer behaviour, what known defects remained, what suppliers could prove, what fallback existed, who could delay, and what impact tolerance was accepted.

Customer access was the central control

The FCA record says the disruption hit branch, telephone, online, and mobile banking. That is a full access stack. For a customer, these are not optional channels. A person who cannot use the mobile app may try online banking. If that fails, they call. If the call centre is overloaded, they go to a branch. If the branch system is slow or incomplete, the fallback fails as well. The result is not one broken channel. It is an access trap.

The regulatory press release says all branches and a significant proportion of 5.2 million customers were affected by the initial issues. That scale changes the standard of proof. A small technology incident can be handled through ordinary service recovery. A broad core-banking disruption requires evidence that vulnerable customers, small firms, mortgage customers, payment recipients, and branch staff were protected. The question is not whether the bank eventually restored systems. It is how much customer work was forced into the gap.

TSB's 2018 annual report describes online access problems, long telephone wait times, slower branch transactions, and fraud pressure against customers after publicity around the incident. That combination matters. A migration outage is not only an availability problem. It can become a security and conduct problem because confused customers are easier to target, because contact-centre overload can delay warnings, because staff may lack reliable data, and because customers may make repeated attempts through channels they do not normally use.

The article therefore treats customer access as the central control. Authentication, entitlement, balance visibility, payment execution, branch servicing, and complaint intake are all access controls. If one customer sees another customer's details, the issue is data confidentiality and transaction integrity. If a business cannot make a payment, the issue is cash-flow continuity. If a vulnerable user cannot reach a telephone adviser, the issue is customer harm. If branch staff cannot process service requests quickly, the issue is fallback capacity. These are not separate reputational problems.

They are consequences of a core service not being proven under stress.

The evidence standard is concrete. Before cutover, TSB needed assurance that representative customers could log in, view accurate data, make payments, receive payments, use cards, visit branches, call support, recover access, and complain if harmed. After cutover, TSB needed proof of what failed, which populations were affected, how transaction state was reconciled, how misleading customer communications were corrected, and how redress was calculated. The public record confirms serious disruption and redress, but it does not give outsiders the full transaction-level repair ledger.

Outsourcing did not move accountability away from the bank

The FCA and PRA enforcement record is especially important because it rejects the idea that a bank can move accountability by moving technical delivery. TSB relied on group-linked technology arrangements and critical third-party supplier services, but TSB remained the UK regulated firm with the customer relationship. The FCA press release says the regulators found failures in organising and controlling the migration programme and managing operational risks arising from IT outsourcing arrangements with a critical third-party supplier.

The PRA final notice at source: bankofengland.co.uk connects the case to safety and soundness. That is not a minor compliance label. A bank's ability to provide critical functions depends on technology, people, suppliers, controls, and evidence. If a supplier cannot prove readiness, the bank cannot simply accept optimism because the final customer duty remains with the regulated firm.

The later PRA action against former CIO Carlos Abarca, announced at source: bankofengland.co.uk and set out in source: bankofengland.co.uk, adds the individual-accountability layer. The public record should not be overstated. The notice is about Senior Manager Conduct Rule 2 and reasonable steps around supplier management; it is not a criminal finding. Its significance is that operational resilience can attach to named senior-management responsibilities when practical control and delegated delivery are misaligned.

The migration was therefore a shared-control test. TSB controlled the customer promise and the regulated duty. The supplier controlled parts of platform delivery. Group ownership and technical history affected dependency. Regulators controlled enforcement and supervisory expectations. Customers controlled none of those things. Accountability follows the party with the practical ability to demand evidence, delay launch, redesign fallback, strengthen supplier oversight, and fund recovery.

This is why the case is not only a TSB story. Modern financial institutions depend on group service companies, outsourcing providers, cloud platforms, payment networks, managed service firms, and specialist software vendors. The regulated firm may not build every component, but it must understand which important business services depend on those components. It must also know when supplier reporting is too thin, when testing is not representative, when known defects are customer-impacting, and when executive confidence is running ahead of evidence.

Readiness evidence had to match real banking behaviour

Core-banking migrations fail accountability when the evidence package is narrower than real life. A test environment may show successful record transfer. A technology team may show successful service activation. A supplier may show platform capacity. But customers do not arrive in neat test cases. They forget passwords, use old devices, call during lunch breaks, attempt payments near payroll deadlines, visit branches with complex needs, ask staff to correct errors, receive inbound payments, and respond to confusing messages. Small businesses reconcile cash flow under time pressure. The readiness file has to represent that messy reality.

The FCA and PRA notices describe the migration as ambitious and complex, carrying a high level of operational risk. That phrase should be read operationally. High risk means high proof. It means go-live criteria should not be a calendar objective alone. It means the bank should have a documented view of severe but plausible failure, the customer services that would be affected, the sequence for restoring them, the communications that would be sent, and the authority to stop or roll back if evidence was weak.

The FCA, Bank of England, and PRA Discussion Paper on operational resilience at source: bankofengland.co.uk was published after the TSB migration but in the same year. It provides useful vocabulary for the lesson: firms should identify important business services, map dependencies, set impact tolerances, and plan on the assumption that disruption will occur. Later policy material at source: fca.org.uk, source: bankofengland.co.uk, and source: bankofengland.co.uk formalised that logic.

The key point is not that 2021 rules should be retroactively applied to every 2018 fact. The point is that the TSB case illustrates why those concepts matter. Customer access to banking is an important business service. The impact tolerance is not whatever outage a programme can survive reputationally. It must be tied to customer harm, financial stability concerns, vulnerable users, and the realistic availability of substitutes. If cash, branch services, telephone support, online banking, and mobile banking are all impaired at once, the customer's substitutes shrink.

Readiness evidence should therefore have included end-to-end customer journeys, branch and contact-centre load, payment-state reconciliation, security monitoring, data confidentiality, supplier incident rehearsal, executive decision rights, and redress machinery. The public record shows regulators found failures in governance, risk management, outsourcing, and continuity. It does not show every test case. That gap is the accountability point: outsiders can see the outcome, but they could not inspect the proof that was used to proceed.

Security and fraud response became part of service recovery

TSB's 2018 annual report says the disruption and the publicity around it precipitated an intense and focused attack on TSB customers. That statement should be handled carefully. It is TSB's own public description, not an invitation to accuse any person outside the record. Its relevance is operational: a banking outage can create a security environment in which customers receive more malicious approaches, more confusion, more calls, and more pressure to verify or move money.

This is why the manifest topic of security automation belongs beside enterprise software automation. The migration failure did not merely require server repair. It required customer authentication confidence, account-data confidentiality, fraud monitoring, scam warnings, complaint triage, and clear communication. If customers are locked out, see unexpected balances, receive inconsistent messages, or cannot reach support, they become less able to distinguish legitimate bank communication from hostile contact.

Security controls after a migration must therefore produce evidence. Which access errors occurred? Did any customers see data they should not see? Were payment instructions duplicated, delayed, misrouted, or blocked? Were unusual login attempts detected? Were contact-centre scripts changed? Were branch staff given consistent identity-verification steps? Were vulnerable customers prioritised? Were fraud claims linked to outage confusion? These are fact questions, not public-relations questions.

The Slaughter and May report at source: tsb.co.uk is useful because it places technology, governance, incident response, and customer outcomes in one review. But the public still does not have the bank's complete security telemetry, customer-case data, or transaction-reconciliation records. That boundary matters. It is reasonable for some operational and personal data to remain confidential. It is also reasonable to ask the bank to preserve a replayable evidence file for regulators, auditors, and customer redress.

The strongest repair record would connect service restoration and security assurance. It would show that login repair did not weaken authentication, that payment repair did not obscure transaction disputes, that branch workarounds did not expose customer data, and that communications did not create avoidable phishing risk. In a banking migration, availability and security are not competing values. Both are part of account access.

Complaint recovery and redress were not afterthoughts

The FCA press release says TSB paid 32.7 million pounds in redress to customers who suffered detriment. That number is part of the core accountability record. Redress is not charity after an outage. It is an evidence-driven process for identifying harm, measuring cost, handling complaints, and correcting the transfer of operational burden from bank to customer.

The redress file should answer several questions. Who was eligible? Which losses were easy to prove, and which were hard for customers to document? Did small businesses receive compensation for missed transactions, delayed receipts, extra staff time, or reputational damage? Were vulnerable customers asked to repeat the same story? Did the bank detect harm proactively, or did the customer have to complain? How were complaints prioritised when support channels were already overloaded? How were errors in the bank's own data reconciled before complaints were judged?

TSB's annual reports and regulator notices establish that redress occurred and that disruption was significant. They do not provide a public customer-by-customer harm ledger, and they should not. But the redress design remains central to accountability because the customer had no control over migration readiness. If a customer had to spend hours trying to pay a bill, call the bank, visit a branch, switch accounts, or fix a failed payment, that time was a cost created by the bank's operational failure.

For small firms, the burden can be heavier. A blocked or delayed banking service can affect payroll, supplier payments, rent, loan obligations, tax payments, customer receipts, and cash forecasting. The Treasury Committee report at source: publications.parliament.uk recognised that small businesses can be left without basic banking services needed to run their businesses. That is why SME service continuity is not a niche topic. It is an accountability denominator.

The complaint process also tests honesty about uncertainty. A bank may not know every failure mode immediately. It can still communicate what is confirmed, what is being investigated, what customers should do, what evidence customers should keep, and how later findings will change redress. The worst version of incident communication asks customers to trust vague reassurance while they carry the operational burden. The better version gives customers a route to relief before the full forensic picture is complete.

The individual-accountability record has narrow but important meaning

The PRA's 2023 notice against former CIO Carlos Abarca is often treated as the personal-accountability coda to the TSB migration. It should be read with precision. The PRA did not say one individual alone caused the outage. It imposed a financial penalty for a Senior Manager Conduct Rule 2 failing connected to reasonable steps and supplier oversight. That is narrower than public anger, but it is important because it shows that operational resilience is not only a firm-level abstraction.

The PRA press release at source: bankofengland.co.uk says the failing undermined TSB's operational resilience and contributed to significant disruption. The final notice at source: bankofengland.co.uk gives the formal basis. The public significance is that senior managers responsible for technology and outsourcing need evidence of supplier capability, not only status updates.

This matters for future migrations. A named executive may rely on expert teams and suppliers. That is normal. But reliance must be controlled. What facts did the executive receive? What adverse evidence was escalated? What questions were asked about service-level breaches or supplier performance? What independent assurance was obtained? What could cause a go-live delay? What did the executive know about fourth parties? How were unresolved risks presented to the board?

The firm-level enforcement and the individual enforcement are therefore complementary. The firm had duties to organise and control its affairs and manage operational risks. A senior manager had duties to take reasonable steps in the area of responsibility. The supplier had practical delivery duties. Regulators had supervisory and enforcement roles. Customers had none of those controls but suffered the consequences. Accountability is not a single arrow; it is a map of who could act before customers were harmed.

The unknowns remain important. The public cannot reconstruct every management meeting, all supplier dashboards, every assurance objection, every legal review, or every go-live decision. The regulatory notices give enough to assign public accountability, but they do not replace the complete evidence archive. That is acceptable only if the non-public archive remains available to regulators and governance bodies with authority to test it.

The sector lesson is operational resilience, not generic digitisation risk

It is tempting to reduce the TSB incident to a warning that digital banking is risky. That is too broad to be useful. Digital banking is now ordinary banking. The real lesson is that operational resilience has to be designed around customer outcomes when technology, suppliers, and business strategy collide. A migration can lower long-term risk and still be mishandled. A new platform can be strategically rational and still fail readiness. Innovation is not the opposite of resilience; weak evidence is.

The 2018 discussion paper at source: bankofengland.co.uk and the later FCA and PRA policy documents at source: fca.org.uk, source: bankofengland.co.uk, and source: bankofengland.co.uk give a better frame. Firms should identify important services, map dependencies, set tolerances, test disruption, communicate effectively, and learn. TSB is a concrete example of what happens when those disciplines are too weak for the level of change.

The Treasury Committee's sector report also matters because it did not treat TSB as a one-off. It connected bank IT incidents, payment-system outages, third-party dependencies, cloud concentration, customer communications, complaints, compensation, and regulatory accountability. That broader frame is why this case belongs in a 500-article risk and accountability corpus. A single outage can reveal sector governance problems when many firms share the same dependency patterns.

The same lesson applies outside banking. Enterprise-software automation often promises efficiency, faster product delivery, and lower operating cost. Those benefits are real only if the automation is observable, reversible, supported, and aligned with the people who rely on it. When the system controls access to wages, savings, rent, payroll, mortgage payments, supplier invoices, or emergency funds, the launch standard is higher than an ordinary software release.

Operational resilience is also not the same as perfect uptime. The Treasury Committee accepted that uninterrupted service is not always achievable. The accountable standard is whether disruption is anticipated, bounded, communicated, repaired, and compensated. A bank should not have to prove that nothing can fail. It should have to prove that foreseeable failure will not cascade into unmanaged customer harm.

Confirmed facts, supported inferences, and unknowns

Confirmed public facts include the April 2018 migration, the immediate technical failures after the data migration, disruption to branch, telephone, online, and mobile banking, impact on all branches and a significant proportion of 5.2 million customers, continuation of some issues until business-as-usual in December 2018, 32.7 million pounds of customer redress, and 48.65 million pounds of combined FCA and PRA penalties. These facts are grounded in the FCA and Bank of England material.

Confirmed public facts also include TSB's annual-report statements about disruption, customer frustration, repair work, and the financial impact of the incident; TSB's publication of the Slaughter and May review; the Treasury Committee's use of TSB as a central case in its IT failures inquiry; and the PRA's 2023 individual enforcement action against the former CIO. Those sources have different purposes, but together they create a coherent public record.

Supported inference includes the conclusion that the key accountability surfaces were migration readiness, end-to-end testing, supplier oversight, customer access, authentication, transaction integrity, branch and call-centre fallback, fraud-risk communication, complaints, redress, and board-level decision rights. The inference is supported by the nature of a core-banking migration and by regulator findings about governance, operational risk, outsourcing, and continuity.

Unknowns remain. The public cannot see the full test evidence, all known defects at go-live, every supplier assurance artifact, complete traffic and capacity telemetry, all customer data-exposure events, every fraud-related customer case, full transaction-reconciliation logs, every branch workaround, and all board or executive discussions. The public also cannot know from open sources exactly which evidence would have changed the go-live decision if weighed differently. Those unknowns should not be filled with speculation. They define the evidence that should be retained and available to authorised reviewers.

This distinction protects the record from overclaiming. It is enough to say regulators found widespread and serious failings. It is enough to say customers were materially affected. It is enough to say outsourcing did not remove accountability. It is not necessary to invent motives, allege unsupported misconduct, or claim access to private forensic files. Daniel Kade's standard for this case is a forensic timeline anchored to public evidence, not a morality play.

What durable repair should prove

A durable repair file after the TSB migration should prove that the bank knows which important business services are supported by which systems, suppliers, people, and data flows. It should show the customer journeys that were tested before launch, the defects known at cutover, the decision criteria for proceeding, the authority to delay, the fallback arrangements, and the way risk was explained to the board and regulators. It should also show whether supplier reporting was independently challenged.

At the service layer, the file should prove that customers can log in, view accurate balances, make and receive payments, use cards, manage mortgages and business accounts, contact the bank, visit branches, and recover access during disruption. At the security layer, it should prove that authentication, account confidentiality, fraud monitoring, and communication controls remain strong during service instability. At the transaction layer, it should prove that payment state, duplicate attempts, failed transfers, delayed credits, and customer corrections can be reconciled.

At the customer layer, it should prove that vulnerable customers, small firms, customers near payment deadlines, and customers with complex branch needs were identified and supported. At the complaint layer, it should prove eligibility rules, case prioritisation, evidence standards, customer communication, redress amounts, and appeal routes. At the governance layer, it should prove executive ownership, supplier challenge, board reporting, regulator communication, and lessons carried into future change programmes.

The repair should be replayable. A reviewer should be able to reconstruct what the bank believed before migration, what failed after cutover, how the bank prioritised fixes, what it told customers, when it changed the message, how it measured harm, what controls were strengthened, and how it verified that business-as-usual had returned. Without a replayable file, the bank asks customers and regulators to trust confidence language after confidence has already failed.

The Slaughter and May review, annual reports, FCA and PRA notices, parliamentary evidence, and operational-resilience policy all point toward the same conclusion: repair is not only restoring the platform. It is restoring the chain of evidence between control and customer outcome. That is a higher standard than technical recovery, and it is the right standard for a bank.

The repair file should also preserve the customer-cost trail that normal engineering dashboards miss. A service can be marked available while customers are still waiting for callbacks, while small firms are checking whether a missed transfer cleared, while branch staff are manually explaining uncertainty, and while complaints teams are asking customers to prove losses created by the bank's own outage. A migration postmortem that focuses only on platform stability leaves those costs outside the accountability boundary.

A stronger file would connect each restoration milestone to customer experience: login success, balance accuracy, payment completion, call-answer time, branch service time, complaint intake, redress decision, and fraud-warning delivery.

The same file should show how lessons were converted into future controls. It is not enough to say lessons were learned. Which go-live gates changed? Which supplier attestations were no longer accepted without independent challenge? Which customer journeys became mandatory test cases? Which severe-but-plausible scenarios were added to resilience exercises? Which board metrics changed from programme progress to customer-service survivability? Which executive could now delay a migration if business pressure conflicted with evidence? These questions matter because repeated transformation is normal in banking.

A single repaired incident does not protect customers if the next programme uses the same weak proof model.

The file should also explain how manual operations were protected during automated failure. Branch staff, call-centre staff, complaint handlers, fraud teams, payment-operations staff, and supplier engineers became part of the customer control surface once digital channels degraded. They needed reliable scripts, current status information, escalation authority, transaction-state evidence, and permission to prioritise customers whose harm could not wait for a complete technology explanation. If those teams lacked accurate information, the bank effectively moved uncertainty from systems into people.

Durable repair therefore has to include staff-facing evidence: what employees were told, how advice changed, what data they could trust, what exceptions they could grant, and how customer outcomes were recorded after emergency workarounds ended.

There is also a cultural repair requirement. During a strategic migration, teams can become fluent in programme vocabulary and less fluent in customer harm. Status can drift toward percentage completion, defect counts, environment readiness, supplier milestones, and launch windows. Those measures are useful, but they are not enough. The bank also needs a live view of how failure would feel to a pensioner without digital confidence, a sole trader waiting for payroll funds, a branch adviser facing a queue, or a fraud team handling confused callers.

Operational resilience becomes durable only when those customer realities shape the cutover decision before the incident, not only the apology after it.

Accountability follows control over the migration

The final accountability allocation follows practical control. TSB controlled the customer relationship, the regulated duty, the decision to proceed, the board and executive governance structure, the communication to customers, the complaint process, and the redress programme. Suppliers controlled parts of platform delivery and evidence generation, but supplier control did not erase TSB's duty. Regulators controlled enforcement and policy response. Customers, small businesses, and branch staff had to absorb disruption with very limited visibility.

This allocation does not mean every harm can be reduced to one decision or one person. Complex migrations fail through chains: strategic pressure, supplier dependency, weak challenge, insufficient testing, optimistic reporting, poor fallback, overloaded support, and slow evidence. The accountability question is whether each party with authority used that authority before customers were harmed and during recovery.

TSB's record is therefore larger than a failed technology project. It is a case study in how operational resilience becomes real: through customer access, supplier governance, senior-management responsibility, complaint recovery, and public evidence. The public sources at source: fca.org.uk, source: bankofengland.co.uk, and source: tsb.co.uk show a record substantial enough to learn from, even though the full private archive remains closed.

The durable lesson is direct. A bank may modernise its platform, change suppliers, automate workflows, and redesign its operating model. But once the cutover affects live access to money, the proof burden changes. The bank must prove readiness in customer terms, not programme terms. It must prove that outsourcing is governed, not assumed. It must prove that fallback protects people, not only systems. It must prove that redress follows harm, not convenience. That is why TSB made banking migration a customer-access accountability test.