Twenty months after the European Banking Authority (EBA) issued the first draft, on 13 March the regulatory technical standard (RTS) on strong customer authentication (SCA) and Common Secure Communication (CSC) under revised Payment Services Directive (PSD2) was finally published in the Official Journal of the European Union.
The length of the process and the number of iterations required to finalise the standard evidence the complexity of developing rules to establish a level playing field between different market participants, while at the same time ensuring technological neutrality, consumer protection, and enhanced security in payments services.
The finalisation of the RTS is an important milestone which will give firms much more clarity and certainty on how to push forward their PSD2 compliance and strategic programmes. Nevertheless, the final RTS still leaves a number of important questions open, particularly in relation to the development and testing of access interfaces for Third Party Providers (TPPs).
Establishing common communications standards
The final text of the RTS, which remains the same as the version published by the EU Commission last November, will apply in its entirety from 14 September 2019. However, from 14 March 2019, Account Servicing Payment Service Providers (ASPSPs) will need to make the technical specifications of their access interfaces (whether dedicated or user-facing) available to TPPs, and also provide them with a testing facility to carry out trials of the software and applications TPPs will use to offer services to their users.
The RTS only specifies that ASPSPs will have to ensure that their interfaces follow standards of communication which are issued by international or European standardisation organisations. The Commission acknowledges that the lack of more detailed requirements is a challenge, but believes that it is the responsibility of market participants to work together to develop a solution that works for all sides.
To facilitate this, the Commission proposed the creation of an Application Programming Interface Evaluation Group (API EG) to evaluate standardised APIs specifications to help ensure that they are compliant with PSD2 and other relevant legislation, including the new General Data Protection Regulation (GDPR), and meet the needs of ASPSPs, TPPs and Payment Service Users (PSUs). The EU Commission, the EBA, and the European Central Bank (ECB) will be observers in the API EG, but will provide assistance to market players if and when required.
The recommendations and guidance issued by the API EG will seek to create harmonised market practices across EU Member States. Achieving this will not only reduce the implementation times and costs for both ASPSPs and TPPs, but will also be crucial to enable effective cross-border competition based on PSD2-enabled products and services.
Common communication standards may also support National Competent Authorities (NCAs) in determining whether to exempt individual ASPSPs, if they have chosen to develop a dedicated interface, from putting in place the fallback mechanism (i.e. opening up their user-facing interfaces as a secure communication channel), which TPPs can rely on if such dedicated interfaces do not meet the common market acceptance criteria, or are unavailable for more than 30 seconds.
This may help assuage, albeit only partially, some the concerns voiced by the EBA that the provisions in the final RTS - including stress-testing, exemptions management, and monitoring performance of dedicated interfaces - will impose significant, and excessive, additional administrative and operational burden both the EBA and NCAs.
The API EG commenced its work in January, with the objective of issuing final guidance and recommendation on APIs standards by June 2018, after which it will focus on defining high level principles and approach for a common testing framework of access interfaces.
In the UK, the Open Banking Implementation Entity will also continue its work, in preparation for the March and September 2019 PSD2 deadlines, to ensure the UK Open APIs standards remain compliant with the finalised RTS on SCA and CSC – in particular in relation to GDPR and the consent protocols – and their functionality is expanded to cover all PSD2 products.
Time for firms to get ready
In our survey last year, many firms noted that the absence of a finalised RTS was creating challenges in the definition of their broader compliance programmes. With the rules now finalised, including the short implementation timelines, firms should push ahead at full speed, not only in relation to their communications interfaces, but also in relation to their SCA solutions.
On the latter point, the main issue will be around implementing SCA requirements while maintaining a seamless and consistent user-experience – being able to do so will, in great part, be determined by a firm’s ability to take advantage of all available PSD2 SCA exemptions. In particular, to take advantage of the Transaction Risk Analysis exemption, ASPSPs will need to adopt advanced and effective payment fraud detection and reporting capabilities able to determine, in real-time, whether a particular transaction presents a low risk of fraud, and consistently maintain overall fraud below the predefined levels set by the RTS.
Last but not least, now that the RTS on SCA and CSC has been finalised, and efforts to create common communications standards are well underway, firms can expect competitive forces in the market to gather pace more quickly. In the UK at least, this view is corroborated by the increasing numbers of TPPs recently authorised by the Financial Conduct Authority, or currently undergoing the application process. In fact, some TPPs are already actively providing services to consumers in the UK market by leveraging banks’ Open Banking APIs. This means that, in order to avoid the risk of being left behind, firms should act now and finalise their strategic response in relation to PSD2 and Open Banking, including committing the necessary monetary and human resources to its implementation, without any further delay.