Identity teams own assurance at onboarding, recovery, and merchant access points, while fraud teams own detection and response across the transaction flow. The governance gap appears when those responsibilities are separated, because abuse then moves into the handoff between identity verification and transaction approval.
How identity and fraud teams share accountability for delivery-platform abuse
Delivery-platform abuse sits between identity assurance and fraud operations, so accountability has to be shared rather than handed off. Identity teams are closest to onboarding, recovery, and merchant access controls, while fraud teams are closest to transaction monitoring and response. The failure mode is not just unclear ownership, but a gap where bad actors move from verified access into abusive delivery behaviour.
Where the ownership boundary should sit
The cleanest split is by control point, not by team logo. Identity teams should own the quality of access into the platform: proofing, recovery, account changes, merchant enrolment, and any step that creates or restores trust. Fraud teams should own the ongoing abuse decisioning: transaction anomalies, suspicious delivery patterns, linked-account behaviour, and abuse escalation once activity is in motion.
That boundary works only if both teams agree on the same abuse taxonomy and handoff criteria. If identity measures “successful verification” and fraud measures “suspicious transactions” without a shared case model, each team can declare success while the platform still absorbs loss.
Identity governance is therefore part of the operating model, not just an onboarding check. A useful reference point is NHI Ownership and Accountability Guide, which is useful here because the same accountability problem appears whenever access, recovery, and ongoing control are split across functions. The broader lifecycle view in NHI Lifecycle Management Guide also maps well to this boundary, since abuse often begins when lifecycle events are not jointly governed.
Why the handoff is where abuse gets through
Delivery-platform abuse rarely depends on a single broken control. More often, it exploits a sequence: a credible identity event, a legitimate-looking merchant or account state, and then abusive transactions that appear normal in isolation. If identity signs off on access quality but fraud does not receive strong context about who was onboarded, recovered, or reauthenticated, the platform loses the ability to connect pre-transaction trust to post-transaction abuse.
That is why case ownership has to follow the risk, not the workflow chart. Identity Fraud Prevention Guide is relevant because delivery abuse often shares the same patterns as synthetic identity, account takeover, bot-driven fraud, and linked-attribute abuse. The important lesson is that fraud teams should not wait for obvious loss events, and identity teams should not stop at proofing if recovery paths and merchant access can be abused later.
A second useful lens is the platform itself as a trust boundary. Identity Proofing and KYC Guide matters because assurance failures at onboarding and recovery often become the entry point for downstream delivery abuse, especially when attackers can reuse the same access path repeatedly.
What shared accountability looks like in practice
Shared accountability does not mean duplicated work. It means explicit joint ownership of the controls that cross the boundary, with each team accountable for its own segment of the chain. Identity should own the trust decision before access is granted or restored. Fraud should own the abuse decision once platform activity begins. Both should own the escalation path when signals indicate that a merchant, account, or device is being used for delivery abuse.
Practically, that means there should be one case record, one abuse taxonomy, and one agreed severity model. If the identity team sees unusual recovery activity but fraud cannot see it, the organisation is still operating with a blind handoff. If fraud sees repeated low-value abusive transactions but identity cannot correlate them to a risky onboarding or recovery path, the platform will keep relearning the same failure.
For teams building the operating model from scratch, the broader programme view in Identity Security Programme Guide is useful because it frames ownership, funding, and governance as a shared control system rather than a series of isolated team tasks.
Risk and Threat Considerations
Delivery-platform abuse becomes materially worse when account assurance and transaction abuse detection are separated. Attackers do not need to defeat every control, they only need a gap where one team sees legitimacy and another team sees activity too late. That gap is especially dangerous in recovery flows, merchant access, and any approval path that lets a verified actor act at scale.
Failure mechanism: A trusted identity event, such as onboarding or recovery, is accepted without enough fraud context, and later abusive transactions are treated as isolated behaviour instead of part of a coordinated abuse chain.
Impact: The platform can accumulate repeat abuse, financial loss, customer harm, and weak accountability, while each team believes the other owns the problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | Shared accountability depends on explicit role ownership across identity and fraud teams. |
| Recommendation — Define clear control ownership and escalation paths for onboarding, recovery, and abuse response. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Delivery abuse often begins with how accounts are created, changed, or recovered. |
| IA-2 — Identification and Authentication (Organizational Users) | Identity assurance at access entry points is central to the abuse boundary. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Fraud response depends on correlating identity events with transaction abuse signals. | |
| Recommendation — Tighten account lifecycle controls for onboarding, recovery, and merchant access changes. Strengthen identity proofing and authentication where access is granted or restored. Correlate onboarding, recovery, and transaction events to detect abuse chains early. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle control is a core lever for reducing delivery-platform abuse exposure. |
| Recommendation — Review and govern accounts, recovery paths, and privileged access on a recurring basis. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Merchant and platform actions can be abused when access boundaries are weak. |
| Recommendation — Enforce function-level authorization on merchant and delivery actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Abuse often becomes scalable when platform actors retain excess access after onboarding. |
| Recommendation — Remove excess permissions from platform accounts and service actors. | ||
Practitioner Guidance
What to prioritise: Define the shared handoff points first, then assign a named owner for each. The highest-risk gaps are onboarding, recovery, merchant access changes, and any exception path that bypasses normal checks.
Decision rule: If a control changes who can enter the platform or regain access to it, identity owns the control; if it detects or responds to abuse in live activity, fraud owns it; if it influences both, it needs explicit joint ownership and a shared escalation rule.
What to verify: Both teams should be able to trace the same case from trust decision to transaction outcome. If they cannot reconstruct the path without manual stitching, the governance model is too loose.
Practitioner takeaway: The goal is not to merge identity and fraud into one function, but to remove the seams where legitimate access turns into unobserved abuse.
Related resources from NHI Mgmt Group
- How should fraud, identity, and product teams share accountability for trust decisions?
- How do identity teams and data security teams share accountability for on-prem exposure?
- How should security teams handle fraud and identity abuse in eCommerce journeys?
- How do platform and IAM teams share responsibility for workload identity?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org