Synthetic identity

What a synthetic identity is

A synthetic identity is a constructed identity that matches no real person. It's assembled by combining data: some true and belonging to different people, some invented, all consistent with each other.

It's not a fake document nor the use of someone else's document. It's a new file that no database had before and that, reviewed field by field, has nothing wrong with it.

That's what sets it apart from everything else. In an identity impersonation there's a real person whose data was used. In an account takeover there's a holder who loses their account. In a synthetic identity there's nobody on the other side. There never was.

The key is coherence: this is not one false data point inside an otherwise correct file, but an entire file built to withstand the usual checks — because it was built for exactly that.

There's no victim to complain, and that's why it surfaces late

Most identity frauds get detected because someone raises the alarm. The impersonated person receives a notification they don't understand, the holder of an account sees a transaction they didn't make, and that alert is the signal that starts the investigation.

A synthetic identity doesn't produce that signal. The file pays its installments, updates its details and behaves better than the portfolio average, because the fraud requires it to behave well. There's no person waiting for a notice and no claim to open.

The consequence is that the organization learns about the case at the end and in the worst way. The file stops paying from one day to the next and answers no contact. That moment is called bust-out.

And there's an effect that makes the problem worse: when the bust-out arrives, the case looks like a default. A customer with history who stopped paying is the definition of delinquency. Unless someone looks at it with a fraud lens, the loss gets classified as credit risk, provisioned as delinquency and never reaches the fraud team. The synthetic identity that worked shows up in no fraud statistic, because it was booked as something else.

That is where the operational consequence comes from: identity theft is detected from the outside, when the real account holder speaks up. A synthetic identity is only detected from the inside, when the organization looks for patterns with no one having flagged that there is something to look for. That is why it tends to sit inside a portfolio for much longer, and why it often gets classified as a write-off before it gets classified as fraud.

How the attack runs, step by step

It's the slowest fraud of the set. Its cycle is measured in months, and that patience is exactly what makes it profitable.

1. Build the identity. A combination of fragments: a rarely used ID number or one with no history attached, an invented name, a date of birth that doesn't match, a real address of an unrelated property. The goal isn't to imitate anyone, it's to assemble something consistent.
2. Give it a footprint. A phone number, an email, an address that receives mail, minimal online presence. Every element the identity accumulates makes it more credible for the next check.
3. Enter through the most accessible product. An account with no credit line, a wallet, a subscription service, a low-risk product. The first signup is almost never the goal: it's the one that produces the first verifiable record.
4. Build history. Months of normal use and on-time payments. Each month of good behavior improves the identity's score and unlocks the next product.
5. Scale the credit. Limit increases, new products, signups at other institutions using the history already built. Often the same identity operates at several institutions at once, and none sees the whole picture.
6. Bust-out. Simultaneous use of all available credit at every institution, then disappearance. There's no subsequent contact, no address, no person.
7. The loss gets misclassified. Without a specific analysis, the file enters the collection process and ends up provisioned as uncollectible.

Step 4 is the one almost no control looks at, because its shape is indistinguishable from a good customer. And step 7 is the one that prevents learning from the case.

Where it shows up in an identity journey

• Account opening — this fraud's own moment. Every synthetic identity comes in through onboarding, because that is where it gets built.
• Document and watchlist checks — the file passes, because the data is consistent and there is no prior record to compare it against.
• Later behavior — the identity operates normally and builds a history, which is exactly what makes it credible to the controls that follow.

A well-run KYC check confirms that the file is consistent. A synthetic identity is designed to be exactly that.

Document validation doesn't detect it, and the reason is structural

A signup control asks whether the data is valid and whether the document is genuine. A synthetic identity is designed so that both answers come back fine: the data is consistent, the format is correct and the document, when it exists, is built on a real template.

The question no consistency check asks is whether there's a person behind that data. And that question isn't answered by looking at the file, because the file is impeccable. It's answered by comparing it against the others.

That's where the shift in approach that defines the defense against this fraud comes from. The useful check isn't "this data is valid" but "this face is already registered in this database under another identity."

Who it affects and what it costs

The damage concentrates where there's credit, and it shows up with a delay.

• Financial services and consumer credit — the central case. The loss is the credit granted, and its real cost is higher than the nominal one, because it was misprovisioned for months.
• Telecommunications and equipment in installments — line activations with device financing, which combine a physical product and credit.
• Retail with point-of-sale financing — shorter cycles and lighter controls, which make them a good first rung for step 3.
• Betting and gaming — less for the credit and more to evade per-person limits and age and identity verification requirements.
• Government — access to benefits and subsidies in the name of people who don't exist, with the aggravating factor that the reconciliation process is usually annual.

The cost that goes unaccounted for is blindness. While losses are booked as delinquency, the risk model gets recalibrated with contaminated data and the organization ends up adjusting its credit policy for a problem it doesn't have.

Which controls stop it

The defense is split between the origin, the context and the portfolio. All three stretches matter and no vendor covers all three.

At the origin, at the moment of signup.

• Biometric deduplication — comparing the applicant's face against the faces already registered in the database, to detect the same face operating under different identities. It's the control that attacks the fraud at the root, because it doesn't ask whether the data is valid but whether that person is already there. An operator of synthetic identities works at scale and reuses faces: that's where they get spotted.
• Liveness detection — forces a real face to be present at the moment of capture, which is the precondition for deduplication to have something to compare. Without it, the face can be synthetic and the comparison loses its meaning.
• Injection attack detection — identifies virtual cameras and video feed substitution. It's a control distinct from liveness detection, not a variant.
• Query to the document's issuing source — checking the number against the registry of the agency that issued it. It detects nonexistent numbers, numbers of deceased people or numbers that don't match the declared data. Its availability varies by country and by integration.

In the context, around signup.

• Checks against credit bureaus and thin files — an identity with no history isn't suspicious on its own, and a history that appears out of nowhere in an adult is. Bureaus provide this, not identity vendors.
• Link analysis between files — addresses, phones and emails shared between applicants with no apparent relationship. It's the non-biometric counterpart of deduplication and is usually solved with internal analytics or graph analysis tools.
• Device signals and signup velocity — the same device behind several identities, or a cadence of applications no person produces.
• Data sharing between institutions — consortia or shared fraud bureaus. It's the only thing that sees the pattern no single entity sees alone, and it depends on each country's market and regulatory framework, not on a product.

In the portfolio, afterward.

• Review of the delinquent portfolio with a fraud lens — reclassifying defaults that share attributes: same device, same address, same signup cohort, total absence of subsequent contact. It's analytics and process work, not a product, and it's what fixes step 7.
• Monitoring for bust-out patterns — accelerated use of the available limit shortly after an increase, across several products at once.

Bureaus, data consortia and the review of the delinquent portfolio aren't provided by an identity verification vendor, and they're half of the defense. A team that plans to cover synthetic identity only with signup controls will greatly improve its origin and will recover nothing of what's already in the portfolio.

How VU approaches it

VU works on the origin, which is where the fraud can be cut before it starts building history.

Verify applies biometric deduplication over the database of already registered identities: it checks the new applicant's face against the existing ones to detect the same person operating under different identities. It's the check that answers the question the file doesn't answer.

Liveness detection runs in the same flow, which is what ensures the compared face belongs to someone present at the moment of capture. It's certified by iBeta at Level 2 of its testing program, which applies the methodology of the ISO/IEC 30107-3 standard. It's evidence produced by an accredited third party, and its scope is presentation attacks.

Where an integration with the issuing agency exists, the document is checked against the source instead of against its image, which is what detects a number that doesn't match the declared data.

Bureaus, data sharing between institutions and the review of the delinquent portfolio still come from elsewhere.