> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/compliance/strong-customer-authentication-sca.md). # Strong Customer Authentication (SCA) A PSD2 security requirement that uses independent authentication factors to reduce fraud in electronic payments. Strong Customer Authentication (SCA) is a [PSD2](/compliance/psd2-second-payment-services-directive.md) security requirement for electronic payments that fall within its scope in the European Economic Area (EEA). Whether SCA applies to a specific transaction depends on the payment scenario, the parties involved, and the applicable regulatory rules. It is designed to reduce fraud by requiring the customer to authenticate using multiple independent factors before certain electronic payments or other protected actions can be completed. ### SCA requirements SCA uses at least two independent elements from three categories: * Knowledge - something only the customer knows, such as a password or PIN. * Possession - something the customer possesses, such as a mobile device or hardware token. * Inherence - something the customer is, such as a fingerprint, facial recognition, or another biometric characteristic. The factors must be independent so that compromising one factor does not compromise the reliability of the other. ### How SCA is applied SCA is applied differently depending on the payment method. EMV® 3-D Secure (EMV 3DS) is a card-payment authentication protocol used to support SCA; EMV 3DS itself is not the regulation. See PSD2 ([Second Payment Services Directive](/compliance/psd2-second-payment-services-directive.md)) for the regulatory framework and [EMV® 3-D Secure (EMV 3DS)](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) for the card-payment authentication flow. **Online card payments** Depending on the issuer’s risk assessment and the applicable rules, authentication may be frictionless or may require a customer challenge, such as approval in a banking application, a one-time password, or biometrics. **Open Banking and account-to-account payments** For Open Banking payments, authentication is typically performed by the customer’s bank using the bank’s own online or mobile authentication methods. **Digital wallets** Digital wallets can use device-based authentication such as biometrics or a device passcode. Whether an additional 3DS step is required depends on the payment credential, regulatory treatment, and issuer decision. #### Exemptions and out-of-scope transactions Not every payment requires active cardholder interaction, and not every payment is subject to SCA. These situations should be distinguished: * Frictionless EMV 3DS: the issuer completes the EMV 3DS flow without an interactive challenge. Depending on the transaction, SCA may still have been satisfied or an exemption may have been applied. * SCA exemption: the transaction is within the regulatory scope of SCA, but the applicable rules allow the payment service provider not to apply SCA. * Out-of-scope transaction: the SCA requirement does not apply to the transaction. The PSD2 regulatory technical standards allow exemptions in defined situations and some transaction types are outside the SCA scope. Examples include: * Qualifying low-value remote electronic payments. * Subsequent payments in a qualifying series of recurring transactions with the same amount and payee after SCA has been applied when the series is created or first initiated. * Payments to trusted beneficiaries previously established by the customer using SCA. * Certain corporate payment processes that meet the regulatory conditions. * Mail order and telephone order (MOTO) transactions, which are outside the scope of SCA because they are not initiated through a remote electronic channel by the payer. {% hint style="info" %} Recurring payments processed as Merchant-Initiated Transactions (MITs) are a separate concept from the PSD2 recurring-payment exemption. For card-based stored-credential payments, subsequent MITs must be based on an appropriately established customer relationship, including the required customer consent and an initial Customer-Initiated Transaction (CIT). See [Stored Credentials](/payment-methods/cards/stored-credentials.md) and [Merchant-Initiated Transactions (MIT)](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md).\ Not all MITs qualify for the PSD2 recurring-payment exemption. The applicable regulatory treatment depends on the specific transaction scenario. {% endhint %} {% hint style="info" %} Whether an exemption can be used and whether additional authentication is required depends on the applicable rules, the payment scenario, and the issuer or payment-service provider. An issuer may still require authentication. {% endhint %} ### Merchant impact Treat authentication as part of the normal payment flow. Rely on the confirmed payment status, not the customer’s return to your website. Your payment flow must allow the customer to complete required authentication. ### Related Documentation * [PSD2 (Second Payment Services Directive)](/compliance/psd2-second-payment-services-directive.md) * [EMV® 3-D Secure (EMV 3DS)](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) * [Cards](/payment-methods/cards.md) * [Pay by Bank](/payment-methods/pay-by-bank.md) * [Customer-Initiated Transactions (CIT)](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md) * [Merchant-Initiated Transactions (MIT)](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/compliance/strong-customer-authentication-sca.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.