Open Banking API Specifications: simplifying a technical resource


| Article by: Antonis KazoulisProfile Image Antonis Kazoulis 5 min

Open banking API specifications - Nordigen

Open Data API Specifications is a framework under which API providers such as banks or financial institutions can generate API endpoints that allow third-party developers to access it. It’s the technical roadmap interested parties can use to develop applications that are tailored to customers’ needs.

 

What is an API?

API is the acronym for Application Programming Interface, which is a software bridge, a channel for data transfer that allows two applications to communicate. Every time you are online using an application like Instagram, you are essentially using an API.

Without further ado, let’s dive straight into the analysis of version 1 of Open Banking Data API Specifications, what they mean and how they can be used.

 

Read/Write API: handling all access requests for transactions and account data

The Read/Write Data API Profile provides a description of the elements that are common across all the Read/Write Data API types. This collection of RESTful APIs enables Third-Party Providers to access data and initiate payments for customers, by connecting to Account Servicing Payment Service Providers – securely, efficiently, and more importantly with customer consent.

Account and Transaction API: step-by-step instructions

The Account and Transaction API Profile describes the workflow and functionality which allows an Account Information Service Provider ('AISP') to:

  • Express the intent to retrieve account information by creating an “account access consent”. This registers the data “permissions”, expiration, and historical period allowed for transactions/statements – that the customer (PSU) has consented to provide to the AISP
  • Following that, retrieve account and transaction data.

 

Step 1: Request Account Information

This process begins with a payment services user agreeing to allow an Account Information Service Provider to access their account data.

Step 2: Setup Account Access Consent

  • The Account Information Service Provider connects to the Account Servicing Payment Service Provider that services the user’s account and creates an account-access-consent resource. This notifies and alerts the ASPSP that a user is granting access to account and transaction data to an AISP. Subsequently, the ASPSP creates an identifier for the resource.
  • Once the account-access-consent resource is created, it will include fields that outline the data that the user has consented to share with the AISP. Here is what the field will showcase:
    • Permissions – a list of data collections that have been granted access.
    • Expiration Date – provisional expiration date of the user’s consent, setting an end date for when the AISP will no longer have access to the user’s data.
    • Transaction Validity Period – a clear period of time, a date range that specifies how far back an AISP can go to access transactions and statements
  • Bear in mind that an AISP may be a data broker, a middleman to other parties, meaning you might have multiple account-access-consents for the same account, with different consent/authorization parameters in each different scenario.

Step 3: Authorise Consent

  • The AISP requests the PSU to authorise the consent. What follows is an elaborate explanation of the way this action is carried out through redirection flow or a decoupled flow.
  • What’s important to note is that during the authorization process, the PSU selects the accounts that are authorised for the AISP request. All of these show up in the ASPSP's banking interface.

Step 4: Request Data

  • This is carried out by making a GET request to the relevant resource.

 

Developing Open banking APIs

Open Data API Specifications: how to develop the API endpoints

Personal Current Account / Business Current Account

As things stand, price comparison websites get their PCA product data using the following three ways:

This process is both time-consuming and error-prone. Having API standards would make the data capture much simpler.

Most of the details and documentation for this section include and entail graphs and code snippets. You can find the full breakdown on the dedicated resource page.

 

Directory Specifications: the roles and functions of each participant in the Directory

This part includes detailed technical information on how the Open Banking Directory works, and the roles and functions of each participant in the Directory. Given the depth of information provided, it would be better to shift your attention to the dedicated resource page.

 

Dynamic Client Registration: how to submit software statement assertions

Dynamic client registration allows third parties to register themselves through a Software Statement Assertion with the Account Services Payment Services Providers (ASPSP) in real-time.

The registration sets in motion a process whereby different scenarios are set in place for when a TPP may need to modify the client. The ASPSPs may implement optional APIs defined here to achieve that behaviour or implement a service management capability to deal with these changes.

The process follows the steps outlined below:

  • The TPP sends a registration request
  • This is a POST request including an SSA (Software Statement Assertion) as a claim
    • The SSA is sent as a signed JSON Web Token, which is derived from the Open Banking (OB) directory and contains the all-important client metadata.
  • The ASPSP validates the SSA based on the specifications provided in the Open Banking OpenID Dynamic Client (OIDC) Registration specification.
  • The ASPSP registers the client application using the metadata included in the SSA.
  • The ASPSP returns the response (successful or failed) based on the open banking UK specification.

To get the actual API endpoints, be sure to visit the dedicated resource page.

 

MI Reporting Specifications: examples, template and everything you need to know

Management information (MI) is a collection of data that summarizes the overall business activity of an entity. Examples of such information include:

  • Information about customers
  • Staff
  • Sales
  • Other types of data

This data is very important in analysing trends, forecasting for the future, and making informed business decisions.

As for open API specifications, MI reporting is used by regulators to better understand how the open banking ecosystem performs and operates. Looking at the API performance details published by OBIE you can get a glimpse of the value of the information provided.

For a complete breakdown of the reporting template key usage instructions, be sure to see the dedicated resource page.

Share
share on facebook share on linked

Article by

...Antonis Kazoulis
Recommended articles