Every fintech that touches European payments eventually meets Strong Customer Authentication (SCA). It is the rule that decides whether a customer breezes through checkout or is asked to confirm their identity, and it sits at the intersection of two goals that often pull in opposite directions: reducing fraud and keeping the payment experience smooth. For compliance and product decision-makers, SCA is not just a checkbox in the payments regulation; it is a design choice that affects conversion, fraud losses, and liability. This guide explains what SCA requires today, how exemptions work, and what the incoming PSD3 and Payment Services Regulation (PSR) framework is likely to change.
This article is general information for fintech and compliance professionals and is not legal advice. Requirements depend on your licences, markets, and payment flows; confirm specifics with qualified counsel and your regulator.
What Strong Customer Authentication Means
Strong Customer Authentication is a requirement introduced under the EU’s second Payment Services Directive (PSD2) and its regulatory technical standards. In essence, it requires that certain electronic payments and account-access events be verified using at least two independent factors drawn from three categories: something the customer knows (such as a password or PIN), something they possess (such as a phone or hardware token), and something they are (such as a fingerprint or face). The factors must be independent, so that compromising one does not compromise the others.
The objective is straightforward: make it substantially harder for a fraudster who has stolen one credential to complete a payment. The practical challenge is that adding authentication steps can add friction, and friction costs conversions. Managing that trade-off well is what separates a mature SCA approach from a compliant-but-clumsy one.
When SCA Applies — and When It Does Not
SCA generally applies when a payer accesses their payment account online, initiates an electronic payment, or performs an action through a remote channel that could carry a risk of fraud. It is most visible in card-not-present e-commerce, where it is typically delivered through the 3-D Secure 2 protocol that lets the card issuer authenticate the shopper during checkout.
Crucially, the rules also recognize that applying full authentication to every transaction would be disproportionate. The technical standards therefore define a set of exemptions, and understanding them is central to designing a checkout that is both compliant and low-friction.
Common exemption categories
The exemptions are options that the payer’s bank can apply based on risk; they are not guarantees, and the issuer makes the final decision. The main categories include:
- Low-value transactions: Small payments (with cumulative limits and a cap on consecutive uses) may be exempt.
- Transaction risk analysis (TRA): Where a provider maintains sufficiently low fraud rates, transactions below risk-based thresholds may be exempted after real-time risk scoring.
- Trusted beneficiaries: Once a payer adds a merchant to a list of trusted payees, subsequent payments to that merchant may be exempt.
- Recurring transactions: A series of payments of the same amount to the same payee may require SCA only on the first.
- Merchant-initiated transactions (MITs): Payments the merchant initiates under an agreed mandate are handled outside per-transaction SCA once the mandate is set up.
Deciding which exemptions to request, and building the risk logic to support them, is closely tied to how you monitor and manage fraud overall. Our guide to fraud and chargeback management covers the wider prevention picture that sits behind exemption strategy.
SCA, Liability, and the Payment Experience
SCA is not only a compliance obligation; it shifts liability. When a transaction is properly authenticated, liability for certain fraud typically moves away from the merchant toward the issuer. When a merchant applies an exemption to reduce friction, it may retain more of that risk. This is the core commercial tension: authenticate more and protect against chargebacks but risk abandoned carts, or exempt more and improve conversion but carry more liability. Decision-makers should treat this as a portfolio decision informed by real fraud and conversion data, not a one-size-fits-all setting. The way authentication integrates with your checkout is also inseparable from your broader payment software and gateway choices.
What PSD3 and the PSR Are Set to Change
The European payments framework is being updated. On 23 April 2026, the EU Parliament, Council and Commission reached agreement on the final texts of PSD3 and the Payment Services Regulation (PSR). Publication in the Official Journal was expected around the end of the second quarter of 2026. Because the PSR is a regulation, it applies directly across Member States once in force, with application generally expected roughly 18 months later; PSD3, as a directive, must be transposed into national law, generally within about 24 months. These dates mean the practical impact will unfold over the coming years rather than overnight.
For SCA specifically, several directions are worth noting:
- Harmonization and clarity: The specifications are expected to be further harmonized, reducing divergence in how SCA is applied across the market.
- Accessibility as a right: Providers are expected to offer at least one authentication method suitable for customers without a smartphone, with disabilities, or with low digital skills, and to do so free of charge.
- Clearer MIT treatment: The framework clarifies that SCA is required when a merchant-initiated mandate is set up, but not on each subsequent transaction under it.
- Stronger fraud-liability expectations: The rules move toward holding providers accountable where they fail to meet expected fraud-detection standards, including in certain authorized push payment (APP) fraud scenarios.
The recurring theme is that authentication is being pushed to become both more inclusive and more risk-intelligent. This mirrors the broader compliance modernization we discussed in our overview of digital wallets and e-money.
Decision Criteria for an SCA Strategy
When reviewing your SCA approach, a few questions help separate a resilient design from a fragile one:
| Dimension | Question to Ask |
|---|---|
| Coverage | Do we correctly identify which flows require SCA across all our channels and markets? |
| Exemption logic | Which exemptions do we request, and is our risk scoring good enough to justify them? |
| Experience | How much friction does authentication add, and where are customers dropping off? |
| Inclusion | Can customers without smartphones or with accessibility needs still authenticate? |
| Liability | Do we understand how our choices shift fraud liability, and is that trade-off intentional? |
| Change readiness | Are we tracking PSD3/PSR timelines so upcoming changes do not surprise us? |
Frequently Asked Questions
Is SCA only relevant to card payments?
No. While it is most visible in card-not-present e-commerce through 3-D Secure 2, SCA also applies to online account access and to other electronic payment channels, subject to the applicable exemptions.
Do exemptions mean the customer is never challenged?
No. Exemptions can be requested, but the payer’s bank ultimately decides whether to apply them or to require full authentication based on its own risk assessment.
Does PSD3 replace SCA?
No. PSD3 and the PSR continue and refine the SCA regime rather than removing it, with an emphasis on harmonization, accessibility, clearer treatment of merchant-initiated transactions, and fraud accountability.
How should we prepare for the transition?
Track the published timelines, review where your current authentication logic and exemption strategy sit, and make sure inclusive authentication methods are on your roadmap. Treat it as a phased program rather than a single deadline.
Conclusion
Strong Customer Authentication is where fraud prevention, regulatory compliance, and customer experience meet. Today it is governed by PSD2 and its technical standards, delivered largely through 3-D Secure 2, and shaped by a set of exemptions that let firms balance security against friction. With PSD3 and the PSR now agreed, the direction of travel is toward more harmonized, more inclusive, and more risk-intelligent authentication, along with sharper accountability for fraud. For decision-makers, the practical task is to treat SCA as a deliberate strategy, measured against real fraud and conversion data, rather than a fixed setting to switch on and forget.
If your team is reviewing its authentication and payments compliance posture, or wants to prepare for the PSD3/PSR transition, get in touch with DanuSoft to discuss your requirements.