Issuing and acquiring banks remain accountable because PSD2 puts the burden of fraud analysis and exemption justification on the regulated participants in the payment chain. If the decision model is poor, the compliance and fraud consequences sit with the institution that approved the transaction logic.
Why This Matters for Security Teams
SCA exemptions are not a technical loophole; they are a regulated decision that shifts risk back onto the institution when the exemption logic is weak, stale, or poorly documented. That matters because fraud teams, payments operations, and compliance owners often treat exemptions as a routing rule instead of a controlled risk decision. When the control fails, the liability usually does not disappear with the transaction. It stays with the bank that approved the path and the evidence behind it. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces that accountable control ownership, monitoring, and auditability must be explicit, not assumed. For institutions already struggling with identity sprawl, the Ultimate Guide to NHIs shows why weak governance patterns tend to repeat wherever approvals are opaque and exceptions are not lifecycle-managed. In practice, many security teams encounter exemption misuse only after chargebacks, scheme reviews, or regulator questions have already exposed the decision gap.
How It Works in Practice
Correct accountability depends on who made the exemption decision, who approved the rule set, and who can prove the basis for that decision after the fact. In payment operations, that means the issuing or acquiring institution must be able to show the rationale, the fraud thresholds, the business context, and the monitoring attached to each exemption class. The burden is not just “did a payment pass?” but “was the exemption justified under the policy in force at the time?” That is why exemption governance needs evidence trails, not just configuration states.
A practical control pattern usually includes:
- Defined exemption owners in compliance and fraud functions, with named approval authority.
- Policy-as-code or equivalent rule governance so exemption logic can be versioned and reviewed.
- Logging of the decision inputs, including merchant type, transaction context, and fraud signal scores.
- Periodic recertification of exemption rules against actual fraud outcomes and scheme guidance.
- Rollback or disablement paths when false positives, abuse patterns, or drift appear.
This is consistent with the broader control discipline described in NIST SP 800-53 Rev 5 Security and Privacy Controls, and the same accountability logic applies in NHI governance, where Ultimate Guide to NHIs stresses lifecycle control, visibility, and revocation as core duties rather than optional hygiene. The control model breaks down when exemption logic is embedded in undocumented vendor settings, because then the institution cannot reliably prove who changed what, why, or under which risk acceptance.
Common Variations and Edge Cases
Tighter exemption controls often increase operational overhead, requiring organisations to balance fraud friction against auditability and speed. That tradeoff becomes sharper when exemptions are used across multiple channels, jurisdictions, or merchant portfolios, because different teams may own different parts of the logic while still sharing the same regulatory exposure. Best practice is evolving, but there is no universal standard for how granular exemption governance must be, so institutions should align the control depth to the risk profile and supervisory expectations.
A few edge cases matter:
- If a third-party processor applies the exemption logic on behalf of the bank, accountability usually still remains with the regulated participant unless the contract, oversight, and evidence chain are explicit.
- If fraud analytics are used to justify the exemption, the model owner, decision owner, and control owner should all be identifiable.
- If exemption settings are copied across regions or products, stale policy inheritance can create silent non-compliance.
- If chargeback trends change faster than review cycles, an exemption may remain “approved” while becoming operationally unsafe.
Current guidance suggests that documentation, challenge rights, and exception recertification are the minimum defensible baseline. That same principle appears in the Ultimate Guide to NHIs, where unmanaged credentials and unclear ownership consistently drive exposure. For payment teams, the lesson is simple: when the exemption is wrong, the accountability is not outsourced with the decision.
Related resources from NHI Mgmt Group
- Who should be accountable for certificate-backed workload access in Kubernetes?
- Which teams are accountable for S/MIME governance when certificates span HR, PKI, and domain ownership?
- Who is accountable when MFA does not meet NIST expectations?
- Who is accountable for certificate trust and root distribution?
