Strong Customer Authentication: What Payment Firms Must Do

Strong Customer Authentication is a technical and operational requirement under the Payment Services Regulations that affects every UK payment firm — and one where the gap between regulatory compliance on paper and genuine security in practice creates both regulatory risk and fraud liability.

Strong Customer Authentication (SCA) requires payment service providers to authenticate transactions using two or more of three specified factors: knowledge (something the customer knows), possession (something the customer has), and inherence (something the customer is). The requirement is set out in the Payment Services Regulations 2017 and the FCA’s supervisory expectations reflect the PSR’s aim of reducing payment fraud while maintaining a viable customer experience.

When SCA Applies

SCA applies to three categories of activity: accessing a payment account remotely (for example, logging in to online banking or a payment app); initiating an electronic payment transaction; and any action carried out through a remote channel that creates a risk of fraud. Within these categories, the SCA requirement applies to transactions initiated by payment service users — customers who are initiating payments — not to merchant-initiated transactions (direct debits, subscription charges) or transactions between accounts held by the same customer at the same payment service provider.

The practical scope is broad. A customer logging into a payment account, transferring money to another account, making an online card payment and topping up a digital wallet all trigger the SCA requirement if carried out through a remote channel. Physical card-present transactions at point of sale are not within the SCA scope under the PSRs, though chip and PIN effectively delivers equivalent authentication.

The Three Authentication Factors

Knowledge — something only the user knows: a password, PIN, passphrase or security question answer. Password-only authentication does not satisfy SCA — it is only one factor. Knowledge factors must be kept confidential by the customer and must not be held in a form that the payment service provider can retrieve and re-use without the customer’s active participation.

Possession — something only the user possesses: a mobile phone (for receiving an OTP via SMS or authenticator app), a hardware token, a smart card or a payment device. The possession factor requires that the authentication generates a unique code or token linked to the specific transaction or session — a physical card number alone does not satisfy this requirement.

Inherence — something the user is: a fingerprint, facial recognition, voice pattern or behavioural biometric. Biometric authentication must be implemented with appropriate security controls — the biometric data itself must not be capable of being extracted and re-used, and the implementation must meet the PSR Technical Standards requirements for error rates and anti-spoofing.

The two factors used must be from different categories — a password plus a PIN (both knowledge) does not satisfy SCA. The combination must also be dynamic: the authentication output must link to the specific transaction amount and payee, not just the session.

SCA Exemptions: The Practical Toolkit

The PSR Technical Standards provide a set of exemptions from SCA — transactions where the payment service provider can authenticate with a single factor (or with no authentication beyond what is normally required) without breaching the SCA requirement. Understanding and correctly applying exemptions is one of the most commercially significant compliance decisions for payment firms, because unnecessary SCA friction reduces conversion rates and damages customer experience.

Low-value transactions. Contactless payments below £100 per transaction and cumulative usage below £300 (or after five consecutive contactless uses) are exempt from SCA. This is the most widely used exemption in consumer payments — the tap-to-pay experience depends on it.

Trusted beneficiaries. Where a customer has added a payee to a list of trusted beneficiaries — by going through SCA for the initial addition — subsequent payments to that payee can be made without SCA. This exemption is applied by the account-servicing PSP (the sender’s bank or payment firm), not the recipient’s firm.

Recurring transactions. For recurring payments to the same payee for the same amount (direct debit equivalents), SCA is only required for the first transaction in the series. Subsequent recurring charges at the same amount to the same payee are exempt as merchant-initiated transactions.

Transaction Risk Analysis (TRA). Where a PSP’s fraud rate for the relevant transaction type is below specified thresholds, it can apply TRA to exempt low-risk transactions from SCA. The exemption thresholds are: fraud rate below 0.13% for transactions up to £100; below 0.06% for transactions up to £250; and below 0.01% for transactions up to £500. PSPs must monitor their fraud rates continuously and stop applying a TRA exemption if their fraud rate breaches the applicable threshold.

Liability for Failed SCA

Where a PSP applies an SCA exemption and a transaction in the exempted category is subsequently found to be fraudulent, the PSP bears the fraud liability — not the customer. This is the critical commercial consideration in exemption strategy: the benefit of improved conversion from applying an exemption must be weighed against the increased fraud liability that follows if the exemption is over-applied.

Conversely, where an account-servicing PSP applies SCA correctly and an unauthorised transaction still occurs — because the fraudster has compromised both authentication factors — the PSP can rely on the SCA compliance as a defence to the customer’s refund claim only where the customer acted fraudulently or with gross negligence. The PSR’s default position is that the PSP bears the loss for unauthorised transactions, even where SCA was applied, unless it can demonstrate the customer’s conduct warrants an exception.

3DS2 and Card Payment SCA

For card-not-present transactions — online purchases — the standard implementation of SCA is through 3D Secure 2 (3DS2), the authentication protocol developed by the card networks to meet PSR requirements. 3DS2 allows the card issuer to apply SCA (or an exemption, with associated liability shift) at the point of online payment. From the merchant’s perspective, implementing 3DS2 through their payment gateway is the practical step required to meet SCA obligations for card-not-present payments.

FCA Supervisory Expectations

The FCA’s supervisory approach to SCA focuses on: whether the firm has implemented SCA for all in-scope transactions; whether exemptions are being applied correctly and within applicable thresholds; whether the firm monitors its fraud rates against TRA exemption thresholds; whether SCA implementation is creating unnecessary friction that damages customer experience; and whether the firm’s incident reporting covers SCA-related fraud events. The FCA has taken action against firms that applied exemptions without adequate fraud monitoring or that claimed SCA compliance without implementing the dynamic linking requirement.

Key References

• Payment Services Regulations 2017
• FCA — Strong customer authentication guidance
• FCA Handbook CONC