Merchants in the European Economic Area (EEA), UK, or those handling European cards, are required to use 3D Secure (3DS) to safeguard transactions. However, there are times when merchants may prefer to avoid adding friction for their customers.
That’s where Strong Customer Authentication (SCA) exemptions come into play.
In this guide, we’ll discuss the different types of SCA exemptions, explore their pros and cons, and explain how they impact liability.
What are SCA exemptions?
Under the European Union’s Payment Services Directive (PSD2), there are special scenarios—known as SCA exemptions—that let you skip 3DS when making payment transactions. These exemptions are requested for each transaction, but it’s the issuing bank that decides whether to grant them.
The four SCA exemptions explained
Under the current SCA requirements, merchants and card issuers can utilize four SCA exemptions, which allow customers to complete a payment without a 3DS challenge.
Low-value payment exemptions
For payments under €30, £25, or the local currency equivalent, merchants can request a low-value payment exemption. However, there’s a cap on how many of these transactions a cardholder can make before authentication is required, meaning customers may still face challenges even when this exemption is applied.
Transaction Risk Analysis (TRA) exemptions
The TRA exemption allows transactions to be processed without the 3D Secure (3DS) flow, depending on the processor’s fraud rating. This exemption can apply to transactions up to €100, €250, or even €500 or the sterling equivalent (see the table below for more information). Issuers can also initiate a request for a TRA exemption.
.avif)
Secure corporate payment exemptions
This niche exemption applies to the use of secure corporate cards that are not assigned to a specific individual, such as those used by a team for office expenses. It exists because authenticating a cardholder is practically impossible when no designated sole cardholder exists.
Trusted beneficiaries list exemptions
After a customer completes an initial 3DS transaction with a merchant, the merchant can request the issuing bank to add them to the buyer’s trusted beneficiaries list. If the buyer agrees, future transactions with that merchant will be exempt from 3DS. In principle, this exemption is incredibly powerful for merchants; however, the challenge is that few, if any, issuing banks currently support it.
What exemptions should merchants use?
Being aware of all available exemptions is crucial for a merchant utilizing 3DS. However, as a general rule of thumb, most merchants should focus primarily on low-value and Transaction Risk Analysis (TRA) exemptions as essential to their overall payment strategy.
Understanding the impact of SCA exemptions on liability shift
A key benefit of 3DS for merchants is the liability shift for fraudulent transactions. When a transaction is authenticated through 3DS, liability for fraud generally shifts from the merchant to the card-issuing bank.
This means that if a customer disputes a transaction and it is verified through 3DS, the merchant is generally protected against fraudulent chargebacks.
However, this liability shift doesn’t apply when a merchant requests an SCA exemption. By bypassing 3DS, the merchant assumes the liability for potential fraud—though this is often a calculated decision based on the transaction’s perceived low risk.
As we’ll now explore, The key to an effective 3DS strategy with exemptions lies in balancing the reduced friction from skipping authentication against the financial risk of taking on liability for fraud.
Can an issuing bank apply for an exemption?
Yes, an issuing bank can apply for an exemption, including for low-value payments. For instance, a merchant might request a 3DS challenge, but the issuing bank may decide to skip it to provide a smoother, frictionless customer experience. In this scenario, the merchant still benefits from the liability shift. Since the bank chose not to challenge the customer, the liability for fraud remains with the bank.
Do 3DS exemptions exist outside of SCA in Europe?
Yes, markets outside of Europe that mandate 3DS also offer exemptions. For instance, under the Australian 3DS mandate, merchants with low fraud rates can qualify for exemptions.
However, the way exemptions are applied differs by region. In Europe, exemption requests are made at the transaction level. In contrast, Japan follows a different model, where transactions are categorized as in-scope or out-of-scope for 3DS, without a request process.
When operating in these regions, it’s important to explore the specific rules and nuances of how 3DS exemptions are handled locally.
Using exemptions to shape a 3D Strategy
More and more merchants are realizing that there is no one-size-fits-all approach to authentication, and simply applying 3D Secure to every payment leads to less-than-optimal outcomes.
Let’s explore three use cases where merchants have optimized their payment flows using SCA exemptions:
SCA exemption use case #1
Company X, which specializes in gift cards with an average order value (AOV) of €20, primarily acquires customers through online social media advertising. To reduce checkout friction and minimize customer drop-off, Company X is willing to accept some fraud risk on transactions under €30. Therefore, it utilizes low-value payment exemptions to enhance the purchasing experience for most customers.
SCA exemption use case #2
Company Y, a retailer of high-end scented candles and diffusers, has an AOV of €150 and primarily serves repeat customers. It implements TRA exemptions for returning customers on transactions under €150. Although its processor allows a threshold of €250, Company Y opts for a lower limit to stay within its risk tolerance.
SCA exemption use case #3
Company Z offers mid-range watches priced between €150 and €500, along with accessories priced from €10 to €30. While prioritizing a seamless customer experience, Company Z has a low tolerance for fraud due to past incidents. It applies low-value payment exemptions for accessory purchases due to their low risk but uses TRA exemptions for returning customers making transactions between €30 and €250.
What are out-of-scope transactions?
Out-of-scope transactions are those that fall outside the regulations of SCA and, therefore, don’t require 3D Secure (3DS) authentication.
Though different from exemptions, these transactions should still be considered when developing an authentication strategy.
Here are examples of out-of-scope transactions:
Subscriptions and scheduled payments
Once a customer provides their card details during an initial payment, subsequent payments—such as subscription renewals or scheduled top-ups—are considered out of scope for SCA, as they are classified as merchant-initiated transactions.
Mail Order and Telephone Order (MOTO) Payments
While mail orders are less common today, telephone orders still occur. Since the customer provides their card details over the phone, these transactions do not fall under SCA requirements. It’s worth noting, however, that there is growing debate under PSD3 to potentially include MOTO payments in SCA, though resistance exists because many MOTO customers are older and may have difficulty using modern authentication methods.
Anonymous Cards
Prepaid or virtual cards are not subject to SCA, as they are not linked to an identifiable individual and thus fall outside the scope of authentication regulations.
One-Leg-Out Scenario
SCA only applies when both the payment processor and the customer are within the EEA or UK. The transaction is considered out of scope if either party is outside these regions. For example, a transaction made using a US-issued card wouldn’t require 3DS authentication, even if the merchant is in the EEA.
Shape an SCA exemption strategy
If you’re exploring SCA exemptions and wondering where to begin. This is typically the process that we walk our merchants through.
- Start by calculating your risk appetite
The first step is to determine your business’s risk tolerance, which is often shaped by the nature of your products, services, and customer base. For example, exemptions can be highly beneficial for returning customers, as they help reduce friction, and the risk is generally lower due to the established trust in the relationship. Understanding how much risk you’re willing to accept will guide your exemption decisions. - Analyze real and projected outcomes
Examine how your transactions perform both with and without 3DS. Consider factors like authorization rates, customer abandonment, and regional trends. For instance, if 3D Secure results in higher authorization rates in specific regions, weigh that against the benefits of using exemptions, which might improve the customer experience but could lead to a slight dip in authorization rates. Running these analyses will help you identify where exemptions can deliver the most value. - Run some A/B tests to find the right balance.
Testing different strategies is crucial. Use A/B testing to compare how transactions perform with and without exemptions across various segments of your customer base. This will help you identify the optimal balance between reducing customer friction and managing fraud risk. - Evaluate your use case
Think critically about why you’re implementing exemptions and what outcomes you expect. Are you aiming for higher conversion rates, a smoother checkout experience, or reduced fraud-related costs? Once you have clear goals, regularly assess your strategy’s performance to ensure it meets those objectives. Make adjustments as needed to maximize the benefits of applying exemptions.
Optimize your approach to SCA using exemptions
Leveraging SCA exemptions is not just about compliance—it’s a strategic move to enhance the customer journey while safeguarding your business against fraud. By carefully assessing your risk tolerance, analyzing transaction data, and experimenting with different approaches, you can craft an authentication strategy that strikes the perfect balance between security and convenience.
Take a look at our blog on the key questions to ask when building an optimal 3DS strategy.
(1).jpg)
