Category: Authentication Methods
Strong Customer Authentication
Also known as: SCA, Strong Customer Authentication under PSD2
Simply put
Strong Customer Authentication (SCA) is a European regulatory requirement intended to make online and certain contactless payments more secure and to help reduce fraud. It generally asks that a customer confirm their identity using more than one type of verification when making a payment. It is a rule set by regulation rather than a specific technology.
Formal definition
Strong Customer Authentication (SCA) is a requirement of the EU Revised Directive on Payment Services (PSD2) applicable to payment service providers within the European context, intended to enhance the security of payments and limit fraud during the authentication process. It became a requirement for businesses processing online payments in Europe on September 14, 2019, and is intended to add additional layers of security to online and contactless offline payments. SCA is a regulatory obligation, not a single technical control; practitioners should note that its scope, applicable exemptions, and enforcement timelines vary by jurisdiction and have differed in practice, and that SCA is distinct from underlying authentication mechanisms such as 3-D Secure or multi-factor authentication, which may be used to help satisfy it but are governed separately. Readers should confirm current obligations against the applicable regulator's published rules, as regional requirements and effective dates differ.
Why it matters
Strong Customer Authentication represents a shift from voluntary or contractual security expectations to a binding regulatory obligation for payment service providers operating within the European context. Because SCA is grounded in the EU Revised Directive on Payment Services (PSD2) rather than in a card brand rule or a single technical standard, it changes how businesses processing online and certain contactless offline payments in Europe must approach the authentication step of a transaction. For merchants, acquirers, and processors, non-compliance can mean declined transactions or increased friction, since a payment that does not meet the applicable authentication requirement may be rejected by the customer's bank.
SCA is intended to enhance the security of payments and to help reduce fraud during the authentication process. It does this by generally requiring more than one type of verification when a customer makes a payment, rather than relying on a single credential that could be compromised. It is important to understand that SCA is a rule, not a mechanism: it defines an outcome and leaves the specific implementation to underlying tools such as 3-D Secure or multi-factor authentication, which are governed separately. No single control eliminates fraud, and SCA should be understood as one regulatory layer within a broader payment security posture.
Who it's relevant to
Merchants processing European online payments
Businesses that process online payments in Europe have been subject to SCA as a requirement since September 14, 2019. They need to ensure their checkout and payment flows can support the additional verification steps required, while managing the customer experience impact of added authentication friction. They should confirm which exemptions may apply to their transactions against current published regulatory guidance.
Acquirers and payment processors
Acquirers and processors operating in the European context must support SCA-compliant authentication flows and understand how underlying mechanisms such as 3-D Secure integrate with the regulatory requirement. Because scope, exemptions, and enforcement timelines have differed in practice by jurisdiction, they should track regional regulator rules rather than applying a single uniform interpretation.
Compliance and regulatory teams
Teams responsible for regulatory compliance need to distinguish SCA as a PSD2 obligation from the technical controls used to satisfy it, and from separate standards such as PCI DSS. They should confirm current obligations, applicable exemptions, and effective dates against the relevant regulator's published rules, as these vary by jurisdiction and have changed over time.
Fraud prevention and risk teams
Fraud analysts should understand that SCA is intended to help reduce fraud during the authentication process by requiring more than one type of verification, but that it addresses one point in a transaction and does not eliminate fraud on its own. It should be considered alongside other detection and prevention controls, each of which carries its own trade-offs.
Inside SCA
Two-factor requirement
SCA is generally defined as authentication using at least two of three independent categories: something the customer knows (knowledge, such as a password or PIN), something the customer has (possession, such as a device or hardware token), and something the customer is (inherence, such as a biometric). The elements must be independent so that compromise of one does not compromise another.
Regulatory basis
SCA is a regulatory concept, most notably associated with the European Union's revised Payment Services Directive (PSD2) and its regulatory technical standards. It is distinct from PCI DSS and the other PCI standards, which are card brand and PCI SSC frameworks rather than payment regulations. Applicability, scope, and enforcement depend on jurisdiction.
Dynamic linking
For remote electronic payment transactions, SCA typically requires that the authentication code be dynamically linked to a specific transaction amount and payee, so that the authentication cannot be reused for a different transaction. This helps reduce certain replay and manipulation risks.
Relationship to 3-D Secure
3-D Secure (for example EMV 3-D Secure) is a common technical mechanism used to help satisfy SCA for card-not-present transactions, but SCA and 3-D Secure are not synonymous. 3-D Secure is a protocol governed under PCI 3DS and card brand rules; SCA is the underlying authentication objective that such a protocol may help meet.
Exemptions and exclusions
Applicable regulation may permit exemptions from applying SCA in defined circumstances, such as certain low-value transactions, low-risk transactions under transaction risk analysis, recurring payments, or merchant-initiated transactions. The specific exemptions, thresholds, and conditions depend on the current regulation and region and should be confirmed against the governing text.
Common questions
Answers to the questions practitioners most commonly ask about SCA.
Is Strong Customer Authentication the same thing as multi-factor authentication (MFA)?
Not exactly. SCA is a regulatory requirement, associated primarily with the EU's PSD2 framework, that generally calls for authentication based on two or more independent elements from the categories of knowledge (something the user knows), possession (something the user has), and inherence (something the user is). MFA is the broader technical concept of combining multiple authentication factors. SCA can be understood as a specific regulatory application of multi-factor principles, with defined element categories, independence expectations, and permitted exemptions. Treating them as interchangeable overlooks that SCA carries jurisdiction-specific regulatory obligations and exemption rules that generic MFA does not. Always confirm requirements against the applicable regulation and any implementing technical standards for your region.
Does implementing SCA prevent card-not-present fraud?
No. SCA is intended to help reduce certain forms of unauthorized transactions by strengthening the authentication of the payer, but it does not eliminate fraud. It addresses risk at the authentication step and does not by itself protect against every fraud type. For example, first-party or friendly fraud, account takeover where the attacker controls the legitimate factors, and social-engineering-driven authorized push scenarios may not be mitigated by authentication alone. SCA also involves trade-offs, including added friction and potential effects on transaction completion. It should be treated as one control among several rather than a guarantee against card-not-present fraud.
How does SCA relate to 3-D Secure in practice?
In card payment contexts, 3-D Secure is commonly used as a mechanism to help perform and convey authentication that can support SCA requirements, but the two are distinct. SCA defines the regulatory objective of authenticating the payer with independent elements, while 3-D Secure is a messaging protocol that enables authentication data to be exchanged between the merchant, the card networks, and the issuer. The PCI 3DS standard governs security requirements for certain 3-D Secure environments and is separate from the regulatory SCA obligation. Whether a given 3-D Secure implementation satisfies SCA depends on how the authentication elements are applied and validated, not on the use of the protocol alone.
What are exemptions in the context of SCA, and how should they be handled?
Exemptions describe scenarios where the applicable regulation may permit a transaction to proceed without applying full SCA, subject to defined conditions. The specific categories, thresholds, and conditions are set by the governing regulation and any implementing technical standards, and they can vary by jurisdiction and change over time. Because applying an exemption typically shifts responsibility and risk considerations, teams should map each exemption they intend to use to the current regulatory text, coordinate with acquirers and issuers on how exemption requests are signaled and honored, and monitor outcomes. Do not assume a fixed list of exemptions or thresholds; confirm against the current published requirements for your region.
How does SCA affect PCI DSS scope and compliance?
SCA is a separate obligation from PCI DSS and does not by itself change PCI DSS scope. PCI DSS governs the protection of cardholder data and, where applicable, sensitive authentication data across your environment, while SCA addresses payer authentication under regulations such as PSD2. Implementing SCA-related components, such as authentication flows or 3-D Secure integrations, may still fall within your broader security and compliance considerations, and any systems that store, process, or transmit account data remain subject to PCI DSS. Assess each system independently: satisfying an SCA requirement does not demonstrate PCI DSS compliance, and vice versa. Confirm control ownership and validation obligations against the current versions of the relevant standards.
Which parties are typically involved in delivering SCA for a transaction?
SCA delivery in card payments usually involves coordination among several parties: the merchant, which initiates the payment and may request an exemption; the acquirer or payment processor, which routes authentication and authorization messaging; the card networks, which operate the relevant protocols; and the issuer, which is generally responsible for authenticating its cardholder and deciding whether an exemption or challenge applies. The precise responsibilities, messaging flows, and decisioning logic depend on the regional regulation, network and brand rules, and the specific integration in use. Because these rules vary by region and change over time, confirm the current expectations with your acquirer and against the applicable published requirements rather than assuming a single fixed workflow.
Common misconceptions
SCA and multi-factor authentication (MFA) are the same thing.
Both draw on independent authentication factors, but they address different contexts. MFA is a general access-control concept applied broadly, including to systems in the cardholder data environment under PCI DSS. SCA is a specific regulatory authentication requirement for payment transactions, with its own conditions such as dynamic linking and defined exemptions. Meeting a generic MFA control does not automatically satisfy SCA obligations.
Implementing SCA eliminates payment fraud.
SCA is intended to help reduce certain fraud, particularly in card-not-present and account takeover scenarios, but it does not eliminate fraud. It does not by itself address friendly or first-party fraud, chargeback fraud, or synthetic identity fraud, and authentication controls carry usability trade-offs and potential for false positives that can affect legitimate customers.
SCA applies uniformly to all transactions everywhere.
SCA is a regulatory requirement whose applicability varies by jurisdiction, and even where it applies, defined exemptions and exclusions may remove the obligation for specific transaction types. Scope, thresholds, and effective conditions differ by region and change over time, so they should be confirmed against the current governing regulation rather than assumed.
Best practices
Confirm SCA applicability and exemption conditions against the current governing regulation for each region in which you operate, rather than relying on a fixed rule set, since thresholds and conditions change over time.
Where SCA applies to remote card-not-present payments, implement dynamic linking so the authentication is tied to the specific transaction amount and payee, and validate that the mechanism enforces this.
Select authentication factors from genuinely independent categories (knowledge, possession, inherence) so that compromise of one factor does not undermine another.
Treat 3-D Secure as a technical enabler that may help satisfy SCA for card-not-present transactions, and validate it under the applicable PCI 3DS and card brand rules rather than assuming the protocol alone meets every regulatory obligation.
Apply available exemptions such as transaction risk analysis deliberately and monitor their impact, balancing reduced customer friction against the risk of increased fraud and false negatives.
Do not rely on SCA as a sole defense; combine it with layered fraud detection and monitoring to address fraud types outside its scope, such as first-party and chargeback fraud, and track false-positive rates affecting legitimate customers.