How to test SCA exemptions: low value, TRA, and trusted beneficiaries

Where SCA exemption defects come from

The typical defect is an exemption applied outside its conditions: a low-value payment exempted after the issuer's counter should have forced authentication, a transaction risk analysis (TRA) exemption granted in a value band the provider's fraud rate no longer allows, or a trusted beneficiary added through an API route that skipped SCA. None of these fail a functional test, because the payment succeeds. They surface in fraud reports, in an audit under Article 3 of Commission Delegated Regulation (EU) 2018/389 (the regulatory technical standards, RTS, checked on 2026-09-22), or in a dispute.

The money consequence sits in PSD2 Article 74(2): where the payer's provider does not require SCA, the payer bears no financial loss unless the payer acted fraudulently, and where the payee or the payee's provider fails to accept SCA, it refunds the financial damage caused to the payer's provider. Toward the payer, the issuer therefore carries the fraud loss on every payment it lets through without SCA, whether the exemption was valid or not. Between issuer and acquirer, card scheme dispute rules decide who pays, and the Visa PSD2 guide cited below notes that liability under Visa Rules may differ from regulatory liability under PSD2.

The PSD2 SCA testing requirements page covers the full article set, the UK's FCA SCA-RTS, and what an auditor requests; this guide covers remote card payments in the EU and EEA. On 22 September 2026, the Payment Services Regulation that will succeed PSD2 is agreed but not formally adopted by Parliament and Council (European Parliament Legislative Train, checked on 2026-09-22), so the RTS thresholds below remain the ones to test. Status changes are tracked on the PSD3 and PSR page.

The rules each test case encodes

The Visa PSD2 SCA for Remote Electronic Transactions Implementation Guide (version 2.0, 1 November 2019, European region) adds three scheme positions that change test scope for Visa cards: one exemption per transaction, the Article 14 recurring exemption is not supported (merchant-initiated transactions are treated as out of scope instead), and acquirers should apply TRA to low-value payments because only the issuer sees the low-value counters.

Procedure

1. Map every exemption path in the payment flow. For each exemption your role can request or grant, record the EMV 3DS indicator sent, the expected issuer response, and the authorisation flag. Payment flow testing records each path as a state in the payment flow map. The authentication request carries cardholder data such as the account number, so run the suite with test cards from your 3-D Secure Server vendor or the scheme sandbox, never production cards.

2. Check the indicators the issuer supports before requesting. EMVCo lists ACS Information Indicator values in the card range data: 08 for TRA exemption supported, 09 for trust list exemption supported, 10 for low value exemption supported, and 11 for secure corporate payments supported (EMVCo 3DS whitepaper, technical features, checked on 2026-09-22). Test a card range without value 10 and confirm your 3DS Server falls back to value 05 or no exemption instead of requesting an exemption the issuer's access control server (ACS) has not declared.

3. Send the exemption request at each boundary. In protocol 2.3.1, threeDSRequestorChallengeInd is an array and value 10 requests the low-value exemption. In 2.2.0 it is a single string and value 05 signals that TRA was already performed. Request fields irrelevant to exemptions are omitted below.

{
  "messageType": "AReq",
  "messageVersion": "2.3.1",
  "messageCategory": "01",
  "deviceChannel": "02",
  "threeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e",
  "threeDSRequestorChallengeInd": ["10"],
  "purchaseAmount": "3000",
  "purchaseCurrency": "978",
  "purchaseExponent": "2",
  "purchaseDate": "20260922101500"
}

purchaseAmount 3000 with exponent 2 and currency 978 is EUR 30.00. Repeat at 3001 (EUR 30.01), where Article 16(a) no longer applies. In 2.3.1 the response reports what the ACS did in transChallengeExemption: 05 TRA, 08 trust list, 10 low value, 11 secure corporate payments, or 79 when no exemption was applied.

{
  "messageType": "ARes",
  "messageVersion": "2.3.1",
  "threeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e",
  "transStatus": "I",
  "transChallengeExemption": "10"
}

transStatus "I" means informational only: the ACS acknowledged the requestor's challenge preference. A challenge response carries "C" and goes through the 3DS2 challenge flow tests.

1. Drive the low-value counter on the issuer side. Article 16(b) caps the cumulative amount of previous remote payments since the last SCA at EUR 100; Article 16(c) caps the number of previous consecutive payments at five. The issuer applies one of the two options. Feed a sequence per test card and assert the decision per row.

seq,card_ref,amount_eur,previous_count,previous_cumulative_eur,expected_decision,note
1,TC-LV-01,25.00,0,0.00,exempt,first payment after SCA
2,TC-LV-01,25.00,1,25.00,exempt,
3,TC-LV-01,0.00,2,50.00,not_counted,zero-value verification does not increment the counter
4,TC-LV-01,30.00,2,50.00,exempt,exactly EUR 30.00 meets Article 16(a)
5,TC-LV-01,30.01,3,80.00,sca,amount above EUR 30
6,TC-LV-01,,0,0.00,reset,SCA completed on row 5 resets both counters
7,TC-LV-01,29.99,0,0.00,exempt,counter restarted

Row 3 follows the Visa guide (section 4.5.1), which says the count is not incremented for zero-value transactions that do not require SCA. Assert that the reset happens only after a successful SCA, and that a challenge abandoned before completion leaves the counters unchanged.

1. Recalculate the TRA fraud rate by value. Article 19(1) defines the rate as the total value of unauthorised or fraudulent remote transactions, whether the funds were recovered or not, divided by the total value of all remote transactions of the same type, both SCA-authenticated and exempted under Articles 13 to 18, on a rolling 90-day basis. Run the calculation independently of the risk engine and compare.

-- Remote card-based payments, rolling 90 days to :as_of, amounts in EUR
SELECT
  SUM(amount_eur) FILTER (WHERE fraud_reported) AS fraud_value_eur,
  SUM(amount_eur)                               AS total_value_eur,
  SUM(amount_eur) FILTER (WHERE fraud_reported)
    / NULLIF(SUM(amount_eur), 0)                AS fraud_rate
FROM payments
WHERE channel = 'remote'
  AND instrument = 'card'
  AND executed_at >= :as_of - INTERVAL '90 days'
  AND executed_at <  :as_of;
-- No filter on auth_method (SCA and exempted both count)
-- No filter on recovered (recovered fraud still counts)

1. Map the rate to the highest allowed ETV. The Annex reference rates for remote card-based payments are 0.13% for an ETV of EUR 100, 0.06% for EUR 250, and 0.01% for EUR 500; for remote credit transfers they are 0.015%, 0.01%, and 0.005%.

from decimal import Decimal

# RTS 2018/389 Annex, remote electronic card-based payments: ETV in EUR -> reference fraud rate
CARD_REFERENCE = [(500, Decimal("0.0001")), (250, Decimal("0.0006")), (100, Decimal("0.0013"))]

def max_etv(fraud_rate: Decimal) -> int:
    for etv, reference in CARD_REFERENCE:
        if fraud_rate <= reference:
            return etv
    return 0  # no TRA exemption

assert max_etv(Decimal("0.0006")) == 250   # equal to the reference rate is allowed
assert max_etv(Decimal("0.00061")) == 100
assert max_etv(Decimal("0.0014")) == 0

Then submit TRA requests at the ETV and one cent above it, and one inside the ETV with a real-time risk flag from Article 18(2)(c), such as an abnormal payer location. The last one must not be exempted.

1. Test the soft decline path in authorisation. The authorisation request mirrors the exemption requested in 3-D Secure (Visa Field 34). When the issuer refuses an exemption sent straight to authorisation, Visa issuers answer with response code 1A (additional customer authentication required). Assert that the merchant retries through 3-D Secure with a challenge, that the retry carries a new idempotency key and a new authentication value, and that the payer is not charged twice.

2. Test trusted beneficiary enrolment on every channel. Send value 09 (challenge requested, trust list prompt) and confirm the challenge offers enrolment. Then send value 08 and confirm trustListStatus (whiteListStatus in 2.2.0) returns "Y". On the issuer side, add and remove a trusted merchant through web, app, and API and confirm each change requires SCA, as Article 13(1) requires.

The pitfall: EUR 30.00 and the word "previous"

The RTS and the scheme guides word the low-value limits differently. Article 16(a) exempts a payment that "does not exceed EUR 30", so EUR 30.00 qualifies. The Visa PSD2 guide (section 4.3) says the value "must be less than 30". An issuer that follows the scheme wording challenges at EUR 30.00, which the rule allows because SCA is always permitted. A checkout that sends EUR 30.00 straight to authorisation then gets a 1A soft decline, possibly after the payer has left.

The second trap is in Article 16(b) and (c): both count previous payments since the last SCA, so the current payment is not part of the EUR 100 sum or the count of five. Read literally, a payer with EUR 95 of earlier exempted payments can make a further EUR 30 payment without SCA. An issuer that adds the current payment before comparing is stricter, which the rule allows. The failure to test for is the opposite: an engine that is more permissive than the literal text, for example one that resets the counters without a completed SCA.

The RTS states every threshold in EUR and contains no conversion rule. For payments in other EEA currencies, record the exchange rate and timestamp your engine used for each threshold decision, so the decision can be replayed in an Article 3 audit.

Test matrix

We run these cases for acquirers, Banking-as-a-Service card programmes, and card issuers such as neobanks, and hand over each exemption decision with its request, response, and rule reference.