Why core banking programmes fail, and what the survivors did differently

We are usually called into a core banking programme at one of two moments: at the very beginning, when a bank is choosing a platform, or eighteen months in, when the steering committee has started asking whether the programme can be saved. The second conversation is more instructive.

Across the recoveries we have run, the failure pattern is consistent enough to be predictable. The chosen platform is almost never the cause. The cause is a set of decisions made in the first ninety days, before anyone wrote a line of configuration.

The three decisions that decide the outcome

1. Treating cutover as an event rather than a sequence

A big-bang cutover concentrates every risk in the programme into a single weekend. If reconciliation fails at 03:00 on Sunday, the options are to press on with known breaks or to invoke a rollback that has probably never been rehearsed at full volume. Neither is a decision anyone should have to make at three in the morning.

Progressive migration replaces that single decision with dozens of small ones. One product family moves. It runs in parallel with the legacy core for a full month-end cycle. Reconciliation runs nightly and must agree to the cent before the next wave is authorised.

2. Underestimating the interface estate

Every bank we have worked with has underestimated how many systems talk to the core. The documented figure is typically between forty and sixty per cent of the real one. The missing interfaces are the informal ones: a nightly file a regional office has collected since 2004, a screen-scraping script in the collections team, a reporting extract that finance considers infrastructure.

• Instrument the core to log every inbound and outbound connection for a full quarter before planning waves.
• Include quarter-end and year-end in that window, because the rarest interfaces are the ones that matter most.
• Classify each interface by consumer, criticality and whether it can be retired rather than migrated.

3. Funding the build but not the decommissioning

Programmes are funded to deliver the new core. They are rarely funded to switch off the old one. The result is an estate running two cores indefinitely, paying two sets of licences and support, with the business case quietly eroding every month.

Decommissioning should be a funded workstream with its own plan and its own milestones, and each migration wave should carry the retirement of the interfaces it replaces. Otherwise the savings that justified the programme never materialise.

What the successful programmes had in common

1. A reconciliation engine built before the first migration, not after the first discrepancy.
2. A rollback rehearsed at production volume, monthly, for the entire programme.
3. An interface inventory built from observed traffic rather than from documentation.
4. A named business owner for each product family, accountable for sign-off on their own wave.
5. Decommissioning funded as part of each wave rather than deferred to a final phase.

“Every site believed it was uniquely different. Almost none of them actually were.”

None of this is technically difficult. It is organisationally difficult, which is a harder problem, and it is why the programmes that succeed are the ones where the delivery discipline was agreed before the platform was chosen.