The Technical Debt Your Vendors Control

Jim Marous (0:00)

Your core and solution provider's technical debt is your problem. They may own the code, but your institution pays the interest every time you try to change something. Cornerstone Advisors surveyed 416 Bank and Credit Union executives for its 2026 research. More than 80% of banks and credit unions plan to increase technology spending this year, and planned system replacements are still falling well short of what actually gets deployed. Spending more and deploying less is what caring technical debt looks like. When technical debt is discussed, most of us picture a money center bank, thousands of apps stacked on each other, code written before we were born, and an army of developers keeping it alive. Then we think that isn't us, because we don't write code. We license a core, a digital platform, origination, card processing, and analytics from companies whose job it is to worry about this so we don't have to. The reasoning is comfortable, but it's wrong. Outsourcing doesn't remove your technical debt, it just changes your relationship to it. A large bank can look at its own debt and decide what to repair. You can't. You're pretty much at the mercy of your solution provider's speed of transformation. The ICBA made this point directly. Community banks outsource most of their technology, and if you keep contracting with a legacy core, you're paying the maintenance on that vendor's accumulated technical debt. You're servicing interest on architecture decisions made before most of you were at your organization. The real issue is this. Your vendor owns the technology debt, but your institution owns the consequences. McKinsey has put a number on where that ends up. Organizations in the bottom fifth of technical debt severity are 40% more likely to end up with a modernization that gets canceled or never finishes it, which is another way of describing what Cornerstone found.

Those projects don't fall short because somebody wrote a bad plan. They fall short because of what was already in the building. Over the last 10 years, banks and credit unions narrowed the digital experience gap dramatically, and that was real work. Customer can now open an account, deposit a check, and apply for a loan from a phone at an institution with maybe only nine branches. Not many people thought that would happen this fast. That's really good, but we need to finish the job because most of that investment went into customer experience, and far less went into back office that supports it. So what does technical debt actually look like at a community bank or credit union? It doesn't look like old code. It looks like a meeting I was in recently. The head of product wanted to remove the friction that a member has with digital new account opening. Many FIs are trying to solve the same problem. She outlined the solution she had reviewed, the cost, the return on investment, and the time the new process would take to put in place. Everyone in the room liked it. Then the question started, does the solution touch our core? It touches the core. Does digital have to change? Yeah, digital has to change. Does it change our internal processes? And then somebody said, hold on, can't our existing platform already do some of this?

Maybe, but nobody's sure. Nobody approached the existing core provider. And then the room did what most rooms do. It didn't say no, it said let's look into it. Six weeks later, another meeting. The solution impacted three directors and compliance, and all of them have to agree, and none of them are in a hurry. A three-month implementation will take at least nine months at best. The idea was added to a list of priorities, and the list may not get read again. And here's the parts we're sitting with. Nobody in that room did anything wrong. Every person in it was being responsible, and the institution still can't do the thing they talked about. That meeting is your technical debt. In a previous Banking Insight video, I talked about the handoffs between departments that never get automated. It's a big part of why processes don't get automated. So whose job was it to stop that meeting from ending the way it did? At a large bank, the answer is easy. There's an owner of the process, a clear understanding of what the institution's tech stack is, and its capabilities, and a line in the budget for updating it. Somebody reports on it to the executive committee every quarter. At your organization, who is that? Most community banks and credit unions have a very good IT director, who's really a vendor manager and who's really already busy. So the debt has no owner, no number, and probably no seat of the strategy table, which means updating the underlying tech stack services once every five to seven years when the core contract comes up.