When should teams use risk-based friction instead of sending a case to manual review?

Use risk-based friction when the case is uncertain but not clearly fraudulent. Step-up authentication, a one-time passcode, or a document check can resolve ambiguity at lower cost than a full manual queue. This works best when the system has enough signal to distinguish high-confidence good orders, high-confidence fraud, and a narrow middle band that actually needs extra verification.

Why risk-based friction fits the middle band

Risk-based friction is the right tool when the system has enough signal to separate routine good outcomes from clearly bad ones, but not enough certainty to auto-decide the ambiguous middle. It reduces queue pressure by resolving uncertainty at the point of decision, while keeping the highest-risk cases available for deeper scrutiny.

The practical advantage is speed with restraint: you add just enough verification to increase confidence without forcing every borderline case through a full analyst workflow. That makes it a control choice, not just an optimisation choice, because the friction itself is part of the decisioning path.

What kinds of checks belong here

Use friction that is proportionate to the uncertainty and easy to complete when the case is legitimate. Step-up authentication, a one-time passcode, device or session revalidation, or a document check can all be appropriate when they answer a specific doubt rather than reopen the entire case.

The key is that the added step should resolve the ambiguity you actually have. If the uncertainty is about account control, use a control that proves current access. If it is about identity or entitlement mismatch, use a control that tests that mismatch directly. If the added step does not improve confidence, it is just delay.

When manual review is the better call

Manual review is better when the case lacks enough reliable signal, when the potential impact is high, or when the team needs judgment that the control layer cannot supply. A human queue is most defensible for edge cases that require context, exceptions, policy interpretation, or a composite view across multiple weak signals.

Risk-based friction works best when the decision space is narrow and bounded. Once the case starts involving conflicting evidence, repeated failures, suspected collusion, or patterns that could indicate systematic abuse, the value shifts from lightweight verification to a fuller investigation.

Risk and Threat Considerations

Risk-based friction can fail if teams apply it too broadly or tune it too loosely. In that case, fraudsters learn which step-up checks are easy to pass, while legitimate users absorb extra delay without meaningfully improving decision quality.

Failure mechanism: The control becomes a predictable hurdle that bad actors can probe and adapt to, or it becomes so weak that it does not change the probability of a correct decision. Overuse also creates friction drift, where more and more cases are routed through challenge steps instead of being properly separated by confidence.

Impact: Weak friction increases false reassurance, weakens the signal-to-noise ratio for manual reviewers, and can push genuinely suspicious cases into a slow, noisy path while routine cases suffer avoidable abandonment or support burden.

Standards & Framework Alignment

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

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Step-up checks and OTPs rely on managed authenticators and their lifecycle.
	IA-2 — Identification and Authentication (Organizational Users)	Manual review and step-up verification both depend on authenticating the actor at the decision point.
Recommendation — Manage authenticators so challenge steps remain reliable, revocable, and limited to the intended decision. Use strong authentication when extra verification is needed before allowing a higher-risk action.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication and Access Control	Risk-based friction is an access decision that adjusts authentication or verification by risk.
Recommendation — Apply risk-based authentication controls to add friction only where uncertainty justifies it.
OWASP ASVS	V6 — Authentication	Step-up authentication and OTP-based verification are authentication controls used to resolve ambiguity.
Recommendation — Require stronger authentication when a case crosses the threshold for additional verification.
OWASP API Security Top 10	API2 — Broken Authentication	If friction relies on weak verification, attackers can bypass the intended assurance step.
Recommendation — Harden authentication checks so challenge steps actually raise assurance instead of adding delay.

Practitioner Guidance

What to prioritise: Tune the decision threshold first, not the individual control. The question is whether the case is uncertain enough to justify a cheap verification step, but not so uncertain that the only sensible outcome is analyst review.

What to verify: Each friction step should have a clear purpose, a measurable completion rate, and a known failure mode. If the check does not materially reduce uncertainty or does not change downstream handling, it should not sit in the flow.

Decision rule: Use friction when one additional signal can reasonably resolve the ambiguity; send to manual review when the case needs context, exception handling, or multi-signal judgment that a scripted check cannot provide.

Practitioner takeaway: Risk-based friction is for uncertainty reduction, not for punishing suspicion; the best implementations keep the middle band small, measurable, and explicitly bounded.