Detecting synthetic-identity fraud at application time

A synthetic identity is fabricated from real parts: a valid name, a date of birth, an address that exists, often a genuine tax or national ID belonging to someone who will never notice. Traditional KYC checks each field against its source, and each field passes. To catch the fraud at application time, you score the relationships between those components and the history behind them, not the components themselves.

That reframing changes what you build. Document verification and database lookups answer whether the data is valid. Synthetic-identity detection has to answer a harder question: does a single real human sit behind this application, and have they existed, coherently, for longer than the fraud ring needed them to? Most of the signal lives in that second question, and almost none of it lives in the fields on the form.

Why the pieces pass but the person doesn’t

The economics are simple. A ring cultivates a synthetic identity for months, sometimes years. It opens a small secured card, makes payments, gets reported to the bureaus, and lets a thin but clean file accumulate. By the time it applies for real credit, the identity looks like a young, low-risk customer with a short history. Then the ring bursts out: it maxes every line across several lenders in a tight window and disappears. No victim calls to dispute anything, which is why the loss reads as first-party fraud and often gets miscoded as ordinary credit loss.

The tells are structural, and you find them by looking across applications rather than inside one.

• Shared attributes across supposedly distinct people. One phone number, device, or bank account tied to many identities. One address that anchors a cluster of thin files that all opened within weeks of each other.
• History that starts too abruptly. A credit file with a hard-inquiry footprint but no pre-history: no old utility trace, no address timeline, no employment record that predates the file’s first line.
• Identifier mismatches that individually clear. A name and a national ID that verify separately but whose issuance dates, age, and address timeline do not fit together into one plausible life.
• Velocity that a real applicant does not produce. The same identity, or slight permutations of it, appearing across your funnel and across consortium data in a compressed window.

None of these is decisive alone. A real person can move house, switch phones, and carry a thin file. The model’s job is to weigh the combination against a false-positive budget, because every synthetic you flag sits next to a genuine thin-file applicant you would rather approve.

The data layer this actually needs

The model is the easy part. The hard part is assembling features that are correct at decision time and that describe an identity across your whole book, not one form. Two problems dominate.

First, entity resolution. You cannot compute how many identities share a device if you cannot decide when two rows are the same device, address, or bank account. Normalisation and fuzzy matching build the stable identity graph that sits underneath every velocity and shared-attribute feature. When that graph is weak, your best signals are noise. It is the same resolution problem that shows up across financial data feeds, pointed at applicants.

Second, point-in-time correctness. Fraud labels arrive late. An account is confirmed synthetic only after the bust-out, sometimes six months post-booking. If you train on features computed today and join them to an application from last spring, you leak future information into the past. The graph you query has to be reconstructed as it stood at the moment of that decision. Every feature in the store needs an as-of timestamp, and every training row has to read the graph at its own application time. Skip that and your offline AUC looks excellent while your production model catches nothing, because it was quietly reading tomorrow’s newspaper.

A few things we hold to when building the pipeline:

• Lineage on every feature, so an adverse decision can be explained and its audit trail reconstructed. Fraud declines still fall under fair-lending scrutiny; an adverse-action decision you cannot explain is one you cannot defend under ECOA and Regulation B.
• An honest label policy. Distinguish confirmed synthetic, confirmed first-party bust-out, and ordinary charge-off. Collapse them together and you train the model to predict credit risk instead of fraud.
• Eval sets built around the bust-out window, not a random split. A time-based split that holds out the most recent cohorts is the only test that resembles production.

Scoring at booking, and monitoring after

You end up running two models against one problem. The application-time score sits inside straight-through processing and lives under a hard latency budget; it leans on graph and velocity features that are cheap to serve, plus thin-file history signals from the bureau. Its precision target is set by how many manual reviews your team can absorb, so the threshold is a business decision as much as a statistical one.

The second model watches booked accounts for the bust-out pattern: coordinated utilisation spikes, payment behaviour that shifts in step across a cluster of shared attributes, first-payment-default clustered by device or address. This is where synthetics that cleared the front door get caught before the loss lands. It also generates the labels that make the booking model better next quarter, which is why the two have to share a feature store and a resolution layer instead of living in separate stacks.

Drift matters here more than it does for most models. Rings change tactics the moment a signal stops working, so a feature that carried weight last quarter can go flat without warning. Monitor feature distributions and per-segment precision continuously, and treat a sudden approval-rate change in any thin-file segment as something to investigate rather than a number to celebrate.