Strong Customer Authentication (SCA)
SCA is the PSD2 rule that an electronic payment, or online access to a payment account, must be authenticated with two independent factors — and, for remote payments, bound to the exact amount and payee. This guide covers the whole rule set across channels: the factors and dynamic linking, what is out of scope and every exemption with its thresholds, how SCA runs for cards online and in store and for online and open banking, the UK regime, what PSD3 / PSR change, and similar mandates elsewhere.
The three element categories
The RTS sets the security requirements for each category (Articles 6–8) and the EBA's June 2019 Opinion (EBA-Op-2019-06) lists which common methods qualify. Two elements from the same category — a password plus a PIN, or two fingerprints — are not SCA.
Knowledge — something only the user knows
- PIN, password or passphrase
- Knowledge-based answer (security question)
- Memorised swiping path or pattern
- Card number, expiry date or CVV — printed on the card, so neither knowledge nor possession
- User ID, e-mail address or username
Possession — something only the user has
- App or browser with device binding (a key held in a secure element or TEE)
- OTP generated by, or received on, a device: hardware token, authenticator app, SMS OTP (proves possession of the SIM)
- Signature generated by a device (e.g. a FIDO authenticator)
- Card evidenced by a card reader (chip cryptogram, CAP) or by a dynamic card security code
- QR code or photoTAN scanned from another device
- App or browser without device binding
- Card details typed into a form
Inherence — something the user is
- Fingerprint, face, iris, voice or vein recognition
- Behavioural biometrics such as keystroke dynamics, where the false-acceptance rate is low enough
- Device biometrics (Face ID, Touch ID, Android BiometricPrompt) used to unlock a bound key
- Behavioural data used only as a risk signal (device fingerprint, location, typing speed fed into a fraud score) — that supports TRA, it is not an element
Independence (RTS Art. 9)
A breach of one element must not compromise the others. The common case is a phone that is both the possession element and the device the user types the password into. The RTS allows this multi-purpose device if the elements run in separate secure execution environments and there are mechanisms to detect and mitigate a compromised device — in practice: a key in the secure enclave or StrongBox, released only by a biometric or PIN check performed by the OS, plus jailbreak/root and tamper detection in the app.
The authentication code (RTS Art. 4)
- Authentication produces an authentication code that can be used only once and cannot be forged or derived from previous codes.
- No information about which element was wrong may be revealed on failure.
- At most five consecutive failed attempts before the credential is temporarily or permanently blocked, and the user is told.
- Online-banking sessions time out after at most 5 minutes of inactivity.
Dynamic linking (RTS Art. 5)
For remote electronic payments, PSD2 Art. 97(2) adds a requirement on top of the two factors: the authentication must be dynamically linked to a specific amount and a specific payee. The RTS spells out four conditions:
Confidentiality, authenticity and integrity of the amount and payee must be protected through every phase of authentication. Two special cases:
- Card-based reservations (Art. 5(2)) — where the payer consents to an exact amount being blocked (hotel, car rental, fuel), the code is linked to that blocked amount.
- Batch payments (Art. 5(3)) — one code may cover a batch of remote transactions to several payees, linked to the total amount and the list of payees.
| Method | Elements | How dynamic linking is achieved |
|---|---|---|
| Banking app push + biometric | Possession (bound key) + inherence | The app displays amount and payee and signs them with the device key; the server verifies the signature over those exact values. |
| SMS OTP + password | Possession (SIM) + knowledge | The OTP is generated for, and the SMS text states, the amount and payee; the server binds the OTP to them. An SMS that shows only "your code is 123456" fails the awareness condition. |
| EMV 3DS challenge | Whatever the ACS uses (app, OTP + password, biometric) | The ACS shows the purchase amount and merchant name from the AReq; the CAVV/AAV it issues is computed over the transaction and verified at authorization. |
| FIDO / passkey with SPC | Possession (authenticator) + inherence or knowledge (user verification) | Secure Payment Confirmation shows amount and payee in browser chrome and puts them into the signed WebAuthn assertion. |
| Chip & PIN at the POS | Possession (chip cryptogram) + knowledge (PIN) | Not a remote payment, so dynamic linking is not required — but the ARQC covers the amount anyway. |
| EUDI Wallet | Possession (WSCD key) + knowledge or inherence (wallet unlock) | The verifier sends transaction data in the OID4VP request; the wallet shows it and binds it into the signed presentation. See the EUDI Wallet guide. |
Related: FAPI and rich authorization requests carry amount and payee to the bank →
🧩 Check yourself