Do Account Servicing Payment Service Providers (ASPSPs) have the right to block access to payment accounts for a Third Party Provider (TPP) who embeds the ASPSP-provided redirection website in order to provide the Payment Service User (PSU) with a TPP-provided user interface?
According to Article 68(5) PSD2, an ASPSP may only deny TPPs access for objectively and duly evidenced reasons related to unauthorised or fraudulent access, including fraudulent initiation of payment transactions. It has however happened that ASPSPs have contacted TPPs to say that they will restrict access to the PSD2 Application Programming Interface (API) because the TPP embeds the redirection domain provided by the ASPSP for PSUs to enter their credentials when using the services of a TPP. The stated reason is that the PSU in this instance does not enter its credentials into the ASPSP-hosted redirection domain but into an interface provided by the TPP.
If the ASPSP offers a redirection-only API, the TPP can improve the user journey by embedding the redirection domain and provide the user with a TPP-provided user interface (instead of requiring the user to enter the credentials into the redirection domain). This allows the TPP to e.g. provide a user interface in different languages, different font sizes and/or adapted to different devices/technology environments. As an example, a web-based redirection domain would not work in environments that are not web-browser based, such as e.g. gas stations, smart watches, Point of Sale terminals, internet of things, AI and voice assistants, etc. whereas the TPP would be able to provide user interfaces adapted for such environments by means of embedding the redirection domain.
Articles 45 and 46 PSD2 specify which information the TPP needs to provide to the PSU when providing such user interfaces and the transmission of security credentials needs to be done in a secure manner with encryption applied using RTS compliant techniques. To be clear, embedding the redirection domain is not “screen scraping” as the TPP identifies itself vis-a-vis the ASPSP (and leverages the PSD2 API); it only means the TPP can adapt and improve the user interface and as such convenience for the PSU.
The ASPSP does not need to do anything to enable embedded redirection; the work is solely at the side of the TPP. Alternatively, the ASPSP can of course as a part of its PSD2 API actively enable an embedded flow, which would mean the TPP would not have to embed the redirection domain itself. But the ASPSP must not block or otherwise make it difficult for the TPP if the TPP elects to build its own PSU-facing interface and transmit the credentials to the redirection domain of the ASPSP as TPPs may transmit credentials pursuant to Article 66(3)(b) PSD2.
Article 68(5) PSD2 provides that an account servicing payment service provider (ASPSP) may deny an account information service provider (AISP) or a payment initiation service provider (PISP) access to a payment account for objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account.
Q&A 6044 clarified that:
It follows from the above that the approach described by the submitter, where the PISP/AISP “embeds” the ASPSP’s redirection domain, would not be in line with Article 30(3) of the Delegated Regulation.
In addition, such an approach may lead to a situation where the ASPSP identifies, based on its transaction monitoring mechanisms under Article 2 of the Delegated Regulation, that it is not the PSU who is trying to access the account and subsequently denies access to the payment account. In such case, the denial of access to the account would be in line with Article 68(5) PSD2.