Strong Customer Authentication (SCA): Requirements & Examples 2026

Strong Customer Authentication (SCA) is a payment-security requirement that generally uses at least two independent authentication elements. Under the current EU PSD2 framework, those elements come from knowledge, possession and inherence, and remote payments also require dynamic linking to the amount and payee. SCA does not mean every payment must show a challenge. Exemptions and risk-based flows can allow low-risk payments to proceed without an interactive step. 3D Secure 2 is a common way card issuers and merchants support SCA for online card payments, but 3D Secure and SCA are not the same thing. In 2026, PSD2 remains the operative EU baseline while the PSD3/Payment Services Regulation reform continues through the EU legislative process.

Key Takeaways

Strong Customer Authentication (SCA) is a payment-security requirement that generally uses at least two independent authentication elements.

Under the current EU PSD2 framework, those elements come from knowledge, possession and inherence, and remote payments also require dynamic linking to the amount and payee.

SCA does not mean every payment must show a challenge. Exemptions and risk-based flows can allow low-risk payments to proceed without an interactive step.

3D Secure 2 is a common way card issuers and merchants support SCA for online card payments, but 3D Secure and SCA are not the same thing.

In 2026, PSD2 remains the operative EU baseline while the PSD3/Payment Services Regulation reform continues through the EU legislative process.

Strong Customer Authentication (SCA) is a security standard used to verify that the person accessing a payment account or authorising an electronic payment is really entitled to do so. In practical terms, it asks the customer to prove their identity using multiple independent factors rather than relying on a password, card number or other single credential alone.

For consumers, SCA is the reason an online checkout may ask for a banking-app approval, fingerprint, face scan, one-time passcode or another verification step. For banks, payment service providers and merchants, SCA is part of a wider fraud-control framework designed to make stolen credentials less useful to criminals.

In the European Economic Area, the core legal basis comes from the revised Payment Services Directive (PSD2) and the Regulatory Technical Standards on Strong Customer Authentication and secure communication. The United Kingdom has a separate post-Brexit framework under the Payment Services Regulations 2017 and FCA technical standards. The broad security concept is similar, but businesses should not assume every EU threshold or exemption applies identically in the UK.

Strong Customer Authentication Definition

Under PSD2, SCA is authentication based on two or more elements that are independent and fall within defined categories. If one factor is compromised, the reliability of the other factor should not automatically be compromised as well.

The three traditional SCA categories are:

Knowledge - something the customer knows, such as a password, PIN or secret code.
Possession - something the customer has, such as a registered phone, banking app, hardware token or payment device.
Inherence - something the customer is, typically a biometric or other characteristic used to identify the user, such as fingerprint or facial recognition.

A compliant SCA flow normally combines at least two independent elements. For example, a registered banking app can provide a possession factor while a fingerprint provides an inherence factor. A password plus a one-time code delivered to a controlled device may combine knowledge and possession, depending on the implementation and security controls.

SCA vs 2FA vs MFA: What Is the Difference?

SCA is often described as two-factor authentication, but the terms are not interchangeable. Two-factor authentication (2FA) and multi-factor authentication (MFA) are broad cybersecurity concepts. SCA is a regulated payment-authentication standard with additional requirements, including independence of authentication elements and, for remote electronic payment transactions, dynamic linking.

A login can use two factors and still fail to satisfy the full SCA rules if the factors are not sufficiently independent or the payment-specific requirements are missing. Conversely, a payment flow may satisfy SCA with a banking-app approval that combines multiple protected elements behind a single user experience.

Why SCA Exists: Reducing Payment Fraud

Payment fraud often begins with stolen or phished credentials. If a criminal has only a card number, password or account identifier, SCA can create an additional barrier by requiring another factor that the attacker does not control.

The latest joint fraud reporting from the European Central Bank (ECB) and European Banking Authority (EBA) reinforces this point. Their 2025 report found that transactions authenticated with SCA were generally less susceptible to fraud, especially card payments. The report also found that card-payment fraud was substantially higher when the recipient was outside the EEA, where SCA is not legally required in the same way.

However, SCA is not a complete fraud solution. Fraudsters increasingly use social engineering to manipulate legitimate customers into authenticating a fraudulent payment themselves. This is why modern payment security combines SCA with transaction monitoring, device intelligence, behavioural analytics, scam warnings, confirmation-of-payee checks and post-transaction fraud controls.

When Is Strong Customer Authentication Required?

Under the current PSD2 framework, payment service providers generally apply SCA when the payer:

Accesses a payment account online.
Initiates an electronic payment transaction.
Carries out a remote action that may create a risk of payment fraud or other abuse.

These are broad rules. Whether the customer actually sees an SCA challenge depends on the payment type, the parties involved, applicable exemptions and the provider's risk analysis.

Dynamic Linking for Remote Payments

For remote electronic payments, SCA also requires dynamic linking. The authentication code must be tied to the specific transaction amount and the specific payee. If the amount or payee is altered, the authentication should no longer remain valid for the changed transaction.

This helps prevent a criminal from intercepting a valid authentication response and reusing it to approve a different payment. It also explains why banking apps commonly show the merchant or beneficiary and the exact payment amount before the customer confirms.

How SCA Works in an Online Card Payment

A typical online card-payment journey can be simplified into the following steps:

The customer enters card details or chooses a stored card at checkout.
The merchant and payment provider send the transaction through the card-payment ecosystem to the issuing bank.
Risk signals are evaluated. The transaction may qualify for an exemption, proceed through a low-friction authentication flow or require an active challenge.
If a challenge is required, the issuer asks the customer to complete an authentication step, such as approving the payment in a banking app or using a biometric plus a protected device.
The authentication result is returned and the transaction continues to authorisation.

The exact experience differs by issuer, payment provider, device and market. A customer may therefore experience SCA as a visible challenge on one transaction and see no extra step on another transaction even though security checks occurred in the background.

What Is 3D Secure and How Does It Relate to SCA?

3D Secure (3DS) is a card-authentication protocol widely used for e-commerce. Modern versions, commonly referred to as 3D Secure 2 or EMV 3-D Secure, allow merchants, payment providers and issuers to exchange contextual information about the transaction and customer.

3D Secure can support SCA, but it is not identical to SCA. SCA is the regulatory authentication requirement; 3D Secure is one technical framework that can help card payments meet that requirement.

A 3DS transaction may use a frictionless flow when the issuer can make a risk decision without asking the customer to interact. If an SCA challenge is required, the issuer can present an app approval, biometric verification, one-time code or another supported method.

Strong Customer Authentication Examples

The following are common examples of SCA-style authentication flows. Whether a specific implementation is compliant depends on the provider's technical design, factor independence and applicable rules.

Example	Factor combination	How it works
Banking app + fingerprint	Possession + inherence	Customer approves the payment on a registered device and confirms with a biometric.
Hardware token + PIN	Possession + knowledge	Customer uses a physical security device together with a secret PIN.
Registered app + password	Possession + knowledge	A protected registered app/device is combined with a customer-held secret.
Security key + biometric/PIN	Possession + inherence or knowledge	A cryptographic authenticator is unlocked using another protected factor.

Does a One-Time Password (OTP) Automatically Count as SCA?

No. An OTP can be part of an SCA solution, but the code alone is only one authentication element. The overall flow must establish two independent factors and protect the authentication process against compromise. The security of SMS or other delivery channels also matters, which is why many providers increasingly rely on app-based cryptographic approvals and biometrics.

Can Passkeys Be Used for SCA?

Passkeys can be a strong building block for payment authentication because they use public-key cryptography and are resistant to many forms of credential phishing. However, a passkey is not automatically “SCA” simply because it is modern or biometric-enabled. Payment providers must assess how the authenticator proves possession, how user verification is performed, whether the factors are independent, and how transaction-specific requirements such as dynamic linking are satisfied.

SCA Exemptions: When a Payment May Not Need a Challenge

SCA rules include narrowly defined exemptions so that payment security does not create unnecessary friction for every low-risk transaction. An exemption does not mean a payment is unsecured. Providers are expected to apply monitoring and other controls, and the entity requesting an exemption may take on additional fraud or liability considerations.

Common EU PSD2 SCA Exemptions

Low-value remote transactions - certain remote electronic transactions up to EUR 30 may qualify, subject to cumulative-value and consecutive-transaction limits since the last SCA event.
Contactless point-of-sale transactions - individual contactless transactions up to EUR 50 may qualify, with cumulative-value or consecutive-transaction limits before SCA is required again.
Trusted beneficiaries - a customer may place a payee on a trusted-beneficiary list using SCA; later payments to that trusted payee can qualify for an exemption.
Recurring transactions - SCA is normally required when a recurring series with the same amount and payee is created, changed or initiated for the first time; later transactions in the series can qualify for an exemption.
Payments between accounts held by the same person with the same account-servicing provider - these may qualify for an exemption.
Transport and parking at unattended terminals - qualifying transactions can be exempted for practical and safety reasons.
Secure corporate payment processes - certain dedicated business-only payment processes can be exempt where the competent authority accepts that they provide equivalent security.
Transaction Risk Analysis (TRA) - a provider with sufficiently low fraud rates may exempt qualifying remote transactions after real-time risk analysis and within regulatory thresholds.

An important 2026 accuracy point: the EU rules for accessing payment-account information were amended after the original SCA regulation. For direct account access, the relevant re-authentication interval is now generally 180 days rather than the older 90-day figure, subject to the conditions in the consolidated regulatory text.

Transaction Risk Analysis (TRA) Explained

TRA is one of the most important SCA exemptions for digital commerce because it allows a payment service provider to identify a transaction as low risk based on real-time analysis. The provider must meet regulatory fraud-rate conditions and evaluate risk indicators such as unusual spending behaviour, suspicious device or software information, malware signals, known fraud scenarios, abnormal payer location and high-risk payee location.

For merchants, this is why improving data quality can matter. Accurate device, customer, transaction and behavioural information can help an issuer or payment provider distinguish a normal purchase from suspicious activity, potentially reducing unnecessary challenges while maintaining security.

Merchant-Initiated Transactions and SCA

Merchant-initiated transactions (MITs) often cause confusion because they are sometimes discussed alongside SCA exemptions. A genuine MIT is generally initiated by the merchant under a prior customer mandate and without the customer actively participating in that later payment. Depending on the legal and scheme conditions, the later merchant-initiated payment may fall outside the payer-initiated SCA requirement rather than being a conventional SCA exemption.

The initial setup of the mandate or the first customer-initiated transaction may still require authentication. Businesses should also use the correct transaction indicators and keep evidence of the customer agreement. Incorrectly labelling ordinary customer-initiated payments as merchant-initiated can lead to declines, disputes and compliance problems.

Recurring Payments vs Merchant-Initiated Transactions

A fixed recurring payment and an MIT are not always the same thing. A subscription charging the same amount to the same payee may fit the recurring-transaction exemption after the first authenticated transaction. Variable or unscheduled merchant-initiated charges may instead rely on a valid merchant mandate and scheme rules. The correct treatment depends on how the payment is initiated and the agreement with the customer.

What Does “Additional Customer Authentication Required” Mean?

Customers and merchants may encounter messages such as “additional customer authentication required,” “SCA required,” or “authentication needed.” These typically mean that the issuer or payment provider will not approve the transaction until an authentication step is completed, or that the attempted payment flow did not supply the authentication information the issuer expected.

For a customer, the solution is usually to follow the bank's authentication prompt, open the banking app if requested, confirm the transaction details and retry the checkout if necessary. For a merchant, repeated authentication errors can indicate an integration problem, an unsupported 3DS flow, incorrect exemption handling or a payment-provider configuration issue.

Why SCA Challenges Fail

SCA can fail even when the card or account is valid. Common causes include:

The customer does not receive or complete the issuer challenge.
The bank has an outdated phone number or device registration.
A banking app is not activated, is offline or cannot complete biometric verification.
The authentication session expires before completion.
The merchant, gateway or issuer does not correctly handle the required 3D Secure message flow.
An exemption is requested but the issuer declines the exemption and asks for SCA instead.
The transaction appears unusually risky and the issuer rejects it even after authentication.

Merchants should track authentication rates, challenge rates, challenge-completion rates and post-authentication authorisation rates separately. Treating every failure as a generic “card decline” can hide the real source of checkout friction.

SCA and Fraud: What It Stops - and What It Does Not

SCA is particularly useful against fraud based on stolen payment credentials because possessing a card number or password may no longer be enough. But fraud adapts. Modern scams frequently manipulate the legitimate user into approving the transaction, defeating the assumption that “the real customer authenticated, therefore the payment must be safe.”

This is why a strong fraud-prevention programme should combine authentication with:

Real-time transaction monitoring and risk scoring.
Device and session intelligence.
Behavioural analytics and anomaly detection.
Scam and social-engineering warnings presented before authorisation.
Beneficiary verification and suspicious-payee controls where available.
Velocity controls, spend limits and account-takeover detection.
Fast customer support and post-transaction fraud response.

Strong Customer Authentication Requirements for Merchants

A merchant does not normally “perform PSD2 SCA” entirely by itself. SCA involves the payment service provider and issuer, but merchant configuration strongly affects whether the authentication flow works efficiently. A practical merchant checklist includes:

Use a payment provider and gateway that support current 3D Secure authentication flows.
Pass complete and accurate transaction data so issuers have enough context for risk decisions.
Request exemptions only when the transaction genuinely qualifies.
Support issuer step-up requests instead of treating an exemption as guaranteed.
Correctly identify recurring and merchant-initiated transactions.
Optimise the mobile authentication experience and test common app-switching flows.
Measure challenge rates, abandonment, soft declines and authentication errors.
Do not rely on SCA alone; maintain independent fraud controls.

Strong Customer Authentication in the UK

The UK retained SCA requirements after Brexit through the Payment Services Regulations 2017 and the UK regulatory technical standards overseen by the Financial Conduct Authority. The FCA states that SCA rules apply when a payer initiates an electronic payment, accesses a payment account online or performs a remote action that may imply a risk of payment fraud, unless an exemption applies.

The UK framework has evolved separately from EU rules. Businesses operating in both the UK and EEA should therefore maintain jurisdiction-specific compliance guidance rather than copying EU exemption thresholds and re-authentication rules directly into UK processes.

What Is Changing in 2026? PSD3 and the Payment Services Regulation

The EU payment framework is in transition. Parliament and Council reached a provisional political agreement on the proposed Payment Services Regulation (PSR) and the Third Payment Services Directive (PSD3) in November 2025, and the agreed text progressed through the legislative process during 2026. The reform is intended to strengthen fraud prevention, transaction monitoring, consumer protection and payment-service rules.

For publishers and businesses, the safest 2026 position is to distinguish between current law and proposed or agreed future rules. PSD2 and the existing SCA Regulatory Technical Standards remain the practical baseline until the replacement legislation becomes applicable. Compliance teams should monitor the final text, publication, transition periods and new EBA technical standards before changing production controls.

Strong Customer Authentication Best Practices for 2026

The best SCA strategy is not “challenge every transaction.” It is to authenticate strongly when required while giving issuers enough high-quality information to make accurate risk decisions. The following practices support both security and conversion:

Keep 3D Secure integrations current and test issuer challenge flows regularly.
Use clear checkout messaging so customers understand why their bank is asking for verification.
Send complete billing, device, account and transaction context when your payment provider supports it.
Do not over-request exemptions. Issuers can still demand step-up authentication.
Design app and browser journeys to survive redirects, app switching and interrupted sessions.
Track fraud and conversion by SCA outcome rather than only by payment authorisation result.
Review accessibility: customers should have workable authentication options even if they cannot use a smartphone or biometric method.
Train support teams to distinguish authentication failure from ordinary card declines.

Frequently Asked Questions About SCA

What does SCA stand for in payments?

SCA stands for Strong Customer Authentication. It is a payment-security requirement designed to verify the customer using multiple independent authentication elements.

What are the three SCA authentication factors?

The three traditional categories are knowledge (something you know), possession (something you have) and inherence (something you are). A compliant SCA flow generally combines at least two independent elements.

Is SCA the same as 3D Secure?

No. SCA is a regulatory authentication requirement. 3D Secure is a card-authentication protocol that can be used to support SCA for online card payments.

Does every online payment require an SCA challenge?

No. Some transactions can qualify for exemptions or proceed without a visible challenge after risk assessment. An issuer can still request step-up authentication when it considers the transaction risky.

What is dynamic linking in SCA?

Dynamic linking means the authentication is tied to the specific payment amount and payee. Changing either should invalidate the authentication for the original transaction.

Are recurring payments exempt from SCA?

The first transaction or creation/change of a qualifying recurring series generally requires SCA. Later transactions with the same amount and payee may qualify for an exemption under the EU framework.

Can biometrics be used for SCA?

Yes. Biometrics such as fingerprint or facial recognition can serve as an inherence factor when implemented appropriately, but SCA still requires the overall authentication design to satisfy the regulatory rules.

Can SCA stop all payment fraud?

No. SCA is effective against many forms of credential-based fraud, but social engineering can trick legitimate users into authenticating fraudulent payments. Additional fraud controls are still necessary.

Is SCA still relevant in 2026?

Yes. SCA remains central to EU and UK payment security in 2026. The EU is progressing PSD3/PSR reforms, but businesses must continue following the rules that are currently applicable while preparing for future changes.

Conclusion

Strong Customer Authentication is one of the most important changes to modern European payment security. By requiring independent authentication elements and transaction-specific protection for remote payments, SCA makes stolen credentials less useful and helps issuers distinguish legitimate customers from attackers.

For merchants, the goal is not to eliminate authentication. It is to make authentication accurate, secure and as low-friction as possible: use modern 3D Secure support, provide good transaction data, apply exemptions correctly, monitor failures and combine SCA with broader fraud controls.

In 2026, SCA remains a core part of the payment-security landscape. The next EU payment-services framework is moving closer, but the most effective strategy today is to follow the current rules carefully while preparing systems and policies for the coming regulatory transition.

Authoritative Sources & Further Reading

Editorial note: This article is educational and does not constitute legal or regulatory advice. Payment rules vary by jurisdiction, payment method and provider. Verify current requirements with the relevant regulator and payment-service provider before making compliance decisions.