All entries
Chapter VIII
Journal · 22 Sept 2026 · 11 min read

SCA Exemptions in 2026: EU vs UK Rules for 3DS2

PSD2 SCA exemptions from the RTS text: TRA fraud-rate bands, EU vs UK limits, MIT scope, liability, and how Stripe, Adyen and Checkout.com request them.

Since 19 March 2026 the UK has had no fixed contactless limit. The FCA replaced the £100 cap with a rule that lets each payment provider decide which contactless payments are low enough risk to skip strong customer authentication. Most pages ranking for "SCA exemptions" still quote £100 and £300, and the EU account-information re-auth window they describe is 90 days. It has been 180 since July 2023.

That is the pattern with SCA content. It was written in 2019 and 2020, before the regulation settled, and the numbers have moved underneath it. This guide works from the regulatory text as it stands in September 2026: Commission Delegated Regulation (EU) 2018/389 (the RTS), its 2022/2360 amendment, the FCA's UK SCA-RTS, and the EBA's Q&A answers. It then covers the part most guides skip, which is how an exemption actually travels through 3DS2 and your PSP's API, and who pays when one goes wrong.

What Are SCA Exemptions Under PSD2?

PSD2 requires two independent factors (knowledge, possession, inherence) for electronic payments the payer initiates. The RTS then carves out specific situations where a payment service provider may skip that. Two things about the wording matter to engineers.

First, exemptions are optional for the PSP. The issuer can always ignore your request and demand a challenge. The only mandatory one is the EU Article 10a, which forbids banks from applying SCA on AISP access within the 180-day window.

Second, an exemption is different from being out of scope. Merchant-initiated transactions and genuine mail or telephone orders are not exempt from SCA. SCA never applied to them in the first place. That distinction changes which flag you send, and I come back to it below.

The Full List of SCA Exemptions: RTS Articles 10 to 18

ArticleExemptionEU conditionUK SCA-RTS
10 / 10aAccount informationBalance and 90 days of transactions; re-auth every 180 days (since 25 Jul 2023)TPP reconfirms consent every 90 days; no bank re-auth (PS21/19)
11Contactless at point of sale€50 per payment; cumulative €150 or 5 in a rowNo fixed cap since 19 Mar 2026; PSP judges low risk
12Unattended transport and parking terminalsNo amount set in the textSame
13Trusted beneficiariesSCA to add or change the listSame
14Recurring paymentsSame amount, same payee; SCA on the firstSame
15Transfers to yourselfBoth accounts at the same PSPSame
16Low-value remote€30 per payment; cumulative €100 or 5 in a row£25; cumulative £85 or 5 in a row
17Secure corporate processesNon-consumer, dedicated protocols, regulator satisfiedSame
18Transaction risk analysisFraud-rate bands up to €500Bands up to £440

One detail from the EBA Opinion (EBA-Op-2018-04, paragraph 43) trips up implementations: the cumulative limits in Articles 11 and 16 are either the count or the amount, at the issuer's choice. Not both. An issuer tracking the count will force SCA on the sixth €2 coffee regardless of total value. You cannot predict which rule a given issuer uses, so any client-side logic that tries to "stay under" the low-value counter is guesswork.

Low-Value Exemption: €30 in the EU, £25 in the UK

The low-value exemption is the one merchants ask for most and get least. The issuer holds the counter, because only the issuer sees every transaction on the card. A merchant flagging a €12 payment as low value is making a request, and if that card has already had five exempted payments since its last SCA, the issuer will step up or soft-decline.

The UK figures are slightly lower after conversion than the EU ones: £25 single and £85 cumulative against €30 and €100. If you run one checkout across both regions, keep the thresholds per currency and per regime, not a single number converted at runtime.

TRA Exemption Thresholds: Fraud Rates by Band

Transaction risk analysis (Article 18) is the exemption that actually moves conversion, because it covers far larger tickets. The PSP applying it must keep its fraud rate for the relevant payment type at or below the reference rate for the band:

Exemption threshold (EU)UK equivalentRemote card fraud rateRemote credit transfer fraud rate
€100£850.13%0.015%
€250£2200.06%0.01%
€500£4400.01%0.005%

The calculation in Article 19 is harsher than most people assume:

  • It is by value, fraud value divided by total remote value of that type.
  • Fraud counts whether or not the money was recovered. A chargeback you won still counts as fraud.
  • The denominator includes both SCA-authenticated and exempted transactions.
  • It runs on a rolling 90-day basis, and the EBA says it is per PSP, not per merchant.
Article 20 then sets the penalty. Two consecutive quarters above the reference rate and the PSP must stop using TRA in that band. It can resume after one clean quarter. That is why acquirers are selective about which merchants they request TRA for: one merchant with poor fraud controls can push the acquirer's whole portfolio over 0.01% and cost every merchant the €500 band.

Real-time analysis must also check six risk factors listed in Article 18(2)(c), including abnormal spending patterns, unusual device or software, malware signs, known fraud scenarios, an abnormal payer location and a high-risk payee location. If your PSP asks for device and browser data in the 3DS payload, this is why.

Are MIT and MOTO Payments Exempt From SCA?

Neither is an exemption. Both are out of scope.

EBA Q&A 2018_4031 says transactions the payee initiates under a mandate, with no action by the payer, "are therefore not subject to strong customer authentication". Q&A 2018_4131 extends that to variable amounts and irregular timing, as long as the merchant holds a mandate. The mandate setup, if done remotely, still needs SCA.

MOTO is narrower than people treat it. Q&A 2019_4788 accepts non-electronic mail and phone orders as out of scope, but card details typed into a web form by the customer, even for a hotel booking arranged by phone, are not MOTO.

The schemes disagree on labels. Mastercard carries 3RI recurring as an exemption-style flag, while Visa treats MITs as out of scope. In practice your PSP maps this for you, but it explains why the same subscription renewal shows up under different indicators in each network's reporting. The EBA/ECB 2025 fraud report found 22% of non-SCA remote card payments were MITs, and another 26% were reported as "out of scope" in a way the EBA says needs investigation. My read: a chunk of that 26% is merchants flagging customer-present payments as MIT to avoid friction. It is also the first place a regulator will look.

Who Applies SCA Exemptions: Issuer vs Acquirer Liability

Table 2 of the EBA Opinion is blunt: "payees can never decide whether or not to use an exemption." The merchant asks. The acquirer can apply Articles 11, 12, 14, 16 and 18, but not trusted beneficiaries, which belong to the issuer. The issuer always has the final say.

Liability follows whoever made the call. Adyen's documentation puts TRA plainly. If the issuer applies it, "the chargeback liability shifts to the issuer". If you or your acquirer request it and it is granted, "the chargeback liability stays with you." That is the trade: fewer challenges, but you give up the liability shift that 3DS would have given you. A fraud chargeback (Visa 10.4, Mastercard 4837) on an acquirer-exempted payment lands on the merchant. My chargeback reason codes guide covers what happens next.

How 3DS2 Signals an Exemption: threeDSRequestorChallengeInd

In EMV 3DS the exemption request travels in threeDSRequestorChallengeInd:

ValueMeaningVersion
01No preference2.1+
02No challenge requested2.1+
03Challenge requested (requestor preference)2.1+
04Challenge requested (mandate)2.1+
05No challenge, TRA already performed2.2+
06Data share only2.2+
07SCA already performed (delegated)2.2+
08Trusted listing exemption2.2+
09Challenge requested, add to trusted list if challenged2.2+
10 / 11Low value / secure corporate payment2.3.1

Values 05 to 09 come from the 2.2 protocol, so a 2.1 flow cannot express a TRA request in 3DS at all. The low-value and secure-corporate codes only arrived in 2.3.1. Before that, many PSPs send those exemptions in the authorisation message instead, skipping 3DS entirely. That is the other path: an authorisation with an exemption flag and no authentication, which the issuer either approves or soft-declines.

Stripe vs Adyen vs Checkout.com: Requesting Exemptions via API

This is where the three PSPs really differ.

StripeAdyenCheckout.com
Can the merchant name an exemption?NoYesYes
Fieldpayment_method_options.card.request_three_d_secureadditionalData.scaExemption3ds.exemption
Valuesautomatic, any, challengelowValue, secureCorporate, trustedBeneficiary, transactionRiskAnalysislow_value, transaction_risk_assessment, trusted_listing, secure_corporate_payment, recurring_operation, out_of_sca_scope, and six more
Challenge preferenceOnly forcing more 3DSthreeDSRequestorChallengeInd 01–063ds.challenge_indicator

Stripe's position is that you "can't use Stripe APIs to manually turn off 3DS". Its engine picks exemptions for you, and the only lever is asking for more authentication. There is an exemption_indicator field, but it exists for importing results from a third-party 3DS provider. For a small merchant this is the right default. For a merchant with its own fraud model and a strong fraud rate, it means you cannot turn that advantage into fewer challenges.

Adyen and Checkout.com both let you name the exemption. Checkout.com's enum is the most complete of the three, and its retry behaviour is worth knowing. When an issuer rejects an exemption, the payment returns response code 20154 and Checkout.com re-runs it through 3DS automatically unless you send 3ds.allow_upgrade: false. If your UI assumed a frictionless payment, the customer suddenly sees a challenge you did not plan for.

A minimal Checkout.com request for a TRA exemption looks like this:

{
  "amount": 18000,
  "currency": "EUR",
  "source": { "type": "token", "token": "tok_..." },
  "3ds": {
    "enabled": true,
    "exemption": "transaction_risk_assessment",
    "challenge_indicator": "no_challenge_requested",
    "allow_upgrade": true
  }
}

Note that €180 sits in the €250 TRA band, which only works if your acquirer's fraud rate is at or under 0.06%.

Handling SCA Soft Declines: Visa 1A and Mastercard 65

When an issuer refuses an exemption at authorisation, it returns a soft decline: Visa response code 1A, Mastercard 65, both meaning "authentication required". That payment is not failed. The correct response is to run 3DS and resubmit with the authentication data attached. Treat 1A and 65 as a state transition in your payment state machine, not an error, and make sure the retry reuses the same idempotency key scope for the order so a double-submit cannot charge twice.

Will PSD3 and the PSR Change SCA Exemptions?

The Council compromise text of the Payment Services Regulation (ST 8221/26, 17 April 2026) keeps the existing structure but moves more into law. Article 3 defines MITs and MOTO for the first time. Article 85(11) confirms exemptions are optional and hands their design to a new EBA technical standard. Article 85a adds an exemption for recurring credit transfers initiated at the payee's request. Article 89 asks the EBA to set out how fraud rates are split between issuing and acquiring PSPs. My PSD3 vs PSR guide covers the timeline, and today's thresholds stay in force until the new RTS applies.

My prediction: the Article 89 work is the one that bites. Today a PSP that both issues and acquires can blend its fraud rate across both books. Once the EBA splits the calculation, some large acquirers will lose the €500 TRA band, and merchants will see more challenges on €250 to €500 baskets. That is likely to show up in 2028 rather than next year, but it is the change to plan for.

The UK is heading the other way. The contactless change swaps a fixed number for PSP judgement, and I expect the FCA to be asked to do the same for low-value remote payments. Expect EU and UK exemption logic to diverge further, not converge.

What This Means for Payments Engineers

1. Store the exemption requested and the outcome on every payment. Record the requested exemption, the ECI, the transStatus, and whether a soft decline occurred. Without this you cannot tell your acquirer which exemptions are working. 2. Split thresholds by regime. EU and UK limits differ and one of them no longer has a number. Keep a config per regime rather than converting at runtime. 3. Do not flag MIT unless you hold a mandate. Customer-in-session payments marked as MIT are the first thing an audit will find, and the EBA is already asking about them. 4. Build for 1A and 65 as expected states. Budget for a challenge on any exempted payment, including ones your PSP retries automatically. 5. Price the liability. Every exemption you request moves fraud liability back to you. Compare the conversion gain to your fraud chargeback rate on the same band before turning TRA on. 6. Check your PSP's 3DS version. On 2.1 you cannot signal TRA inside 3DS, only at authorisation. If you want a second opinion on an exemption strategy across EU and UK acquirers, you can reach me via Tom Wang.

Key Takeaways

  • The RTS lists nine exemption articles, but only TRA, low value, recurring and trusted beneficiaries matter for most online checkouts.
  • The UK has had no fixed contactless cap since 19 March 2026. UK low value is £25 / £85, EU is €30 / €100.
  • TRA fraud rates count recovered fraud and are calculated per PSP, which is why acquirers ration the exemption.
  • MIT and MOTO are out of scope, not exempt, and the mandate setup still needs SCA.
  • A requested exemption moves fraud liability to the merchant. An issuer-applied one does not.
  • Stripe decides exemptions for you. Adyen and Checkout.com let you name them.