Why do transaction risk exemptions create liability under PSD3?

Why transaction risk exemptions can still create liability

A transaction risk exemption is not a free pass, it is a judgment that the payment was low risk enough to skip stronger authentication. That makes the decision itself part of the liability picture: if fraud later occurs, the merchant or payment provider may need to show that the exemption was justified by evidence, not just by a policy flag or a threshold rule.

That is why exemption use is usually assessed after the fact against the quality of the decisioning, the monitoring in place, and the evidence retained at the time of processing. A weak fraud model, stale risk signals, or incomplete logs can turn a defensible exemption into a disputed one.

For practical detail on how PSD2 and PSD3-linked strong customer authentication exemptions are expected to work, see PSD2/PSD3 Strong Customer Authentication Guide.

What must be true for the exemption to be defensible

The key issue is not whether an exemption was technically available, but whether the business can justify the decision path that led to skipping full authentication. That usually means the exemption was applied against a current risk score, supported by fraud monitoring, and consistent with the transaction profile the rules were meant to cover.

In practice, the strongest cases are the ones where the decision trail can be reconstructed: what risk indicators were present, what checks were run, and why the transaction was allowed to proceed without stronger customer verification. If that trail is missing, liability arguments become much harder to defend.

That is also why payments teams often need to align exemption logic with broader fraud controls, as described in Fraud Prevention Guide for Digital Businesses.

For organisations operating in open banking or broader payment-access flows, the control question also extends beyond the single transaction, because access models, consent paths and third-party risk can shape what evidence is available later. Open banking and open finance security is useful background where exemption decisions sit inside a wider payment ecosystem.

Why fraud after the fact shifts the burden of proof

Once fraud is reported, the exemption decision is no longer only an operational convenience, it becomes part of the dispute and liability analysis. The organisation may need to show that the exemption was applied in good faith, using the information available at the time, and that the process was not just a shortcut to reduce friction.

That burden matters because exemptions can be overused, especially when teams optimise for conversion or payment speed without equivalent investment in fraud evidence. The most common failure mode is not an obvious policy breach, it is a decision that looked reasonable in isolation but cannot be substantiated when challenged.

Where the decision rests on monitoring quality, merchant-side fraud operations and evidence retention become central. Resources such as Transaction Monitoring and Behavioural Biometrics Guide are relevant because they show how teams strengthen the evidence base behind low-risk decisions. Merchant-side dispute readiness is also covered in Ecommerce Fraud and Chargeback Protection, especially where exemptions later become part of a chargeback narrative.

Risk and Threat Considerations

Transaction risk exemptions create a liability edge because they intentionally remove a stronger authentication step from the payment flow. If the risk model is weak, stale, or poorly tuned, an attacker or fraudster can exploit that gap by steering transactions into the exemption path and then disputing the outcome after the payment clears.

Failure mechanism: The business cannot demonstrate that the transaction met the exemption criteria at the time of approval, or it cannot show that the fraud signals and monitoring were strong enough to justify skipping full authentication.

Impact: The organisation faces avoidable fraud loss, weaker dispute defence, and potential reimbursement or liability exposure where the exemption decision cannot be substantiated.

Practitioner Guidance

What to verify: Treat exemption use as an evidentiary control, not just a risk rule. Verify that each exempted transaction leaves a retrievable record of the score, rule path, timestamp, and the fraud signals that supported the decision.

Decision rule: If the transaction would be hard to defend to a regulator, acquirer, or customer after fraud occurs, do not rely on the exemption alone. Use the exemption only when the decision can be reconstructed from contemporaneous evidence, not from hindsight.

What practitioners underestimate: The liability problem is usually not the exemption category itself, but the weakness of the proof around it. Good controls do not just reduce fraud, they make the exemption explainable.

Practitioner takeaway: The safest exemption is the one you can justify later with the same evidence you used to approve it in the first place.

Related resources from NHI Mgmt Group

• PSD3
• Why do SaaS integrations create compliance risk under NYDFS?
• Why do privileged accounts create extra risk under NIS2?
• Why do over-provisioning and under-provisioning both create security risk?