The most common mistake is treating exemptions as a blanket way to remove authentication rather than a controlled risk decision. Low-value and recurring transactions may qualify, but they still need monitoring. If exemptions are applied too broadly, fraudsters can exploit the reduced friction. Teams need governance, transaction review, and exception handling that preserves both usability and security.
PSD3 exemptions are controls, not permission to skip authentication
PSD3 exemption logic is often misunderstood as a way to make checkout “frictionless” by default. It is better treated as a controlled exception process: the exemption may reduce step-up authentication in a specific transaction context, but it does not remove the need to understand risk, enforce policy, and keep an audit trail of when the exemption was used and why.
The practical issue is that exemptions shift where the control lives. Instead of authenticating every time, teams must rely more heavily on transaction monitoring, fraud signalling, merchant risk decisions, and clear exception criteria. That means the design problem is not “how do we avoid authentication,” but “how do we preserve trust when authentication is intentionally lighter?”
For teams that want the governance side of that decision to be real, the control model should look more like NHIMG’s Ultimate Guide to NHIs than a one-time UX shortcut: reduced friction only works when the surrounding lifecycle, visibility, and exception handling stay disciplined.
Where teams go wrong with low-value and recurring transaction exemptions
One common mistake is assuming that low-value or recurring transactions are inherently safe enough to exempt without deeper review. In practice, the exemption still depends on context: amount, frequency, customer behaviour, channel patterns, and whether the merchant can detect abnormal use. A transaction that looks harmless in isolation can become a useful abuse path when repeated at scale.
Another error is treating the exemption as static. Fraud patterns change, customer profiles drift, and a once-acceptable exemption strategy can become overbroad if it is not revisited. Teams also forget that “recurring” does not automatically mean “trusted,” especially when credentials, tokens, or payment instruments can be reused by an attacker who has already obtained access to the account or payment flow.
This is why payment teams should be cautious about reducing friction for its own sake. The right benchmark is not how often authentication is removed, but whether the exemption remains defensible under the current fraud environment, operational monitoring, and customer-loss tolerance.
Why monitoring and exception handling matter more when friction is reduced
When authentication steps are removed or relaxed, the detection burden rises. Teams need to know whether the exemption is being applied in the intended cases, whether the risk engine is catching anomalous patterns, and whether the business can quickly reverse or tighten the decision when abuse emerges. Without that, exemptions become a blind spot rather than a convenience feature.
That same logic shows up in breach analysis: reduced friction creates value for legitimate users, but it also shortens the path for an attacker if the account, token, or payment relationship is already compromised. The lesson from incidents such as the Uber Breach is that weakened verification and social engineering pressure can turn a usability shortcut into a control failure when governance is loose.
Practitioners should also remember that a controlled exemption is not the same as a permanent waiver. Strong programmes define escalation paths for edge cases, exceptions, and suspicious behaviour, then preserve enough transaction evidence to justify when an exemption was applied and when it should be withdrawn.
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 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-02 — Internal and External Context | PSD3 exemptions depend on business context and risk tolerance. |
| GV.OC-03 — Legal and Regulatory Requirements | PSD3 exemption use is shaped by payment-regulatory obligations. | |
| PR.AA-01 — Identity and Access Management | Authentication is the control being reduced, so access assurance remains central. | |
| Recommendation — Define exemption boundaries using the organisation’s fraud and user-experience context. Map exemption decisions to applicable payment-regulatory requirements before relaxing controls. Preserve authentication assurance where exemption criteria are not explicitly met. | ||
| CIS Controls v8 | 6.3 — Access Rights Management | Authentication exemptions change how access is granted to payment actions. |
| 8.2 — Audit Log Management | Exemption use should be traceable for review and fraud investigation. | |
| 13.1 — Network Monitoring and Defense | Monitoring abnormal transaction behaviour is key when friction is reduced. | |
| Recommendation — Restrict exemption scope to the minimum transaction patterns that remain defensible. Log exemption decisions and retain evidence for later review. Use monitoring to detect abuse patterns across exempted payment flows. | ||
| PCI DSS v4.0 | 8.4.2 — MFA for Access Into the Cardholder Data Environment | Payment authentication relaxation must still fit strong authentication expectations. |
| 10.2 — Audit Logs for Security-Relevant Events | Exemption decisions are security-relevant and should be auditable. | |
| Recommendation — Keep strong authentication in place wherever the exemption does not clearly apply. Record exemption use so investigators can reconstruct decisions and trends. | ||
Practitioner Guidance
What to prioritise: Treat exemption governance, monitoring, and review thresholds as the core of the control. If a team can only explain the user experience benefit but not the fraud decision logic, the exemption is probably too broad.
What to verify: Check that the exemption is bounded by transaction type, value, recurrence pattern, and current fraud signals, and that there is a clear path to reinstate stronger authentication when risk increases. If you cannot explain the rollback condition, the policy is incomplete.
Common mistake: Teams often optimise for “less friction” without measuring whether exceptions are still behaving like exceptions. That usually leads to drift, where the exemption expands quietly and the security team notices only after losses increase.
Practitioner takeaway: The objective is not to remove authentication wherever possible, it is to make every reduction in friction explicit, reviewable, and reversible before fraudsters learn to exploit it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
