SCA Exemption Strategy: The Operator Playbook for TRA, Low-Value, and Trusted Beneficiary

A checkout team that treats SCA exemptions as a switch to flip — "we qualify for TRA, so turn it on" — is solving the wrong problem. An exemption request is exactly that: a request. It travels to the issuer inside the authorization message or the 3DS2 authentication flow, the issuer's risk engine looks at it, and the issuer decides whether to honor it, ignore it, or force a challenge anyway. Most of the 3DS challenge rate operators are fighting isn't a data-quality problem or a threshold-qualification problem — it's a request that never had a real chance of being accepted, sent by a team that thought qualifying was the same thing as winning.

This is the operational counterpart to 3DS2 and the Authentication Tax, which covers what the authentication tax costs and sketches the exemption categories in the context of that cost. This article stays on the ground: how an exemption is actually carried in the message flow, which field does what, why issuers wave requests through inconsistently, and what "the TRA fraud rate" actually measures — because it is not what most people assume.

The Exemption Landscape

SCA under PSD2's Regulatory Technical Standards (RTS, Commission Delegated Regulation (EU) 2018/389) applies by default to electronic payments in the EEA, with a defined set of exemptions and a separate set of transaction types considered out of scope entirely. The distinction matters operationally: an exemption is something you request and the issuer can refuse; out-of-scope status means SCA was never required in the first place. Neither category quite describes a wallet transaction, worth naming before the table below: Apple Pay and Google Pay transactions typically carry device-level authentication (Face ID, Touch ID, or a passcode, tied to the device itself) that satisfies SCA's factor requirements directly, rather than needing an exemption requested on top of it — a different mechanism from every row below, none of which apply once genuine on-device authentication has already occurred.

The MIT row is worth pausing on, because it's a genuine scheme difference rather than a labeling quirk: Visa's position is that merchant-initiated transactions are out of scope of PSD2 altogether, so there's nothing to "exempt" — the initial mandate-setting transaction (the CIT) needs SCA, subsequent MITs don't need anything requested at all, provided they're correctly flagged. Mastercard instead treats the recurring case (its "3RI" category) as an actual exemption that has to be claimed transaction by transaction. Get the flagging wrong and the practical failure mode is identical either way — an issuer that can't recognize the transaction as cardholder-absent will request SCA the cardholder isn't there to complete. The mechanics of that failure, the CIT/MIT anchor requirement, and the six MIT subtypes are covered in full in Merchant-Initiated Transactions: SCA, Reason Codes, Auth Rate Impact — this article won't re-tread that ground.

How an Exemption Is Actually Requested

The mechanics differ depending on whether the transaction goes through a 3DS authentication step first or straight to authorization, but the pattern is the same: a field in the message tells the issuer which exemption is being claimed, and the issuer's system decides what to do with that information.

On the pure authorization side, Visa's implementation runs through Field 34 (Electronic Commerce Data, Dataset ID 56), which the acquirer populates with one of a defined set of tags: 9F7C for the low-value exemption, 9F7D for TRA, 9F7E for trusted merchant, 9F7F for secure corporate payment. Visa is explicit that acquirers should submit only one exemption indicator per message — submitting several doesn't strengthen the request, it just gets forwarded to the issuer as-is and, per Visa's own guidance, "may have an adverse impact on Issuer's approval rates." If the issuer decides SCA is still required, it returns response code 1A in Field 39 — a soft decline meaning "come back with a full authentication," not "this transaction is denied."

Inside the EMV 3DS authentication flow itself (versions 2.1 and 2.2), the equivalent carrier is the 3DS Requestor Challenge Indicator field, populated by the merchant's 3DS Server. The exemption-relevant values are: 05 for TRA, low-value, or (for Mastercard) MIT; 06 for a data-share-only request; 07 for SCA performed via issuer delegation; and 08 for "no challenge requested, rely on an existing whitelist status." Secure corporate payment is flagged differently again — through a merchant-data message extension field rather than the challenge indicator. Whichever field carries the request, the same rule applies as on the pure-authorization side: if the issuer's Access Control Server declines to accept it, the authentication response comes back with a soft-decline transaction status (Mastercard uses response code 65 in this context, Visa uses 1A), and the transaction has to be funneled back through a full 3DS challenge before it can proceed.

That soft-decline retry is the piece operators most often get wrong. The correct response mirrors the general soft-decline recovery pattern — but with a compressed clock. A soft decline for insufficient funds can wait a day or two; a soft decline asking for SCA cannot, because the whole point of most exemptions is to avoid an active cardholder session, and by the time a delayed retry reaches the customer, they're gone. Practically, that means: if an exemption request is soft-declined and the cardholder is still on the checkout page, retry immediately with the challenge indicator set to mandate SCA. If the transaction was submitted directly to authorization with an exemption flag rather than through the 3DS flow first, a rejection there is worse — the cardholder has likely already left the session, and there's no clean way to bring them back for a challenge mid-checkout.

Why Issuers Ignore Exemption Requests

The asymmetry is structural, not incidental. An acquirer or merchant requests an exemption. An issuer decides. Nothing in the message flow obligates the issuer to explain why it declined, and nothing prevents an issuer's risk model from treating a technically-qualifying exemption request as itself a risk signal worth ignoring — a merchant sending TRA flags on transactions the issuer's own model doesn't like is a pattern issuers can and do act on independently of whether the acquirer's aggregate fraud rate happens to be compliant.

The clearest evidence that this isn't a hypothetical is that the schemes had to write rules against it. Visa's PSD2 implementation guide states plainly that "Visa Issuers may not systematically decline Acquirer exemptions or out of scope transactions unless they are flagged incorrectly," and separately, that "transactions sent via 3DS with a TRA request flag may not be systematically challenged." A rule prohibiting a specific behavior is reasonably strong evidence the behavior was common enough, at scale, to warrant a rule. Visa also requires that an issuer receiving an authentication request with a TRA exemption indicator may not decline the same transaction at authorization with an SCA-required code after having already granted the exemption at the authentication stage — closing a loophole where an issuer accepts the exemption in one message and reverses course in the next.

None of that means an individual soft decline was wrong. It means the merchant-side signal ("we qualify, so approve it") and the issuer-side decision ("we don't like this specific transaction, so we won't") are genuinely independent judgments running on different data, and treating a rejected exemption as a bug rather than an expected branch of the flow is the mistake. For diagnosing which specific issuer response you're looking at, and whether it's worth an immediate retry, the Card Decline-Code Lookup tool covers the per-code detail this article doesn't.

TRA Thresholds and the Fraud-Rate Bands Everyone Misquotes

This is the exemption most misunderstood, and the misunderstanding compounds because the numbers themselves are quoted correctly more often than the concept underneath them is. The RTS Article 18 bands, confirmed independently through EBA Q&A guidance and Visa's own implementation documentation, are:

The pattern is intentional: the higher the value band you want to exempt, the lower your fraud rate has to be. A PSP with a fraud rate of 0.10% can apply TRA up to €100 but not up to €250.

Here is the part that gets quoted wrong constantly: the fraud rate is the requesting PSP's, calculated at PSP level, not the merchant's. Per the EBA's own clarification (echoed in third-party analysis of the RTS), no more granular breakdown is permitted — a PSP cannot claim a lower fraud rate for one merchant, one card type, one scheme, or one customer segment than its overall figure. A merchant with genuinely excellent fraud performance does not, on its own, "have a TRA-qualifying fraud rate." It contributes to whichever PSP's blended rate is being measured, and if that PSP's book is dragged down by other merchants or other transaction categories, the individual merchant's clean record doesn't unlock the exemption on its own.

The second layer is which PSP is doing the applying. TRA can be applied by the acquirer or by the issuer, and each qualifies independently on its own fraud rate — this is not a rule requiring both sides to clear the bar simultaneously. If the acquirer's rate doesn't qualify for a given band, the issuer can still apply TRA off its own fraud performance, entirely independent of whether the acquirer ever requested it. This is precisely why an acquirer can submit a technically-compliant TRA request and still see it rejected — the acquirer's qualification is necessary for the acquirer's own request, but it says nothing about what the issuer's risk engine will do with it, and the issuer isn't obligated to reason from the acquirer's fraud rate at all.

Two more details worth having in the room before you build a TRA program: the fraud rate calculation itself is unauthorized-plus-fraudulent remote transaction value divided by all remote transaction value of the same type, on a rolling quarterly window, with first-party ("friendly") fraud specifically excluded from the numerator. And the €500 regulatory ceiling is a maximum, not a floor — Stripe's currently published limits cap TRA availability well inside that ceiling (up to £220 for UK and Swiss merchants, up to €250 for EEA merchants), because Stripe's own fraud rate — not the regulatory ceiling — is what determines how much of the theoretical exemption room it can actually offer its users.

Building an Exemption Engine

An exemption engine's job is not to maximize the number of exemption requests sent — it's to sequence checks so that mandatory-authentication conditions get resolved first, discretionary exemption requests get tried in the order most likely to succeed, and a rejection routes cleanly into a challenge rather than a dead end.

A workable ordering, consistent with the pattern issuer risk engines are built to expect:

1. Resolve compliance-mandatory cases first. One-leg-out transactions (issuer or acquirer outside the EEA), transactions above the €500 regulatory TRA ceiling, and transactions where your own PSP's fraud rate is already running above its qualifying band all need to skip exemption logic entirely and go straight to full authentication — requesting an exemption you structurally can't win just adds latency and burns an issuer-trust signal for no benefit.
2. Try TRA before other discretionary exemptions, where the transaction value and current rolling fraud rate support it — it's the exemption with the broadest applicability and the one issuers are most tooled to evaluate automatically.
3. Fall back to low-value or trusted-beneficiary requests where TRA doesn't apply or isn't available at the current value band. Remember that low-value's consecutive-use and cumulative-spend counters are tracked by the issuer, not visible to the acquirer — a merchant cannot know in advance whether a given cardholder is on their fourth exempted transaction or their sixth, which means low-value soft declines will look unpredictable even when your own request logic is correct.
4. On a soft decline, retry immediately with SCA mandated — not with the same exemption flag resent, and not on a delay. The whole value of most exemptions is avoiding an active session; a delayed retry has usually lost that session already.
5. Log the rejection, not just the outcome. An issuer or BIN range that's rejecting a disproportionate share of otherwise-qualifying TRA requests is a signal worth tracking on its own — not because you can appeal an individual decline, but because a pattern across many transactions from one issuer is exactly the kind of aggregate evidence that supports an acquirer-led conversation with that issuer, the same lever described for general auth-rate optimization in Authorization Optimization: The Hidden Margin in Card Acceptance.

Trusted-Beneficiary Allowlisting in Practice

Trusted beneficiary is the exemption merchants have the least direct control over, and the mechanics explain why. Only the issuer can create or maintain a cardholder's trusted list, and only the cardholder can add or remove a merchant from it — an acquirer cannot apply this exemption on the merchant's behalf the way it can request TRA. The merchant's actual lever is narrower: request inclusion during a challenge, then check the response on every subsequent transaction.

In EMV 3DS terms, that means setting the 3DS Requestor Challenge Indicator to the whitelist-request value when a challenge is presented — signaling to the issuer that, if the cardholder completes the challenge, the merchant would like to be added to the cardholder's trusted list at the same time. Enrollment happens inside that authenticated moment, not as a separate API call the merchant controls. On future transactions, the merchant's 3DS Server should check the whitelist status field the ACS returns; a positive status means the issuer has the merchant listed for that cardholder, but critically, the issuer retains the right to step up authentication anyway if its risk model flags something suspicious in that specific transaction, trusted-listing status notwithstanding.

The operator implication is that trusted-beneficiary rates build slowly and only through completed challenges — you cannot batch-enroll existing customers into a trusted list retroactively, because the enrollment moment is tied to a live SCA event. This makes trusted beneficiary a compounding asset for high-repeat merchants (subscription services, frequent-purchase retailers) and close to irrelevant for one-time or low-frequency transaction profiles, since there's rarely a second visit to build the list from.

Delegated Authentication and Where Liability Actually Sits

"Delegated authentication" gets used loosely to describe two mechanisms that behave very differently on the one question that matters commercially: who eats the fraud loss.

The first is genuine delegation — a program under which an issuer explicitly pre-approves a third party (a wallet, a merchant's own authentication stack) to perform SCA-equivalent authentication in place of the issuer's own ACS, flagged in EMV 3DS via the issuer-delegation exemption value. Under Visa's Delegated Authentication Programme, this is a formal relationship: the delegate has to meet fraud-performance requirements on entry and on an ongoing basis, and has to flag at the transaction level that authentication was performed. When an issuer accepts a delegated claim under this kind of program, liability does move with it — but only for the delegates and merchants the issuer has actually vetted and documented, not as a blanket consequence of a merchant claiming to have "done its own SCA." An issuer that hasn't formally logged which merchants and categories it accepts delegation from is not in a strong position to defend that liability stance if a scheme review asks about it later.

The second mechanism is Visa's newer Data Only flow, including the Digital Commerce Authentication Program (DCAP) that took effect in 2026. This is not authentication at all — it's enriched data sharing. The merchant submits device ID, IP address, email address, and full billing address through Visa's data-exchange infrastructure; Visa validates and scores that data and passes it to the issuer's risk engine ahead of authorization, and Visa's own published figures put the authorization-rate improvement at roughly 280 basis points from enhanced data generally, with a further 50 basis points when full DCAP standards are met. None of that involves a cardholder challenge, and because no authentication event occurs, no liability shift occurs either — the merchant retains fraud liability on those transactions exactly as if 3DS had never been invoked. Confusing DCAP-style data sharing with delegated authentication is an expensive mistake to discover after a fraud spike: one moves liability, the other explicitly does not, and the two are easy to conflate because both are marketed as reducing friction.

Mastercard's position on delegated authentication and its own Identity Check equivalents could not be independently verified for this article — every Mastercard-specific domain attempted (developer.mastercard.com, mastercard.us/mastercard.com rules and transaction-processing pages) either returned a 403 or rendered no retrievable content, including with a browser user agent via direct fetch. Where Mastercard mechanics are referenced elsewhere in this piece — soft-decline code 65, the 3RI exemption category — the source is EMV 3DS server vendor documentation rather than Mastercard's own site, and operators running Mastercard-heavy portfolios should confirm Mastercard's current delegated-authentication liability position directly with their acquirer rather than assume it mirrors Visa's.

Measuring Exemption Performance

A dashboard that reports "exemption rate" as one number is making the same mistake as an auth-rate dashboard that reports a single blended percentage — it hides exactly the pattern that would tell you what to fix. Four numbers, tracked separately, do the job:

Attempt rate — the share of eligible transactions where an exemption was actually requested. A low attempt rate against a high theoretical eligibility (based on transaction value and current fraud-rate qualification) usually means the exemption engine's rule ordering is too conservative, not that the transactions don't qualify.

Acceptance rate (sometimes framed as its inverse, the issuer override rate) — the share of exemption requests the issuer actually honored versus soft-declined back to a challenge. This is the number that catches an issuer or BIN range quietly rejecting a disproportionate share of otherwise-qualifying requests — a pattern worth escalating to the acquirer relationship rather than treating as noise.

Challenge rate — the share of all attempted transactions, including exemption-requested ones, that ultimately ended up at a cardholder challenge. This is the number that should actually move as exemption programs mature; if it isn't moving despite a healthy attempt rate, the acceptance rate is where the problem lives.

Fraud rate — tracked on exempted transactions specifically, not blended into the overall book, because this is the number that keeps the whole program eligible in the first place. A TRA program that quietly lets fraud creep upward inside exempted transactions is spending down the fraud-rate headroom that made the exemption legal to request at all — and because the qualifying rate is calculated at PSP level with a rolling quarterly window, that deterioration shows up with a lag, after several months of transactions are already baked into the reported figure.

When Exemptions Backfire

The failure modes cluster around three patterns. First, requesting exemptions on transactions where the PSP's own rolling fraud rate has already drifted past the qualifying band for that value tier — every request in that state is a wasted round trip that also degrades the issuer's confidence in future requests from the same source, since it looks indistinguishable from a merchant that doesn't understand its own numbers. Second, treating a soft decline as a dead end rather than a retry trigger — the cardholder is still there, the fix is a challenge, and letting the transaction die instead converts a recoverable authentication delay into a lost sale exactly the way an unretried soft decline does anywhere else in the authorization flow. Third, chasing exemption volume as the metric that matters instead of challenge rate and fraud rate — a program that maximizes the number of exemption requests sent, irrespective of acceptance rate, is optimizing for a vanity number while the acceptance-rate and fraud-rate numbers that actually determine whether the program survives its next quarterly review go unwatched.

The broader regulatory backdrop is also shifting under this. PSD3 and the Payment Services Regulation are expected to clarify several currently ambiguous exemption scenarios — particularly around low-value contactless harmonization and MIT scope — inside the implementation window running through the rest of this decade. None of the mechanics in this article are likely to be upended wholesale, but the specific thresholds and scheme interpretations are worth re-checking against the RTS text as the PSR's clarifications land, rather than assuming the 2018 baseline holds indefinitely.