Cybersecurity, Identity & Fraud
Synthetic Identity Detection API
A synthetic identity passes every individual check, because every element of it is real. What does not hold up is how the elements fit together.
- Banks and lenders
- Fintech platforms
- Telecom providers
- Buy-now-pay-later providers
- Marketplaces
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Synthetic identity fraud works by assembly. A real national identifier, often belonging to someone who does not monitor their credit, is paired with a fabricated name, a mailbox address and a new phone number. Each element verifies. The identifier is valid, the address exists, the phone connects. Document checks pass because the documents are consistent with the identity being claimed. Nothing is wrong in isolation.
The incoherence shows up in relationships and history. The identifier has no association with that name anywhere in the record. The phone number was activated three weeks ago. The address is linked to eleven unrelated applicants in six months. The applicant's file begins abruptly with no earlier trace. Nothing here is proof, which is precisely why this is a scoring problem and not a rule.
And that is where the real difficulty sits, because the profile of a synthetic identity overlaps heavily with the profile of a genuine person who simply has no history. A recent immigrant, a nineteen-year-old opening a first account, someone who has lived outside the financial system, a person who changed their name after marriage or divorce — all of them look thin, new and loosely connected. A model tuned to catch synthetics will decline real people in those groups unless it is built, measured and operated with that specific harm in mind.
Who buys this
Banks and lenders, Fintech platforms, Telecom providers, Buy-now-pay-later providers, Marketplaces
What the API returns
What comes back
- A coherence score describing how well the identity elements fit together
- Element-level consistency findings: identifier, name, date of birth, address, phone, email
- Relationship signals — shared addresses, devices, phones and bank details across applications
- File-thinness assessment that distinguishes “no history” from “history that contradicts itself”
- Velocity across your own application stream and, where permitted, a consortium
- Reason codes written for adverse-action notices as well as for analysts
- An explicit review recommendation with the specific question a reviewer should resolve
- Thin-file context flags, so a benign explanation for a low score is visible to the reviewer
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/applications/score | Score an application for identity coherence |
| GET | /v1/applications/{id}/reasoning | Full element-level findings and relationship paths |
| GET | /v1/entities/{id}/relationships | Shared-attribute graph around an application |
| POST | /v1/feedback | Report confirmed synthetic, confirmed genuine, or appeal outcome |
| GET | /v1/fairness/report | Outcome-rate reporting across monitored applicant groups |
| POST | /v1/simulate | Replay historical applications against a proposed threshold |
Request and response
illustrativeRequest
{
"application_id": "app_552104",
"applicant": {
"name": "J. Harrow",
"date_of_birth": "1994-03-18",
"national_id_present": true,
"address": { "line1": "Unit 4, 88 Cross Street", "postcode": "M4 5AB", "country": "GB" },
"phone": "+44...8821",
"email": "jharrow94@example.com"
},
"channel": "web",
"product": "unsecured_credit",
"device": { "fingerprint": "df_41c9" }
}Response
{
"application_id": "app_552104",
"scored_at": "2026-10-21T15:31:44Z",
"coherence_score": 31,
"band": "low_coherence",
"recommendation": "manual_review",
"review_question": "Confirm the association between the national identifier and the applicant name",
"findings": [
{ "element": "national_id", "status": "no_name_association",
"detail": "Identifier present in bureau data with a different surname", "weight": 0.33 },
{ "element": "phone", "status": "recently_activated",
"detail": "Number first observed 19 days ago", "weight": 0.14 },
{ "element": "address", "status": "high_applicant_count",
"detail": "11 unrelated applicants in 180 days at this unit", "weight": 0.22 },
{ "element": "email", "status": "consistent", "detail": "Domain and age unremarkable", "weight": 0.00 }
],
"relationships": {
"shared_address_applications": 11,
"shared_device_applications": 3,
"cluster_id": "cl_7731"
},
"thin_file_context": {
"file_depth_months": 4,
"benign_explanations": ["possible recent arrival", "possible first credit product"],
"note": "Low coherence is consistent with both synthetic assembly and a genuine thin file"
},
"reason_codes": ["ID_NAME_MISMATCH", "ADDRESS_APPLICANT_DENSITY", "PHONE_RECENTLY_ACTIVATED"],
"appeal_reference": "apl_552104"
}Where the data comes from
| Your own application history | Past applications with confirmed outcomes — the only data that teaches the model what synthetics look like in your channel |
| Credit bureau identity data | Identifier-to-name-to-address associations and file depth, used strictly within the permissible purpose your agreement allows |
| Telephone number intelligence | Line type, activation recency and portability history from a licensed provider |
| Address reference data | Postal files and property type, which distinguish a residential unit from a mail-forwarding service |
| Device and session signals | Collected by your own client, linking applications that share hardware or behavioural characteristics |
| Consortium data where lawfully available | Cross-institution application signals, only where the participation terms and data protection law both clearly permit it |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Coherence modelling on the relationships between elements rather than the validity of each element, because validity is exactly what a synthetic identity has
- Graph construction over shared addresses, devices, phones and bank details, with cluster scoring that distinguishes an organised ring from a shared house
- Explicit separation of “thin file” from “contradictory file” as distinct features, so absence of history and presence of conflict are never collapsed into one signal
- Reason codes designed up front for adverse-action use, written in language a notice can carry and a reviewer can act on
- Fairness testing as a build deliverable: outcome rates measured across age bands, tenure, nationality where lawfully recorded, and file depth, with disparities reported rather than discovered later
- Threshold selection against the asymmetric cost of errors — a declined genuine applicant and an approved synthetic are not equivalent harms and should not share one threshold
- Human review required by design for the low-coherence band, with the specific question to resolve returned alongside the score
- Drift and disparity monitoring in production, because a model that was balanced at launch does not stay balanced as the applicant mix changes
What it changes for the business
Losses that survive first payment
Synthetic accounts often perform normally before defaulting deliberately, which standard credit models do not catch.
Ring detection
Relationship clustering turns single declines into identification of the whole set of linked applications.
Reviewable decisions
Element-level findings give a reviewer a specific question instead of a score to second-guess.
Documented fair treatment
Disparity reporting and an appeal route are what make this defensible to a regulator and to a declined customer.
How it fits into your product
How it embeds
- Synchronous scoring in the application flow, with a latency budget that fits a live decision
- Review queue integration carrying the findings, the relationship graph and the question to resolve
- An appeal endpoint and reference, so a declined applicant has a route that produces a recorded outcome
- Feedback endpoint for confirmed synthetics, confirmed genuine applicants and appeal results
- Deployment inside your infrastructure, which is the normal arrangement where applicant data cannot leave
- Fairness reporting exposed as an endpoint your compliance function can query directly
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Will this decline real people?
Yes, some, and that has to be designed around rather than hoped away. Recent immigrants, young applicants and people returning to the financial system after years away genuinely do look thin and loosely connected. We treat that as a build requirement: thin-file and contradictory-file signals are kept separate, benign explanations are returned alongside the score, the low-coherence band routes to human review instead of automatic decline, and disparity across applicant groups is measured before launch and monitored after. If your intended use is automatic decline on score alone, we would argue against it and we would want that disagreement on the record.
Is there an appeal route?
There has to be one, and we build it. Every score returns an appeal reference, the reason codes are written so a notice can state them in plain language, and appeal outcomes feed back as labels. A declined applicant who is genuine is the error this system makes most often, so the correction path is part of the product rather than a policy afterthought.
Can this be used for credit decisioning?
It is an identity-coherence signal, not a creditworthiness measure, and it should not be used as a proxy for one. Where it feeds a credit decision, fair-lending obligations, permissible-purpose rules for bureau data and adverse-action notice requirements all apply, and your compliance team sets the constraints. We build to those constraints and will say plainly when a proposed use looks like it conflicts with them.
How much history do you need?
Twelve months of applications with confirmed outcomes is comfortable; six is workable. Synthetic fraud confirms slowly — the account may perform for a year before defaulting — so labels lag. Below six months we would start with relationship and velocity signals, which need no training labels, and add the model once outcomes exist.
Will you use protected characteristics as features?
No. Nor proxies we can identify as standing in for them. Where such attributes are lawfully recorded we use them only for measuring disparity in outcomes, never as model inputs, and the fairness report exists so that distinction is auditable rather than asserted.
Related blueprints
Account Takeover Detection API
Detects compromised sessions from login, device, session and in-account behaviour, and returns a step-up decision rather than a bare score.
IP Reputation Intelligence API
Proxy, hosting, bot and abuse indicators for any IP address, served as a lookup your product can call on every request.
Phishing URL Detection API
Risk scores and threat classification for any URL or domain, as a check your email gateway, browser or messaging product can run inline.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.