Strong Customer Authentication: What It Is, What Regulators Expect, and What Gets You Cited

What is Strong Customer Authentication?

Strong Customer Authentication (SCA) is a payment security requirement that obliges payment service providers (PSPs) to verify payers using at least two independent factors drawn from three defined categories: something the user knows (knowledge), something the user has (possession), and something the user is (inherence). The two factors must be independent, meaning that a breach of one cannot compromise the other.

PSD2 Article 97 establishes the legal obligation across EEA member states. The EBA's Delegated Regulation 2018/389, commonly called the RTS on SCA, defines the technical standards: how factors must be independent, what dynamic linking requires, and the conditions under which PSPs can apply exemptions. In the UK, SCA was retained post-Brexit under the Payment Services Regulations 2017 (PSR 2017), with the FCA setting migration timelines and supervisory expectations in Policy Statement PS19/26.

The control sits in the payment authorisation 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. SCA triggers at three points: online account access, electronic payment initiation, and any action carrying material fraud risk.

Exemptions exist: low-value transactions under €30, trusted beneficiaries, 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 defence.

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.

Why is Strong Customer Authentication required?

The regulatory case for SCA starts with 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 is the primary legal basis. 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. EBA Opinion EBA/OP/2019/07 and subsequent supervisory convergence reports clarified how national competent authorities should enforce these standards and where supervisory divergence was acceptable.

SCA also connects directly to AML obligations. FATF Rec 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 authorising 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, which took effect in October 2023, made this financial directly. PSPs with poor SCA implementation now face both supervisory action and mandatory reimbursement liability on APP fraud losses.

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 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.

How Strong Customer Authentication connects to other controls

SCA is one layer in a connected stack of controls, and its gaps are amplified when adjacent controls are also weak.

The most direct 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 transaction monitoring signals, not sit 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 authorisation. SCA confirms the payer is who they claim to be; sanctions screening confirms the payee is not on a designated list.

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 authorising 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.

Zero Trust Security Solutions provide 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.