3D Secure and PSD2 SCA: A Guide for EU and UK PSPs (2026)

March 2026 | GPayments Insights | 13 min read

Overview

PSD2 Strong Customer Authentication (SCA) requires that remote electronic card payments in the EU and UK are authenticated using at least two independent factors: something the cardholder knows, has, or is. EMV 3DS2 is the primary technical mechanism for meeting this requirement on card-not-present transactions. When an issuer ACS presents a multi-factor challenge, the transaction meets the SCA standard. Frictionless flows are permitted under SCA exemptions defined in EBA Regulatory Technical Standards, including the transaction risk analysis (TRA) exemption.

Introduction

For payment service providers operating in the European Union and the United Kingdom, 3D Secure is not just a fraud tool, it is the primary mechanism for meeting a regulatory mandate. Understanding how EMV 3DS 2 maps to PSD2 SCA requirements, which exemptions apply, and what the upcoming PSD3 framework changes is now a core compliance capability.

This guide is written for compliance and risk professionals, payment architects, and technology teams at PSPs, issuing banks, and enterprise merchants operating under PSD2 and its UK equivalent. It covers the SCA requirement, how EMV 3DS 2 satisfies it, the exemption framework, and the approaching PSD3 transition.

What PSD2 Strong Customer Authentication Requires

The Payment Services Directive 2 (PSD2) was transposed into EU member state law with authentication requirements effective from September 2019, with enforcement timelines extended to September 2021 in most markets. In the United Kingdom, the Financial Conduct Authority implemented equivalent requirements under PS20/6 with a phased enforcement timeline concluding in March 2022.

SCA requires that a payment service provider authenticates a customer using at least two of the following three factors when initiating a remote electronic payment.

SCA Factor	Definition	Common Implementation
Knowledge	Something only the user knows.	PIN, password, passphrase, security questions.
Possession	Something only the user possesses.	Mobile phone with OTP, hardware token, banking app.
Inherence	Something the user is.	Fingerprint, facial recognition, voice recognition, behavioural biometric.

One thing to consider is that the two factors used must be independent, so that compromising one does not weaken or expose the other. They must also generate an authentication code that is dynamically linked to the specific transaction amount and payee, ensuring the code cannot be reused for a different transaction.

How EMV 3DS 2 Meets the SCA Requirement

A 3DS challenge flow that presents a one-time passcode sent to the cardholder’s registered mobile phone (possession factor) and requires a PIN or password entry (knowledge factor) satisfies the SCA two-factor requirement. A challenge using a biometric via a banking app (inherence) combined with app possession also meets the standard.

The dynamic linking requirement is met through the authentication code generated by the ACS, which is transaction-specific and cannot be reused. The card schemes and EMVCo have worked with the EBA to confirm that properly implemented EMV 3DS 2.x satisfies the technical specifications in the EBA Regulatory Technical Standards.

The critical word is properly implemented. A 3DS integration that does not enforce challenge flows where required, that accepts frictionless outcomes beyond the permitted exemption thresholds, or that does not generate and record authentication codes correctly is not SCA-compliant even if it uses EMV 3DS 2.x infrastructure.

SCA Exemptions: When Frictionless Authentication Is Permitted

SCA does not require a challenge on every transaction. The EBA Regulatory Technical Standards define a series of exemptions under which frictionless authentication is permissible. Applying these exemptions correctly is where significant conversion optimisation lives.

Exemption	Condition	Who Can Apply It
Low-value transactions	Transactions below EUR 30. Cumulative limit of EUR 100 or 5 consecutive transactions without SCA.	Acquirer or issuer can apply. Issuer can override.
Transaction Risk Analysis (TRA)	Transaction fraud rate below thresholds set in EBA RTS (0.01% to 0.13% depending on reference fraud rate). Transaction below the relevant value threshold.	Acquirer or issuer. Issuer fraud rate must be below applicable EBA threshold. Issuer can reject the exemption claim.
Recurring transactions	Fixed amount, fixed payee. SCA applied on first transaction in the series.	Acquirer for subsequent recurring payments to same payee at same amount.
Trusted beneficiaries	Cardholder has added payee to trusted list with their issuer following a prior SCA challenge.	Issuer after cardholder whitelisting.
Secure corporate payments	Dedicated corporate payment protocols and processes applicable to legal persons only.	Acquirer for eligible corporate transactions.

The TRA exemption is the one that drives the most frictionless conversion in practice. It allows transactions to be approved without challenge where the acquiring PSP’s and critically, the issuing bank’s fraud rates are below the EBA thresholds. Issuers have the right to decline a TRA exemption claim and require SCA regardless. This means the frictionless rate on TRA-exempted transactions is partly controlled by the issuer.

⚠️ Common SCA Compliance Mistakes

1. Applying TRA exemptions without monitoring issuer override rates — if issuers are regularly declining your TRA claims, your fraud model or transaction quality is triggering issuer concern.

2. Not implementing dynamic linking correctly — the authentication code must be specific to the transaction amount and payee.

3. Treating 3DS frictionless as inherently SCA-compliant — frictionless is only SCA-compliant when it falls under a valid exemption.

4. Not retrying with SCA when a soft decline is received — PSD2 requires the ability to escalate to full SCA when an exemption is declined.

The Soft Decline and SCA Escalation Flow

When a PSP applies a TRA exemption and the issuer declines it, the payment response will include a specific soft decline code indicating that SCA is required. The PSD2 framework and card scheme rules require that PSPs who receive this response are able to retry the transaction with a full SCA challenge flow.

This requires the merchant checkout and payment platform to support the soft decline escalation path, detecting the response, initiating a new 3DS authentication with a challenge, and presenting that challenge to the cardholder. PSPs and merchants that do not handle soft declines correctly see these transactions fail at payment, which is avoidable.

PSD2 in the UK Post-Brexit

The United Kingdom is no longer subject to EU law but implemented equivalent SCA requirements through the FCA. The FCA’s PS20/6 policy statement and subsequent supervisory guidance established SCA requirements for UK payment service providers using the same fundamental framework as PSD2 — two-factor authentication for remote electronic payments, with the same category of exemptions.

The key practical difference for cross-border transactions is that UK issuers and EU issuers are now in separate regulatory regimes. A TRA exemption that complies with EBA RTS thresholds may be handled differently by a UK issuer operating under FCA guidance. PSPs processing transactions across both EU and UK markets need to be aware of both frameworks and monitor issuer override behaviour separately for each.

PSD3: What Is Coming

The European Commission’s proposed Payment Services Regulation 3 (PSR) and revised Payment Services Directive 3 (PSD3) are progressing through the EU legislative process. The authentication framework under PSD3 maintains the SCA requirement while proposing some refinements to the exemption framework and introducing stronger requirements for open banking authentication flows.

The most significant proposed change for 3DS infrastructure is the proposed strengthening of the TRA exemption framework, with more granular fraud rate thresholds and potential changes to which party can apply which exemption. Financial institutions and PSPs with significant EU transaction volumes should be monitoring the legislative timeline and preparing their 3DS infrastructure for potential adjustments to exemption logic.

The fundamental role of EMV 3DS 2. as the primary SCA mechanism for card payments is not under threat from PSD3. The direction of travel is toward stricter enforcement and more granular exemption management, not away from the protocol.

What Enterprise PSPs and Banks Need

A certified EMV 3DS 2.2 or 2.3 ACS for issuing banks, with proper SCA challenge flow implementation and dynamic linking
A certified 3DS Server for acquirers and merchants with exemption logic, soft decline handling, and SCA retry flows
Ongoing monitoring of fraud rates to maintain TRA exemption eligibility under EBA thresholds
Transaction-level authentication reporting for regulatory audit trails
Legal entity awareness across EU and UK regulatory regimes for cross-border operations
A 3DS provider with active regulatory monitoring capability for PSD3 developments

Frequently Asked Questions

Q: Does 3D Secure make a payment PSD2 SCA compliant?

A: EMV 3DS 2.x can make a remote card payment SCA compliant when it presents a valid multi-factor challenge or correctly applies an SCA exemption. Not all 3DS flows are automatically SCA compliant — the implementation must correctly enforce challenge flows where required and handle exemptions within EBA threshold limits.

Q: What is the transaction risk analysis SCA exemption?

A: The TRA exemption allows a payment to be processed without a challenge if both the acquiring PSP’s and the issuing bank’s fraud rates are below specified EBA RTS thresholds, and the transaction is below the applicable value limit. The issuer can decline a TRA exemption claim and require SCA regardless.

Q: What happens when an SCA exemption is declined by the issuer?

A: The issuer returns a soft decline code indicating SCA is required. The PSP or merchant must be able to detect this response and retry the transaction with a full 3DS SCA challenge flow. Platforms that cannot handle soft declines will see these transactions fail at payment.

Q: Is PSD2 SCA required in the UK as well as the EU?

A: Yes. The UK implemented equivalent SCA requirements through the FCA following Brexit. UK PSPs must comply with FCA PS20/6 and subsequent supervisory guidance, which mirrors the PSD2 SCA framework. Cross-border transactions involve both UK and EU regulatory contexts.

Q: What is PSD3 and when does it take effect?

A: PSD3 refers to the proposed third Payment Services Directive under discussion in the EU legislative process. It maintains the SCA requirement while refining the exemption framework. The timeline for implementation remains subject to EU legislative process. EMV 3DS 2.x will continue to be the primary SCA mechanism under PSD3.

Q: What is the EBA RTS for SCA?

A: The EBA Regulatory Technical Standards (RTS) on Strong Customer Authentication and Common and Secure Open Standards of Communication define the technical requirements for SCA under PSD2. They specify the factor requirements, exemption conditions including TRA thresholds, and dynamic linking obligations. The RTS are available on the EBA website.