When should organisations prioritise transaction risk analysis over strong customer authentication under PSD2?

Organisations should prioritise transaction risk analysis when the transaction qualifies for an exemption and the fraud profile supports it. The key decision is whether the payment can be reviewed with enough confidence to avoid unnecessary step-up friction. That approach helps reduce drop-off, preserve revenue, and keep authentication aligned with actual risk rather than applying the same control everywhere.

How PSD2 decides the balance between fraud review and step-up authentication

Transaction risk analysis is not a replacement for strong customer authentication, but PSD2 allows it to be used in specific exempted cases when the payment service provider can justify the decision from its own fraud and behavioural signals. The practical question is whether the organisation has enough evidence to treat the payment as low risk, so that extra friction would add more cost than protection.

That balance matters most when the payment path already has low observed fraud, the transaction context looks consistent, and the business wants to avoid unnecessary abandonment. In those cases, transaction risk analysis becomes the decision control, while strong customer authentication remains the default control to fall back on when confidence is weaker or the exemption conditions are not met.

What should drive the exemption decision in practice?

The strongest decision inputs are fraud rate, anomaly detection, device and session signals, payee familiarity, and whether the transaction sits inside the organisation’s monitored thresholds. Good transaction risk analysis is not just a score, it is an operational judgement about whether the current payment looks materially different from the customer’s normal behaviour and whether the institution can defend the exemption if challenged.

That means the choice is usually dynamic rather than static. A low-value payment from a known customer on a familiar device may justify transaction risk analysis, while the same customer on a new device, in an unusual location, or with changed behavioural signals may need step-up authentication instead. For a practitioner view of how risk-based authentication and step-up fit into broader customer identity controls, see Customer IAM (CIAM) Guide and the MFA Guide.

In payments environments, organisations should also treat exemption logic as part of the fraud control stack, not as a pure UX decision. PSD2 exemptions only work if the institution can show that the exemption is applied consistently, the monitoring is active, and the risk model is tuned to the actual payment population.

How to avoid using transaction risk analysis too broadly

Transaction risk analysis works best when it is narrowly scoped to payments that can be judged with confidence, because overuse weakens both fraud control and regulatory defensibility. A common failure is to treat every low-friction payment as an exemption candidate, even where the organisation lacks enough visibility into account takeover, device compromise, or payee change behaviour.

That is why the surrounding authentication estate still matters. If the organisation cannot reliably detect suspicious sign-in patterns, session theft, or account recovery abuse, transaction risk analysis may be operating on weak upstream identity signals. Strong customer authentication remains the safer choice when the transaction context is ambiguous or the fraud signal quality is poor. A useful comparison point is how payment-step decisions differ from broader account security controls in the Financial Services Identity Security Guide.

Where organisations see repeated pressure to exempt transactions, the better question is often whether the payment journey or fraud model needs tuning, not whether SCA should be bypassed more often. If the exemption decision cannot be explained in plain terms, or if the same pattern would not be comfortable under review, the business should usually default back to strong customer authentication.

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, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	PSD2 step-up and exemption decisions depend on authenticators and their lifecycle.
	IA-2 — Identification and Authentication (Organizational Users)	Customer step-up decisions hinge on reliable identity and authentication assurance.
Recommendation — Align payment fallback paths with authenticator management and enforce rotation, revocation, and recovery controls. Use stronger authentication when transaction-risk confidence is insufficient.
ISO/IEC 27001:2022	A.5.15 — Access control	The question concerns when to apply stronger versus lighter access assurance for payments.
Recommendation — Define access and authentication decision rules that require escalation when risk exceeds tolerance.
CIS Controls v8	CIS-6 — Access Control Management	Transaction risk analysis and SCA are both access-control decisions affecting payment approval.
Recommendation — Restrict payment-step exceptions to monitored cases with documented approval logic.
NIST CSF 2.0	PR.AA-05 — Identity management, authentication, and access control are managed for all users and devices	PSD2 balancing depends on managed authentication and access decisions for transaction approval.
Recommendation — Manage authentication strength by transaction risk and enforce fallback to stronger assurance when needed.

Practitioner Guidance

What to verify: Confirm that the exemption logic is tied to measurable fraud performance, not just convenience metrics. The organisation should be able to show which signals triggered the transaction risk decision, what thresholds were used, and when the payment was escalated to strong customer authentication.

Decision rule: If the transaction is within an allowed exemption class and the organisation has sufficient fraud telemetry to support a defensible low-risk decision, use transaction risk analysis. If the context is noisy, novel, or hard to explain after the fact, step up to strong customer authentication.

What to prioritise: Prioritise low-friction treatment only for payment flows where abandonment is a real business issue and the fraud profile is stable. That keeps the exemption model focused on genuine operating benefit rather than becoming a blanket shortcut.

Practitioner takeaway: The right choice is not “risk analysis or authentication” in the abstract, but “can this payment be safely exempted with evidence?” If the answer is uncertain, strong customer authentication is the more defensible control.