Fraud Prevention

They fail different checks, which is why running both matters.

Identity fraud uses a real person's stolen details. The identity genuinely exists and has a full, consistent history, so history checks pass. What fails is the link between the document and the person presenting it, which is what document and biometric checks are looking for.

Synthetic fraud fabricates a person who never existed, usually by assembling real and invented fragments. Each detail may verify somewhere on its own, so field-level checks can pass. What fails is history: the combination has no past.

A control tuned only for stolen identities tends to miss synthetics entirely, because nothing about a synthetic application looks stolen.

The tell is always absence of history, not presence of an error:

• A name, date of birth and address that each verify somewhere but have never appeared together
• Contact details (phone and email) registered recently, with no earlier trace
• No address history: a current address with nothing before it
• A mismatch between the claimed and observed location

Each of these is individually weak. A genuine customer might be a recent migrant, or a young adult with a first phone number and no address history at all. It is the combination, weighed against a reference universe of more than 2 billion records, that separates a thin file from a fabricated one.

Because the identities of people who have died are a favoured source of stolen details. The person cannot notice the misuse or report it, and the credential itself is often entirely genuine.

Screening every application against a set of more than 7 million deceased records catches this at the door, where a document check on its own would pass: the licence is real, the details are real, and the rightful holder is not in a position to object.

It is a cheap check with an unusually clean signal, and it is one of the few fraud controls that almost never produces an argument about interpretation.

Indications that a returning customer is not the person who opened the account.

The two most useful are changes in contact details (a phone number or email replaced shortly before a significant transaction or a credential reset) and a mismatch between the customer's observed location and the one on file.

These feed a review, not an automatic block, and that is deliberate. Customers do genuinely change phone numbers and do travel, and blocking on either signal alone would lock out far more legitimate customers than fraudsters. The signal is there to raise the question, not to answer it.

Not for the great majority. The checks run in the background and return in seconds, so a clean application passes without the customer being aware anything happened.

Escalation is reserved for applications that flag. Only those see an additional step: a document request, a biometric check, or a manual review.

The design goal is that friction lands where the risk is, instead of being applied evenly across everyone as a precaution. Spreading it evenly is what causes drop-off among exactly the customers you want.

It routes to your review queue with the specific failed signals attached: not a bare risk score, but the reasons the application was held.

From there the reviewer can escalate to a document or biometric check, request more information from the applicant, or decline. Your policy decides what is available at each step and who can authorise it.

Accepted customers can stay under monitoring in WatchEye afterwards, which matters for synthetics in particular: they are built to behave impeccably for months before the loss is taken.

Because every control after the account opens is more expensive and less effective.

A failed onboarding check costs a review. A fraudulent account that gets opened costs write-offs, investigation time, regulatory reporting, and the customer relationship if a real person's identity was involved. Credit extended to a fabricated identity is rarely recovered at all, because there is no one to pursue.

Synthetics make the case most clearly. They build clean repayment history for months precisely so that later controls treat them as good customers, and then bust out. The application really is the last easy opportunity to catch them.

Yes. Four endpoint groups cover the screens on this page:

• Global Data Check — per-field identity matching
• Deceased Check — the stolen-identity screen
• DVS — document authenticity against the issuing authority
• Person — contact and location research

If you would rather not integrate, IDFEX ID Check runs the same document, data, deceased and consistency checks against an application from the portal, and WatchEye provides the review queue and ongoing monitoring.