How to detect synthetic identity fraud: the checks, and what each needs

To detect synthetic identity fraud you need four things in order, and only the last of them is unusual. Work out who the applicant is against everyone you have already seen. Check whether the evidence they supplied is genuine. Check whether the person presenting it is its owner. Then compare the whole application with every application before it, because a made-up identity is almost never alone. Botminds' Synthetic Identity Fraud Detection is built around that last step — six agents link each new card or loan application to the ones that preceded it, run the identity and credit checks on each name in the cluster, and hand the file to an analyst — but the first three steps are what make the fourth worth having, and most of them use data you already hold.

The sequence below follows the federal digital identity guidelines, which name the steps and the checks precisely enough to build against. Where this page adds something, it says so. The product figures and screens are the solution's sample data on a fictional issuer.

One thing to settle before any of it: the longest item on your plan is not software. It is enrolment in the government's consent-based number check, which has eligibility conditions, a certification and a 365-day agreement period attached to it. Start that first.

Why one score will not do it

Because the thing you are looking for is not an anomaly in an application. It is a relationship between applications, each of which is individually unremarkable. A synthetic identity carries a real Social Security number, a credit file a bureau will confirm, and a payment history someone built on purpose. There is nothing in it for a single-application model to object to.

The federal guidelines approach this from the other direction and arrive at the same place. They set out six expected outcomes of identity proofing: identity resolution, evidence validation, attribute validation, identity verification, identity enrolment, and fraud mitigation — and they are explicit about which one comes first and why. "Identity resolution is the starting point in the overall identity proofing process, including the initial detection of potential fraud" (NIST SP 800-63A-4, §2.3). Resolution is the question of who this is within the population you serve, which for a lender means: who else in my book is this?

The guidelines are equally explicit about the shortcut most control designs lean on. "Knowledge of an SSN is not sufficient to act as evidence of identity, nor is it considered an acceptable method of verifying possession of the Social Security card when used as evidence." A number is an attribute to resolve against, not proof of anything. At the assurance level that covers ordinary consumer accounts, the stated objectives include "limit highly scalable attacks", "protect against synthetic identity", and "protect against attacks that use compromised personal information" (NIST SP 800-63-4, Table 1) — three objectives that describe a ring rather than an applicant.

Step one: resolution, or who else is this?

Resolution means establishing that the claimed identity "corresponds to a single, unique individual within the context of the population of users served." Read as a lender, that is a question about your own book first and the outside world second, and it is the step most application controls skip entirely because it does not fit the shape of a per-application score.

In practice resolution against your own applications means comparing elements: the telephone number, the device, the address, the employer's telephone number, the funding account, the email pattern, and the authorised-user tradelines on the credit file. The Federal Reserve describes the same technique and is clear that it is not confined to one product — institutions should "break down their internal barriers to facilitate sharing of information across product lines," because a synthetic identity with a credit card "also may own a direct deposit account, line of credit, auto loan or mortgage" (Federal Reserve, July 2020).

Two design rules belong here rather than later. Elements must carry different weights, because a shared employer is weak evidence and a shared handset is strong; in the solution the weights are settings — device 30, funding account 30, telephone 20, address 15 and doubled for a mail-receiving store, employer telephone 10, email pattern 5. And some elements must carry no weight at all: surname and any protected characteristic are set to zero by design, which is a decision to make once, in writing, rather than every time somebody tunes a model.

Step two: validation, or is any of this real?

Validation is two of the six outcomes, which is worth separating because they fail differently. Evidence validation confirms that supplied evidence "is genuine, authentic, and accurate" — the driving licence is a real licence, not a template someone shared. Attribute validation confirms the accuracy of the core attributes themselves — the name, date of birth and number really do go together.

For a lender, attribute validation has one authoritative source and one statutory route to it. The consent-based service lets the Social Security Administration "verify and disclose to a PE, based on the number holder's consent, whether a number holder's submitted SSN, name, and date of birth matches the information in SSA's records," where the request "must be in connection with a credit transaction or a circumstance described in section 604 of the Fair Credit Reporting Act" (SSA, 90 FR 15030). It returns a match or a no-match, nothing more, and its price is a subscription tier rather than a per-check rate, which is why whether it runs on every application is a budget decision.

Evidence validation is where the document checks live: whether the image is of a genuine document, whether fields have been altered, whether the same template appears across several applications. The last of those is a resolution finding dressed as a validation one, and it is a good illustration of why the steps are a sequence rather than a checklist — the answer to "is this document genuine" is sometimes only visible once you have six of them side by side.

Step three: verification, or is this the right person?

Verification confirms "that the applicant is the genuine owner of the presented evidence and attributes." In a remote application that usually means a photograph of an identity document and a selfie, checked for liveness and for a match. It is the step that costs the applicant something, which is why it belongs in a band rather than on everything.

In the solution that band is a setting: scores between 500 and 699 ask for a document and a selfie instead of a hold, while 700 and above stops the application for a person to look at. The design intent is conversion as much as fraud — a control with only two outcomes will stop people it should merely have asked a question. The federal guidance points the same way from the applicant's side, expecting a documented redress route for anyone a fraud check goes against and recommending a trained human reviewer in unattended processes.

The eight checks, and the data each one needs

Six of these are named in the federal guidelines — one as a requirement, five as recommendations — and two come from the lending literature. Three of the eight need nothing you are not already collecting.

The ninth thing, which is not a check, is the government number verification in step two. It sits apart because it is the only item on the page whose start date you do not control.

What your customer identification programme already gives you, and what it does not

Every bank already runs an identity process at account opening, and it is a reasonable question why that is not enough. The programme requires, at a minimum, that you obtain before opening an account the customer's "Name", "Date of birth, for an individual", "Address" and "Identification number" — for a US person, a taxpayer identification number (31 CFR 1020.220(a)(2)(i)). It also requires procedures for verifying identity "using information obtained in accordance with paragraph (a)(2)(i) … within a reasonable time after the account is opened", and procedures for what to do when the bank "cannot form a reasonable belief that it knows the true identity of a customer."

Three gaps follow, and each is a design requirement rather than a criticism of the rule. The elements collected are precisely the four a synthetic identity is assembled to satisfy. Verification may occur after the account is opened, which for a credit card means after a limit exists. And the programme is about one customer, so nothing in it asks whether this customer resembles the last eleven.

The Red Flags Rule is the part of the framework that does ask, and its list of illustrative examples includes two that cannot be answered on one application: identifying information "associated with known fraudulent activity", where the rule's own examples are an address or telephone number already seen on a fraudulent application, and an address or telephone number "the same as or similar to the address or telephone number submitted by an unusually large number of other persons opening accounts" (16 CFR part 681, Appendix A). Which of the 26 examples a ring actually trips, and which ones need the comparison, the Red Flags guide works through one by one.

What you have to bring

Six data sets, and the awkward one is the last.

If device and contact data has not been stored historically, decide now whether you are prepared to start storing it, because that decision sets how quickly your evidence base becomes useful — and it is independent of any purchase.

The enrolment that sets your start date

The government number check has conditions attached that have nothing to do with software and cannot be accelerated by a vendor. A permitted entity means "a financial institution or service provider, subsidiary, affiliate, agent, subcontractor, or assignee of a financial institution," and such an entity "must possess an Employer Identification Number and a Data Universal Number System (DUN) and Bradstreet number." The entity must certify that it is a permitted entity, that it complies with the governing section and the applicable financial privacy requirements, and that it "will retain sufficient records to demonstrate its compliance with its certification … for a period of not less than 2 years." Payment is for a 365-day agreement period.

None of that is onerous. All of it involves other departments — legal for the certification, finance for the tier, procurement for the registration numbers — and that is why it belongs at the front of the plan rather than in the middle.

The first 90 days, and the step-up band

Start wider than you intend to finish, and in observation rather than in enforcement. For the first weeks, score every application and hold nothing on the new control alone: you are measuring the hold volume your thresholds imply before anybody's application is affected by them. The number that decides your threshold is not the catch rate; it is how many applications a day a person would have to look at.

Then set the step-up band before you set the hold line. A control with two outcomes converts every uncertainty into a stopped application, and stopped applications are the cost that turns a fraud programme into an argument with the business. In the solution the band is 500 to 699 and asks for a photograph of an identity document and a selfie; the hold line is 700. The monitor screen shows the three outcomes side by side — passed to underwriting, asked for an identity document and a selfie, or held for a person — which is the right way round to look at it.

Three outcomes, counted daily, before any threshold is enforced

Three more things belong in the first quarter. Decide what happens to an application that arrives at two in the morning, because the government service is not a round-the-clock facility. Write down the redress route, because the identity guidelines require one and because the first wrongly held applicant will arrive sooner than the first ring. And agree, before you need it, who signs a decline and who signs a closure — the four signatures a ring decision generates are not interchangeable.

Every rule on this page, as a setting with a date against it

To see the sequence running on your own applications and confirmed fraud cases, start from Synthetic Identity Fraud Detection.

Questions people ask

How do you detect synthetic identity fraud?

In four steps, in order. Resolve the applicant against everyone you have already seen, comparing device, telephone, address, employer telephone, funding account, email pattern and borrowed tradelines. Validate the attributes with the consent-based government check and the credit file's first-seen date and depth. Verify the person with a document and a selfie where the score warrants it. Then let a person decide. The federal guidelines put resolution first because it is where initial detection of potential fraud happens.

What data do you need to detect synthetic identities?

Six sets: your application stream, the consent-based government number check, credit bureau reports, device and contact data, uploaded identity documents and selfies, and your own confirmed fraud cases. Three of them you already have. The one most often missing historically is device and contact data, and its absence shows up first as a disappointing back-test rather than as a live failure.

What checks should run on every application?

The ones that cost nothing per application: the comparison against your own application history, the credit file's first-seen date and depth against the claimed age, and the mailing address check. Device fingerprinting belongs here too if the signal is captured. The checks with a per-use or subscription cost — the government number check, carrier lookups, death records — are where the every-application question becomes arithmetic rather than principle.

Do you need device data to detect synthetic identities?

Not to start, but it is the single highest-value addition. In this solution the device carries the heaviest link weight alongside the funding account, and in the sample ring it is the device that pulls the cluster together: a seventh application on one handset takes the score from 540 to 904. The federal guidelines name device fingerprinting specifically as a protection against scaled attacks and enrolment duplication.

How long does it take to get fraud detection live?

The software is not the constraint; the government enrolment is. Expect the permitted-entity confirmation, registration numbers, certification and tier selection to take weeks and to involve legal, finance and procurement, with a 365-day agreement period starting after it. Everything that depends only on your own data — the comparison across applications, the credit-file and address checks, a replay against closed files — can be built in parallel from week one.

What do you do about accounts that are already open?

Not with the government check, which validates information for new account applications; the Social Security Administration's position, as recorded by the Federal Reserve, is that existing account data cannot be validated this way because the privacy statute prohibits disclosure without prior consent. What does work on a portfolio is the comparison itself: run the links across booked accounts as well as applications, since a ring usually holds several accounts at the same institution and tends to bust out on them at about the same time.