PSD2 finalised standard on SCA and CSC: the wait is over, but questions remain - Banking blog

SFCR image 1

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.

Time for firms to get ready

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. 

Do Swiss firms need to prepare?

In our EMEA wide PSD2 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, European firms should push ahead at full speed, not only in relation to their communications interfaces, but also in relation to their SCA solutions. 

However, from a Swiss perspective, there is currently limited pressure on firms to push ahead with the implementation as for now Swiss firms are not required to comply with PSD2 except for their subsidiaries in the EU, which offer payment services. Hence, Swiss banks have the freedom to decide whether and how to make their API’s accessible to third parties.

We believe it is prudent to closely assess the aforementioned announcements by the EBA and especially monitor the outcome of the work of the API EG as it is expected that the pressure, in particular from clients, is likely to increase as soon as the service is available in the neighbouring EU states. Monitoring the implementation will not only provide clarity around the open question regarding the development and testing of access interfaces for TTPs, it will also provide Swiss banks with the opportunity to prepare ahead of a future Open Banking Ecosystem. 

As those banks with subsidiaries offering payment services in the EU are forced to comply with RTS already by 14 September 2019, they will be required to closely monitor how the standards of communication are defined and implemented in the EU. Also, these banks might find it more efficient to implement the changes across their entire bank to make use of the necessary investments towards a future Open Banking Ecosystem. Depending on the dynamic of this development in the Swiss marketplace, it is likely that the pressure on other Swiss player will increase sooner than currently expected. 

This blog was first written by the Deloitte EMA Centre for regulatory strategy. To read more about the open banking topic, please click here.

 

Andreas Timpert

Andreas Timpert - Partner, Financial Services, Zurich

Andreas is a Financial Services partner with more than 20 years of Consulting experience focusing on defining and implementing Operating models in front-, middle- or back-office functions. Typical drivers for change include regulatory changes, cost optimization or technology-driven transformations.

Andreas also leads Deloitte’s Rethinking Compliance initiative and is the co-author of the Deloitte point of view “Compliance 2025: DNA evolution in the Financial Services Industry”.

Email 

Ch-blog-andreas-lentzsch

Andreas Lentzsch - Senior Manager, Zurich

Andreas is a Senior Manager in Deloitte’s Financial Services Operations Consulting practice, with over 8 years experience gained across Consultancy and the Private Banking industry.

He has a proven track-record of successfully managing complex projects leveraging a variety of methodologies and working with geographically dispersed teams. An assured communicator, Andreas is comfortable working and influencing at senior MD level and leading teams.

Email

Comments

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

Categories