PSD2 / SCA · Identity Lens

PSD2 / SCA

PSD2 SCA codified what good customer authentication looks like; the regulator-led RTS turned it into design requirements that most CIAM stacks are still catching up with.

Back to Thinking

Full name: Revised Payment Services Directive — Strong Customer Authentication (PSD2 SCA)
Region: European Economic Area (PSD3 / PSR forthcoming)
Applies to: Payment service providers operating in the EEA: banks, payment institutions, e-money institutions, account-information service providers (AISPs), and payment-initiation service providers (PISPs).

PSD2 (Directive (EU) 2015/2366) and its Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication (Commission Delegated Regulation (EU) 2018/389) set the baseline for customer authentication in EEA payments. PSD3 and the Payment Services Regulation, in the EU legislative pipeline, will tighten the regime further. SCA principles — independence of factors, dynamic linking, exemption logic — are the modern reference for customer-facing identity design.

What it asks for

The Identity Lens

The clauses that bite when identity architecture is weak, rewritten in plain English. Authoritative text is linked below.

Article 4 RTS — Authentication code

The authentication code must be unique to each transaction, unforgeable, and not reusable. Replay-resistant authenticators (FIDO2, app cryptograms) satisfy this; SMS OTP increasingly does not.

Articles 6-9 RTS — Independence of authentication elements

Knowledge, possession, and inherence must be independently compromisable. A factor implemented on the same device as another factor must use software-isolated execution environments and tamper-resistance.

Article 5 RTS — Dynamic linking

For payment transactions, the authentication code must dynamically link to the amount and the payee. This is the SCA-specific requirement that distinguishes payment authentication from generic login.

Articles 10-18 RTS — Exemptions

Transaction risk analysis, low-value, recurring, trusted beneficiary, and corporate exemptions allow SCA to be skipped under specific conditions. Implementing exemptions correctly requires real-time fraud signal evaluation in the authentication flow.

Where teams miss it

Common Misses

Patterns we see again and again — usually because the identity programme runs in parallel to the compliance programme rather than inside it.

SMS OTP retained as a primary factor despite EBA opinion language that increasingly treats it as non-compliant for new implementations and as fraud-prone in operation.

Dynamic linking implemented at the messaging layer (the OTP message includes the amount) but not cryptographically bound to the authentication code — failing the RTS technical interpretation.

Exemption logic that approves the exemption without recording the underlying transaction-risk-analysis decision, leaving the bank unable to evidence the exemption was correctly applied at audit.

Customer-identity stack that achieves SCA compliance through a separate auth flow bolted on top of a non-compliant primary login — duplicating effort and producing inconsistent fraud signals.

What works

Where Design Pays Off

Patterns we have seen survive supervisory review, audit, and the next change.

Phishing-resistant, replay-resistant authenticators (FIDO2, app cryptograms with attested device binding) as the SCA primary factor, with SMS OTP retained only as a fallback governed by step-up rules.

Dynamic linking and exemption logic implemented inside the CIAM platform so both consumer login and payment auth share a single fraud-and-risk decision plane.

Customer-identity architecture designed against the PSD3 / PSR draft text now, so the gap to the next regime is shrinking rather than expanding.

Authoritative sources

Read the source

Every claim above is checkable. Start here.

EUR-Lex

Commission Delegated Regulation (EU) 2018/389 — RTS on SCA

EUR-Lex

Directive (EU) 2015/2366 — PSD2

European Banking Authority

EBA Opinions and Q&A on SCA and PSD2

Related Services

Need a PSD2 / SCA-ready identity baseline?

We start with an assessment that maps your identity controls to PSD2 / SCA requirements, then design and operate the gaps.

Book a Conversation