Open banking API specifications: simplifying a technical resource

Open banking 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 them. It’s the technical roadmap interested parties can use to develop applications that are tailored to customers’ needs.

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 (ASPSP) 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 a 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.

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:

• Bank proprietary APIs

• Information collected by data agencies

• Screen scraping

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 (ASPSPs) 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 the Open Banking Implementation Entity (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.