Banking on APIs

The acronym API (Application Programming Interface) is pretty well understood these days, so much so that people outside of the technology team have a good understanding. My simple definition is that it is software that allows separate software solutions (either on the same or different physical computer) to “talk to each other”. According to Wikipedia, the software originated in the 1940s but the term API didn’t emerge till the 1960s. So, whilst we had the capability of separating functionality and data, it was a surprise to me in my early days of programming why we wrote “monolithic software solutions”.

APIs should be seen as strategic by banks

In 1992, I wrote a paper on the future of application development for Lloyds Bank. My paper described a vision of “end user development” to maximise flexibility and reduce cost of development. In this paper I called for the bank to:

1. Develop more tools and less applications.
2. Data access to be separated from applications.
3. Create applications from services (that returned data or screens).

The first point argued that first we should write “tools” not solutions. For example, we had a standard letters application for generating customer communication; however, this solution was written for specific letter types and didn’t have the concept of templates meaning that new code was written for additional letters. 

The second two essentially argued the case for more APIs rather writing everything into one application. I was no visionary or genius; this was common sense to me. Driving greater re-use and flexibility would mean we would develop solutions faster. Further by providing the right “tools” there would be some applications we wouldn’t even have to write because business users could use our tools to solve similar problems.

What I thought was common sense was actually asking the bank to act as a whole rather than as set of separate moving parts, something I wrote about last week. Some of the pushbacks I got were:

• I only have budget for solving my need, not for creating a solution that can be more widely used by the bank.
• Who else will use these APIs, I’m not spending money on building something that I hope other parts of the bank will use.
• Building flexibility now will slow us down.
• What if we have to change a “service” will we need to retest several applications instead of just one?

Of the three recommendations for me the creation of our APIs was the single most important thing we could have changed. The issue wasn’t creating any, because we had developed some common services for this like printing. The real issue was not seeing it as strategic. The IT director had “bigger fish to fry” with thousands of staff and millions of pounds of vendor purchases. The head of retail didn’t understand technology and quite frankly it was not his concern.

Hence, it’s no surprise that Amazon was entirely built on APIs only because CEO Jeff Bezos demanded it. If you haven’t already read his note, it’s well worth doing so.

Once again I was shown that business silos helped drive the implementation of monolithic software, it was not the lack of technical ability or vision. However, it is a lack of strategic vision both from a business and technology perspective that many organisations – and especially banks – developed large inflexible monolithic platforms. The repercussions of which have cost them decades of hard to maintain, difficult to change and costly to run systems based on technology that has past its sell-by date. Most recently, Anthony Jenkins, CEO of banking tech vendor 10X and former CEO of Barclays, accurately described banks as “museums of technology”.

I’m not saying that transformation is easy or that it has to be done in one go. Far from it. You cannot eat an elephant in one go, you eat it piece by piece. In my tech strategy for NatWest Cards Services I proposed that:

• Develop a design pattern (a layered design of presentation, process/business logic, data) for every new system.
• Each layer had API interfaces.

Then, every new development followed this pattern. Every new purchase of vendor solution had this pattern as purchase criteria. Every enhancement to an existing system looked to develop to this pattern. Then, over of a number of years, we would see the landscape being migrated to something more flexible and maintainable – this way there was less risk and cost.

What surprises me most today is that I see banks expanding their museum collection of technologies without a plan of how to minimise it. That there are still silo-based purchases or developments.

This week I’m just saying that we know technology is now core to the bank even though it is not their actual business. Creating a banking strategy and vision is now almost impossible without a good understanding of technology – both from the perspective of what is possible with technology now and in the future.

About the author

Dharmesh Mistry has been in banking for more than 30 years both in senior positions at Tier 1 banks and as a serial entrepreneur. He has been at the forefront of banking technology and innovation, from the very first internet and mobile banking apps to artificial intelligence (AI) and virtual reality (VR).

He has been on both sides of the fence and he’s not afraid to share his opinions.

He founded proptech start-up AskHomey (sold to a private investor in spring 2023) and is an investor and mentor in proptech and fintech. He also co-hosts the Demystify Podcast.

Follow Dharmesh on Twitter @dharmeshmistry and LinkedIn.

Read all his “I’m just saying” musings here.