Accountability sits with the party that initiates the exemption request. That matters because the party asking for frictionless processing also accepts the associated chargeback exposure. Merchants, acquirers, and issuers therefore need a clear decision model for which transactions qualify, who submits the exemption, and how fraud performance will be monitored over time.
How PSD2 exemption accountability works in practice
The accountability question is less about who benefits from the exemption and more about who makes the request and accepts the risk. In practice, the initiating party needs to own the qualification decision, the evidence behind it, and the resulting dispute exposure, because the exemption changes the fraud and chargeback profile of the transaction.
That is why the operational model has to separate commercial convenience from control ownership. A merchant may want lower friction, but the decision still depends on whether the acquirer will submit the exemption, whether the issuer will honour it, and whether the organisation can defend the transaction after the fact.
When the exemption is used correctly, accountability should be traceable to a named workflow owner, not left implicit across the payment chain. If no one can point to who requested it, who approved it, and what eligibility test was applied, the organisation has a governance gap as well as a payments risk.
What the exemption changes in the chargeback and fraud model
A psd2 exemption is not a risk transfer mechanism. It is a decision to process a transaction without the usual friction of strong customer authentication in a defined scenario, so the party initiating the exemption needs to accept that the fraud and dispute profile may worsen if the qualifying conditions are wrong or drift over time.
That makes fraud monitoring part of the accountability model. Merchants and acquirers need to watch whether exemption usage is actually improving approval rates without creating a higher downstream loss rate, because chargeback exposure can rise even when conversion metrics look better.
The practical issue is not only abuse at the point of sale. Weak exemption governance can encourage overuse, inconsistent application across channels, and poor exception handling, all of which make it harder to explain why a disputed payment was routed without additional authentication.
Who should own the decision, evidence, and oversight
Accountability normally sits with the party closest to the exemption decision and its supporting evidence. In a merchant-led flow, that means the merchant owns the transaction rationale and the evidence trail; in an acquirer-led or platform-led flow, the acquirer or platform owner must ensure the exemption criteria, routing logic, and monitoring are controlled and reviewable.
Clear ownership also matters across commercial partners. The merchant, acquirer, and issuer each have different incentives, so the control model should specify who can request the exemption, who can submit it, who can override it, and who is responsible for reviewing fraud outcomes when exemption volumes change.
For payment teams, the strongest sign of control maturity is that exemption use is measurable by transaction type, risk segment, and channel, with an explicit threshold for pausing or narrowing the exemption if fraud performance degrades. Financial Services Identity Security Guide is useful here because it places PSD2 SCA, payments fraud, and operational accountability in a broader financial-services control context.
Risk and Threat Considerations
PSD2 exemptions create a predictable abuse surface when organisations treat them as a routine friction-reduction tool instead of a controlled exception. The main risk is that exemption logic can be over-applied, weakly evidenced, or poorly monitored, which leaves the business carrying avoidable chargeback losses and making dispute decisions with incomplete provenance.
Failure mechanism: The exemption is requested or routed without a durable, reviewable decision trail, or it is applied to transactions that do not meet the intended eligibility conditions, so fraud losses are absorbed without a clear accountability owner.
Impact: Chargeback exposure increases, fraud performance becomes harder to explain, and the organisation may struggle to defend exemption use when disputes, scheme reviews, or internal audits ask why a transaction was processed without stronger authentication.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | PSD2 exemption routing depends on controlled decision rights and approvals. |
| A.5.18 — Access rights | Exemption accountability requires traceable ownership of who can invoke the flow. | |
| A.5.24 — Information security incident management planning and preparation | Chargeback and fraud escalation need a prepared response path when exemption losses rise. | |
| Recommendation — Define who may request and approve exemption use under access control rules. Review and record which roles can initiate or override exemption requests. Prepare escalation steps for exemption-related fraud and dispute spikes. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Exemption use is a business risk decision that needs explicit risk appetite and ownership. |
| PR.AA-05 — Authenticator Management | The exemption decision affects how authentication is applied or bypassed in payment flows. | |
| DE.CM-01 — Networks and information systems are monitored to detect anomalies | Monitoring exemption outcomes is needed to spot fraud deterioration and chargeback anomalies. | |
| Recommendation — Set risk tolerance for exemption use and tie it to accountable ownership. Ensure authentication exceptions are approved and monitored consistently. Monitor exemption performance and investigate abnormal dispute patterns. | ||
Practitioner Guidance
What to prioritise: Define the exemption owner first, then make sure the owner also owns the evidence trail and the post-transaction review loop. If those responsibilities are split across merchant, acquirer, and payments operations, accountability will be blurred even when the technical flow is correct.
What to verify: Confirm that every exemption path has a documented eligibility rule, a named requester, and a measurable fraud-review checkpoint. If you cannot reconstruct why a specific payment qualified, the control is too weak to trust in a dispute-heavy environment.
What good looks like: Exemption usage is narrow, auditable, and tied to a clear decision model that can be paused when chargeback performance worsens. The goal is not maximum exemption volume, but controlled use with visible loss outcomes.
Practitioner takeaway: Treat the exemption as an accountable risk decision, not a payment convenience feature, because the party that asks for the exemption should also be the party that can justify it when chargebacks follow.
