'Behavioural data' cannot be relied upon for authorising payments, says regulator

The regulator made the comments as it set out draft proposals on strong customer authentication (51-page / 452KB PDF) as part of its obligations under the new Payment Services Directive (PSD2).  PSD2 came into force earlier this year and will need to be implemented into national laws across the EU by 13 January 2018.

PSD2 generally requires PSPs to apply "strong customer authentication" where organisations or consumers try to access their payment accounts online, initiate an electronic payment transaction or "carries out any action through a remote channel which may imply a risk of payment fraud or other abuses".

Those provisions also apply to cases where payments are initiated through payment initiation service providers (PISPs) or where account holders request information about their accounts via an account information service provider (AISP).

PSD2 imposes data security obligations on PSPs to account for such third party interactions with the accounts they manage and PSPs must also ensure that PISPs and AISPs can rely on the strong customer authentication measures deployed by a PSP to deliver their services.

According to the Directive, strong customer authentication is a mechanism that requires payment account holders wishing to access their accounts or make a payment to provide information that allows their identity to be verified and which is built on two or more independent factors. Those elements are something the account holder knows, something they possess or something inherent in them.

In seeking to define the regulatory technical standards for strong customer authentication, the EBA said that "behavioural data cannot be considered as a standalone inherence element", but that it can be used as "an additional tool for fraud prevention".

According to the draft standards, to comply with the requirements for strong customer authentication PSPs will require to generate a one-time-only "authentication code" that those making payment will need to input to proceed with an electronic payment.

The standard proposed by the EBA is drafted in such as way as to be technologically neutral. However, the regulator said that the authentication code must contain "security features" that at least include "algorithm specifications, length, information entropy and expiration time". The security features must ensure authentication elements remain confidential, that new authentication codes cannot be generated "based on the knowledge of another authentication code generated for the same payer" and that the authentication code is forgery-proof, it said.

The new standards, if introduced as drafted, will require PSPs to place a maximum limit on the number of times customers can enter the wrong authentication details consecutively. Measures must also be taken to ensure customers seeking to make payments are provided with information about that transaction via a separate "channel, device or mobile application" from those used for initiating the payment.

"The authentication procedure should ensure the confidentiality, authenticity and integrity of the information displayed to the payer through all phases of the authentication procedure including generation, transmission and use of the authentication code," the EBA said.

"To that end, the channel, device or mobile application where the information about the amount and the payee of the transaction is displayed should be independent or segregated from the channel, device or mobile application used for initiating the payment. This can be done, for example, via an independent channel to prevent any manipulation of the transaction details through the initiation process of the payment transaction," it said.

The EBA said PSPs must carry out periodical testing, evaluation and auditing of the security of their authentication procedure.

"The conduct of such evaluation, which should rely on openly and publicly available state-of-the-art methods, must be organisationally independent from the units involved in the design, development and maintenance of the strong customer authentication procedure," the EBA said.

Among the transactions that the EBA has proposed be exempt from strong customer authentication requirements are contactless payments with a value of €50 or less and credit payments made by payers to their "trusted beneficiaries".

The EBA is consulting on its proposals until 12 October.

"It’s interesting to see neither APIs or screen scraping approaches mentioned by name in the EBA’s consultation but the options are explored – the EBA has stuck with an approach of technical neutrality but many banks are pushing for an API approach to be adopted to accept that third party providers can connect into their data and functions," technology and payments law expert Angus McFadyen of Pinsent Masons, the law firm behind Out-Law.com, said.

"There is a view that screen scraping presents security concerns that are not manageable. The UK’s open data initiative is driving towards an API approach – this may yet blaze the way for mass market account access (XS2A) in Europe and beyond. That said, the EBA seems open to allowing screen scraping and comments from regulators in the past have suggested that it is an increasingly acceptable means of operating, despite it being challenged in the early 2000s," he said.

"Banks and IT vendors need to jump on this consultation, doing everything that they can to shape the RTS to a workable model. Whilst there is a good base, the exemptions in particular require significant development to make strong authentication work well in a mobile environment," McFadyen said.

According to a recent report by PwC (23-page / 1.32MB PDF), more than two-thirds of European bankers "fear that PSD2 will cause them to lose control of the client interface". The report said that many banks are "unsure how to respond to the new directive" and are "adopting a defensive, wait-and-see stance that is risk averse".