Feature/ Banking & Finance

The rise of APIs

Karm Legal Consultants share insight on the impact of Application Programming Interfaces on the banking and finance sector and the approach taken by regulators like the UK’s FCA and ADGM’s FSRA on the subject.

API’s can be thought of as a user interface which as a computer application interacts with another over the internet or within a private network using predefined rules described in the API. APIs facilitate a way to share, move and access information, previously ring fenced within an isolated system. They are the underlying infrastructure that form the technological basis for most open banking initiatives.

Through the years, APIs have broadly been classified as private, partner and open APIs. As the nomenclature suggests:

Private APIs are typically used within an organisation or system to facilitate integration of systems,

Partner APIs are expected to facilitate integration between institutions/companies and its business partners.

Open APIs are typically understood to open up the information and functionalities to third parties that may not necessarily have a business relationship with them.

Like every new technology and offshoots thereof, the term ‘Open APIs’ has been subject to abuse. Whether or not Open APIs will breach the borders of data privacy has long been a debate across jurisdictions. It is pertinent to note that only some of the Open APIs are ‘public’ and for anyone to use (or to register for use), while some might even serve Open Data. However, not all APIs are Open APIs and most Open API providers need API consumers to register (refer Fig. 1 above). Now, hold on to the word ‘register’ as we discuss more on ‘Open Baking’ and ‘Open Finance’ on subsequent pages.

As of now we’d like to iterate the existence of various methodologies that define how messages are formatted and transmitted over the internet. These methodologies provide encryption techniques enabling the transmitted information to be read by only the originator and the intended recipient. Representational State Transfer (REST) and Simple Object Access Protocol (SOAP) are two widely used examples of such API methodologies.


In the banking industry, Open APIs have acted as a secure method of communication between third parties and online banking systems. From a regulatory perspective, the technical standards under EU's Second Payment Services Directive (PSD2), effective January 13, 2018 encouraged the ‘provision of a standardised and reliable access interface to payment accounts’.[1]

The aim of PSD2 was to reach a market agreement on one technical specification so that all systems across Europe could ultimately be based on one or a few technical API standards. In particular, the aim of PSD2 was to open the following areas to third party service providers in an attempt to ‘open’ the banking system. The areas of (a) payment initiation services; (b) account information services; and (c) issuance of card-based payment instruments; were opened up in a manner permitting consumers to initiate the payments, access their account information and hold payment instruments (like cards) provided by third party service providers. This could be looked at as more of a consumer centric approach, where the consumer may have access to maximum banking services based on the limited information that the consumer may be required to provide.

Along the same lines, earlier in 2018, nine of UK’s major banks took initiatives to facilitate open banking in the UK and commissioned an Open Banking Implementation Entity (OBIE) that was tasked with developing technical standards to enable third party access via open APIs. Beyond Europe’s well-known Payment Services Directive (PSD2), Singapore, Hong Kong and Australia’s initiatives are making serious strides towards open banking, by mandating their Financial Institutions to make data available to third parties. Meanwhile, the Swiss Fintech Innovations Association (SFTI) in September 2018, published a first draft of common API specifications. Open APIs have largely been viewed as the game-changing model for banking titans like Switzerland.

OPEN API 2.0 - Open Finance

From a purely ‘Finance’ perspective there could be three API approaches for financial services organisations, indicating diverse strategies that firms are taking to grow open banking initiatives into alternative revenue streams.




Acting as a supplier


Financial institution supplies their own products via third-party platforms

Limited API investment, the focus is on integrating with APIs offered by third-party providers

Acting as a distributor

Financial institution offers products of third-party providers on its own platform

Greater API investment, the focus is on enabling third-party providers to efficiently integrate their products

Acting as a platform provider

In addition to the role of supplier and distributor, the financial institution acts as a platform provider for third parties to exchange data with other third parties

With significant API investment, the focus is on providing secure and scalable infrastructure for other market participants to offer their products


We are now slowly witnessing a shift more towards enabling ‘open’ financing models in addition to open banking. In December of 2019 the UK Financial Conduct Authority (“FCA”) issued a ‘call for input’ to explore opportunities and risks arising from open finance[2]. FCA with the said report, aims at having an open financing system wherein consumers and businesses – ‘can grant access to their data to trusted third-party providers (TPPs) and in return gain access to a wider range of financial services/products’ and ‘have greater control over their data’.


In a rather laudable attempt, ADGM’s regulatory arm, Financial Services Regulation Authority (FSRA) has, on October 14, 2019 published their guidance regarding the development and use of APIs in the ADGM (“Guidance”). The Guidance doesn’t restrict itself to discussing the Open APIs, but rather classifies and recognises all the three categories of Private, Partner and Open APIs. The Guidance also recognises the REST and SOAP methodologies and discusses the fundamentals of both. Their aim of the Guidance is to promote the use of standardised, interoperable and trusted APIs to create the means to adapt and update in the context of an increasingly complex and changing business environment.


The FSRA expects API Providers and Consumers to maintain a safe, sound and trusted financial services ecosystem. They want organisations to mitigate the risks of money-laundering, terrorist financing and data breaches, and for them to do so by following a mandated guideline and framework on AML/CFT and Data Protection.

The FSRA sets out its guidelines relating to certain API requirements. They are believed to be the industry best practices around the design, security maintenance and use of APIs to ensure interoperability, resilience and scalability of the API economy. They are;

The FSRA notes that in the context of open banking, there is a need to establish a common API standard, which allows all parties in an open banking ecosystem to exchange data and information in a harmonised way based on the same rules with maximal interoperability, accessibility and ensuring that understanding is preserved, and the meaning can be conveyed.

Although the FSRA does not propose to make Open Data or APIs mandatory, it does view them as being an integral element of any Financial Institution’s digital strategy and will actively look to align with international best practices to maintain a safe and trusted digital environment. It thus follows that with this guidance, the FSRA intended to promote experimentation, accelerate implementation of cutting-edge technologies, and speed up industry adoption of customer-focused disruptive ideas, to drive further financial inclusion and to realise the API economy.


From a regulatory perspective, there are significant licensing and compliance requirements that may arise for the fintech providers while integrating APIs and performing the above-mentioned roles. There is a likelihood of overlap in the roles that the fintech and service providers may deem to provide while rendering their services. Remember the good ol’ days when various platform companies had a hard time detaching their liabilities from the payment gateways (also made functional by API integration)? We are hinting at something similar.

As such, it is essential to have robust API Contracts and API definitions (such as the ones facilitate by SWAGGER[3]) to understand, what an API does or will do; and interact with its various components, without having to integrate it into application right away. Needless to say, whether in code or in vernacular, it is always a good idea to run a contract past your lawyer.

Text by:

Akshata Namjoshi, senior associate, Karm Legal Consultants

Manav Joshi, legal researcher, Karm Legal Consultant

[1] European Central Bank (2018). “The revised Payment Services Directive (PSD2) and the transition to stronger payments security.” Available at: [Accessed 8 Feb. 2020].

[2] Financial Conduct Authority (2019) “Call for Input: Open finance” Available at: [Accessed February 8, 2020].

[3] Swagger (2020). “Documenting Your Existing APIs: API Documentation Made Easy with OpenAPI & Swagger” Available at: [Accessed 8 Feb. 2020].

To stay updated,

subscribe to our newsletter