Who is accountable when economic deterrence fails against fraud operations?

Why This Matters for Security Teams

economic deterrence fails when fraud operations can absorb blocks as a cost of doing business. The accountable party is not the single analyst who tuned a rule, but the function that owns the full abuse path across onboarding, device intelligence, rate limiting, and payment or account controls. That matters because attackers rarely depend on one weakness; they chain retries, synthetic identities, and automation until the unit economics turn in their favour.

NHI Management Group’s coverage of DeepSeek breach shows how exposed credentials and downstream access can create fast-moving abuse paths, while the NIST Cybersecurity Framework 2.0 emphasises that outcomes depend on coordinated governance, not isolated control points. The practical question is whether the organisation can make fraud unprofitable across the full kill chain, not whether one detector fired.

Security teams often get trapped by measuring alert volume or blocked attempts instead of the attacker’s total return on investment. In practice, many security teams encounter economic fraud only after account farms, device reuse, and retry loops have already scaled beyond the threshold where a single control can contain them.

How It Works in Practice

Accountability should follow the team that owns the abuse economics end to end. If fraudsters can create accounts cheaply, reuse devices, rotate identities, and keep retrying until a payment or reward flow succeeds, then no single control owns the failure. The response has to combine fraud operations, identity governance, and platform security under one measurable outcome: whether the attack path still produces profit.

That usually means defining ownership around the complete transaction path and assigning control objectives at each step. For example, fraud teams may own velocity and anomaly detection, identity teams may own onboarding assurance and step-up checks, and platform teams may own throttling, device binding, and abuse-resistant APIs. The State of Secrets in AppSec is a useful reminder that control sprawl and slow remediation create the gaps attackers exploit. For governance, current guidance suggests using NIST Cybersecurity Framework 2.0 to map shared outcomes across protect, detect, and respond functions rather than assigning blame to one team.

• Define the abuse path in business terms, such as signup, verification, device trust, retries, and payout.
• Assign a named owner for each stage, but keep one accountable lead for the whole path.
• Measure attacker economics, including cost to create accounts, cost to evade detection, and time to monetise.
• Review whether controls reduce conversion, not just whether they increase block rates.

This guidance breaks down in highly decentralised environments where product teams ship independent risk controls without shared telemetry, because the abuse path cannot be measured consistently.

Common Variations and Edge Cases

Tighter fraud controls often increase customer friction and operational overhead, requiring organisations to balance prevention against conversion, false positives, and support load. That tradeoff becomes sharper when the business depends on low-friction onboarding or real-time payments, because aggressive gating can suppress legitimate activity as quickly as it suppresses abuse.

There is no universal standard for this yet, but best practice is evolving toward shared accountability with clear escalation paths. Some organisations place primary accountability in fraud operations, while others split ownership between fraud, IAM, and platform reliability teams. The important point is that the accountable owner must be able to change multiple parts of the system, not just tune a rule. NHIMG’s The State of Secrets in AppSec highlights how fragmented controls can undermine centralised defence, and that lesson applies directly to fraud economics as well. Where the attack path involves vendor platforms, app stores, or outsourced verification, accountability should extend to the team that can enforce the weakest external dependency, not just internal tooling.

In practice, economic deterrence fails most often when teams optimise their own metrics while the attacker optimises the whole system.

Related resources from NHI Mgmt Group

• Economic Deterrence
• What did the incidents in ServiceNow reveal about support operations?
• Why do indicator-based detections fail against modern identity attacks?
• What breaks when fraud controls assume attacks are repetitive?