🔐 3-D Secure 2 and SCA exemptions

The framework: PSD2, SCA, and EMV 3-D Secure

PSD2 requires strong customer authentication (SCA: two factors out of knowledge, possession, and inherence) for electronic payments initiated by the payer in the EEA. EMV 3-D Secure (3DS2), specified by EMVCo, is the protocol that delivers it for cards. It carries transaction and device data to the issuer, which decides whether to authenticate silently (frictionless) or to require a challenge.

Frictionless vs. challenge

In the frictionless flow, the ACS assesses risk using only the data it receives (AReq) and authenticates without any interaction. The cardholder sees nothing. In the challenge flow, the ACS requires an interaction, now mostly an approval in the banking app (possession of the phone plus a PIN or biometrics, which meets SCA). SMS OTP on its own has been dropped because it counts as only one factor.

Transmitted data: what drives frictionless

The 3DS2 AReq is the message the merchant uses to submit a transaction for authentication; the Directory Server then routes it to the issuer’s ACS. It can carry around 130 fields, about 100 of them mandatory or conditional and several dozen optional. That is the big difference from 3DS1. The more fields the merchant fills in, the more the ACS has to refine its score, and the more likely a frictionless outcome becomes. The fields fall into the following categories.

• Browser device data (mandatory in browser flows): browserUserAgent, browserLanguage, browserScreenWidth/Height, browserTZ, browserJavaEnabled, browserAcceptHeader, IP address;
• SDK device data (in-app flows): device identifiers, model, OS, jailbreak/root status; richer and more reliable than browser data;
• Transaction data: amount, currency, date, planned recurrence (recurringFrequency, recurringExpiry);
• Merchant risk indicators: shipping address, shipIndicator (ship to billing address, in-store pickup, digital goods, etc.), deliveryTimeframe, reorderItemsInd (repeat purchase), preOrderPurchaseInd;
• Cardholder account info: customer account age (chAccAgeInd), date of last password change, number of transactions in the last 24 hours and the last year, number of saved cards;
• Requestor data: threeDSRequestorChallengeInd, which lets the merchant request a challenge (03), indicate that it prefers none (02), or signal that a mandate requires SCA (04).

{
  "threeDSRequestorAuthenticationInd": "01",   // 01 = payment (vs. card enrollment)
  "threeDSRequestorChallengeInd": "02",        // 02 = no challenge requested
  "acctNumber": "4895370000000000",            // PAN or DPAN
  "purchaseAmount": "8990", "purchaseCurrency": "978",  // EUR 89.90 (ISO 4217)
  "browserIP": "92.184.100.23",
  "browserUserAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_5...)",
  "browserLanguage": "fr-FR", "browserTZ": "-120",
  "browserScreenWidth": "390", "browserScreenHeight": "844",
  "cardholderName": "MARIE DUPONT",
  "email": "marie.dupont@example.com",
  "shipAddrCity": "Paris", "shipAddrPostCode": "75002", "shipAddrCountry": "250",
  "merchantRiskIndicator": {
    "shipIndicator": "01",                     // ship to billing address
    "deliveryTimeframe": "03",                 // overnight delivery (within 24 hours)
    "reorderItemsInd": "02"                    // reorder of a previously purchased item
  },
  "acctInfo": {
    "chAccAgeInd": "05",                       // customer account created > 60 days ago
    "nbPurchaseAccount": "11",                 // 11 purchases in the last 6 months
    "suspiciousAccActivity": "01"              // no suspicious activity observed
  }
}
// Rich, consistent data -> low ACS risk score -> transStatus Y, no challenge.

Liability shift: who bears the fraud loss?

A liability shift moves the cost of fraud from one party to the transaction to another. On unauthenticated card-not-present transactions, that cost falls on the merchant, in the form of a fraud chargeback. 3DS authentication shifts it to the issuer: a cardholder who disputes an authenticated transaction can no longer obtain a fraud chargeback. Non-fraud reasons, such as items not received or not as described, remain available in every case.

SCA exemptions in detail

The RTS (Delegated Regulation (EU) 2018/389) provide exemptions from SCA, which the acquirer requests in the authorization flow (or the issuer applies). Separately, some cases are out of scope and are not exemptions at all, such as MITs, MOTO, and one-leg-out transactions (one of the two banks outside the EEA). The distinction matters. An issuer can refuse an exemption requested from it, whereas an out-of-scope transaction is by definition not subject to the authentication requirement.

The applicable TRA threshold depends on the fraud rate of the acquirer (for acquirer TRA), calculated quarterly under the RTS methodology. A merchant with a low fraud rate is still capped by the overall rate of its acquirer’s portfolio. The fraud levels of other merchants in that portfolio therefore set the exemption ceiling available to it, which affects the choice of acquirer and how MIDs are segmented.

Soft declines and exemption strategy

A soft decline is a recoverable decline by which the issuer requires authentication: code `1A` at Visa (Additional customer authentication required) and `65` at Mastercard, repurposed for this use under PSD2. It tells the merchant that the transaction can go through if resubmitted with 3DS. Every European payment flow must implement this resubmission loop.