Both. Fraud teams need behavioural detection and loss prevention, while IAM teams need stronger identity assurance across the full lifecycle. If the two functions do not share signals, synthetic identities can pass one control layer and defeat the other.
Why synthetic identity is a shared fraud and IAM problem
Synthetic identity is not just a scam pattern, it is a control-gap pattern. Fraud teams usually see the financial behaviour, velocity and loss signals, while IAM teams control how identity is established, strengthened and revoked over time. If either side works alone, the synthetic identity can survive because the business problem spans both detection and assurance.
The practical split is simple. Fraud functions are best at spotting anomalous openings, unusual attribute combinations, bot activity and early loss indicators. IAM functions are best at reducing how easily a fake identity is admitted, re-used or left in a trusted state. Identity Fraud Prevention Guide is directly relevant because it treats synthetic identity, account takeover, bot signals and device intelligence as part of one fraud-control surface.
This is why synthetic identity should be treated as a shared operating issue rather than a handoff. Fraud can block a suspicious application, but IAM can still be left with a weak proofing, recovery or lifecycle path that makes the same identity look legitimate later. Conversely, strong IAM without fraud telemetry can still approve a well-formed synthetic profile that has been engineered to look clean at onboarding and then slowly monetised.
Where the control boundary breaks down
Synthetic identity exploits the space between “looks valid” and “is trustworthy.” A record can pass document, email or phone checks, receive an account, and still be fabricated from a mix of real and invented attributes. Over time it may build history, accumulate trust and defeat controls that assume the identity was legitimate at birth. Identity Proofing and KYC Guide is useful here because it ties proofing assurance, liveness checks and onboarding fraud into one assurance model.
The break usually appears at one of three points: admission, persistence or monetisation. Admission failures happen when onboarding controls are too shallow. Persistence failures happen when account recovery, change management or step-up authentication does not re-test trust. Monetisation failures happen when a synthetic identity can be used across products, channels or limits without correlated detection. When those layers are separated, one team sees “approved,” another sees “fraud loss,” and nobody owns the full identity story.
That is why Identity Security Programme Guide matters for this topic: it frames identity governance, lifecycle ownership and cross-functional RACI as programme issues, not isolated tooling choices. Synthetic identity gets harder when proofing, fraud, IAM and operations all agree on who owns the signal, the decision and the follow-up action.
How practitioners should divide responsibilities without dividing the truth
The right model is shared responsibility with shared signals. Fraud teams should own pattern detection, loss prevention thresholds and case escalation. IAM teams should own identity proofing strength, lifecycle controls, recovery integrity and access assurance. Both teams should work from the same identity record, the same risk score inputs where possible, and the same exception policy so that a decision in one layer does not silently undo the other.
Good practice is to connect onboarding, authentication and downstream account behaviour into one review path. If a synthetic identity is detected after account creation, the response should include not only case closure or chargeback action, but also the identity proofing method, recovery factors, linked accounts and privilege review. For broader lifecycle design, NHI Lifecycle Management Guide is a useful analogue for how lifecycle discipline, inventory, rotation and offboarding reduce stale trust and orphaned access.
In practice, the teams should agree on one decision rule: if the identity can still authenticate, recover, transact or be re-issued after being flagged by fraud, then the IAM side of the control path is still too weak. That is the point where stronger assurance, tighter step-up checks, or stronger deprovisioning logic is needed, not just more fraud review.
Risk and Threat Considerations
Synthetic identities create compound risk because they can bypass one control layer while appearing normal in another. The main exposure is not only direct loss, but also polluted identity data, distorted risk models and a longer attacker dwell time inside customer or account ecosystems.
Failure mechanism: A fabricated identity passes onboarding, builds credible history and then uses the gap between fraud detection and identity assurance to preserve access, recover accounts, or open higher-value relationships before the organisation connects the signals.
Impact: Losses can scale across accounts, channels and products, and the organisation may also inherit bad identity data that weakens future proofing, monitoring and exception handling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Identity proofing and assurance directly shape synthetic identity admission risk. |
| Recommendation — Use assurance levels and phishing-resistant authentication to make fabricated identities harder to establish. | ||
| NIST SP 800-53 Rev 5 | IA-12 — Identity Proofing | Synthetic identity hinges on whether an identity is validly established at onboarding. |
| IA-5 — Authenticator Management | Fraudulent identities often persist through weak recovery and credential lifecycle control. | |
| AC-2 — Account Management | Synthetic identities exploit lifecycle gaps after initial approval, especially account creation and revocation. | |
| Recommendation — Strengthen identity proofing before account issuance and tie exceptions to documented review. Control authenticator issuance, rotation and revocation so compromised or fabricated identities cannot persist. Review account lifecycle events continuously and disable identities that fail risk checks. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle discipline is central when fraud and IAM share responsibility for identity trust. |
| Recommendation — Inventory accounts, remove stale access and enforce timely deprovisioning for suspicious identities. | ||
| OWASP ASVS | V6 — Authentication | Authentication strength affects whether a synthetic identity can later re-enter or escalate trust. |
| V14 — Data Protection | Identity data quality and protection matter because fraud and IAM depend on trustworthy attributes. | |
| Recommendation — Require strong authentication and recovery controls before allowing high-risk identity actions. Protect identity attributes and validate high-risk changes before they alter trust decisions. | ||
Practitioner Guidance
What to verify: Make sure fraud, IAM and operations are looking at the same identity lifecycle events, not separate views of the same person or account. If one team can approve, recover or reissue without the other seeing it, the control model is split.
Decision rule: If a customer can survive an onboarding challenge but still looks suspicious on behaviour, treat it as a lifecycle and monitoring problem, not just a case review problem. If a customer looks legitimate in behaviour but weak in proofing, treat it as an assurance failure that can later turn into fraud.
What practitioners underestimate: The most damaging synthetic identities often look only slightly wrong at first. The issue is not a single failed check, it is the accumulation of small trust decisions that no team re-evaluates together.
Practitioner takeaway: Synthetic identity is best handled as one control problem with two owners, fraud for detection and loss containment, IAM for assurance and lifecycle integrity. If those owners do not share signals and escalation rules, the attacker only needs to beat the weaker layer once.
Related resources from NHI Mgmt Group
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