When I started my career in financial services 20 years ago, the IT team was still in the basement of our imposing office. Writing software was a multi-year process that started with detailing exactly what you needed in a business requirement document upfront, then waiting patiently for tech teams to build what you thought you described, with a big reveal at the end — several months or occasionally years later.
In that time, your needs and regulatory constraints may have shifted and the people behind the original ask may have left the bank.
No matter.
It was par for the course and all it needed was a few extra weeks of tweaks and meetings. What are a few weeks when a project has taken years already?
Imagine this: Tier 1 European Bank, circa 2007.
A small army of people are working on a price verification system. The army involves three vendors from three countries and four internal teams, plus compliance.
The requirements for the system were written by the business teams. However, the person at the helm of the business has changed twice during this project, as have the staff in the vendor teams. This meant that a small and thriving cottage industry opened up for so-called ‘KT’ (knowledge transfer) professionals, who held onto acquired know-how when team members left. Only, the people doing KT were not the people who specified, designed or built the system, so you needed those folks to spend time with the KT folks so that the other folks who would eventually use the system would know what this was meant to do.
Are you following? Good.
When I joined this project, it had been in development for two years. When I left three years later, it was being primed for user acceptance testing with superusers; general release was at least a year away.
Superusers were meant to be savvy business people who could understand tech and would learn the system before advocating for its usage among their peers on the floor.
If I told you that both of our superusers moved up and on before they could use, advocate for or supercharge anything, would you believe me? Of course, you would.
We were doing all this, by the way, on screens with green blinking cursors, complex commands and absolutely no notion of user friendliness. This was also the year when the first iPhone appeared on the market.
For most of us, that was the first time we saw intuitive technology. No instruction manual was needed: you just felt your way around it, as a user. It was clear what you needed to do: no KT required, no superuser needed.
The realisation that we could build this kind of technology in financial services didn’t dawn upon us immediately. But it didn’t take too long for financial services institutions to start asking what this kind of technology would look like if we used it.
Compliance and risk came into the room. A process of intense education started. What is an application programming interface (API), and how do you control and manage it? What does the appropriate risk matrix look like?
As those questions started getting answers and the digital era started dawning for financial services, banks suddenly said: ‘Hey, wait! We’ve done something like this before.’
Apps were new, but online availability was not. Banks had online services since the mid-1990s. Stanford Credit Union launched the first website for banking services as early as 1994.
So, this suddenly felt like an extension, not a departure.
Apps started becoming ubiquitous. Almost every bank has one or 10 for its customers and increasingly for its teams. Technology that is easier to use — that doesn’t need an army of explainers — became the norm. The technology we built started looking very different, but the way we built it didn’t change much.
Although the result could and would look slicker, modern — worthy of a place on your iPhone home screen — the way we got there was slow, convoluted and tentative.
Remember the price verification system story from above.
The arrival of applications was poorly timed for its long-awaited unveiling. The team had to go back to the drawing board and ‘put an app on top’, as the business phrased it.
Only the original system wasn’t built to be able to do that. It was built for a world where we tallied our books at the end of the day. It was not built to be able to stream and parse information in real time.
What to do, at this point, several years into a very expensive project? Scrap it and start from scratch? Or hack it and hope for the best?
No prizes given for guessing which course of action was chosen.
Some API-wrappers were created. The system now managed tentative intra-day calculations with the source of truth coming at the end of the day. People needed to be aware of that and moderate their commitments, caveat their statements, and keep verifying the price-verification data.
Some fruitless battles were had with the compliance team, who refused point blank to let us get a calendar feed that wasn’t built in the bank. A team of three people spent weeks creating a spreadsheet of public holidays in Thailand and Uruguay, Qatar and Indonesia — all the places that had currencies that weren’t highly traded; these were calendars that didn’t coincide with the European working week and included public holidays that we hadn’t heard of before.
Only, it wasn’t just our team that took that shortcut.
Every bank in the world looked at their existing systems — in development like ours or live and operational — and asked, ‘Do I scrap them, or do I put an API on top and manually manage what doesn’t fully work?’
Hand on heart, we didn’t realise how deeply and rapidly the world was changing. It felt like a pragmatic choice, across the board. It felt like the most realistic way of accommodating change.
But, with every passing year, the process by which technology decisions were made creaked more and more. The multi-year, ‘tell-us-what-you-want-before-we-start-building’ approach was replaced by agile teams, proactive dialogue and faster development cycles.
Banks and financial services entities went deep into exploring relationships with digital-first entities and start-ups to capitalise on their speed and creativity, agility and expertise.
And it worked.
With each passing year, more apps were released, more partnerships were announced, more new technology was brought into the mix.
The mix got bigger and more complicated.
It now included technologies from different eras that didn’t work well together. A lot of manual intervention was required to close those gaps. That required different teams with different skills to manage the technical estate from different decades. And different teams to manage the operating risk we accumulated when we decided to ‘put an app on top’.
This complexity is not only a worry for stability and performance. It is also expensive, because it is carrying the combined technological choices of the past 30 years.
The fascination with apps has led us on an incredible journey of realising the power of digital capabilities and what we can do with real-time data. What we can possibly do with generative artificial intelligence (AI), as it is maturing and rapidly evolving?
In a fully digital system, the three people who worked on Googling public holidays in Sri Lanka for the foreign exchange exceptions calendar would not be needed. The mistakes, or the incorrect assumptions, they made — about Good Friday being a holiday in all majority Christian countries, for instance — would not happen.
The army of KT folks would not be needed.
For years, we have accepted and carried this inefficiency as the cost of doing business. But a new era is dawning.
Big tech is entering financial services without those operating costs and delays because their estates are fully digital. The AI adoption cycle is accelerating, demanding ready and secure access to systems that are already struggling with API calls.
It is time to clean up the mix and remove systems that are no longer fit for purpose. Consign them to museums of technology as tools that served us well, but are no longer relevant.
For the sake of managing that operating risk and for the sake of managing the cost to serve towards profitability, start switching your ancient museum pieces of software off.
Leda Glyptis is a fintech executive and former banker.
