How to stop new-account fraud at signup

New-account fraud, in the sense this guide means, is one person creating accounts at signup to do something a real new customer would not: re-claim a free trial or a welcome offer again and again, or slip back in after a ban under a fresh name. The accounts are not stolen identities and there is no credit application behind them; they are real-looking registrations that are simply not the new people they claim to be. You stop it not by checking the email or showing a CAPTCHA, both of which read one signup in isolation, but by reading the device and network behind the registration and scoring how new the person really is before the account exists. A wave of "new" registrations often traces back to the same handful of devices, and the email never gives it away.

The scale is not small: Stripe's 2025 analysis of first-party fraud found that 7.4 percent of signups at AI companies were tied to suspected multi-account abuse. This guide covers the abuse-and-evasion kind of new-account fraud, the fake account creation behind trial farming and ban evasion, why the usual signup checks miss it, and how to score a registration at the moment it happens.

Key takeaways

• This guide is about the abuse-and-evasion kind of new-account fraud: fake signups created to farm offers or evade a ban, not the stolen-identity, bank-account kind, which is identity verification and KYC territory.
• Email verification and CAPTCHA check a single signup on its own and have no memory of who registered before, so a device on its tenth account passes both.
• The two motivations are one mechanic: abuse re-claims trials and bonuses, evasion brings a banned user back, and both produce many accounts from one device.
• The advantage is at the registration itself. Scoring a signup before the account is created is the cheapest place to act, and it does not require an identity document.
• Detection produces evidence, not a verdict. Your signup handler reads the score and the named signals and decides what a risky registration gets.

What is new-account fraud here, and what is it not?

"New-account fraud" covers two very different problems that share a name. This guide is about the one a product team owns, what most teams call fake account creation: real-looking registrations minted to abuse an offer or slip past a ban, not to steal an identity. It is worth being explicit about the one it is not.

It is not identity theft or KYC fraud

The version that dominates the headlines is a financial-identity problem: someone uses a stolen or synthetic identity, often a real Social Security number stitched to fabricated details, to open a bank account or a line of credit in another person's name. That is identity-theft and synthetic-identity fraud, and it is handled by identity verification, document checks, and credit-bureau signals, the regulated KYC stack. The 2026 Javelin Identity Fraud Study put traditional identity-fraud losses at $27.3 billion in 2025, affecting 18 million victims, which is the headline number this device-layer guide is deliberately not about. If the risk you are managing is a stolen identity opening a credit account, the controls are document verification and KYC, and this guide covers the device read for the abuse-and-evasion kind instead.

It is not multi-accounting yet

The version a product team faces is quieter: a real-looking account created at signup that is simply not a new person. No identity is stolen; the registration just is not what it claims. That makes it the upstream half of multi-accounting.

Multi-accounting is read as linkage after several accounts exist, tying them back to one user. New-account fraud is read at the single registration, the moment it is created, before there is a second account to link it to. Same device layer, earlier point. This guide is about that earlier point: scoring the signup itself.

Why do email checks and CAPTCHA miss it?

The two controls most signup flows already have, email verification and a CAPTCHA, both fail for the same structural reason: each one judges a single registration in isolation and has no memory of who signed up before.

A CAPTCHA asks "is this a human?" A disposable inbox and a confirmation click answer yes every time, because the person is human; they are just not a new one. Email verification asks "does this inbox exist?" A throwaway address or a name+1@, name+2@ variation always does. Neither check can answer the question that actually matters at signup, which is "have I seen the person behind this registration before," because neither one remembers the last registration. They validate the signup in front of them and forget it.

A device identifier closes exactly that gap. It carries memory across registrations: the same device returning under a fresh email and a new IP is the link those resets were meant to break. Detecting fabricated accounts at scale is a well-studied problem that USENIX NSDI research approached from the social graph; the device-layer version of that idea leans on the traits that are expensive to change instead. One entity forging many identities is the Sybil attack, formalized in John Douceur's 2002 IPTPS paper, that this line of work addresses.

The two motivations: abuse and evasion

Strip away the vocabulary and fake signups come from two motivations, and both leave the same trace. Naming them keeps the detection question simple.

• Abuse is creating accounts to claim something meant for new customers more than once: a free trial cycled under fresh emails, a welcome bonus or first-order discount farmed across registrations. Free-trial abuse prevention carries the depth of this case, where the same signup-scoring read stops a trial farm.
• Evasion is creating an account to undo a consequence: a banned user signing up again under a new name to get back in. Making a ban follow the person, the subject of ban evasion, rests on the same device read.

The motivations differ, the signal does not. Whether the goal is a free month or a way back past a ban, the person has to produce a registration that looks new while sitting on a device that is not. That repeated device is the one thing neither goal can cheaply hide, which is why one read at signup covers both.

What do fake signups cost you?

A fake signup is cheap to create and expensive to live with, and the cost rarely shows up as a single line item. It lands in three places at once:

• Acquisition metrics that lie. Every fabricated registration inflates new-user counts and lowers cost-per-acquisition, so a channel that is partly a farm reads as your best-performing one, and the budget follows it.
• Infrastructure and support spent on no one. Free-tier compute, storage, seats, and onboarding email go to accounts that were never going to convert, and a support queue fills with tickets from identities that do not exist.
• A staging ground for worse. A pile of fake accounts is raw material. The same registrations get pointed at the offer abuse, spam, fake reviews, and scraping that follow, and they feed the multi-accounting that a single signup-time check cannot see on its own.

None of these is dramatic on day one, which is why fake account creation runs unnoticed until the cumulative total surfaces in the margin, the metrics, or an abuse report.

What signals flag a fake signup?

A fake signup gives itself away through what the person cannot reissue for every account. The email is disposable, the IP is rentable, the cookie clears in a click, but the device behind the registration and the network it rides stay the same from one account to the next. Reliable detection ignores any single flag and asks how many independent signals land on the same registrant. The ones that move the needle most, and the risk each carries:

What you can read at signup	Why it points to a fake account	Risk it carries
The same device behind several recent signups	one person registering many times, not many people	High
An anti-detect browser or a spoofed device profile	a profile rebuilt to look unique per registration	High
A VPN, anonymous proxy, or datacenter connection	network cover routed under each signup	High
The same network footprint behind many "new" registrations	a farm working from one place	Medium-High
A burst of signups minutes apart from one footprint	automation, not organic growth	Medium-High
A device tied to an account you already closed or banned	a banned user returning under a fresh name	Medium-High
A registration region that disagrees with the network origin	a masked origin, or one place reused	Medium-High
A disposable or plus-addressed email on a device already seen	a throwaway identity on familiar hardware	Medium

No single row is proof. A real new user can sign up over a VPN, and two genuine people can register from one household network. The read is correlation: a registration that lights up several rows at once, especially a device already seen behind other signups, is the one worth holding. Swapping the email or rotating the IP changes none of the device traits underneath, which is why the device, not the address, is the anchor that holds.

How do you score a registration before the account exists?

The advantage at signup is timing. You do not have to clean up a fake account after it farms a trial or evades a ban; you can read the registration and decide before the account is created. With ShieldLabs, a JavaScript snippet identifies the visitor on the signup page, and your server reads the score for that session when the registration is submitted. A scored signup carries the visitor, the device behind them, a score, and the named signals that moved it:

{
  "event_type": "identification.scored",
  "schema_version": "2026-06-01",
  "created_at": "2026-06-11T11:30:00Z",
  "data": {
    "request_id": "7a2e9c41-3b8d-4f60-a157-9e0c4d2b6f38",
    "visitor_id": "c1f4b9a6-2d73-4e85-b0a9-6f8c1e3d5a72",
    "device_id": "8d3a6e29-5c41-4b97-ae20-3f9b7c0d4e61",
    "connection_type": "proxy",
    "risk_score": 85,
    "detection_flags": { "anti_detect_browser": true, "datacenter_ip": true },
    "observed_at": "2026-06-11T11:30:00Z"
  }
}

The score is one number from 0 to 100, and the signals name what is behind it rather than hiding it in a black box. A registration like the one above, a high score on a session running an anti-detect browser over a datacenter connection, is the kind your signup handler holds before creating the account. A clean registration goes through normally. The device_id is the part that carries memory: the same identifier reappearing behind a "new" signup is the link a fresh email was supposed to break.

We implemented exactly this read on signup flows and watched what the device_id surfaced that the email never did: the same identifier returning behind a run of "fresh" registrations. The share is not trivial. In 2025, Stripe reported that 7.4 percent of signups at AI companies were tied to suspected multi-account abuse, and it is precisely that repeat-device population a scored signup surfaces before the account exists.

Score, do not block: your signup handler decides

What makes this safe to run at the front door is that detection and action stay separate. ShieldLabs returns a risk score and the named signals. You read the score and decide, by your own rules, what a registration gets: let a clean new user in, hold a high-risk one for review, or step a borderline one up to email or phone verification.

Because the policy lives in your application rather than a sealed verdict engine, you set the threshold, change it as you learn, and can always say why a signup was held. That separation is what lets a genuine new customer register untouched while a farm or a returning banned user gets caught.

Which industries new-account fraud hits hardest

In the abuse-and-evasion sense, fake signups follow whatever a fresh account unlocks, so the platforms hit hardest are the ones that hand a new account something for free:

• SaaS and AI tools. Free tiers and trials invite farming a new account per cycle, and Stripe found 7.4 percent of signups at AI companies tied to suspected multi-account abuse.
• iGaming and betting. Signup bonuses and free bets make mass fake registration, and returning after a ban, worth the effort.
• Marketplaces and social. Fake sellers, spam accounts, and bot profiles all start as a signup, so catching them at registration saves the downstream cleanup.
• Crypto and Web3. Airdrops and reward programs make fabricated accounts and wallets worth minting in bulk, the Sybil pattern.
• Streaming and subscriptions. A fresh account resets a free trial or a promotional rate, so one person cycles many.

The reward differs by vertical, but the fake signup leaves the same device trail whatever it is chasing, which is what a signup-time read anchors on.

Preventing new-account fraud with ShieldLabs

ShieldLabs runs on your signup or registration page through one JavaScript snippet, and it risk-scores every visitor on the first visit, so you have a read on the person behind a registration before the account is created. At the center is persistent identification that ties a "fresh" signup back to a device already seen, even after the person switches email, clears cookies, and rotates IP. It does its work in the background, with no friction for a real new user and no identity document required.

We ran a burst of signups from one device under fresh emails and a rotated IP, and the persistent device identifier tied every attempt back to the same device even after the cookies were cleared. The registration form saw new-looking users; the device read saw one.

Around that identifier, each visit returns a risk score from 0 to 100 with the anonymity signals behind it: an anti-detect browser, a VPN or anonymous proxy, a datacenter connection, and others. Across registrations, the pre-built patterns surface which accounts trace back to one device, so a signup farm reads as a trend in the dashboard rather than a pile of separate registrations. You read the score through the API and webhooks and decide, by your own rules, what a risky signup gets, whether that means letting a clean user in, holding a high-risk one for review, or stepping a borderline one up to verification. The same identity layer carries into multi-accounting prevention once the accounts exist, and into new account fraud prevention as a managed solution.

Sources

1. Wikipedia: Disposable email address
2. Cao, Sirivianos, Yang, Pregueiro: Aiding the Detection of Fake Accounts in Large Scale Social Online Services (USENIX NSDI, 2012)
3. Douceur, John R.: The Sybil Attack (IPTPS, 2002)
4. Stripe: Analyzing first-party fraud trends: account, free-trial and refund abuse (2025)
5. Javelin Strategy & Research: 2026 Identity Fraud Study: The Illusion of Progress