Blog / Ravelin University, 3DS & SCA, Payments & payment fraud

SCA transaction optimization guide & differences between out-of-scope, TRA and other exemptions

To benefit from the plentiful opportunities for frictionless, smooth shopping experiences, merchants would be wise to understand exactly when to apply SCA – and when it's not needed.

24 July 2025

SCA transaction optimization guide & differences between out-of-scope, TRA and other exemptions

There’s no question that PSD2 has changed the nature of online payments and helped boost consumer confidence in online shopping. It was arguably one of the factors that helped ecommerce grow by leaps and bounds – now expected to reach revenues of $707 billion in 2025.

PSD2 effectively transformed the online landscape, at least in Europe. It’s a brilliant piece of legislation that boosted entire industries. However, it’s also created confusion, even so many years later.

Not all transactions – nor all online transactions – need a secure customer authorization (SCA) challenge. Some do not fall under the scope of the PSD2 in the first place, while others can be exempt.

Understanding these nuances allows PSPs and merchants to be able to deliver the best possible experience to shoppers while staying compliant.

Are you applying 3DS checks dynamically, only when it’s needed? Are you missing safe opportunities to treat provably good customers to frictionless shopping journeys? And what can you do about this?

When to not apply 3DS

Assuming you have a solid payment fraud solution running in the background, your goal ought to be to only apply 3D Secure/secondary authentication when required per SCA regulations.

The simplest way to figure out what to do is to assume all transactions require SCA, unless they are out of scope or unless they can be exempt.

Let’s take a closer look.

*Note that the below applies to the EEA and UK, strictly speaking. Other regions with similar SCA legislation tend to have similar expectations. However, you should confirm this with local regulation experts.

The three types of exceptions under PSD2 SCA

Under the EU’s PSD2, there are three ways in which a transaction can be compliant without needing to involve an SCA challenge – and, as is expected, possibly under PSD3 and PSR1: out-of-scope transactions, exemptions, and TRA exemptions.

1. Out-of-scope for SCA transactions

These transactions do not fall within the scope of SCA, so by nature they are not subject to the PSD2 directive’s requirements.

Out-of-scope transactions include:

Cash payments: Transactions conducted entirely in physical currency are exempt, as the PSD2 only applies to online payments.
Check payments: Payments made using paper checks are also exempt.
Gift cards & other anonymous transactions: Gift cards are completely anonymous and not subject to checks – and this is why fraudsters tend to use them for ecommerce fraud as much as possible.
MOTO: Mail order and telephone orders are not considered electronic payments and are thus not within the purview of PSD2 SCA.
One-leg-out (and two-leg-out): When either the issuing country of the acquirer country is outside the EEA or the UK, PSD2 rules don’t fully apply but are instead implemented on a best-effort basis.
MIT transactions: Merchant-initiated transactions that are preauthorized and for the same amount – including direct debits and recurring card payments – don’t require SCA. These are, for example, subscriptions or top-ups. Keep in mind that preauthorized MIT transactions for varying amounts can fall within scope, so make sure to check with your acquirer.

How to approach out of scope transactions

When a transaction is out of scope, it is entirely up to the merchant whether they will introduce any failsafes and additional challenges.

Crucially, for some of these transactions, it’s not possible to implement SCA even if desired.

2. Exempt transactions under PSD2 SCA

If the transaction is within scope, it could still be subject to one of the exemptions defined in the PSD2 Technical Standards. You can estimate whether the transaction is exempt with a SCA exemption engine, in which case it will fall under one of these categories:

Low value exemption: Applies to small amount payments only. Typically, these are less than €30/£25 though there are rules defining the maximum amount of consecutive payments for this card and cardholder. Generally, merchants do not have a way of knowing this, as the payments are typically made to other merchants. The issuer will then reject the request for the exemption if they have to.
Low risk exemption: Payments can also be exempt because they are low risk – but it has to be provable as low risk. Typically, this is done through Transaction Risk Analysis (TRA), which will come from your payment fraud detection solution. PSD2 regulation defines specific reference low-risk fraud rates, and card issuers will have their own as well.

Trusted beneficiary: If a cardholder has marked a merchant as a “trusted beneficiary”, future purchases from them will not require authentication. However, in this case, the liability for fraud shifts to the merchant, and the merchant can request whitelisting from the issuer. This is achieved through programs such as Visa’s Trusted Listing and Mastercard’s Identity Check.

Secure corporate payments: These are B2B payments between known corporate entities, which have already established trust, made through secure corporate environments. This is an issuer-side exemption.

How to request a PSD2 exemption

Unlike out-of-scope transactions, exemptions are requested by the merchant from the issuer. No merchant or PSP can automatically apply those exemptions without requesting them through their authorization or authentication request.

And, as would be logically expected, the better evidence you can provide in the form of data, the more likely you are to have the issuer agree and grant an exemption.

Cheat sheet for merchants – determining when to apply SCA or not

The below steps should ensure that you remain compliant, safe, as well as taking advantage of opportunities for frictionless transactions and maximizing acceptance.

Once a transaction comes in:

Conduct TRA using your payment fraud solution. Then:
1. Always block “prevent” recommendations.
2. Send “review” recommendations to authentication, regardless of other considerations
3. Transactions that are deemed safe and receive “allow” recommendations can move forward to step 2.
Apply compliance logic:
1. Is the transaction one leg out? Then authorize.
2. Is the card American Express? Always authenticate*.
3. Is the transaction above €500? Authenticate.
4. Is the transaction above reference fraud rates for that acquirer? Authenticate.
5. If none of the above are true, you can optimize the transaction.
Which exemption and/or which route?

Use a transaction optimization solution to determine whether you can request applicable exemptions:
1. Is the transaction row risk per TRA? Request an exemption/no challenge.
2. Is the transaction low value? Request an exemption/no challenge.
3. In all other cases, authenticate. Send the transaction through to the issuer, including as much data as you can to increase the chances of acceptance. They may return a challenge or authorize frictionless.
4. Consider payment orchestration at this stage as well, to maximize your chances of acceptance and secure the lowest possible fees.
Payment authorized, declined or authentication challenge requested. The issuer will respond with their preferred route: They might authorize the payment, decline it for one of various reasons (including reasons unrelated to SCA, such as insufficient funds), or request cardholder authentication.

*Important note: Due to unique American Express guidelines, all transactions in the EEA and UK require authentication, even if they belong to the above categories.

The better you understand the logic behind SCA mandates, the better payment journeys you can serve your customers.

Frequently Asked Questions

How will I know if my exemption request was successful?

There is no way to know for sure if an exemption request was honored by the issuer, but it can be assumed.

Authorization route → If there was no soft decline and the transaction was authorized, you can assume that your exemption request was successful. The transaction could still be declined for non-PSD2 purposes though (eg: insufficient funds).

Authentication route → If frictionless authentication was performed, you can assume that your exemption request was also successful.

What’s the difference between SCA exemptions and out-of-scope transactions?

In both cases, the cardholder will not have to authenticate themselves using additional factors.

However, with out-of-scope transactions, you can probably ignore any SCA rules as they don’t apply. Exemptions have to be requested from the issuer, which might involve the acquirer or your 3DS provider. The issuer might accept that request or reject it – including for reasons beyond the merchant’s control or knowledge.

When does liability shift to the issuer?

Liability shifts are a complex matter. Generally speaking:

The use of exemptions or delegated authentication will mean that liability sits with the acquirer/merchant
Frictionless 3D Secure authentication (without an exemption applied) often means liability sits with the issuer.
For trusted beneficiaries, if the issuer accepts the trusted listing, the liability falls with the issuer.
For secure corporate payments, the liability falls with the issuer.

However, each card scheme will have different rules on whether liability shifts to the acquirer/merchant or issuer when an exemption is accepted, or delegated authentication is used. This can often be influenced by whether the acquirer or the issuer applies the exemption.

Related resources

Nikoleta Dimitriou, Senior Content Manager

SCA transaction optimization guide & differences between out-of-scope, TRA and other exemptions

When to not apply 3DS