Every major European bank is running core banking systems built on technology that predates the internet. In many cases, the core transaction processing platforms date to the 1970s or 1980s — written in COBOL (Common Business-Oriented Language — a programming language developed in 1959 that remains the foundation of many core banking transaction processing systems today), running on mainframes, maintained by a diminishing population of specialists who understand them, and holding the authoritative record of every customer account, every transaction, every financial position that the bank has. They are, by almost every conventional measure, obsolete. They are also, by almost every operational measure, indispensable.
The gap between those two observations is where most core banking transformation programmes live — and where most of them fail.
Why Banks Cannot Simply Replace Core Systems
The conventional narrative about core banking modernisation treats legacy systems as a technical problem with a technical solution. The system is old; replace it with something modern. The logic is clean. The execution is not. The reasons banks cannot simply replace core systems are numerous, but they cluster around three fundamental difficulties that the clean narrative consistently underestimates.
The first is operational risk at a scale that has no parallel in other industries. A core banking system processes millions of transactions daily, maintains the authoritative record of customer funds, and operates within a regulatory framework that imposes strict requirements on data integrity, availability and auditability. The consequences of a failed migration are not a degraded user experience — they are customer funds that cannot be accessed, regulatory breaches that attract immediate supervisory attention, and reputational damage that can persist for years. The risk calculus is fundamentally different from replacing an ERP (Enterprise Resource Planning) system or a CRM (Customer Relationship Management) platform.
The second is the undocumented complexity that accumulates over decades. Core systems that have been in production for thirty or forty years contain business logic that exists nowhere but in the code — logic that was added incrementally, often without documentation, to handle edge cases, regulatory changes, product variations and operational exceptions that have long since passed from institutional memory. Migrating a core system does not mean rewriting known functionality; it means reverse-engineering decades of undocumented business rules and ensuring that nothing is lost in translation. The discovery of this complexity, in almost every programme I have observed or been involved in, takes significantly longer than planned and costs significantly more than estimated.
The third is the integration estate that has built up around the core. A mature banking platform is not a standalone system — it is the hub of a network of integrations: payment processors, reporting systems, risk platforms, regulatory reporting feeds, customer-facing digital channels, partner bank connections. Every one of those integrations was built against the specific behaviour and data structures of the existing core. A replacement system that changes the data model, the API behaviour, or the processing sequence forces changes across that entire integration estate. In practice, this means that "replacing the core" is a programme that touches almost every system in the bank.
"The difficulty is not replacing the technology. The difficulty is replacing decades of accumulated, undocumented business logic without losing any of it — in a live production environment, with zero tolerance for error."
The Three Approaches — and Why Each Has Limits
Faced with this challenge, banks have historically pursued one of three strategic approaches. Each has genuine advantages. Each has limits that are frequently underestimated at the outset.
Big-bang replacement — replacing the core system in a single, defined cutover event — is the approach that is most intellectually clean and most operationally dangerous. It promises a definitive break from legacy and a known endpoint. The risk is concentrated: if the cutover fails, or if the new system contains errors that were not caught in testing, the consequences are immediate and severe. Several high-profile banking migrations have demonstrated what that failure looks like. The programmes that succeed with big-bang approaches typically share one characteristic: they have invested more in testing — specifically in production-equivalent parallel running — than any other activity in the programme. The programmes that fail typically ran out of time and compressed testing.
Progressive modernisation — moving functionality incrementally from the legacy core to a new platform, running both systems in parallel during the transition — reduces the concentration of risk but significantly extends the programme timeline and creates a sustained period of dual-system operation that is expensive, complex and introduces its own category of reconciliation risk. The danger in progressive approaches is not the cutover event — it is the accumulation of complexity as the two systems diverge over time. Maintaining synchronisation between a legacy system and its replacement, across an evolving regulatory and operational environment, is a sustained operational challenge that most programmes underestimate.
The strangler-fig pattern — building new capability around the edges of the legacy core, gradually reducing its scope until it can be decommissioned — has become fashionable as a lower-risk alternative to direct replacement. It works well for adding new capabilities and channels without touching the core. It is less effective at actually decommissioning the legacy, because the core's residual scope — the transaction processing and account management functions that everything else depends on — is precisely the functionality that is hardest to replace incrementally. Programmes that start as strangler-fig approaches frequently evolve, years in, into big-bang replacements of the residual core.
The most successful core modernisation programmes I have observed combine elements of all three approaches: a strangler-fig strategy for new capabilities and channels, progressive migration for defined functional domains with clear boundaries, and a planned big-bang cutover for the residual transaction processing core — with comprehensive parallel running and a tested rollback plan. None of this eliminates the risk. All of it makes it manageable.
What the Successful Programmes Do Differently
Having observed both successful and failed core banking transformation programmes, the differences are consistent enough to generalise.
They invest disproportionately in discovery. Before writing a line of new code, successful programmes spend substantial time and money understanding the existing system: documenting the business logic, mapping the integration estate, identifying the edge cases and exceptions that the code handles and the documentation does not mention. This investment feels expensive before a line of code has been written. It is the difference between knowing what you are building and discovering it mid-programme.
They treat data migration as a first-class workstream. In most core banking programmes, data migration is treated as a technical task that happens near the end. In the successful programmes, it is a parallel workstream that runs from the beginning — because the data quality problems that will complicate migration are present in the existing system, and identifying them early is vastly cheaper than discovering them during cutover.
They build rollback capability and test it. The go/no-go decision at cutover depends on having a tested, reliable rollback option. Programmes that treat rollback as a theoretical option rather than a tested operational procedure are making a commitment to the new system before they have evidence that it works correctly in production. That commitment is made under pressure, at the worst possible time.
They maintain executive commitment across political cycles. Core banking programmes take years. In that time, sponsoring executives move on, regulatory priorities change, and the organisation's risk appetite fluctuates. The programmes that complete are those where institutional commitment — including board-level commitment to the risk and cost — is sustained across those changes. Programmes that depend on a single sponsoring executive rarely survive that executive's departure intact.
Questions for Technology and Business Leaders
- Have you completed a comprehensive discovery of the business logic embedded in your core system — including the undocumented logic that exists only in the code?
- Have you mapped your full integration estate against the core, and assessed the cost of remediating those integrations as part of the programme?
- Is your programme approach matched to your organisation's actual risk appetite — not the risk appetite it claims, but the one it will demonstrate when a cutover goes badly?
- Is data migration a first-class workstream with dedicated resources and a clear plan, or is it a task scheduled for the end of the programme?
- Do you have a tested rollback plan that could be executed within a defined timeframe if the post-cutover production environment reveals critical defects?
- Is the board-level commitment to this programme — including commitment to the cost, the risk and the timeline — documented and tested against realistic scenarios, not just the optimistic one?
Core banking modernisation is not impossible. It has been done successfully, by banks with the discipline and the resources to do it properly. What it is not is simple, quick or cheap — and the programmes that approach it as though it were one of those things reliably produce the expensive failures that make the next programme harder to sponsor.