Understanding PSD3: A comprehensive overview of strong customer authentication and payment fraud prevention

Frederik Mennes,

In a move to address the evolving landscape of payment services and payment security, the Directorate-General for Financial Services (DG FISMA) of the European Commission recently unveiled its draft proposal for PSD3, the long-awaited successor of the revised Payment Services Directive (PSD2). In this article, we present and discuss the European Commission's proposals in PSD3 that relate to strong customer authentication (SCA) and payment security, while explicitly focusing on Internet banking.

Adapting to emerging payment fraud challenges

PSD3's emergence is driven by several factors highlighting the need for regulatory updates. While PSD2 successfully curbed account takeover (ATO) fraud through SCA, new threats like authorized push payment (APP) fraud have surfaced. This type of payment fraud exploits users' trust and consent to initiate and authorize payments, posing a significant challenge.

Additionally, open banking adoption has faced hurdles due to data access limitations for account information service providers (AISPs) and payment initiation service providers (PISPs). Unequal opportunities for payment service providers (PSPs), along with the persistence of largely national payment systems despite cross-border service provision, further highlight the necessity for PSD3's revisions.

The legislative framework of PSD3

The proposed PSD3 comprises two legislative acts: a Directive and a Regulation. The Directive (called Payment Services Directive 3) concentrates on licensing and supervising payment and electronic money institutions; it replaces the Electronic Money Directive. The Regulation (called Payment Services Regulation) defines rules for PSPs offering payment and electronic money services. Notably, the Payment Services Regulation applies directly in all Member States, preventing national discrepancies arising from transposition into domestic legislation.

In addition, article 89 of the Regulation requests the European Banking Authority (EBA) to develop Regulatory Technical Standards (RTS) that would likely replace existing PSD2 standards. These new RTS are expected to cover areas such as:

  • SCA and exemptions
  • Transaction risk monitoring
  • Security measures for personalized security credentials
  • European digital identity wallets

Evolution of strong customer authentication

Articles 85-89 of the Payment Services Regulation (PSR) detail requirements concerning strong customer authentication, a central focus of PSD3 – with several changes proposed, such as:

  1. Definition of SCA: The basic definition of SCA, based on knowledge, possession, or inherence factors, remains consistent with PSD2. However, under Article 85, authentication elements do not have to belong to different categories (i.e., possession, knowledge, or inherence) anymore as long as these elements are independent.
  2. SCA by AISPs: PSD2's requirement to perform SCA at least every 90 days in case of access via an account information service provider (AISP) generated a lot of usability concerns from AISPs, and is addressed in Articles 85 and 86 of the PSR. These articles reduce friction for AISPs and their users by allowing AISPs to perform SCA themselves instead of relying on SCA by account servicing payment service providers (i.e., ASPSPs or banks).

  3. Diversity of SCA mechanisms: PSPs are required to ensure SCA accessibility for all users, including those with disabilities or limited digital skills. Furthermore, article 88 prohibits PSPs from adopting a mobile-only approach to SCA. Overall, this means PSPs may use mobile authentication mechanisms, but they need to foresee other SCA mechanisms (e.g., hardware tokens) as well.

  4. Outsourcing SCA: PSPs are encouraged to collaborate with technical service providers for SCA as long as they comply with EBA guidelines on outsourcing and the forthcoming Digital Operational Resilience Act.

Addressing payment fraud challenges

Addressing payment fraud is a crucial aspect of safeguarding the financial ecosystem and protecting consumers from malicious activities. The Payment Services Regulation (PSR) proposal introduces a comprehensive set of anti-fraud measures to tackle the growing challenges of payment fraud, reflecting the ever-evolving nature of fraudulent tactics employed by criminals. The PSR proposal responds to evolving payment fraud challenges by introducing additional anti-fraud measures, such as:

  1. IBAN/Name Matching Verification Service: Article 50 of the Payment Services Regulation (PSR) mandates payment service providers (PSPs) to provide a service that enables payers to verify whether the names and IBANs of payees match. The purpose of this service is to combat social engineering-based fraud, which occurs when payers are deceived into transferring money to an IBAN that belongs to a fraudster. A similar service called "Confirmation of Payee" exists in countries like The Netherlands and the United Kingdom.

  2. Transaction monitoring: Article 83 necessitates transaction monitoring mechanisms to support SCA implementation and fraud prevention. These requirements were already present in the RTS on SCA under PSD2, but are now directly included in the PSR, underscoring their importance.

  3. Fraud data sharing: PSPs are required to share fraud-related information collectively, enhancing transaction monitoring effectiveness.

  4. User education: Article 84 obligates PSPs to educate customers about payment fraud, such as identifying and preventing fraudulent activities. This is not new, but PSPs should now focus their efforts specifically on the growing Authorized Push Payment (APP) fraud.

  5. Liability for fraud: Article 59 discusses liability for fraud whereby the victim is manipulated by a fraudster who pretends to be an employee of the victim's PSP and unlawfully uses the PSP's name, email address, or phone number. In such a scenario, the victim's PSP has to refund the victim the full amount of the fraudulent authorized payment transaction under the condition that the victim has, without any delay, reported the fraud to the police and notified their payment service provider.

PSD3 legislation timelines and next steps

The next step in the legislative process consists of a review of the Commission's proposal by the European Parliament and Council. It currently needs to be made clear whether Parliament will review the proposal before the elections in May 2024, or whether it will defer the review to the following term after elections.

The PSR enters into force on the twentieth day after publication in the Official Journal of the European Union and enters into application 18 months after. If the final proposal of the PSR would be published by the end of 2023, the PSR would enter into application in the second half of 2025. The development of the RTS happens typically during the 18 months after the entry into force of the PSR and/or PSD3.

Preparing for PSD3

As the legislative process unfolds, payment service providers need to strategize and adapt. Start by focusing on the following:

  1. Impact assessment: Identify affected functions and assess the implications of PSD3 on each, considering customer channels, security, fraud prevention, and legal departments.

  2. Strategic incorporation: Integrate PSD3's impacts into your organization's strategic planning, recognizing the significance of the proposed changes.

  3. Compliance implementation: Roll out necessary process changes and developments to ensure timely compliance with PSD3.

credit card authentication via fingerprint
Webcast

How can banks and PSPs start preparing now for PSD3?

Get an update from PSD3 Expert, Frederik Mennes, about PSD3’s scope & expected timelines, the legislative structure, and what banks and PSPs should do now to prepare.

Watch now

Frederik leads OneSpan's Security Competence Center, where he is responsible for the security aspects of OneSpan's products and infrastructure. He has an in-depth knowledge of authentication, identity management, regulatory and security technologies for cloud and mobile applications.