Global banks spend over $300 billion annually just maintaining legacy IT infrastructure. Neobanks are operating at one fifth the cost per customer of traditional institutions. The technology debt inside financial services is no longer a background risk — it is compounding into an existential competitive threat that regulators, investors, and customers are all beginning to notice simultaneously.
There is a number that circulates among technology leaders at major financial institutions that does not appear in annual reports or investor presentations. It is the proportion of the IT budget consumed by maintaining systems that were built before most of the people maintaining them were born — keeping the lights on for infrastructure that the institution depends on operationally but that actively limits what it can build, how fast it can respond to regulation, and how competitively it can price its products. Estimates vary by institution, but the consistent finding across the industry is that between 60 and 80 percent of technology spending in established financial institutions goes to maintaining existing systems rather than building new capabilities. That ratio is the structural explanation for almost every competitive disadvantage that traditional financial institutions experience relative to their digital-native competitors.
The legacy problem in financial services is not a secret and it is not new. The COBOL applications running core banking functions at major institutions, the batch processing architectures that cannot support real-time transaction visibility, the data warehouses that were state of the art in 1995 and now require armies of data engineers to maintain — all of this has been known and discussed for decades. What has changed in 2025 is the competitive and regulatory pressure that has made the cost of continued deferral higher than the cost of addressing it, and the availability of modernisation approaches that make the transition less catastrophic than the complete core replacement programmes that have failed so visibly and expensively in the past.
The ratio of maintenance to innovation spending in traditional financial institutions is the single number that explains their competitive position relative to digital-native challengers — and it is a ratio that regulatory pressure, customer expectations, and AI adoption requirements are all making increasingly untenable. Image: Unsplash (free for commercial use — download and host locally before publishing).
What Legacy Really Costs — Beyond the Maintenance Bill
The direct cost of legacy system maintenance — the $300 billion annual figure cited by McKinsey for global banking alone — is significant but it is not the full cost. It is the visible portion of a much larger economic burden that manifests in ways that are harder to attribute directly but equally real in their impact on competitiveness and profitability.
The cost of operational risk is the most immediately tangible. TSB's migration failure in 2018 locked 1.9 million customers out of their accounts for weeks, resulted in a £330 million remediation cost, and triggered regulatory action that included a £48 million fine. The Royal Bank of Scotland's IT failure in 2012 prevented 6.5 million customers from accessing accounts for several days and cost the bank £175 million in direct costs plus the long-term reputational damage that is harder to quantify but clearly visible in the customer satisfaction data that followed. These are not exceptional events caused by unusual circumstances — they are the predictable consequence of operating complex, interdependent legacy systems that have been patched and extended far beyond their original design parameters, maintained by teams whose understanding of the underlying architecture is increasingly incomplete as the people who built it retire.
The cost of compliance is rising sharply as regulation increasingly assumes digital capabilities that legacy architectures cannot easily provide. Real-time transaction reporting requirements, the data accessibility mandates of open banking frameworks, the audit trail requirements of MiFID II and equivalent regulations, and the operational resilience standards that regulators in the UK, EU, and US are tightening — all of these impose implementation costs that are dramatically higher on legacy architectures than on modern platforms, and some of which simply cannot be met without significant architectural change. The compliance cost premium paid by institutions running legacy core systems is a persistent drag on profitability that compounds every time regulatory requirements become more demanding.
The cost of speed is perhaps the most strategically significant. A neobank with a cloud-native, API-first architecture can deploy a new product feature in days. A traditional institution with a mainframe core and a multi-layer integration stack typically measures the same change in months, sometimes quarters. In a competitive environment where customer expectations are being shaped by digital-native financial services that update and improve continuously, this speed disadvantage manifests as products that are late to market, pricing that cannot respond dynamically to competitive changes, and customer experiences that feel static relative to challengers who are iterating visibly and constantly.
The Neobank Cost Structure That Is Redefining the Benchmark
The cost per customer of a digital-native challenger bank — built on cloud infrastructure, automated operations, and modern software architecture from inception — is approximately one fifth of the equivalent figure for a traditional institution. This is not primarily an efficiency advantage from better processes or more disciplined cost management. It is a structural advantage from a technology architecture that requires dramatically less human intervention to operate, can scale without proportional increases in operational cost, and does not carry the maintenance overhead of systems that have been accumulating complexity for thirty years.
As neobanks move upmarket — acquiring more affluent customers, adding more sophisticated products, and achieving the scale at which their business models become profitable — this cost structure advantage becomes increasingly threatening to traditional institutions in precisely the customer segments where traditional banks have historically generated the most value. The retail banking customer who kept their current account at a high street bank while using a neobank for savings and international transfers is becoming the customer who keeps their current account at a neobank while asking whether they need the high street bank relationship at all. The answer, for a growing proportion of younger customers, is increasingly no.
Why Core Banking Replacement Has Failed So Often
The history of core banking replacement programmes is one of the most sobering in enterprise technology. Commonwealth Bank of Australia's core replacement, completed in 2012 after seven years and approximately $1 billion, is frequently cited as one of the few large-scale successes. For every CBA, there are multiple programmes that were abandoned after years of effort and hundreds of millions in sunk cost, or that delivered partial outcomes at multiples of the original budget and timeline.
The reasons for failure are consistent and worth understanding clearly, because they repeat across institutions and geographies regardless of the vendor chosen or the methodology applied. Core banking systems are deeply integrated with every other system in a financial institution — risk management, compliance reporting, customer relationship management, payment processing, regulatory reporting. A replacement programme must either replace all of these simultaneously — a scope so large it is nearly impossible to manage — or maintain the old and new systems in parallel during a transition that can last years, with the complexity and cost of running parallel systems adding to an already enormous programme budget.
The data migration challenge is similarly underestimated in most failed programmes. Decades of customer data, transaction history, and product configurations accumulated in legacy systems contain inconsistencies, undocumented exceptions, and structural oddities that reflect business decisions made by people who left the organisation years ago. Migrating this data to a new system accurately and completely, in a way that passes regulatory scrutiny and does not create customer-facing errors, is consistently more complex and more time-consuming than initial programme estimates project.
The organisational change dimension is the third consistent failure point. A core system replacement changes how every function in a bank operates — from the front office to operations to risk to finance. The change management required to prepare an organisation of thousands of people for a new system, while simultaneously maintaining the quality of customer service and regulatory compliance on the current system, is an undertaking that requires sustained executive commitment and dedicated resource over a multi-year programme. In practice, executive attention shifts, resource gets diverted to other priorities, and programme momentum degrades in ways that are predictable in retrospect but persistently underestimated at programme initiation.
The Approaches That Are Actually Working
The modernisation strategies generating the most promising results in 2025 share a common characteristic — they avoid the big-bang core replacement in favour of incremental approaches that decompose the modernisation problem into manageable pieces, deliver value at each stage, and maintain operational stability throughout the transition.
The strangler fig pattern — wrapping legacy systems with modern APIs that expose their functionality to new digital channels and services, while gradually replacing underlying components piece by piece — has become the dominant architectural approach for financial institutions that need to modernise without the catastrophic risk of wholesale replacement. The name comes from the strangler fig tree, which grows around and eventually replaces its host while the host continues to function throughout the process. Applied to financial services technology, it allows a bank to build modern customer-facing capabilities on top of legacy infrastructure, demonstrate their value, and incrementally replace the underlying components as confidence in the new architecture grows and as the institution builds the technical capability to manage the transition safely.
Cloud migration of non-core workloads — moving analytics, customer communication, compliance reporting, and digital channel infrastructure to cloud platforms while leaving core transaction processing on stable legacy systems — delivers the speed, cost, and flexibility benefits of cloud for the functions where they matter most, without the risk of touching the core systems where the operational consequences of failure are most severe. Many institutions have discovered that a significant proportion of the competitive capabilities their customers value most — the quality of the mobile app, the speed of customer service response, the sophistication of financial planning tools — can be delivered from cloud-hosted systems without requiring core system replacement at all.
AI and automation layered on top of legacy infrastructure is delivering operational cost reductions that are meaningful even without architectural change. Robotic process automation handling reconciliation, reporting, and data extraction from legacy systems. AI-powered fraud detection operating on transaction streams from core systems. Machine learning credit models consuming data from legacy data warehouses through modern data pipelines. These approaches do not solve the underlying architectural problem but they extract more value from existing investment while the longer-term modernisation strategy is designed and sequenced.
AI-powered fraud detection and risk management are delivering measurable operational benefits in financial institutions that layer modern capabilities on top of legacy infrastructure — demonstrating value without requiring architectural overhaul before the benefits arrive. Image: Unsplash (free for commercial use — download and host locally).
Open Banking and the API Economy: The Regulatory Forcing Function
Open banking regulation — which requires financial institutions to provide third-party providers with access to customer account data and payment initiation services through standardised APIs, with customer consent — has been the most significant external forcing function for financial services technology modernisation over the last several years. In jurisdictions where it is most advanced — the UK, Australia, and increasingly across the EU through PSD2 and its successors — open banking has required institutions to build API infrastructure that exposes core banking data to external systems in ways that legacy architectures were not designed to support.
The compliance cost of building these APIs on top of legacy infrastructure has been high — requiring integration layers, data transformation services, and security controls that add complexity to already complex systems. But the strategic consequence of open banking is more significant than the compliance cost. It has created an infrastructure layer — standardised, secure, API-based access to financial data — that enables an ecosystem of financial services innovation around the core banking relationship that institutions can either embrace strategically or watch competitors exploit.
The institutions treating open banking as a strategic opportunity rather than a compliance exercise are building platforms that attract fintech partnerships, embed their banking infrastructure in third-party services and applications, and position themselves as the invisible but essential infrastructure layer of a broader financial services ecosystem. This platform strategy requires the kind of modern, API-first architecture that open banking compliance has forced institutions to begin building — and it represents the most compelling long-term competitive response to digital-native challengers available to traditional institutions that cannot match their cost structure directly.
The Talent Problem Underneath the Technology Problem
Every financial services technology modernisation programme eventually encounters the same human constraint that is rarely discussed in vendor presentations and programme business cases: the people who understand how the legacy systems actually work are leaving the industry, and the people with the skills to build modern replacements do not want to work in financial services at the salaries that regulated institutions can offer relative to technology companies.
The COBOL developer pool is ageing. The mainframe operators who understand the operational characteristics of core banking systems well enough to manage a migration safely represent knowledge that cannot be fully documented and that retires when they do. Institutions that have not invested in knowledge transfer programmes — capturing the undocumented understanding of how systems actually behave rather than how they were designed to behave — are accepting a risk that compounds every year as experienced staff leave without adequate successors.
At the same time, the software engineers, data architects, and cloud platform specialists who build modern financial services technology have choices about where they work that include technology companies, fintechs, and digital-native banks offering more interesting work, faster career progression, and in many cases better compensation than the modernisation programmes of established institutions. The most successful financial services modernisation programmes have treated talent strategy as a programme workstream in its own right — building the internal capability to design, build, and operate modern systems rather than outsourcing it entirely to system integrators whose incentive structure does not always align with the institution's interest in building internal capability.
The institutions that navigate the legacy modernisation challenge successfully over the next decade will be those that address the technology, the architecture, the data, the regulation, and the talent dimensions as an integrated programme rather than a technology project. That integration requires a level of executive commitment, programme discipline, and organisational patience that has been the distinguishing characteristic of every successful large-scale financial services transformation on record. It is not a comfortable investment. But relative to the alternative — continuing to absorb the compounding cost of a legacy technology estate while digital-native competitors build the cost structures and customer relationships that will define the next generation of financial services — it is the only one that makes strategic sense.
