EBA clarifies a few obstacles for third-party payment service providers

On 4 June 2020, the European Banking Authority (EBA) published an opinion regarding certain obstacles to the provision of third-party payment services under the Second Payment Services Directive (PSD2). This directive has been applicable since early 2018 and adds a couple of new payment service providers to the EU’s payments landscape, namely account information service providers (AISPs) and payment initiation service providers (PISPs). These so-called third-party providers (TPPs) must be able to connect with their users’ account servicing payment service providers (ASPSPs), usually a bank, in order to perform their services. To make such connection, secure access interfaces are needed. 

The EBA has already formulated regulatory technical standards on strong customer authentication (SCA) and common and secure communication (CSC). These require ASPSPs that have implemented dedicated interfaces to ensure that no obstacles are created to the provision of account information or payment initiation services. However, the standards did not fully specify how this should be operationalized in practice and which market practices could be considered as creating obstacles. 

With this new opinion, the EBA wants to clarify a few things in order to enable customers to use the new and innovative payment services offered by TPPs. Competent authorities in the Member States must now take action to ensure that the ASPSPs under their supervision provide compliant interfaces without obstacles.

In this blogpost, we will briefly examine this opinion to see what it means in practice.

1. Authentication procedures

AISPs and PISPs should be able to rely on the authentication procedures provided by the ASPSPs to their users. All supported authentication procedures should therefore be made available to AISPs and PISPs as well. If, for instance, a bank allows its users to log-in to the online banking platform using biometrics, this option should also be available when the user authenticates through the AISP or PISP. From a technical viewpoint, this may require the support of decoupled authentication or app-to-app redirection to the ASPSP’s authentication app and secure transmission of the authentication status.

Not offering all authentication options available to users to PISPs and AISPs would, then, be considered as an obstacle. Redirection or decoupling should also not create unnecessary friction – for instance by creating extra steps for the user. Sending the user through a redirection from the mobile browser to the app or having the user manually (re-)open apps, would be unnecessary friction. 

2. Mandatory redirection

Redirection is by many TPPs seen as an obstacle, as it is limited to browsers and mobile apps, and thus limits how payments can be initiated. According to the EBA, such redirection is only an obstacle if other authentication options are offered to the user and not made available to the PISP or AISP. If a certain authentication option is the only solution the ASPSP offers to its users, it is not obliged to provide other approaches to PISPs or AISPs. However, if the ASPSP would, for instance, offer instant payments at the point of sale to its users, it should also allow its users to initiate instant payments with the same amount limits using a PISP’s services.

3. Multiple authentications

The authentication procedure involving AISPs or PISPs should not require more SCAs than the procedure involving only the user and its ASPSP would. In the case of PISPs where the necessary information is transferred, a single SCA should suffice to initiate the payment. Requiring more SCAs in such scenario would thus constitute an obstacle. Only substantiated security arguments – such as a suspicion of fraud – should justify multiple SCAs here. Where not all information is transferred – for instance when the account to be debited must be selected by the user at the ASPSP – multiple authentications may be justified. Also when combining AIS and PIS, multiple SCAs may be needed. 

4. 90 days re-authentication

Users must re-authenticate with their ASPSP at least every 90 days. Some AISPs have expressed concern about this, arguing that if their users have accounts at multiple ASPSPs, they would be required to go through SCA with all of them every 90 days in order for the AISPs to provide their services. 

Here, the EBA reminds AISPs that they should principally conduct SCA all the time. An exception in the regulatory technical standards allows them not to conduct SCA when only showing a limited set of data, but even then they still need to re-authenticate every 90 days. To minimize friction, the EBA supports the use of the exception, but maintains the 90 days re-authentication principle. Re-authentication should be performed by the ASPSP, but this can be delegated to the TPP.

5. Account selection

Some cases have been reported where the user is required to manually input their IBAN when going from the AISP or PISP to the ASPSP’s domain. Such manual input can, according to the EBA, be considered as an obstacle. APSPS could, for instance, allow the AISP’s user to retrieve a list of the user’s accounts via the interface, enabling the user to select the right account rather than having to manually enter it. Also in the case of redirection, account selection could be made possible on the ASPSP’s domain after authentication. However, this does not mean that a PISP should get access to the list of all the user’s accounts, as such would be out of scope. 

6. Additional checks to consent

The regulatory technical standards already made clear that ASPSPs asking their users for additional consent in order to be able to use a TPP’s services creates an obstacle. The TPP itself should obtain the user’s consent when using the service, and no second check on consent by the ASPSP should therefore be needed. 

7. Additional registrations

Requiring TPPs to go through an additional registration process with each ASPSP is considered as an obstacle. Some registration may technically be needed to establish the secure communication that is required here, but this should be limited to what is technically necessary and not go further. A pre-registration of the TPP with its contact details with an ASPSP would then be considered an obstacle. 

8. Conclusion 

The EBA’s opinion provides a few welcome clarifications on questions that remained after the implementation of the PSD2. It is clear that some ASPSPs were hesitant to open up to TPPs, and this hesitance has resulted in obstacles that prevent TPPs from reaching their full potential.

In the end, users pay the price for those obstacles, as they make their use of TPPs more cumbersome than it needs to be. With the EBA’s clarifications, some of the most pressing obstacles will now have to be removed, thus benefiting TPPs and their users.

Do you still have questions about this opinion or about your payment services? Please contact Timelex.