A Fine That Was About Process, Not Ambition
In 2018, TSB attempted a big bang migration of its core banking platform and locked customers out of their accounts for weeks. The UK's Financial Conduct Authority ultimately fined the bank 48.65 million pounds, and the specific finding is the part CIOs should sit with: regulators cited insufficient contingency planning and untested cutover configurations, not the underlying decision to migrate the platform. TSB was not punished for being ambitious about modernization. It was punished for executing the cutover without the validation discipline that ambition required.
That distinction matters because it reframes the lesson. The failure was not that TSB tried to move off legacy infrastructure, every regulated enterprise eventually has to. The failure was treating the cutover itself, the specific hours when the old system goes dark and the new one takes over, as an engineering afterthought rather than the highest risk event in the entire program. Eight years later, that same failure pattern, an otherwise sound migration undone by an under rehearsed cutover, is still the most common way regulated modernization projects end up in regulators' reports.
Mapping Dependencies You Cannot See in a Normal Week
The first discipline in avoiding a TSB style failure is dependency discovery, and the specific trap is collecting that data over too short a window. Systems that have run for decades accumulate integrations that only activate occasionally, at month end, quarter end, or during annual reconciliation processes, and a discovery exercise run over a normal operating week will miss them entirely. The fix is mechanical but often skipped under program timeline pressure: collect dependency data across a full business cycle before finalizing a cutover plan.
This is not a theoretical risk. A parking operations migration project moving a system running on a VAX minicomputer across nearly 200 New York City locations to the cloud only surfaced its full dependency map by reconciling transactions over months of parallel running, not weeks. Legacy systems that have absorbed decades of undocumented workarounds do not reveal their true dependency graph on a compressed timeline, and compressing that discovery phase to hit a program deadline is where the TSB style risk gets reintroduced.
Rehearsal Discipline Is the Difference Regulators Actually Notice
Commonwealth Bank of Australia's 2025 core banking cloud migration offers the contrasting case. The bank ran five full dress rehearsals of its cutover, up from three originally planned, and kept customers online through a three hour core outage during the actual transition. That additional rehearsal discipline, adding two more full run throughs after the program already had a credible plan, is exactly the kind of investment that looks unnecessary until the week it prevents a TSB outcome.
Shadow running, keeping the legacy system as the system of record while the new platform runs in parallel for a full business cycle, is the companion discipline. It is expensive and operationally awkward, since it means maintaining two systems simultaneously well past the point where the new one appears to work. But in a regulated environment, the legacy system is the reference implementation against which every output from the new platform gets validated, and skipping that parallel period is how subtle calculation errors make it into production undetected.
Building Controls In, Not Auditing Them On Afterward
Regulatory frameworks like the Banking Industry Architecture Network and The Open Group's TOGAF exist to give migration programs a shared, business readable vocabulary for what a compliant system must do, rather than leaving compliance as a translation exercise performed after the technical design is finished. The US Consumer Financial Protection Bureau's Circular 2022-03, which requires adverse action notices even when a complex algorithm drove the decision, is a concrete example of a control that has to be designed into a system's architecture, because it cannot be bolted on by an audit team after the fact.
The underlying principle is that compliance is a primary design constraint, not a post deployment audit. Evidence that was never captured during a migration cannot be reconstructed later, no matter how sophisticated the audit process is afterward or how many analysts are assigned to reconstruct it from secondary records. That has direct implications for how AI readiness gets built into modernization programs specifically: if a migrated system cannot produce the explanation trail a regulator or customer is entitled to, that gap has to be closed in the architecture itself, well before launch, not patched in with documentation after a complaint arrives and the record is already incomplete.
What This Means for Your Next Cutover
If your organization is planning a core system migration in a regulated environment, the TSB fine is worth treating as a line item in your risk register, not a historical curiosity. Specifically: budget for dependency discovery across a full business cycle rather than a compressed discovery sprint, plan for more cutover rehearsals than feels necessary once the plan looks solid, and insist that compliance requirements show up in architecture reviews before build starts, not in a pre launch audit.
None of these five disciplines, dependency mapping, calendar aware sequencing, parallel validation, built in controls, and business readable governance standards, are exotic. They are achievable with existing frameworks and enough schedule discipline to resist compressing the rehearsal phase under deadline pressure. The organizations that get cited in regulatory reports are almost never the ones that lacked the technical capability to migrate safely. They are the ones that ran out of patience for the rehearsal their own plan called for.
