PSD2: How the Final RTS Requirements Will Impact You - Update

On November 27, 2017, the European Commission published its final Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) under PSD2. With the release of the final PSD2 RTS requirements, banks of all sizes can now take action to develop a compliance strategy and implement effective security solutions for electronic remote payment transactions.

The Revised Payment Services Directive, known as PSD2, harmonizes security requirements for online banking and online payments, providing a common regulatory framework for the EU. The security requirements in the final RTS are driven by two core objectives of PSD2: protect consumers from fraud by increasing payments security, and enhance competition and innovation in the retail payments market.

On December 5, Frederik Mennes, PSD2 expert and Sr. Manager, Market & Security Strategy at VASCO presented a webinar entitled: PSD2: Are you ready for the long-awaited final RTS?

Article 97 of PSD2 requires Payment Service Providers to authenticate a user when they access an online payment account, initiate an electronic payment transaction, or carry out any action through a remote channel that may imply a risk of payment fraud. Watch our webinar to learn which categories of authentication solutions meet these requirements.

He covers four key topics in this webinar, now available on demand:

Final RTS key requirements for Strong Customer Authentication, including a detailed discussion of changes to:

  • Common and Secure Communications. Banks offering dedicated interface to TPPs (e.g. third –party providers) do not need to provide a fallback interface to TPPs if the dedicated interface meets certain performance and availability criteria;
  • Strong Customer Authentication (SCA). Payments by corporate users may be exempted from SCA requirements by the National Competent Authority (NCA); and
  • Audits. Audits of security measures of Payment Service Providers (PSPs) must be carried out by an auditor with expertise in IT Security and payments, and that is operationally independent within or from the PSP.

Authentication solutions that meet these requirements, including the following categories of devices:

  • Two-device authentication. The possession element is the authentication or banking device, consistent with a hardware token that scans a QR code and provides a trustworthy display or a mobile device (e.g. phone, tablet) that runs a mobile banking app;
  • Two-app authentication and one-app authentication. The possession element is the mobile device, which stores cryptographic keys to generate authentication codes with secure channel and security software to detect overlays; and
  • Out-of-band. The possession element is the mobile phone where the user receives authentication codes. The knowledge of inherence element is entered onto the banking device (for two-device authentication) or mobile device (for two-app or one-app authentication).

How to create a trusted mobile device to comply with mobile security requirements, including an examination of how to protect mobile applications from cloning, and how to create a secure execution environment for apps using Application Shielding or RASP technology. Examples of mechanisms to protect an app against cloning are as follows:

  • Including device-specific data into the calculation of the authentication code;
  • Encrypting data used by the app using a cryptographic key stored inside the device’s Secure Element; and
  • Using a password or PIN to encrypt the data that is used by the app to generate an OTP

How to reduce fraud through risk analysis to prevent, detect and block fraudulent payments, including awareness that:

  • Transaction risk analysis is mandatory, even when strong customer authentication is used.
  • Transaction risk assessment mechanisms should be based on elements such as the amount of payment, known fraud scenarios, signs of malware infection in the payment session, etc.;
  • Transaction risk analysis can be used to exempt a subject from the need to perform SCA. However, this exemption is subject to a several corresponding conditions.

All banks operating in the EU, including retail and corporate entities, are subject to compliance. The RTS (including authentication requirements) will become applicable in August or September 2019.

Don’t Wait: Build Your Compliance Strategy for PSD2 Now

It’s important to recognize that the RTS are technology and business-model neutral. Because the RTS is a legal text and not technical or prescriptive, it can be interpreted in any number of ways by any number of institutions. With so much on the line legally and financially, the real question becomes how to build the most effective strategy for compliance.

If you are a line of business owner managing service and delivery channels in the bank, an IT leader responsible for implementing security in these channels, or an in-house legal expert, watch the webinar for expert insights on how to interpret the standards and comply with the final PSD2 RTS requirements.


PSD2: Are you ready for the long-awaited final RTS?


Our Blog Updates in your mailbox? Sign up!

Join thousands of professionals and get fresh insights on cyber security trends & advice and tips to help you make informed decisions

No sales pitches, no games, and one-click subscribe

2 Responses to PSD2: How Will the Final RTS Requirements Impact You? [Update]
  1. what do the 4 2da types mean? its hard to say based just on the pictures – how is the 2nd, 3rd and 4th compliant and what is the flow?

  2. Hello Shyam, you can find more details about the 2da types and their compliance with the PSD2 requirements in following whitepaper:

Leave a Comment