Home > blog > How to mitigate the risk of API overload in Open banking

At the heart of open banking strategies lie application programming interfaces (APIs). They form the backbone for information exchange between banks and third-party providers (TPPs) or non-financial service providers. By doing so, banks are able to build on value-added services to a set of consumer base directly or indirectly which they would have taken longer time to acquire & develop.

But banks have to be aware of the risk of overdeveloping APIs. Creating a multitude of APIs opens banking landscape to security risks and overloading the underlying IT infrastructure. Without proper security protocols, API weak points can be exposed to operational risks and data breaches. But how can we reduce the risk of API overload in open banking? We take a look at strategies to attenuate the risk of API overload.

  • Development of API should be in line with digital banking strategy:

Most banks have rushed into API development without a defined API strategy. The development of APIs needs to be in line with the company’s business strategy, specifically its strategies for digital transformation. APIs can be used in different ways, but the core of digital transformation relies on creating value addition to the customer. Today, the banking ecosystem comprises an eclectic mix of financial institutions, FinTechs, vendors, and a diverse customer base. To be able to cater to this new ecosystem, banks have to digitally transform their legacy systems, address microservices.

Focusing on customers’ needs, banks are creating unique partnerships with technology companies to develop value add services. With newer technologies like artificial intelligence (AI), machine learning, blockchain, and predictive analytics, banks are developing new resources to lower costs and quicker turnaround. Some banks have collaborated with neo banks or acquiring them to align API development with their digital transformation journey.

Enriching the digital ecosystem, BBVA’s API market creates infrastructures that support the distribution and creation of third-party products in synergy with banks. Their aim is to make banking services “invisible” in order to minimize a customer’s effort to use digital products. For example, BBVA invisible payments allow employees/customers to make payments via facial recognition. In the bank’s cafes and restaurants, customers have to look into a camera to automatically bill and pay for purchases.

  • Create synergy between the various teams within the organization:

Data silos have plagued the banking sector for decades. But in the age of digital advancements, banks can no longer operate by building walls around teams. Across banking functions, teams need to communicate and exchange information/data. Legacy siloed architectures are also a major barrier for breaking down silos.

For banks to implement APIs they have to first improve their data integrity capabilities, essentially rethinking their data collection processes. Application querying data sets with errors can bring the entire system down. In this scenario, tools like validation APIs can help banks integrate data. But these tools are limited by the flow of data from varied sources. Standardizing data collection and management processes across silos would streamline and centralize data sources. This eliminates duplication efforts and reduces siloed API development.

As data sources increase (Internet of things devices, smartphones), data siloes would continue to manifest itself. Banks have to focus on breaking these silos with innovative solutions. Most banks are adopting DevOps to remove barriers between development and testing and breaking down silos. Lloyds Banking group, for example, uses DevOps to drive community and collaboration among engineers/developers.

  • Maintaining a balance between internal and external APIs:

The banking sector is highly regulated owing to the sensitivity of the data being handled. In this environment, it is a security risk for banks to allow TPPs to access information, who may leverage the data to extend their own offerings. A recent report

A good start for addressing security and trust issues would be for banks to develop APIs that support their internal development. These private APIs are by invitation only and are being used by banks in B2B experiments. For example, in 2016, Deutsche bank conducted an open house hackathon to test its dbAPI programming interface. The event drew over 750 applicants from 22 countries to develop digital solutions for banking clients. The interface provided an easy and convenient platform for developers to use. Eventually, the banks opened its data store to external software developers.

Partner and Open APIs are the latest trends to take over since open banking. These APIs allow automated information exchange with third parties. While the system allows for quick development of products and solutions, it opens security vulnerabilities if implemented incorrectly. Plug-and-play APIs allow banks to extend their service offerings and build API-led connectivity. This strategy is effective in monetizing the API economy and creating new revenue streams.

Successful APIs require internal and external developer communities that are healthy, collaborative, and future-thinking. While banks need to offer their services to TPPs, they should also think about leveraging TPPs for their own offerings; fostering external connections. Gartner calls it an “inside-out banking”, wherein banks interconnect with external FinTech companies.

Globally, open banking initiatives remain in very early stages of development and implementation. The four most powerful technology companies  Google, Amazon, Facebook, and Apple (GAFA) are enabling a broader cross-industry data sharing ecosystem. To compete with non-banking financial companies (NBFCs), banks have to develop strong relationships with their customers and vendors, while distributing the risks. Mitigating API overload will aid banks to increase revenues and focus on developing mutually beneficial business value offering than a technology marvel on their ability to integrate.

Article by

Maveric Systems