Strong Customer Authentication (SCA): Definition and Use in Compliance

What is Strong Customer Authentication (SCA)?

Strong Customer Authentication (SCA) is a legal requirement that a payer prove identity with two independent factors before an electronic payment or account login goes through. The factors come from three categories: knowledge (something you know, like a PIN), possession (something you have, like a registered phone), and inherence (something you are, like a fingerprint). At least two must be present, and they must be independent. A stolen password alone shouldn't unlock the second factor.

The rule lives in PSD2 and its Regulatory Technical Standards. It covers card payments, bank transfers, and access to online payment accounts inside the European Economic Area and the UK.

Here's a concrete case. A shopper buys a €200 jacket online. The card details alone used to be enough. Under SCA, the issuing bank now sends a push notification to the customer's banking app, where they approve with a fingerprint. Password (knowledge, captured at app login) plus device-bound biometric (possession plus inherence) clears the two-factor bar. If the customer can't complete the step, the payment is declined.

SCA isn't a blanket rule. The standards carve out exemptions so that not every coffee purchase triggers a challenge. Low-value payments, recurring fixed payments, and transactions a bank scores as low risk can skip the step. This balance, security against friction, is the whole design tension. The European Banking Authority drew the lines, and firms operate inside them. Strong authentication pairs naturally with biometric authentication and feeds the wider identity verification stack a bank runs at onboarding and login.

How is Strong Customer Authentication (SCA) used in practice?

In practice, SCA shows up at the moment a customer pays or logs in. The mechanics differ by channel, but the decision logic is similar: does this transaction need a challenge, or does an exemption apply?

For online card payments, banks deliver SCA through 3-D Secure version 2. The merchant's checkout passes transaction and device data to the issuer, the issuer's risk engine scores it, and it either approves silently (frictionless flow) or asks for a challenge (biometric, one-time code, or app approval). Payment teams watch the frictionless-to-challenge ratio closely, because every challenge costs conversion.

Consider a UK acquirer processing 50,000 e-commerce transactions a day. Their fraud team sets the transaction risk analysis exemption to apply when their rolling fraud rate stays under 13 basis points, the threshold that permits exemptions up to €100. If fraud climbs past that band, they lose the exemption and challenge volume jumps. So they monitor fraud basis points daily and adjust merchant-level rules.

SCA also shapes fraud strategy. A strong second factor sharply cuts card-not-present fraud and account takeover. It does little against scams where the customer authenticates the payment themselves, which is why authorized push payment fraud keeps rising even in SCA markets. Teams pair authentication with behavioral analytics to catch the cases authentication misses.

Strong Customer Authentication (SCA) in regulatory context

SCA is regulatory, born from EU law rather than industry preference. The legal source is Commission Delegated Regulation (EU) 2018/389, the Regulatory Technical Standards under PSD2. The European Banking Authority wrote and clarified these standards through repeated opinions and Q&A, because the original text left questions about exemptions, biometric storage, and merchant-initiated transactions.

Enforcement varies by jurisdiction. In the EU, national competent authorities supervise SCA. In the UK, the Financial Conduct Authority onshored the rules after Brexit and ran its own enforcement timeline, with full e-commerce SCA required from 14 March 2022. The European Banking Authority's published standards remain the reference text. You can read the EBA's position directly on its strong customer authentication pages.

A real example of regulatory teeth: the original 14 September 2019 deadline arrived with most of the e-commerce market unprepared. Regulators granted a managed rollout rather than break online retail, which tells you how disruptive a hard cutover would have been.

SCA connects to neighboring rules. It supports the consumer-protection aims that sit alongside PSD2 open banking provisions, and its biometric handling intersects with GDPR, since fingerprints and face data are special-category personal data. Firms processing that data need a lawful basis and tight retention controls. Compliance officers treat SCA as a payments rule with a privacy dimension, not a standalone authentication checkbox. The looming PSD3 proposals are expected to refine, not replace, this framework.

Common challenges and how to address them

The biggest practical problem with SCA is friction. Every challenge is a chance for the customer to abandon the purchase. Industry data after the 2021 rollout showed measurable cart abandonment spikes when challenges fired on transactions customers expected to clear silently. The fix is disciplined exemption management: use transaction risk analysis where your fraud rate permits it, mark trusted beneficiaries, and route low-value payments through the carve-out.

A second challenge is biometric data governance. Storing fingerprints and face templates triggers strict privacy obligations. The answer is on-device biometric matching, where the factor never leaves the customer's phone and the bank receives only a pass or fail signal. This keeps the firm clear of holding raw biometric data and aligns with data minimization principles.

Third, SCA creates a false sense of security against social-engineering fraud. A customer tricked by a romance scam or a business email compromise will sail through authentication, because they believe the payment is genuine. The control verifies identity, not intent. Banks address this by layering transaction monitoring and real-time scam detection on top of authentication, flagging unusual payee patterns even when the factors check out.

Fourth, accessibility. Customers without smartphones or with disabilities can struggle with app-based challenges. Good practice keeps fallback methods, such as hardware tokens or SMS codes, available, while acknowledging SMS is the weakest possession factor. The trade-off here is real: stronger factors exclude some users, weaker factors invite fraud. Firms document the balance they strike.

Related terms and concepts

SCA sits inside a cluster of payments and fraud concepts, and understanding the neighbors sharpens what SCA does and doesn't do.

The closest relative is 3-D Secure, the protocol that actually delivers SCA for online card payments. People sometimes use the two terms loosely, but they're distinct: SCA is the legal requirement, 3-D Secure is one technical method of meeting it. SCA lives within the broader PSD2 framework, which also governs open banking access and payment initiation.

On the fraud side, SCA is a control against card-not-present fraud and account takeover, but it leaves authorized push payment fraud largely untouched. That gap is why authentication alone never makes a complete strategy.

The factor types link to identity tooling. Inherence factors rely on biometric authentication and increasingly liveness detection to defend against deepfake fraud and presentation attacks. The whole approach belongs to the same family as identity verification at onboarding.

On the privacy axis, handling biometric factors pulls in GDPR obligations and personally identifiable information controls. And measuring whether SCA is working means watching authorization rate and chargeback rate together, since a control that blocks fraud but tanks approvals isn't a win. Teams reviewing payment security often start with payment gateway security as the surrounding discipline.