<-SM->
bfsi
2018/08/30
30 Aug, 2018

How WSO2 Open Banking Adheres to the Open Banking UK Standard

  • Sachithra Dangalla
  • Senior Software Engineer - WSO2

This article presents an overview of the Open Banking UK Standard and its API specifications, the changes in the latest version, the security features specified by the Standard as well as the key features of WSO2 Open Banking that have allowed it to comply with the latest version of the Open Banking UK Standard.

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).

Figure 1

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.

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.

Open Banking UK Standard

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.

  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.

Figure 2

  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.

Figure 3

  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.

Read/Write API Specification v2.0

The latest version of the Read/Write API Specification was released in February 2018, which expanded the information domain handled by the Read Write APIs. The previous versions of the Account Information 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

In v2.0, the following were added to the list of resources:

  • 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

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.

Unlike Account and Transaction API, the Payment Initiation API was not affected by the v2.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.

Adhering to UK Standard with WSO2 Open Banking

WSO2 Open Banking solution is consistently updated with the latest specification versions and currently, it complies with the UK Standard’s Read/Write API Specifications v2.0. In addition to offering innovative solutions for financial businesses, WSO2 Open Banking supports customers to upgrade to the latest specification versions.

WSO2 combines API management, identity and access management, and analytics to offer a complete Open Banking solution that consists of an implementation of the specification, adherence to security requirements, and streamlined user experience. Let’s take a look at some of the key components of Open Banking UK Standard that play a major role in the security and privacy of data, all of which are featured in WSO2 Open Banking.

Consent Management

User consent is a significant factor in Open Banking that determines the level in which the third-party providers can access the account information. Open Banking outlines a 3-step consent model named as consent management that follows consent, authentication, and authorization.

  • Consent is the process by which a TPP requests permission from the PSU to approach the ASPSP for information.
  • Authentication is the process by which the PSU is identified by the ASPSP as a valid consumer.
  • Authorization is the process that allows the PSU to provide a confirmation to the ASPSP regarding the consent given to the TPP.

Open Banking UK Standard has introduced a model of consent management on top of which WSO2 Open Banking has implemented a unique consent management module that handles the consent flow including user consent, authorization, and authentication.

OAuth2

OAuth 2 is an authorization framework that allows a user to authorize a TPP to access PSU information maintained at the ASPS without sharing any credentials with the TPP. Article 32, Obligations for a Dedicated Interface, of European Banking Authority (EBA) Regulatory Technical Standards (RTS), specifies that the ASPSPs should implement dedicated interfaces that will be used by TPPs to redirect PSUs for authorization purposes while preventing TPPs from acquiring the credentials of the PSUs. OAuth2 essentially serves this purpose by delegating the user authentication functionality solely to the ASPSP. The Open Banking Security Profile emphasizes the need of OAuth2 in data flows. WSO2 Open Banking follows OAuth2 protocol to offer streamlined authorization services.

OpenID Connect

While OAuth2 serves authorization, OpenID Connect or OIDC serves the requirement of authentication. That is to allow ASPSPs to confirm the identity of the PSUs before they grant authorization to TPP. This is usually achieved using an identity provider that will manage information about the users and authenticated sessions. While OAuth2 allows users to permit TPPs to access the information, OIDC allows the ASPSPs to check who the user is. WSO2 Open Banking implementation includes OIDC support as per the requirements of the Open Banking Security Profile.

Strong Customer Authentication

As the name implies, Strong Customer Authentication (SCA) refers to the strict method of verifying the identity of a user. PSD2 mandates SCA for online payments that are elaborated in Articles 1-36 in EBA RTS for SCA. In order to achieve SCA, multi-factor authentication is used, in which, at least two of the following elements should be satisfied for an authentication to be successful:

  1. Something the user knows, e.g. a password (Article 6 ~ Requirements of the elements categorized as knowledge)
  2. Something the user owns, e.g. a key (Article 7 ~ Requirements of the elements categorized as possession)
  3. Something the user is, e.g. biometrics (Article 8 ~ Requirements of devices and software linked to elements categorized as inherence)

However, exemptions from SCA can be allowed based on predefined conditions in order to improve the user experience.

Adaptive Authentication

Adaptive authentication refers to the process of dynamically selecting the types of multi-factor authentication depending on the user’s risk profile and behavior. This can be based on the device profile (e.g. the request coming from an unidentified device), location awareness (e.g. the user location is identified as risky), or the user behavior (e.g. the user tries to access certain resources for the first time). The configuration of adaptive authentication can either be based on static policies that are defined with regards to statistics such as the user role, the importance of the resource, location, time, etc. or dynamic use cases where the system learns and predicts the behavior of the user through learning techniques. Regardless of how the corporate risk levels are defined, adaptive authentication should adapt to them and employ the appropriate authentication methods. In WSO2 Open Banking solution, adaptive authentication is used to implement SCA exemptions as defined in EBA RTS for SCA article 10-18.

Request Object Support

The Request Object support facilitates parameters to be sent in a self-contained JWT instead of plain request parameters. The request object can be represented either by value, in which the encrypted request object is set as a parameter with key “request”, or by reference, in which the request is passed as a reference with key “request_uri”. The payload of the request is essentially a JSON object and it comprises a set of mandatory claims as well as any optional value based on the requirement. The Request Object can either be in plaintext (unsigned) or signed, wherein the server will extract the certificate from the Request Object and perform validations in order to fulfill the process of authentication. The requirement of Request Object support is elaborated in Open Banking Security Profile and is implemented in WSO2 Open Banking solution.

Private Key JWT Authentication

Private JWT Client Authentication is a method used to authenticate a user by using the token endpoint. This allows the server to authenticate only that clients who have registered the public keys. The request is communicated via JWT, that consists of two JSON objects namely JWT header and JWT body. Initially, the user is required to sign the JWT using his private key, and share his public key with the authorization server. Subsequently, get the JWT token, that is then used by the authorization server to authenticate the user. JSON Security Suite in Open Banking Security Profile defines the requirements of JWT authentication which are followed by WSO2 Open Banking.

Conclusion

This article discusses the Open Banking UK Standard and its key components in the context of how WSO2 implements the APIs, features and other specification requirements. By combining the features with the implementation of the requirements, WSO2 Open Banking offers a unique solution that adheres to the latest version of the Open Banking UK Standard.

 

About Author

  • Sachithra Dangalla
  • Senior Software Engineer
  • WSO2