PSD3 and Strong Customer Authentication: What you need to know

The impact assessment identifies four key problems in the payment market, despite the introduction of PSD2. The first problem is “consumers are at risk of fraud and lack confidence in payments”. The first specific objective of PSD3 is thus to “Strengthen user protection and confidence in payments”. 

To do this the commission suggests the following changes in their proposal for PSD3:

• Define a legal basis for the exchange of information on fraud between PSPs
• Require an obligation to educate customers about fraud
• Extend verification to all credit transfers
• Conditional reversal of liability for authorised push payment fraud
• Obligation on PSPs to improve the accessibility of SCA for users with disabilities, older people, and other people facing challenges regarding the use of SCA
• Improvements to user rights and information
• The number of strong customer authentications in a payment initiation journey should be the same even if more than one PSP is involved

A welcome change in the proposal is to clarify the liability of Payment Service Providers (PSPs) for unauthorized payment transactions. It clarifies that PSPs can only refuse refunds to the payer if they have reasonable grounds to suspect fraud. In such cases, PSPs must provide a justification for their refusal and guide the payer to seek further assistance. Additionally, it has been clarified that PSPs are held fully liable if they fail to notify the payer of discrepancies in the SCA process, ensuring accurate communication of payment details.

The proposal further addresses situations where consumers are manipulated by individuals posing as PSP employees. In article 59 PSPs are held responsible for any resulting financial damage, emphasizing their role in protecting customers from fraudulent activities. It also introduces an obligation for electronic communications service providers to cooperate with PSPs in preventing fraud, promoting information sharing and collaborative efforts.

Furthermore, there is a liability of the PSP of the payee, requiring them to refund the financial damage incurred by the PSP of the payer (Article 60). This provision ensures accountability throughout the payment process. It also updates provisions related to notification, rectification of unauthorized transactions, information requirements, and the right of recourse to reflect the new liability provision for incorrect application of the matching verification service.

In Article 58 the proposal introduces new liability provisions for technical service providers and operators of payment schemes who fail to support strong customer authentication. The goal here is to address problems identified during the implementation of SCA and to encourage stakeholders to fulfil their responsibilities, within the existing contracts. This is a topic that we’ll probably do a separate blog post on in the future. Finally, the proposal clarifies that neither the payer nor the payee bears any financial losses when an exemption from strong customer authentication is applied, maintaining security measures while acknowledging exemptions in specific cases.

The proposal for a new PSD3 has a whole chapter on operational and security risks in the authentication process. One of the new requirements for SCA in the proposal is a new provision in Article 83 requiring PSPs to implement transaction monitoring mechanisms to enable the application of SCA and enhance the prevention and detection of fraudulent transactions. These mechanisms must analyze payment transactions, considering typical elements of the user's behaviour, such as location, time, device, spending habits, and the online store used for the purchase. 

Other new provisions are added to allow PSPs to voluntarily exchange personal data, including unique identifiers of payees, for transaction monitoring purposes. These information-sharing arrangements must define participation details and operational elements, using dedicated IT platforms. As this type of information exchange can run afoul of privacy laws there is a requirement for PSPs to first conduct a data protection impact assessment and, if necessary, consult with the supervisory authority in accordance with the EU's General Data Protection Regulation.

Another welcome clarification is regarding the application of SCA in merchant-initiated payment transactions (MITs). Here it is clarified that strong customer authentication should be applied during the set-up of the mandate but is not required for subsequent MITs. For mail orders and telephone orders (MOTOs), only the initiation of the payment transaction needs to be non-digital to be exempt from SCA obligations. However, paper-based payment orders, mail orders, or telephone orders placed by the payer should still be subject to security standards and checks by the PSP to prevent abusive circumvention of strong authentication requirements. Additionally, the scope of SCA exemptions has been narrowed for payment transactions initiated by payees based on a payer's mandate, while an obligation to require SCA is introduced when a mandate is placed through a remote channel with the direct involvement of a payment service provider.

For account information services, SCA is only required for initial data access. However, account information service providers must enforce SCA when their customers access aggregated account data on the service provider's domain, at least every 180 days. This ensures that account information remains secure and protected while allowing a balance between security and user convenience.

While it is likely that everyone reading this post has at least one smartphone this is not the case for every customer of most banks. In some of our conversations with banks and other financial institutions, we’ve actually found that as much as 15% of their customers either don’t have a smartphone or don’t want to use it at all for banking. It is therefore not surprising that Article 88 of the proposal requires that every customer should have access to SCA. It is even spelt out in paragraph 2 that “Payment services providers shall not make the performance of strong customer authentication dependant on the exclusive use of a single means of authentication and shall not make the performance of strong customer authentication depend, explicitly or implicitly, on the possession of a smartphone.”

This will be a challenge for many PSPs, as today smartphones are the obvious way to implement SCA. An alternative that we in Okay have been working on is to use voice calls in combination with a second device as the SCA factor, so if this is something that you might be interested in please reach out to us.

EU’s process for adopting new law is quite long and complicated, going through multiple stages of proposals, readings and conciliation. Right now PSD3 is in the earlier stages, where stakeholders have been consulted, an impact assessment has been created, and an initial proposal has been created. According to Article 89, there are also new regulatory technical standards to be published, such as for transaction monitoring mechanisms. While there is still quite a bit of way to go before PSD3 becomes part of national law it is clear that the new SCA requirements will have an impact on payment services that are being designed today. 

The proposal is clearly headed in the right way, with clearer liabilities and responsibilities. But, personally, I would also like to see the PSD3 try to take more of the other regulatory efforts under its wings, such as the MiCA, DORA, and AML directives, all of which cover some of the same regulatory areas as PSD2. Maybe the Commission could even look at how the authentication required for PSD3 could be used for the Digital Identity Wallet initiative? 

Of course, the PSD2 is still very much in effect, which is why we’ve recently announced our consulting services offering. We’re here for you if you need help evaluating your PSD2 compliance, are worried about threats to your customer authentication, or need to improve your security.

If you’re interested in this type of topic please follow us on LinkedIn, as we’re sure to cover the PSD3 many more times over the coming months.