The trouble with technical debt

For years, I have argued with executives at banks about digital transformation and technical debt, so I finally decided to write down why and the whole issue really boils down to leadership and laggardship. Here are my thoughts:

Technical Debt: The Hidden Balance Sheet of Banking

Banks understand debt. They understand principal, interest, refinancing, maturity and default. What they often understand less well is another form of debt that sits nowhere on the balance sheet but can be just as damaging: technical debt.

The analogy is almost perfect.

A bank makes a technology decision today because it is quicker, cheaper or more convenient, but that decision creates a future liability.

The institution may postpone upgrading a core platform, bolt another application onto an ageing architecture, avoid rewriting an awkward interface, defer automated testing or create another workaround to get a product out of the door. The immediate problem disappears, but the debt remains and, just like financial debt, it attracts interest. That interest is paid every time the bank tries to change something.

A useful definition from Zendesk describes technical debt as the future cost of reworking code created by taking shortcuts today. Those shortcuts may produce faster delivery initially, but they progressively make applications harder and more expensive to change.

For a bank, however, technical debt goes far beyond badly written code. It can sit in the core banking system, payments infrastructure, customer databases, identity systems, fraud engines, APIs, compliance platforms, cloud environments and the thousands of interfaces connecting them. It also sits in operating processes built around those systems.

That is why technical debt may be one of the biggest unrecognised liabilities in banking.

How big is the problem?

Some of the numbers are extraordinary.

Research collated by Rockstar Developer University suggests that developers can spend roughly a quarter to a third of their working time dealing with technical debt, maintenance and poor code. Stripe’s earlier research estimated that developers were spending more than 17 hours a week on maintenance-related issues, while other studies put technical-debt losses at around a working day each week.

What was specifically interesting in that research is that they estimated a third of Stripe’s workforce were dedicated to technical debt compare to two-thirds or more in a traditional bank.

Think about that in banking terms.

Imagine a bank employing 10,000 people in technology. If even 20 per cent of their productive capacity is absorbed by unnecessary complexity, legacy maintenance and workarounds, the institution effectively has 2,000 technology employees working simply to service the interest on decisions made years ago. They are not building new products. They are not improving customer experience. They are not developing AI. They are keeping the machine running … and the machine keeps getting more expensive day by day.

vFunction cites McKinsey research suggesting technical debt can represent as much as 40 per cent of an organisation’s technology estate. It also points to research finding that, for more than half of organisations surveyed, technical debt consumed more than a quarter of the total IT budget. For a large global bank spending $10 billion a year on technology, even a fraction of those percentages becomes serious money.

This is why technical debt should not be discussed as an IT housekeeping issue. It should be discussed by the executive committee in exactly the same way that capital allocation, operational resilience and credit risk are discussed.

It is a business liability.

The problem with banks is that they never start again

There is an obvious reason why banks accumulate more technical debt than many other industries which is that they never get the opportunity to start with a blank sheet of paper.

A retailer might replace its e-commerce platform. A media company might rebuild its website. A startup might rewrite its application.

A large bank cannot simply switch off the core banking system on Friday evening and replace it on Monday morning.

The bank has millions of accounts, billions of historical transactions, regulatory reporting obligations, direct debits, standing orders, card authorisations, payment connections, securities systems, treasury platforms and perhaps several decades of customer records.

So, banks do what banks have always done.

They add another layer.

A system built in the 1970s gets connected to something built in the 1980s, which gets connected to something installed in the 1990s, which gets wrapped in middleware in the 2000s, exposed through APIs in the 2010s and is now being connected to artificial intelligence in the 2020s.

Every generation solves the immediate problem. Very few generations remove the previous one. This is how a technology architecture becomes an archaeological site.

Somewhere underneath the mobile banking app may sit a transaction engine written decades earlier. Between the two may sit dozens of systems translating, reconciling and moving information backwards and forwards.

Customers see a beautifully designed application. Underneath is plumbing and the plumbing matters.

Technical debt becomes organisational debt

The most dangerous form of technical debt is not always code. It is complexity. For example, Zendesk divides technical debt into several categories including architecture, infrastructure, DevOps, code, processes, security, defects and documentation. Banks tend to have all of them simultaneously.

Architecture debt occurs when hundreds or thousands of applications become tightly coupled. Changing one component requires changes to five others. Infrastructure debt appears when systems still depend on ageing servers, operating systems or middleware. Security debt builds when patches, encryption upgrades or identity architecture improvements are postponed. Documentation debt emerges when nobody is entirely certain why an application works the way it does. Process debt appears when humans become the integration layer.

This last point is particularly important.

A surprisingly large amount of technical debt inside financial institutions is disguised as operational procedure.

By way of example, System A cannot talk properly to System B so someone downloads a spreadsheet. When the data does not reconcile, someone checks it manually. When an application cannot perform a regulatory process automatically, operations staff create a workaround. Eventually the workaround becomes the process.

Five years later, nobody remembers why thirty people are performing the reconciliation every morning. They simply know that if they stop doing it, something breaks.

Technical debt has turned into organisational debt.

The interest rate keeps rising

The Bagile analysis makes another important observation which is that, as technical debt grows, the cost of making changes rises with it. Similar changes become progressively harder to implement, releases become stressful, incident investigations take longer and teams become reluctant to touch certain applications at all.

That phenomenon is painfully familiar in banking.

Ask why a seemingly trivial change to a bank account takes nine months and dozens of people and the answer is rarely that the change itself is complicated. The complication lies in everything the change touches.

A new savings product might affect the core ledger, interest calculations, statements, tax reporting, customer communications, mobile banking, internet banking, branches, call centres, regulatory reporting and data warehouses.

A fintech might change the feature in days. The bank needs a programme.

That difference is not necessarily because the fintech employs better programmers. It is because the bank is carrying decades more technical debt.

The result is that technical debt acts as a tax on innovation … or is that attacks on innovation?

Every new idea must pay the tax before reaching the customer.

This is why fintechs move faster

One reason fintech startups disrupted banking was not simply that they had better ideas. They had less history. A fintech beginning with a modern cloud architecture, APIs, modular services and a single customer database has far less inherited complexity. If the fintech wants to launch a feature, there may be relatively few dependencies. The established bank may want to launch exactly the same feature, but first has to navigate twenty existing systems.

That difference creates the illusion that fintechs are inherently faster.

They are not.

They are lighter but this advantage does not last forever.

A fintech that survives for ten or fifteen years begins accumulating exactly the same problem as a traditional bank. Products get launched quickly. Exceptions appear. Acquisitions introduce another technology stack. Developers leave. Documentation ages. APIs multiply. Temporary fixes become permanent.

Today’s elegant fintech will become tomorrow’s legacy bank. Technical debt is not an incumbent-bank problem. It is a time problem.

Every technology company accumulates it.

The dangerous phrase: “we’ll fix it later”

Some technical debt is perfectly rational.

vFunction makes the useful distinction that not all debt is bad. Organisations sometimes deliberately accept technical debt in order to release software quickly or meet an important deadline. The danger arises when that debt is allowed to become embedded in the architecture and progressively moves the organisation away from its intended technical design.

This is exactly like financial leverage.

Borrowing is not inherently bad. Borrowing without knowing how you will repay it is.

A fintech may quite sensibly launch a minimum viable product knowing that parts of the platform will need rebuilding if the business succeeds. The problem appears when the business succeeds spectacularly. Suddenly ten thousand customers become ten million. The temporary architecture becomes critical infrastructure. Nobody wants to stop growth long enough to rebuild it and then the company raises another funding round, launches three more products and enters five countries.

Technical debt compounds.

Eventually the company discovers something deeply uncomfortable: success has made its technology harder to replace. Banks have spent decades living with this problem. Fintechs are now reaching it faster.

Then along came artificial intelligence

AI changes the equation again.

For years, technical debt accumulated because programmers could only produce software at human speed. AI can produce code at machine speed. That sounds wonderful, and in many respects it is. Developers can create applications more quickly, write tests, generate documentation and solve problems faster … but it creates another possibility. We may now be able to create technical debt faster than we can understand it.

Rockstar’s insights highlights this contradiction citing Google’s DORA research which shows that greater AI adoption is associated with improvements in areas such as documentation and code-review speed, but with lower delivery stability. Other recent surveys show widespread use of AI-generated code alongside significant developer mistrust of its output.

This matters enormously for banking.

A bank cannot allow thousands of developers and AI coding assistants to create millions of lines of software without understanding how those additions affect architecture, security, data lineage and operational resilience. AI-generated code that works is not necessarily good code. More importantly, code that works today may create dependencies nobody notices until something changes tomorrow.

MIT’s Sloan Management Review makes an interesting argument in this area that all technical debt is now AI technical debt.

Outdated infrastructure and applications do not merely increase costs. They can prevent companies from deploying AI effectively because AI depends upon accessible systems, reliable data and a flexible digital architecture.

This may be particularly important for banks because most of their AI ambitions depend upon something they have struggled with for decades.

Data.

You cannot put AI on top of bad plumbing

As I have said 1,000 times, you cannot be smart with dumb data.

Consider the AI-powered bank everyone is discussing.

An AI financial assistant understands the customer’s circumstances, anticipates cash-flow problems, moves money intelligently, identifies fraud, negotiates bills, manages investments and perhaps executes transactions autonomously.

Wonderful.

Now ask the difficult question.

Where does the AI get its information?

If customer data is scattered across forty systems, stored using different identifiers, updated at different times and governed by conflicting definitions, the AI does not magically solve the problem. It inherits it.

A customer may be classified differently by the mortgage system, credit-card platform, wealth business and current-account system. Which version is correct?

AI needs clean, accessible, well-governed data.

That means the ability to deploy AI may ultimately depend less upon which large language model the bank selects and more upon whether the underlying technology estate has been modernised.

The shiny AI interface is the easy bit. The plumbing remains the hard bit.

Technical debt becomes regulatory debt

There is another reason why banks need to treat technical debt differently from most companies which is that banks are regulated.

When an online retailer has a technology failure, customers may be unable to buy shoes for an hour. When a bank has a technology failure, millions of people may be unable to access their money.

Technical debt therefore intersects directly with operational resilience, cybersecurity, consumer protection, data governance and regulatory compliance.

Zendesk specifically identifies security debt as one category of technical debt, including outdated libraries, weak authentication and other deferred security improvements that can expose organisations to attacks and compliance risk.

For financial institutions, this is not theoretical. Every ancient dependency is potentially a vulnerability. Every undocumented interface is potentially an operational risk. Every manual workaround is potentially a control failure. Every fragile connection is potentially tomorrow’s outage.

The chief risk officer should therefore care about technical debt just as much as the chief technology officer.

The wrong answer is “replace everything”

Of course, recognising the problem produces another temptation.

Transformation.

Banks periodically announce enormous technology transformation programmes designed to replace legacy systems and eliminate decades of complexity. They often discover that replacing everything is almost as dangerous as replacing nothing. MIT Sloan makes an important point here: zero technical debt should not be the objective. Companies need to distinguish good debt from bad debt and concentrate investment on areas that create the most value.

That is a much more realistic approach for banks.

A forty-year-old system is not automatically bad because it is old. If it processes billions of transactions reliably, is inexpensive to operate and rarely needs changing, replacing it may produce little business value. Conversely, a five-year-old platform that prevents the bank launching products, accessing data or connecting APIs may represent enormous technical debt.

Age is not the measurement.

Friction is.

The right question is therefore not: How old is this system? It is: How much does this system constrain our ability to change?

That is a very different conversation.

Treat technical debt like a loan book

Perhaps banks should manage technical debt using concepts they already understand.

Imagine every significant piece of technology debt sitting on an internal balance sheet. The bank would know the principal: the estimated cost of replacing or restructuring it. It would know the interest rate: how much additional development effort, operational cost and risk it creates each year. It would know the probability of default: the likelihood that the system creates a serious outage, security incident or regulatory failure. It would know the opportunity cost: which innovations cannot be delivered because of it.

The organisation could then rank technical debt rather than vaguely promising to “modernise the bank”.

Some debt would be left alone. Some would be refinanced by wrapping legacy systems with modern interfaces. Some would be gradually amortised through refactoring. And some would need to be repaid immediately.

That is portfolio management.

Banks already know how to do it.

Put technical debt on the executive dashboard

This leads to what may be the most important change.

Technical debt needs a number.

TheFork’s proposed methodology asks the practical questions organisations often fail to answer: how much technical debt do we have, where is it located and how much investment will be required to keep it under control? Banks should be able to answer those questions.

Imagine a board technology report that showed not just project expenditure and system uptime but:

Technology debt ratio: proportion of technology expenditure devoted to servicing legacy complexity.

Change friction: how long comparable technology changes take over time.

Critical legacy concentration: percentage of strategically important processes dependent upon difficult-to-change systems.

Manual dependency: number of critical processes requiring human intervention because systems do not integrate properly.

Architecture complexity: number of dependencies required to deliver a typical product change.

Debt repayment: amount of technical debt removed during the quarter versus new debt created.

AI readiness: percentage of critical data and applications accessible through modern, governed interfaces.

Now technical debt stops being something developers complain about. It becomes measurable management information. That changes the conversation.

The 15 per cent rule

The MIT Sloan analysis, drawing on Accenture research covering 1,500 companies, found that organisations considered well positioned for change typically maintained a reinvention-ready digital core and devoted around 15 per cent of their IT budgets to technical debt remediation.

That does not mean every bank should blindly allocate 15 per cent but it does provide a useful principle.

Technical debt repayment needs a permanent budget. Not a transformation programme every ten years or a massive cleanup after something breaks. An ongoing allocation.

Every technology budget should contain money for building the future and money for removing constraints created by the past.

Otherwise, the past consumes the future.

The fintech warning

There is also an important message here for fintech founders.

Your lack of technical debt is one of your biggest competitive advantages.

Protect it.

Every shortcut taken to reach the next funding round, every undocumented API, every duplicated service and every temporary architecture decision create a claim against future engineering capacity.

When the company has twenty engineers, those decisions may seem trivial but, when it has two thousand, they become institutional.

The smartest fintechs will therefore think about technical debt before they become big enough to have a legacy problem because there is nothing magical about legacy. Legacy is simply successful technology that nobody replaced.

Technical debt is strategic debt

The big mistake is to think technical debt belongs to the technology department because it does not. Technical debt determines how quickly a bank can launch a product, enter a market, respond to regulation, integrate an acquisition, detect fraud, personalise a customer experience or deploy artificial intelligence.

That makes it strategic.

If one bank can change a product in three days and another requires nine months, the difference appears in market share. If one fintech can deploy an AI assistant across clean APIs and another spends two years reconciling data sources, the difference appears in valuation. If one institution spends most of its technology budget building and another spends most of it maintaining, the difference appears in profitability.

Technical debt therefore has an unusual property.

You rarely notice it when you create it but you do notice it when you want to do something else, and that may be the best definition of technical debt for a bank.

Technical debt is the accumulated cost of yesterday’s technology decisions imposed upon tomorrow’s business ambitions.