One-line definition
Strong Customer Authentication (SCA) is the EU regulatory standard, mandated by PSD2, that requires online payments to be verified using at least two independent factors from three possible categories — something the customer *knows*, *has*, or *is* — before the transaction can be authorized.
Real-life analogy
Think of a bank vault that needs two different keys turned at the same time by two different people. One key alone does nothing. A password alone (something you know) is not enough; a phone alone (something you have) is not enough. SCA forces the payment flow to combine two unrelated proofs of identity, so that a stolen password is useless without the device, and a stolen device is useless without the password or biometric.
A more everyday version: withdrawing cash from an ATM requires your physical card (something you have) *and* your PIN (something you know). If someone shoulder-surfs your PIN, they still need the card. If someone steals the card, they still need the PIN. SCA applies that same logic to e-commerce, where the "card" becomes a registered device or an app, and the "PIN" becomes a password, OTP, or fingerprint.
Core formula
SCA is satisfied when at least two of the following three independent elements are present, and the elements must belong to different categories:
| Element category | What it means | Typical examples |
|---|---|---|
| Knowledge (something you **know**) | A secret only the customer should hold | Password, PIN, passphrase, security question |
| Possession (something you **have**) | A physical or digital object the customer controls | Mobile phone, hardware token, smart card, authenticator app |
| Inherence (something you **are**) | A biological or behavioral trait | Fingerprint, Face ID, voice recognition, iris scan |
The formula can be written as:
SCA = (Knowledge + Possession) OR (Knowledge + Inherence) OR (Possession + Inherence)
Critically, two passwords do not count. Two factors from the same category are treated as one, because a single breach (e.g., a phishing kit) can compromise both. The elements must also be independent, so that compromising one does not compromise the other, and the authentication must be dynamic, meaning a new code or challenge is generated for each transaction rather than reused.
Comparison with related terms
| Term | Scope | Who mandates it | Key difference from SCA |
|---|---|---|---|
| **SCA** | Authentication for electronic payments and account access | EU (PSD2), enforced nationally | The specific two-of-three rule; a legal requirement, not a suggestion |
| **2FA / MFA** | General account security | Voluntary or platform policy | 2FA can use two factors from the same category in some weak implementations; SCA explicitly forbids this and adds transaction-linking rules |
| **3D Secure 2 (3DS2)** | A protocol for authenticating card-not-present transactions | Card networks (Visa, Mastercard) | 3DS2 is the *technology* most commonly used to deliver SCA; SCA is the *regulation* 3DS2 helps satisfy |
| **PCI DSS** | Data security for cardholder information | Card networks | PCI DSS protects stored card data; SCA protects the *moment of payment authorization* |
| **PSD2** | The broader EU payment services directive | EU legislature | PSD2 is the law; SCA is one of its requirements |
In short: PSD2 created the obligation, SCA is the obligation, and 3DS2 is the most common way merchants meet it.
Use cases
1. Card-not-present e-commerce in the EEA. Any online card payment where both the merchant and the cardholder's bank are in the European Economic Area generally requires SCA. A German shopper buying from a French retailer will typically be challenged unless an exemption applies.
2. Recurring subscriptions. The first payment in a subscription requires SCA. Subsequent recurring charges of the same amount to the same merchant can often be exempted, but if the amount changes — say a plan upgrade from €9.99 to €19.99 — SCA is usually triggered again.
3. Account login and balance checks. SCA is not limited to payments. Under PSD2, customers accessing their account online, or third-party providers (like budgeting apps) accessing account data, must also apply SCA at least every 90 days.
4. Open banking and AISP/PISP flows. A payment initiation service provider (PISP) must authenticate the customer with SCA before initiating a transfer, and the customer's bank must apply SCA when the account is accessed.
5. Low-value and low-risk exemptions. Transactions under €30 can often skip SCA, but only up to a cumulative limit of €100 or five consecutive transactions before SCA is required again. Merchants with low fraud rates (below the thresholds set by the EBA, typically 0.13% for card fraud and 0.06% for transaction fraud) can also apply a TRA (Transaction Risk Analysis) exemption for payments up to €500.
Misconceptions
"SCA is the same as 3D Secure." Not quite. 3DS2 is one implementation of SCA, and it is the dominant one for cards, but SCA can also be satisfied through app-based authentication, biometrics, or hardware tokens. A merchant can be SCA-compliant without using 3DS at all, though in practice 3DS2 is the path of least resistance.
"SCA always means a worse checkout experience." This was true under 3DS1, where redirects and static passwords caused high abandonment. Under 3DS2, authentication is often invisible or frictionless: the issuer can approve using risk signals and device data without challenging the customer, and the challenge, when it happens, is usually a biometric prompt or a one-time code in-app. Properly implemented, 3DS2 can actually *increase* approval rates because the issuer sees richer data.
"SCA applies to all transactions." No. There are exemptions: low-value transactions (under €30), recurring payments of the same amount, trusted beneficiaries, and TRA-based exemptions. The catch is that exemptions are not guaranteed — the issuer can still request a challenge, and exceeding exemption thresholds forces SCA.
"SCA is a merchant's problem only." It is a shared responsibility. The issuer, the acquirer, the PSP, and the merchant all play a role. A merchant can request an exemption, but the issuer decides whether to grant it. Misconfigured exemption logic on the merchant side is one of the most common causes of unnecessary declines.
"Once authenticated, always authenticated." SCA has a time limit. For account access, re-authentication is required at least every 90 days. For payments, the authentication is transaction-specific; a new payment generally needs a new authentication unless an exemption applies.
Related terms
- PSD2 (Payment Services Directive 2) — the EU law that introduced SCA.
- 3D Secure 2 (3DS2) — the authentication protocol most merchants use to comply.
- Exemptions — the carve-outs (low-value, TRA, recurring, trusted beneficiary) that let payments skip SCA.
- Transaction Risk Analysis (TRA) — a risk-based exemption that allows higher-value payments to skip SCA when fraud rates are low.
- Dynamic Linking — the SCA requirement that the authentication code be tied to the specific amount and payee, so a code generated for €10 cannot be reused for €1,000.
- AISP / PISP — account information and payment initiation service providers, both subject to SCA.
- Frictionless Flow — a 3DS2 authentication that passes without customer challenge.
- Challenge Flow — a 3DS2 authentication that requires the customer to complete an OTP, biometric, or app approval.
- EBA (European Banking Authority) — the regulator that publishes the technical standards and fraud thresholds behind SCA.