UK: PSD2 Standard On Secure Communication: A Balancing Act

Earlier this week, the European Commission published the final Regulatory Technical Standard (RTS) on Strong Customer Authentication and Common Secure Communication under the revised Payment Services Directive (PSD2). In this final version, the Commission confirmed that screen scraping¹ will no longer be allowed once the RTS comes into effect, heeding concerns expressed by the European Banking Authority (EBA) and other stakeholders around security. However, Account Servicing Payment Service Providers (ASPSPs) will still be required to put in place contingency measures in case of unavailability or under performance of their dedicated interfaces during a communication session with Third Party Providers (TPPs).

New contingency measures

Under the updated rules, ASPSPs will be required to make the technical specifications of all their communication interfaces, whether dedicated or not, publicly available, and offer, at least six months prior to the application date of the RTS, a facility enabling Payment Service Providers to test the interfaces and ensure their proper functioning. In the case of dedicated interfaces, ASPSPs will also have to define transparent key performance indicators and service level targets, which will have to be at least as stringent as those set for the online payment and banking platforms used by the ASPSPs' customers. National Competent Authorities (NCAs) will stress-test and monitor the performance of dedicated interfaces.

In addition to the above, ASPSPs will also be required to put in place a so-called fallback mechanism, which TPPs can rely on if dedicated interfaces are unavailable for more than 30 seconds, or if they did not meet the general operational requirements set out in the RTS.

As in the earlier draft of the RTS, such a fallback mechanism will consist of opening up the ASPSPs user-facing interface as a secure communication channel for payment initiation and account information services. However, and importantly, the Commission has now specified that, when using the fallback option, TPPs should ensure that they can be identified by the ASPSPs; take the necessary measures to ensure they only access, store or process data the consumer has consented to; log the data they access and make it available to the relevant NCA if requested; and justify to the NCA, upon request, the use of the interface.

NCAs, in consultation with the EBA, will be able to exempt individual ASPSPs from putting in place such fallback mechanism, provided their dedicated communication interfaces fulfil the quality criteria defined by the technical standards. The EBA will be responsible for ensuring the assessment of the quality of dedicated interfaces is consistent across Member States. Exemptions will be revoked by the NCAs if a dedicated communication interface no longer meets the quality criteria for more than two consecutive calendar weeks. In this case, the fallback mechanism will have to be put in place by the ASPSP in the shortest timeframe possible, and in no more than two months.

Balancing security and competition

The Commission had initially rejected the EBA's proposal, earlier in February, to prohibit the use of screen scraping. Its concern, shared by the FinTech sector, was that such a ban would leave TPPs at a disadvantage in cases where a dedicated interface failed, because while a bank would be able to offer its own payment services through its customer-facing interfaces, TPPs would not be able to do so until the functionality of the dedicated interface was restored.

On the other hand, allowing the unrestricted use of screen scraping as a contingency measure would introduce a material security risk for ASPSPs and customers. This is because TPPs would be able to access any information available to customers on their online banking platforms, as if they had they logged in, making it very difficoult or impossible, for ASPSPs to identify TPPs and limit access only to data allowable in line with a customer's consent.

Therefore, the Commission had the unenviable task of developing a standard that could reconcile the need to ensure a level playing field between TPPs and ASPSPs, with that of protecting consumers and keep payments services secure. The final RTS tries to do so by introducing, in essence, a more restrained version of screen scraping as a fallback mechanism – one where the onus is put on the TPPs to be able to prove to NCAs that they are acting in line with PSD2 rules, and the consent obtained from customers.

Theory vs. practice

In principle this compromise does achieve a better balance between security and competition, but in practice, the new contingency measures may prove somewhat impractical to implement for both firms and NCAs. They could also have unintended consequences.

Increased cost, complexity and fragmentation

As the EBA observed previously, introducing a fallback mechanism is likely to increase costs for both ASPSPs and TPPs, as they will need to design and maintain multiple connectivity solutions. In particular TPPs will need to build and maintain different connectivity solutions for every ASPSP they wish to connect to, for both dedicated and user-facing interfaces. And although TPPs will be responsible for identifying themselves, ASPSPs will still need to upgrade their user-facing interfaces to make this possible. Since ASPSPs cannot be sure they will be granted an exemption by their NCAs, or be sure it will not be revoked at short notice, they may need to put in place the fallback mechanism as a preventative measure.

This could disincentivise some ASPSPs from developing dedicated interfaces altogether, which in turn could slow down the development of standardised application programming interfaces, and reduce interoperability and competition in the market. This risk may be further increased by the requirement to publish technical specifications and provide a testing facilities for PSPs at least six months before the application date of the RTS. This effectively reduces the time ASPSPs have to develop their secure communication solutions by a third.

Finally, supervising and enforcing these contingency measures including stress-testing, exemptions management, and monitoring performance of dedicated interfaces, will also pose significant operational challenges for NCAs and the EBA, putting further strain on their already constrained resources.

Next steps

The RTS will become applicable 18 months after its publication in the Official Journal of the European Union. Subject to the agreement of the European Council and Parliament, which have three months to scrutinise the final text, the RTS is currently expected to become applicable around September 2019.

Footnotes

1 The action of using a computer program to copy data from a website, without having to identify oneself.  

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.