The first release of the API specifications for Open Banking was five years ago. At the time, I recall that many people in the banking sector didn’t see much value in it. In fact, many saw it as a potential impediment to their job.
by Martin Gaffney, Vice President EMEA, Yugabyte
Five years on, it is clear that those fears were unfounded. In May 2022 alone, UK businesses and consumers made five million open banking-driven payments. The UK open banking community made a record 1 billion API calls in the same month.
So, Open Banking ended up being a pleasant surprise rather than a restrictive move by the regulators. It opened up opportunities and showed that having to work with APIs is not a constraint but in fact, quite the opposite.
It’s taken the market a while to see that. 20 years ago, every management consultant in the sector was recommending disintermediation—the idea that you needed to own and run your own supply chain to reduce complexity.
That was still the driver when big banks started to go online: they built their own websites, their own banking applications, their own mobile solutions—all with the aim of owning everything from cell phone banking to the back end.
In practice, this actually added complexity. It meant that when a bank decided to write a web page, it had to be set to talk to an application server, which talked to its internal database, which was deployed on its on-prem server farm. It was all the bank’s responsibility, from start to finish. As a result, the organisation may have needed multiple developers with various overlapping skill sets working on this full tech stack.
But now, thanks to Open Banking and APIs, to be a serious player in banking, you must be adept at exposing and consuming APIs. To do this, you need to have the right architectures, skills, and tools in place to support this modern approach to software development.
I’d go so far as to say that we are now entering the era of ‘de-disintermediation’—as what Open Banking really means is that the bank is no longer permitted to lock anybody out, and we all need to work in a different and ‘more open’ way.
Welcome to the new de-disintermediated financial services IT world
Consumers see this on their mobile banking app, which is now full of friendly questions about whether you want to hook in another of your accounts and bring them all together in one place. Personally, I love this: it makes sense to me as a digital citizen, as a capitalist, and as a shopper.
I also like all the new businesses that Open Banking and de-disintermediation have allowed to flourish. Embedded banking is why Klarna can exist, where Buy Now, Pay Later comes in; it’s how many new payment brands work and has contributed to the major upsurge in innovative FinTech companies.
I am also seeing extremely positive moves at the tech and architecture end of the ecosystem. To do Open Banking, you must build your app in a way that allows somebody else to come in at the application server layer. You must also allow that other party’s application server to talk to other application servers, all of which have databases at the back end.
This is where the API has come into its own. IT people in progressive financial services companies welcome the fact that application programming interfaces (a technology in search of a business case for too long) make it so easy for two pieces of software to talk to each other by a contract.
App modernisation + liberalisation = good times ahead
The reality is that the people who will succeed in an Open Banking/de-disintermediated/API-centric world are the people who build their processes, skill sets, tools, and architectures in a way that embraces this way of working. Delivering on this new approach will unlock business value.
This also means the end of huge monolithic banking applications. Now, developers can break the front off and replace the proprietary apps with APIs. This means you can more effectively outsource the value that your back end supplies, even if that’s still some monolithic mainframe app in your data centre. APIs allow you to expose it to the web and give chosen partners access to it, adding value for you.
This way of working is possibly better known to you as microservices architectures on the Cloud. Two separate tech and business development threads mesh here: one is app modernisation and the other is the general acceptance that microservices architectures are good for exploiting cloud architecture. A drive to allow more competition in the market in the shape of Open Banking has shown the API to be the best way to both comply with the regulations and to embrace that great new architecture.
There is also a database aspect here because as soon as you start the road to de-disintermediation by breaking your big banking systems up, you’re also breaking your data up. You can’t just stick with your tried and true (if rather expensive) monolithic database on the back end. Even if you did, you’d still have the ongoing problem that on-prem monolithic proprietary databases never match well with cloud-based microservices, which aim to bring everything data processing as close to the customer as possible around the world.
Given this, you can’t really have all your data sitting in a great data barn somewhere outside London. You’ll need to move to the modern data layer, an intrinsic part of this microservices architecture.
How about ending the banking IT ‘technical debt’ issue
It’s time, then, to thank the inventors of Open Banking, who weren’t (as feared) awkward people who wanted to stop you from doing stuff. You should see them instead as benefactors who’ve unlocked the door for you as a banking CIO to access a massive amount of innovation and business value in a supply chain you no longer need to 100% own.
If you embrace this, much of your day-to-day work, which is really just technical debt and patching up the work your predecessor did when John Major was PM, can go away. You can rip it up and rewrite it, turn it into an API, and let somebody else put a front end on it.
To me, the benefit of Open Banking is very clear. However, if you don’t see this as an opportunity, and consider it just another IT burden, maybe you need to ask how much of a contribution to the business you’re really making.