Key Factors of Open Banking UK Specification

European banks are revamping their IT infrastructures to embrace PSD2, which is effectively reshaping Europe’s financial ecosystem. Conforming to PSD2 regulations, the Competition and Markets Authority (CMA) in the UK has introduced Open Banking. Open Banking requires banks, or Account Servicing Payment Service Providers (ASPSPs), to open up their data through a set of secure application programming interfaces (APIs) to an agreed standard, which will be accessed by Third Party Providers (TPPs). The TPPs will be using the implemented APIs to provide mobile or web application based services to personal and business banking customers also known as Payment Service Users (PSUs).

Prior to Open Banking, banks used their own proprietary applications to allow consumers to use bank’s services. With Open Banking, in addition to proprietary applications, third parties can create applications that facilitate the communication between the bank and the consumers through banking services. This process eventually increases the competition among service providers that will bring about innovative solutions to the industry.

Open Banking Terminology

Before going into the details of the specification, let’s take a quick look at some of the terms that will be used later in this article.

1. PSU - Payment Service User - The PSU is typically the consumer who is defined as a natural person making use of a payment service as a payee, payer or both.
2. TPP - Third Party Provider - An organization or a natural person that consumes APIs developed according to standards to access customers’ accounts in order to provide account information services and/or to initiate payments.
3. AISP - Account Information Service Provider - A TPP utilizing the Account and Transaction API is known as an AISP. An AISP provides consolidated account information on one or more payment accounts held by PSU with one or more payment service providers.
4. PISP - Payment Initiation Service Provider - A TPP utilizing the Payment Initiation API is known as a PISP. The PISP provides an online service to initiate a payment order at the request of the PSU with respect to a payment account held at another payment service provider.
5. ASPSP - Account Servicing Payment Service Providers - The bank is typically referred to as ASPSP and is defined as an entity that provides and maintains payment accounts for payers and publishes APIs to permit third-party providers to provide services to the payers.

More information about the definitions and terms that are used in the Open Banking context can be found in the Glossary.

The APIs

The Read/Write API Specification in Open Banking UK Standard describes two main API categories:

1. Account and Transaction API - The API utilized by AISPs to read account information
2. Payment Initiation API - The API utilized by PISPs to write payment instructions

In addition to the above two specifications, Open Banking Security Profile is available which comprehensively defines the security features that should be facilitated by the users of Open Banking.

Account and Transaction API Specification

The Account and Transaction API Specification focuses on information retrieval where a consumer will use a third party application or a service provider to retrieve his banking information about resources such as account details, balances, transactions and beneficiaries. The API endpoints defined in Account and Transaction API Specification, facilitate AISPs to retrieve account information from ASPSP on behalf of the PSU when the PSUs consent is provided.

The flow in detail:

1. The PSU requests account information from the AISP
2. The AISP requests the ASPSP to initiate authorization and consent flow
3. The ASPSP authenticates the user upon which the user provides the consent
4. The AISP requests account information from the ASPSP
5. The ASPSP sends the requested information to the AISP

When the PSU requests account information from the AISP, the AISP will request the bank to facilitate the request upon which the ASPSP attempts to authorize the PSU. When the user confirms with the bank to allow the AISP to access the information, that is, when the PSU approves to proceed with the request, the bank will expose the requested information to the AISP. When the AISP requests for information from the bank, the information will be sent to them. In case the PSU had not given his consent, the requested information will not be exposed to the AISP and when the information is requested, the AISP will be notified that the request was not approved by the user. Additionally, the AISP is allowed to check the status of the information request, which allows the ASIP to check whether the user has consented to the request or not.

In order to facilitate the above-mentioned use cases, the Account and Transaction API Specification has defined the resources that should be exposed through endpoints that are to be implemented by the ASPSPs. Each endpoint is defined by URL patterns, the data model that defines the required data, and attributes and parameters to be used during API communication. The access to account information is controlled by a set of data called ‘Permissions’ that permits or restricts an AISP from accessing account information.

Payment Initiation API Specification

The Payment Initiation API Specification focuses on real-time payments and transactions where a consumer will use a third-party application or a service provider to perform a payment, e.g. make an online payment. The API endpoints defined in the Payment Initiation API Specification, facilitate PISPs to submit the payment instructions to ASPSPs, so that the ASPSPs can process the payments given that the PSU had provided the consent to. These endpoints also allow PISPs to check the statuses of the payment instructions.

The flow in detail:

1. The PSU requests the PISP to process a transaction
2. The PISP requests the ASPSP to initiate the transaction
3. The ASPSP authenticates the PSU, upon which the PSU provides the consent
4. The PISP requests the ASPSP to process the transaction
5. The ASPSP processes the payment

When the PSU requests the PISP to process a payment, the PISP will request the bank to facilitate the request. When the consumer confirms with the bank to allow the PISP to perform the payment, that is, when the consumer approves to proceed with the transaction, the bank will note down the status of the consent. When the PISP sends the payment instruction to the bank, it will be processed by the bank according to the consent given by the PSU. In case the consent is given by the user, the payment will be processed, else, the PISP will be notified that the payment was not approved by the user. Additionally, the PISP is allowed to check the status of the user consent as well as the payment instructions sent to the bank.

In order to facilitate the above-mentioned use cases, the Payment Initiation API Specification has defined the endpoints that are to be implemented by the ASPSPs. Each endpoint is defined by URL patterns, the data model that defines the required data, and attributes and parameters to be used during API communication. The specification also includes expected responses, error messages and instructions on handling malformed requests.

How WSO2 Open Banking Adheres to the Open Banking UK Standard

WSO2 Open Banking solution includes implementations of the Open Banking specifications including Open Banking UK Standard. The solution is a combination of WSO2’s renowned products API management, identity and access management, and analytics platforms, which offers a sophisticated compliance experience for financial businesses.

Refer my article on WSO2 library for more information!

Cheers!