The requirements for non-dedicated PSD2 interface and how ASPSPs can meet them

This is the first piece from an upcoming series of articles about non-dedicated PSD2 interfaces. The scope of these articles is to describe to EU-based ASPSPs that have chosen to provide a non-dedicated interface - what are the requirements, how to meet them, and what are the potential challenges. This first piece will cover the requirements legally imposed upon the PSD2 interface and what banks can do to meet them.

According to PSD2, ASPSPs should provide at least one interface for regulated TPPs (including other ASPSPs that act as TPPs) for identification and secure communication. As PSD2 is technology neutral, ASPSPs are free to choose whether to offer a dedicated interface (i.e. API) or a non-dedicated PSD2 interface (i.e. adjustment of their existing PSU facing interface). The technical requirements for both types of interfaces are almost the same, yet the main differences are in the ease of supporting some services/features, cost of implementation, and interfaces’ maintenance.

Article 30 of RTS stipulates the requirements that PSD2 interfaces should meet, regardless of whether the interface is dedicated or non-dedicated. So, I’ll focus on the non-dedicated interfaces and what ASPSPs that chose to provide this type of interface shall do from a technical standpoint.

Article 30 of RTS. General obligations for access interfaces

For the purpose of TPP identification, ASPSPs can rely on eIDAS certificates (Article 34 of RTS). The identification is done by requesting TPPs to provide their eIDAS QWAC certificate during the communication sessions or by asking them to sign all the TPP requests using their eIDAS QSEAL certificate. More details in regards to this topic can be found in the PSD2 TPP identification challenge for ASPSP article.

For secure communication, ASPSPs’ TLS or eIDAS QWAC certificates can be used during the interaction with TPPs.

In most cases, ASPSPs are already providing the status of payment order execution to PSUs on their online banking accounts. Yet, as Article 30 (1)(c) stipulates, ASPSPs will now have to ensure that the information about the execution of the payment transaction is available via its non-dedicated interface - so that TPP can receive all this information.

ASPSPs can use their existing authentication procedures available to PSU that are in conformance with Strong Customer Authentication (SCA) requirements. ASPSPs should not issue additional credentials sets for PSU to use in conjunction with TPP, because it can be seen as an obstacle. All existing PSU authentication flows used in the PSU interface (non-dedicated PSD2 interface) should be available for TPP as well.

ASPSPs should not block or impede TPPs by using such measures as IP blocking, fancy captchas, HTTP headers checks, JavaScripts checks, or any others.

ASPSP should accurately identify the PSU during any communication session. This can be done by means of authentication of PSU at the beginning of the communication session or in case of AIS flow, via long-lived session token based on PSU consent. It’s important to note that the non-dedicated interface shall be adjusted in such a way that it does not drop the session of other TPPs or PSUs when there are several entities using the channel at the same time.

TPP should protect PSU credentials while processing and passing them from PSUs to their ASPSP. It can be done by both TPP and ASPSP using HTTPS/TLS for communication but additional safeguards on TPP side should be implemented as well (i.e. end-to-end encryption).

For communication via the non-dedicated PSD2 interface, ASPSP should use such standards as common HTTP/HTTPS, TLS, HTML, JSON, etc. that are already widely used on the market.

ASPSP should provide complete documentation for TPPs. It should include at least such information as: the used PSU authentication methods (including types of the fields on each step), headers that are used for TPP identification via QSEAL, entry points in case of QWAC TPP client certificates, the URLs and formats of accounts, transactions, payment pages and requests, etc. By using the provided documentation and testing facility (Art. 30 (5) - see below), TPPs should be able to seamlessly integrate with ASPSP’s non-dedicated interface and provide their payment service(s) to PSUs.

ASPSPs shall make available the documentation for TPPs not later than March 14, 2019 or 6 month before the launching of non-dedicated interface in live. Taking into account that March - the deadline for providing a sandbox environment - has already passed, ASPSPs that have chosen to provide a non-dedicated interface for identification and communication with TPP should have offered such documentation long ago. ASPSPs should have also provided a summary of the documentation on their website so that TPPs could easily access it and request the detailed documentation. Lloyds Banking Group, for example, has already published a summary of documentation for non-dedicated interface on their website, and the same was done by Caixa Bank France.

ASPSPs should update the documentation for non-dedicated channels 3 months before undertaking any technical change - so that TPPs can adjust their integration with the ASPSP accordingly to offer a continuous and reliable service. Such changes may include: PSU authentication method updates, modifications in headers that are used for TPP identification via QSEAL, changes in the URLs, data formats of accounts, transactions, payment pages/requests, and so on.

In case of emergency situations related to security, availability and/or integrity of the non-dedicated interface, ASPSPs can make the necessary changes instantly. Yet, such changes should also be documented.

ASPSPs that have chosen to provide a non-dedicated PSD2 interface should have provided a testing facility by March 14. This critical RTS requirement allows TPP to test their integration with the ASPSP’s interface. TPPs can achieve a working and reliable integration with the ASPSP’s non-dedicated interface only by being provided a combination of documentation and testing interface. Without the testing interface, TPPs will be struggling to provide their service to PSU once the live non-dedicated interface is launched. Such testing facility will allow to remove potential errors; from one side it will help ASPSPs to prevent from PSU raising issues, and from another side TPP will be able to provide reliable service to PSUs. Of course, no sensitive or personal identifiable information should be provided via the test facility.

ASPSPs’ obligation towards interfaces available to TPPs, including non-dedicated interface, should be provided in accordance with all the requirements stipulated in Article 30 and competent authorities will ensure that TPPs can still provide services to PSUs when ASPSPs fail to comply with the imposed requirements.

The final and most important PSD2 deadline of September is approaching very fast. Banks are rushing to launch some sort of PSD2 interfaces (dedicated or non-dedicated) that don’t meet all the imposed requirements, and this makes it difficult for TPPs to test their applications; not even to mention that many banks have not even provided a testing facility yet. If some banks decided to go with non-dedicated interfaces, they shall evaluate their compliance solution against the requirements listed above. If some of them are hard to implement, we suggest banks to consider building a dedicated interface.

In the next article, I will list several short term benefits and long term challenges when building a non-dedicated PSD2 interface.