PSD2 RTS on authentication and communication


PSD2 RTS on authentication and communication

The devil is in the (lack of) details

Following the entry into force of the revised Payment Services Directive (PSD2) on 12 January 2016, in August the European Banking Authority (EBA) published the draft regulatory technical standard (RTS) to define how, in practice, Access to Accounts for Third Party Providers (TPPs) and enhanced security and authentication requirements, two key pillars of the directive, will be implemented. In this article, we explore some of the major implications for the payment industry, and banks in particular.

Enhanced security and authentication requirements

Under PSD2, all Payment Service Providers (PSPs) will be required to apply Strong Customer Authentication (SCA) every time a payer initiates an electronic payment transaction, with a few exemptions.

The cost of designing, implementing, and auditing the effectiveness of the SCA procedure will fall on the Account Servicing Payment Service Providers (ASPSPs), i.e. the banks. Whereas Payment Initiation Service Providers (PISPs) and Account Information Services Providers (AISPs) must ensure that SCA is properly applied, they have the right to rely on the authentication procedure provided by the ASPSPs.

Under the SCA procedure, a valid combination of the authentication elements will generate an authentication code to the payer’s PSP, specific to the amount and payee agreed by the payer when initiating the transaction. This is also known as “dynamic linking”.

Importantly, the RTS requires PSPs to ensure the independence of all the elements used in the SCAprocedure and the channel, device or mobile app through which the authentication code is generated and received to be “independent or segregated” from the channel, device or mobile app used for initiating the electronic payment transaction.

This will pose challenges both technically and commercially. Technically, PSPs will need to ensure two different applications/channels are used to separately initiate payments and generate authentication elements (for example by requiring users to install the relevant bank “app” on their phone or carry a token generating key). Commercially the challenge will be to do so with as little inconvenience to the user as possible, as cheaply as possible, but better than competitors.

In addition, the draft RTS requires ASPSPs to “prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation”, meaning that banks will need to perform fraud screening on all electronic payment transactions prior to final authorisation. If confirmed in the final RTS, this will be a major change for the industry which will require extensive investment and will prove difficult to implement within the current PSD2 implementation timescales.

Finally, one of the few exemptions from SCA requirements will actually increase the authentication requirements. SCA will not be required for individual contactless card transactions of up €50 , or where the cumulative amount of the transactions without SCA does not exceed €150. Although technically an “exemption”, in reality banks will be required to introduce much stricter and cumbersome authentication processes than the ones currently in place and, since users will need to be “verified” every €150, the user-friendliness, and therefore possibly the use, of contactless payments could be reduced.

Overall, our view of the new security and authentication requirements is that the EBA is erring on the side of security and consumer protection, at the expense of innovation and user-experience, in contrast to the general direction of travel of both the industry’s and customers’ expectations.

Common and secure open standards of communications

Under PSD2, TPPs will be able to connect, with customers’ consent, directly to the customer’s bank details and use the banks’ infrastructure to facilitate payment initiation or account information services. “Access to Account” (XS2A), as it is known, is one of the most significant changes, both strategically and operationally.

To enable XS2A, the RTS requires banks to offer at least one interface to TPPs to allow communication exchanges to take place. Whenever possible, interfaces should use ISO 20022 elements. Beyond this however the EBA does not prescribe any other specific industry standard or Application Programming Interfaces (APIs).

The interface must have the same functionality, availability and level of support as the online platform provided to Payment Service Users (PSU), but banks can decide whether the interface they offer to TPPs is dedicated or not. Banks could decide, for example, to give TPPs access to the same online portal as their customers, without incurring the cost of creating and maintaining a new interface.

The EBA, conscious that regulation cannot move nearly as fast as innovation, has steered clear of overly prescriptive requirements, which may quickly become obsolete, and opted for a more outcome-based approach.

But the absence of more detailed requirements is not necessarily positive for the banking industry, nor start-ups. The short implementation timeframes, combined with the large number of existing and new industry participants and the lack of industry standards for communication interfaces, could lead to fragmentation and a lack of interoperability between TPPs and banks, to the detriment of all stakeholders, including the consumer.

Banks will quickly need to decide how to strategically position themselves in the new payment landscape. If a bank chooses to act as a TPP and offer similar services to “FinTechs”, or act as a utility provider to TPPs, an industry communication standard would significantly help reduce inefficiencies and maintenance costs, while maximising opportunities. We will see a strong push from banks, and FinTechs, to develop industry standards to address some of these concerns. In the UK, the Open Banking Standard initiative will lead the way, and generally, those banks which have already adopted ISO 20022 will be at an advantage.

From a compliance and operational perspective, XS2A design and implementation will require banks to make a significant investment in IT, as well as in a new and enhanced risk control framework to manage enhanced third party risk, fit to identify and mitigate the risks introduced by new TPP provided channels, which will be of particular interest to fraudsters.

Next steps

The consultation on the draft RTS closed on 12 October 2016. The final standard, which the EBA aims to publish by January 2017, will be applicable 18 months after the adoption by the EU Commission, at the earliest October 2018. This is a short timeframe considering the strategic choices and implementation challenges involved, so banks should ensure their PSD2 programmes will enable them to effectively respond as soon as possible.

Authors: Stephen Ley, Partner Risk Advisory at Deloitte LLP, Steven Bailey, Director Risk Advisory at Deloitte LLP, and Valeria Gallo, Manager EMEA Centre for Regulatory Strategy at Deloitte LLP. 

Did you find this useful?