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.

The control sits in the payment authorization layer. It's the mechanism that stops an attacker holding stolen credentials from completing a transaction, because credentials alone don't satisfy the two-factor requirement. It triggers at three points: online account access, electronic payment initiation, and any action carrying material fraud risk.

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 transactions under €30, trusted beneficiaries, recurring fixed payments, corporate payment protocols, and transaction risk analysis (TRA) for low-risk remote payments. Each exemption carries its own conditions and its own liability implications. A PSP that misapplies an exemption and suffers a fraud loss cannot point to the exemption as a defense. 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. Beyond the EEA, NIST Digital Identity Guidelines SP 800-63B sets equivalent authenticator assurance levels for US federal systems and is widely treated as the technical benchmark by US financial institutions, even absent a direct PSD2 obligation.

---

Strong Customer Authentication (SCA) in regulatory context

SCA is regulatory, born from EU law rather than industry preference, and it starts from a concrete data point: card-not-present fraud across the EEA reached €1.49 billion in 2020, according to the ECB's 8th Card Fraud Report. SCA was designed to cut that number by making stolen card credentials insufficient to complete a payment.

PSD2 Article 97 establishes the legal obligation across EEA member states. Commission Delegated Regulation (EU) 2018/389, the EBA's RTS on SCA, provides the technical blueprint: factor independence, dynamic linking to payee and amount, exemption thresholds, and fraud rate monitoring requirements. The EBA wrote and clarified these standards through repeated opinions and Q&A, including EBA Opinion EBA/OP/2019/07 and subsequent supervisory convergence reports, 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, SCA was retained post-Brexit under the Payment Services Regulations 2017, with the Financial Conduct Authority setting migration timelines and supervisory expectations in Policy Statement PS19/26 and requiring full e-commerce SCA from 14 March 2022. 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 also connects directly to AML obligations. FATF Recommendation 10 requires adequate customer due diligence before and during a business relationship. Weak authentication is one of the fastest ways past those controls, because it lets fraudsters and money mule networks operate through compromised legitimate accounts without triggering identity-based alerts.

Authorized push payment fraud is where SCA failure is most visible as a loss event. APP fraud manipulates customers into authorizing payments themselves, technically passing SCA, but weak device-binding or out-of-app authentication channels create the attack surface that social engineering exploits. In the UK, the Payment Systems Regulator's mandatory APP reimbursement scheme, effective from October 2023, made this financial directly: PSPs with poor SCA implementation now face both supervisory action and mandatory reimbursement liability on APP fraud losses.

SCA connects to neighboring rules as well. 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.

---

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.

---

What do regulators expect to see?

"SCA is live and working" is not an answer on exam day. Supervisors from the FCA, BaFin, or DNB want documented evidence that the control is genuinely in place, properly calibrated, and actively managed. Here is what they look for.

Policy and procedure documentation. A written SCA policy covering scope, trigger events, exemption criteria, exemption monitoring, and escalation. The policy needs a named owner, an approval history showing senior sign-off, and a review date within the past 12 months. Policies that haven't been updated since PSD2 implementation in 2019 are an immediate red flag.

Exemption management records. Transaction-level logs showing which exemption was applied to each non-SCA transaction, the basis for it, and the outcome. EBA guidance is explicit: PSPs applying TRA must monitor fraud rates per payment category and must withdraw the exemption if their rate exceeds the relevant RTS threshold. Aggregate-level fraud rates do not satisfy this requirement.

Authentication failure and fraud correlation data. Examiners want to see a live link between authentication failure events and confirmed fraud. If this data sits in separate systems with no analytical bridge, that is a finding, not just a gap.

Testing and assurance records. Evidence that authentication flows have been tested end-to-end, that testing covers edge cases (device changes, SIM swaps, session hijacking vectors), and that results have been reviewed by a second-line function with the authority to require remediation.

Governance trail. Board-level or senior management reporting on SCA performance. The operational dashboard is not enough. In regulated PSPs, the board risk committee should be able to articulate the firm's exemption strategy and its current fraud rate position against RTS thresholds.

Third-party and API channel coverage. Open banking introduces additional SCA touchpoints. Regulators expect the same controls applied to third-party provider (TPP)-initiated payments as to direct customer transactions. Many firms passed direct-channel SCA reviews and then failed on TPP coverage.

---

What does good Strong Customer Authentication look like?

Good SCA practice goes beyond compliance minimum. The EBA's 2021 supervisory convergence report identified that many PSPs had implemented SCA technically but ran exemption strategies that eroded the protection in practice. A well-run SCA programme treats the control as a fraud-reduction tool, not a box to check.

In practice, these are the indicators of a mature programme:

1. Authentication factors are genuinely independent. Knowledge, possession, and inherence elements are delivered through separate channels. A one-time password sent to the same device that initiated the transaction is technically non-compliant under RTS Article 9.
2. Dynamic linking is correct. For payment initiation, RTS Article 5 requires the authentication code to be cryptographically linked to the specific payee and specific amount. Codes valid for any transaction of any value are non-compliant, regardless of how the authentication channel is structured.
3. Exemptions are earned, not assumed. The TRA exemption requires real-time fraud rate monitoring per payment category against the RTS thresholds. PSPs that apply TRA but monitor only blended fraud rates are using an exemption they cannot prove they are entitled to.
4. Step-up authentication is triggered intelligently. When a session or device shows anomalous behaviour (new device, unusual location, velocity spike), the system escalates to a higher authentication factor automatically. Manual intervention should not be required.
5. Fallback handling is documented. When SCA is unavailable or fails, there is a defined, documented process. Uncontrolled fallback to password-only authentication is one of the most common exam findings.
6. SCA covers access events, not just payments. Accessing sensitive account data (statements, beneficiary lists, standing orders) triggers SCA, not just payment initiation.
7. Monitoring is continuous and granular. Fraud rates per payment type, exemption usage rates by category, and authentication failure rates by channel are reviewed at least monthly by the risk function, not just at year-end.

The EBA's RTS on SCA and NIST SP 800-63B are the primary reference documents for implementation standards at EEA and US institutions respectively.

---

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.

---

Common audit findings and exam citations

Real enforcement tells you where SCA programmes actually fail.

The FCA's 2022 multi-firm review on SCA implementation found that a material number of UK PSPs were applying exemptions without maintaining the transaction-level fraud data needed to justify them. Inadequate TRA monitoring was the single most common gap: firms couldn't demonstrate their fraud rates were below RTS thresholds because they weren't tracking them at the required payment-category granularity.

Five categories account for most findings:

Exemption misapplication. PSPs applying TRA, trusted beneficiary, or low-value transaction exemptions without meeting the underlying conditions. The €30 cumulative limit (five consecutive low-value exemptions, or a cumulative total of €100) is frequently miscounted in production systems.

Dynamic linking failures. Authentication codes not cryptographically bound to the specific payee and amount, meaning a code intercepted mid-session could be replayed against a different transaction entirely.

Channel and device independence failures. SCA flowing through the same device and application used to initiate the transaction. This directly violates the independence requirement of RTS Article 9, and it is more common in mobile banking apps than regulators have found comfortable.

Documentation gaps. No written SCA policy, or a policy that predates current EBA guidance and has never been updated. This is the finding that turns a technical control gap into a broader governance finding with senior management implications.

Open banking blind spots. Firms with functioning direct-channel SCA but no equivalent controls for TPP-initiated transactions. The Authorized Push Payment Fraud typology exploits exactly this gap: social engineering directs victims to payment interfaces that bypass standard SCA prompts.

The broader lesson from the Danske Bank 2018 enforcement action applies here: weak identity controls at onboarding compound into transaction-level failures. SCA gaps don't exist in isolation. They tend to sit alongside weak customer due diligence and insufficient transaction monitoring.

---

Metrics and KPIs

If your SCA reporting consists of "the control is live", that is not sufficient for a second-line review or an external exam. A well-run programme produces specific, measurable numbers reviewed on a defined schedule.

Authentication success rate. The percentage of SCA challenges completed successfully on the first attempt. Industry data from the EBA's fraud reports suggests mature implementations achieve rates above 90% for step-up authentication. Rates below 85% indicate friction that will drive workarounds or excessive exemption usage.

Exemption rate by payment type. What percentage of in-scope transactions are processed under each exemption category. A TRA exemption rate above 30-40% warrants scrutiny: are fraud rates genuinely within threshold, or is the exemption compensating for poor UX?

Fraud rate per payment category. The RTS sets hard thresholds for TRA: 0.13% for transactions up to €250, 0.06% for transactions up to €500, and 0.01% for transactions up to €1,000. Track these per payment type, not blended. A blended rate below threshold can hide a category-level breach.

Authentication failure rate by channel. Distinct from success rate: how often does SCA fail outright, triggering a fallback? High failure rates on specific channels (SMS OTP, in-app biometric) point to reliability issues that need remediation, not just monitoring.

Exemption-to-fraud rate. How often does a transaction processed under exemption subsequently result in confirmed fraud? This tells you whether your exemption logic is calibrated correctly or whether your exemption usage is creating the attack surface.

Time to revoke a compromised authenticator. How quickly a compromised SIM or device can be revoked from the authentication stack. Regulators expect this to be measurable in minutes.

Review these metrics monthly at operational level, quarterly at the risk committee, and annually at board level. Three years of trend data is the minimum for exam readiness.

---

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 most direct operational connection is with transaction monitoring. SCA controls the authentication gate; transaction monitoring watches what happens after the gate is open. A customer who passes SCA and then makes an unusual payment still needs to be caught downstream. These two controls should share data: authentication events, device fingerprints, exemption history, and session anomalies should all feed monitoring signals rather than sitting in separate systems.

Customer due diligence is the upstream dependency. SCA assumes you know who owns the account. If CDD is weak at onboarding, SCA is authenticating an identity that was fraudulently established. The two controls have to work together, a point the Danske Bank 2018 enforcement action illustrated at scale. Sanctions screening intersects at account opening and at real-time payment authorization: SCA confirms the payer is who they claim to be, sanctions screening confirms the payee is not on a designated list.

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.

From a typology perspective, the two highest-priority connections are authorized push payment fraud and smurfing and structuring. APP fraud happens after SCA passes, because the customer was manipulated into authorizing the payment. In smurfing, multiple accounts each need to pass SCA to operate, making strong authentication part of the barrier alongside velocity rules and network analysis.

On the privacy axis, handling biometric factors pulls in GDPR obligations and personally identifiable information controls. 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, and zero trust security provides the broader framework: continuous verification principles that extend beyond the initial authentication event to cover every privileged action within a session.

---

How FluxForce supports Strong Customer Authentication

FluxForce AI agents monitor authentication events in real time. They detect anomalous patterns like SIM-swap signals, device fingerprint mismatches, and high-velocity authentication failures before any transaction authorisation decision is made. Nova Sentinel applies continuous behavioural verification across payment sessions and produces tamper-proof audit trails that satisfy EBA documentation requirements. Exemption usage, fraud rate thresholds by payment category, and authentication failure trends appear in structured dashboards ready for second-line review and external examination. Book a demo to see how FluxForce maps to your SCA programme.