Who is accountable when synthetic identities enter a marketplace?

Accountability usually sits across fraud, identity, and product teams, which is why ownership needs to be explicit. IAM and fraud operations must share the same trust signals, while product teams need to understand which experiences can tolerate step-up checks. If ownership is fragmented, abuse will exploit the gaps between teams.

Why This Matters for Security Teams

Synthetic identities in a marketplace are not just a fraud problem or just an identity problem. They are a governance problem because marketplace trust depends on signals from signup, device posture, payment behavior, session risk, and downstream abuse detection. When those signals are split across teams, attackers exploit the seams between controls, especially where onboarding is fast and moderation is light.

NHI Management Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a useful reminder that identity abuse rarely stays isolated to one control plane. The same pattern appears in marketplace abuse when synthetic accounts are used to harvest access, manipulate reputation, or automate fraudulent transactions. For control design, current guidance suggests aligning ownership to the outcome being protected, not to the system boundary. NIST SP 800-53 Rev. 5 provides a useful baseline for accountability and access control expectations, but teams still need explicit operational ownership to make those controls work in production.

In practice, many security teams encounter synthetic identity abuse only after chargebacks, spam, or partner complaints have already revealed the gap, rather than through intentional governance.

How It Works in Practice

Accountability should be assigned by control stage, with a single named owner for each decision point. Fraud teams usually own abuse patterns and risk scoring, identity teams own verification and trust signals, and product teams own the user experience when step-up checks interrupt a transaction. The goal is not to merge all responsibility into one team, but to define who can approve, who can block, and who must respond when a synthetic identity crosses a threshold.

That operating model works best when the same signals feed both prevention and response. For example, if device reputation, email age, payment instrument reuse, and velocity rules all indicate synthetic behavior, the case should move through a shared workflow rather than separate queues. The Ultimate Guide to NHIs shows why this matters at scale: NHI Management Group reports that only 5.7% of organisations have full visibility into their service accounts, which is a strong indicator that fragmented ownership creates blind spots.

Operationally, mature teams use:

• Clear RACI ownership for fraud, IAM, trust and safety, and product security
• Shared trust signals in one case-management or decisioning layer
• Escalation rules for marketplace onboarding, listings, and payout changes
• Audit trails that show which team approved, denied, or reviewed each action

For technical control design, NIST SP 800-53 Rev. 5 is a useful reference for access control, auditability, and incident handling, while marketplace abuse patterns are easier to understand through case studies such as JetBrains Marketplace AI Plugin Campaign and Code Formatting Tools Credential Leaks, where trust in a distribution channel was exploited through hidden abuse paths. These controls tend to break down when the marketplace uses separate owners for signup, payout, and moderation because attackers can pivot through whichever team has the slowest response time.

Common Variations and Edge Cases

Tighter ownership usually improves accountability, but it also increases coordination overhead, requiring organisations to balance faster abuse response against product friction and release speed. There is no universal standard for this yet, so the right model depends on whether the marketplace is consumer-facing, partner-driven, or embedded inside a platform ecosystem.

In high-volume marketplaces, product teams often resist heavy step-up checks because they can suppress conversion. In those environments, best practice is evolving toward risk-tiered ownership: low-risk actions stay streamlined, while higher-risk events such as payout changes, bulk listing creation, or account recovery require stronger review. If synthetic identities are tied to automated agents or scripted ecosystems, the accountability boundary becomes even more important because one bad actor can create thousands of identities faster than a manual review queue can respond.

Another edge case appears when a marketplace relies on third parties for verification or moderation. In that scenario, the vendor may execute the control, but accountability still remains with the marketplace owner. NHI Management Group notes that 92% of organisations expose NHIs to third parties, which is a reminder that delegated execution does not remove governance responsibility. Current guidance suggests writing ownership into policy, response playbooks, and control attestations so no team can assume another group is handling it.

Related resources from NHI Mgmt Group

• Who is accountable when SMS pumping drives fraud losses in a marketplace?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?