Accountability is shared across regulators, governments, and businesses. Regulators set the rules, governments shape digital infrastructure and intervention capacity, and businesses implement identity, verification, and fraud controls. In high-risk environments, no single party can absorb the full burden. Effective resilience depends on coordinated action across policy, technology, and enforcement.
Why This Matters for Security Teams
When digital fraud risk is high, accountability cannot sit in one silo because the fraud path usually crosses policy, identity, payments, customer operations, and incident response. Regulators define baseline obligations, governments influence the resilience of digital infrastructure, and businesses operate the controls that stop abuse in real time. That split matters because fraud is not only a crime problem. It is also an identity assurance and operational resilience problem.
Security teams often underestimate how quickly weak account recovery, synthetic identities, and abused service accounts can turn into repeatable fraud at scale. NHIs are a major part of that exposure: in Ultimate Guide to NHIs — Why NHI Security Matters Now, NHI Management Group reports that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation. That is a reminder that resilience depends on controls that can adapt across trust boundaries, not just on fraud rules after the fact. Current guidance from NIST Cybersecurity Framework 2.0 also frames resilience as a shared governance outcome, not a single-control objective.
In practice, many security teams encounter the fraud problem only after repeated account abuse, payment abuse, or API abuse has already exposed gaps in ownership and escalation paths.
How It Works in Practice
Shared accountability works best when each party owns a different layer of the fraud-resilience stack. Regulators set expectations for strong customer authentication, reporting, and consumer protection. Governments provide the digital rails, national identity infrastructure, and law enforcement coordination that make intervention possible. Businesses own the operational controls: onboarding checks, device and session risk, step-up verification, velocity limits, secrets hygiene, and response workflows.
For practitioners, the key question is not who is “most responsible,” but who can act at the point of failure. That is where identity controls matter. The patterns described in the Top 10 NHI Issues show how compromised service accounts, leaked API keys, and over-privileged automation can become fraud enablers when they are left outside normal governance. The same lesson applies to customer-facing fraud: if the control plane cannot reliably distinguish legitimate from abusive activity, the organisation will keep paying for detection after damage is done.
- Regulators define minimum assurance, reporting, and consumer redress requirements.
- Governments improve national identity, data-sharing, and enforcement capacity.
- Businesses implement step-up verification, transaction monitoring, and privileged access controls.
- Security teams bind these layers together with logging, policy enforcement, and incident playbooks.
Where operational maturity is stronger, teams map fraud controls to identity governance and use NIST-style risk management to assign owners for prevention, detection, and recovery. Where it is weaker, the organisation treats fraud as a customer-support issue until losses force a redesign. These controls tend to break down in highly federated ecosystems because no single party owns the full identity and transaction path.
Common Variations and Edge Cases
Tighter fraud controls often increase friction, so organisations must balance stronger assurance against customer drop-off, support burden, and regulatory latency. That tradeoff becomes sharper in cross-border payments, open banking, and platform ecosystems where many participants influence the final trust decision.
Best practice is evolving on how much responsibility should shift to the ecosystem versus the end business. Current guidance suggests that accountability should be formalised through shared control mappings, data-sharing agreements, and clear escalation duties, rather than assumed informally. In sectors with heavy automation, the fraud problem can also blend into NHI governance: compromised API keys, vulnerable CI/CD paths, and unmanaged service accounts can bypass traditional fraud screens entirely, which is why NHI management belongs in resilience planning. The 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, underscoring how often hidden machine identities become a resilience gap.
In practice, the edge case is a well-defended customer journey built on poorly governed machine identities, where fraud response appears effective until attacker automation starts using trusted systems as the entry point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Defines organisational context and shared resilience responsibilities. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Fraud resilience often fails when machine credentials are not rotated or revoked. |
| NIST AI RMF | GOVERN | Shared accountability requires clear roles, risk ownership, and oversight. |
Assign fraud-resilience owners across business, tech, and response teams under a common governance model.
Related resources from NHI Mgmt Group
- Why do fraud rings create more risk than isolated fraud attempts in digital platforms?
- When should organisations treat an NHI as a high-priority risk?
- Who is accountable when stronger anti-fraud regulation requires faster account disruption?
- Who is accountable when fraud controls fail across registration, deposit, and withdrawal flows?