A colleague of mine once said, “God was able to create Heaven and Earth in six days because He did not have an installed base of users.” Anyone who has spent any time in the software business understands this axiom all too well.
This is essentially the premise behind technical debt. As soon as your institution commits to a solution and begins adding customers or members to it, constraints emerge making it difficult to enhance or upgrade the technology.
The same holds true for the company which sold you the solution. The more clients running on that system, the harder it is for them to add new functionality, particularly at the pace required given the speed of change in the digital world.
There is a cartoon I have used in my presentations to explain this conundrum. In it, a person is riding a bicycle with square wheels. Another person is running after the bicycle with round wheels. That says it all. You can’t change the tires if the bicycle is in constant motion. With software systems consumers depend on to manage their money, make purchases, withdraw cash, et al, stopping the “bicycle” to put on the round tires presents, what is to too many financial institutions, too much risk.
One of the reasons fintechs and neobanks have been able to be more innovative than traditional financial services providers is that they do not have technical debt; at least not like the legacy players do. Starting with a “blank sheet of paper” is far easier than trying to change the storyline in a 600-page book.
Additionally, these non-traditional players often are building a piece of software that sits in front of the systems where the heavy lifting is done (and the technical debt accumulates)…though some successful startups still end up with that “installed base of users,” which can slow the responsiveness to the evolving expectations of those users.
Still, these successful startups have an advantage over many banks and credit unions since everything from their development methodologies to the technology tools they are using were built in an era where continuous innovation is a requirement.
Managing Your Institution’s (Other) Debt Load
I have yet to encounter a bank or credit union whose list of worthwhile IT projects wasn’t significantly longer than the bandwidth available to tackle it. This mismatch leads to a series of prioritization exercises and painful tradeoffs, with projects rated in some fashion, e.g., Must Have, Nice to Have, and something akin to “Never Happening.”
One of the more crushing aspects of technical debt is related to the amount of time, resources and money which must be spent to “keep the lights on” – maintaining existing systems, applying mandatory patches, addressing regulatory requirements, etc. Think of it as the many services an average household depends on that must be paid monthly before the family can even think about discretionary funds.
The amount of money an institution must spend to service its legacy technology represents greater than 80% of its IT budget. As with a household budget that must cover interest on credit cards, student loans and other long-term debt, continuing to pay interest only on technical debt ultimately leads to a day of reckoning.
Open Banking, but Closed Third Parties?
There are steps which can be taken to start to retire technical debt. To succeed, though, requires the cooperation of the third parties providing services to banks and credit unions who are, also, often making interest-only payments on their technical debt while trying to stave off that day of reckoning. At the same time, their clients look to them to serve as conduits to the latest and greatest in banking services – if not as a direct provider, then as an enabler standing ready to plug new solutions into their platforms.
This is where things get dicey. The large legacy banking vendors have, until now, enjoyed a captive audience. (Financial institutions use the term “vendor lock.”) These vendors know the tremendous amount of time, money and risk institutions face when considering a replacement of what are often very complex systems. As tempting as it is to use these facts to “extend” their relationship with a bank or credit union, some legacy vendors are seeing the wisdom of playing the long game in a way that benefits their clients.
The emergence of Open Banking has made the notion of plug-and-play interoperability across solutions far more feasible. Using APIs to open up their solutions (and not charging sums that are clearly meant to discourage interoperability) will address bank and credit union clients’ single greatest frustration with providers, by allowing these institutions to incorporate newer technology that delivers the experience consumers are expecting.
Many of the middle and back office solutions vendors provide are very good at what they do and will remain part of the IT landscape for that reason. Many, also, are not built in a way that can adapt to the digital revolution on their own. Accepting this reality and working as partners with their clients to create an open banking model will, in fact, lower everyone’s technical debt, as each provider focuses on what they do best. After all, in a digital world, good enough isn’t. Just ask your consumers.
The Bottom Line: Will the legacy providers play the long game for the benefit of their clients? Market forces may provide a tiebreaking nudge, as a new breed of core providers built on open platforms are enjoying increasing traction. In the world of continuing innovation, the level of technical debt will never reach Dave Ramsey levels, but the prognosis is improving for banks and credit unions looking to reduce their burdens.
