The Person Who Doesn't Exist: How Synthetic Identity Fraud Slips Past Static Data

TL;DR: Synthetic identity fraud creates a plausible persona from fabricated details or a mix of real and invented identifiers, so each field can pass a narrow check even though the combined person does not exist. Entity resolution links records at ingestion and preserves shared-attribute relationships, giving fraud and KYC systems the cross-source context needed to find contradictions, reuse, and networks.

Test synthetic identity patterns against a resolved entity graph. Book a Demo or Try Tilores Studio (Free).

Static validation asks whether a field looks valid. A date has the right format. An identifier has the right length. An address exists. An email can receive a message. A document looks internally consistent.

Synthetic identity fraud exploits the gap between valid fields and a real person. The records describe someone, but the identity may combine details that have never belonged to one human being. Each source sees a plausible slice. No source sees the contradiction.

What is synthetic identity fraud?

Synthetic identity fraud is the use of a fabricated persona, often assembled from both real and invented information, to obtain an account, credit, cover, benefit, or another service.

The Federal Reserve’s definition describes a synthetic identity as a combination of real information, such as a legitimate Social Security number, and fictional information, such as a made-up name, address, or date of birth. Other schemes can use entirely fabricated details. The defining point is that the combined persona does not correspond to one real person.

That makes synthetic fraud different from ordinary identity theft. A stolen identity impersonates an existing victim. A synthetic identity constructs a new subject. It is also different from account takeover, where the attacker gains control of an existing account, and from a watchlist false positive, where a legitimate person resembles a listed person by name or other fields.

Those distinctions shape the control. A watchlist process asks whether this real applicant is the listed person. A synthetic identity process asks whether the applicant’s attributes form a coherent person across records and time.

Why do static data checks miss a person who doesn’t exist?

Static checks miss synthetic identities because they validate fields or documents in isolation rather than testing whether the same combination remains coherent across sources.

Check	What it can establish	What it can miss
Format validation	An identifier, date, phone, or postcode has an allowed shape	The fields belong to different people or to no one
Document validation	A supplied document appears authentic and internally consistent	The wider identity has conflicting history elsewhere
Email or phone verification	The applicant controls a channel at that moment	The same channel supports several claimed identities
Address check	An address exists or matches a file	The address is reused across an unusual set of personas
Single-source lookup	The source contains a matching record	Other sources hold contradictory names, dates, contacts, or relationships

None of these checks is useless. The weakness appears when they operate alone. A real identifier can pass its validity check. A newly controlled email can pass a one-time code. A legitimate address can pass an address lookup. The combination still may not describe a real person.

Static rules also lose time. They inspect the current application without asking how the same identifiers behaved in prior applications, accounts, claims, devices, or payment records. Synthetic personas often gain plausibility through repeated use. Without entity history, each appearance looks new.

Which cross-record signals can expose a synthetic identity?

Cross-record signals expose synthetic identities by showing reuse, contradiction, and implausible identity change across time.

Useful signals include:

One approved identifier appearing with several unrelated names or dates of birth.
Several claimed people sharing the same email, mobile number, device, address, or payment instrument.
A persona whose name and date of birth drift while one underlying identifier stays fixed.
New records that almost match several existing entities but do not fit any one of them cleanly.
Contact details moving together across applications that claim to be unrelated.
A cluster of accounts connected through several weak anchors rather than one decisive identifier.

These signals require care. Families share addresses. Businesses share phones. Devices get resold. Email addresses are recycled. A single shared anchor is a reason to search, not a reason to merge everyone into one identity or declare fraud.

The strongest patterns combine independent evidence. Date of birth plus mobile plus postcode is more useful than mobile alone. Email plus device plus payment instrument tells a different story from email alone. A conflict between reliable identifiers can be as important as a similarity.

How does entity resolution change synthetic fraud detection?

Entity resolution changes synthetic fraud detection by maintaining a persistent identity and relationship graph as each new record arrives.

Tilores applies deterministic rules, fuzzy matching, and probabilistic scoring at ingestion. Configured link rules decide when records belong to the same entity. Consistency rules can stop records from merging when reliable fields disagree. Broad search rules can find records that share a phone, email, address, or another anchor without forcing those records into one person.

That last distinction matters. Synthetic fraud often creates a network, not a larger customer profile. If every shared address or phone merges into one entity, the system destroys the pattern that investigators need to see. Separate person entities with graph relationships preserve the ring.

The fraud or KYC service then queries the current resolved context through GraphQL. It can retrieve entity IDs, source records, graph edges, duplicate information, rule hits, entity scores, and search hit scores where configured. Query time does not assemble the person. It retrieves the entity context that the ingestion path already maintains.

Our guide to fraud detection with entity resolution and graph neural networks explains how graph analysis can use that structure. Entity resolution creates the reliable nodes and links. Rules, models, and investigators evaluate the fraud pattern.

What should the entity model link, and what should stay separate?

The entity model should link records that refer to the same person while keeping related people, accounts, devices, and organisations as separate entities.

Observed pattern	Safe first action	Common mistake
Exact high-confidence identifier plus corroborating personal fields	Consider a person link under the configured rules	Ignoring a clear prior identity because the email changed
Shared phone or email only	Return a search cohort or relationship for review	Merging every record that uses the shared contact
Conflicting reliable identifiers	Block or review the merge	Letting fuzzy name similarity override the conflict
Shared device, address, or payment instrument across distinct people	Preserve a graph relationship	Turning a fraud ring into one false person entity
Changed name and address with stable corroborating history	Link when the full rule is satisfied	Treating every change as a new customer

This design supports both precision and discovery. Conservative link rules protect legitimate people from false merges. Search and relationship rules expose the wider network. Investigators can move between the resolved person and the connected cohort without confusing the two.

It also gives the team a correction path. If new evidence shows that records were merged incorrectly, the entity can be split. If an old source record is removed, the graph can update. The next GraphQL query retrieves the current state.

How should synthetic identity controls work beside AML and KYC?

Synthetic identity controls should enrich AML and KYC workflows with resolved context, not replace verification, screening, monitoring, or case management.

Document checks, database checks, biometrics, device signals, transaction monitoring, and behavioural controls each answer a different question. Entity resolution answers, “Which records and relationships belong to this person, and which do not?” A KYC or fraud workflow can then use that context when it applies its own policy.

The real-time AML and KYC entity resolution pattern is relevant because identity state changes after onboarding. A new phone, address, employer, account, claim, or transaction source can reveal a relationship that was not visible on day one. Ingestion-time resolution keeps the entity current before the next review retrieves it.

Tilores sits beside the KYC and AML platform, MDM, warehouse, fraud stack, and case system. It feeds them entity context. It does not make the regulatory decision or take over their governance and review work.

Why does real-time resolution matter for synthetic identities?

Real-time resolution matters because every new event can strengthen, weaken, or contradict the current identity.

A nightly batch leaves a gap between the new application and the resolved result. During that gap, a service can create another account, extend another offer, or treat the applicant as unseen. If the decision is live, the identity update needs to reach the serving path before the next step.

Tilores resolves and assembles records as they are ingested. Once ingestion completes, the fraud service can query the current entity context. That is different from trying to compare raw records inside the decision request. It also differs from a batch file that becomes stale as soon as new records arrive.

The comparison in real-time versus batch entity resolution helps teams decide which path serves which workflow. Historical backfills and warehouse reconciliation still suit batch. New applications, account changes, and fraud decisions need current context.

What evidence should an investigator see?

An investigator should see the source records, matched fields, conflicting fields, graph edges, rule hits, scores, and time sequence behind the entity and its relationships.

A single risk score is not enough. It can rank a case, but it cannot explain why several personas appear connected or why two similar records stayed separate. The review view should preserve source labels and record IDs so the investigator can trace each claim back to its origin.

Time matters too. A synthetic persona can develop gradually. The order in which names, addresses, phones, devices, and accounts appeared can distinguish an ordinary life change from a constructed pattern. The evidence view should therefore make additions, merges, splits, and deletions inspectable.

Most importantly, the interface must separate evidence from conclusion. A shared device is evidence. A resolved match is evidence. Neither is a fraud verdict. The case workflow should record the final decision and the policy applied.

How should a team evaluate synthetic identity resolution?

A team should evaluate synthetic identity resolution with known persons, known synthetic patterns, difficult non-matches, and realistic shared-attribute cases.

Build test sequences, not only record pairs. Start with a legitimate person whose address and phone change. Add household members who share an address. Add two people with a common name and date of birth. Then add fabricated personas that reuse an identifier, contact channel, device, or payment instrument across otherwise different applications.

Check four results:

Does the system link the legitimate person’s changed records?
Does it keep distinct household members and namesakes separate?
Does it expose shared attributes as relationships or search cohorts?
Does each GraphQL result contain enough evidence for a reviewer to understand the match?

Then correct an intentional false merge, ingest another record, and query again. A production identity layer must handle the lifecycle, not only the first match.

FAQ

What is a synthetic identity?

A synthetic identity is a fabricated persona built from invented details or a mix of real and invented information. The combined identity does not correspond to one real person, even when some individual fields are valid.

How is synthetic identity fraud different from identity theft?

Identity theft misuses the identity of an existing victim. Synthetic identity fraud constructs a new persona. A synthetic persona may include one real identifier, but the full set of details does not belong to that real person.

Is synthetic identity fraud the same as a watchlist false positive?

No. A watchlist false positive occurs when a legitimate person resembles a listed person. Synthetic identity fraud concerns a constructed persona whose attributes do not form one coherent real person.

Why can document and field checks miss synthetic identities?

Those checks often validate one document or field at a time. They can confirm format, authenticity, or control without testing whether the same combination remains consistent across prior records and sources.

Does a shared phone number prove synthetic fraud?

No. Families, businesses, and reassigned numbers create legitimate sharing. A shared phone is a search signal that needs corroboration from other identifiers, relationships, and history.

When does Tilores resolve synthetic identity records?

Tilores resolves and assembles records at ingestion using configured deterministic rules, fuzzy matching, and probabilistic scoring. Fraud and KYC systems retrieve the current resolved context through GraphQL at query time.

Does entity resolution replace KYC or fraud monitoring?

No. It supplies persistent entities, relationships, and evidence to those systems. Verification, screening, transaction monitoring, case handling, and final decisions remain in the existing control stack.

What should a synthetic identity evaluation test?

Test legitimate changes, shared households, namesakes, reused contacts, conflicting identifiers, multi-record synthetic patterns, false merges, missed links, entity corrections, and the evidence returned to investigators.