Introduction
Strong Customer Authentication, commonly shortened to SCA, is a European payment-security requirement designed to reduce fraud by requiring stronger proof of a customer's identity for many electronic payments and account-access actions.
Under the EU's revised Payment Services Directive, PSD2, payment service providers are generally required to apply SCA when a payer accesses a payment account online, initiates an electronic payment transaction, or carries out certain remote actions that may involve a risk of payment fraud or abuse.
SCA is commonly described as a form of multi-factor authentication because it normally requires at least two independent authentication elements drawn from separate categories: something the customer knows, something the customer possesses, and something the customer is.
For online card payments, EMV 3-D Secure can help payment providers meet SCA requirements while allowing low-risk transactions to be handled with less friction when applicable rules and exemptions permit.
This guide explains SCA from a defensive payment-security perspective, including what the factors mean, when SCA applies, common exemptions, how 3DS fits in, and why SCA does not guarantee that every payment will be authorized.
Quick Answer: What Is Strong Customer Authentication?
Strong Customer Authentication is an authentication requirement under PSD2 intended to strengthen the security of electronic payments and online access to payment accounts.
PSD2 defines strong customer authentication as authentication based on the use of two or more elements categorized as knowledge, possession, and inherence. The elements must be independent so that compromise of one does not compromise the reliability of the others.
The European Commission states that the SCA requirement began applying from 14 September 2019 and was introduced to make online payments safer and help fight fraud.
For remote electronic payments, SCA also includes requirements designed to link the authentication to the specific transaction amount and payee.
What Does SCA Stand For?
SCA stands for Strong Customer Authentication.
It is a regulatory concept rather than the name of one specific app, password, or payment technology.
Banks and payment providers can implement SCA using different authentication methods as long as the method satisfies the legal and technical requirements applicable to the transaction.
This is why one bank may use a mobile-app approval while another uses biometrics, a hardware device, or another compliant combination of factors.
Where Does SCA Come From?
SCA is a core security requirement of Directive (EU) 2015/2366, commonly known as PSD2.
PSD2 was designed to improve competition, innovation, consumer protection, and security across the European payments market.
The detailed technical requirements are supplemented by Commission Delegated Regulation (EU) 2018/389, commonly called the Regulatory Technical Standards, or RTS, on Strong Customer Authentication and secure communication.
The RTS sets out requirements for authentication elements, dynamic linking, transaction monitoring, exemptions, and secure communication between payment-service providers.
When Did SCA Take Effect?
The European Commission states that the SCA requirement under PSD2 came into force on 14 September 2019.
Implementation for some payment sectors and countries involved supervisory transition periods, particularly for e-commerce, but the legal framework itself is rooted in PSD2 and the related RTS.
Merchants should follow current processor, acquirer, and national-regulator guidance because operational enforcement and regional payment rules can differ.
As of August 2026, PSD2 and its SCA framework remain the relevant existing legal foundation while the EU's proposed PSD3 and Payment Services Regulation are moving through the final stages of the legislative process.
When Is SCA Generally Required?
PSD2 Article 97 requires payment service providers to apply Strong Customer Authentication when the payer accesses a payment account online, initiates an electronic payment transaction, or performs an action through a remote channel that may imply a risk of payment fraud or other abuse.
For merchants, the most familiar case is an online card payment initiated by a customer.
However, SCA is broader than card payments. It can also apply to online banking, payment initiation, and other electronic-payment activities depending on the service and circumstances.
Whether SCA must be performed for a particular transaction can depend on the transaction type, location of the payment providers, applicable exemptions, and other regulatory conditions.
The Three SCA Factor Categories
SCA is built around three categories of authentication factors.
Knowledge means something only the customer knows, such as a password or PIN.
Possession means something only the customer possesses, such as a registered mobile device, payment card, hardware token, or secure authenticator.
Inherence means something the customer is, generally referring to biometric characteristics such as fingerprint or facial recognition.
A compliant SCA event generally requires at least two independent elements from different categories.
Knowledge: Something You Know
Knowledge factors are secrets the customer is expected to know.
Examples can include a password, passcode, or PIN where the implementation meets applicable security requirements.
A simple piece of personal information that can easily be discovered or copied should not automatically be assumed to provide strong authentication.
The quality of the implementation matters because reusable knowledge factors can be vulnerable to phishing, credential stuffing, or social engineering.
Possession: Something You Have
Possession factors establish that the customer controls a particular device, card, token, or other authenticator.
Examples can include a registered banking application, hardware token, payment card used with appropriate security, or another cryptographically bound device.
Possession should be demonstrated securely rather than merely inferred from knowing information printed on a card.
Modern mobile-banking authentication commonly uses device binding and cryptographic credentials to provide stronger evidence of possession.
Inherence: Something You Are
Inherence refers to biometric or behavioral characteristics associated with the customer.
Examples commonly include fingerprint recognition and facial recognition.
Biometric data should be protected carefully because, unlike a password, a physical characteristic cannot simply be replaced in the same way after compromise.
The regulatory concept is not that every SCA payment must use biometrics, but that biometrics can provide one of the permitted authentication-factor categories.
Why the Factors Must Be Independent
PSD2 requires the authentication elements to be independent.
The purpose is to prevent the compromise of one factor from automatically compromising the other.
For example, storing two supposed authentication factors in the same insecure place could undermine the intended security benefit.
Strong authentication depends not only on counting factors but also on separating and protecting them appropriately.
SCA vs Ordinary Two-Factor Authentication
SCA and ordinary two-factor authentication are closely related but not perfectly interchangeable terms.
Two-factor authentication generally means using two different forms of verification.
SCA is a specific regulatory standard with additional requirements concerning independence, protection of authentication data, and, for remote electronic payments, dynamic linking to the amount and payee.
A system that casually calls itself '2FA' is not automatically proof that it satisfies all PSD2 SCA requirements.
What Is Dynamic Linking?
For remote electronic payment transactions, PSD2 requires Strong Customer Authentication to include elements that dynamically link the authentication to a specific amount and a specific payee.
The aim is to help ensure that authentication for one transaction cannot simply be reused to authorize a materially different payment.
The customer should be made aware of the transaction amount and payee during authentication, and any change to those details should invalidate the authentication code or result where the regulatory requirements apply.
Dynamic linking is one reason modern payment authentication is more than simply entering a generic login password.
Why Dynamic Linking Matters
Without transaction-specific linking, a customer could potentially authenticate one action while an attacker attempts to substitute a different payment.
Dynamic linking reduces that risk by binding authentication to the transaction being approved.
For consumers, this is why it is important to read authentication prompts carefully and verify the merchant or payee and amount before approving.
If the displayed payment details do not match the intended purchase, the customer should reject the authentication request and contact the issuer through an official channel.
SCA and Online Card Payments
For e-commerce card payments in the European Economic Area, SCA often affects how the issuer authenticates the customer.
The merchant or payment provider can initiate an EMV 3-D Secure authentication flow so that the issuer receives transaction context and can perform the required customer authentication.
Depending on the transaction and applicable rules, the customer may experience a frictionless flow, a challenge, or an exemption-related outcome.
SCA does not require that every payment display an OTP screen.
How EMV 3-D Secure Supports SCA
EMVCo states that EMV 3-D Secure can be used by the European payments community to meet PSD2 Strong Customer Authentication requirements.
EMV 3DS provides a framework for exchanging transaction information between merchants and issuers and supports both frictionless and challenged authentication.
It can also support two-factor authentication methods and help payment participants apply exemptions provided under the Regulatory Technical Standards.
EMVCo notes that EMV 3DS version 2.0 and later can support SCA, while newer versions provide broader functionality for exemptions and modern authentication flows.
Does SCA Always Mean 3-D Secure?
No.
SCA is the regulatory requirement. 3-D Secure is one technology commonly used to meet that requirement for online card payments.
Other payment channels can use different authentication technologies.
For example, a banking application could use device possession plus biometrics for a bank transfer without necessarily involving a card-network 3DS transaction.
The correct distinction is: SCA defines the security requirement, while technologies such as EMV 3DS provide ways to implement compliant authentication in particular payment environments.
Does SCA Always Require an OTP?
No.
An OTP can contribute to authentication, but SCA does not mandate one universal OTP method.
Modern authentication can use combinations such as a registered device plus biometrics, a banking app plus a passcode, or other compliant factors.
EMV 3DS also supports frictionless authentication in situations where regulatory conditions permit an exemption or where the issuer can otherwise authenticate without showing a traditional OTP screen.
The appearance of an OTP should therefore not be used as the sole indicator of whether a payment was handled securely.
What Is an SCA Challenge?
A challenge is a visible step-up authentication request used when stronger customer verification is needed.
It can involve a banking-app approval, biometric verification, passcode, OTP, or another secure issuer-supported method.
The challenge should clearly relate to the transaction being authenticated.
Consumers should never provide authentication codes to someone who contacts them through an unrelated message or call, because legitimate SCA is performed through the bank or payment authentication flow.
What Is Frictionless Authentication Under SCA?
Frictionless authentication means the customer does not need to complete an additional visible challenge during the payment experience.
In EMV 3DS, the issuer can evaluate transaction and risk information to determine whether a challenge is necessary.
In regulated SCA environments, whether a frictionless experience is permitted depends on the applicable authentication method, transaction flow, and any relevant exemption.
Frictionless does not mean that the merchant has found a way around security. It can be a legitimate outcome of modern risk-based authentication.
What Are SCA Exemptions?
The PSD2 Regulatory Technical Standards permit payment service providers not to apply SCA in certain defined circumstances.
These exemptions exist because requiring the same level of visible authentication for every low-risk transaction could create unnecessary friction without proportionate security benefit.
Commonly discussed exemptions include certain low-value transactions, low-risk transactions assessed under transaction risk analysis, trusted beneficiaries, recurring transactions with the same amount and payee after appropriate setup, and certain secure corporate-payment processes.
Exemptions are regulatory mechanisms, not loopholes that remove all fraud controls.
Low-Value Transaction Exemption
The RTS includes an exemption for certain low-value remote electronic payments, subject to conditions and cumulative limits.
The existence of a low-value exemption does not mean every small transaction will automatically avoid SCA.
Issuers and payment providers may still require authentication based on risk, cumulative transaction limits, fraud concerns, or applicable rules.
Merchants should rely on their processor's implementation rather than attempting to manually infer when a low-value transaction must be challenged.
Transaction Risk Analysis Exemption
Transaction Risk Analysis, often shortened to TRA, allows qualifying low-risk transactions to be exempted from SCA under conditions set by the RTS.
The payment provider must operate transaction-monitoring mechanisms and meet fraud-rate thresholds associated with particular transaction-value bands.
This exemption is designed to let low-risk payments proceed with less friction while requiring stronger authentication as risk increases.
Merchants should not treat TRA as an automatic right to skip authentication because the issuer or acquirer may still decline the exemption or request SCA.
Trusted Beneficiary Exemption
Customers can in certain circumstances designate trusted beneficiaries through their payment service provider.
Payments to a trusted beneficiary may then qualify for an SCA exemption under the RTS.
Adding or changing a trusted beneficiary itself requires appropriate security because an attacker should not be able to add themselves to the trusted list without strong verification.
This exemption is more commonly relevant to account-based payments than ordinary merchant card checkout.
Recurring Transactions
Recurring payments can receive special treatment under SCA rules.
When a customer establishes a series of recurring payments for the same amount to the same payee, SCA is generally relevant when the series is created or modified, while later qualifying transactions may not require the same interactive authentication.
Card-on-file and merchant-initiated transactions can involve additional network classifications and rules beyond the general SCA framework.
Merchants should use their payment provider's stored-credential and recurring-payment capabilities instead of attempting to design their own exemption logic.
Merchant-Initiated Transactions and SCA
A merchant-initiated transaction is initiated by the merchant under a prior agreement with the customer rather than by the customer actively pressing a payment button at that moment.
Certain properly classified merchant-initiated transactions may fall outside the normal SCA requirement because the payer is not actively initiating that specific payment.
However, the original customer agreement and credential setup may require authentication, and payment-network rules still apply.
Misclassifying ordinary customer-initiated payments as merchant-initiated transactions can create compliance, fraud, and dispute risks.
Secure Corporate Payment Processes
The RTS permits an exemption for certain electronic payment transactions initiated by legal persons through dedicated payment processes or protocols that are available only to non-consumers, when competent authorities are satisfied that those processes provide security levels equivalent to PSD2.
This exemption is intended for specialized corporate-payment environments rather than ordinary consumer e-commerce.
Businesses should not assume that simply calling a transaction 'corporate' automatically removes SCA requirements.
The applicable payment provider and regulatory conditions determine whether the exemption can be used.
When SCA Does Not Apply
Some payment scenarios are outside the scope of SCA rather than technically 'exempt' from it.
Examples can depend on geographic scope, whether the payer actively initiated the transaction, the payment instrument, and the roles of the payment service providers involved.
This distinction matters because an out-of-scope transaction and an exempt transaction are not legally identical.
Merchants should rely on their acquirer or payment provider for correct classification instead of building compliance solely from public checklists.
SCA and Geographic Scope
PSD2 SCA is a European regulatory requirement and does not automatically apply to every payment everywhere in the world.
Its application can depend on where the payer's and payee's payment service providers are located and on the relevant transaction structure.
Global merchants can therefore see different authentication behavior for otherwise similar customers.
A merchant should not treat different regional authentication outcomes as evidence that one market has no fraud controls.
SCA vs Payment Authorization
SCA authentication and payment authorization are separate decisions.
SCA addresses whether the customer's identity or authority has been strongly authenticated.
Authorization is the issuer's decision about whether the transaction should proceed.
A payment may satisfy SCA and still be declined because of insufficient funds, card restrictions, account status, merchant risk, sanctions controls, issuer fraud analysis, or other reasons.
Therefore, passing SCA does not guarantee payment approval.
SCA vs CVV
CVV validates a card-verification value associated with the payment card.
SCA requires stronger authentication using independent factors and, for remote electronic payments, transaction-specific protections.
A correct CVV by itself does not satisfy the concept of SCA because static card information does not necessarily establish two independent authentication factors.
CVV can still be used as an additional payment-risk signal alongside SCA and other controls.
SCA vs AVS
AVS compares billing-address information with issuer records.
SCA authenticates the customer using independent factors.
A billing-address match is useful transaction context but is not equivalent to strong customer authentication.
Merchants can use AVS alongside SCA, 3DS, fraud analytics, tokenization, and other controls.
SCA vs MFA
Multi-factor authentication, or MFA, is the broad security concept of using more than one authentication factor.
SCA is a regulated payment-specific form of strong multi-factor authentication with defined factor categories, independence requirements, and transaction protections.
A consumer may therefore encounter MFA in email, social media, cloud services, or banking, while SCA specifically refers to payment and account-access requirements under the relevant European framework.
Not every MFA implementation should automatically be assumed to satisfy SCA.
SCA vs 3DS Liability Shift
SCA compliance and card-network liability shift are related but separate concepts.
SCA determines whether regulatory authentication requirements are met.
3DS liability shift determines responsibility for certain fraud-related disputes under card-network rules.
A transaction can have regulatory and network consequences at the same time, but one should not be used as shorthand for the other.
Merchants should follow both regulatory requirements and payment-network dispute rules.
Why SCA Does Not Eliminate Fraud
SCA substantially strengthens authentication, but fraud can occur through threats that do not disappear simply because multi-factor authentication exists.
Examples can include account takeover, social engineering, malware, compromised devices, first-party misuse, merchant compromise, or customers being manipulated into authenticating a fraudulent payment themselves.
This is why payment providers also use transaction monitoring, fraud analytics, tokenization, secure communications, and customer education.
SCA reduces one important category of payment risk; it is not a complete fraud-prevention system.
How Social Engineering Can Undermine Authentication
Attackers may attempt to persuade customers to approve a payment or disclose authentication information.
A technically valid authentication can still be dangerous if the customer is deceived about what is being authorized.
Consumers should carefully inspect transaction amount and payee information during authentication and should never approve a prompt simply because someone on the phone tells them to do so.
Dynamic linking and clear transaction information help, but customer awareness remains important.
What Consumers Should Know About SCA
Consumers may encounter SCA as a banking-app approval, biometric prompt, passcode, OTP, or another issuer-controlled authentication method.
Not every purchase will necessarily show the same authentication experience.
Customers should keep their issuer contact information and banking app current, protect their devices and email accounts, and read authentication prompts before approving.
If a prompt appears for a payment they did not initiate, they should reject it and contact the issuer through an official channel.
Authentication codes and banking passwords should never be sent to a merchant or stranger through ordinary chat, email, or social media.
What Merchants Should Know About SCA
Merchants should implement SCA through reputable acquirers, payment processors, and EMV 3DS providers rather than attempting to manage regulatory authentication manually.
They should provide accurate transaction information, support current 3DS versions, classify recurring and merchant-initiated payments correctly, and monitor authentication outcomes.
Merchants should also track conversion, challenge rates, authorization rates, fraud, and false declines so that authentication is both compliant and commercially effective.
SCA should be integrated with broader security controls rather than used as the only fraud-prevention measure.
How Merchants Can Reduce Unnecessary SCA Friction
Use modern EMV 3DS and provide complete transaction context so issuers can make better risk decisions.
Use legitimate exemptions through the payment provider where the transaction qualifies.
Classify recurring and merchant-initiated transactions correctly.
Avoid repeatedly asking customers for information that the payment provider can handle securely.
Measure challenge rates and checkout abandonment so unnecessary friction can be identified without weakening authentication.
The objective should be compliant, risk-based authentication rather than simply minimizing the number of challenges.
SCA and False Declines
Strong authentication can sometimes help reduce false declines by giving issuers more confidence that an unusual transaction is legitimate.
For example, a transaction may look unusual because the customer is traveling or buying from a new merchant.
If the customer can be strongly authenticated, the issuer has additional evidence to distinguish genuine activity from fraud.
However, poor implementation can also create checkout failures, so merchants should monitor both authentication and authorization performance.
What Is the Future of SCA Under PSD3 and the Payment Services Regulation?
The European Union is revising its payment-services framework through proposals commonly called PSD3 and the Payment Services Regulation, or PSR.
The European Commission records that Parliament and Council reached political agreement on the PSD2 review on 27 November 2025.
As of June 2026, the European Parliament's legislative tracker described the Payment Services Regulation as close to adoption, with the negotiated text having passed the ECON committee in May 2026.
The agreed framework continues to emphasize Strong Customer Authentication and stronger fraud-prevention responsibilities.
Until the new rules are formally adopted and become applicable, merchants and payment providers should continue to follow the existing PSD2 and RTS framework while preparing for future changes.
Common Myths About SCA
Myth: SCA means every payment needs an SMS OTP. Reality: SCA can use different combinations of authentication factors and modern 3DS can support frictionless experiences where permitted.
Myth: CVV is Strong Customer Authentication. Reality: CVV is a static card-verification value and does not by itself satisfy the two-independent-factor SCA model.
Myth: SCA and 3-D Secure are the same thing. Reality: SCA is the regulatory requirement; EMV 3DS is one technology used to support SCA for online card payments.
Myth: If a transaction is exempt from SCA, it has no fraud protection. Reality: authorization, transaction monitoring, issuer fraud controls, merchant analytics, and other protections still apply.
Myth: Passing SCA guarantees the transaction will be approved. Reality: authentication and authorization are separate.
Myth: Every transaction outside Europe must use SCA. Reality: SCA's legal scope is tied to the applicable European payment framework and transaction circumstances.
Myth: SCA eliminates online fraud. Reality: it strengthens authentication but cannot eliminate social engineering, account takeover, merchant compromise, or every other fraud type.
Conclusion
Strong Customer Authentication is one of the most important payment-security changes introduced by PSD2.
Rather than relying on a single password or static card detail, SCA requires stronger authentication based on independent factors and, for remote electronic payments, transaction-specific protections such as dynamic linking.
Modern technologies such as EMV 3-D Secure help payment providers implement these requirements while minimizing unnecessary friction through risk-based and frictionless authentication where permitted.
SCA is not the same as an OTP, CVV, AVS, or payment authorization. It is a regulatory framework for proving customer authority more strongly.
For consumers, the practical lesson is to protect authentication factors and carefully review every payment prompt. For merchants, the lesson is to implement SCA through current payment infrastructure, use exemptions only when legitimately applicable, and combine authentication with layered fraud prevention.
As European payment law continues evolving toward PSD3 and the Payment Services Regulation, Strong Customer Authentication remains central to the EU's strategy for safer digital payments.
