TL;DR: fake account detection
- Email verification and CAPTCHA confirm an endpoint, not a person. A fraudster opening 200 accounts by hand passes every check in isolation because no single check sees the pattern across sessions.
- The detection layer that works is device fingerprinting at registration. One device behind many sign-ups is the constant signal, regardless of how many emails, IPs, or browser profiles the fraudster rotates through.
- Disposable email blocklists are a losing race. New domains appear faster than lists update. The only durable control looks at the device, not the inbox.
Fake account detection is the practice of catching fraudulent registrations at signup, before an account is used for bonus abuse, multi-accounting, or as a mule in a fraud chain. Email verification and CAPTCHA are not enough on their own, because both confirm an endpoint rather than the person behind it.
The control that actually works ties many registrations back to one physical device, no matter how many email addresses or IP addresses the operator rotates through.
Why Email Verification and CAPTCHA Fail
Email verification and CAPTCHA both confirm an endpoint, not a person. Neither can detect a fraudster who has already created hundreds of accounts, because each new registration passes both checks in isolation with no link to earlier sessions.
Email verification only tells you that an inbox exists and is reachable by whoever is registering. It does not tell you who that person is, whether this is their first account, or whether the inbox was spun up three minutes ago from a disposable email service. Temporary email providers generate syntactically valid addresses in seconds, pass standard format validation, and receive the confirmation message. The verification step completes, the account is created, and the operator moves to the next one.
CAPTCHA confirms that a human solved a challenge at the moment of registration. It says nothing about whether that human is a genuine new user or a fraudster who has already opened 200 accounts by hand. CAPTCHA was built to block bots. It has no mechanism to catch multi-accounting by human operators working across hundreds of sessions.
How Disposable Email Domains Defeat Email Verification
Disposable email providers generate syntactically valid addresses on demand, defeating verification checks that rely on format validation or known-bad-domain blocklists. New disposable domains spawn faster than blocklists update, making list-based detection a losing race. Durable detection requires device fingerprinting and behavioral signals that catch the account creation pattern regardless of which email provider the fraudster uses.
The scale is easy to underestimate. Services like Guerrilla Mail, Mailinator, and hundreds of similar providers spin up addresses instantly, receive confirmation links, then disappear. Blocklist vendors publish updates weekly at best. A fraudster using a disposable domain that appeared in the last 24 hours bypasses every blocklist in circulation. The verification step completes. The account is created. The blocklist update that would have caught it publishes after the bonus is already claimed.
The only durable control is one that does not look at the email address at all. Device fingerprinting identifies the device behind the signup, not the inbox it used to register. For a full explanation of the signals involved, see what is device intelligence.
The Multi-Registration Pattern
A device fingerprint exposes the pattern that email verification and CAPTCHA cannot see. The underlying device is the constant. The email address, the IP address, the browser profile, and the registration timestamp all vary. The device does not.
When a fraudster creates 100 fake accounts, they use 100 different email addresses, 100 different IP addresses drawn from a residential proxy network, and vary registration times to avoid velocity triggers. Each individual registration looks legitimate in isolation. No single signal crosses a threshold.
The device fingerprint ties all 100 registrations together. Canvas rendering output, WebGL behavior, and font list entropy stay consistent across the sessions even when every other variable is different. The pattern becomes visible at the device layer when it is invisible at every other layer. One device creating many accounts is a strong fraud signal that no other registration data can produce.
The Fraud Ecosystem That Fake Accounts Feed
$13.5 billion in US account takeover losses in 2025, up 18% year over year. Source: Javelin Strategy & Research, 2026 Identity Fraud Study
| Year | US account takeover losses |
|---|---|
| 2024 (estimated) | ~$11.4B |
| 2025 | $13.5B |
Javelin Strategy & Research reports $13.5 billion in US account takeover losses in 2025, affecting 6 million victims, an 18% rise year over year. The Verizon Data Breach Investigations Report 2026 found stolen credentials appear in 39% of all data breaches, and fake accounts are the infrastructure that monetises many of those credentials. They receive transferred value, relay stolen funds, and accumulate points or credits before being cashed out.
A fake account is rarely the end goal. It is the entry point into a multi-stage fraud chain, and blocking fake accounts at signup disrupts that chain at its cheapest point.
Catching Anti-Detect Browsers
Sophisticated operators use anti-detect browsers, tools that spoof browser fingerprints by overriding canvas output, WebGL parameters, and other signals so each session looks like it comes from a different device. They are built specifically to defeat fingerprinting.
cside analyzes more than 250 signals per session, including canvas entropy patterns, WebGL rendering output, font list entropy, and TLS handshake fingerprint TLS fingerprinting. The combination of these signals is not something most anti-detect browser configurations can patch cleanly.
Canvas entropy is particularly resistant to spoofing at scale. A convincing fake canvas fingerprint needs either consistent hardware-level manipulation or careful coordination of many rendering parameters at once. Anti-detect browsers that override canvas output tend to produce characteristic entropy distributions that differ from genuine browser populations, and that mismatch is one of the signals cside's anti-detect layer keys off.
TLS handshake fingerprint TLS fingerprinting operates at the network layer, below the browser's own APIs. Anti-detect tools that focus on JavaScript-accessible APIs do not alter the TLS handshake signatures that TLS handshake fingerprint captures.
cside Signup Shield: Detection at Registration
cside Signup Shield builds a passive device fingerprint at the point of registration. The registrant sees no extra step or challenge; the fingerprint comes from the browser environment during the signup session itself.
cside returns that fingerprint to your system as a device ID, a risk score, and a real-time verdict that flags multi-account and anti-detect-browser sessions. Your rules engine consumes it in real time and applies whatever your policy calls for: block, challenge, shadow-flag, or pass.
Multi-registration detection works retrospectively as well as live. If a device that has created three accounts in the past 30 days comes back to create a fourth, the multi-account signal fires at registration, before the account exists in your system.
cside runs as cookieless device fingerprinting. The usual legal basis is legitimate interest under UK GDPR and EU GDPR, applied to fraud prevention, and cookieless fingerprinting for that purpose does not typically require a consent prompt. Your legal team should still review your specific implementation against your privacy policy.
Further Reading
- Signup Shield - block fake and AI-driven account creation at registration
- New account fraud: types and detection - the full taxonomy of fraud at account creation
- Account takeover fraud detection - catch fraudulent activity after signup
- Fraud detection API: how it works and what to look for - browser-layer signals returned per session
- Multi-accounting - stop one operator running many accounts
