Notifications
Clear all
Topic starter
10/07/2026 9:22 pm
TL;DR: Cyber-fraud fusion now spans onboarding proofing, government source validation, continuous device and behavioral intelligence, and cross-account graph analysis, yet most stacks only cover two of those modules, according to Incode. The missing layers leave synthetic identity, agentic account takeover, and coordinated fraud clusters under-governed.
NHIMG editorial — based on content published by Incode: Cyber-Fraud Fusion in Practice: The Four-Module Stack Most Vendors Are Missing
By the numbers:
Questions worth separating out
Q: How should security teams design identity controls for cyber-fraud fusion?
A: Design the stack as four separate controls: onboarding proofing, government source validation, continuous runtime intelligence, and cross-account graph analysis.
Q: Why do document checks alone fail against synthetic identity fraud?
A: Document checks only prove that an artefact looks valid, not that the person behind it exists in authoritative records or is entitled to the account.
Q: How do organisations know whether continuous identity intelligence is working?
A: It is working if the programme can distinguish the enrolled identity from the entity operating the account during the session.
Practitioner guidance
- Build separate controls for onboarding and runtime trust Do not let document verification carry the weight of continuous identity assurance.
- Add government source-of-truth checks for high-risk identities Use authoritative records when document authenticity alone would allow synthetic identities to pass.
- Instrument post-login behaviour as a security signal Monitor device similarity, behavioural drift, and session consistency after the account is created.
What's in the full article
Incode's full article covers the operational detail this post intentionally leaves for the source:
- The four-module fusion architecture with examples of what each module catches and what it misses.
- Practical questions for self-assessing whether your fraud and identity stack has any missing coverage modules.
- The article's explanation of why government validation and graph intelligence are the hardest modules to operationalise.
- The vendor's description of how agentic traffic and synthetic identity patterns change detection requirements.
👉 Read Incode's analysis of the four-module cyber-fraud fusion stack →
Cyber-fraud fusion and the identity stack gap teams are missing?
Explore further
10/07/2026 9:44 pm
Cyber-fraud fusion is an identity architecture problem, not a dashboard problem. The article is right to frame the issue as coverage geometry across attack classes rather than feature count. In practice, the industry often treats fraud and IAM as adjacent functions when they are actually different views of the same identity lifecycle. Practitioners should read this as a warning that control boundaries, not interface polish, determine whether abuse is visible.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Only 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
A question worth separating out:
Q: Who is accountable when fraud and identity controls are split across teams?
A: Accountability should sit with the function that owns end-to-end identity risk, not with whichever team first sees the event. Fraud, IAM, and security operations need shared thresholds, shared escalation paths, and shared ownership for cross-account detection. Otherwise, every team can see part of the abuse and none can stop the full pattern.
👉 Read our full editorial: Cyber-fraud fusion needs four identity modules, not two
