What breaks when PSD2 controls are applied to every eligible transaction without exception handling?

Where Blanket PSD2 Enforcement Stops Being Good Security

PSD2 strong customer authentication is effective when it is applied with transaction context, exemption logic, and a clear view of customer experience. If every eligible payment is forced through the same step, the control stops behaving like a risk-based safeguard and starts acting like a conversion barrier. The practical breakage is not technical failure, but the loss of proportionality between fraud reduction and checkout completion.

In consumer ecommerce, that proportionality matters because small interruptions can create outsized abandonment. A checkout flow that is too rigid can also distort how customers and merchants treat exceptions, pushing teams to bypass the control path informally instead of designing it correctly. That is why Financial Services Identity Security Guide is relevant here, because it places PSD2 SCA alongside the broader obligation to balance payment security with operational usability.

Why Exception Handling Is Part of the Control, Not an Optional Extra

PSD2 is designed around differentiated treatment of transactions. Exemption handling, transaction risk assessment, and step-up decisions are part of the control model, not a workaround to it. When those branches are removed, the organisation is no longer applying security according to the transaction’s actual risk profile, so low-risk purchases and repeat customers are treated as if they all deserved the highest-friction path.

That changes the security posture in a subtle way. A blanket policy can increase consistency, but it also removes the ability to reserve strong customer authentication for cases where it adds real value. For payment systems, the better question is whether the control is reducing abuse at an acceptable business cost, not whether it is being invoked on every event. The European Commission’s EU Cyber Resilience Act is not a PSD2 rule, but it reflects the same design principle: security mechanisms should be built with lifecycle fit and operational impact in mind.

What Actually Breaks in the Checkout Journey

The immediate break is user flow. Extra challenges interrupt the purchase path, and each interruption creates another point where legitimate buyers can drop out, especially on mobile devices or in time-sensitive purchases. The secondary break is organisational: teams lose a way to distinguish transactions that genuinely need extra verification from those that do not, so the control becomes blunt rather than selective.

That in turn can weaken downstream control quality. When every transaction is challenged, payment teams may lose sensitivity to the signals that should trigger selective intervention, such as unusual amount, channel, device, or behavioural context. Good checkout security is not just about adding friction, it is about placing the friction where it changes the risk outcome. For practitioners who want a control-based lens, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful anchor for thinking about access, authentication, and risk-aligned enforcement.

How to Keep PSD2 Controls Effective Without Turning Them Into a Revenue Drag

Security teams and payment owners should treat exemption logic, customer segment behaviour, and conversion impact as part of the same control discussion. If the implementation cannot distinguish between high-risk and low-risk transactions, the design is too coarse. If the business cannot explain why a challenge is required in a specific case, the policy is probably over-applied.

What to prioritise: Preserve transaction-level decisioning, because that is what keeps strong customer authentication aligned to risk instead of volume. Monitor challenge rates, abandonment at step-up, and the percentage of eligible transactions forced through the same path.

What to verify: Check that exemption handling is documented, tested, and reviewed with both fraud and commerce teams. A control that looks stronger on paper but increases cart abandonment materially is usually mis-tuned, not improved.

Practitioner takeaway: The right objective is not maximum challenge frequency, it is maximum risk reduction per unit of customer friction, with exceptions handled deliberately rather than erased by policy.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Strong authentication governs access and step-up decisions in transaction flows.
	AC-6 — Least Privilege	Applying friction only when needed reflects minimum necessary control in access decisions.
Recommendation — Tune authentication strength to transaction risk and preserve selective step-up paths. Limit step-up enforcement to transactions that genuinely require additional assurance.
ISO/IEC 27001:2022	A.8.5 — Secure authentication	PSD2 SCA is an authentication control whose use must be proportionate to transaction risk.
Recommendation — Implement strong authentication with exemption handling and risk-based application.
CIS Controls v8	CIS-6 — Access Control Management	Checkout authentication decisions are access-control decisions affecting user path and abuse resistance.
Recommendation — Apply access control rules selectively and review exceptions for business impact.

#1 Authority in NHI Education, Research and Advisory, empowering organizations to tackle the critical risks posed by Non-Human Identities (NHIs), including AI Agents.