Banned-User Re-Registration: Detecting Ban Evasion on Marketplaces

A user you banned for fraud is back on your platform in under an hour, listing the same scam under a new name. Email blocklists never stop this, because the only thing that actually changed was the address in the signup form.

Ban evasion is the quiet tax on every trust-and-safety team. You do the hard work of investigating, deciding, and enforcing, and the offender simply re-registers. Closing that loop requires linking the new account back to the device and environment behind the ban.

Why traditional ban lists leak

Most enforcement is built on identifiers the user controls and can replace for free:

• Email and phone. Disposable inboxes and virtual numbers make these throwaway. A blocklist here filters noise, not intent.
• Account ID or username. Meaningless the moment a new one is minted.
• Raw IP address. A residential connection rotates, and a proxy swaps countries on demand. Blocking an IP blocks whoever inherits it next, not the banned user.

The pattern is the same in each case: you banned an account, but the human and the machine behind it walked away untouched.

Signals that survive a new signup

Effective ban enforcement anchors to properties that are expensive to change, not cheap to fake. A cloud device-intelligence platform like Prynt produces a stable visitorId from hundreds of browser and hardware attributes, so the same laptop returns the same identifier across a brand-new account, a cleared cookie jar, and a private window.

Layered on top, server-side Smart Signals raise the confidence that a fresh registration is an evasion attempt:

• Incognito / private mode, a common reflex when someone is trying to look new.
• VM and emulator flags, since ban evaders often spin up throwaway environments.
• Tampering and antidetect-browser detection, catching tools sold specifically to defeat fingerprinting.
• Datacenter and proxy IP reputation, flagging the infrastructure that evaders lean on.

No single attribute is proof. Together they let you say, with a confidence score, that this “new” seller is the account you removed last Tuesday.

Wiring ban checks into your flows

Ban evasion is best caught at the two moments the user commits to an identity: registration and reactivation of dormant privileges.

1. At signup, collect the visitorId before you create the account. Query your ban table by visitorId, not just by email, and hold or step up any match.
2. At first high-risk action — listing an item, requesting a payout, messaging a buyer — re-check. Evaders sometimes register clean and only reveal the device later when they switch machines mid-session.
3. On appeal, use the linkage as evidence. A legitimate user wrongly flagged rarely shares a device with three previously banned fraud accounts.

Because Prynt runs in the cloud with server-side signals, you can enforce these checks from your backend where the user cannot inspect or bypass them. If you are also fighting coordinated signup rings, our guide to signup fraud protection covers the honeypot and timing layer that complements device linkage.

Handling the edge cases fairly

Device linkage is powerful, which means it needs guardrails so you do not punish innocents:

• Shared devices. Family computers, libraries, and office machines genuinely serve many people. Treat a device match as a strong signal, not an automatic ban, and weigh it with behavior.
• Confidence, not certainty. Use the confidence score to route: high-confidence matches to auto-hold, medium to manual review, low to monitor. This keeps false positives out of your enforcement queue.
• Explainability. Keep the specific signals that drove a decision so your appeals team can explain it and reverse it when warranted.

It also helps to weight the timing. Re-registrations that happen minutes or hours after an enforcement action carry far more suspicion than a device that reappears months later, when it may genuinely have changed hands. Feeding the interval between ban and return into your score keeps the fast, obvious evaders in your queue while giving benign device reuse the benefit of the doubt.

A ban evader is fighting to look like a stranger. Your job is to remember the machine, not the name it typed this time.

Ban evasion will never drop to zero, but it can stop being free. When every re-registration is checked against the device behind your past enforcement, offenders have to buy new hardware and defeat multiple signals just to try again — and most give up first.

See how stable a visitorId stays across cleared cookies and private windows in the live playground, or compare tiers on the pricing page when you are ready to enforce bans that actually hold.