Legacy System Modernization in Banking: Tech, Regulation, or Both?

On 31 January 2025, customers at one of the UK’s largest banks began experiencing problems with payments and digital banking. The timing could hardly have been worse. It was payday for many people and the deadline for millions of taxpayers to submit and pay their self-assessment tax bills. Barclays later told the UK Parliament that 56% of online payments attempted during the incident had failed after its mainframe processing performance severely degraded.

Customers are accustomed to digital services that are immediate and continuously available, but the infrastructure that supports many banking services was built in a different era. Banking requires complex infrastructures that can’t be changed overnight, and every significant change has to account for security, auditability, and regulatory requirements, often while the underlying services remain live.

This is why the usual explanation for slow banking innovation often falls short. Legacy system modernization matters, but replacing old technology does not remove the rules governing how that technology can change. Regulation and governance create another constraint on how quickly systems can be built, reviewed and released.

So where is the real bottleneck? Is it the technology banks are trying to leave behind, the regulation they cannot afford to bypass, or the way the two collide every time something needs to change? In this article, we’ll unpack where that bottleneck really sits and explore a more practical way for banks to move forward without solving one problem only to create another.

Key Takeaways

• Customers increasingly expect mobile banking to be fast, reliable, and continuously available.
• Banks face two distinct constraints: legacy infrastructure that is difficult to change and compliance requirements that govern how changes reach production.
• Replacing or migrating technology does not automatically remove either constraint
• Incremental core banking modernization can reduce operational risk by changing systems in smaller, more manageable units.
• AI-assisted software delivery can reduce the manual work of understanding and testing legacy systems, provided governance and human review remain built into the process.

The Digital Expectation Banks Can't Ignore

The Barclays incident was not an isolated reminder of how dependent customers have become on digital banking. In March 2025, the UK Parliament’s Treasury Committee reported that nine major banks and building societies accumulated at least 803 hours of unplanned technology and systems outages between January 2023 and February 2025. That is equivalent to more than 100 eight-hour working days. Across 158 incidents, millions of customers experienced problems accessing or using banking services. The causes varied from system updates to internal software failures.

At the same time, customer expectations continue to rise. Forrester reported that in 2024, 73% of online adults in Australia, 68% in the UK, and 65% in the US agreed that they should be able to accomplish any financial task through a mobile app. For many customers, mobile is now the primary way they expect to interact with their bank. Those expectations are very unlikely to unease. Latinia’s Banking Agenda 2026 argues that speed, personalization, and trust are becoming baseline conditions rather than a source of lasting differentiation.

Competition from digital-native providers adds further pressure. Finance Magnates reported research showing that 44% of young UK consumers believe neobanks offer significantly better tools and services than high-street banks.

The practical issue is that customers rarely see the complexity behind the experience. When they open their banking app, they do not see the mainframe processing a transaction, the integrations connecting it to other systems, or the internal testing, approval, and compliance processes that guide a release.

That disconnect can make slow digital delivery look like a purely technical problem. But the constraint is broader than the technology itself. The underlying technology determines how difficult a change is to make, but governance, and regulatory compliance banking requirements have a significant impact on whether that change can move safely from staging to production. That is why focusing on legacy systems in banking alone gives an incomplete picture of the problem.

,Why "Just Modernize the Legacy Systems" Is an Incomplete Diagnosis

There is good reason for legacy technology to take part of the blame here. Older systems can absorb resources, accumulate dependencies, and make relatively ordinary changes difficult to deliver. But legacy system modernization cannot be treated purely as an infrastructure project, it needs an integrated approach.

The Legacy Infrastructure Drag

The maintenance burden alone can cause significant inefficiencies. Research from payments technology provider RS2, reported by IT Pro, estimated that banks spend around 70% of their IT budgets maintaining legacy systems. That leaves a considerably smaller share available for new products or transformation initiatives.

The cost is particularly visible in core banking. The Banker reported research estimating that UK banks would spend £3.3 billion in 2026 to maintain outdated core banking systems. Bankers even described these systems as a ‘bottomless pit’ of wasted resources.

Unlike neobanks and fintechs, core banking systems weren’t built in a digital environment from the start. Some of the technology behind core banking systems is rooted in the 1970s and 1980s, when transaction processing required to handle large volumes reliably and with minimal downtime, like reported by McKinsey. Many of these systems weren’t designed around customization, integrations, or rapid release cycles. A change in a single component may affect many others: payments, fraud systems, reporting, or customer communications.

The problem is also widespread. An FCA study found that 92% of UK financial services companies still relied on legacy technology, while an IBS Intelligence research concluded that 55% of banks regard legacy limitations as their single biggest barrier to achieving business goals. Yet replacing the technology does not remove all sources of friction.

The Regulatory Drag That Rarely Gets Named

Even though software changes are more than welcome in the baning environment, they still need to satisfy requirements around security, operational resilience, privacy, risk, and accountability. IT teams need to know exactly what changed, which tests were performed, who reviewed the work, and whether the release can be reversed if necessary.

Those requirements affect delivery regardless of the systems on which the banking service was built upon. In a 2021 survey of more than 150 senior banking leaders, OneSpan and Arizent found that 48% of financial institutions said regulatory compliance had slowed innovation, considering it a serious roadblock for digital banking transformation. This shows how modern architecture can make software easier to change. But it does not yet remove the need to prove that the change is safe, controlled, and compliant with demanding regulations.

Why the Standard Fixes Fall Short

When legacy systems become a constraint, there are two frequent approaches: replace the platform entirely or move it to new infrastructure.

Rip-and-replace

• It offers the possibility for a clean break, but it may also bring unnecessary risk to an already delicate operation.
• Core banking infrastructure is highly interconnected. Replacing a large part of it at once concentrates migration, integration, and testing into a single program, increasing the risk of disruption.
• The bank must get the new system working while preserving service continuity and meeting the same operational and regulatory requirements.

Lift-and-shift

• Moving an application to the cloud may improve where and how it runs, but it does not necessarily fix the application itself.
• If the software is difficult to change or depends on connections that are poorly understood, those problems remain after the move.
• Migration also does not remove governance requirements. Changes still have to meet the bank’s own standards and regulatory procedures.

How Incremental, Governed Modernization Closes the Gap

What banks actually need is not another legacy system modernization project followed by a separate compliance phase. Modernization and governance need to happen as part of the same process, so the information required for review is gathered as changes are made.

Putting that model into practice starts by reducing the size and uncertainty levels of each change. Rather than replacing the entire system at once, you can isolate specific areas, services, or products that need improvement and modernize them independently. McKinsey describes decomposition and decoupling as ways banks can reduce complexity and make future changes easier.

This kind of incremental core banking modernization limits the potential impact of each change. Smaller changes are easier to test, review, monitor, and reverse if something does not work as expected. Teams can keep a clear record of what changed, how it was tested, and who approved it, rather than reconstructing that evidence afterwards.

Architecture matters too. Simply moving a complicated old system into modern infrastructure does not necessarily make the system easier to change. Separating functions, standardizing how systems communicate with one another, and improving how data is organized can help ensure that modernization removes existing constraints instead of carrying them into a new environment.

This is where AI-assisted software delivery can be ohelp. Engineers working with systems built over decades often have to understand code they did not write, identify which other systems depend on it, and work out what might be affected by a change. AI-assisted engineering can help explain unfamiliar code, map dependencies, suggest tests, and identify potential downstream effects.

The real cost of ungoverned AI-assisted delivery is that greater speed can come at the expense of visibility and control. The aim is not autonomous modernization. The strategy is to use AI-assisted software delivery to speed up the work without turning development into a black box. Engineers still review the proposed changes, compliance teams can see what changed and why, and the bank keeps control over what ultimately reaches production.

Where DesignVerse Fits

DesignVerse applies that model by creating a governed engineering context layer from a bank’s existing code, documentation, architecture, and engineering standards. Instead of treating AI as a generic coding assistant working from isolated prompts, DesignVerse gives AI-assisted engineering access to the context of the environment it’s changing. That makes a significant difference when improving existing banking systems, where the challenge is rarely starting from scratch.

With DesignVerse’s engineering context layer every change is recorded as hashed, attributable, revertible version, making traceability part of the process rather than something assembled later for an audit. This keeps the whole process of change auditable by design.

It also adds a safeguard to your deployment, by keeping it inside a controlled environment like a private cloud, on-premises infrastructure, VPCs, or air-gapped configurations, with role-based access control and isolated environments.

For core banking modernization, payments, and digital channels, that means teams can work incrementally on existing systems while keeping the engineering context, governance, and reversibility. The goal is to address regulation and legacy complexity as two key components of the same delivery process. See how DesignVerse for banking and financial services can help you.

Conclusion

The pressure behind digital banking transformation is clear. Customers expect banking to be fast, easy to access, continuously available, and constantly improving.

Banks should assume that incidents like the Barclays outage can happen again. The priority should be to do everything that is possible to reduce the chances of disruption, limit its impact, and make complex systems safer to change. That is what this integrated approach is designed to support: more safeguards around every change, clearer visibility into what was updated and why, and a better ability to learn and adapt as technology evolves.

Effective legacy system modernization therefore requires more than replacing old technology. Banks need a delivery model that reduces technical complexity while making governance part of the engineering workflow. Incremental modernization, stronger architectural boundaries, built-in auditability, and governed AI-assisted software delivery offer a way to improve delivery speed without separating modernization from compliance.

The real challenge is not choosing between fixing legacy technology and satisfying regulation. It is finding a way to do both at the same time. A few years ago, doing that at speed and at scale may have seemed unrealistic. Today, it is not only possible, but necessary. See how DesignVerse can help your engineering teams modernize complex legacy banking systems without starting from scratch. Book a dedicated demo.

FAQs

Is legacy technology or regulation really slowing digital banking transformation?

Both can slow delivery in different ways. Legacy technology makes changes more difficult and risky, while regulatory requirements determine how those changes must be documented, tested, governed, and reviewed.

Can banks carry out legacy system modernization without replacing the entire core?

Yes. Incremental modernization and decomposition allow banks to isolate capabilities and reduce dependence on a monolithic core over time. McKinsey describes decomposition and decoupling as ways to reduce complexity and make future changes easier.

Why is core banking modernization so difficult?

Core systems connect to large numbers of applications, products, payments processes, data flows, and operational controls. Some trace their origins to platforms developed in the 1970s and 1980s, and many have accumulated decades of customisation and integration.

Why doesn’t lift-and-shift solve the problem?

Migration can move an old application to newer infrastructure, but it does not necessarily fix the application itself. If the system is difficult to change or relies on poorly understood connections, those problems can remain after the move.

How does AI-assisted software delivery help in regulated banking?

AI can help teams understand legacy code, identify dependencies, generate tests, and surface downstream risks. In regulated environments, those capabilities are most useful when human review, traceability, standards, and approval remain built into the process.