SCA in a Post-PSD2 World: Exemption Engines, Fraud Rates and the Friction You Can Legitimately Remove

Strong Customer Authentication exemptions are not a compliance concession you claim once and forget. They are a data-driven optimisation with a live kill-switch: run them well and you cut checkout friction, run them badly and you breach the fraud-rate thresholds that revoke the exemption for a whole band of your traffic.

Most writing on SCA treats the exemptions as a checkout-conversion trick — a list of tricks to suppress the one-time passcode. That framing misses the part that bites. Under PSD2 (Directive (EU) 2015/2366) and the Regulatory Technical Standards in Commission Delegated Regulation (EU) 2018/389, applicable since 14 September 2019, the right to skip authentication is conditional on your realised fraud performance, measured continuously and reported to your competent authority. The exemption engine is therefore two systems welded together: a real-time decision path that scores each transaction, and a monitoring path that watches whether your own outcomes still entitle you to keep scoring that way. Build the first without the second and you are one bad quarter away from losing the exemption on a large slice of your book, with no warning you designed for.

The two exemptions worth engineering for

There are several exemptions in the RTS. Two are worth building a proper engine around because they carry real volume and real conditions.

Low-value remote payments (Article 16). You may skip SCA where the individual remote electronic payment does not exceed EUR 30, provided that either the cumulative value of prior exempted payments since the last SCA does not exceed EUR 100, or the number of consecutive prior exempted payments does not exceed five. This is a counter, not a risk judgement. The engine has to hold per-instrument running state and reset it every time an authentication actually happens.

Transaction Risk Analysis (Article 18). This is the one that matters at scale. You may exempt a remote transaction assessed as low-risk in real time, up to an exemption threshold value (ETV), but only if your monitored fraud rate for that payment type sits at or below the reference rate for that band. For remote card-based payments the bands are: ETV of EUR 100 requires a reference fraud rate of 0.13%; EUR 250 requires 0.06%; EUR 500 requires 0.01%. For credit transfers the same ETV bands require 0.015%, 0.01% and 0.005% respectively. The higher the value you want to wave through, the cleaner your fraud numbers have to be.

The design consequence is immediate. The ETV you are entitled to use is an output of your monitoring, not a static config value. An engine that hard-codes a EUR 500 ceiling is asserting a 0.01% fraud rate it may not have. The entitlement has to be computed from live data and fed back into the decision path.

How the fraud rate is actually calculated

Article 19 defines the fraud rate as the total value of unauthorised or fraudulent remote transactions divided by the total value of all remote transactions of that type, whether authenticated with SCA or executed under an exemption, calculated on a rolling quarterly basis of 90 days. Two things trip firms up here. First, it is value-weighted, not count-weighted — a handful of large frauds moves the number far more than a spread of small ones. Second, the denominator includes your authenticated traffic too, which means aggressive SCA elsewhere does not clean up the ratio; the fraud has to actually be low.

Article 20 is where the kill-switch lives. If your monitored fraud rate exceeds the reference rate for a band, you must report it to the competent authority immediately with your remediation plan. If it exceeds the reference rate for two consecutive quarters, you must stop using the TRA exemption at that ETV band until the rate has returned to at or below the reference for a full quarter. That is not a fine — it is a mechanical loss of the optimisation, applied to a whole tier of transactions at once. If you have not modelled what your approval rate and friction look like with that tier forced back into SCA, you will find out live.

The engine, in pseudocode

The shape that works keeps the entitlement calculation out of the hot path. Fraud rates are recomputed on a schedule, cached as the currently permitted ETV per payment type, and the per-transaction decision is a fast lookup against that plus the low-value counters and the real-time risk score.

# SCA exemption decision engine (pseudocode, British English comments)
# Entitlement is derived from monitored fraud, not hard-coded.

REFERENCE_RATE = {            # Article 18 reference fraud rates, card-based
    100: 0.0013,             # ETV EUR 100  -> 0.13%
    250: 0.0006,             # ETV EUR 250  -> 0.06%
    500: 0.0001,             # ETV EUR 500  -> 0.01%
}

def permitted_etv(payment_type):
    # Highest ETV band whose reference rate our 90-day fraud rate meets.
    fr = rolling_fraud_rate(payment_type, window_days=90)  # Article 19
    eligible = [etv for etv, ref in REFERENCE_RATE.items() if fr <= ref]
    return max(eligible) if eligible else 0

def decide(txn, state):
    # 1. Low-value exemption (Article 16): a counter, not a risk call.
    if txn.amount <= 30 \
       and state.cumulative_since_sca + txn.amount <= 100 \
       and state.count_since_sca < 5:
        return exempt("low_value")

    # 2. TRA exemption (Article 18): capped by live entitlement.
    etv = permitted_etv(txn.payment_type)
    score = risk_score(txn)            # real-time analysis of the txn
    if txn.amount <= etv and score <= RISK_ACCEPT_THRESHOLD:
        return exempt("tra")

    # 3. No exemption survives -> challenge with SCA, reset counters.
    return require_sca()

# Runs on a schedule, not per transaction:
def monitor(payment_type):
    fr = rolling_fraud_rate(payment_type, window_days=90)
    for etv, ref in REFERENCE_RATE.items():
        if fr > ref:
            report_to_competent_authority(payment_type, etv, fr)  # Article 20
        if breached_two_consecutive_quarters(payment_type, etv):
            disable_tra_band(payment_type, etv)  # withdraw until recovered

Two engineering points that the regulation forces. The decision path must be idempotent — a retried authorisation must not double-count the low-value cumulative state or you will drift the counters and either over-exempt or wrongly challenge. The discipline is the same one I have written about for making POST safe to retry. And the real-time risk score depends on trusting the identity and session context of the request, which is its own correctness problem; treat the signals feeding it with the same rigour you would apply to validating a token properly rather than assuming the upstream got it right.

Monitoring is the product, not the afterthought

The failure mode I see is a well-built decision path bolted to a monthly spreadsheet that reconciles fraud after the fact. By the time that spreadsheet shows a breach, you may already be a quarter into the two-quarter clock. The fraud rate has to be a first-class, continuously computed metric with alerting on approach to each reference band — the same instinct that makes teams instrument delivery with real operational metrics rather than quarterly reviews. You want to see the EUR 500 band tightening while you still have room to tighten your risk-score threshold and defend it, not after the entitlement has already collapsed to EUR 100.

What PSD3 changes, and what it does not

The regime is in flux, so build for it. The European Parliament and Council reached provisional political agreement on PSD3 and the accompanying Payment Services Regulation on 27 November 2025, with publication expected around mid-2026 and the detailed exemption mechanics deferred to fresh EBA regulatory technical standards. The direction of travel is clear: SCA stays mandatory for payer-initiated remote transactions; merchant-initiated transactions are authenticated at mandate set-up rather than on each pull; there is a new obligation to offer at least one authentication method that works for customers without a smartphone; and the governance around exemptions and transaction risk analysis is being tightened, not loosened.

What this means for the architecture is that the specific ETV bands and reference rates may move, but the shape will not: an exemption is a conditional right whose condition is your own measured fraud. Hard-code the numbers as configuration you can change; treat the entitlement-from-fraud loop as the permanent structure. Verify the final figures against the transposing instruments when the PSR RTS land.

Every basis point of fraud you tolerate is friction you are allowed to remove somewhere else. The firms that win this are not the ones suppressing the most passcodes — they are the ones who can prove, quarter after quarter, that they earned the right to.