Ban Evasion Detection at Signup

You've already met this fellow. You banned him last month, and he's back this morning with a new email, a new username, and the same enthusiasm for whatever earned the removal. The ban was attached to an address. He was not.

Ban evasion detection is recognizing that person at the next signup, before the new account repeats the old offense. Dregs links the registration to accounts that share devices, sessions, and behavior, and the Uniqueness score drops as soon as the link is real. The ban sticks to the person, not the email.

What Is Ban Evasion?

Ban evasion is a banned or suspended user regaining access by registering a new account instead of appealing the original decision. The replacement usually carries a fresh email and username, and it often runs from the same device, browser, and network as the account you removed. On a SaaS product, a community, or a marketplace, the way back in is your signup form. (The short version is in the ban evasion glossary entry.) What you need in practice is a way to catch the return without punishing a household that only shares a laptop.

The method requires very little of its practitioner. Our man picks up a fresh address, invents a username, opens an incognito window under the impression that this constitutes a disguise, and walks back in. Unlike duplicate accounts, which are kept alive several at a time to stack a trial or a vote, ban evasion runs in sequence, one account after another, each undoing your last enforcement decision. The tell you act on is the link back to an account you already removed.

Email bans, IP bans, and cookie checks don't survive contact with a determined returner.

The Traditional Defense Why It Often Fails
Email blocklist A fresh address costs nothing and takes seconds. Plus-addressing, aliases, and free providers mint as many as patience allows, and every one of them verifies without complaint.
IP ban Residential addresses rotate, VPNs are cheap, and a carrier or campus network is shared by people who did nothing. Block the address and you have blocked a household, or nobody at all.
Cookie or session reset Incognito mode and a cleared cache are the whole disguise, and they work against any check that lives in the browser's storage. The machine underneath is still the same machine.
Manual recognition Your trust and safety team can remember a username, but not a stranger who spent four minutes on a new one. The queue refills with the same party, wearing a different name tag.

What a Ban That Does Not Hold Costs You

A removal that the subject quietly reverses is a delay, not an enforcement action. Your team has spent the work of investigating, deciding, and following up, and the account is back before the paperwork is cold.

A moderation treadmill

Every report, review, and removal has to be done again for the same person. Your queue looks busy, but the underlying problem doesn't move.

People stop reporting

A member who was harassed, scammed, or spammed sees the same party return within a week and reasonably concludes that reporting it was pointless.

The ban teaches tradecraft

Each successful return is a free lesson in which checks you actually run. The more studious of these nuisances take notes, and the next account is a little harder to recognize by eye.

How Ban Evasion Detection Works

Detection starts by linking the new registration to identities you already have, including the one you banned, rather than inspecting the signup in isolation. Dregs does that from several angles at once, with custom rules and lists implemented as a pipeline of AI-assisted analyzers. A returner can swap out one signal. Changing device, identity relationships, and behavior all at once is considerably harder.

Uniqueness Score

When a new account uses a device you have already seen on a removed identity, the Uniqueness score for the new account drops. The fingerprint is cookieless, so it survives incognito mode, a cleared cache, and a new login. The score is the summary, and the observations underneath it let you see exactly why.

Identity Graph

The identity graph records the link: shared device, shared session, similar name or email, overlapping behavior. A second account connects to the banned one moments after the new activity arrives. Households and offices overlap for good reasons, so each link stores its evidence rather than a verdict.

Behavior When the Device Changes

After enough removals, a returner may switch browsers, pick up a VPN, or reach for an anti-detect browser, and the hardware tell gets weaker. The Behavior score still compares how the new account moves through your product with how the removed one did. Habits are harder to replace than a browser profile.

Example: A Banned User Signs Up Again

Here's how a return can look when the original account was already being tracked:

Week 1
"Jordan Hale" signs up, uses the product, and draws reports. You investigate, decide, and ban the account in your application. The identity stays in Dregs, and you don't mark it disregarded.
Week 3
A new signup arrives as "Alex Nguyen" on a different email, in an incognito window, with nothing changed but the name on the form. Dregs drops the Uniqueness score on the new identity and creates a relationship link to Jordan's account, with the shared device on the link.
Moments later
A badge you defined in your badge rules is applied, for example when Uniqueness is low and a linked identity was one you already acted on. An escalation fires to your channels. A webhook reaches your application, which can quarantine the new account before onboarding finishes: no welcome email, no access, no second lap through the same reports.

The reviewer still has the observations... the point is less manual review, not a silent ban of everyone who shares a Wi-Fi router.

Households, Shared Devices, and False Positives

A shared laptop is the honest failure mode. A parent and a teenager, two roommates, the shared machine at a front desk, a coworking space: two real customers, one browser, and a Uniqueness score that dips because the device evidence is true. Treat that dip as proof of ban evasion and you'll remove someone who did nothing. Privacy-conscious users who withhold a phone number or sit behind a VPN aren't the target either.

Read the other three scores before you act. A household pair usually keeps strong Authenticity, Humanity, and Behavior: real names, real use, two different lives on one machine. A return of a banned user is a thin new account tied to one you already removed, often with the same hours and the same path through the product. The link type matters too. A link on the same device is worth a look, while a shared IP alone, on a carrier or an office network, usually isn't.

When you have decided a device or a person is known good, mark that device or identity as disregarded. Dregs then skips that identity in scoring and excludes its devices from everyone else's cross-account analysis, and re-scores the identities that were affected. That's the right tool for your own staff, a QA fleet, or a household laptop you've already reviewed.

It's the wrong tool for the banned account. Disregarding that identity drops its devices out of the analysis, which is how a later signup stops linking back. Leave the removed account in place, and leave the disregarded flag off, so the next registration still has something to attach to. Policy stays yours: the score and the link are evidence, and your badge rules decide what happens automatically.

Responding When a New Account Links to a Banned One

Detection is half the job. The response should be graduated, because a false positive here means removing a real member. Dregs sends the scores, the link, and the badge, and your application decides what "quarantine" means.

Quarantine

On a clear link to an account you already banned, the webhook can hold the new signup: create nothing, or create it with no access. The returning account meets a closed door instead of a fresh start.

Review queue

Send borderline links to a person, with the observations attached. That's far less manual review than rereading your whole user table, and it's the right lane when a shared device might be a household.

Step-up checks

Ask for something the original ban already established you can ask for, only on the linked accounts. Legitimate members of a household can usually complete it, and a returner hoping for a free pass often won't.

Same enforcement

Apply the outcome you already chose: removal, a feature limit, a mute. You aren't inventing a new policy, just refusing to let a new email erase the old one.

These work best when they're automatic for the clear cases and quiet for the ambiguous ones. With webhooks, your application hears about the linked signup almost as soon as it lands and can quarantine, flag, or step up without waiting for the next moderation shift.

Ban evasion sits next to duplicate accounts, which is the same linking problem aimed at a benefit instead of a ban, and next to fake signups and new account fraud, when the return arrives as junk rather than as a plausible person. Uniqueness scoring is the number underneath both. Sock puppet accounts are the other reason one person needs a second name.

Frequently Asked Questions

Q: What is ban evasion?

A: Ban evasion is a banned or suspended user regaining access by registering a new account instead of appealing the original decision. The new account usually has a fresh email and username, while the person, the device, and the habits are often the same. That's why a ban that only blocks an email address doesn't hold: it has to stick to the person, not the email.

Q: How does ban evasion detection work?

A: Link the new signup to the accounts you already have, including the ones you've removed. Cookieless device fingerprints survive incognito mode and cleared cookies, and shared sessions, similar names and emails, and overlapping behavior add their own evidence. Dregs rolls that into a Uniqueness score and an identity graph, so a returning user shows up in your dashboard as a linked account rather than a stranger. Every score opens into its observations, so you can see exactly why the accounts were connected before you act.

Q: Will ban evasion detection create false positives for households?

A: It can. Families, roommates, and offices legitimately share a laptop, and a shared device is real evidence with an innocent explanation. That's why Uniqueness is a score rather than a verdict, and why a household pair usually still looks strong on Authenticity, Humanity, and Behavior. Read the observations before a hard block. You can mark known-good shared devices and trusted identities as disregarded, which removes them from cross-account analysis, but don't disregard the banned account itself if you still want future signups linked back to it.

Q: How is ban evasion different from duplicate accounts?

A: Duplicate accounts and multi-accounting are several accounts open at once, usually to multiply a trial, a vote, or a referral. Ban evasion is sequential: you remove one account, and a new one appears to undo that decision. The linking machinery overlaps, but your response doesn't. A duplicate might be merged or rate-limited, while a linked return of a banned user is a candidate for the same enforcement you already applied, once you've checked it isn't a false positive.

Q: Is this the same as game ban evasion?

A: No. Dregs works on accounts in a SaaS product, a community, or a marketplace, where the door back in is your signup form. It isn't client-side game anti-cheat, a hardware ban, or anything that runs inside a game. Dregs scores the accounts you already track.

Stop ban evasion at signup.

Dregs helps you catch a banned user returning under a new email. Install the tracking script and Uniqueness scoring links the new account to the person you already removed, so your application can quarantine it before the ban has to be done twice.

Schedule a Demo