Spotting Repeat Fraudsters (Device Fingerprinting)
- Device fingerprinting has evolved into device intelligence: hundreds of signals across hardware, browser, network, behavior, and sensor data
- Modern platforms can detect VPNs, emulators, phone farms, remote desktop tools, and anti-detect browsers
- Signals like battery state, gyroscope data, TLS fingerprints, and typing cadence reveal things transaction data alone can't
- Vendors range from consortium-scale networks (ThreatMetrix, Iovation) to deep behavioral analytics (Sardine) to fully managed decisions (Forter)
- No single signal is definitive. The power comes from cross-layer correlation: transport + device + browser + behavior
Device fingerprinting is a way of recognizing the phone or computer placing an order. A small script reads details the device gives away anyway - browser version, screen size, graphics chip, time zone, network - and builds an ID out of them. The point is that the ID sticks even when the fraudster comes back with a new name, a new email and a different card.
Your processor already does some of this. Stripe Radar and Adyen RevenueProtect both fingerprint devices. The question is whether you need more than that.
Device fingerprinting started as a unique ID for a browser. Device intelligence goes much deeper. It collects hundreds of signals across hardware, software, network and behavior. All of it answers four questions. Is this a real device? Is a real person using it? Have we seen it before? Is someone else driving it? That's the whole job.
This page is the signals, what each one reveals, and which vendors have them. Putting them into rules? See Building Fraud Rules.
How It Works
Fingerprint Types
| Type | How It Works | Persistence | Evasion Difficulty |
|---|---|---|---|
| Cookie-based | Stores a token in the browser | Low (cleared easily) | Trivial |
| Browser fingerprint | Hashes browser attributes (user agent, plugins, fonts) | Medium (changes with updates) | Moderate |
| Device fingerprint | Combines hardware signals (GPU, CPU, screen, sensors) | High (survives browser changes) | Hard |
| Probabilistic/fuzzy | Uses ML to match devices even when some attributes change | High (survives cookie clearing, incognito) | Very hard |
| Behavioral | Learns how a specific person uses a device (typing, movement) | Medium-High (builds over sessions) | Very hard to replicate |
Good vendors combine several types. They don't lean on any single fingerprint. They cross-reference every layer instead. Spoof one signal and you've created inconsistencies in the others.
Signal Categories
Platforms collect signals across seven categories. No one category decides anything on its own. You catch fraud on the inconsistencies between them.
1. Browser and App Signals
The traditional fingerprinting layer. Still useful, but easily spoofed in isolation.
| Signal | What It Reveals | Fraud Relevance |
|---|---|---|
| Canvas fingerprint | Hash of rendered 2D graphics (varies by GPU, driver, OS) | Matches known emulator/headless signatures |
| WebGL fingerprint | GPU vendor and renderer string, 3D rendering output | Google SwiftShader = software GPU (headless/emulator). VirtualBox Graphics Adapter = VM |
| Audio fingerprint | Audio processing output unique to hardware/OS stack | Absent in headless browsers, identical across emulator instances |
| Font enumeration | Installed font list | Windows device claiming Linux fonts = spoofed user agent |
| Navigator properties | Plugins, languages, hardware concurrency, device memory | navigator.webdriver === true = automation (Selenium, Puppeteer) |
| User agent | Browser and OS identification | Easily spoofed, but inconsistencies with other signals are revealing |
Multilogin, GoLogin and Dolphin Anty spoof all of these signals. Every profile looks unique, and fraud operations use them heavily. Platforms still catch them. The spoofed browser attributes don't line up with the signals that are hard to fake: TLS fingerprints, sensor data, behavior.
Want server-side IP lookups with no SDK? Geolocation, VPN detection, datacenter detection, all by API - see Data Enrichment. This section is the deeper network stuff, and it needs a client-side SDK. WebRTC leak detection, TLS fingerprinting, residential proxy detection by device correlation. You can't get those from an API.
2. True IP and Network Intelligence
The IP is the most spoofed signal in fraud. Good platforms go past the visible one and hunt for the real one.
| Technique | How It Works | What It Catches |
|---|---|---|
| WebRTC leak detection | Creates a hidden peer connection via STUN servers. UDP traffic can bypass VPN tunnels, revealing the real IP | VPN users whose real IP leaks through WebRTC |
| TLS fingerprinting (JA3/JA4) | Hashes the TLS ClientHello message (cipher suites, extensions). Each TLS client has a unique signature | User agent says "Chrome" but TLS fingerprint matches Python requests library = bot |
| ASN/datacenter detection | Maps IP to owning organization. Classifies as residential, mobile, datacenter, or hosting | Datacenter IPs are 20-50x more likely to be fraud than residential |
| Residential proxy detection | Correlates IP rotation patterns with stable device fingerprints | IP changes every request but device fingerprint stays constant = rotating residential proxy |
| Timezone vs. IP mismatch | Compares browser timezone (Intl.DateTimeFormat) with IP geolocation | IP in London, timezone set to America/Los_Angeles = VPN user who forgot to change timezone |
Several vendors sell "True IP" technology. It tries to surface the actual IP behind a VPN or proxy. ThreatMetrix pioneered it with TrueIP. Sardine sells a similar "True Piercing" set (TrueIP, TrueOS, TrueLocation). Accuracy swings by technique, and by how the VPN is configured. Don't treat it as ground truth.
IP classification matters as much as the IP itself:
| IP Type | Example Owner | Risk Level |
|---|---|---|
| Residential | Comcast, AT&T, BT | Low (expected for consumers) |
| Mobile/Cellular | T-Mobile, Vodafone | Low (expected for mobile) |
| Datacenter/Hosting | AWS, DigitalOcean, OVH | High (real consumers don't browse from datacenters) |
| Known VPN provider | NordVPN, ExpressVPN ranges | Medium-High |
| Known proxy service | Bright Data, Oxylabs | High |
| Tor exit node | Published exit node lists | Very High |
3. Device Integrity
These signals check the device itself. Has it been tampered with, or is it an emulator? Is someone driving it remotely?
| Signal | Normal Device | Fraud Indicator |
|---|---|---|
| Emulator detection | Real hardware identifiers (e.g., samsung/...) | Generic build strings (goldfish, ranchu, sdk_gphone), SwiftShader GPU, missing sensors |
| Root/jailbreak | Stock OS, normal permissions | Presence of su binary, Cydia/Magisk, SELinux permissive, writable system partition |
| Remote desktop | No remote access software active | TeamViewer, AnyDesk, Windows RDP, Zoom screen sharing detected |
| VM detection | Real GPU, normal CPU | VirtualBox/VMware graphics adapters, low CPU core count, VM-specific BIOS strings |
| Developer tools | navigator.webdriver is false | navigator.webdriver === true, empty plugins array, CDP connection active |
| Frida/instrumentation | No runtime hooks | Frida toolkit detected (commonly used to bypass security checks and manipulate API responses) |
Remote access scams are growing. A fraudster calls the victim and talks them into installing TeamViewer. Then he drives their device and makes the transaction himself. It comes off the victim's real device, on their real IP. Traditional signals look clean. Spotting active remote desktop software is one of the few ways to catch it.
4. Behavioral Biometrics
How someone uses a device is very hard to fake at scale. The newest and strongest signals live here.
Typing and keystroke dynamics:
| Signal | What It Measures | What Fraud Looks Like |
|---|---|---|
| Typing speed | Characters per second, words per minute | Perfectly uniform timing = bot/automation |
| Dwell time | How long each key is held | Zero variance = programmatic key injection |
| Flight time | Gap between releasing one key and pressing the next | Identical intervals = scripted input |
| Segmented typing | Typing in bursts with pauses (switching to reference material) | Typing name/address in fragments while looking at a stolen data sheet |
| Copy-paste in identity fields | Whether name, SSN, or address was pasted vs. typed | Legitimate users type their own name from memory. Pasting it is a strong fraud signal |
Mouse and pointer behavior:
| Signal | What It Measures | What Fraud Looks Like |
|---|---|---|
| Movement trajectories | Cursor path between targets | Perfectly straight lines = simplest bot. Geometric patterns = scripted |
| Micro-movements | Tiny jitter when cursor is "still" | Zero jitter = bot. Humans always have hand tremor |
| Click patterns | Timing, location, frequency | Uniform click intervals = automation |
| Scroll behavior | Speed, direction, pauses | Uniform scroll with no pauses = bot |
| Guided movement | Cursor controlled by someone else (latency artifacts) | Remote access tool in use |
Mobile sensor data:
| Signal | What It Measures | What Fraud Looks Like |
|---|---|---|
| Gyroscope | Device orientation and rotation | Zero readings = emulator (no physical sensors) or phone farm device sitting on a rack |
| Accelerometer | Movement and vibration | Perfectly static = not being held by a human |
| Touch pressure | Force of finger on screen | Uniform pressure = automation. No pressure data = emulator |
| Device orientation | How the phone is held | Static at ~90 degrees = propped up on a rack, not in someone's hand |
5. Battery and Power Signals
A small category, and a revealing one. You get it through the Battery Status API on web, and native SDKs on mobile.
| Signal | Normal User | Fraud Indicator |
|---|---|---|
| Always at 100%, always charging | Battery fluctuates throughout the day | Phone farm: devices permanently plugged into USB hubs |
| Battery level never changes across sessions | Varies naturally | Emulator (many report a static level like 0.50 or 1.00) |
| Inconsistent battery between "same user" sessions | Consistent within short timeframes | Account sharing or credential selling |
Battery data alone is weak, and it's only useful as corroboration. Take a device that's always charging and never moving the gyroscope. It's turned up on 50 accounts. That's almost certainly a phone farm device.
6. Phone Farm and Fraud Factory Detection
A phone farm is a rack of devices pretending to be independent users. Physical or virtual, doesn't matter. No single signal catches them, so don't go hunting for one. You catch farms on the composite profile.
| Signal | What a Farm Device Looks Like |
|---|---|
| Battery | Always at 100%, always charging (plugged into USB hubs) |
| Gyroscope/accelerometer | Zero movement (mounted on rack, not held by a human) |
| Device attributes | Same hardware fingerprint appearing across many "different" accounts |
| Factory resets | Frequent resets (every few hours/days) to create "fresh" identities |
| Device ID cycling | IMEI, Android ID, or advertising ID changes on the same hardware |
| Network patterns | Many devices sharing the same IP range or cycling through a small pool |
| Behavioral uniformity | All devices show identical interaction patterns, timing, and session flow |
| No natural idle periods | Legitimate users sleep. Farm devices may operate 24/7 |
| Physical proximity | Dozens of "independent" devices co-located in the same physical space |
7. Consortium and Reputation Data
The strongest signal here is also the simplest. Has this device committed fraud before?
Consortium networks pool device reputation across thousands of merchants. Flag a device at one merchant. Everyone else in the network sees it in real time. That's the whole value.
| What Consortium Data Tells You | Example |
|---|---|
| Device has been involved in fraud before | Device flagged for chargebacks at 3 other merchants in the past 90 days |
| Device is brand new to the network | Never seen before, no history (higher risk for new accounts) |
| Device has long trusted history | First seen 2 years ago, clean history across 12 merchants (strong trust signal) |
| Device is linked to known fraud rings | Same device cluster seen in coordinated attacks across the network |
How Signals Work Together
No single signal is definitive, so you layer them and cross-reference. It's the inconsistencies between layers that give you the strongest read.
Example: Catching an anti-detect browser
An anti-detect browser spoofs canvas fingerprint, WebGL renderer, user agent, timezone and language. But:
- The TLS fingerprint (JA3/JA4) still matches the underlying Chromium build, not the spoofed user agent
- The battery API reports a static level (emulated environment)
- Typing patterns don't match the account's historical behavior
- The IP is residential, but the ASN belongs to a known residential proxy provider
Any one of these alone might be explainable. All four together aren't.
Example: Detecting a remote access scam
The transaction comes from the victim's real device, real IP, real location. Traditional signals look clean. But:
- Remote desktop software (TeamViewer) is active
- Mouse movements show latency artifacts consistent with remote control
- The user is on an active phone call during the session
- Typing patterns show hesitation and segmented entry (victim being coached)
Vendor Landscape
Vendors vary a lot. What they collect, how big the consortium is, how they hand you a decision. The table below compares capabilities, not marketing claims.
Comparison by Capability
| Capability | Sardine | ThreatMetrix | Iovation | Kount | Sift | Forter |
|---|---|---|---|---|---|---|
| Behavioral biometrics | Deep (typing, mouse, sensors, copy-paste, active calls) | Yes (BehavioSec integration) | Limited | Limited | Basic | Yes (6,000 attributes) |
| True IP / proxy piercing | Yes (True Piercing) | Yes (TrueIP, pioneer) | Basic proxy detection | Basic proxy flag | Basic | Yes |
| Emulator detection | Yes + TrueOS | Yes | Yes | Yes (PC_REMOTE flag) | Yes | Yes |
| Remote desktop detection | Yes (92% precision, protocol-agnostic) | Limited | Limited | PC_REMOTE flag | Limited | Limited |
| Phone farm detection | Yes (sensor + behavioral composite) | Via consortium | Via device reputation | Via velocity | Via velocity | Via identity graph |
| TLS fingerprinting | Yes | Yes | Limited | Limited | Limited | Yes |
| Anti-detect browser detection | Yes | Yes | Limited | Limited | Limited | Yes |
| Consortium network scale | Growing | 1.4B identities, 110M daily decisions | 5B devices, 185M fraud reports | 17.5B devices (Equifax network) | 1T+ events/year | 1.2B identities |
| Custom rule engine | Yes (4,000+ features) | Yes (60+ assertions) | Yes (business rules) | Yes (policies + UDFs) | Yes (Workflows) | No (fully managed) |
| Credit bureau data | No | No | No | Yes (Equifax) | No | No |
| Chargeback guarantee | No | No | No | No | No | Yes |
Choosing a Vendor
The right vendor matches your biggest problem. Not the longest feature list.
| If Your Primary Problem Is... | Look At |
|---|---|
| Sophisticated fraud bypassing basic rules (anti-detect browsers, residential proxies, emulators) | Sardine, ThreatMetrix - deepest signal collection and cross-layer correlation |
| Needing device reputation at scale (has this device been seen in fraud before?) | ThreatMetrix (1.4B identities), Iovation (6B+ devices) - largest consortium networks |
| Remote access / social engineering scams | Sardine - only vendor with protocol-agnostic remote desktop detection at reported 92% precision |
| Identity verification + device signals (synthetic identity, application fraud) | Kount/Equifax - unique credit bureau integration alongside device fingerprinting |
| Multi-abuse-type detection (payment fraud + promo abuse + content abuse + ATO) | Sift - independent scores for 5 abuse types, ThreatClusters for industry-specific models |
| Not wanting to manage rules at all (fully outsourced decisions with financial guarantee) | Forter - managed decisions with 100% chargeback guarantee on approved transactions |
| Budget-conscious / just getting started | Fingerprint Pro (device ID focused, lower cost), or your processor's built-in tools (Stripe Radar, Adyen RevenueProtect) |
Pricing and Accessibility
| Vendor | Entry Price | Free Tier? | Self-Serve? | Primary Use Case |
|---|---|---|---|---|
| Fingerprint | From $99/month (100K identifications) | Yes - 20,000 identifications/month | Yes | Device identification, returning visitor recognition |
| SEON | Starter $699/month (2,500 fraud checks, 10 users, 50 rules) | No published free tier | Yes | Social profiling + email/phone enrichment + device signals |
| ThreatMetrix (LexisNexis) | Enterprise quotes only | No | No | Large enterprise device intelligence, consortium reputation |
| BioCatch | Enterprise quotes only | No | No | Behavioral biometrics for banks, social engineering detection |
| NeuroID | Enterprise quotes only | No | No | Form interaction analytics, application fraud detection |
| Iovation (TransUnion) | Enterprise quotes only | No | No | Device reputation + credit bureau integration |
| Sardine | Enterprise quotes only | No | No | Deep behavioral biometrics, True IP piercing, remote desktop detection |
One row there carries a price read off the vendor's own page. That's SEON: seon.io/pricing, verified 2026-08-02. The Fingerprint figures weren't re-checked in that pass. Confirm them on Fingerprint's own pricing page before you budget. Everything marked enterprise-quotes-only publishes nothing at all.
Budget-conscious? Two self-serve options here, Fingerprint and SEON. Only Fingerprint publishes a free tier, SEON publishes none. You start at Starter: $699/month for 2,500 fraud checks, ten users, fifty custom rules. Premium is quote-only. That's roughly 28 cents a fraud check, and it's worth writing down. SEON's the only fraud vendor on this page that publishes one at all. Use it as your yardstick when a quote-only vendor sends a proposal. And SEON isn't a pure device fingerprinting tool. It bundles a basic device hash into a lightweight fraud platform, alongside email and phone enrichment.
Enterprise? ThreatMetrix, BioCatch, NeuroID, Iovation and Sardine all want a sales call and an annual contract. None of them publishes a minimum volume. There's no threshold you can check yourself. The only way to find out if you're too small is to ask. A vendor that won't quote you has answered the question. If that happens, start with Fingerprint or your processor's built-in tools (Stripe Radar, Adyen RevenueProtect).
On Stripe Radar or Adyen RevenueProtect? You've already got basic device fingerprinting, IP intelligence and ML scoring. Standalone vendors add the deeper signals: behavioral biometrics, sensor data, True IP, consortium reputation. Processor tools don't collect those. Whether you need one comes down to your fraud sophistication and your volume. See Processor Rules Configuration for what each processor includes.
Use Cases
Fraud Detection
| Use Case | How Device Intelligence Helps |
|---|---|
| Card testing | Same device cycling through hundreds of card numbers = single fraud source |
| Multi-accounting / promo abuse | Same device fingerprint across multiple "different" accounts |
| Account takeover | New device + new location + new behavioral pattern on existing account |
| Fraud ring linkage | Cluster of devices with shared attributes, same IP ranges, same behavioral patterns |
| Application fraud | Emulator detected, copy-paste in identity fields, no sensor data |
| Remote access scams | Active remote desktop software, mouse latency artifacts, active phone call |
Account Security and Trust
| Use Case | How Device Intelligence Helps |
|---|---|
| Step-up authentication | Trigger MFA on unknown device (see 3DS) |
| Trusted device recognition | Returning device with clean history = lower friction |
| Session management | Limit active devices per account |
| Compelling evidence | Device fingerprint matching for Visa CE 3.0 chargeback representment |
Implementation Approaches
Build vs. Buy
| Approach | What You Get | What You Don't Get |
|---|---|---|
| In-house (FingerprintJS open source) | Basic device fingerprinting, full control, no data sharing | No consortium data, no behavioral biometrics, no True IP |
| Device ID vendor (Fingerprint Pro) | Stable device IDs, basic bot detection, good accuracy | Limited behavioral signals, smaller consortium |
| Full platform (Sardine, ThreatMetrix, Sift, etc.) | Deep signals, behavioral biometrics, consortium, rules engine | Higher cost, data sharing requirements, vendor dependency |
| Processor-included (Stripe Radar, Adyen) | Basic fingerprinting + ML scoring included in processing fees | Black-box scoring, limited device signal visibility, no cross-merchant reputation |
See vendor selection guide for evaluation criteria.
What to Ask a Vendor
Ask these on the vendor call, in these words:
- What signals do you collect beyond basic fingerprinting? (Behavioral biometrics, sensor data, TLS fingerprints)
- How do you handle anti-detect browsers and residential proxies? (Cross-layer correlation, not just database lookups)
- How big is your consortium, and is it relevant to my vertical? (A billion devices doesn't help if none are in your industry)
- Can I write custom rules against your signals, or are decisions fully managed?
- What's the latency? (Sub-100ms is the standard for real-time decisioning)
- How do you handle privacy compliance? (Data tokenization, consent management, GDPR readiness)
Privacy Considerations
Device fingerprinting may be subject to:
- GDPR (consent requirements, legitimate interest basis)
- CCPA (disclosure requirements)
- ePrivacy Directive
- Local regulations
Consult legal before implementation. See compliance overview for related requirements.
Best Practices
- Transparency - Disclose device fingerprinting in your privacy policy
- Purpose limitation - Use only for fraud prevention and security
- Data minimization - Collect only what's needed for fraud detection
- Retention limits - Expire device profiles (consortium retention may differ)
- Consent where required - Cookie banners, opt-in where legally necessary
- Vendor data sharing - Know what your vendor shares across its consortium, and on what terms
Next Steps
Just getting started?
- Use your processor's built-in device fingerprinting first (Stripe Radar, Adyen RevenueProtect)
- Build velocity rules using device ID as a dimension
- Review privacy requirements before adding standalone tools
Adding standalone device intelligence?
- Choose a vendor based on your primary fraud problem
- Integrate it and run shadow mode for 30 days
- Compare the new signals to your current catches and false positives
Already have device intelligence?
- Use device signals in fraud rules
- Build behavioral patterns into your review process
- Prepare device data for CE 3.0 chargeback representment
Related Topics
- Data Enrichment - Server-side IP, email, phone signals (no SDK)
- Building Fraud Rules - Using device signals in rules
- Account Takeover - ATO detection with device data
- Velocity Rules - Device-based velocity limits
- Promo Abuse - Multi-account detection
- Risk Scoring - Incorporating device signals into scores
- Behavioral Analytics - Complementary detection method
- Evidence Framework - How device data fits Tier 1/Tier 2
- Compelling Evidence - Using device data in representment
- Manual Review - When device signals trigger review
- Fraud Vendors - Full vendor landscape
- Card Testing - Bot detection patterns
- Fraud Model Feedback - How device signals improve ML
- Running Fraud Operations - Operational cadence