What is the significance of the PSD2 update?

On 8 February 2018, the Berlin Group published the updated specifications for the revised PSD2 Directive. This document is based on both the most recent EBA RTS version and the results of the market consultations on the previous version (0.99) of the Framework, which took place towards the end of 2017.

In this article, we want to outline the most relevant changes and what they mean:

New optional API endpoints
With respect to payment initiation services, only the endpoint for single payments has so far been defined. The new use cases are now standing orders, aggregated orders and scheduled transfers.
With respect to account information services, a new function is now supported besides the existing services, which provides the TPP with detailed information on all the accounts of a payment service user (PSU).

Additional SCA approach with OAuth2
The revised specification now defines two ways to use OAuth2 as support for consent management of PSUs in relation to TPP.
OAuth2 has already been available as a pre-step. In this case, the authentication of the customer before the transaction is translated into an access token, which can then be used at the XS2A interface without having to forward the customer to the authentication server.
What is new is the integration of OAuth2 as the OAuth2 SCA approach for payment initiation authorisation. Contrary to the first option, the PSU will be forwarded to the bank’s authentication server during the transaction. After successful authorisation by the PSU, payments can be automatically initiated or automatically accessed at the account endpoint.

Multi-currency accounts
So far, account information services have only been able to communicate with regular accounts. Multi-currency accounts have now been included in the specification for the first time. This refers to a group of different sub-accounts, which have the same account identification (e.g. IBAN). Sub-accounts are accounts in their own right, which are held in different currencies.

Integration of digital TPP signatures
It is a fact that banks can ask TPPs to use qualified seal certificates based on eIDAS standards. These can be used for signing messages in the application layer by TPPs and offer banks additional security. What is new are the exact requirements for the integration of the signatures in API calls as well as the reference to a new ETSI document (TS 119 495), which is currently available as a draft. This includes a specification of qualified certificates for the PSD2.

Individual API field enhancements
Banks will now be able to add additional data attributes to response messages, as well as send optional data attributes that are additional for TPPs, allowing them to, for example, set up additional or enhanced services. This gives banks greater flexibility when communicating via the XS2A interface. Banks should coordinate the description of the new attributes with the Berlin Group before implementing enhanced data elements in order to continue to ensure a harmonised standard.

Next steps:

In March 2018, the scope of this document will be expanded to include technical specification for OpenAPI, a detailed FAQ document and resolved / implemented feedback consultations. A revised version (V1.1) of the Framework is expected to be published in summer.

Until then, questions regarding the option to initiate API calls from the bank are likely to remain open. According to the current guidelines, these are initiated exclusively by TPPs. However, the plan is to extend the existing pure client-server protocol to a server-server protocol, which will enable banks to initiate API calls.

Version 1.0 of the XS2A Framework is a solid foundation for banks to begin implementing the PSD2. Standard providers of PSD2 software – such as NDGIT – will use it to implement PSD2 and Open Banking products efficiently.