How should fraud and compliance teams balance stronger verification with user friction?

Why This Matters for Security Teams

Fraud and compliance teams are usually trying to solve two problems at once: stop synthetic identity, account takeover, and deepfake-enabled abuse, while keeping onboarding and step-up checks fast enough that legitimate users do not abandon the flow. The practical tension is that stronger verification reduces risk, but every added control can create delay, drop-off, and support burden. The right answer is not “more checks everywhere”; it is risk-based verification tied to observed confidence and transaction context, a pattern that fits the broader control objectives in the NIST Cybersecurity Framework 2.0.

NHIMG’s guidance on Top 10 NHI Issues shows how identity failures tend to compound when controls are applied without lifecycle discipline, and the same pattern appears in customer verification workflows. When teams over-rely on static rules, they often miss the difference between a low-risk return user and a high-risk synthetic actor using polished documents, replayed biometrics, or automated mule infrastructure. In practice, many security teams encounter escalation failures only after fraud loss or compliance exceptions have already become expensive.

How It Works in Practice

Operationally, balanced verification starts by separating signal collection from final decisioning. Teams gather device, behavioural, network, document, and identity evidence first, then apply policy to decide whether the user can pass, needs step-up, or must go to manual review. That mirrors the lifecycle discipline in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where risk is managed across creation, use, rotation, and revocation rather than at a single point in time.

For fraud and compliance teams, the practical design goal is to use the lightest effective control first. Common patterns include:

• Low-risk users receive passive checks such as device reputation, velocity screening, and document authenticity scoring.
• Medium-risk cases trigger step-up verification such as liveness checks, stronger document proofing, or secondary contact validation.
• High-risk cases route to manual review, enhanced due diligence, or temporary hold until evidence is resolved.

This approach works best when policy is explicit about threshold logic, appeal paths, and what evidence can override a prior decision. It also aligns with control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need repeatable approval, auditability, and documented exceptions. For compliance-heavy environments, risk-based verification can also support obligations under the FATF Recommendations by demonstrating proportionate controls instead of one-size-fits-all friction.

NHIMG research notes that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which is a reminder that verification workflows are only as strong as the identity and evidence sources behind them. These controls tend to break down when confidence signals are noisy, incomplete, or easy to spoof across channels.

Common Variations and Edge Cases

Tighter verification often increases abandonment and review cost, requiring organisations to balance fraud reduction against conversion, fairness, and regulatory defensibility. That tradeoff becomes sharper in environments with thin data, cross-border users, or high-value transactions where the acceptable friction threshold is different.

Best practice is evolving for deepfake defence and synthetic identity detection, and there is no universal standard for this yet. Some teams use more aggressive step-up only when multiple high-confidence signals agree; others prefer earlier manual review for regulated products or first-party fraud exposure. The correct threshold depends on loss tolerance, user type, and whether the workflow is a one-time enrollment or an ongoing session.

Edge cases deserve explicit policy. Returning users should not be treated the same as first-time applicants, and high-trust populations may need fewer prompts unless behaviour changes materially. Compliance teams should also ensure that stronger verification does not become arbitrary or discriminatory, especially where biometrics are involved. Current guidance suggests documenting why a user was escalated, what evidence was considered, and how the decision can be reviewed later. That makes the workflow defensible without forcing universal friction on every transaction.

Related resources from NHI Mgmt Group

• Who should be accountable when identity fraud moves across compliance, fraud, and verification teams?
• How should security teams balance fraud friction with user experience?
• How should security teams balance onboarding speed, fraud prevention, and compliance in verification programs?
• Why do identity verification programmes in crypto need to balance fraud prevention with user friction?