Face Dedupe: How to Stop Duplicate Sign-Ups Before They Happen

Most platforms don't experience duplicate accounts as one problem. They experience a promo budget draining faster than the sign-up numbers justify, a referral program paying out to accounts that look oddly alike, a banned user back on the platform within the week, and a KYC queue rejecting what is obviously the same person for the fourth time under a new email.

Those read like four unrelated incidents. They're one: the same person enrolling more than once. Every one of them survives because the sign-up form checks what a user types, and everything a user types can be replaced. This guide covers what changes when the check moves to the face: how a 1:N dedupe search works, which fraud it closes off, and what it takes to add to an onboarding flow you already run.

One root cause, several symptoms

Duplicate enrollment isn't a single scam. It's the shared mechanic underneath a whole category of them.

• Welcome-bonus abuse: one person claims a promotion meant for one person, ten times, from ten accounts.
• Referral gaming: accounts created for no reason other than to be referred, so the referrer collects the payout.
• Multi-accounting: extra accounts stay in service long after sign-up, splitting activity across identities that each look clean in isolation.
• Ban evasion: a suspended user is back the next day under a new name, and your suspension enforced nothing.
• Credit and BNPL stacking: in fintech, one borrower opens several accounts to stack credit lines well past what a single applicant qualifies for.
• KYC evasion: a rejected applicant returns with a different email, a different phone number, and a story adjusted to whatever tripped the last check.

Treated separately, each of these gets its own rules, its own review queue, and its own analyst time, and each set of rules only ever catches the version of the trick it was written for. Treated as one problem, they share one answer: work out whether this person is already here, before the account exists.

Why deduplicating on email and phone doesn't work

The instinct is to dedupe on the fields the form already collects: email, phone number, name and date of birth, ID number. That would work if those fields were welded to a person. They aren't. A new email address takes seconds. A second phone number takes a spare SIM. Names and dates of birth are typed by the person you're screening. Even a government ID number can be borrowed, or paired with a fabricated name in a synthetic identity.

None of these are broken as contact details. They're just weak as identity keys, and a dedupe rule is only as strong as the key it runs on. Fraud teams end up tuning device fingerprints, IP heuristics, and velocity rules, all of which are proxies, and all of which someone motivated can move around.

There is one thing in the sign-up flow a user cannot swap out to dodge a check: their face.

So the shift is a simple one. Stop deduplicating on what people type. Start deduplicating on who they are.

Verification and dedupe answer different questions

Face dedupe is a close cousin of face verification, and the difference is worth being precise about, because it decides what each one can catch.

Verification is a claim check. It confirms the selfie matches the document, which is exactly what you want at onboarding, and it is entirely silent on whether the same person already holds four accounts. A verified user can be a duplicate user. If you want the mechanics of the comparison itself (embeddings, cosine similarity, thresholds, liveness), that's covered in the face verification guide.

Dedupe is an identity check. It ignores the name, the email, and the ID number attached to a face, and asks only whether that face is already on file.

How a dedupe check runs at sign-up

In practice it's one step inserted between capture and account creation:

1. Capture. The new user submits a face capture, the same selfie or short video an onboarding flow already asks for.
2. Embed. Before anything is stored, the face is converted into an embedding: a numerical vector derived from the face's geometry, not a photo.
3. Search. That embedding is compared against the full index of enrolled face templates, one query against N records.
4. Score and decide. Every comparison returns a similarity score. If the best score clears your match threshold, the sign-up is flagged or blocked as a duplicate before anything downstream fires: no welcome bonus, no referral payout, no restored access for a banned account.

The order is what matters. A duplicate caught after the bonus has been credited is a chargeback and a support ticket. A duplicate caught at step four is a non-event.

Note that the search is over your own enrollment index. It doesn't depend on which document the user holds or which country issued it, because at this point in the flow it isn't reading a document at all. Doing this at population scale is also why it needs a purpose-built face index rather than a loop over stored images: the cost of a naive scan grows with every user you add.

Where it pays for itself

• Promotions and referrals: the second sign-up from a known face is flagged immediately, so the promo budget goes to new customers rather than to one customer, repeatedly.
• Enforcement that holds: a suspension actually suspends, because a new email doesn't produce a new face.
• Multi-accounting: reward farming and referral gaming both assume accounts are cheap to create. Dedupe removes the assumption.
• Lending exposure: stacked credit lines across parallel accounts get flagged as one applicant at application time, not after the first missed payment.
• KYC integrity: an applicant can adjust every typed field between attempts and still get matched to their earlier attempt.
• Cleaner analytics: user counts, retention, and cohort numbers stop being inflated by the same people counted several times.

How Taareef fits it into your flow

Most onboarding fraud works because the system only checks the parts that are easy to fake. Taareef's face dedupe puts the check one layer deeper, at the biometric level, and it runs as a 1:N search of each new face against every face already enrolled.

It's a developer-first API, so it's an added step in the onboarding flow you already have, not a separate system to run alongside it. The same face capture you already collect for verification serves the dedupe search, and the same structured JSON shape as the rest of Taareef comes back, so the decision lands in code rather than in a review queue. You don't need a new fraud team standing by to compare photos before an account is created.

And because face capture is a live step, the check is proactive by construction. The duplicate is identified while the person is still in the flow, not reconstructed from the wreckage weeks later.

Why it matters

Field-level dedupe asks whether two records look the same. They rarely do, because whoever created the second record made sure of it. Face dedupe asks whether two people are the same, and that's the question the fraud actually turns on.

Bonus abuse, referral gaming, multi-accounting, ban evasion, credit stacking, and KYC re-tries aren't six problems to solve six times. They're one duplicate enrollment, wearing six different costumes, and a 1:N face search at the door catches all of them in the same call.