Strong customer authentication: two factors, and the list of exceptions

Authentication has to use two elements from two of three categories, and the elements must be independent, so that breaking one does not compromise the other. Knowledge is something only the customer knows: a password, a PIN. Possession is something only the customer has: a phone with a registered app, a card reader, a hardware token. Inherence is something the customer is: a fingerprint, a face, a voice.

Two passwords are not SCA. A card number and a CVV are not SCA either, because the card number is on the card and the CVV is printed beside it, so neither is independent of the other. A phone app that both receives the push and holds the biometric check counts, because the possession element is the registered device and the inherence element is the fingerprint on it. That combination is why banking apps replaced card readers.

Low value: a remote transaction under 30 euros may skip the check, until the cardholder has made five such transactions or reached 100 euros cumulatively since the last authentication, at which point the issuer requires SCA again. Transaction risk analysis, the TRA exemption, lets the provider run a real-time risk assessment and skip the check, but only while its own fraud rate stays below a threshold tied to the amount: below 0.13 percent for exemptions up to 100 euros, below 0.06 percent up to 250 euros, below 0.01 percent up to 500 euros.

Trusted beneficiaries lets a customer whitelist a merchant at their own bank, after which only the first payment is challenged, and few issuers ever implemented it. Contactless at a terminal is exempt up to a per-transaction limit with cumulative caps. Secure corporate payments cover dedicated corporate processes where there is no individual cardholder to authenticate. Merchant-initiated transactions, including a subscription charged to a stored card, sit outside the scope entirely, provided the card was authenticated when it was stored and the customer agreed to later charges.

A merchant or its provider flags an exemption in the authorization request; the issuer decides whether to accept it. That split is the part that surprises people. A merchant can request the TRA exemption on every eligible transaction and still get challenged, because the issuer runs its own risk model and may not agree.

When the issuer disagrees it usually returns a soft decline, which is a refusal that means "authenticate and come back". A checkout that treats a soft decline as a failed payment loses the sale outright, so the integration has to catch the code and route the customer into a challenge instead, as PCI Proxy sets out. The same source describes stacking the exemptions in a cascade, checking trusted beneficiary first, then low value, then TRA, instead of picking one and hoping.

SCA is the rule; 3-D Secure is the mechanism that performs it on a card. In the 3-D Secure 2 flow the merchant sends the issuer a rich set of data about the transaction, the device and the customer's history, and the issuer decides between two paths. A frictionless flow approves the authentication from that data alone and the customer notices nothing. A challenge flow puts the customer in front of their bank's authentication, usually a push to the banking app.

The quality of the data decides which path you get, which makes 3-D Secure 2 a data-submission discipline and not a checkbox. There is also a data-only variant some schemes support, which sends the authentication data to the network without requesting authentication from the issuer: it can improve approval rates on transactions outside SCA scope, and it provides no liability shift because no authentication was requested.

Every extra step between the buy button and the confirmation loses some buyers, and a challenge is an extra step. That is the whole reason the exemption list exists and the reason merchants invest in it. A well-run exemption strategy keeps most low-risk traffic frictionless and reserves the challenge for transactions that actually look risky.

The counterweight is fraud, and the counterweight has teeth. A provider that leans on the TRA exemption and lets its fraud rate drift above the threshold loses the exemption for the whole portfolio, not for the bad transactions. Any merchant optimizing authorization rates on a German checkout is managing that trade-off, and card payments in Germany covers what the rest of the stack costs.

The default under PSD2 is that an authenticated payment moves the fraud liability to the payer's bank, and an unauthenticated one leaves it with whoever chose to skip the check. Where the merchant requested the exemption, the merchant carries the fraud. Where the issuer granted the exemption on its own initiative, or refused an authentication the merchant asked for, the issuer carries it.

Two cases catch people out. A merchant-initiated transaction has no liability shift, because nobody authenticated anyone at that moment. A data-only flow has none either. So a subscription business charging stored cards is carrying its own fraud on every renewal, which is one reason the account-based alternatives on account-to-account payments and variable recurring payments get a serious look.

The package keeps SCA and adjusts it around the edges that caused complaints. The direction is to stop treating authentication as a card problem: the rules gain an explicit accessibility duty, so a bank may not make its only authentication method one that a customer without a smartphone or with a disability cannot use, and the exemption framework is expected to be clarified where practice diverged from the text.

The PSR also connects authentication to the fraud regime, which earlier texts kept in separate boxes, with the payee name check from verification of payee and a refund right for impersonation scams described on APP fraud. The provisional political agreement came in November 2025 and application is expected around 2028, so the RTS as they stand today remain the operating rules for some time.

Strong customer authentication is a PSD2 requirement that an electronic payment be authenticated with two independent elements from two of three categories: knowledge, possession and inherence. The Regulatory Technical Standards set the detail and list the exemptions, and on a card payment the check is normally performed through 3-D Secure 2.

The main ones are low value under 30 euros with a five-transaction and 100-euro cumulative cap, transaction risk analysis up to 100, 250 or 500 euros depending on the provider's fraud rate, trusted beneficiaries whitelisted by the customer, contactless at a terminal, and secure corporate payments. Merchant-initiated transactions and mail or telephone orders fall outside the scope, as do transactions where one party is outside the EEA.

Not to the recurring charge, if it is set up correctly. The card has to be authenticated with SCA when it is stored and the customer has to agree to later charges, after which each renewal can be flagged as a merchant-initiated transaction outside SCA scope. The trade is that a merchant-initiated transaction carries no liability shift, so the merchant bears the fraud on those payments.