PSD2 SCA: Connecting the dots between the SCA exemptions, 3DS frictionless flow, and fraud liability protection
What are the SCA exemptions?
With PSD2 SCA coming into effect, most countries in European Economic Area (EEA) have imposed strong customer authentication since December 31, 2020. Before the mandate, merchants or acquirers would request authentication from issuers only if they saw it as necessary. However, the regulator has inverted the default by requiring all transactions to be strong customer authenticated unless PSPs apply for an exemption. This mandate is to promote the security of electronic payments in the region.
There are several exemptions that PSPs can apply. Recurring payments (RP), transaction risk analysis (TRA), and low-value payments (LVP) are the commonly used exemptions.
RP is a passive exemption. It is the default exemption for all recurring transactions since the customers are not in a browser session. To use this exemption, merchants must obtain an SCA when initially setting up the recurring agreement. Also, acquirers must correctly flag the transactions with the recurring indicator and reference the original transaction’s scheme ID (Visa TID or Mastercard Trace ID).
TRA and LVP are active exemptions on the other hand. PSPs must have a system in place to assess the eligibility for using the exemption on a per-transaction basis.
TRA is the most popular exemption. Both acquirers and issuers can apply for a TRA exemption without a frequency limit if their fraud score is below certain thresholds. However, before applying for a TRA exemption, PSPs should adequately assess the transaction risk, such as checking velocity, user IP, and cardholders’ behaviour.
Using the LVP exemption requires no sophisticated technologies. PSPs can apply for this exemption so long as the transaction meets the criteria of €30 or less, and it’s a one-off customer-initiated transaction. However, since PSPs are not required to perform a risk assessment, the application of LVP is more restrictive:
- The maximum number of consecutive transactions without SCA = 5
- The maximum cumulative amount of transactions without SCA = €100
The issuers are responsible for keeping a tab on how many LVPs have been performed on a card and when the last authentication was. Unfortunately, the acquirers or merchants do not have visibility into that.
How does SCA exemption lead to a 3DS frictionless flow?
3-Domain Secure Protocol v2 (3DS2) is the widely used method to meet the SCA requirements. Unlike the traditional v1 protocol, 3DS2 introduces the concept of frictionless flow. From the perspective of PSD2, the frictionless flow is the “channel” that issuers use when they decide to apply or accept the SCA exemption on a given transaction.
When merchants or acquirers initiate the 3DS process, the protocol collects device fingerprints and shares browser data with the issuer’s Access Control Server (ACS) behind the scene. Then, ACS will perform transaction risk analysis against their fraud engines using this information. Either two things can happen; the ACS imposes a challenge by requesting an OTP or an out-of-band authentication via the banking app, or, if ACS deems the transaction low-risk, it proceeds to the frictionless flow, meaning that the cardholder does not have to prove themselves. It also signifies that the issuer has applied an exemption.
Similar to issuers, merchants or acquirers can request an SCA exemption using the latest 3DS2.2 protocol. A challenge indicator of 05 (no challenge requested — transactional risk analysis is already performed) must be set in the message. However, requesting an exemption via 3DS flow might be tricky for merchants/acquirers. The 05 indicator may be used to refer to three kinds of exemption (LVP, TRA, RP) plus the merchant-initiated transaction (MIT) exclusion.
EMV Co is introducing additional challenge indicators (10-14) in v2.3 protocol that specifically serves for each individual exemption. The EMV 3DS Testing Programme is being updated to align with the v2.3 and are expected to be available in the second half of 2022. Although, this may take months for the market to upgrade their systems to support the latest protocol.
Let’s look specifically at the TRA and LVP exemptions. The ACS cannot tell which exemption is requested when it receives the 05 indicator. According to the Mastercard guide, ACS should deem all exemptions as TRA without applying the LVP counters:
Mastercard Authentication Guide:
In authentication, an ACS will not know if a value of “05” in the 3DS Requestor Challenge Indicator indicates an LVP exemption subject to counters management or TRA exemption not subject to counters management. In this case, the ACS should not apply the LVP counters in authentication processing if the amount is less than or equal to €30, assuming the TRA exemption applies. This will be combined with checking the LVP counters in authorization if the LVP exemption is flagged. If SCA is needed, an RC65 should be issued by the Issuer host based on which Acquirers should retry with EMV 3DS without Acquirer exemption.
Meanwhile, Visa also suggests that issuer application of the LVP exemption is only viable for transactions submitted directly to authorization as the issuer ACS will not have visibility of the cumulative transaction count and value for transactions submitted via 3DS.
It’s important to note that the request for exemption by merchants or acquirers is not final. The ACS may assess the transaction risk using their fraud engine before granting the frictionless flow. Thus, applying acquirer-exemption through the 3DS protocol may potentially increase friction in the payment process.
Another way to request an acquirer-exemption is to initiate the authorization request directly. Meaning merchants would send payments to issuers without using the 3DS protocol and include the appropriate exemption flag in the authorization message.
For LVP exemption, issuers would check the transaction against the LVP counters during the authorization process. Suppose the LVP count is below the limits. In that case, issuers should accept the exemption request and perform other account-related checks, such as fund availability, CVV, expiry date, AVS, etc. But if the thresholds have been reached, issuers should return an SCA soft decline (RC 65 for Mastercard and 1A for Visa). In such cases, merchants may resubmit the transactions using the 3DS protocol and include a challenge indicator 04 (challenge requested: mandated).
1. The 3DS frictionless flow is the result of the SCA exemption. Thus, such transactions are not considered as strong customer authenticated.
2. In the majority of the cases, Visa does not recommend acquirers or merchants to apply for the LVP exemption as first choice because they have no view of the cumulative consecutive transaction and value counts. Also, the transaction will need to be resubmitted via 3DS if either limit is breached.
3. Since TRA exemption can only be used if acquirers meet the prescribed fraud thresholds, merchants must obtain approval from their acquirers prior to using the TRA exemption.
Who suffers the fraud liability?
With the 3DS v1 protocol, the fraud liability shifts to the issuer once a successful authentication has been performed. Similarly, the v2 protocol provides fraud liability shift protection for the merchants on all successfully challenged or attempted challenge transactions. However, the 3DS frictionless transactions do not always offer merchants protection. The liability lies with the person who applied for the SCA exemption.
The blue cells in the table above indicate the action that drives liability for each scenario. Looking at the three (3) TRA scenarios as an example:
- Acquirer requests TRA exemption, and the issuer accepts it (frictionless — liability shifts to the acquirer)
- Acquirer requests TRA exemption, but the issuer goes through SCA (challenge — liability shifts to the issuer)
- Issuer requests TRA exemption (frictionless — liability shifts to the issuer)
SCA and fraud liability on recurring payments and MITs
The PSD2 SCA requires customer authentication when merchants set up the recurring or MIT agreement. When initiating the authentication request, merchants or acquirers must send a challenge indicator of 04 (challenge requested — mandated), and the issuers should challenge the transaction. In addition, the merchant and the cardholder should have an explicit agreement stating the reason for the payment, terms, and the amount (or an estimate when the final amount is unknown).
Because the SCA is mandated on the initial recurring and the initial MIT payment, merchants will get the fraud liability shift protection on those transactions. However, that initial SCA does not grant the same liability protection to the subsequent recurring or MIT payments. So merchants would still potentially face a chargeback from those subsequent payments.
Example:
A card was used for subscribing a streaming service with a monthly fee of $10. The customer went through the authentication during sign-up and was charged a discounted trial of $6 for the first month. Then, the service provider automatically billed the card again in the following month at $10. Shortly after, the cardholder reported both charges as fraudulent as he did not sign up for the service. If the cardholder’s claim is legitimate, the issuer will be liable for the initial payment of $6, and the merchant is responsible for the subsequent recurring $10.
Having said that, the latest 3DS protocol now supports 3RI (3D requestor-initiated) authentication. This new feature lets merchants generate the necessary authentication data while the cardholder is off-session. Thus, merchants can perform 3RI authentication when initiating subsequent recurring payments. The 3RI authentication will shift the fraud liability of subsequent payments to issuers. Using the previous example, suppose the service provider had performed 3RI authentication on the $10 recurring charge. As a result, the issuer will now be liable for the initial payment of $6 and the subsequent payment of $10.
Merchants or acquirers should use the 3RI authentication only if the cardholder could not have triggered the transaction during checkout. Mastercard provides the following examples:
- The transaction is part of a recurring payment arrangement.
- The final amount is not known during the checkout (e.g. online groceries shopping).
- An event triggered the transaction after the checkout (e.g. miscellaneous rental or service charges).
- The transaction is broken down into multiple payments happening at different times (e.g. installments, travel bookings, marketplaces).
- The transaction is a staged-wallet funding transaction.
- The transaction follows a declined authorization at a transit validator, but the customer has already completed the billable journey (Transit Debt Recovery).
Note that merchants cannot use the 3RI or the MIT exclusion to bypass the PSD2 SCA requirements for transactions where the cardholder triggers the payment using a card that is already stored with the merchant (Card-on-File).
1. 3DS only protects merchants from fraud-related chargebacks. Merchants may still be subject to CB for dissatisfied customers, missing orders, etc.
2. Another thing to keep in mind is if an exempted transaction results in fraud, then not only will the liability be on the party that applied for exemption, but it will also affect their fraud count.
Although PSD2 SCA poses many challenges to PSPs, it has also driven technology innovation in the payment space. The 3DS2 protocol is a robust solution that offers enhanced security in the fast-growing eCommerce industry. By better understanding the PSD2 SCA framework, merchants can leverage this great solution to optimize their payment flows. As a result, it may lead to incredible rewards from the improved performance, lower abandonment, and increased chargeback protection.
Reference
- Cardinal Exemptions for SCA Requirements — What Are They
and What A Merchant Needs to Know to Use Them - Mastercard Authentication Guide for Europe Version 1.3
- PSD2 SCA Regulatory Guide December 2020
- PSD2 SCA Secure Corporate Payment Exemption Guide June 2021
- PSD2 SCA Optimisation Best Practice Guide July 2020
- EMV 3DSecure — Protocol and Core Functions Specification Version 2.3.0.0
