Fraud detection is a layered problem. There’s no single signal that catches everything, and no signal that’s reliable on its own. But IP-based signals — country, ASN, hosting-provider detection, VPN/proxy flags, velocity — are some of the cheapest, fastest signals you can collect, and they sit on the request itself before you’ve done any other work.

This post is a practical guide to using IP data in fraud detection without falling into the most common traps. We’ll cover what signals are useful, when each one matters, and the cases where IP data is actively misleading.

The Core Principle: IP Is a Signal, Not a Verdict

Before anything else: do not block users based on a single IP signal. Country mismatches, VPN detection, even “IP belongs to a hosting provider” — all of these have legitimate explanations:

A customer travels and uses your service from a different country.
A developer tests their own integration from a cloud server.
A privacy-conscious user routes everything through a VPN, including totally legitimate purchases.
A corporate VPN exits in a different country than the user lives in.

Treating IP signals as one input among many — feeding into a risk score, not into a hard block — is the difference between “fraud detection that works” and “fraud detection that drives away your best customers.”

The IP Signals That Actually Matter

1. Country Code

The simplest signal. The user’s IP resolves to a country. You compare that country to:

The billing country on file
The shipping country
The country of the card issuer (BIN check)
The country the account was created from

Mismatch = elevated risk. Multiple mismatches = much higher risk.

Caveat: travel exists. A new login from a different country isn’t fraud — it’s a vacation. The signal is “this login is unusual,” not “this is fraud.”

2. ASN and Hosting-Provider Detection

This is where IP data starts being genuinely useful. If a user’s IP belongs to a major cloud provider — AWS, GCP, DigitalOcean, Linode, Hetzner — that user is almost certainly not a human at home. They might be:

A bot scraping your site
An automation script (your own user’s CI, or someone else’s)
A user running a personal VPN on a cloud VM
A genuine cloud-deployed application calling your API

If you’re a consumer product, residential ISP ASNs (Comcast, BT, Deutsche Telekom) are normal. Cloud-provider ASNs are suspicious. You can look up an IP’s ASN in milliseconds, and our ASN directory lets you browse which ASNs belong to which providers.

The strongest single signal here: classify each ASN as residential / mobile / business / hosting and score accordingly. Hosting-class IPs hitting a consumer signup flow are a strong fraud signal.

3. VPN / Proxy / Tor Detection

VPN detection is its own discipline. A few approaches:

Known IP lists. Commercial VPN providers operate from a limited number of IP ranges. Lists are kept updated by various providers, including us.
ASN matching. Most VPN traffic exits through ASNs known to host VPN infrastructure. Cross-referencing the ASN against a list of known VPN-friendly providers is a strong signal.
TCP/IP fingerprinting. More advanced — the timing characteristics, MTU, and other low-level details of a VPN connection differ from a direct one.
Latency triangulation. If the GeoIP says “Berlin” but the round-trip latency from your server in Frankfurt is 200ms, that’s not a Berlin user.

For most apps, the first two are enough. Tor detection is similar but more reliable — Tor exit nodes are publicly listed.

4. IP Velocity

How many distinct IPs has this user logged in from in the last hour, day, week?

A single user account suddenly hitting from 50 different IPs in different countries within an hour is almost certainly compromised credentials. Track this per-user and alert on outliers.

The mirror image: how many distinct user accounts have logged in from this single IP in the last day? Multiple unrelated accounts from one IP could be a fraudster managing many accounts (or it could be a shared office IP — context matters).

5. IP Reputation

Some IPs have shown up repeatedly in fraud attempts across multiple services. Threat-intel feeds and abuse databases (Spamhaus, AbuseIPDB, etc.) provide reputation scores. Worth integrating as another input, but not as a hard block — false positives are common and reputation data ages quickly.

Building the Pipeline

A practical IP-based fraud check at the edge of your application looks something like:

on request:
    ip = request.client_ip
    geo = lookup_ip(ip)  # via your provider's API
    
    risk = 0
    
    # Country mismatch with billing country
    if user_logged_in and geo.country != user.billing_country:
        risk += 1
    
    # Hosting provider IP
    if geo.asn_type == 'hosting':
        risk += 3
    
    # Known VPN/proxy
    if geo.is_vpn or geo.is_proxy:
        risk += 2
    
    # Tor exit node
    if geo.is_tor:
        risk += 5
    
    # Velocity check
    recent_ips = user.distinct_ips_last_hour()
    if recent_ips > 10:
        risk += 3
    
    # Apply
    if risk >= 5:
        require_step_up_auth()
    elif risk >= 3:
        log_for_review()

This is illustrative, not prescriptive. The thresholds and weights depend entirely on your product. A consumer game has different tolerances than a B2B SaaS.

A few notes:

Make the lookup fast. Use an API at your edge (we run Ip2Geo’s API at the edge precisely for this) or an in-process database. Adding 200ms to every request is not acceptable for most applications.
Cache per-IP. The geo of an IP doesn’t change between two requests one second apart. A 60-second cache (per-IP) is fine.
Don’t make the user wait. Run the fraud check asynchronously where possible, or in parallel with the rest of the request.

High-Value Actions Need Higher Scrutiny

Not every request needs full fraud checking. The cost of a false positive on a homepage visit is irritating; the cost of a false positive on a checkout is a lost sale.

Apply more checks — and stricter thresholds — for:

Account signup
Password reset
Adding a payment method
High-value transactions (above a threshold)
Withdrawals / payouts
Bulk operations

Apply fewer checks (or just log) for:

Anonymous browsing
Read-only API calls
Low-value actions (likes, follows, etc.)

This “stepped” approach lets you keep the customer experience smooth for normal interactions while focusing scrutiny where it matters.

When IP Data Lies

A short list of cases where IP-based geo is unreliable or misleading:

Mobile carriers

Mobile network operators sometimes route traffic through gateways that are not where the user is. A user in Berlin on a Vodafone roaming connection might appear to come from a Vodafone gateway in Düsseldorf.

Corporate VPNs

A company headquartered in the US might have its global employees exiting through a US VPN. Those employees are not in the US.

Mobile data via CGNAT

Carriers using Carrier-Grade NAT share one public IP among thousands of users. The geo of that IP is the geo of the carrier’s gateway, not any individual user. See the CGNAT post for more on how IP addressing works under the hood.

Cloudflare / CDN egress for end users

Some products run user traffic through Cloudflare’s network (Warp, browser isolation services). The exit IP is Cloudflare’s, not the user’s.

Newly allocated IP ranges

RIRs allocate fresh blocks to providers regularly. Geo databases need time to catch up. A correctly-located IP today might appear “unknown” or wrong if you’re using a stale database. Hosted APIs tend to be much fresher than self-hosted MMDBs.

What to Build vs Buy

The “build a fraud system from scratch” approach is rarely the right call. The big fraud platforms — Sift, Forter, Stripe Radar, Fingerprint, Castle — already do most of this and aggregate signals across many merchants. Their data is broader than anything you can build alone.

But: those platforms are expensive at scale, and they’re not always available in all jurisdictions. There’s a middle path:

Use a dedicated fraud platform for high-stakes signup/checkout flows where the cost of fraud is high.
Use lightweight IP-based checks at the edge for everything else — bot detection, geo-routing, basic abuse prevention. This is where Ip2Geo and similar IP enrichment APIs come in.
Roll your own per-account velocity tracking because you have the user-account context that external platforms don’t.

The IP layer is the cheapest and most universal. Add fancier signals on top.

A Short Cheat Sheet

Country mismatch alone ≠ fraud. Combine with other signals.
Cloud-provider ASN on a consumer flow ≈ strong signal.
VPN detection is useful, but expect ~5–15% false positives.
IP velocity (one user, many IPs) is one of the most reliable signals for account takeover.
Same IP, many accounts is one of the most reliable signals for mass fraud.
Never block on a single signal. Build a score, use thresholds.
Cache lookups. Don’t pay an API call per request — pay it once per IP per minute.
High-stakes actions deserve more scrutiny. Don’t subject your whole site to your checkout’s risk policy.

If you want to try this against your own traffic, the Ip2Geo API returns country, city, ASN, ISP, and VPN/proxy detection in a single call — fast enough to run inline on every request. The free tier of 1,000 lookups/month is enough to wire up basic IP signals and see what your traffic actually looks like.

IP-Based Fraud Detection: A Developer's Guide to Signals and Scoring