Strong Customer Authentication & Compliance Under PSD2

In the physical world, it’s relatively straightforward for banks, credit card issuers, and other institutions to verify a customer’s identity with a valid ID before they can access their accounts. But, when it comes to securing online accounts and payment services, it isn’t as cut and dry. 

Single-factor authentication methods, like password-based security, no longer suffice in the modern landscape. It’s now the standard to use multiple authentication factors to ensure customers are who they claim to be. 

Global regulators have taken notice of the rising threats to online account security and passed legislation to standardize and strengthen authentication requirements in the financial sector. This includes the introduction of strong customer authentication (SCA) requirements, which are now enforced throughout the EU and the UK.

Below, we’ll cover strong customer authentication, the SCA requirements set out in PSD2, and what to expect from new legislation PSD3 and PSR1. 

Strong customer authentication (SCA) is a security requirement introduced by the Revised Payment Services Directive (PSD2) to reduce the risk of fraud in online payments. 

To comply with SCA, financial institutions and payment services providers in the EU and UK must authenticate customers with two of the following three factors: 

• Something the customer knows (password or PIN)

• Something the customer has (device, token, or badge)

• Something the customer inherently is (biometric factor)

   

So, when European customers want to access their financial account, shop, or send a payment online, they must successfully complete a multi-factor authentication (MFA) challenge to verify they are the rightful account holder.

Strong customer authentication helps payment service providers and financial institutions meet PSD2 compliance and enhance the security of online payments, reducing the risk that consumers fall victim to fraudulent transactions. This can lead to lower fraud-related costs both for consumers and financial institutions. 

SCA supports greater consumer trust in financial services, with the understanding that providers have implemented the appropriate security measures to prevent unauthorized access or use of their accounts and financial data. 

At the same time, implementing multi-factor authentication can add friction to the customer experience, especially during online checkout. Plus, the various exemptions allowed for SCA can be complex, requiring organizations to implement robust systems to handle these sophisticated decisions in real-time.

SCA requirements are mandatory for account servicing payment service providers (ASPSPs). This includes banks and any monetary financial institution that offers financial accounts or third-party providers (TPPs) involved in the processing or initiation of electronic payments. 

Situations Where SCA is Mandatory

SCA applies when a customer initiates an online or offline contactless payment over €30 in the European Economic Area (EEA). There are certain exemptions and transactions that are considered out of scope for SCA, as we’ll discuss in further detail below. 

In general, SCA applies to any of the following scenarios: 

• Online payments: Purchases made online, like on an e-commerce website or when sending an electronic payment 

• Contactless transactions: In-person purchases above a certain threshold when using a contactless payment method 

• Accessing accounts: When a customer accesses their online banking or payment service account

   

Regulatory Requirements and Guidelines

SCA was introduced as a mandatory requirement in PSD2, a critical EU financial regulation, which outlines the specific guidelines for its implementation. Additional requirements and clarifications for SCA are expected with Payment Service Directive 3 (PSD3) and Payment Services Regulation 1 (PSR1), which were proposed by regulators in June 2023. 

The European Banking Authority (EBA) is the primary supervisory authority of SCA, ensuring compliance with its requirements and providing further clarifications to help payment service providers with its implementation. 

Authentication using a simple username-password combination does not comply with SCA requirements. Instead, providers can use a combination of any two types of authentication factors to strengthen account and payment security. 

Here are some of the methods providers use in combination with one another to authenticate customers in compliance with SCA requirements: 

SMS OTPs

A one-time password (OTP) sent via SMS is a way to implement authentication via something the customer “has”, such as the mobile device where the passcode is sent. 

During authentication, customers can request to have an OTP sent to their registered device. Upon receiving the OTP by SMS, they will enter it into the prompt, and be successfully authenticated if it matches. 

The OTP is a randomly generated sequence of characters that is only valid for the current session or transaction. Thus, it can only be used “one time”, reducing the risk that a compromised credential that’s used repetitively, like a password, will create a security breach. 

However, SMS OTPs are susceptible to man-in-the-middle attacks, where a fraudster intercepts the sent code from the network before it ever reaches the customer. The fraudster can use the OTP to access the customer’s account without their knowledge or initiate a fraudulent payment. 

Fingerprint Recognition

Biometric authentication, like fingerprint recognition, is an example of something a customer “is”, which can be used as one of the factors for SCA. 

If a customer is prompted with a fingerprint authentication challenge, they can place their finger on the appropriate scanner. If the fingerprint that’s detected matches the one that’s stored, they will be authenticated and able to initiate the transaction. 

Fingerprint recognition is a highly convenient authentication method for customers, as it doesn’t require them to remember anything or possess a certain device or item to verify their identity. 

However, it’s not always feasible to implement, like when a customer purchases something from an e-commerce site using a laptop without a fingerprint scanner. 

Facial Recognition

Similarly, facial recognition is another biometric authentication method used in SCA. Rather than the customer scanning their fingerprint, they can use the camera on their device to scan their facial features.  

For successful authentication, the facial scan provided during the authentication process should match what’s stored in the database. 

This method offers high levels of security, as it’s nearly impossible for fraudsters to create a facial scan spoof or replica with the proper depth and nuanced details to bypass authentication. However, customers may not be as willing to have their facial data stored by each of the platforms that use this technology.

Strong Customer Authentication was introduced as part of the Revised Payment Services Directive (PSD2), which European regulators passed in November 2015. However, full enforcement of SCA did not begin until December 31, 2020. 

PSD2 came into force in January 2018, with initial enforcement of SCA set for September 2019. However, the SCA deadline was met with growing concerns that merchants were not adequately prepared for the changes, which could negatively impact commerce across the EU.

As a result, several extensions were granted so impacted businesses could have enough time to update their systems and comply with the requirements. Eventually, the final deadline was set for the end of 2020. 

In June 2023, the European Commission proposed a subsequent update to the regulation with the Payment Services Directive 3 (PSD3) along with a proposal for Payment Services Regulation 1 (PSR1). 

Among other changes, PSD3 aims to make it even easier for payment service providers to comply with SCA by clarifying exemption criteria. It also hopes to make SCA methods more inclusive and not reliant on just one device or mechanism. The goal of PSR1 is to create a more unified regulatory framework for payment services in the EU. PSD3 and PSR1 have yet to go into force, pending the official passing of this legislation.

Establishing a multi-factor authentication requirement for certain transactions wasn’t the only provision of PSD2. However, SCA remains one of the most transformative aspects of this regulation. 

Specifically, PSD2 mandated the EBA to create “regulatory technical standards (RTS) for strong customer authentication (SCA) and common and secure open standards of communication”. 

For reference, here are the regulatory technical standards that are specified in PSD2:

• Requirements for strong customer authentication

• Situations that are low risk enough to be exempt from requiring SCA

• Security measures that help protect the confidentiality and integrity of personalized security credentials

• Requirements for common and secure open standards of communication (CSC) between ASPSPs, TPPs, payers and payees

We’ll now provide an overview of the step-by-step process showing how strong customer authentication works in real-time. 

While the specific requirements dictating when SCA should be implemented are unique, the authentication and identity verification steps closely mirror that of any standard MFA process. 

1. A customer attempts to access their financial account, initiate a payment online, or complete a transaction in person using a contactless method.
   

2. The customer enters one authentication factor to begin the verification process. This might be a username and a PIN or password.
   

3. The provider detects that SCA is required for the requested action and initiates a second authentication challenge for the customer to complete.
   

4. The customer receives the second authentication challenge, which may be an OTP, facial recognition, or fingerprint scan request.
   

5. The customer returns the appropriate second factor for authentication, whether it’s the OTP sent to their device or a facial or fingerprint scan.
   

6. If the customer has verified their identity by satisfying both authentication challenges, the PSP or bank can allow the customer to complete their request. 

Good SCA provides the appropriate levels of assurance that a provider needs to satisfy in high-risk scenarios. However, it should also allow consumers to choose which step-up modalities work best for them. More provisions on SCA accessibility will be mandated by PSD3 and PSR1.  

Dynamic Linking Requirement

The EBA added a dynamic linking requirement to PSD2 to prevent “man-in-the-middle” attacks. These are when bad actors try to hijack an authentication code to authorize fraudulent payments or access. The “dynamic linking” aspect means that the authentication code should dynamically fail if a middleman tries to use it for the wrong payee or amount. 

The SCA dynamic linking requirement includes the following:

• The payer must be made aware of the payment amount and payee

• Authentication code must be specific to the amount and payee agreed to by the payer when initiating the transaction

• Banks (or other ASPSPs) must only accept authentication codes that match the original information

• Any change to the amount or payee should make the authentication code invalid

• ASPSPs must maintain the integrity, confidentiality, and authenticity of the transaction information and what is displayed to the payer throughout all phases of the authentication

Certain exemptions apply to SCA. Here are some scenarios where payment service providers don’t have to ask customers to perform strong customer authentication: 

• Low-value transactions: Customers can initiate payments below €30 without performing SCA. Exceptions apply when there have been five payments since the last SCA or the cumulative total since the last SCA is over €100.

• Recurring payments: Subsequent payments for the same payee and amount don’t require SCA unless it’s the payer’s first time setting up the transaction. 

• Trusted beneficiaries: ASPSPs can allow customers to set up a “whitelist” of beneficiaries that don’t require SCA for payments unless it’s the first time the payer adds the payee to the whitelist. 

   

As illustrated above, PSPs can determine that a transaction is exempt from SCA based on transaction values or with a risk-based analysis. 

Risk scoring can be used to determine whether a payment is a low enough risk to not require SCA, such as if it’s being sent to a whitelisted payee.  

However, SCA is necessary if transaction risk analysis detects an abnormal spending or behavior pattern, unusual device information, malware infection, known fraud scenarios, or abnormal or high-risk payee location.

Aside from the abovementioned exemptions to SCA, certain transactions may occur out of the scope of SCA requirements. This includes: 

• Anonymous transactions: When customers use payment forms that aren’t connected to their identity, like a prepaid gift card or voucher, SCA may not be required. 

• Merchant-initiated transactions: Online payments that the merchant initiates instead of the customer, including recurring subscription fees or service charges that the customer has previously authorized.

To comply with the SCA requirements of PSD2, financial institutions and payment service providers can follow these tips for effective implementation and management: 

Adhere to Monitoring and Reviewing Requirements

Banks (and other ASPSPs) must conduct independent audits and reviews of SCA procedures, SCA exemptions, and the confidentiality and integrity of users’ credentials and APIs at least every three years.

They must have mechanisms in place for detecting potential fraud, including monitoring:

• Lists of compromised or stolen devices

• Payment amounts

• Known payment fraud scenarios

• Signs of malware at any stage of the authentication

• Usage logs of access devices or software

ASPSPs must analyze transaction risk and calculate overall fraud rates and risk scores for each transaction type.

They are also expected to monitor and adequately document the following information about all payment transactions:

• Total fraud amount and rate

• Average transaction value

• Total number of payments

Utilize Modern Multi-Factor Authentication Mechanisms

On the surface, multi-factor authentication is the most obvious technology you’ll need to meet the SCA requirements. 

Many financial institutions already have an MFA solution in place to secure online and mobile banking access, often with a one-time passcode through SMS or email. But first-generation solutions that rely on SMS or email aren’t designed for financial-grade security. 

While any MFA is better than nothing, bad actors have caught up to older MFA technology, which means one-time passcodes can be intercepted over email and text. Instead, modern multi-factor authentication, like PingID, is secure because it doesn’t rely on hard tokens or require servers to be on-premises, and it can look and feel like it’s part of your existing mobile app or branding.

Implement a Standards-Based Authentication Authority Architecture

SCA is much broader than just MFA. It’s about creating a sole digital authentication platform for all customer journeys. 

To accomplish that, you need a powerful, flexible standards-based authentication authority architecture that can enforce MFA only when required and support a broad variety of context and authentication factors. And more than just technology is needed. Becoming SCA compliant will involve reworking processes and change management for employees, third parties, and customers.

SCA requirements and best practices will continue to evolve as new regulations are introduced and authentication mechanisms advance with the help of emerging technologies. Here are some of the trends in SCA on our radar: 

Emerging Technologies and Practices in SCA

Ongoing advancements in authentication technology will impact how PSPs and banks implement SCA. 

For instance, continuous authentication methods can monitor customer behaviors on an ongoing basis, constantly assessing the perceived risk of their behaviors and requests and prompting additional authentication challenges as appropriate. 

In addition, the popularity of passwordless authentication solutions will continue to take hold across all industries and lessen the reliance on problematic passwords. Passwordless authentication supports SCA objectives like enhancing online security while offering a more convenient user experience. 

Predictions for the Future Landscape of SCA and PSD2/PSD3/PSR1 Compliance

As we have mentioned throughout, proposed updates to current regulations with PSD3 and PSR1 will provide further guidance on SCA requirements and exemptions. 

While the specifics of this legislation are not yet final, PSPs and banks can expect a focus on SCA accessibility to accommodate more customers and an extension of its scope to more scenarios that require SCA. Overall, we expect a greater emphasis on enhancing the user experience and enabling more frictionless authentication.

Strong customer authentication (SCA) is becoming the standard across financial services in every geography. Even where it isn’t officially mandated, innovators are proactively adopting SCA to deliver the right balance of security and convenience for customers.

As we await future evolutions in SCA requirements with PSD3/PSR1, many of the world’s largest financial institutions turn to Ping Identity for our expertise in identity and access management technology and our leadership in open standards and the global open banking movement.

The Ping Identity Platform is a modern IAM (identity and access management) platform. It provides a broad spectrum of PSD2 and open banking capabilities to handle a variety of SCA use cases, including support for the most common API vulnerabilities as defined by OWASP.

Learn more about financial service solutions.