PSD2 and strong customer authentication: the rules behind payment friction

Strong customer authentication is the reason online payments started asking for a second step — and the reason some still do not. The requirement is simple; the exemption framework is where the commercial consequences live, because it decides how much friction your customers experience.

What SCA requires

Authentication using at least two independent elements from three categories: knowledge (something only the user knows), possession (something only the user has), and inherence (something the user is). Independence matters — compromise of one must not compromise another, which is why a code displayed in the same app being authenticated is weak.

For remote payments there is an additional requirement: dynamic linking. The authentication code must be specific to the amount and the payee, and any change to either must invalidate it. This is what prevents an attacker reusing a captured approval for a different transaction.

The exemptions that shape the experience

• Low value. Small transactions, subject to cumulative counters and amount limits before a challenge is forced.
• Transaction risk analysis (TRA). The commercially important one — if the provider's fraud rates sit below defined thresholds, transactions up to corresponding values may be exempted. Lower fraud earns more exemption headroom, so fraud performance directly buys reduced friction.
• Trusted beneficiaries. Payees the customer has whitelisted with their bank.
• Recurring transactions of the same amount to the same payee, after the first.
• Merchant-initiated transactions, which sit outside SCA when properly set up — the mechanism behind most subscription billing.
• Corporate payments made through dedicated secure processes.

Exemptions are requested, not guaranteed. The merchant or acquirer may flag a transaction as exempt, but the issuer decides — and can challenge anyway. Designing a checkout that assumes an exemption will be honoured produces unpredictable behaviour and abandoned carts.

Where implementations go wrong

• Treating the two factors as independent when they are not — a one-time code delivered to, and entered on, the same compromised device.
• Breaking dynamic linking by displaying an amount that does not match what is authorised, which also destroys the customer's ability to spot fraud.
• Ignoring accessibility. Authentication depending solely on a smartphone excludes customers who do not have one, and inherence factors need alternatives.
• Not measuring exemption outcomes. Teams request exemptions and never track how often issuers honour them, so nobody knows whether the strategy works.
• Assuming out-of-scope means unregulated. One-leg-out transactions and merchant-initiated flows have their own conditions.

Relationship to PCI DSS

They solve different problems and both apply. SCA authenticates the payer; PCI DSS protects card data. Satisfying one says nothing about the other, and a payment programme needs both mapped to a single control set rather than run as separate workstreams.

UK divergence

The UK retained an equivalent regime after leaving the EU and has been consulting on reform, with its own regulator and guidance. If you operate in both markets, treat them as two regimes with a shared architecture — verify current UK requirements separately rather than assuming continued alignment.

Key takeaways

• Two factors from different categories, genuinely independent, plus dynamic linking.
• Exemptions are requested, not guaranteed — the issuer decides.
• Low fraud rates buy exemption headroom, so fraud performance reduces friction.
• SCA and PCI DSS solve different problems; you need both.