An Account Servicing Payment Service Provider (ASPSP) offers to Payment Initiation Services Providers (PISPs) a functioning redirect model, as part of a dedicated Application Programming Interface (API), meeting all requirements of EBA and local Competent Authority, both in relation to availability, performance and an obstacle free redirect approach where the ASPSP authenticates the Payment Service User (PSU) in the ASPSP domain.

Are Third-Party Providers (TPPs) allowed to re-engineer the customer journey designed by the ASPSP to the effect that authentication of the PSU will take place in the TPP domain?

A practice is noticed where PISPs connect to the ASPSP’s API, and subsequently re-engineer the authentication flow (redirect flow) instead of directing the PSU to the ASPSP domain for authentication. In other words, a PISP uses a hybrid construction in which it connects to the ASPSP’s PSD2 API, but subsequently intercepts the PSU redirect URL (aimed to lead to the ASPSP domain) and embedding the redirection flow directly into the PISP domain to perform screen scraping.     ASPSPs that have opted for a redirect API generally have implemented such redirect API for the sake of security. The PISP can rely on the ASPSP’s authentication procedures by the ASPSP performing Strong Customer Authentication (SCA) in its own domain. There are concerns about this circumvention of the redirect approach by PISPs or TPPs in general. Using the ASPSP’s API yet manipulating/reverse engineering the (obstacle free) customer journey specifically designed by the ASPSP for SCA, is not only non-compliant with the RTS on SCA, but also creates confusion to PSUs and increases security and fraud risks. It is perceived that in case an ASPSP offers a fully functioning PSD2 API in combination with an obstacle free redirection approach there cannot be any legitimate reason for PISPs not to use such API in accordance with the ASPSP design thereof. Clarification on this matter is requested.   

Specific legislative provisions that support this:

•                 RTS SCA Article 31 allows ASPSPs to choose to implement a ‘dedicated interface’ over the alternative of ‘allowing the PSP to use the PSU interface’
•                 PSD2 Article 97.5 and subsequently RTS SCA Article 30.2 require ASPSPs to make available to TPPs all authentication procedures 

it provides to its PSUs. This implies that the authentication methods (redirection, decoupled or embedded) which the ASPSP needs to make accessible to the TPP must be equal to the actual authentication procedures the ASPSPs have available to its PSUs. This also implies the use thereof by the TPP.

                Paragraph 48 of the EBA Opinion on the implementation of the RTS SCA and CSC of June 2018: In the cases of redirection and decoupled approaches, PSU’s authentication data are exchanged directly between PSUs and ASPSPs, as opposed to embedded approaches, in which PSU's authentication data are exchanged between TPPs and ASPSPs through the interface.