PSD2 SCA in practice: friction vs fraud trade-offs

Strong Customer Authentication was designed to protect consumers, and it does — issuer fraud rates have fallen meaningfully across markets where SCA is properly enforced. But SCA applied bluntly, as a checkbox bolted onto checkout at the last minute, punishes conversion far more than the regulation actually requires. The gap between "compliant" and "compliant and commercially sensible" is almost entirely a design and data quality problem.

Understanding the exemption landscape

PSD2 provides several routes to avoid a full authentication challenge without breaching the regulation: low-value transaction exemptions, trusted beneficiary lists that customers themselves whitelist, recurring transaction exemptions for subscriptions after the first payment, and transaction risk analysis (TRA), where issuers or acquirers with sufficiently low fraud rates can request exemptions based on real-time risk scoring.

TRA is the most powerful and most underused of these routes, because it depends on data quality that many merchants simply do not provide. An issuer cannot approve a low-risk exemption request if the 3DS2 message arriving with the transaction is thin — missing device fingerprinting data, billing history signals, or account tenure information that would let the issuer's risk engine make a confident low-risk call.

3DS2 data quality is the real lever

Most merchants treat 3DS2 as a protocol to implement once and forget. In practice, the richness of the data fields you populate directly determines how often issuers can exempt your transactions from a full challenge. Populating account age, order history, shipping address consistency and device signals meaningfully improves exemption rates — often more than any UX tweak to the challenge screen itself.

Soft declines versus hard declines

A soft decline under SCA (issuer requesting authentication where none was attempted) is recoverable — the transaction can be retried with a proper 3DS2 challenge. A hard decline is not. Merchants who conflate the two in their monitoring lose visibility into how much recoverable revenue is being abandoned simply because the retry flow was not built, or was built poorly.

Designing the challenge experience

When a challenge is unavoidable, the UX around it matters enormously. Contextual messaging — explaining briefly why a challenge is appearing — measurably reduces abandonment compared to an unexplained redirect. Challenge flows should also be tested across the full range of issuer bank apps and OTP delivery methods your customer base actually uses, since failure modes vary significantly by issuer.

Building an SCA monitoring practice

• Track exemption request rates and exemption grant rates separately by issuer and by transaction type.
• Distinguish soft declines from hard declines in every dashboard and alert.
• Monitor 3DS2 data field completeness as a KPI, not just a one-time integration checkbox.
• A/B test challenge screen messaging and measure abandonment at each step of the challenge flow.
• Review exemption and challenge policy quarterly as issuer risk appetite and fraud patterns shift.

SCA as a product capability

The organisations that get the best combination of low fraud and high conversion treat SCA policy as an owned product capability with a dedicated owner, metrics and a roadmap — not a one-time compliance integration signed off before launch and never revisited. Issuer risk models evolve, fraud patterns shift by season and geography, and an SCA policy frozen at launch degrades steadily over time.

This also means SCA policy needs to be observable in the same dashboards as checkout conversion, so that friction trade-offs are visible to the people who own commercial outcomes, not buried in a compliance team's quarterly report.

Every unnecessary SCA challenge is a fraud control the regulation did not actually require you to apply.

Working with issuers and acquirers on data quality

Improving 3DS2 data quality is rarely something a merchant can do entirely alone — it usually requires a direct conversation with your acquirer or payment service provider about which optional data fields their integration actually forwards to issuers, since not every PSP integration populates the full available field set by default. Ask specifically for a field-completeness report rather than assuming your integration already sends everything the specification allows.

It is also worth requesting exemption performance data segmented by issuer from your acquirer periodically, since issuer risk appetite for TRA exemptions genuinely varies and shifts over time. An acquirer that can show you which issuers are granting exemptions readily, and which are challenging almost everything regardless of risk score, gives you a much more targeted view of where further data quality investment will actually move your numbers.

Bring these findings back into your own product roadmap explicitly, since a data quality investment that meaningfully improves exemption rates with your largest issuer by transaction volume can be worth far more than a general improvement spread thinly across every issuer your customers happen to bank with.

Key takeaways

• TRA exemptions depend on 3DS2 data richness far more than on issuer generosity.
• Soft declines are recoverable revenue — build and monitor the retry path explicitly.
• Contextual challenge UX reduces abandonment more reliably than generic redirect flows.
• Treat SCA policy as an owned, continuously tuned product capability.
• Review exemption performance by issuer regularly; risk appetite is not static.