Synthetic Identity Fraud Detection With ML and Data Linkage
Finding Customers Who Were Never Real in the First Place
Most fraud detection assumes there is a victim whose identity was misused and a genuine person whose behaviour you can compare against. Synthetic identity fraud removes both assumptions. There is no victim to report the account, no legitimate behavioural history to deviate from, and frequently no real person at all, just a carefully cultivated file that has behaved impeccably for two years.
That is why the losses usually sit in credit rather than in fraud. The account pays on time, builds limits, then draws everything and disappears, and the case is written off as a charge-off with nobody to pursue. Synthetic identity fraud detection is therefore less about scoring an application and more about finding relationships between identities that should have none.
What makes synthetic identity fraud different from impersonation?
There is no real victim, so nothing gets reported and the account looks like a good customer for a long time.
In impersonation, a real person eventually notices and disputes. In a synthetic case, the identity is fabricated from a mixture of real and invented attributes, often a genuine identifier paired with an invented name and date of birth, and then deliberately cultivated with small credit products and consistent repayment. Nobody complains, so the only detection opportunity is one your systems create for themselves.
Why does it pass onboarding checks?
Because every attribute is individually valid, and attribute-level checks cannot see the combination.
Identity proofing is designed to resolve a claimed identity to a unique individual, validate the evidence, confirm that individual exists in the real world, and verify that the applicant is that individual. NIST's guidelines set out that structure along with identity assurance levels and a scale of evidence strength from unacceptable to superior. Synthetic identities are built specifically to satisfy those checks attribute by attribute: the identifier exists, the address is real, the documents may be genuine. What fails is the fourth outcome, verifying the association between the applicant and the identity, and that is exactly the part hardest to automate remotely. Raising evidence requirements helps at the margin, and it also raises friction for genuine customers, which is why detection cannot rest on proofing alone. The onboarding architecture that captures this evidence properly is covered in this guide to digital onboarding and KYC automation.
Why is the loss recorded in the wrong place?
Because a bust-out looks identical to a credit deterioration unless you connect the accounts involved.
If your institution charges off an account with no linkage analysis, the case enters credit loss statistics and the pattern is invisible. Institutions that start linking discover clusters: fifteen charge-offs across three products sharing devices, phone number stems, or funding accounts. That reclassification is often the first business case for the programme, because it moves a known cost from an unexplained bucket into a preventable one. Ask for a retrospective linkage analysis of last year's charge-offs before asking for budget.
Would your institution recognise a cluster of related charge-offs as one fraud case?
Which detection signals actually work?
Relationship anomalies first, then file and behavioural patterns, then bust-out precursors.
| Signal group | Examples | Strength |
|---|---|---|
| Shared attributes across identities | Same device, contact stem, address history, funding account, employer across unrelated identities | Very high |
| Application velocity in a cluster | Several applications from linked attributes within a short window | High |
| File characteristics | Thin or recently created credit presence, unusual identifier-to-age relationship, sparse history depth | Medium to high |
| Behavioural cultivation | Small balances, perfect repayment, no organic life events, low product engagement | Medium |
| Bust-out precursors | Simultaneous limit-seeking across products, utilisation stepping up together, contact detail changes | High |
| Contact reachability | Unreachable by phone, mail returns, no digital footprint consistent with claimed history | Medium |
Why is data linkage the core technique?
Because a synthetic identity is unremarkable alone and obviously anomalous in relationship.
The whole method rests on that asymmetry. One identity sharing a device with another proves little. Twelve identities sharing three devices, two funding accounts, and a phone number pattern is not a coincidence, and no per-application score will ever see it. That is why graph representation matters, and why network approaches keep outperforming rules here. The BIS Innovation Hub's Project Aurora, reported in May 2023, found that privacy-enhancing technologies combined with network analysis across institutions detected potentially up to three times more complex schemes while reducing false positives by up to eighty percent compared with siloed, rules-based approaches. The reasoning and tooling behind that graph view is set out in this guide to using graph databases to uncover fraud networks.
Which relationships belong in the graph?
Devices, contact details, addresses, funding instruments, employers, and application metadata.
Build edges from attributes a fraudster must reuse: devices and their identifiers, phone numbers and email patterns, addresses including historical ones, bank accounts used for funding or repayment, claimed employers, and application session metadata such as IP ranges and submission timing. Weight edges by discriminating power, since a shared corporate email domain means almost nothing while a shared device means a great deal. Then compute cluster-level features such as size, density, growth rate, and the share of members already in default, because those cluster features are what the model should consume rather than raw edges.
How should entity resolution be built?
As a scored relationship graph kept deliberately separate from your customer master record.
Entity resolution for risk and entity resolution for customer mastering are different problems with different error costs, and conflating them causes real harm. Use deterministic rules for high-confidence identity matching in the master record, and use probabilistic scored linkage for the risk graph. A probabilistic link should never silently merge two real customers, because the consequences of a wrong merge, from misdirected statements to incorrect credit decisions, land on genuine people. The mastering side of this problem, including how duplicates arise in the first place, is covered in solving duplicate customer records.
How do you prevent wrongly implicating real customers?
By requiring corroboration, keeping thresholds high for action, and retaining the specific evidence.
Households share addresses, families share devices, and small businesses share contact details, so a single shared attribute must never trigger action. Require multiple independent links plus at least one behavioural or file signal before a case is raised, keep the action threshold materially higher than the investigation threshold, and always store the exact evidence behind a score so a reviewer can see which links fired. Then track false positive outcomes by link type, since that is how you learn which attributes are noisy in your population rather than in a vendor's benchmark.
How should machine learning be applied?
On graph and cluster features, with realistic handling of scarce and delayed labels.
The modelling problem here is unusual not because the algorithms are exotic but because the supervision is poor. Design around that rather than pretending otherwise.
What labels do you actually have?
Very few confirmed cases, arriving months late, so start with weak labels and improve them.
Confirmed synthetic identity cases are rare and confirmation is slow, which rules out naive supervised learning at the start. Most programmes begin with weak labels: first-payment default combined with linkage anomalies, charge-offs within a cluster, or accounts unreachable at default. Treat those as proxies with known bias, be explicit about that bias in model documentation, and build a case management process that generates clean labels going forward, because in two years your label quality determines your model quality. That labelling and retraining discipline is the core of what this guide to MLOps for regulated workloads describes.
Which model families fit the problem?
Gradient-boosted models on engineered graph features first, graph neural networks once the data supports them.
Engineered cluster features fed to a well-tuned gradient-boosted model are usually the right starting point: they train on modest label volumes, they are explainable, and they capture most of the available signal. Graph neural networks earn their place at larger scale and where relationship structure carries information that hand-engineered features miss, which is where Project Aurora's network approach showed its advantage. Sequence them in that order rather than starting with the more sophisticated option, because a model nobody can explain and nobody can label properly will not survive its first credit committee review.
How do you handle explainability and customer impact?
By preserving linkage evidence and treating any credit-affecting decision as one you must justify.
Declining an application or restricting a limit on the basis of a synthetic identity score affects a real person if the score is wrong, and it must be explainable in terms a regulator and a customer accept. Keep reason codes tied to specific evidence, never to a raw score, and review adverse outcomes as a standing process rather than on complaint. The governance framework for that sits in this guide to model governance and explainability, and the same principles apply whether the model sits in underwriting or in fraud.
Can you show which specific links produced a synthetic identity score?
Where in the lifecycle should detection run?
At onboarding, through early tenure, at every limit increase, and continuously for bust-out precursors.
| Lifecycle point | What to look for | Action available |
|---|---|---|
| Application | Cluster membership, velocity, file thinness | Decline, step up proofing, approve with lower limit |
| First 90 days | Behaviour inconsistent with claimed profile, unreachability | Restrict, verify, monitor |
| Limit increase request | Cluster growth, coordinated limit-seeking | Hold, require verification |
| Ongoing tenure | New links appearing to known clusters | Re-score, adjust limits |
| Pre-bust-out window | Utilisation stepping up across products, contact changes | Freeze limits, block cash access |
| Default | Retrospective linkage for reclassification | Recovery decisions, label generation |
The pre-bust-out window is where the money is saved. A cultivated identity is worth very little to a fraudster until it can draw everything at once, so detecting coordinated utilisation increases across a cluster in the weeks beforehand prevents the loss rather than merely explaining it afterwards. That means the graph must be scored continuously, not only at application, which is the single most common gap in existing programmes.
What governance does this require?
Clear lawful basis for linkage, retention limits, access control, and defined handling of adverse outcomes.
Linking identities across products and channels means processing personal data for a purpose the customer did not directly request, so establish the lawful basis and document it before building. Keep the graph access-controlled and audited, since it is one of the most sensitive datasets in the bank. Set retention limits per attribute rather than keeping everything indefinitely. And define the process for a customer who disputes a decision, including how a link is reviewed and removed. Multi-jurisdiction operations add another layer, as set out in this guide to data privacy compliance across jurisdictions.
How do you measure success when labels are scarce?
Through cluster-level outcomes, reclassified losses, prevented exposure, and precision on reviewed cases.
Report clusters identified and their eventual performance, which is a stronger measure than per-application accuracy. Track charge-offs reclassified from credit loss to fraud, since that quantifies the problem you were previously not measuring. Measure exposure prevented, meaning limits withheld or frozen on accounts that later showed bust-out behaviour elsewhere in the cluster. Watch precision on cases sent to review, because analyst time is your constraint. And track time from cluster formation to detection, since that interval is the fraudster's cultivation window and shortening it is the clearest sign the programme is maturing.
How should delivery be phased?
Linkage first, then retrospective analysis, then scoring at application, then continuous cluster monitoring.
Build the linkage graph before any model, because everything depends on it and it delivers value immediately through investigation support. Run a retrospective analysis of past charge-offs next, which produces both the business case and your first labels. Then score at application using cluster features, with actions limited to step-up verification and lower initial limits rather than outright decline while precision is unproven. Then move to continuous cluster monitoring with bust-out detection, which is where losses are actually prevented. Cross-institution sharing comes last and multiplies the value of everything before it, for the reasons set out in federated fraud intelligence sharing, and the behavioural side of the same problem connects to authorised push payment fraud prevention where mule accounts are frequently synthetic.
Synthetic identity fraud is the clearest example in banking of a problem invisible to per-transaction and per-application controls. It only becomes visible when you look at relationships, which means the investment is in data linkage and graph engineering rather than in another scoring model bolted onto the application flow.
Frequently Asked Questions
What is a synthetic identity?
A fabricated identity built from a mix of real and invented attributes, often a genuine identifier paired with an invented name and date of birth, cultivated until it looks like an ordinary customer.
Why does synthetic identity fraud pass onboarding checks?
Because each attribute is individually verifiable. The identifier exists, the address is real, and the documents may be genuine, so checks that validate attributes separately find nothing wrong.
Why is it usually recorded as credit loss rather than fraud?
Because the account performs normally, then defaults with no one to pursue. Without linkage analysis the case looks like an ordinary charge-off, which is why the problem is systematically understated.
Why is data linkage the core detection technique?
Because a synthetic identity is normal in isolation and anomalous in relationship. Shared devices, contact details, addresses, and funding sources across supposedly unrelated identities are the strongest signal.
What labels can you actually train on?
Very few confirmed cases, arriving late. Most programmes start with weak labels such as first-payment default combined with linkage anomalies, then improve labels as confirmed cases accumulate.
What is a bust-out?
The moment a cultivated synthetic identity maximises every available credit line and disappears. Detection value is highest in the weeks before it, when utilisation and behaviour shift together.
How do you avoid wrongly merging real customers?
Keep linkage separate from customer mastering. Use a scored relationship graph for risk decisions and never let a probabilistic link silently merge two real customer records.
Does this need explainability?
Yes. Any decision affecting credit access must be explainable in terms a customer and a regulator accept, so preserve the specific linkage evidence behind every score.
