Standards for Open Banking APIs

Enterprise digital transformation has seen explosive growth over the last two decades, and banking institutions are no exception. One innovation that has come out of this growth is open banking. 24.7 million users switched to open banking in 2020 alone, a number estimated to reach 132 million by 2024.

Open banking lets banks publish their application programming interfaces (APIs) for third parties to use in developing new applications and services. Banking-as-a-Service (BaaS) is a key component of open banking, connecting FinTech companies to banking systems using APIs. The result is an improved digital banking experience for customers.

With open banking, customers can access their accounts and other banking services through digital channels, and third parties can perform transactions on behalf of customers. Consumers and organizations thus get access to numerous financial services and products without the overhead cost of traditional banking systems. In the fast-paced world of FinTech, open banking APIs allow companies to gain a competitive advantage by becoming more customer-centric. 

This article will introduce you to the basic standards of open banking. We’ll cover the APIs involved, how they work and the standards for those APIs and their providers. You will also learn about the different stakeholders involved in an open banking system.

What does open banking involve? 

Core services offered by third-party, open banking applications typically include:

  • Sharing of information about products and services, allowing customers to compare financial products
  • Real-time sharing of financial transactional data
  • Real-time payment for products and services

Banks provide such data by exposing the functionalities of their applications—many of which could be legacy—through their internally developed APIs.  

APIs are software programs that expose the data or functionalities of an underlying—often legacy—application. The API is accessed (“consumed”) by third-party applications, and it is the means of communicating with the source banking applications.

Due to the sensitive nature of financial data, third-party providers need to comply with and adhere to regulations and guidelines. One such core guideline is the Modified Payment Service Directive, PSD 2, from the European Union.

Open banking regulations: Europe’s PSD 2

PSD 2 was developed to increase innovation, competition and cooperation in the open banking sector of the EU through secure payment services. It allows banks to create APIs that third-party providers can leverage in order to offer secure, swift and reliable banking-related services and data access to customers. To work with PSD 2, a FinTech company needs to register either as an Account Information Service Provider (AISP) or Payment Initiation Service Provider (PISP)

AISP

An AISP is a licensed financial institution that helps users to access data about their financial accounts, which can be held in multiple institutions—like banks or credit unions.

PISP

A PISP is an organization that has permission to connect to a consumer’s bank account and initiate payments on behalf of the customer.

Understanding the open banking API ecosystem

Like in any API ecosystem, APIs in open banking can be categorized according to their accessibility:

  • Private APIs are used exclusively within an organization. The code and the API interfaces remain proprietary. Although open banking is all about exposing a bank’s applications, banks themselves could build and offer customer-facing digital services with their own APIs.
  • Partner APIs allow partner organizations to access a bank’s APIs. For example, a bank may partner with a government program offering “money smart” advice to the general public. That bank would expose its APIs only to that government partner to allow access to banking data.
  • Public APIs are exposed to anyone. Any FinTech organization (AISP or PISP) can use these APIs.

Some common examples of open banking API functions include:

  • Merchant services for e-businesses to receive payments
  • Online payment services for retail consumers to make payments
  • Accessing client account information from multiple financial institutions
  • Comparing or recommending financial products from multiple financial institutions
  • Applying for personal and business loans
  • Financial planning services like budgeting and expense tracking
  • Accounting, reporting, reimbursement and tax services
  • Securely sharing transaction data with service providers

Who can be an open banking API provider or user? 

There are three primary groups of stakeholders in the world of open banking:

  1. API providers
  2. API customers
  3. End users 

Banks—or Account Services Payment Services Providers (ASPSPs)—are typically the API providers, responsible for designing, building, operating and managing the security and availability of their APIs.

API customers are PISPs and AISPs that use the open banking APIs exposed by banks to serve their customers. Many API customers are FinTech companies that build mobile apps, SaaS platforms or even more APIs for customized services.

End users are those who use the applications built by PISPs and AISPs. These end users may be multinational enterprises or individual retail customers. These end users usually pay to use the application built by the API customer. A typical business model adopted by API customers is the recurring subscription fee model.

Interaction flow of open banking APIs and end users

Interaction flow of open banking APIs and end users

API standards in open banking

The open banking API standards include five different categories:

  1. Read/write API
  2. Open data API
  3. Directory
  4. Dynamic client registration
  5. Management Information (MI) reporting

Read/write API specifications

The read/write API specification is a collection of RESTful APIs that enable the third-party providers (AISPs or PISPs) to access data from banks and traditional financial institutions to serve their customers. These specifications define how to access the customer’s account information and transaction data from bank servers with the consent of the customer. The specification has attributes to control approved permissions, permission expiration and the historical time up to which data access is granted. 

To initiate using these APIs, the AISP or PISP first creates an account access consent resource by interacting with the ASPSP. The permissions, expiration date and validity period are defined, and the user is asked to approve or deny the access request.

Open data API specifications

The open data API specification defines API formats for providing data regarding a bank’s services, products and channels. It encompasses various APIs that include:

  • ATM locator and branch locator APIs to provide customers with information about a bank’s service channels
  • Personal and business current account information APIs, with details about eligible rates, repayment clauses, fines and related charges
  • Commercial credit card information APIs
  • Loan APIs

Apart from these standard API definitions, the third-party providers would need to depend on the bank’s proprietary APIs or screen scraping to get access to these details.

Directory specifications

Directory specifications contain detailed information about how an open banking directory works, along with the roles and functions of each participant in the directory. A directory is a repository of identity information of people and organizations who deal with a bank.

These specifications define how third-party providers can use APIs to manage identities and access on behalf of people and organizations in the bank’s user directory. It also defines how to issue, manage and revoke certificates and encryption keys. The ability to update and find information present in the directory is also a function of directory APIs.

Dynamic client registration specifications

Dynamic client registration specifications define the APIs for third-party service providers to register themselves with ASPSPs to access their APIs. The purpose of the client registration specifications is to ensure a low friction process without hurdles for third-party providers to start interacting with banks.

The client registration specifications are built on top of the OAuth 2.0 standard. The guidelines mandate a provider to submit a Software Statement Assertion to an ASPSP for creating OAuth clients.

Management Information (MI) reporting specifications

MI reporting specifications define APIs for third-party applications to provide management information to the open banking implementation entity. This information helps the open banking implementation entity to:

  • Understand the adoption levels of open banking standards
  • Measure the performance of the APIs
  • Understand drop-out rates and usage patterns
  • Forecast volumes

MI reporting defines APIs to provide volumetric data, auth efficiency data, account information adoption data, payment information adoption data, etc. It is not a mandatory requirement for third-party providers.

Security profiles 

Security profiles define security provisions for the client and server and propose security recommendations for interacting with the APIs. These profiles help in standardizing the security aspects of the APIs. Open Banking API Standards define, at a high level, two security profiles from the OpenID Foundation:

  1. Financial-grade API (FAPI)
  2. Client-initiated backchannel authentication (CIBA)

FAPI

The FAPI specification deals with REST APIs for providing JSON-formatted “higher risk” data to client applications. They are built on top of the OAuth 2.0 authentication framework. The specification includes a read-only API and a read-write API. The profiles define how the client applications can obtain auth tokens for their users, use these tokens to identify customers and interact with the endpoints to access the secure data.

FAPI 1.0 Profile

FAPI 1.0 Profile

CIBA

CIBA presents a different approach to authentication for open banking API access. In contrast to FAPI, CIBA avoids browser redirection-based interaction with the user to perform authentication. Instead, user authentication is performed by the consumption device itself. The consumption device may be directly controlled by someone other than the customer, like a bank teller or a petrol pump attendant. CIBA uses a Backchannel Authentication endpoint, along with read-only and read-write APIs to do this.  

CIBA Profile

CIBA Profile

Conclusion 

The world of digital services is expanding exponentially, and effortless transactions have become requisite for a good customer experience. In that sense, open banking is the future of banking for both financial institutions and consumers.

Currently, open banking is still a new concept in some regions. Different countries have set different standards for open banking. Moreover, different organizations have come up with various ways to deal with financial institutions.

Fortunately, Kong has an API system that follows industry standards—giving a sense of trust to its consumers and reducing the chances of fraud. As more organizations adopt the open banking system, more API providers will come into the industry. This means more financial organizations will need strong API management systems that provide security, transparency, fault tolerance and routing. This is where Kong can make a difference. 

To learn more, contact us for a personalized demo.