Why banks must warm up to APIs?
After enough has been written about the benefits of using APIs for banks, only one pertinent question remains: It now boils down to ‘When rather than Whether’ for API adoption by banks. In that pursuit, the biggest challenge seems to be – ‘how to monetize our API efforts?’ The simple answer is to figure out what customer needs to zero in on the right kind of APIs to suit their needs. Easier said than done, this needs a VC mindset and a business approach to technology. These are qualities that would be hard to come by in banks, especially state-owned or traditional banks.
One of the important lessons that Open Banking has taught is that data moves as a matter of course from one environment to another, and that ‘to be useful, customer data must move’. So, whether the data is under the control of a third party via screen scraping, or is hosted on a private, public, or hybrid cloud by the financial institution itself, the reality is that Open Banking is about being an architecture that enables fluid movement of financial data.
If UPI is about movement of money, APIs are about movement of data. The fastest growing API categories have been payments and financial information. This is because every business needs to make and receive payments, and every business needs financial information. Ironically, non-financial businesses have taken the lead here, not banks.
Starter Pack: Internal APIs
Given the lack of monetization models, we may not witness a proliferation of partner APIs or Public APIs any soon. However, there are enough cases for banks to start using APIs internally. Factors such as cost savings, speedier time to market, and increased product quality and services are significant enough reasons.
In fact, a 2018 McKinsey survey revealed that more than 91% of APIs are internal1. The term ‘Amazon effect’ is often used to signify a digital-first business model. In the early 2000s, Amazon CEO Jeff Bezos issued a memo (sometimes called the ‘Bezos API mandate’) that has legendary status among the tech community. Bezos decreed that all teams must deliver their internal functionality only through APIs, including internal communications and processes. These APIs were designed from the ground up to be eventually externalized. Amazon is now reaping the rewards of its founders’ vision two decades ago.
For banks, the best part of using internal APIs is that they can be embedded into existing systems: ERP, websites, or mobile apps. These APIs can be automated, so that banks do not need to learn a new system or change their business rules or processes much. Banks usually engage their core banking system providers to build internal APIs to facilitate mobile and web-based services such as net banking.
These APIs are not shared outside of the bank but are rather intended to connect disparate applications and databases internally. As they gain in confidence, they could well morph into Partner APIs. For instance, wherever possible, the bank may partner with a third-party provider to extend limited access to data through APIs to enable processes such as creating an underwriting model for issuing loans.
Microservices strategy
All of this necessitates adopting a microservices strategy. This can be a huge cultural change by itself, because it blurs the lines between IT, operations, and the businesses. Internal processes are broken down into modular components by creating private APIs for each fundamental deliverable. These private APIs then help solve complex business problems through a series of API calls, instead of using manual processes on top of a single-purpose, monolithic technology solution.
For instance, a series of APIs can help decouple mainframe services from customer experiences such as a mobile banking application, so they are easier to maintain and evolve. The bank’s security services could also be decoupled via APIs, making them independent of the underlying technology. This also helps standardize the security at the transformational layer. The goal, of course, would be to have a complete suite of financial service APIs that decouple all client applications from core backend services.
Success stories
Danske Bank offers a good example of a successful model2. Danske siloed its technical systems into API-ready sub-domains, starting with three layers: a foundational layer (mainly consisting of a system of records), a process or functional layer (providing meaningful data to consumers), and an experiential layer (responsible for individual customer touchpoints such as apps). The foundation layer (system of records) was further broken down across object-oriented subdomains, such as customers. Each of these objects then became the basis for an API (or set of APIs).
Apart from the cultural and mindset issues we have seen, older banks could also face challenges from the limitations of legacy systems and infrastructure. Despite this challenge, APIs would soon become indispensable for the survival and growth of banks. As we said, it is a matter of ‘When’ rather than ‘Whether’.
"We have to stop optimizing for programmers and start optimizing for users. — Jeff Atwood Just a decade ago, the Read more
Platformable, a consulting firm that helps companies and public bodies generate value through the use of APIs, recently published stats Read more
