Definition
SCA (Strong Customer Authentication) is the central security requirement of PSD2.
To validate an online payment, access sensitive data or authorise a TPP, the PSU must prove their identity with at least two independent factors, drawn from distinct categories.
The 3 factors
SCA requires 2 of 3 factors, each from a different category:
- Knowledge (something you know): password, PIN, secret answer.
- Possession (something you have): phone (OTP, push), physical key, card.
- Inherence (something you are): biometrics — fingerprint, face, voice.
Examples: PIN + push in the app (knowledge + possession) is valid; fingerprint + phone (inherence + possession) is too; password + secret question is not (the same category twice).
When SCA is mandatory
- On every online payment initiated by the PSU.
- On every AISP access to accounts (every 180 days since the 2022 RTS amendment, up from 90 before).
- On the first connection to a banking service or to a new session.
- For any sensitive action: adding a payee, transferring to a new IBAN, raising a limit.
The available exemptions
So as not to degrade UX, the EBA provides exemptions that banks may grant:
- Low value: ≤ €30 (cumulative counter of €100 or 5 transactions).
- TRA (Transaction Risk Analysis): possible if the merchant or bank has a low fraud rate.
- Trusted merchant: added by the PSU to their whitelist.
- Identical recurring payment: same amount, same payee (SCA on the first occurrence).
- Transfer between accounts held by the same owner at the same ASPSP.
- B2B payment via a dedicated secure protocol (corporate cards).
Dynamic linking
For payments, SCA must include dynamic linking: the code is tied to the exact amount and payee. If the attacker changes the IBAN or amount after authentication, the transaction is rejected — which makes man-in-the-middle attacks far harder.
In the PSD2 ecosystem
SCA is implemented by the ASPSP (the bank), never by the TPP. The TPP can trigger it via different flows (redirect, decoupled, embedded), but it is always the bank that authenticates its customer.
Concrete examples
- Online card payment: 3D Secure 2 is the dominant implementation. You approve with biometrics or push in your bank's app, rather than an SMS OTP, because biometrics convert better.
- Connecting to an AISP: linking Bankin' to your bank requires a full SCA (login + biometrics), to be renewed every 180 days.
- Trusted merchant: after a first SCA payment at Amazon, adding it to your whitelist removes SCA from subsequent payments.
- TRA and conversion: a large merchant (Cdiscount, Decathlon) invests in a risk engine, often via its PSP, to trigger the TRA exemption and maximise conversion.
- TPP side: a PISP (Fintecture, Bridge, Trustly) must handle three SCA modes — redirect (sending to the bank's page), decoupled (push while the PSU stays on the site) and embedded (entry in the TPP's interface, rarer) — with each bank favouring one.