How should fraud teams implement targeted friction without hurting conversion?

Start by classifying journeys by risk and customer intent, then assign the lightest effective control to each path. Use passive monitoring for normal behaviour, step-up authentication for meaningful anomaly, and manual review only where loss exposure justifies it. The goal is precision, not maximal obstruction, because unnecessary friction directly affects abandonment and revenue.

Why This Matters for Security Teams

Targeted friction is a fraud control decision, not a purely UX choice. If every journey gets the same challenge level, high-risk abuse still slips through while legitimate customers are pushed into abandonment. The better pattern is to align controls to intent, device and behavioural confidence, and downstream loss exposure. That is consistent with risk-based thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls and with NHI governance lessons from Ultimate Guide to NHIs, where over-broad privilege and weak lifecycle control create avoidable exposure.

For fraud teams, the practical challenge is that friction has to be selective enough to catch synthetic or manipulated journeys, but invisible enough that genuine customers do not feel punished. That means using passive signals first, then escalating only when the risk score, step-up confidence gap, or transaction pattern justifies it. The same logic applies to agentic and non-human workflows that initiate payments, refunds, or account changes: if their identity posture is weak, fraud control has to account for machine speed as well as human intent. In practice, many security teams encounter excessive abandonment only after a broad challenge policy has already been pushed live.

How It Works in Practice

Effective targeted friction usually starts with journey segmentation. The fraud engine should distinguish low-risk browsing from account takeover indicators, high-value checkout, first-time payout, password reset, and sensitive profile changes. Each path gets a different control tier based on observed behaviour, historical loss, and customer value. This is where precision matters: the aim is not to “catch everything” with one heavy control, but to apply the lightest effective check that still changes attacker economics.

Good implementations combine several signals before stepping up. Common inputs include device reputation, velocity, payment instrument consistency, geo-variance, session integrity, and prior trust history. Where a control is needed, it should be proportionate: silent monitoring, then an out-of-band challenge, then manual review only if the expected loss justifies delay. The Ultimate Guide to NHIs is relevant here because automated journeys often depend on API keys, service accounts, or bots that can look “normal” at the customer layer while being weakly governed underneath. If those machine identities are over-privileged or poorly rotated, targeted friction at the front door may be too late to stop abuse.

• Use passive monitoring for known-good behaviour and low-value actions.
• Trigger step-up only on meaningful anomalies, not on a single weak signal.
• Apply stronger checks to account recovery, payout changes, and first-time beneficiaries.
• Route borderline cases to manual review when the fraud loss exceeds the customer delay cost.

Operationally, this works best when fraud, IAM, and product teams share decision thresholds and measure abandonment by journey, not just by channel. These controls tend to break down when legacy rules engines cannot separate high-risk sessions from high-value legitimate sessions because everything gets the same threshold.

Common Variations and Edge Cases

Tighter friction often increases abandonment and support load, requiring organisations to balance fraud reduction against conversion, customer trust, and review capacity. Best practice is evolving, especially where fraud scoring is blended with agentic automation or delegated third-party activity. There is no universal standard for this yet, so the right answer depends on risk appetite and the sensitivity of the journey.

One common edge case is trusted repeat customers whose behaviour changes for legitimate reasons, such as travel, device upgrades, or accessibility tools. Another is automated legitimate activity, including bots that place orders on behalf of customers or internal service accounts that initiate refunds or entitlement changes. In those cases, the fraud stack should avoid treating automation as inherently suspicious. Instead, it should verify identity posture, entitlement scope, and transaction context before escalating. This is where NHI governance becomes relevant: machine actors should be known, constrained, and observable, not hidden inside broad exceptions.

Current guidance suggests measuring friction by fraud prevented per thousand challenged journeys, not by total challenge volume. That helps avoid “security theatre” where controls look strict but do not materially reduce loss. For controls and audit alignment, teams can map escalation logic to NIST SP 800-53 Rev 5 Security and Privacy Controls while using the NHIMG research on broad NHI exposure to justify stronger governance for automated actors. In practice, the hardest failures appear when high-risk automation is left on a low-friction path because nobody has connected fraud policy to identity ownership.

Related resources from NHI Mgmt Group

• How should security teams implement passkeys without hurting login conversion?
• How should security teams implement zero trust authentication without adding too much user friction?
• How should security teams implement stronger authentication without creating more user friction?
• How should security teams implement just-in-time access without creating too much friction?