FAQ on PSD2

What is PSD2?

In the early 2000s, screen scraping became a regular means in the US for payment initiation service providers to process payments on behalf of customers. The European Commission and the European Banking Authority reacted by issuing a Payments Services Directive (PSD) in 2007 and a new version PSD2 that formally went into effect in September 2019. The key objectives of the PSD2 directive are creating a more integrated European payments market, making payments more secure and protecting consumers.

To comply with PSD2, financial organisations must make their payment and account APIs accessible to Third Party Providers. Examples include payment initiations from a bank account and viewing bank account transaction data.

The most visible change of PSD2 is that banks are obliged to make payment accounts accessible online to third parties, so-called fintech providers. This way, FinTech providers (banks as well as non-bank platforms) can initiate payments and retrieve account information for a customer of any bank operating in the EU. This enables aggregator platforms to be created that link into multiple banks. Obviously, to protect bank customers, FinTech providers need to be licensed and need to obtain detailed consent from the account holder.

What is Open Banking?

In the UK, the Competition and Markets Authority (CMA) was concerned about a perceived lack of innovation and competition in the financial space around the same time as the EU/EBA PSD2 initiative. In fact, the CMA established the UK Open Banking program before PSD2 was enacted. Under the Open Banking program, the nine major British banks and building societies were required to allow consented access to account and payment data.

The program effectively resulted in an API-based Open Banking standard developed under the guidance of the UK Open Banking Implementation Entity. As the Open Banking standard explicitly aligns with PSD2, its technical specifications can be used for the creation of a PSD2 API as well. In fact, it covers following PSD2 use cases:

  • Payment Initiation Service defined by article 66 of PSD2,
  • Account Information Service defined by article 67 of PSD2, and
  • Confirmation of the Availability of Funds service defined by article 65 of PSD2.

What is the Berlin Group?

The European Banking Authority’s drafted Regulatory Technical Standards (RTS) for PSD2. This RTS, however, specifies only technical framework conditions and does not standardise an API framework. Because PSD2 aims to develop a unified, innovative, pan-European digital ecosystem for financial products, uniform interfaces and processes are essential.

Initiatives were being launched in France, Poland and Slovenia to fill the gap. The Berlin Group, consisting of almost 40 banks, associations and payment processors from across the EU, aimed a pan-EU approach. They now have defined a common API standard called NextGenPSD2.

What is NextGenPSD2?

NextGenPSD2 is a common API standard developed by the Berlin Group for uniform and interoperable communications between banks and Third Party Providers of payment services. It incorporates pan-European requirements on customer consent handling for Access-to-Account services (dubbed XS2A) and covers following PSD2 use cases:

  • Payment Initiation Service defined by article 66 of PSD2,
  • Account Information Service defined by article 67 of PSD2, and
  • Confirmation of the Availability of Funds service defined by article 65 of PSD2.

NextGenPSD2 follows the REST service approach and adopts the Swift standard for payment messages, namely ISO 20022 in JSON or XML. NextGenPSD2 further adopts OAuth 2 as an option for user authentication and authorisation.

What is openFinance?

OpenFinance is an API framework announced by the Berlin Group end of 2020 that will build on their NextGenPSD2 API Framework. Based on open industry standards (e.g. REST, JSON, ISO20022), the openFinance API Framework will set standards for additional services such as Pay by Loan, Request to Pay and Reservation of Funds.

How does OAuth relate to PSD2?

While PSD2 is a legal directive, OAuth 2 is a solution within a standardised API framework. Both NextGenPSD2 of the Berlin Group and the UK Open Banking API standard support OAuth 2 for customer authentication and authorisation. In this case, the user will be the OAuth Resource Owner, the bank will be the OAuth resource Server and the third party provider (another bank or a payments platform) will be the OAuth Client.

NextGenPSD2, however, considers OAuth 2 as an one of the options. It supports two ways of integrating OAuth2:

  • Using OAuth 2 for authentication of a user in a pre-step, translating this authentication into an access token to be used at the XS2A interface afterwards,
  • Using OAuth 2 for authorisation of payment initiations and payment consents, building upon Strong Customer Authentication (SCA).

How does MFA relate to PSD2?

Multi-factor authentication (MFA) is part of the Strong Customer Authentication (SCA), the Regulatory Technical Standard (RTS) issued by the European Banking Authority relative to PSD2.

SCA states that a payment services provider authenticates a payer using two or more of the following elements: knowledge (something you know), possession (something you have) and inherence (something you are). SCA adds dynamic linking of transaction details (amount and payee) to the multi-factor authentication of the payer.

Dynamic linking makes sure that an “authentication code” that is provided after MFA has been successfully completed is only valid for that specific transaction. The three key criteria are:

  • the payer is made aware of the amount of the payment transaction and of the payee.
  • the authentication code generated shall be specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction.
  • the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the payee agreed to by the payer. Any change to the amount or the payee shall result in the invalidation of the authentication code generated.

NextGenPSD2 defines four approaches to implementing the SCA security flows: Redirect, OAuth 2, Decoupled, and Embedded. The bank determines which of these approaches it will make available to the third party provider.

How does OIDC relate to PSD2?

PSD2 requires the customer (the payer) to be identified and the EBA RTS requires SCA to be applied.

For this, UK Open Banking requires that banks (i.e. Account Servicing Payment Service Provider in general) support the issuance of OIDC 1 ID-tokens and Third Party Providers may request that an ID-token is issued. In addition to OIDC 1, Open Banking requires FAPI to further standardise the contents of the ID-token and to strengthen the authentication.

NextGenPSD2 of the Berlin Group allows ODIC 1 ID-tokens to be used as one of the options.

Note that there are differences in the contents of the ID token: wheras UK Open Banking uses a special claim to identify the payment, NextGenPSD2 uses a dynamic scope value.

What is FAPI?

Financial grade API (FAPI) is an API security framework from the OpenID Foundation, issuers of the OIDC 1 standard. FAPI originated at Open Banking and provides technical guidance and requirements to achieve API security levels that meet the requirements in the finance sector as well as healthcare, HR, insurance and beyond.

Despite providing a strong baseline for security, OAuth 2 and OIDC 1 do contain some vulnerabilities and loopholes. Moreover, their specifications are broadly defined and leave room for interpretation and implementation options which, paradoxically, negatively affect interoperability.

FAPI aims to address both of these shortcomings, effectively removing optionality by mandating the use of specific and secure processes. In short, FAPI expands upon OAuth 2 and OIDC 1 to close the vulnerabilities and significantly improve interoperability. FAPI does this in four critical ways:

  • All exchanges between client and server use JSON Web Tokens (JWT).
  • JWT must use asymmetrical key pairs ensuring a cryptographic password exchange.
  • A limited set of secure algorithms are allowed in JWT exchange.
  • It provides conformance testing methods, which can be automated.

With open banking now clearly embraced by banks across the globe, it is not surprising to see FAPI being adopted to improve digital collaboration in other verticals, for example insurance, healthcare, HR, travel, hospitality and retail.

What is CIBA?

Client Initiated Backchannel Authentication (CIBA) is part of FAPI and is issued by the OpenID Foundation, issuers of the OIDC 1.0 standard. Compared to OAuth 2 and OIDC 1, CIBA specifies an alternate method of users granting access to their resources whereby the flow is started from a consumption device, but authorised on an authentication device. Its authentication flow links a direct Relying Party directly with the OpenID Provider without redirects through the user’s browser.

CIBA addresses the need for dynamic linking with SCA in PSD2. Dynamic linking payment details need to be securely delivered to the user, the user needs to consent to those details, and the whole process must be strongly authenticated. The outcome must be an authentication code that can be verified against the original request, along with the user’s identity.

CIBA does not by itself provide dynamic linking. It is however an important part of the puzzle, providing the secure channel to an end user device for digital signature. Put simply, CIBA is a new OAuth 2 grant type for OIDC 1.0 tokens.

For an example of how PSD2 and CIBA can work in practice, please have a look at our post: https://nura.pro/2021/08/16/passwordless-payment/.