Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

Mobile synthetic identity fraud: what IAM and fraud teams miss


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 20377
Topic starter  

TL;DR: Mobile synthetic identity fraud is accelerating alongside digital banking, with attackers stitching together real PII, deepfakes, emulators, and bots to bypass mobile KYC flows, according to Guardsquare. The control gap is not just verification quality but whether the app can prove it is running untampered in a trusted environment.

NHIMG editorial — based on content published by Guardsquare: Protect Your Mobile App From “Frankenstein Fraud”

By the numbers:

Questions worth separating out

Q: How should security teams reduce synthetic identity fraud in customer onboarding?

A: Security teams should combine document proofing, data validation, device intelligence and reputation checks in a single onboarding policy.

Q: Why do synthetic identities make modern KYC harder?

A: Synthetic identities are harder because they can pass individual checks while still being fake in aggregate.

Q: What breaks when mobile apps do not check for tampered environments?

A: When tampered environments are not checked, attackers can automate onboarding, spoof camera input, and run large-scale fraud from emulators or rooted devices.

Practitioner guidance

  • Harden mobile onboarding against runtime tampering Add device integrity checks, rooting and jailbreaking detection, and runtime protection around camera and document capture so manipulated sessions are blocked before KYC completion.
  • Move fraud controls to the API enforcement layer Use server-side app attestation to validate app state, device context, and request legitimacy before account creation.
  • Detect synthetic identity patterns across identity attributes Correlate breached PII, account age, device consistency, and transaction behaviour to identify identities assembled from multiple sources.

What's in the full article

Guardsquare's full post covers the operational detail this post intentionally leaves for the source:

  • Runtime protection and attestation logic used to detect emulators, rooted devices, and hooking frameworks
  • Examples of how mobile apps can crash or block sessions when camera API hooks are detected
  • Server-side policy patterns for rejecting bot-driven account creation before fraud can start
  • Threat monitoring details that link device clusters, geolocation, and fraud telemetry

👉 Read Guardsquare's analysis of mobile synthetic identity fraud and app protection →

Mobile synthetic identity fraud: what IAM and fraud teams miss?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 4 months ago
Posts: 19968
 

Synthetic identity fraud is now an identity governance problem, not just a fraud problem. The article shows that attackers rely on the same trust assumptions that identity verification systems are built on, then layer automation and deception on top. That means fraud prevention, mobile security, and lifecycle identity governance must be treated as one control plane. Practitioners should stop separating onboarding trust from runtime trust.

A question worth separating out:

Q: Who should own fraud controls when IAM and fraud teams overlap?

A: Ownership should sit with the team accountable for the decision point, while IAM, fraud, and compliance all contribute the signals and policy. If one group owns alerts and another owns action, attackers exploit the gap. Shared governance matters more than shared tooling.

👉 Read our full editorial: Mobile synthetic identity fraud is scaling faster than KYC controls



   
ReplyQuote
Share: