Use risk-based decisioning rather than broad blocking. The goal is to distinguish high-risk from low-risk activity using multiple signals, then apply friction only when the evidence justifies it. Teams should track approval rate and false-positive rate alongside fraud loss so prevention does not damage trusted-user experience.
Why This Matters for Security Teams
Fraud controls are only effective when they reduce abuse without creating unnecessary abandonment. For customer-facing journeys, the real risk is not just fraudulent sign-ups or account takeovers, but also overblocking legitimate users at key moments such as onboarding, password reset, payment, or step-up authentication. Security leaders therefore need a decision model that separates trust from suspicion, rather than treating every friction point as equally necessary. The control challenge maps well to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access, monitoring, and verification controls must be balanced against usability.
Risk-based decisioning is the practical answer because it lets teams use device signals, behaviour patterns, velocity, identity confidence, and transaction context together instead of relying on a single hard rule. That matters because fraudsters adapt quickly, while legitimate customers vary widely in how they authenticate and transact. Current guidance suggests that customer conversion should be treated as a security outcome as well, since a control that drives users to churn can weaken the business more than the fraud it prevents.
In practice, many security teams discover that their fraud rule set is working only after trusted customers have already been pushed out of the journey.
How It Works in Practice
Effective balancing starts with a layered policy model. Low-risk activity should pass with minimal interruption, while higher-risk events trigger progressively stronger checks. That usually means combining identity verification, device fingerprinting, behavioural analytics, transaction context, and historical trust into a score or policy decision. The objective is not perfect certainty, but a defensible threshold for when to add friction, request re-authentication, or route to manual review.
Security and fraud teams should define controls by journey stage. Onboarding often needs identity proofing and fraud screening. Login needs account takeover detection and adaptive step-up. Payments and beneficiary changes need stronger transaction monitoring and explicit confirmation. Where personal identity assurance matters, eIDAS 2.0 — EU Digital Identity Framework is relevant because it reinforces the importance of interoperable identity assurance and trusted authentication in regulated digital transactions. Where the organisation has AML or KYC obligations, the FATF Recommendations — AML and KYC Framework should inform escalation rules, recordkeeping, and customer due diligence.
- Use multiple signals, not one blocklist or one score.
- Apply step-up only when the risk increase is material.
- Track approval rate, abandonment, false positives, and fraud loss together.
- Separate prevention logic for onboarding, login, and transaction events.
- Review decisions against recent fraud patterns to reduce rule drift.
Operationally, the best programs create feedback loops from confirmed fraud, customer complaints, and manual review outcomes so thresholds can be tuned by channel and geography. They also preserve evidence for audit and dispute handling, because a friction decision that cannot be explained is difficult to defend. These controls tend to break down when identity signals are sparse, device data is unreliable, or legitimate users share networks and behaviours with fraud rings, because the risk model loses discrimination power.
Common Variations and Edge Cases
Tighter fraud controls often increase drop-off, requiring organisations to balance loss prevention against conversion and support burden. That tradeoff becomes sharper in markets with high mobile usage, shared devices, thin-file users, or heavy privacy restrictions, where fewer signals are available and false positives rise. Best practice is evolving here: there is no universal standard for how much friction is acceptable, so teams should set thresholds by product risk, customer segment, and regulatory exposure rather than copying a generic policy.
Edge cases matter. High-value transactions may justify stronger controls than low-value recurring purchases. First-party fraud can look like legitimate activity, so manual review still has a role in some flows. In cross-border environments, national identity assurance, payment regulation, and sanctions screening can all influence the same journey. Where digital identity is part of the customer experience, trust frameworks should support a smoother path for verified users rather than forcing repeated checks. That is why many mature programs treat identity confidence as an input to fraud policy, not as a separate compliance exercise.
For teams designing these controls, the key question is not whether to add friction, but where friction actually improves trust. Controls should be revisited whenever the business launches a new market, changes payment rails, or introduces delegated access, because the fraud pattern shifts faster than static rules do.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Adaptive access decisions support least privilege and risk-based authentication. |
| NIST SP 800-63 | IAL/AAL | Identity assurance and authenticator strength affect customer verification and trust. |
| EU AI Act | If AI scoring drives fraud decisions, governance must cover transparency and oversight. |
Use PR.AC-4 to gate access with context, then step up only when risk is elevated.
Related resources from NHI Mgmt Group
- How can regulated gaming teams balance fraud prevention with conversion?
- How should teams balance fraud prevention with low-friction customer onboarding?
- How should security teams classify AI agent traffic in fraud prevention flows?
- What do security teams get wrong about fraud prevention in iGaming?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org