The Rapid Evolution of Banking Infrastructure: Achieving ‘Continuous Innovation’ is More Feasible Than You Think

By Brad Goad, DXC - Global Head - Banking & Payments, Commercial Lead

For most of the past decade, the conversation about banking modernization has been framed as a binary. Either an institution commits to replacing its core, with all the cost, risk, and multi-year disruption that implies, or it accepts that its legacy estate will continue to constrain what it can offer customers, regulators, and counterparties. Neither option has aged well. The wholesale replacements have a mixed track record at best, and the do-nothing path has become untenable as the world around the bank has moved to real-time.

The more interesting question, and the one a growing number of operators are now putting at the centre of their planning, is whether the choice was ever genuinely binary in the first place. The legacy core is not the problem it is often portrayed to be. The mainframe applications that still run a meaningful share of global banking deposits and payment flows are dependable, predictable, and operationally proven at a scale that newer architectures have not yet been asked to match. What they were not designed for is the tempo of contemporary financial markets. Real-time payments, continuous settlement, intraday liquidity management, and near-instant regulatory reporting all assume an operating cadence that batch-oriented systems were never intended to support.

The gap between those two realities is where the real opportunity sits. It is also where the most useful framing of modernization is now emerging: not as replacement, but as arbitrage. The objective is to retain what the legacy estate does well, the integrity of the ledger and the reliability of the rails, while removing the friction that prevents the bank from acting at the speed its market requires.

That reframing matters because it changes what a modernization programme is actually trying to achieve. Treated as a code conversion exercise, the work collapses into a translation problem. Move the COBOL to Java, refactor the data structures, run the regression tests. The reality on the ground is considerably less tractable. Many of the applications in question are inadequately documented, their dependencies undocumented or known only to individuals who have long since retired. The functionality they encode has accreted over decades of regulatory change, product launches, and tactical fixes. Before any of it can be responsibly rewritten, it has to be understood, rationalised, and then deliberately redesigned around the business outcomes the bank actually wants today, not the ones it inherited from a previous era. Programmes that skip that step tend to produce modernized versions of yesterday's bank, at considerable expense.

The alternative is to think about modernization at the architectural layer rather than the application layer. The analogy that has gained traction, and that is increasingly being adopted in core banking discussions, is the smartphone. A modern phone is not defined by any single application. It is defined by the operating system that orchestrates them, and by the ecosystem of capabilities that the operating system makes available. The user assembles an experience by composing components, not by buying a monolithic device. Banking is moving in the same direction. The institution still needs a ledger of record, and that ledger still benefits from the qualities the legacy core has always provided. What it now also needs is an orchestration layer that allows new capabilities, whether they originate in fintech partners, in-house engineering teams, or industry utilities, to be brought into production at something approaching software-industry timelines rather than traditional banking-IT timelines.

This is where the commercial logic becomes clear. Every additional capability that a bank has to integrate from scratch is a multi-quarter programme. Every capability that is pre-integrated into an orchestration layer is a configuration exercise. The compression of those timelines is what allows the bank to keep pace with real-time payments mandates, evolving reporting obligations, and the competitive pressure exerted by digitally native challengers, without taking on the existential risk of replacing the core on which the business continues to depend.

The institutions that will emerge from the next five years in the strongest position are unlikely to be those that committed earliest to a wholesale rebuild, or those that defended the legacy estate longest. They will be the ones that learned to operate both at once, deliberately, and treated the gap between them as an asset to be worked rather than a problem to be eliminated. The arbitrage between legacy and real-time is, in that sense, the defining technology question for banking in this cycle. The answers the industry settles on will shape what banks look like for a long time after the question itself has been forgotten.