PSD3 and PSR Changes: Everything Banks Need to Know

A Look Back at PSD2 and SCA

Before we unpack PSD3 and PSR, let’s take a quick look back at PSD2. PSD2 (also referred to as the revised Payment Services Directive or second Payment Services Directive) was designed to foster greater competition by evening the playing field between banks and non-bank organizations. 

Strong Customer Authentication (SCA) was a key component of the overall regulatory package and aimed to reduce fraud.  

A retrospective review by the European Commission concluded that SCA broadly had a positive impact in reducing unauthorized fraud. However, one of the unintended consequences of SCA is that it’s allowed other fraud typologies to emerge, such as scams. In the European market, scams are better known as spoofing. 

Spoofing occurs when a scammer contacts a victim and convinces the victim to make an authorized transaction on their behalf. This presents a whole new set of challenges for banks in terms of protecting customers and better detecting fraudulent transactions. PSD3 attempts to address some of those challenges. 

5 Key Principles of PSD3

PDS3 includes five key principles:

IBAN-Name Checking

The first of these principles is IBAN-name checking. For those familiar with the UK’s Confirmation of Payee model, this proposal is very similar. It allows customers to validate that they’re paying whom they expect to pay through communication between the sending and receiving banks. In the event of a mismatch, a customer can be warned of that and potentially avoid a scam as it’s occurring. 

Enhanced Data-Sharing

The second principle is a legal basis and framework that allows banks to share data amongst themselves more effectively.

It’s become common in many parts of the world for banks to recognize the scale of the scam and spoofing challenge. They recognize that fraudsters talk to each other and share best practices. There’s now a realization that banks need to follow those principles if they want to stay ahead of the fraudsters. Being able to share known bad data, such as known mule accounts or known high-risk beneficiaries, will ultimately allow financial services organizations of all sizes to make better risk decisions as transactions occur. 

Enhanced Fraud Monitoring

The third principle is that banks will be asked to improve their performance from a fraud transaction monitoring perspective. Now it’s unclear what this requirement will mean until further details emerge. One possible outcome, however, could mean banks will be forced to move away from a rules-based approach to fraud detection and focus more on an automated machine learning-led way of detection. 

Customer and Staff Education

The fourth principle is around the education of both consumers and staff members. It’s recognized widely that customer education is a key pillar in any scam and spoofing prevention strategy. Banks are going to be forced to do more of that. We’re seeing banks move away from traditional education awareness, where customers must hunt for best practices and guidance. We’re seeing banks overtly put that into user journeys as transactions occur. This education, presented at the right time with the right message, if done correctly, can allow the banks to make the customers their first line of fraud defense and potentially thwart the customer from actually making that transaction before it even hits the bank’s fraud systems. 

Staff training is also a key part of PSD3. Banks must ensure that their staff members are knowledgeable on the latest scam trends and can remain credible and knowledgeable when a customer asks them for advice.

Enhanced Customer Refund Rights

The fifth and perhaps most important principle is that customers will have enhanced rights to refund if they fall victim to a spoofing scam. Currently, in the EU, no law mandates that customers must be reimbursed if they fall victim to spoofing. PSD3 looks to offer some enhanced consumer protection if certain spoofing types occur. 

That caveat of certain scam types is important because the proposal outlines that victims will only be reimbursed if they’re the victim of an impersonation scam. So that leaves questions about investment scams, romance scams, and all these other types of scams that we know are at large on the market.

The second caveat is that they may be entitled to a refund if there’s a failure in the aforementioned IBAN-name checking service. However, we will await further details to understand exactly what an error in that process means. 

Banks Face Increased Risk Exposure 

This is important for banks because their risk exposure will be significantly increased. Currently, they’re not providing those refunds. They’re going to have that liability going forward. That means they will have to find fraud budgets they haven’t previously had. As a result, we expect them to double down on their detection and technology efforts to offset some of the risk exposure we created by this new set of regulations. 

Enhanced Scam Protection Under PSR

Moving back to the PSR, there are some clear parallels to what I described in PSD3. The concept of the PSR is that it offers enhanced consumer protection if somebody falls victim to a scam. So in principle, that means more refunds more often. It also means a 50/50 liability split between the sending and receiving banks. This split motivates both sides of the transaction to do more regarding consumer protection in fraud detection. 

As we move towards that April deadline, finer details of the policy are starting to emerge. For example, we now know that the initial proposal of a £100 claim minimum limit has been removed and that anybody who is a scam victim, regardless of the loss amount, is in scope for a refund. 

We also know that faster payments will, in the short term, be the only payment types in scope for refund. This removes scams that occur via a cash loss or international transactions. The logic is that data analysis shows that 97% of scams currently occur via faster payment rails. Other payment types, such as CHAPS, will be considered in future policy iterations.