Create new digital services
using Open Banking APIs
by Cooperative Bank of Thessaly
according to PSD Directive

Learn more about PSD2
apis mouse

AISP Production Service under PSD2 Open Banking API

1. Introduction

The following guide demonstrates how to use the PSD2 Open Banking APIs in the production environment, for AISP TPPs. If you have tested your application scenarios with the Sandbox APIs, there are only a few changes you need to make in order to go live.

If you haven’t familiarize yourself with the Sandbox APIs, please visit the Sandbox Guide Developer’s example page to learn more about the API calls and the AISP scenario.

2. SCA Workflow

According to the PSD2 Directive, Strong Customer Authentication (SCA) practices need to be implemented so that PSUs can authorise consents and provide TPPs with access to their accounts. Amongst the available approaches, the Bank’s implementation supports both the SCA Redirect flow and SCA Embedded approach, with added OTP functionality.

SCA Redirect flow is used for PSU Authentication (OAuth):

  • PSU is redirected to a secure environment provided by the Bank’s Infrastructure
  • PSU authenticates himself by providing his web banking credentials
  • Once the PSU is authorized, he is redirected back to the TPP application

SCA Embedded Approach is used whenever a payment initiation request is created by the TPP:

  • TPP requests a payment using the PSU Authorization Token
  • Bank sends an SMS one time password (OTP) on customer’s mobile
  • PSU authenticates himself by providing the one-time password (OTP)
  • PSU can then provide his consent so that the TPP can access his account information

In the Sandbox flow, this procedure was simulated by using the one time password “123456”, and PSU data was mocked for testing purposes.

3. TPP Identification

3. TPP Identification

One more area that needs to be covered while moving into the production APIs, is the identification of TPPs. In the Sandbox Developers portal, Client ID and Client Secret parameters where produced for the test application, and where used in the API calls as an identification method for the TPP.

According to PSD2, only certified TPPs are allowed to access the Bank’s dedicated interface. TPPs need to carry a valid PSD2 eIDAS certificate (QWAC & QSealC) to identify themselves and use the APIs via a secured channel. The PSD2 eIDAS certificates are issued by Qualified Trusted Service Providers (QTSPs). The European Banking Authority (EBA) provides a list of the trusted QTSPs here.

So in order to use the production Open Banking APIs, instead of attaching only Client ID and Client Secret in your call headers, you also need to provide your eIDAS certificate in the tpp-signature-certificate header parameter.

The XS2A interface will check the validity of the certificate against known formats, and also check the regulatory status of the TPP by referring to the TPP register provided by the EBA here.

4. AISP Scenario

We will cover a basic scenario, where an AISP TPP initiates a consent for access to the PSU’s account(s).

Flow:

  1. PSU Login: User is required to login with his e-Banking credentials
  2. Create a consent to access the PSU account(s)
  3. OTP: OTP is generated for secure authentication
  4. Consent finalisation: After consent is authorised, PSU is able to access his accounts through TPP.

The API calls have been tested with the Postman application.

Create Consent

The required Header parameters:

  • tpp-signature-certificate: The qualified PSD2 eIDAS certificate for TPP identification
  • X-Request-ID: Unique identifier for the TPP application
  • PSU-ID: Unique identifier of the account holder (PSU) (e.g web banking username)

The request Body format:

The specific body is used to request access to all the PSU accounts. If you want to request access to a specific account, or for specific fields only (e.g see only balances) you can modify the request body according to the API specification.

Response (OTP is generated for secure authentication):

Authorise consent (PSU provides the one-time password sent to his phone, to complete the authentication process):

The required Header parameters:

  • tpp-signature-certificate: The qualified PSD2 eIDAS certificate for TPP identification
  • x-ibm-client-id: The TPP client id
  • x-Request-ID: Unique identifier for the TPP application

The Request Boby Format:

Response (Consent authorized):

You can now access the PSU accounts via the “Read Account Details” GET call in the Account Details folder of the AIS collection

After PSU grants consent, “Read Account Details” fetches all the accounts available for the given PSU

5. Conclusion

The above steps cover a basic AISP scenario using the production APIs. The guide was focused on demonstrating the SCA process and consent management. As an AISP, the above process has to be followed once. Each accounts consent has a validity of 90 days. For this duration, you can implement the rest of the API calls for access to accounts as in the Sandbox case.

6. Useful links

5. Conclusion

The above steps cover a basic AISP scenario using the production APIs. The guide was focused on demonstrating the SCA process and consent management. As an AISP, the above process has to be followed once. Each accounts consent has a validity of 90 days. For this duration, you can implement the rest of the API calls for access to accounts as in the Sandbox case.

6. Useful links