A shaky core cutover used to be a private engineering problem. Since 17 January 2025 it is not. DORA is in force. Article 19 sets a reporting clock for any incident that disrupts a regulated firm: an initial notification, an intermediate report when the status changes materially, and a final report once the root cause is known. Article 28 goes further. It requires exit and transition plans for critical ICT services to be comprehensive, documented and tested in advance, and it names concentration risk outright. So the seam around a core transformation - the hand-offs, the fallback, the vendor chain - is no longer only where programmes go wrong. It is where the law now expects you to have already looked.
That is the argument here, and it is tested rather than asserted. The usual "X per cent of projects fail" numbers come from firms selling the core or the delivery, and none of them cites a primary study. So this piece leans on documents nobody wrote to sell anything: an independent public-spending audit, a parliamentary committee's own correspondence, a payments-standards body's technical guidance, and - once, dated, as a landmark - a pair of binding UK regulatory notices. They point to the same four places a core programme actually breaks: integration and vendor testing, the payment and card rails, compliance timing, and the weeks after go-live. Rarely the ledger itself.
Figure 1. Core programmes rarely fail at the ledger. They fail in the four seams between the customer channels and the core.
Seam one: integration and vendor testing
The clearest recent breakdown of where the cost and time go sits in one audit. In December 2025 the National Audit Office reported on the Bank of England's RTGS renewal - a genuine payments-core migration, checked by a body with nothing to sell. The programme finished at 431 million pounds against 375 million approved, about 18 months late. Three causes carry almost the whole overrun. The first was a foundational replan: the programme moved off a Bank-wide platform onto one built specifically for it. The second was a clash of timetables it did not choose - the ECB brought its own ISO 20022 migration forward to land four weeks ahead of the Bank's, and that collision alone cost roughly 23 million pounds. The third, closer to go-live, was internal technical issues that needed more time to test and fix. One integration contract went through 47 changes on its own. None of the three is a ledger defect. The NAO treats the programme as a relative success at 15 per cent over, so read it as the anatomy of where the money goes, not a worst case.
IBM's September 2025 research found 94 per cent of banks report being behind schedule on core modernisation. BCG's Expand Research work from the same May put spend on simply running the existing estate at more than 60 per cent of bank technology budgets. It is a treadmill. Most of the money keeps the old system alive, and what is left funds a rebuild that is already late - exactly the condition under which testing and integration get squeezed.
Seam two: the payments and card rails
The industry's biggest live seam sits inside a message-format change most customers will never hear about. Under ISO 20022 coexistence, a rich MX message has to be translated down into the older, narrower MT format, and that loses information two ways. Some fields are simply too short for the content. Other elements - the ultimate debtor, the ultimate creditor, the legal entity identifier - have no home in the MT format at all. SWIFT's own convention adds a "+" to a truncated field to signal the drop, so a sanctions or financial-crime check downstream has to read that character as a warning rather than as data. Screen against the shortened text instead of the full message SWIFT keeps, and false alerts rise on legitimate payments while the real party can be missed entirely. This is not a future risk. MT decommissioning penalties start in November 2025, a structured-address mandate follows by November 2026, and as of mid-2025 only around 44 per cent of payment-instruction traffic had even started life in ISO 20022. The lossy step is running across the live network now, on both sides of every bank still mid-migration.
Seam three: compliance timing as a delivery constraint
DORA's two provisions carry more weight than the opening let on, because they change what "ready for go-live" means. Article 19's clock starts at the first sign of a major incident and stops only once the root-cause work is finished. What used to be an internal scramble is now a set of externally visible deadlines. Article 28 is quieter, but for a transformation it may matter more. Before contracting a critical ICT service, a bank has to assess concentration risk in that arrangement and hold an exit and transition plan that is comprehensive, documented and actually tested - not drafted and filed. Reach go-live on an informally-scoped test plan with no rehearsed way back, and you are not just carrying operational risk. You are very likely failing a specific, named legal duty, before anything has gone wrong.
Seam four: the weeks after go-live
Nothing about this seam is historical. The Treasury Committee's 2025 correspondence put numbers on it: between January 2023 and February 2025, nine UK banks reported at least 803 hours of unplanned outages and at least 158 separate incidents. That is a live, current volume of core-platform fragility. Barclays' own disruption in late January 2025 is instructive precisely because it was not a migration. The bank pointed to a fault in a critical module of its mainframe operating system. It still left a share of customers unable to log in or move money, with compensation running into the millions. The weeks after any core-adjacent change are where resilience is really tested - in public, in front of customers, and now against a regulator's incident clock.
The one landmark we keep, and why
Everything above is 2024 or 2025. There is one exception, used once and dated on purpose: the FCA and PRA Final Notices against TSB, issued in December 2022 over an April 2018 migration. It earns its place as the clearest case on the public record of a regulator stating, in binding language, that a core ledger migrated correctly while the layers around it came apart.
The mechanics are worth the detail. Authentication traffic for the OpenAM session component was meant to stay on a local load balancer. Instead it was, at times, sent to a global one that routed sessions to the wrong data centre. OpenAM had also been set up, in error, as a cluster spanning both sites. Together that collapsed session persistence for a bank serving 5.2 million customers.
The way the risk was handled is the real lesson. The resilience test most likely to have caught this was cut back to a single data centre by an informal decision taken outside governance - never minuted, never escalated. The fallback was then given up on 12 April 2018, while the outstanding tests it depended on only finished on 17 April, days before the go-live weekend of 20 to 22 April. The FCA's own root cause is a supply-chain visibility gap: the prime contractor sat on top of 85 further suppliers, and the bank had never secured a clear line of sight into that chain, even as it left the decisive testing to that same contractor.
The numbers close the case. The fine came to 29.75 million pounds. Redress paid to customers came to 32.7 million - more than the penalty itself - and normal service was not restored until 10 December 2018. In 2018 none of this started a statutory clock. Under DORA today the same fact pattern - an untested fallback, an unmanaged fourth-party chain - would very likely already be a breach the law had set out in advance, not a lesson learned after the fact.
Building the seam on purpose
If the failure keeps landing between the interface and a bank's own mix of systems, that space is where the deliberate engineering has to go. One of our engineers has run exactly this pattern in production. Take card personalisation - binding a blank card to a named holder - in the harder case where the card belongs to someone other than the account owner. That one action reaches across client records, the list of eligible accounts, the current status, any power of attorney on file, and a set of compliance checks that decide whether it is even permitted. Each of those lives in a different legacy system, with its own protocol and status codes.
The team's answer was to put all of it behind a single orchestration service, with a strict division of labour. The front end and its backend-for-frontend hold only display logic. Every substantive step - gathering the data, running the checks, branching the scenario, translating each legacy system's response into one clean model - lives in the orchestrator. Underneath sit individual wrapper services, one per legacy system, each hiding its protocol behind a stable interface.
Figure 2. The orchestration layer. The interface holds display logic only. One service gathers, checks, branches and translates. A wrapper per legacy system hides its protocol, and a document store holds application and session state so the orchestrator can collect, then redistribute.
A longer client-registration flow, more than ten steps deep, carries the same shape further. The orchestrator first collects, building an application entity in a document store as the customer moves through the journey. Then it fans that back out once the application is complete: run the checks, create the client, open the accounts, personalise the cards. Collect, then redistribute. When a legacy system changes, the fix stays local to the orchestrator - the exact inverse of the TSB failure the FCA described, where the hand-offs across a deep vendor chain were the one thing nobody could see into.
The lesson under all four seams is the same. Which core a bank buys matters far less than how it engineers the joins between that core, the channels, the rails and the vendors. Design those joins as first-class components. Prove they hold under load before the fallback is closed off. Make every hand-off something you can watch. Do that, and you have covered the ground where these programmes actually fail.
If you are about to run one of these programmes, we have written the orchestration-layer pattern up as a fuller practitioner guide - the wrapper-per-system model, the collect-then-distribute flow for long processes, and when the pattern is worth the extra layer. Get in touch and we will send it over.
Primary sources
- Bank of England RTGS renewal programme - National Audit Office, December 2025: nao.org.uk
- TSB core migration, April 2018 - FCA Final Notice, December 2022: fca.org.uk; PRA Final Notice: bankofengland.co.uk; FCA press release: fca.org.uk
- DORA, Regulation (EU) 2022/
2554, Articles 19 and 28 - EUR-Lex: eur-lex.europa.eu - Core modernisation progress (94 per cent behind schedule) - IBM Institute for Business Value, September 2025: ibm.com
- Run-the-bank technology spend (more than 60 per cent) - BCG with Expand Research, 2025: bcg.com
- UK bank operational-resilience incidents, January 2023 to February 2025 (at least 803 hours of unplanned outages across at least 158 incidents at nine banks and building societies) - House of Commons Treasury Committee: committees.parliament.uk; Barclays January 2025 outage cause - Barclays UK CEO letter to the Committee, 26 February 2025: committees.parliament.uk
