The Operational Challenge: One Account Looks Clean, the Network Does Not
A new user signs up with a valid-looking ID document, a clear selfie, a new phone number, and a clean device session. OCR is readable. Liveness passes. The selfie matches the ID portrait. The account is approved.
Days later, another account appears with a different name, document number, phone number, and email address. The face looks similar, but not identical. The device has changed. The account passes again.
This is why synthetic identity fraud detection is difficult. Fabricated profiles are built to pass single-account checks. The fraud signal often appears only when accounts are compared against each other.
In Southeast Asia, the challenge is sharper. Digital banks, e-wallets, lending platforms, gaming apps, and super apps onboard users across different ID formats, Android device tiers, network conditions, and regulatory frameworks.
The Federal Reserve defines synthetic identity fraud as the use of combined personally identifiable information to fabricate a person or entity for dishonest gain. The implication is clear: identity verification cannot stop at one applicant. It must evaluate relationships across accounts.
Under the Hood: Why Traditional KYC Misses Fabricated Profiles
Most onboarding systems are built around a stateless decision flow. A mobile client captures an ID document and selfie, then sends a JSON payload through REST or gRPC to the backend. The risk engine evaluates OCR fields, face match score, liveness result, device fingerprint, IP address, and session metadata. It returns approve, review, or reject.
That architecture works for basic fraud. It fails when the synthetic profile looks clean at the individual level.
The missing layer is cross-account memory. If face embeddings, device fingerprints, document metadata, phone hashes, email hashes, and behavioral signals are not indexed for later comparison, the platform cannot identify identity reuse over time.
Synthetic fraud is therefore a graph problem. The question is not only “Does this user pass KYC?” It is also “Has this face, device, document pattern, or session behavior appeared elsewhere under another identity?”
Step-by-Step Workflow for Cross-Account Detection
Step 1: Normalize Identity Signals During Ingestion
Convert onboarding data into structured, searchable attributes: account ID, document country and type, OCR name, date of birth, hashed document number, face embedding ID, device fingerprint hash, phone and email hash, IP ASN, geo-region, liveness result, face match score, and session timestamp.
Avoid storing unnecessary raw PII where hashed, tokenized, or encrypted attributes are sufficient. FATF’s Guidance on Digital Identity is a useful reference for customer due diligence.
Step 2: Add 1:N Face Search, Not Only 1:1 Face Matching
1:1 face matching asks whether this selfie matches this ID portrait.
1:N face search asks whether this face has appeared before under another account.
That distinction matters. A synthetic fraud ring may reuse the same face with different names, IDs, emails, and phone numbers. Without 1:N search, the platform may approve each account separately.
For scalable deployment, convert detected faces into embeddings and index them in a vector search layer. Approximate nearest neighbor retrieval can return candidate matches quickly, while a more precise comparison model re-ranks results before risk scoring.
Log model version, similarity score, threshold, candidate match count, and review outcome for auditability.
Step 3: Build a Cross-Account Risk Graph
Do not block users based on face similarity alone. Combine biometric, device, document, and behavioral signals into a graph-based view.
| Signal Type | What It Detects | Best Used For | Risk Consideration |
|---|---|---|---|
| Face 1:N Search | Same or similar face across accounts | Synthetic profile clusters and repeated onboarding attempts | Needs threshold tuning and review for borderline matches |
| Device Fingerprint | Shared device, emulator, VM, or reset pattern | Multi-account abuse and scripted account creation | Device sharing can be normal in some markets |
| Document Metadata | Reused templates, edited portraits, or recaptured documents | Document manipulation and fabricated profiles | Compression may reduce image quality |
| Behavioral Signals | Repeated typing, swiping, retry, or session patterns | Bot-assisted onboarding and organized fraud rings | Best used with stronger identity signals |
The goal is to detect clusters. One weak link may be harmless. Multiple links across the same account group should increase risk.
Step 4: Apply Risk-Based Decisions
Cross-account analysis should not create a binary approval model. Use tiered actions: approve and monitor low-risk users, request step-up verification for medium risk, route high-risk users to manual review, and block or freeze critical-risk actions.
This reduces false positives while still escalating suspicious identity networks.
Regional Context: Why Southeast Asia Needs This Layer
First, onboarding is mobile-first. Users may submit images from low-end Android devices, compressed cameras, unstable networks, and poor lighting. Fraud systems must handle quality variation without rejecting too many legitimate users.
Second, ID documents differ across Indonesia, the Philippines, Thailand, Vietnam, Malaysia, and Singapore. Each market has different formats, data fields, capture quality, and verification practices.
Third, regulatory expectations are rising. Bank Negara Malaysia’s Electronic Know-Your-Customer policy document outlines e-KYC requirements for financial institutions. The Bangko Sentral ng Pilipinas’ Circular No. 1170 covers customer due diligence and digital identity systems.
The takeaway: single-session KYC is necessary, but not sufficient. Platforms need a persistent identity layer that can recognize fraud patterns across users, sessions, and time.
How Face++ Supports Cross-Account Identity Analysis
Face++ supports face detection, face comparison, and face search capabilities for onboarding, account recovery, login risk control, and fraud investigation workflows.
For synthetic identity fraud detection, the key capability is connecting 1:1 verification with 1:N identity search. The platform can verify whether a user matches the submitted ID portrait, then help determine whether the same face appears elsewhere in the customer base.
A typical architecture includes client-side image quality control, server-side feature extraction, 1:1 ID-to-selfie verification, 1:N search against enrolled or risk-labeled profiles, cross-signal risk scoring, and API integration with KYC, fraud, and case management systems.
For low-bandwidth environments, image quality checks can reduce unnecessary retries. For high-volume platforms, asynchronous search and batch graph analysis can reduce synchronous onboarding latency.
Technical CTA
If your onboarding flow already uses OCR, liveness detection, and 1:1 face matching, the next maturity step is cross-account identity analysis.
Review whether your current architecture can identify the same face under another identity, connect accounts by device or document signals, route risky clusters to review, and log model scores and thresholds for audit.
Schedule a technical deep-dive with the Face++ team or review your API architecture for 1:N face search and graph-based risk scoring readiness.
FAQ
What is synthetic identity fraud?
Synthetic identity fraud uses a mix of real and fabricated information to create a profile that does not fully belong to a real person.
Why is 1:1 face matching not enough?
It checks one selfie against one ID portrait, but does not detect whether the same face appears across multiple accounts.
What is cross-account analysis?
It compares identity signals across users to find hidden links, such as shared faces, devices, documents, or session patterns.
Does this increase false positives?
Not if deployed with risk-based decisioning. Borderline matches should trigger review or step-up verification.
Is this suitable for mobile-first markets?
Yes. With image quality checks, efficient payload design, and asynchronous search, it can work in low-bandwidth environments.
