PSD2 - What Legal Questions Third Party Providers Will Have to Ask Themselves

Most of the provisions of Directive 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services (“PSD2”) will need to be implemented by January 2018.

As an exception to the above, the deadline for implementing the provisions concerning the security of payment services (including strong customer authentication or “SCA”), and the technical details of how account servicing payment service providers (“ASPSPs”, mainly banks) are expected to provide third party payment service providers (“TPPs”) access to payment accounts, is currently set towards the end of 2018 (although is not yet set in stone, and may therefore slip towards the beginning of 2019 — see below for more details).

Below we address the main questions that TPPs need to consider in order to prepare themselves for the challenges arising from PSD2. As you will see, most questions turn around the issue of security — i.e. how to ensure secure communication between the TPPs and the banks and/or the security of payments, and/or how can TPPs ensure the security of the data that they will collect.

The below information takes into account the draft Regulatory Technical Standards (“RTS”) on strong customer authentication and common and secure communication between banks and TPPs that the European Banking Authority (the “EBA”) published on 23 February 2017.

1. What will be the standards of communication between banks and TPPs?

The draft EBA RTS allows banks to choose whether to set up a “dedicated interface” (typically an account programming interface or “API”), or to allow TPPs access to the same interface as the one made available by the bank to its customers.

If the bank opts for a “dedicated interface”, it will need to ensure the same level of availability and performance as the interface offered by the bank to its customers. The bank will also need to provide contingency measures in case of unplanned unavailability, including alternative options that TPPs can use during the downtime.

Assuming that most (if not all) banks decide to opt for a dedicated interface, this will likely result in many different interfaces being offered by banks, and therefore a need for TPPs to adapt their systems to each bank they would want to communicate with. This would certainly generate costs for TPPs and result in a lack of interoperability. This is why TPPs are continuing their lobbying on the draft EBA RTS, with a view to forcing the banks to offer at least one common dedicated interface.

2. What will happen with screen scraping?

Due to the requirement under PSD2 for TPPs to identify themselves towards the bank, the current TPP practice of accessing the payment account using the consumer’s credentials (referred to as “screen scraping”), which does not allow the bank to identify whether it is the consumer or a TPP that is logged into the account, will no longer be allowed once the RTS become applicable (i.e. as from November 2018, at the earliest).

Assuming that the banks deliver the interfaces by the time the RTS become applicable, TPPs would have a solution to continue to access the account. However, should there be a time gap between the prohibition of screen scraping and the banks making the interfaces available (which would be a technical breach by the banks of their obligations under PSD2 and the RTS), TPPs could face periodic difficulties in providing their payment services to customers.

3. How to ensure the safety of customers’ data obtained in the course of TPPs providing services?

Under PSD2, there are two different sorts of TPPs: payment initiation service providers (“PISPs”) and account information service providers (“AISPs”). PISPs “push” a payment from the payment account of the customer to another payment account (e.g. an online merchant), whereas AISPs collect data from payment accounts, typically aggregating this data from different banks.

PISPs are only entitled to information on the initiation and the execution of the payment order.

However, pursuant to the draft EBA RTS, AISPs will obtain access to the same data that is made available by the banks to the customer in relation to his/her payment accounts, including data protected by banking secrecy. AISPs will have to prepare their organisation for processing, protecting and transferring this data, in particular if such data is covered by banking secrecy. In our opinion, the services offered by AISPs will only be successful if they offer a level of security comparable to that offered by the banks. If this level is lower, customers may not be ready to use the services offered by AISPs.

4. What type of payment transactions/activity require strong customer authentication?

One of the requirements of PSD2 is to apply SCA in particular when the consumer accesses its payment account online or initiates an electronic payment transaction. SCA requires the use of two or more factors, categorised as knowledge (something only the user knows), possession (something only the user possesses) and/or inherence (something only the user is), that need to be mutually independent.

However, the draft EBA RTS provides for possible exemptions to the principle of SCA, which will be important for TPPs’ business:

A “read-only” exemption, where the consumer can access his account balance and list of payment transactions executed within the last 90-day period, without SCA (relevant for AISPs).

A remote electronic payment transaction that does not exceed EUR 30 (and a cumulative value of EUR 100 or 5 remote transactions) without SCA; and an exemption for low-risk transactions, where the low level of risk is determined on the basis of a “transaction risk analysis” (“TRA”, otherwise referred as “Risk-Based Authentication”/RBA) (relevant for PISPs).

From the TPPs’ perspective, one of the biggest questions is whether they will be required to rely upon the authentication procedures agreed between the bank and the customer, or whether that is only an option — meaning that TPPs are free to agree to a different authentication procedure directly with the customer (in which case it may be worth investing in such a proprietary authentication solution). The situation is not entirely clear on this topic, and some TPPs are continuing to lobby for the second option.

Authors:
Scott McInnes, Partner at Bird & Bird, Belgium.
Marta Stanisławska, Associate at Bird & Bird, Warsaw.
Adam Łukaszewski, Junior Associate at Bird & Bird, Warsaw.