How to stop multi-accounting

What it costs you

• trending_downWhatever the extra accounts unlock: repeated free tiers, repeated referral credit, repeated first-order discounts, extra votes, extra entries.
• trending_downReferral programmes specifically, where self-referral turns your growth budget into a direct transfer to one person.
• trending_downData quality, because your user count, retention and conversion are all measuring people who do not exist.
• trending_downFairness, which sounds soft until your actual users notice and start posting about it.

How the attack runs

1. 01

   Identify what a second account is worth

   Multi-accounting is rational whenever account number two gets something account one cannot. A free tier that resets, a referral bounty, a one-per-customer discount, a rate limit, a competition entry.

2. 02

   Create separation where you are looking

   Whatever field you check, they vary. Different email, different name, different card if they have to. The separation is targeted at your known checks, which is why publishing your rules makes them cheaper to defeat.

3. 03

   Reuse everything you are not looking at

   Nobody varies what they do not have to. The same machine, the same browser profile, the same timezone, the same behavioural rhythm, the same payout destination. The reuse is where the link lives.

4. 04

   Operate the accounts in parallel

   Referral abuse in particular needs both accounts alive at once, which produces overlapping sessions and near-simultaneous actions that a single human genuinely cannot produce.

The signals that do

These are the signals that carry weight on multi-accounting, and why each one is the signal rather than the obvious alternative. Not all of them are ours: the ones marked you build this genuinely work and Kaidn does not check them, so you would be wiring them up yourself. Listing those unlabelled would read as a claim we cannot support.

Multi-accounting is the abuse most likely to make you punish a real customer, because the honest version of the situation is that you usually cannot prove it. You can establish that two accounts are strongly related. Whether one person controls both, or two flatmates share a laptop, is an inference.

Any approach that forgets this will eventually ban somebody's mother.

Different fields, same person#

The pattern is always the same. The abuser varies the identifiers they believe you are checking, and reuses everything else, because varying things is work and nobody does unnecessary work.

So the accounts have different emails, and the same payout destination. Different names, and the same device. Different cards, and the same referral origin. The link is never in the field you made unique. It is in the field you did not think to look at.

This is why single-field uniqueness rules fail in a specific and predictable way: they teach the abuser exactly which field to vary, and cost them one afternoon.

Link on relationships, weight the evidence#

The approach that holds is to stop asking "is this account a duplicate" and start asking "what is this account connected to, and how strongly".

A shared payout destination is heavy evidence. A shared device is moderate evidence and needs context. A shared IP on a mobile network is close to no evidence at all. When several land on the same cluster at once, the confidence stops being marginal.

That weighting is the entire difference between a system that finds rings and one that generates false positives. It is also why we return the checks and their weights on every verdict rather than a number: when you disagree with an outcome, you need to see which signal produced it.

What "a shared device" should actually mean#

"Same device" is the signal everyone reaches for first, and it is the one most likely to be wrong, because the thing being compared is usually a browser fingerprint and browser fingerprints collide. On our own production traffic a single iOS Safari fingerprint covers 2.30 different people. A default iPhone is genuinely identical to another default iPhone, so the hash is not lying, it is just not an identity.

The fix is to resolve that hash into something defensible before scoring it, and to carry the uncertainty along with it. We do that in three rungs:

1. A token you replayed. Your server stores the device_token we return as a first-party cookie and sends it back on the next visit. Nothing is inferred, we are reading back an id we issued. Residual risk 0.01, and it is not zero because households share browsers.
2. The fingerprint plus the network it came from. When there is no token, the identity is h(device_id, asn). We tested what actually separates two strangers holding identical phones, and it is the network: of 132 colliding fingerprints, splitting by ASN resolved them from 5.23 people per key to 1.45, while splitting by TLS fingerprint fixed one of them and timezone fixed none.
3. Neither available. You get a random id that links nothing, rather than a shared key invented out of one weak input. An honest blank is better than a confident guess.

The rung then governs how hard the device signal is allowed to hit. A replayed token carries full weight on its own. A fingerprint match only carries full weight once three or more accounts agree on the same network, because two unrelated users share an ASN roughly ten percent of the time on mobile-heavy traffic. Accounts that share a fingerprint but sit on different networks stay light, since that is more often a collision than a person. Neither path can reach a block by itself.

That is the difference between a device signal you can defend to an angry user and one you cannot. Full mechanics are in the device identity docs.

Resolving an identity, not comparing a field#

The whole argument above, in one call. What matters is not that the fields differ, it is what they resolve to:

const r = await kaidn.score({
  event: "signup",
  user_id: user.id,
  ip: req.ip,
  email: user.email,          // r.i.n.g+promo@gmail.com
  device_id: body.kaidn_device_id,
});

{
  "verdict": "review",
  "score": 58,
  "reasons": ["email_reuse", "aliased_address", "device_reuse"],
  "checks": [
    {
      "check": "emailReuse",
      "weight": 25,
      "reason": "email_reuse",
      "message": "This mailbox is behind 4 accounts",
      "evidence": { "accountCount": 4 }
    },
    {
      "check": "deviceReuse",
      "weight": 18,
      "reason": "device_reuse",
      "message": "This device is linked to 4 accounts, on different networks",
      "evidence": { "accountCount": 4, "sameAsnAccountCount": 1 }
    }
  ],
  "device": {
    "resolved_id": "d2c1f0a7b93e4d5681ca07f4e2b91d38",
    "resolution": "probabilistic",
    "resolution_rung": 2,
    "collision_risk": 0.21,
    "account_count": 4,
    "account_count_same_network": 1
  }
}

Four addresses, one mailbox. That is the finding, and it did not come from comparing strings.

Read the collision risk before you act on a device link#

This is the part most integrations skip and then regret. collision_risk is the measured probability that one resolved identity covers more than one real person, and on iOS Safari without a device token it sits at 0.21. Banning on a bare device link at that confidence bans ordinary iPhone users:

const deviceOnly = r.reasons.length === 1 && r.reasons[0] === "device_reuse";
const shaky = (r.device?.collision_risk ?? 0) > 0.15;
const corroborated = (r.device?.account_count_same_network ?? 0) > 1;

if (deviceOnly && shaky && !corroborated) return allowWithFlag(r.event_id);
if (r.verdict === "block") return deny(r.reason_text);
if (r.verdict === "review") return queueForReview(user.id, r.reasons);

Make the identity deterministic and the guessing mostly stops#

The highest-value change here is not a better fingerprint, it is not needing one. Store the opaque device_token from a previous response as a first-party cookie and replay it on the next event, and the identity is remembered rather than inferred, which takes collision risk to roughly 0.01:

// cookie handling is opt-in, because storing a first-party cookie is your
// decision to make rather than ours
const kaidn = new Kaidn({ apiKey: process.env.KAIDN_API_KEY, cookie: {} });

const r = await kaidn.scoreWithCookie(
  { event: "signup", user_id: user.id, ip: req.ip, email: user.email, device_id: body.kaidn_device_id },
  { cookies: req.headers.cookie, setCookie: (h) => res.append("Set-Cookie", h) }
);

// on the return visit: r.device.resolution === "deterministic", resolution_rung === 1

Review is the correct outcome more often than blocking#

For most services, the right response to a probable duplicate is not a ban. It is to withhold the thing that made the second account worth creating.

Do not pay the referral bounty. Do not grant the second free trial. Do not count the second entry. Leave the account able to use the product normally. If you are wrong, a real user notices nothing; if you are right, you removed the incentive without an appeals queue.

Blocking should be reserved for the clusters where the evidence is heavy and consistent, and even then a review step will pay for itself the first time it catches a family.

Something to check before you buy anything#

Take your referral programme and look for reciprocal pairs, plus accounts whose activity stopped within a day of a bounty paying out. That query takes an hour and will tell you whether you have a multi-accounting problem worth spending on, which is a better basis for a decision than any vendor demo, ours included.