Developer Guide
Synthetic Identity Detection API: How Multi-Signal Scoring Catches Fake Identities (2026)
Short answer: a synthetic identity detection API catches fabricated identities by scoring how consistent multiple signals are with each other — not by checking any one in isolation. You send email, phone, device, IP, and payment signals in one request and get back a risk_score, a decision, and a reasons array. Synthetic identities pass individual checks but fail correlation (a "new" email next to an aged phone under a different name), which is exactly what the Identity Consistency Engine measures.
Synthetic identity fraud is the hardest fraud to catch because nothing about it looks fake in isolation. This is a developer-oriented walkthrough of how a multi-signal API detects it, with an illustrative request/response, the correlation logic that does the work, and how to wire it into a signup flow. The JSON below is illustrative — confirm exact field names against the live API reference.
Accuracy figures are typical targets; results vary by traffic mix, geography, and configuration.
Table of Contents
What Is Synthetic Identity Fraud
A synthetic identity is a fabricated profile assembled from a mix of real and fake elements — a real but stolen detail here, an invented one there — designed to pass verification and behave like a legitimate user long enough to commit fraud (often a credit bust-out). Because the pieces are chosen to look plausible, each one survives a standard check. For a fuller definition, see our synthetic identity fraud explainer.
Why Single-Signal Checks Miss It
Consider a classic synthetic profile and how each isolated check responds:
- •The email is deliverable and not on a disposable block-list → email check passes.
- •The phone is an active mobile line → phone check passes.
- •The device is an ordinary browser → device check passes.
Every individual gate is green, yet the identity is fake. The tell is in the relationships: the email was created yesterday, but the phone has years of carrier history under a different name. A single-signal pipeline never compares those two facts, so it never sees the contradiction.
How Multi-Signal Correlation Detects It
SwitchID's Identity Consistency Engine scores the relationships between signals (see all signals):
- •Cross-signal correlation — does the phone area code match the IP region? Does the card country match both?
- •Name-variant matching — "John Smith" vs "J Smith" vs "John R Smith" across the email, phone, and card.
- •Temporal consistency — were the email, phone, and device all created/associated in the same narrow window?
- •Network analysis — is the same device or network behind multiple "different" identities?
- •Velocity detection — burst signups from the same IP, device, or email domain.
Combined with phone age/port history, email domain age, and device fingerprint uniqueness, these checks surface identity elements that don't correlate — the signature of a synthetic profile.
The API Call (Illustrative)
Send the signals you have in a single request:
POST /v1/verify
{
"email": "j.smith.2026@example.com",
"phone": "+15555550300",
"ip": "203.0.113.47",
"device_fingerprint": "d41d8cd98f00b204e9800998",
"payment": {
"name": "Jonathan Smith",
"bin": "411111"
}
}And read back a decision with the reasons that drove it:
{
"risk_score": 88,
"decision": "deny",
"reasons": [
"email_age_under_24h",
"phone_name_mismatch",
"phone_history_predates_email",
"ip_datacenter",
"consistency_failure"
],
"signals": {
"email": { "disposable": false, "age_days": 0 },
"phone": { "line_type": "mobile", "name_match": false },
"device": { "reused_across_identities": true },
"network": { "type": "datacenter" }
}
}Here the individual signals look unremarkable, but the engine flags phone_history_predates_email and a consistency_failure — the device is reused across identities and the phone's name doesn't match. The risk_score of 88 lands in the deny band (default 71–100). Default thresholds: 0–40 approve, 41–70 challenge, 71–100 deny — all configurable.
Integrating Into a Signup Flow
Where to call it and how to act:
decision — approve clean users instantly, deny obvious synthetics, challenge the middle.reasons for audit trails and to build a clear appeals path for false positives.Testing Without Real PII
Build against deterministic sandbox credentials so you can verify every branch before sending real data:
| Test input | Decision | Score |
|---|---|---|
+15555550100 / approve@test.com | approve | 10 |
+15555550200 / challenge@test.com | challenge | 55 |
+15555550300 / deny@test.com | deny | 95 |
Test mode is free and unlimited.
Detect synthetic identities in one call
Free Developer tier — 200 verifications/month, no credit card. Test deterministically, then go live.
Frequently Asked Questions
How does a synthetic identity detection API work?
It scores the consistency of multiple identity signals against each other rather than checking any one in isolation. You send the signals a user provides at signup — email, phone, device, IP, and card metadata — and the API returns a risk_score (0–100), a decision (approve/challenge/deny), and a reasons array. The core detection comes from cross-signal correlation: a synthetic identity usually passes each individual check but fails when the signals are compared (for example, a brand-new email paired with a phone that has years of history under a different name).
Why can't single-signal checks detect synthetic identities?
Because synthetic identities are assembled to pass them. The email is deliverable, the phone is active, the device looks ordinary — each check says 'fine.' The fabrication only shows up in the relationships between signals: mismatched name variants, elements all created in the same narrow window, a device reused across identities, or velocity that doesn't match a real person. Detection requires correlating the signals, which is exactly what the Identity Consistency Engine does.
How accurate is synthetic identity detection?
No detection is perfect — synthetic fraud is adversarial and evolving. SwitchID targets a typical ~95% approval rate for real users at a default <2% false-positive goal, and you can tune thresholds to your risk tolerance. The model improves with more signals: detection is stronger when phone, email, device, and payment are all present than when only one or two are. Results vary by traffic mix, geography, and configuration.
Can I test the API without real PII?
Yes. SwitchID provides deterministic test credentials. The phone +15555550100 always returns approve (score 10), +15555550200 returns challenge (score 55), and +15555550300 returns deny (score 95). Similarly approve@test.com, challenge@test.com, and deny@test.com return fixed results. Test mode is free and unlimited, so you can build and verify your integration logic before sending any real data.
How do I integrate it into a signup flow?
Call the API at the point of signup (or first sensitive action) with whatever signals you have, then branch on the decision: approve clean users instantly, deny obvious fraud, and challenge or step up the ambiguous middle (e.g., require phone verification, or trigger a document + liveness check for high-risk sessions). The reasons array tells you which signals drove the decision so you can log it and build appeals. Most teams integrate in under an hour.