Somewhere in your bank, a core system built fifteen, twenty or forty years ago is approving a transaction right now. It works. It has worked for years. And every year it costs a little more to keep working than anyone has written down.

I call that the legacy tax. Most banks pay it without ever seeing the invoice, and in the AI era the invoice is growing. In this piece I want to itemise it, explain why AI has not made it go away, and describe how we at Intellect are approaching it, and legacy modernisation in particular, with MSOCK. I will also be clear about which of our results are proven and which are still in progress, because CIOs and boards are right to ask.

Running to stand still

Banks spend more on technology than almost any other industry, typically 6% to 12% of revenue against 3.75% to 5% in telecoms, media and technology.¹ A lot of that spend never reaches a customer. McKinsey puts technical debt at roughly 40% of IT balance sheets.²

Legacy looks different in different places. In the US and Europe it often means mainframes written in the 1980s. In Asia, the Middle East and Africa, most cores date from the 2000s. They are younger, but heavily customised, and they were built before mobile-first banking, real-time payments and open APIs. The pattern underneath is the same everywhere. Patches, customisations and acquisitions pile up, the people who understood the original design retire or move on, and the system slowly drifts out of understanding. A system nobody fully understands is expensive to run and frightening to change.

What the tax is made of

Deloitte advises banks to judge legacy systems on total cost of ownership, not purchase price, and warns that the cost and risk of running outdated cores only grow the longer banks wait.⁴ Most of the published research comes from US and European banks and the exact numbers vary by market, but I see the same five costs in every one of them.

Run cost

The first is run cost. In a McKinsey survey of CIOs at financial services and technology firms, 10% to 20% of the budget meant for new products was being diverted to deal with tech debt, and 30% of CIOs put it above 20%.^2,3

Speed

The second is speed. On legacy architecture, a new solution takes nine to eighteen months to reach production. On modern, modular stacks it takes three to four.⁵

Customers

The third is customers. McKinsey found that in 2018 about a quarter of new US current account customers stayed with their existing bank without shopping around. By 2025 that had fallen to 4%.⁶ Frustrated customers rarely complain. They leave, and where instant payments and digital challengers make switching easy, they leave faster.

Compliance

The fourth is compliance. Regulators now treat IT resilience as a supervisory matter, not a technical one. One Asian central bank stopped a large private bank from launching new digital products in December 2020 after repeated outages,⁷ and in April 2024 barred another from onboarding customers online, citing deficiencies in IT risk management.⁸ In Europe, the Digital Operational Resilience Act has applied since January 2025.⁹

People

The fifth is people. Many institutions run critical, high-volume transactions on systems that only a handful of engineers understand. Every resignation becomes an operational risk.

The part that never shows up on a budget line

Those five at least appear somewhere, in a budget, a regulator’s letter or a deposit report. The bigger share doesn’t. It sits in slower change, repeated discovery, integration work, rework, and the engineering time spent just understanding how something works before anyone can change it.

Over decades a bank accumulates knowledge in its business rules, product logic, processes, APIs, integrations, data relationships, exceptions, regulatory requirements and the decisions made during earlier transformations. That knowledge is spread across code, documents, diagrams, databases, interfaces and people. The problem is rarely that documentation doesn’t exist. It is that the knowledge is fragmented and nobody can see how the pieces connect. That is what makes change expensive, and why I think of the legacy tax as a knowledge tax.

It also compounds. Six in ten CIOs in McKinsey’s survey said their tech debt had risen perceptibly in the previous three years.³ Every new application layered onto an ageing core makes it more entangled and more costly to modernise next year than this year.

Why faster code has not meant faster modernisation

Many banks are hoping AI is the way out, and the prize is real. McKinsey estimates generative AI could add $200 billion to $340 billion a year to global banking.¹⁰ But PwC’s 2026 survey of 4,454 CEOs found that 56% had seen neither higher revenue nor lower costs from AI so far, and that companies with strong AI foundations were three times more likely to report meaningful returns.¹¹ My own view is that for a bank, the foundation is the core. Modernisation is no longer only about cutting run costs. It is the price of entry to the AI era.

AI has made writing software dramatically faster. Developers can generate code, refactor, write tests and automate repetitive work at a pace we have not seen before. Yet many banks that have added copilots and coding agents tell me large transformations still take about as long as they did.

Take a request that sounds simple: change this business rule. The code may be easy. But before touching it, the bank needs to know which applications and APIs use the rule, which processes and customer journeys depend on it, which downstream systems consume its output, what regulatory obligations are attached to it, and what happens if it changes in one system and not another. The answers exist, but they are scattered across code, documents and people. Without that context, AI simply helps a bank produce changes faster than it can assess their consequences.

­­­­Understanding before action

This is the problem MSOCK, the Multidimensional Multilayer System of Connected Knowledge, was built for. It connects what a bank knows about its own systems (business rules, processes, APIs, code, data and obligations) into one map that people and AI can both query, and it works in five stages: understand, visualise, assess, act and govern.

For any proposed change, it assesses the blast radius: what the change directly touches, what needs regression testing, and what is safe to leave alone, each with its evidence and a confidence level. Where it cannot read something, it says so rather than guessing. Four engineering machines then act on that understanding across the lifecycle (build, change, run and modernise), and a command centre keeps each change under named human authority, with the evidence recorded at each gate.

MSOCK is not another copilot. It sits beneath the copilots and coding agents a bank already uses and gives them the enterprise context they lack, so the existing investment stays in place and gets more accurate. And because every change is traced to the rules and obligations it touches, the record a regulator or auditor asks for is built as the work happens, not reconstructed afterwards.

Modernisation that starts from knowledge

Most modernisation approaches start from the code. They rehost it, or transpile it into a newer language, and the bank ends up with the same logic that nobody can read, now on a different platform. Others start with a rewrite from interviews and documents, and discover halfway through that the system does things nobody mentioned. Both fail for the same reason. Nobody knew what the old system actually did.

We approach it the other way round, in three phases that we call Harness, Map and Assure.

Harness

In the Harness phase, MSOCK reads the whole estate as it runs today (programs, screens, batch jobs, data files, interfaces) without rewriting anything, and builds a connected map of what the bank actually does. Every fact in the map is traced back to the exact line of code that proves it, and the map shows how complete it is, so nobody mistakes a documentation gap for a fact about the system. Domain experts verify what it found. Nobody has to write the documentation from memory.

Map

In the Map phase, the legacy map is then matched, dimension by dimension, against the map of the target platform. For us the target is eMACH.ai, whose packaged capabilities are already described in the same structure, so this is a comparison of knowledge with knowledge, not a translation of code. Each dimension is classed as a fit, a partial fit, a gap, or something that needs more discovery. Fits are re-hooked onto existing capabilities, partial fits get adapters, and only the genuine gap is built new.

On an illustrative mainframe funds-sweep system we mapped, nine of 21 dimensions were a direct fit, nine were partial, two were gaps and one needed discovery. That is a realistic picture. The bank-specific logic that makes it a bank is usually the part that needs building, and everything else does not.

Assure

Assure is the last phase, and it is where I would press any vendor hardest, ourselves included. Before any traffic moves, we replay recorded production days from the old system against the new one at full volume and compare outputs field by field. We certify that non-functional behaviour, such as throughput, availability and recovery, is at least equal. Failure is rehearsed before cutover, rollback is rehearsed, and the old system stays the system of record for each capability until the evidence for it is filed. Each wave goes live only when the evidence exists, not when a workshop agrees that it should.

The same approach applies whether a bank is on a 1980s mainframe or a customised 2000s core, and whether it is moving to our platform or to another modern one.

What we have seen so far

Intellect has been using MSOCK on its own delivery. On one live reference engagement across 140 projects within Intellect, change cycle time fell from three months to three weeks, engineering effort from 180 days to 45, and total project effort from 170 person-months to 50. An 11-month project was delivered in six. These are our own figures, from our own work, and I would not ask you to treat them as a forecast for your estate.

Three bank cases, with their status as it stands today:

I would add one more case with a caveat. An incentive engine at a large public-sector bank in Asia was delivered 3.5 months early, with 301 working days against 685 planned, using our AI-driven delivery method before MSOCK was launched. It shows the approach MSOCK builds on, not MSOCK itself.

Taken together, these point the same way. Mapped back to the tax: shorter cycles go after the speed cost, lower effort releases run budget for growth, a precise view of impact reduces the incidents that invite regulators in, and a living map of the estate turns what retiring experts know into an institutional asset.

Making the case to the board

Boards fund outcomes, not architecture. The strongest modernisation cases I have seen fit on one page and are written in currency, not technical debt. Put a number on the run cost released and when. Put a number on revenue from launching products in months rather than quarters, and on the deposits you keep through better digital journeys. Estimate the probability-weighted cost of a regulatory action or a major outage with and without modernisation. List the critical systems that depend on a handful of engineers and what it costs if they leave. And name the AI use cases your current core blocks, with the value they would unlock.

Then close with one clear, bounded ask. Not a five-year programme, but a short and measurable first step that proves the numbers on your own estate.

A small first step: the Three-Week Open Challenge

The decision in front of you

For years the argument for waiting was that the tools would get better. They have. If tech debt already absorbs 10% to 20% of every new-product budget, and every year on a core that AI cannot understand is a year your competitors spend building their lead, then delay is now the expensive option.

The legacy tax is optional. It just doesn’t feel that way until you can see what you are paying.

Sources

1. McKinsey & Company, Managing bank IT spending: Five questions for tech leaders, October 2024
2. McKinsey & Company, Breaking technical debt’s vicious cycle to modernize your business, April 2023
3. McKinsey & Company, Tech debt: Reclaiming tech equity, October 2020
4. Deloitte, Modernizing legacy systems in banking
5. McKinsey & Company, Unlocking value from technology in banking: An investor lens, October 2024
6. McKinsey & Company, Global Banking Annual Review 2025, October 2025
7. Financial press reporting on a central bank’s restrictions on a large private bank’s digital launches, December 2020 and March 2022
8. Press Trust of India, report on a central bank’s restrictions on a private bank’s online onboarding and card issuance, April 2024
9. Regulation (EU) 2022/2554, Digital Operational Resilience Act, applicable from 17 January 2025
10. McKinsey & Company, Capturing the full value of generative AI in banking, December 2023
11. PwC, 29th Global CEO Survey, January 2026