What Strong Customer Authentication Requires

Most explanations of Strong Customer Authentication stop at "two-factor authentication for payments." That is close enough to be misleading, because it omits the part that makes SCA different from logging into an email account.

Three categories, two elements, independent

The requirement comes from the EU's revised Payment Services Directive, Directive (EU) 2015/2366, which defines strong customer authentication as authentication based on two or more elements drawn from these categories:

• Knowledge — something only the user knows
• Possession — something only the user possesses
• Inherence — something the user is

Two elements, from different categories. A password and a security question are both knowledge, so they are one factor presented twice.

The categories must also be independent: breaching one must not compromise the others. This is why a one-time code delivered to the same device where the payment is being approved raises questions — if the device is compromised, both elements fall together, and the independence the rule demands is notional rather than real.

Dynamic linking is the part that matters

This is what separates SCA from generic two-factor authentication.

For remote payments, the authentication must be dynamically linked to the specific transaction: tied to that amount and that payee, such that any change to either invalidates the authentication.

The reason is an attack ordinary 2FA does not address. If authentication merely proves a user is present and consenting to something, an attacker who can intercept or relay that approval can apply it to a different payment. Dynamic linking binds the approval to its content — approve €40 to this merchant, and the approval is worthless for €4,000 to another.

Put simply: 2FA proves who. Dynamic linking proves what. SCA requires both.

It is also why compliant flows display the amount and payee at the moment of approval. That display is not a courtesy; it is the user seeing what the cryptographic binding covers.

Exemptions, and why they are not loopholes

Authenticating every transaction would impose friction wildly disproportionate to the risk on a small contactless purchase. The framework therefore defines exemptions — categories including low-value payments, certain recurring transactions, and payments a provider's risk analysis assesses as low risk.

The important structural point: an exemption is a permission to skip authentication on defined conditions, not an exception to the liability framework.

Applying one generally moves fraud liability toward the party that chose to skip. That converts exemption strategy from a compliance question into a commercial one: every exemption trades a measure of fraud exposure for a measure of conversion. Firms that lean hard on exemptions are buying checkout completion with fraud losses, which can be entirely rational and should at least be deliberate.

Why it changed checkout design

Before SCA, authentication was something bolted onto a payment flow when risk seemed elevated. After, it became a default with exceptions — and the exceptions had to be justified per transaction.

That inverted the design problem. The question stopped being "when should we challenge?" and became "can we justify not challenging, and do we want the liability if we cannot?"

It also made authentication quality commercially visible. A provider whose challenge flows fail on older devices, or time out, or bounce users out of a payment app, loses sales in a way that is measurable. Authentication UX became a revenue concern rather than a security checkbox.

What it does not solve

SCA addresses unauthorised transactions — someone else using your credentials. It does very little about authorised fraud, where the legitimate customer is deceived into approving a payment themselves.

In that scenario every control performs correctly. Two independent elements, dynamic linking to the right amount and the right payee, cryptographic proof of consent. The payment is genuinely authorised. The customer was lied to about who they were paying.

This is the same structural gap that irrevocable payment rails expose, discussed in our comparison of instant payments and ACH: a control that verifies authorisation cannot distinguish a deceived authoriser from a willing one. Authentication rules and reversal rights address different halves of the problem, and neither covers both.

The practical checks

For anyone assessing an implementation:

• Are the two elements genuinely from different categories, and genuinely independent?
• Is the authentication dynamically linked, and is the amount and payee shown at approval?
• Which exemptions are being applied, how often, and who carries the resulting liability?
• What happens to users whose devices cannot support the inherence or possession element?

That last one is the accessibility question, and it is the one most likely to be discovered after launch.

The definition and categories described here are taken from the text of Directive (EU) 2015/2366 as published on EUR-Lex, read on 1 October 2026. Implementing technical standards and national rules add detail this piece does not cover, and requirements differ outside the EU. This is a description of the framework, not compliance advice.