Beyond SCA: A Practical Guide to Low-Value, TRA, and Trusted Beneficiary Exemptions in 3DS

Strong Customer Authentication was built to cut fraud. It also cuts conversion. Every extra tap between "buy" and "confirmed" loses a percentage of buyers who simply give up, and merchants running high transaction volumes feel that loss on the bottom line every single day.

PSD2 anticipated this trade-off and built exemptions into the Regulatory Technical Standards for exactly that reason. An exemption is a legal basis to skip the SCA challenge and route the transaction frictionless through 3D Secure, without giving up compliance. Three of them matter most in practice: Low-Value, Transaction Risk Analysis, and Trusted Beneficiary. Each works on a completely different mechanism, and most payment teams only use one when they should be stacking all three.

Low-Value: the simplest exemption, with a catch

The Low-Value exemption is the one merchants reach for first because the rule sounds easy: transactions under €30 don't need SCA.

That's true, but incomplete. The RTS caps how often a card can ride on this exemption before the issuer has to step in anyway. A card gets a maximum of five consecutive low-value transactions without a challenge, or a cumulative €100 in unchallenged spend since the last time SCA was completed on that card, whichever comes first. Cross either line and the next transaction requires a full authentication, even if it's a €5 coffee subscription charge.

Who enforces the counter matters too. The issuer tracks it, not the merchant or the acquirer. A merchant applying the exemption is making a request based on the amount; whether it actually goes frictionless depends on the issuer's own running count for that card, which the merchant can't see. This is why a €25 transaction can sail through frictionless on one attempt and get challenged on the next: the card simply hit its counter.

For subscription and micro-transaction businesses, this creates a predictable pattern worth planning around. If your average order value sits comfortably under €30, expect roughly one in five to six transactions to trigger a challenge purely on volume, regardless of how clean your fraud profile is. Building that challenge flow properly, rather than treating it as an edge case, avoids a chunk of preventable cart abandonment.

Transaction Risk Analysis: the exemption that actually requires work

TRA is where most of the real authorization-rate gains live, and it's also the exemption that takes the most infrastructure to use well.

The mechanism: either the acquirer or the issuer can claim TRA on a transaction, provided their own reference fraud rate for card-not-present payments stays under a threshold tied to the transaction value. The EBA set three bands: a fraud rate below 0.13% clears transactions up to €100, below 0.06% clears up to €250, and below 0.01% clears up to €500. Above €500, TRA isn't available at all, full stop.

Here's the part that trips people up. The fraud rate isn't calculated per transaction. It's a rolling quarterly average across the PSP's entire card-not-present portfolio, reported to the national regulator every 90 days. One bad month of chargebacks can push the whole book above threshold and shut off TRA for everyone processing through that PSP, not just the risky merchants. This is exactly why TRA punishes sloppy fraud monitoring on any single high-risk merchant in a shared portfolio. It's a collective number.

Claiming TRA also isn't a checkbox. The acquirer or issuer has to run real risk analysis before requesting the exemption, factoring in things like the customer's transaction history, device and behavioral signals, delivery address versus billing address, and whether the spending pattern looks like the account holder or looks like someone else. The 3DS v2 message set was built specifically to carry this data to the issuer, which is why merchants sending rich, accurate data elements through 3DS see meaningfully better TRA acceptance than those sending the bare minimum.

And even a compliant TRA request can be overridden. The issuer has the final say. If the issuer's own risk engine doesn't like the transaction, it comes back as a soft decline requiring a full SCA challenge, exemption or not. Any merchant relying on TRA needs a checkout flow that can catch that soft decline and immediately reroute into a challenge, rather than treating it as a failed payment. Miss that step and you're losing sales that were never actually declined, just redirected.

Trusted Beneficiary: exemption by relationship, not by risk score

Trusted Beneficiary works on a different logic entirely. Instead of scoring the transaction, it scores the relationship between the cardholder and the merchant.

A cardholder adds a merchant to their trusted beneficiary list, called whitelisting, through their own bank's online banking or app. That's the critical detail: the merchant cannot add itself. The action has to originate from the cardholder's side, inside a channel controlled by the issuer, usually as a prompt right after a successfully authenticated transaction with SCA. Once whitelisted, every future transaction from that merchant to that card can go frictionless, with no value cap and no counter to run out.

This makes Trusted Beneficiary the strongest exemption of the three once it's live, and also the slowest to build up. It depends entirely on the issuer offering the whitelisting prompt and the cardholder actually completing it, and adoption of that UX varies a lot by bank and by market. A merchant can't force it. What a merchant can do is make the first SCA-authenticated purchase count: prompting the customer, in plain language, to whitelist the merchant with their bank right after that first checkout, when the transaction is fresh and the customer is already engaged.

Subscription businesses and repeat-purchase merchants get the most out of this exemption because the payoff compounds. One successfully whitelisted card removes friction from every renewal or reorder going forward, which is a very different economics than TRA, where you're re-earning frictionless treatment transaction by transaction against a rolling fraud rate.

Why the smartest merchants stack all three

None of these exemptions are mutually exclusive, and treating them as separate strategies wastes the overlap between them.

A typical high-volume order flow should check eligibility in this order: is the customer already trusted-beneficiary whitelisted? If yes, done, frictionless with no cap. If not, does the transaction qualify for Low-Value and has the card's counter not been exhausted? If not, does TRA clear based on current portfolio fraud rate and the transaction's risk signals? Only if none of the three apply should the flow fall back to a full SCA challenge.

Running that cascade requires two things most merchants underestimate: clean, real-time visibility into which exemption a given card and transaction qualify for, and a 3DS integration capable of sending the request with the right exemption flag and correctly handling whatever the issuer sends back, including overrides. Get the cascade wrong and you either request an exemption you don't qualify for, which the issuer will reject anyway, or you fail to request one you did qualify for, which means eating an unnecessary challenge and the drop-off that comes with it.

One more thing worth saying plainly: exemptions are not a substitute for actual fraud prevention. TRA specifically depends on keeping your fraud rate low in the first place. Merchants who chase frictionless rates by requesting TRA aggressively while ignoring the fraud signals feeding it are working against their own future eligibility. The exemption is a reward for good risk management, not a bypass around it.

What's changing under PSD3

The proposed Payment Services Regulation and PSD3 are still moving through the EU legislative process, but the direction on exemptions is already visible: more granular fraud rate bands for TRA, and potential changes to which party, acquirer or issuer, holds the right to apply which exemption. Nothing here is final, and timelines have shifted before. Merchants building 3DS logic now should keep the exemption engine configurable rather than hardcoding today's thresholds, because those numbers are the part most likely to move.

‍