In the previous post, we discussed the basic concepts of Open Banking. This article presents an overview of the Account and Transaction APIs and the changes introduced by v2.0.0 of Open Banking UK Specification.

The Read/Write APIs of Open Banking UK Specification v1.1.0 were released on November 2017 and consisted of:

• Account and Transaction API Specification v1.1.0
• Payment Initiation API Specification v1.1.0

This article focuses on the information domain of the Accounts API and let's discuss the Payments API in a future post.

Let's go through an overview of the Accounts flow:

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

V1.1.0 of the Account and Transaction API, allowed the data exchange between banks and TPPs with regard to the following resources:

• Account details - The resource that represents the account to which credit and debit entries are made e.g. account ID, account type, and currency
• Balances - Representation of the net increases and decreases in an account (AccountId) at a specific point in time. The data model includes account ID, credit/debit indicator, and available balance value
• Beneficiaries - Trusted beneficiaries information including beneficiary ID and creditor account details
• Direct debits - Direct debit information including identification code, status, and previous payment information
• Products - Information pertaining to products that are applicable to accounts, e.g. name and type
• Standing Orders - Standing orders information including frequency and first/next/final payment information
• Transactions - Posting to an account that results in an increase or decrease to a balance. The data model includes transaction history details including the amount, status, balance, and date and time

Each resource is exposed via API endpoints and the corresponding responses are defined in the specification. Each resource can be retrieved in bulk or per a given account and each retrieval is secured by a set of predefined permission codes all of which are defined in the specification.

V2.0.0 of the Read/Write APIs were released in February 2018 and the major change introduced was the list of new resources that are supported by the Account Information API. This effectively expanded the information domain handled by the Account APIs.

The newly added resources are:

• Account Requests - Authorizations to access to the account
• Offers - Details related to offers that are available for the accounts such as offer type, limit, and description
• Party - Information about the logged in user or account owner such as name, email, and address
• Scheduled Payments - Single one-off payments scheduled for a future date with the details including the instructed amount, date and time, and creditor account details
• Statements - Associated information for each statement on the account including the start date, end date, and statement amounts

Unlike Account and Transaction API, the Payment Initiation API was not affected by the v2.0.0 release. The Payment Initiation API includes API definitions that facilitate payments and a payment request includes information such as instruction type, payment amount, creditor details, debtor details, and remittance information. The specification includes comprehensive descriptions of the API endpoints, headers, data models of the requests and responses as well as required security features.

Cheers!

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!