SCA and 3DS2 are not the same thing
SCA is the legal requirement. 3DS2 is the protocol most PSPs use to meet it. Strong Customer Authentication comes from PSD2 (Directive (EU) 2015/2366) and its binding technical standard, Commission Delegated Regulation (EU) 2018/389, known as the “RTS on SCA and CSC.” It mandates two-factor authentication on electronic payments in the EEA. EMV 3-D Secure version 2 is the technical mechanism card schemes built to satisfy that mandate for card-not-present transactions.
The distinction matters because vendors blur it. A PSP that says “we’re SCA-compliant” usually means “we support 3DS2.” That’s necessary but not sufficient. 3DS2 is a protocol with dozens of optional data fields and configuration choices. A merchant can run 3DS2 end to end and still fail SCA if the ACS never actually performs a compliant two-factor check, or if exemption requests are malformed and get silently ignored by the issuer.
Outside the EEA, 3DS2 shows up without an SCA mandate behind it. In the US, PSPs use 3DS2 to shift fraud liability to the issuer, not to satisfy a legal authentication requirement. If your compliance obligations span both regions, that’s two different reasons to run the same protocol, and conflating them leads to over-building in markets where SCA doesn’t apply and under-building where it does. A US-only merchant expanding into the EU can’t reuse its domestic 3DS2 configuration and assume SCA compliance comes along for free; the data requirements and exemption logic behind each are different because the underlying legal obligation is different.
Why PSD2 mandates SCA, and why 3DS2 became the default way to meet it
PSD2 requires two of three independent factors on remote electronic payments: something the customer knows (a PIN or password), something they have (a phone that receives an OTP), or something they are (a fingerprint or face scan). The regulation names the requirement; it doesn’t name a protocol. The mandate itself was transposed into EU member state law with enforcement dates staggered by market, generally taking effect from September 2019, with several markets granted extensions to September 2021 to give issuers and acquirers time to build out 3DS2 support.
3DS2 became the default implementation because it was already built into the card networks’ infrastructure. Where 3DS1 sent a static password challenge on every transaction, 3DS2 passes over 100 contextual data points, including device fingerprint, transaction history, and browser data, to the issuer‘s Access Control Server, which scores the risk before deciding whether to challenge at all. According to a Broadcom EMV 3-D Secure analysis, merchants running 3DS2 typically see a 1-3% lift in authorization rates from that added context. The same analysis notes that a poorly implemented 3DS2 flow, with missing data fields, an outdated protocol version, or unhandled mobile edge cases, can cost 2-5% of approvals instead. The protocol doesn’t guarantee the outcome; the implementation does.
The three factors SCA requires an issuer to check
Factor Examples Who evaluates it Knowledge PIN, password, security question Issuer’s ACS Possession Phone receiving an OTP, hardware token, registered device Issuer’s ACS Inherence Fingerprint, face scan, voice pattern Issuer’s ACS, via the cardholder’s device
The merchant or acquirer sends the 3DS2 authentication request; the issuer’s Access Control Server decides which two factors to check and whether the transaction can skip a challenge entirely. That split matters for scoping a compliance review: your integration has to send correct, complete data, but it doesn’t get to decide how the factors are evaluated. The issuer’s ACS makes that call, every time, regardless of what the merchant’s own risk engine concluded.
Exemptions: when a transaction can skip the challenge
This is the section compliance officers actually search for, and it’s the section every competitor guide leaves as prose instead of numbers. Under Delegated Regulation (EU) 2018/389, four exemption categories cover most commercial traffic:
- Low-value exemption (Article 16). Transactions of €30 or less can skip SCA, but only up to a cumulative €100 or five consecutive exempted transactions to the same merchant. Hit either cap, and the next transaction requires full authentication regardless of its amount.
- Transaction risk analysis, or TRA (Article 18). The exemption most orchestration platforms lean on. Eligibility depends on the PSP’s own fraud rate for that payment category, measured against the published reference table below.
- Trusted beneficiary and recurring transactions. A cardholder can whitelist a specific merchant with their issuing bank, exempting future transactions to that merchant regardless of amount. For subscriptions and other fixed-amount recurring payments to the same merchant, only the first transaction requires SCA, as long as the amount and recipient don’t change afterward.
- One Leg Out. If either the payer’s or the payee’s PSP sits outside the EEA, the transaction falls outside PSD2’s territorial scope entirely, and SCA doesn’t apply regardless of amount.
TRA eligibility runs against a published fraud-rate table:
| PSP’s card fraud rate | Exemption threshold value (ETV) |
|---|---|
| 0.13% (13 bps) or below | Up to €100 |
| 0.06% (6 bps) or below | Up to €250 |
| 0.01% (1 bps) or below | Up to €500 |
A PSP with a fraud rate above 0.13% doesn’t get TRA at any transaction value, no matter how the request is worded. That’s why some PSPs push harder on exemptions than others: the exemption is earned by keeping fraud rates down, not requested on demand. The EBA’s Single Rulebook Q&As set the calculation methodology behind that fraud rate, and getting the math wrong doesn’t just risk a rejected exemption in the moment. It can trigger a review of every exemption claimed on that fraud-rate basis.
Every exemption is a request, not a guarantee. The merchant or acquirer flags it in the 3DS2 message; the issuer’s ACS makes the final call and can force a challenge anyway if its own risk engine disagrees with the exemption claim.
What “SCA-compliant” actually requires from a merchant’s integration
Three things, none of which “we support 3DS2” automatically covers:
- Complete data element transmission. 3DS2’s value comes from the contextual data it hands the issuer. An integration that sends a minimal, sparse data set gives the ACS less to work with, which pushes more transactions into a forced challenge instead of frictionless approval: the opposite of what SCA’s risk-based design is supposed to deliver. Visa’s 3DS data requirements spell out which fields matter most for a frictionless outcome, and which ones issuers weight most heavily in their own risk scoring.
- Correct exemption request logic. Claiming TRA on a transaction that exceeds your actual fraud-rate threshold, or claiming the low-value exemption after the cumulative cap is already hit, doesn’t just risk a single decline. Issuers track exemption claims over time, and a pattern of invalid claims can lead to exemptions being rejected wholesale for that merchant relationship.
- Verified challenge handling. When the ACS forces a challenge, the flow has to render correctly across browsers, in-app webviews, and mobile devices, and has to handle timeouts without silently failing the transaction. This is the layer where most “SCA-compliant” integrations quietly break, because it only shows up in edge cases that a standard test suite doesn’t cover: a webview that can’t render the challenge iframe, a timeout that drops the transaction instead of falling back, a redirect that loses session state on certain mobile browsers.
None of this shows up in a vendor’s marketing claim that they “support 3DS2.” It shows up when a QSA or an issuer’s own monitoring flags a gap between what was implemented and what the regulation actually requires.
Where 3DS2/SCA implementations go wrong
The recurring failure mode isn’t a missing feature. It’s a single point-to-point integration that can’t adapt. A merchant integrates 3DS2 with one PSP, tunes the data fields and exemption logic for that PSP’s ACS relationships, and it works. Then they add a second PSP for redundancy or geographic coverage, and the same exemption logic, built around the first PSP’s fraud-rate profile, doesn’t transfer cleanly. Each PSP has its own fraud rate, which means its own TRA eligibility: a threshold that was valid on PSP A can be invalid on PSP B, and nothing in a standard integration flags that mismatch automatically.
The compliance risk compounds because nobody owns the cross-PSP view. Engineering owns the integration with each individual PSP. The compliance officer approved a CDE boundary that assumed one 3DS Server relationship, not several with different exemption profiles and different fraud-rate baselines. That gap, between what was approved during vendor risk assessment and what’s actually running in production months later, is exactly the scenario compliance officers name as their top concern with expanding payment stacks: the engineering team adds a connection, and the compliance review hasn’t caught up.
What to ask a vendor that claims SCA compliance
“We’re SCA-compliant” is a claim, not evidence. Before that claim goes into a vendor risk assessment, get specific answers on four points:
- Which party runs the 3DS Server? A vendor might operate its own 3DS Server as a hosted service, or pass the request through to whichever PSP is underneath it. That distinction changes who controls the data fields sent to the ACS, and therefore who’s accountable when a frictionless flow starts converting to forced challenges.
- What fraud rate is the exemption logic built on? If the vendor claims TRA eligibility, ask for the fraud rate that claim is based on and how recently it was calculated. A fraud rate that qualified for the €500 threshold six months ago doesn’t stay valid indefinitely if the underlying transaction mix has shifted.
- How are exemption requests tracked across providers? If the vendor routes across more than one PSP or ACS relationship, ask how exemption eligibility is reconciled when the providers have different fraud-rate profiles. A generic answer, a bare claim of “we handle it,” doesn’t hold up under a compliance review. Ask for a data flow diagram or a specific mechanism, not a summary sentence.
- What happens on a forced challenge failure? Ask what the vendor’s fallback is when an ACS challenge times out or fails to render. This is the failure mode that doesn’t show up in a demo and does show up in production.
Where Orchestra fits: routing 3DS2 authentication without owning the compliance risk
Orchestra’s 3DS authentication orchestration routes 3DS2 authentication requests across PSPs and their ACS relationships through a single integration, and applies exemption logic consistently across that routing layer instead of re-tuning it per PSP. That solves the specific failure mode above: adding a second or third PSP doesn’t mean re-deriving TRA thresholds and data-field requirements from scratch for each one, because the routing layer already tracks which PSP’s fraud-rate profile supports which exemption at which transaction value.
It doesn’t change who’s legally on the hook. SCA is a PSD2 obligation that sits with the merchant and acquirer, not with any orchestration or routing layer sitting in between. Orchestra’s PCI DSS Level 1 compliance outsourcing covers the scope reduction that comes from tokenization and Level 1 certification. It doesn’t transfer the underlying SCA mandate. If a vendor sells that transfer as included in the package, that’s a claim to check against the specific contractual language, not take at face value.
PSD3 is coming, and the exemption rules will tighten
PSD3 and its companion Payment Services Regulation (PSR1) reached political agreement on 27 November 2025. According to Norton Rose Fulbright’s PSD3/PSR briefing, formal adoption and publication are expected in early-to-mid 2026, starting an 18-24 month transposition period for PSD3 itself. The PSR, which carries most SCA and fraud-monitoring obligations, is expected to begin enforcement in late 2026 to early 2027, since as a regulation it applies directly in member states without waiting for national transposition the way a directive does.
The practical shift for compliance teams: PSPs that don’t apply SCA correctly, or don’t meet the mandated fraud-monitoring standards behind it, face more liability exposure for resulting fraud losses under the new framework, according to Morrison Foerster’s PSD3 analysis. If your current exemption logic is already loosely tracked across multiple PSPs, that’s the gap PSD3 raises the stakes on closing before enforcement begins, not after.
Frequently Asked Questions
Are SCA and 3DS2 the same thing?
No. SCA is the PSD2 regulatory requirement for two-factor authentication on electronic payments. 3DS2 is the technical protocol most commonly used to satisfy that requirement for card transactions.
Does every transaction under PSD2 need SCA?
No. PSD2 defines specific exemptions, including low-value, transaction risk analysis, trusted beneficiary, and recurring payments, where a transaction can proceed without a full two-factor challenge, subject to caps set in Delegated Regulation (EU) 2018/389.
Who decides whether a transaction is exempt from SCA?
The merchant or acquirer requests the exemption through the 3DS2 message, but the issuer’s Access Control Server makes the final call on whether to honor it or force a challenge anyway.
What are the three authentication factors SCA requires?
Knowledge (something the customer knows, like a PIN), possession (something the customer has, like a phone that receives an OTP), and inherence (something the customer is, like a fingerprint or face scan). SCA requires at least two of these three.
Does using 3DS2 automatically make us SCA-compliant?
Not automatically. Compliance depends on sending the full 3DS2 data element set, requesting exemptions correctly against your actual fraud-rate thresholds, and confirming the ACS performs a genuine two-factor check whenever a challenge is triggered.
Does SCA apply outside the EU and UK?
No. SCA is scoped to EEA-region electronic payments under PSD2 and, going forward, PSD3. 3DS2 is used elsewhere, including the US, but as a fraud-scoring and liability-shift tool rather than a legal authentication mandate.
What happens if we don’t implement SCA correctly?
Beyond direct regulatory exposure, incorrect implementation typically shows up as lost liability shift on fraud chargebacks and lower issuer approval rates, since incomplete data fields or invalid exemption claims push more transactions into unnecessary challenges or outright declines.