Why SCA Exemption Requests Still Fail—and What Approval Rate Actually Means When They Do

The business problem is not whether to seek exemptions, but whether the approval lift outweighs fraud exposure, liability shift loss, and the risk that a failed first attempt cannot be retried.

Authentication is decided upstream

Under PSD2 Article 97, strong customer authentication applies when a payer accesses a payment account online, initiates an electronic payment, or carries out any remote-channel action that carries fraud risk. The European Banking Authority clarified in 2019 that these conditions are not cumulative—meeting one triggers the requirement. Yet the same authority notes that the issuer, not the merchant, grants or refuses an exemption request. Visa's December 2020 regulatory guide states this explicitly: the issuer makes the decision. Mastercard's authentication documentation confirms the hierarchy—exemption requests travel up, but declines travel down

This matters operationally because merchants control the ask, not the outcome. A merchant can flag transaction-risk analysis, cite low value, or invoke subscription recurrence. The issuer weighs its own fraud rate against thresholds set in the Regulatory Technical Standards, plus any internal risk appetite. Mastercard's guidelines note that when an acquirer's fraud rate sits below threshold but the issuer's rate sits above, the issuer is expected to decline the exemption. The exemption request becomes a signal, not a guarantee.

Exemptions versus exclusions

The PSD2 framework separates transactions that might skip authentication from those that never needed it. This distinction determines whether you are requesting special treatment or simply operating outside the perimeter.

Merchant-initiated recurring transactions—subscriptions, installments, automatic renewals—fall outside PSD2 scope entirely according to Visa's guide, because the customer did not initiate them. Customer-initiated recurring payments, such as standing orders set up from a bank account, remain in scope. Visa notes that the RTS contains a recurring payments exemption for series of identical amounts to identical payees, but this exemption is not supported in Visa's processing system for merchant-initiated recurring payments. The exemption exists on paper; the infrastructure does not honor it.

Mail order and telephone order transactions occupy a different category. The European Banking Authority described them as outside PSD2/RTS SCA requirements in March 2019. Visa confirms MO/TO is out of scope and does not require SCA. Mastercard's documentation lists card-present, mail order, telephone order, voice response, and call centre transactions as excluded from PSD2 authentication requirements. These channels are excluded by channel type, not exempted by rule exception.

Tokenised payments, however, stay in scope. The EBA stated in 2019 that where tokenisation or similar technology initiates an electronic payment through internet or at-distance channels, SCA applies. The technology does not remove the requirement; it merely reshapes how credentials travel.

The limits attached to exemption requests

The Regulatory Technical Standards provide two remote-payment exemptions with explicit constraints. Transaction-risk analysis allows low-risk transactions to proceed based on behavioural and contextual data. Low-value payments below EUR 30 qualify under separate conditions.

A PayPlug white paper documented the practical limits: exemption requests for sub-EUR 30 transactions can be refused after five consecutive exempted payments without fresh authentication, or when cumulative exempted payments exceed EUR 100. These are hard ceilings, not guidelines. The merchant who tracks neither counter faces sudden authentication demands mid-checkout.

The PayPlug paper also defined soft decline: a transaction submitted for authorisation without authentication and without applicable exemption, where the issuing bank responds by requesting strong customer authentication. This is not a hard decline with a decline code. It is a conditional rejection that invites retry. The invitation often expires before the customer returns.

Soft declines and the lost retry

The soft-decline mechanism creates a specific failure mode. Customer initiates checkout. Merchant requests exemption. Issuer refuses. Response codes indicate authentication required. But the merchant's initial flow assumed frictionless approval; the technical path to challenge insertion may not exist in real time. By the time the system pivots, the customer has abandoned, or the session has timed, or the payment method has been flagged for inconsistent behaviour. The transaction dies not from issuer rejection but from infrastructure mismatch.

Visa's documentation and Mastercard's guidelines both describe issuer discretion over exemption grants. Neither guarantees retry coherence. The merchant who measures only final authorisation rate misses the intermediate leakage—attempts that could have succeeded with authentication but never got there.

When an exemption is worth the risk

The decision calculus has three variables: approval probability, fraud probability, and liability position. Requesting an exemption where the issuer's fraud rate exceeds threshold invites decline. Mastercard's guidelines make this explicit—issuer fraud-rate conditions override acquirer compliance. Succeeding with an exemption where fraud materialises exposes the merchant to liability that authenticated, liability-shifted transactions avoid.

PayPlug's analysis framed the trade-off directly: exemptions improve conversion when granted, damage it when refused, and carry hidden costs in fraud absorption. The merchant must weigh not nominal exemption availability but actual issuer behaviour by transaction type, value band, and historical fraud pattern. Some merchants segment by issuer BIN range. Others abandon exemptions entirely for high-value segments where liability exposure dominates.

The European Commission's notification described exemption intent—reducing friction for low-risk transactions. Implementation introduced friction of a different kind: uncertainty, retry complexity, and the soft-decline dead end.

What to measure instead of overall approval rate

Overall authorisation rate conflates paths that should be separated. A merchant reporting 87% approval tells nothing about whether exemptions lifted that figure or suppressed it, whether soft declines recovered or perished, whether authentication completion rates differ by exemption category.

The operative metric is authorisation rate by authentication outcome: what share of exemption-requested transactions converted, what share of soft-declined transactions recovered through challenge, what gap exists between exemption-granted and exemption-denied cohorts. Industry reporting on these splits remains inconsistent; PSPs aggregate differently, and scheme data arrives with lag. Merchants building internal dashboards typically instrument at authentication request, challenge presentation, challenge completion, and final authorisation—four events, not one.

Without this granularity, the merchant optimises blind. An exemption strategy that lifts exemption-granted approvals by 12% but loses 23% of exemption-denied transactions to soft-decline attrition shows positive in aggregate, negative in truth. The measurement infrastructure matters as much as the exemption logic.

The question that remains operational is specific: for your transaction mix, your issuer distribution, your fraud history, does the authenticated path or the exempted path yield higher net authorisation? The answer changes quarterly. The infrastructure to detect that change—event-level tracking by authentication outcome—remains the prerequisite for any strategy that treats exemptions as more than hope.