Best Synthetic Identity Fraud Detection Software

Last updated: September 2026

The best synthetic identity fraud detection software is the one that still catches a seasoned identity built from valid data, keeps watching the account after it opens, explains every flag it raises and leaves your genuine thin-file customers alone. A demonstration will not show you any of that. Your own applications will, when you replay your confirmed synthetic identities, and your good customers with little credit history, through the tool before you sign.

This guide sets out eight criteria for choosing synthetic identity fraud detection software, each with the questions to ask a provider and what a weak answer looks like. It ends with a test you can run on your own applications and a table that puts the criteria side by side.

TL;DR

• Judge synthetic identity detection software on your own applications: the confirmed synthetic identities it would have caught, and the genuine thin-file customers it would have declined.

• Checking that each element is valid is only the starting point. A synthetic identity is built from valid data, so the tool has to check whether the name, Social Security number (SSN), date of birth, address, phone and email have a history together.

• An SSA eCBSV match shows that an SSN, name and date of birth belong together in the Social Security Administration's records. It does not show that the applicant is that person, and a child's real SSN matches too.

• The tool should keep scoring the account after it opens, because the synthetic identities that get through are usually found later, by investigators.

• Every flag needs a reason an investigator can work with, and every provider should be able to say how often it declines applicants who turn out to be good.

• Oscilar wrote this list. Oscilar orchestrates third-party synthetic identity, credit bureau and identity providers and decides over their results; it is not one of them. The criteria name no providers.

The short answer: how to choose synthetic identity fraud detection software

To choose synthetic identity fraud detection software, pick the tool whose signals still catch a seasoned identity with valid data, that keeps watching after the account opens, that explains each flag, and that does not punish your genuine thin-file customers. Prove each of those on your own applications rather than on a provider's examples. Replay confirmed synthetic identities and a set of good customers with little credit history through each candidate, and compare what each one would have caught and what each one would have declined.

The signals a tool reads matter more than the score it returns. A strong tool reads identity-element consistency, SSN verification, the depth and history of the credit file, device and application behaviour, and links across applications together. It then routes the result into the decision with its reasons attached.

Oscilar wrote this list. Oscilar orchestrates third-party synthetic identity, credit bureau and identity providers and makes the decision over their results, and it does not supply synthetic identity scores itself. The criteria below name no providers or products, and a later section applies the same criteria to Oscilar.

For what synthetic identity fraud is and how it develops, read synthetic identity fraud across the customer lifecycle. This guide assumes that background and goes straight to choosing the software.

What a synthetic identity tool has to catch that identity verification does not

A synthetic identity tool has to catch an identity that looks consistent on paper and passes identity verification, because it was built to pass. The Federal Reserve defines synthetic identity fraud as "the use of a combination of personally identifiable information (PII) to fabricate a person or entity in order to commit a dishonest act for personal or financial gain." Identity verification confirms that a claimed identity exists and matches its documents at one moment in time. It does not establish intent, or that the identity was not assembled specifically to pass the check.

The synthetic identities lenders see now are built from valid data and given time to age. A director of fraud at a consumer lender said that "a lot of companies, what they're picking up on right now is the synthetic fraud of today", rather than identities built the slow way years ago. A credit and fraud strategy manager at an online consumer lender described applications built from real stolen data whose fields all matched, so the checks came back clean across every bureau.

The pattern is not limited to consumer credit. A product manager at a large bank described a commercial case: "it was a completely synthetic identity that was creating this contract, but it passed all of the normal checks you would go through." A head of fraud operations at a financial services company described the cost when a loan goes to a false identity: the loan is lost "even though the PII associated with it is perfectly valid."

Nobody else reports a synthetic identity for you. The director of fraud at the consumer lender put it bluntly: "Obviously synthetic, the only victim is us." With no real person to notice an unfamiliar account and complain, the institution finds a synthetic identity itself or not at all.

Each signal fails somewhere on its own, which is why the criteria below ask how a tool reads them together.

The eight criteria, and how to use them

Before comparing tools, measure how much synthetic identity fraud you actually have, because exposure is uneven. Several lenders found little on their own books.

One consumer lender's portfolio review with synthetic identity providers found very little synthetic fraud, with identity theft the larger problem, and a subprime auto lender's look-back study also found very little. A small-business lender's data chief said they had not seen a surge, then added that maybe they were missing it. A risk lead at another consumer lender said synthetic identities had not come up much for them at all.

The size of your exposure changes what you buy. An institution that loses little to synthetic identities needs a tool that adds signal without adding friction for good applicants. An institution that loses a lot needs depth after onboarding as much as at the application.

The eight criteria follow the order in which a synthetic identity gets examined: its elements, its SSN, its credit file, its device and behaviour, its links to other applications, the account after it opens, the explanation of each flag, and the cost to genuine customers. Each criterion has the same three parts: what it is, what to ask a provider, and what a weak answer looks like. Ask every provider the same questions in writing and hold each one to its answers on your data.

1. It checks whether an identity's elements belong together

What it is: Identity-element consistency is whether the name, SSN, date of birth, address, phone and email on an application have a history together, and not only whether each one is valid. Validity is the starting point. A risk team member at a consumer installment lender described the usual first pass: "is the social security number? Valid? Is this email, valid? Is the phone number? Valid?" A synthetic identity built from valid parts passes that check element by element.

The Federal Reserve Bank of Boston recommends looking at "relationships bigger than just those few components", such as how long an email address and a phone number have existed and what they connect to. Real people build up that depth over time, and fabricated identities do not.

What to ask a provider:

• For an application from our data, which pairs of elements did you check against each other, and what history does each pair have: this address with this name, this phone with this email?

• A chief risk officer at a card-issuing bank asked for a tool that matches each element "on sources" and flags when it "says that address has never been associated with that person." Can you show that result on our applications?

• How old is each element, and does a newly created email or phone number count differently from one with years of history?

• What do you return when every element is valid but the elements have no shared history?

What a weak answer looks like: A pass or fail for each element on its own, with no view of whether the elements belong together. A tool that checks validity alone will pass a synthetic identity assembled from valid parts.

2. It uses SSN verification for what it actually proves

What it is: SSN verification checks the Social Security number against an authoritative record. The Social Security Administration's eCBSV service (electronic Consent Based SSN Verification) lets financial institutions and their service providers check, with the number holder's written consent, whether an SSN, name and date of birth match SSA records. It returns a yes or no, identifies the element that does not match, and flags a death record if there is one.

An eCBSV match shows that the SSN, name and date of birth belong together in SSA's records. It does not show that the person applying is that person. A child's real SSN, entered with the child's real name and date of birth, matches as well, and a child's number arrives with no credit history attached. A senior director of fraud at a student lender described synthetic identities built on a young child's file and then used to open credit cards, bank accounts and car loans.

What to ask a provider:

• Where does SSN verification sit in the flow, and how is the applicant's consent collected before the check runs? A consumer installment lender's risk and technology team described the flow they wanted: when a decision needs an eCBSV check, the flow asks the applicant for the consent it requires, then runs the check when the consent comes back.

• What does the tool do when an SSN matches but the credit file behind it started recently for an applicant whose date of birth says they are an adult?

• How is an SSN mismatch or a death record combined with the other signals, instead of being treated as the whole answer?

What a weak answer looks like: An eCBSV match presented as proof that the applicant is real. A match confirms that three elements agree in SSA's records, and says nothing about who entered them.

3. It reads the credit file's depth and history, and knows a washed file

What it is: Credit-file signals describe how long an identity has been on file with the credit bureaus, how many trades it has, and where its first trade line came from. A director of fraud at a consumer lender listed the basics: "we're looking at the credit file, how long has it been in file? How many different trades do they have?" The same director noticed that many synthetic files had been started in the same place: "A lot of them are using the same bank to set up that credit profile." That pattern shows up only across many applications.

Seasoning defeats the simplest version of this check. The director described fraudsters who wait years before using an identity, building up its profile, so that when it finally applies it looks legitimate because it has been on file for a long time.

A clean file can be clean because it was scrubbed. The same director described reviewing a file where "all these trades look good. Everything's paid. But then I started looking at the accounts. They're all closed. And I was like, I bet there's credit washing". As the director explained, "when there's credit washing, you can't see what was previously there."

A no-hit result is ambiguous. A senior director of fraud risk management at a payments company pointed out that when the bureau returns nothing, the applicant may be a genuine thin-file customer, young or new to the country, or someone who entered a real-looking made-up name and date of birth. The credit file cannot tell those apart, so the tool has to use other signals.

What to ask a provider:

• Which credit-file attributes do you use: time on file, number and type of trades, the source of the first trade line, recent inquiries?

• Can you recognise a file where most trades are paid and closed, and treat it as a question rather than a clean result?

• What happens to a no-hit applicant: a decline, a step-up check, or a hand-off to other signals?

• Can you see patterns across applications, such as many new files started on the same first trade line?

What a weak answer looks like: File age and trade count read as a score, with a clean file treated as a good one and a no-hit declined by default.

4. It uses device and application behaviour

What it is: Device and application behaviour is how the application was filled in and on what device: typing and pasting, pace, automation tools, and whether the same device has been seen before. Behaviour catches what data cannot, because a synthetic identity's data can be flawless while the way it is entered is not. In one deposit account opening workflow, the checks for bot-driven synthetic identities look at whether the applicant is using automation software, or barely typed while presenting a high synthetic identity score.

Attacks change pace. A credit and fraud strategy manager at an online consumer lender described one that first behaved like a person, completing the application flow at a human pace. Once restrictions went on, it switched to hitting the lender's APIs directly at machine volume to get around checks such as one-time passcodes. A tool that reads only the application form would have missed the second half of that attack.

What to ask a provider:

• Which device and behavioural signals do you collect during the application, and do you see traffic that goes straight to our APIs and skips the form?

• How do behavioural signals combine with the synthetic identity score, for example a high score on an application that was barely typed?

• Do you recognise the same device across applications, and across our web and mobile flows?

What a weak answer looks like: Device and behaviour sold as a separate product whose result never reaches the synthetic identity decision.

Synthetic identities built with deepfake selfies and documents need a further test, of the document and selfie checks that sit before this criterion, and that test is covered in a separate guide to choosing deepfake detection tools.

5. It links applications across your book

What it is: Linkage connects applications that share something: a phone, an email, a device, an address, a bank account or a face. Velocity checks count how often those shared elements appear within a period. Both are only as good as the keys they link on, and fraudsters test which keys you use. A chief credit officer at an online consumer lender described an attack that worked because of one such assumption: "They exploited the fact that they had assumed that we would do velocity checks on a combination of checking account and routing number."

Some signals exist only across applications. A senior director of fraud analytics at a consumer lender described repeat offenders in store and online: "Even we'll see same picture on different driver's licenses, and things like that." A product manager at a large bank wanted to know whether an identity had started to "open an unusual number of accounts across fis", meaning across financial institutions, and whether there were "significant changes in address and other PII" over time.

What to ask a provider:

• Which elements do you link on, and can we add our own linking keys without an engineering release?

• Can you link on a face or a document image, and not only on text fields?

• Do you see applications made at other institutions, or only ours, and what does that data cover?

• How do you show a ring: the linked applications, what they share, and when each one appeared?

What a weak answer looks like: Fixed velocity rules on a few fields, with no way to see or change which keys they use.

6. It keeps watching after the account opens

What it is: A synthetic identity that passes onboarding is usually found later, by investigators. Speaking about synthetic identity checks, a fraud team lead at a card-issuing bank said: "when stuff does get through, you know, that's one thing my team finds more often than not." Detection software should therefore keep scoring the account as it seasons, and not stop at the application.

The signals change after the account opens. The director of fraud at the consumer lender watched "the amount of inquiries that occurred within a short period of time. So that's telling me that it's a synthetic bust out." A director of risk and compliance at a payments company described machine learning that could "proactively flag bust out or synthetic id situations where there were commonalities" across accounts, and identify a situation "before became a bust out." On the business side, a VP of operations at a financial services company described fabricated business identities that sat dormant for months under policies that let them linger, then busted out, because nothing was in place to catch them.

An onboarding flag has to reach monitoring. A risk leader at a payments company said a synthetic identity is sometimes flagged during onboarding and still missed across silos afterwards. The usual reason is that the onboarding signal rarely reaches the transaction monitoring or compliance team.

The economics of a bust-out, and how it overlaps with first-party fraud, are covered in first-party fraud and bust-out signals. This criterion covers only what a tool must see before the bust-out happens.

What to ask a provider:

• Do you score accounts after they open, on which events, and how often?

• Can an onboarding flag or score follow the account into monitoring and change what happens to it later?

• Which signals do you watch before a bust-out: bursts of credit inquiries, patterns shared across accounts, dormant accounts that suddenly become active?

• Can you look back over accounts we opened and show which later bust-outs you would have flagged, and at what point?

What a weak answer looks like: Detection that ends at the approval decision, or a monitoring product that never sees the onboarding result.

7. It explains each flag and routes it

What it is: Explanation is the reason attached to a flag: which signals fired, what the tool linked the application to, and why the result crossed a threshold. A score with no reason cannot be worked by an investigator or defended to an examiner. An alert that says only that something looked anomalous is not actionable, and the context attached to it is what makes it actionable: the linked device, the related accounts and the identity's history. The operational test is whether the reason reaches the person handling the case, with reason codes and attributes visible in the queue.

Routing decides whether that reason is used. A VP of payment operations at a payments fintech preferred separate tools: "So when you think about synthetic fraud, id fraud device, I would actually want a solution for each." Separate tools can work, as long as the synthetic identity result, the identity verification result and the device result reach one decision and one case. Three queues that each see a third of the picture will miss what only the combination shows.

What to ask a provider:

• Show a flagged application from our data: which signals fired, what it was linked to, and what an investigator sees.

• Are reason codes returned with every score, in a form we can store with the decision?

• Where does the result go: straight into our decision, into a case, or into a separate portal?

• Can our team set what happens at each level of risk, such as approve, step up or send to review?

What a weak answer looks like: A bare score with no reasons, delivered to a separate portal that neither the decision nor the investigators ever see.

8. It tells you what it gets wrong on genuine customers

What it is: False positives are the genuine applicants a tool flags or declines. In synthetic identity detection they fall hardest on people with little credit history, such as young applicants and people new to the country. Their files look thin for the same reason a synthetic identity's file looks thin, so a tool that treats a thin file as suspicious declines good customers along with bad ones. Ask each provider what the tool does with those applicants and how often it declines one who turns out to be good.

Treat the answer as part of provider due diligence. For US banks, the June 2023 Interagency Guidance on Third-Party Relationships: Risk Management is in force and was proposed for replacement on 11 September 2026. As at 29 September 2026 the replacement is a proposal, and it emphasises tailoring third-party risk management to each relationship's assessed risk. Under either text, a provider that cannot show how it treats your genuine applicants leaves you little to base that oversight on.

What to ask a provider:

• Of our genuine thin-file customers, which would you have flagged or declined, and what would have cleared them?

• Which other signals do you use for an applicant with no credit file?

• Do you report false positives by segment, such as age or time on file, and can we see that on our own applications after go-live?

• How do we adjust the tool's result for a segment we know performs well?

What a weak answer looks like: A detection rate with no false-positive rate beside it, or a false-positive figure measured on another institution's customers.

How to test synthetic identity detection on your own applications

Test synthetic identity detection software on your own applications, because a provider's examples show what the tool can do and not what it will do for you. A senior director of fraud risk management at a payments company described the gap: "it's always nice when you go to a vendor website and you see all these pretty things that they could do. And then you test them and you're like, well, what do they actually do?" Six steps make the test repeatable.

1. Size your exposure. Count how many of your losses were synthetic identities, and in which products, before you set a budget. Several lenders who did this found less synthetic fraud than they expected.

2. Assemble two sets. The first is confirmed synthetic identities from past losses and investigations. The second is genuine customers with thin files who turned out to be good. Judge every candidate on both sets.

3. Replay both sets through each candidate, side by side. An AML officer at an asset manager described a trial environment where the team could "pass through some of our old data and compare it to the pass rates that we had with older tools." One consumer lender scored applications with its current provider and a challenger at the same time, and tested a newer version of the incumbent's score, before choosing.

4. Where there is no history, run the candidate live on a slice. A signal you have never used has no past results to backtest. The senior director of fraud risk management noted that in this case "it can't be a back study", and planned to "plug in and just evaluate from, you know, like abc test perspective." Run the candidate on a share of live applications alongside your current process.

5. Look back for later bust-outs. Take the accounts opened over the past year, find those that later busted out or were charged off as synthetic identities, and ask each candidate which it would have flagged at opening or while the account seasoned.

6. Check the explanation on a handful of flags. Give an investigator several flagged applications from the test and ask whether the reasons were enough to work each case.

Agree in writing, before the test starts, what data leaves your institution and how each candidate's results will be compared.

Where Oscilar fits, judged on the same criteria

Oscilar wrote this guide, so this section applies its criteria to Oscilar, using only what Oscilar's published pages state. Oscilar does not supply synthetic identity scores itself. It orchestrates third-party synthetic identity, credit bureau and identity verification providers, together with an institution's own data, and makes the decision over their results. On criteria 1 to 3, what Oscilar can check therefore depends on the providers an institution connects.

On device and behaviour and on links across applications (criteria 4 and 5), Oscilar's account opening fraud detection uses device intelligence, behavioural biometrics and data enrichments, and analyses cross-account linkages to uncover fraud rings. It includes pre-built rules and machine learning models for scenarios including application fraud. Oscilar's platform combines an ensemble of supervised machine learning, unsupervised anomaly detection and rules, and covers onboarding, credit, fraud and AML in one place, which is where criterion 6 asks an onboarding flag to follow the account.

On explanation and routing (criterion 7), Oscilar's case management prioritises queues and gives a natural language explanation of why each case was created. Oscilar keeps a full audit trail per decision with stored reasoning, and human-in-the-loop by design. Oscilar's platform is specified for decisions in under 100 milliseconds.

On genuine customers and on testing (criterion 8 and the test above), Oscilar supports backtests on historical data and A/B tests before a change goes live, and monitoring of false positives, approval rates and custom KPIs afterwards. Oscilar's auto model monitoring covers data drift, feature drift and concept drift, with outcome KPIs measured by segment.

Oscilar was named to Chartis's 2026 FCC50, its ranking of financial crime and compliance technology vendors, with category wins for Low-Code/No-Code Customization and Agentic AI Innovation. Oscilar is also a Nacha Preferred Partner for Account Validation, Fraud Monitoring, and Risk and Fraud Prevention. Neither recognition ranks synthetic identity detection tools, and neither replaces testing Oscilar on your own applications as you would any other provider.

This guide covers the detection layer. Choosing the onboarding software a detection tool plugs into is a separate decision, covered in a guide to onboarding software for banks.

The eight criteria at a glance

The table pairs each criterion with the question that tests it, the answer that should give you pause, and the part of the test that proves it.

Use the second column as the script for every provider conversation and the last column to plan the test.

Frequently asked questions

What is the difference between a synthetic identity check and identity verification?

Identity verification confirms that a claimed identity exists and matches its documents or records at one moment. A synthetic identity check asks whether the identity was fabricated: whether its elements have a history together, whether its credit file has genuine depth, and whether the application behaves like a real person. A synthetic identity built from valid data can pass identity verification and still fail a synthetic identity check.

Does an SSA eCBSV match stop synthetic identities?

An SSA eCBSV match does not stop synthetic identities on its own. A match, made with the applicant's consent, shows that an SSN, name and date of birth belong together in the Social Security Administration's records. It does not show that the applicant is that person, and a child's real SSN used with the child's real name and date of birth also matches. Use eCBSV as one signal alongside element history, credit-file depth and behaviour.

How should detection software treat a genuine thin-file applicant?

Detection software should treat a thin file as missing information and not as evidence of fraud. A no-hit at the credit bureau looks the same for a young applicant, someone new to the country and a made-up identity. The tool should turn to other signals, such as element history, device and behaviour, or a step-up check, before it declines anyone.

Can software flag a synthetic identity months after the account opened?

Software can flag a synthetic identity months after the account opened, if it keeps scoring the account after onboarding. Bursts of credit inquiries, dormant accounts that become active and patterns shared across accounts can all appear before a bust-out. That only works when the onboarding result follows the account into monitoring.

How many past applications do you need to test a synthetic identity tool?

No fixed number applies. You need enough confirmed synthetic identities to see a difference between candidates, and a set of genuine customers, including thin-file ones, to measure false positives. An institution with few confirmed cases can add a look-back at accounts that later busted out, or run the candidate live on a slice of applications.

How does Oscilar measure up against these criteria?

Oscilar does not supply synthetic identity scores itself. It orchestrates third-party synthetic identity, credit bureau and identity providers, adds device intelligence, behavioural biometrics and cross-account linkage, and makes the decision over the results, with a full audit trail per decision with stored reasoning, and human-in-the-loop by design. Because Oscilar wrote this guide, test it on your own applications as you would any other provider.

The best synthetic identity fraud detection software for your institution is the one that performs on your own applications. It catches the confirmed synthetic identities in your history, keeps watching accounts after they open, explains its flags and leaves your genuine thin-file customers alone. Oscilar's approach to account opening fraud is one option to put through that test alongside any other provider you are considering.