Finextra’s piece, “How Open Banking Will Blow Core Systems Out of the Water,” says that the three hottest TLAs in banking are APIs, PSD2 and DLT (Distributed Ledger Technology). DLT is the generalization of blockchain-type systems.
You don’t have to use blocks to have a chain. According to the article, this isn’t considered to be a mature technology. But though it’s very exciting, it concerns us only indirectly through the use of APIs with DLT. APIs and PSD2, of course, are our bread and butter.
The article raises a couple of points that we at APIContext have been saying over the last few months, both here on the blog and in our recent whitepaper (which you can get a free copy of by filling in the form on this page.)
The banking grab bag
APIs have been around in one form on another for many years now. But the idea of RESTful web APIs as the very glue of our increasingly digitized economy is still a fairly unfamiliar one for many managers in operational units. Managers usually think it’s quick and straightforward to API-ize existing functionality, especially if they’re under pressure to open up systems from more senior managers and regulators.
Most banks rely on a grab bag of gnarly and often antiquated legacy systems to power the backend of their core legacy banking functionality. It’s not just a matter of throwing up a service fabric as a glorified API gateway between the external API world and the internal banking one. A lot of work is often needed to re-architect the core systems to make them API-ready.
Danger
This creates danger. It’s not easy, quick or cheap to API-ize your bank, so there’s a temptation to cut corners. But that can lead to problems with both the APIs themselves and the backend.
As we have often said here, if you’re monitoring, you’re not managing your APIs. And the complexity of backends means that you can’t assume an API that works this afternoon will still be working tomorrow morning.
And, of course, in open banking, you have to worry about everyone’s else APIs, too. Your APIs might be working fine, but if the third-party API your customer needs is not, then you’re still going to get it in the neck.
It’s noteworthy that of the nine CMA9 banks in the UK, despite having more than ample notice of PSD2 and open banking, five requested an extension from the CMA9 and one missed it altogether. And just from our own ongoing analysis of the performance of the six public CMA9 APIs, the quality varies widely. Now, those APIs are simple, non-mission-critical GETs. It’s likely that even wider variation in performance will be seen with more complex (and generally more mission-critical) APIs.
Monitor your APIs!
All of this emphasizes just how vital it is that banks actively monitor APIs. Not just their own, but also those third-party APIs (“Was it them or us at fault?”) and against which they must benchmark (“Why are their APIs so much faster and more reliable than ours?”).
Like it or not, we are moving into a fast-evolving world of open banking. That means there are going to be a lot of APIs out there. Open banking will only deliver its promises to both customers and banks if the APIs that enable it are up to scratch.
The only way to know the APIs really are up to scratch 24 hours a day, 7 days a week, is to keep yourself and your rivals honest by actively monitoring the APIs.
