EU Regulatory Technical Standards for Strong Customer Authentication Enter Into Force

In Short

The Situation: The second EU Payment Services Directive requires banks to give third-party payment service providers ("TPPs") access to the bank accounts of their customers (with their consent), in order to enable TPPs to provide account information and payment initiation services.

The Result: The regulatory technical standards ("RTS") on strong customer authentication and secure standards of communication lay down minimum requirements for the interfaces between banks and TPPs.

Looking Ahead: The RTS ban traditional "screen scraping". Banks that make available a dedicated interface for account access by third-party service providers will also be allowed to block forms of "screen scraping", whereby a TPP identifies itself to the bank. Nevertheless, even banks that make available a dedicated interface must allow "screen scraping" as a contingency measure.

On March 14, 2018, the Commission Delegated Regulation No 2018/389 supplementing PSD2 with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication entered into force. The obligations set forth in these regulatory technical standards ("RTS") will apply after a transitional period of 18 months, on September 14, 2019.

How Did We Get Here?

The revised Payment Services Directive (EU Directive No 2015/2366), known as PSD2, entered into force on January 12, 2016, with transposition into national Member State law by January 13, 2018. PSD2 mandates the European Banking Authority ("EBA") with developing RTS on strong customer authentication ("SCA") and secure standards of communications between account-servicing payment service providers ("ASPSPs", mainly banks), third-party payment service providers ("TPPs"), payers, and payees.

On February 23, 2017, the EBA submitted draft RTS to the European Commission for adoption. However, the Commission disagreed with parts of the EBA's draft and, in a controversial move, decided to amend it. The Commission finally adopted an amended version of the RTS on November 27, 2017, which takes into account some of the EBA's comments on an intermediary draft.

The adoption by the Commission was followed by a three-month period for review by the European Parliament and the Council, which lapsed on February 27, 2018. As neither institution raised any objections, the Commission went ahead with the publication of the RTS in the Official Journal of the European Union. The RTS entered into force on the day after their publication, on March 14, 2018.

The RTS set out minimum requirements in relation to: (i) SCA; (ii) protection of the confidentiality and integrity of payment service users' personalized security credentials; and (iii) common and secure standards of communication. In this Commentary, we discuss only the first and third aspects.

Strong Customer Authentication

SCA under PSD2 requires (at minimum) two-factor authentication based on two or more of the following elements:

• knowledge (something the user knows—for example, a password or a PIN),
• possession (something the user owns—for example, a card or smartphone), and
• inherence (something the user is—for example, a fingerprint or iris scan).

Combining these elements should result in generating an authentication code. The RTS establish minimum requirements for each of these elements, as well as the dynamic linking of the transaction to a specific amount and a specific payee (such that any change to the amount or the payee results in invalidating the authentication code). The independence of each SCA element should be guaranteed, so that the breach of one element does not compromise the other elements.

The RTS provide for several exemptions from the obligation to use SCA, including for contactless payments and low-value transactions (with limits on the amounts and the number of consecutive transactions). The Commission added an exemption to the ones already contained in the EBA's draft for electronic payment transactions initiated through processes made available only to payers who are not consumers. This exemption specifically aims at business-to-business and machine-to-machine transactions using specific protocols, for which the use of SCA might be impractical. Nonetheless, the RTS also provide for close monitoring of fraud rates, and payment service providers must cease making use of the exemptions if the monitored fraud rate exceeds certain thresholds.

Common and Secure Standards of Communication

PSD2 introduced two new types of TPPs: (i) account information service providers and (ii) payment initiation service providers. The objective is to stimulate competition and innovation in payment services by facilitating account access by players other than banks, while at the same time subjecting these players to regulation for the first time. TPPs may be fintech companies but also other banks. For instance, on the basis of access rights under PSD2, a bank could enable its customers to use its own banking applications to access accounts held at other banks, acting as a TPP toward the other banks.

The interface between banks and TPPs is probably the most controversial aspect of the RTS. Currently, TPPs commonly use a technique called "screen scraping" to access bank account information and initiate payments. Screen scraping means access through the customer interface of the bank (with an overlay from the TPP), using the customer's security credentials. Generally speaking, banks sought a complete ban on screen scraping on security and cost grounds, while the fintech side of the debate favored the continued use of screen scraping, at least as a fallback solution.

The RTS confirm that traditional screen scraping, whereby the TPP impersonates the customer and thus has access to all the customer's data without identifying itself to the bank, will be banned after the 18-month transitional period. However, screen scraping is not entirely dead. Banks can comply with the obligation to open up their accounts to TPPs in two ways, either by making available a dedicated application programming interface ("API") or by allowing TPPs to use their own customer interface. The second option is basically screen scraping, except that TPPs must now identify themselves to the banks.

In addition, the RTS require banks that opt to use APIs to have contingency measures in case of unplanned unavailability of the interface or a systems breakdown (presumed in the absence of reply within 30 seconds to five consecutive requests). This fallback mechanism is accessed through the bank's customer interface, which is essentially screen scraping.

Competent national authorities may exempt banks from the obligation to have such a fallback mechanism in place if they can demonstrate that their dedicated interfaces are sufficiently robust. The authorities can revoke such an exemption if the dedicated interface no longer meets the conditions of the exemption for more than two consecutive calendar weeks. In that case, the bank must make available the contingency measure within two months.

In practice, the RTS' fallback mechanism provision may mean that banks opting for APIs must develop both a dedicated interface and an identification layer for direct access using the customer interface. This may be necessary even if national authorities grant an exemption from the fallback mechanism, since developing an identification layer for TPP access would not be practicable within the above-mentioned two-month period.

A dedicated interface must offer at all times the same level of availability and performance as the banks' own customer interface. Banks must define transparent key performance indicators and service-level targets for the dedicated interface such that these are at least as stringent as for the customer interface.

Although the obligation to make available either a dedicated interface or a TPP identification layer in the customer interface will apply only after the transitional period of 18 months, in practice, banks must be ready in 12 months. This is because the RTS provide that banks must make available interface documentation as well as a testing facility no later than six months before the RTS' application date, in order to give TPPs enough time for their own software development.

The access to accounts, or "XS2A", regime introduced by PSD2 represents a challenge both for banks and fintech companies. Reliance on "hacks" such as screen scraping (in the traditional sense) is eliminated. Also, without standardization of APIs, TPPs potentially face developing software that can "talk" to the different APIs of hundreds of banks. This situation opens opportunities for providers of API "aggregator" or "hub" services. While there is no EU-wide standard underway, various standardization initiatives are now emerging. These include government initiatives such as Open Banking in the United Kingdom and industry initiatives such as the Berlin Group in Germany or STET in France.

The text of the RTS is available here. The European Commission has also published a fact sheet concerning the RTS.

Five Key Takeaways

1. The RTS' requirements regarding SCA and interfaces for third-party access to the accounts will become effectively applicable after a transition period of 18 months, on September 14, 2019.
2. The RTS provide for several exemptions from the general obligation to use SCA, but these can be lifted if monitored fraud rates exceed certain thresholds.
3. For third-party access to bank accounts, traditional screen scraping will be banned. However, banks must still enable a form of screen scraping whereby TTPs identify themselves as such, either as the main solution for access to the accounts or as a fallback mechanism.
4. Banks must be ready with the development of the interfaces for third-party access within 12 months, to give TPPs time to integrate the banks' APIs by September 2019.
5. In the absence of an EU-wide API standard for PSD2, reducing the complexity of connecting banks and TPPs will largely depend on national or regional standardization initiatives and providers of "aggregator" services.

Lawyer Contacts

For further information, please contact your principal Firm representative or one of the lawyers listed below. General email messages may be sent using our "Contact Us" form, which can be found at www.jonesday.com/contactus/.

Philippe Goutay
Paris
+33.1.56.59.39.39
pgoutay@jonesday.com  

Olivier Haas
Paris
+33 1 56 59 38 84
ohaas@jonesday.com  

Alexandre Verheyden
Brussels
+32.2.645.15.09
averheyden@jonesday.com  

Karl Stas
Brussels
+32.2.645.14.64
kstas@jonesday.com

Jones Day publications should not be construed as legal advice on any specific facts or circumstances. The contents are intended for general information purposes only and may not be quoted or referred to in any other publication or proceeding without the prior written consent of the Firm, to be given or withheld at our discretion. To request reprint permission for any of our publications, please use our "Contact Us" form, which can be found on our website at www.jonesday.com. The mailing of this publication is not intended to create, and receipt of it does not constitute, an attorney-client relationship. The views set forth herein are the personal views of the authors and do not necessarily reflect those of the Firm.