SCA
Strong Customer Authentication
SCA (Strong Customer Authentication) is a PSD2 requirement in the European Economic Area and the UK: a payment must be confirmed with at least two independent factors from three categories: knowledge, possession, and inherence.
What is SCA (Strong Customer Authentication)?
## Core requirement
SCA was introduced by the PSD2 directive for payment services in the European Economic Area and the UK. It requires that initiating an electronic payment or access to a payment account be confirmed with at least two factors from three categories: knowledge (password, PIN, code), possession (phone, card, token, bank app), and inherence (fingerprint, facial recognition). The factors must be independent, meaning that compromising one must not expose another.
## How it works in practice
For online card payments, the issuer usually requests confirmation via the 3-D Secure 2.x protocol: a one-time code by SMS or push notification in the banking app, biometrics, or confirmation in the app. For remote payments, dynamic linking is also required: the confirmation code must be tied to a specific amount and payee, otherwise an intercepted code could be used for a different transaction.
## Exemptions
PSD2 and RTS provide for exemptions: low-value transactions (under RTS, up to 30 euros per transaction with cumulative limits), transaction risk analysis (TRA) for low-risk operations, recurring payments to the same payee after the first SCA, merchant-initiated transactions (MIT), and payments made through dedicated corporate protocols. The decision to apply an exemption is usually made by the issuer and is not guaranteed.
## Impact on conversion and declines
Introducing SCA increases the share of confirmation steps, which lowers conversion in payment flows. A common mistake is assuming it is enough to pass the 3DS flag to the provider: if the challenge fails, the issuer returns a decline that appears in reporting as a bank decline. For high-risk merchants, it is important to track the challenge rate, declines after SCA, and conversion separately by country and issuer.
## Common mistakes
Typical mistakes include sending SMS codes without linking them to the amount, storing customer data to bypass SCA instead of implementing it correctly, and ignoring requirements for stored cards (card-on-file) and subscriptions, where SCA is needed for the first payment and when payment parameters change. Rules depend on jurisdiction and the specific issuer, so they should be checked against the current documentation of the payment provider and the bank.
FAQ
What is SCA in simple terms?
SCA is a rule that requires two different types of verification out of three to confirm a payment: something you know, something you have, or something you are. The goal is to reduce fraud involving stolen card data.
Does SCA apply in all countries?
No. The requirement applies in the EEA and the UK under PSD2 and local rules. Other jurisdictions may use their own authentication mechanisms, so the rules depend on the country of the issuer and the acquirer.
How is SCA different from 3-D Secure?
SCA is a legal requirement, while 3-D Secure is one of the protocols usually used to implement it for online card payments. SCA can be performed in other ways, but in practice 3DS 2.x remains the main tool.