Geolocation Fraud Detection: How Location Data Catches Bad Transactions
March 23, 2026
Email validation catches disposable addresses. Card checks catch mismatched CVCs. But some of the most costly fraud slips past both because the email is real and the card details are correct — they're just being used from the wrong side of the world.
That's where geolocation comes in. By checking where a transaction originates and comparing it to where it should originate, you add a detection layer that's hard for fraudsters to fake.
What Geolocation Fraud Detection Actually Does
Every device connected to the internet has an IP address, and every IP address maps to a physical location. You can see this in action with a free IP lookup tool. When a customer makes a purchase, their IP reveals:
- Country and city — Where the request is coming from.
- ISP/carrier — Whether they're on a residential connection, mobile network, data centre, or known proxy service.
- Connection type — VPN, proxy, Tor exit node, or direct connection.
Fraud detection compares this location data against other transaction signals:
- Does the IP country match the billing address country?
- Does the IP country match the card-issuing country?
- Is the connection coming through a VPN or proxy?
- Is the ISP a residential provider or a hosting company?
A customer in London paying with a UK-issued Visa from a British Telecom residential IP is low risk. The same card details used from a data centre IP in a different country, routed through a VPN, is a different story.
The Signals That Matter
Not all geolocation mismatches are equal. Here's how to weight them.
Country Mismatch (High Signal)
When the IP country doesn't match the billing or card-issuing country, it's one of the strongest fraud indicators available. Legitimate reasons exist — business travel, expats, students abroad — but statistically, country mismatches correlate heavily with fraud.
What to do: Don't auto-block, but elevate the risk score significantly. If country mismatch appears alongside other flags (disposable email, new account, high-value purchase), that combination should trigger a review or block.
VPN/Proxy Detection (Medium-High Signal)
VPNs are widely used for legitimate purposes — corporate networks, privacy, accessing region-locked content. But in the context of a financial transaction, a VPN adds uncertainty. You can no longer trust the location data, which means one of your verification signals goes dark.
What to do: Treat VPN usage as a risk multiplier. On its own, it's not enough to block. Combined with other signals, it tips the scale.
curl -X POST https://api.fidro.io/v1/validate \
-H "Authorization: Bearer sk_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"email": "buyer@example.com",
"ip": "203.0.113.42",
"country_code": "US"
}'
Fidro's response includes VPN detection, proxy detection, and whether the IP country matches the provided billing country — all in one call.
Tor Exit Nodes (High Signal)
Tor routes traffic through multiple relays to anonymise the user. Unlike VPNs, there are very few legitimate commercial reasons to make a purchase through Tor. The anonymity it provides is specifically designed to prevent identification.
What to do: Block or require additional verification for Tor-originating transactions in almost all cases. The false positive rate is extremely low for e-commerce.
Data Centre IPs (Medium Signal)
Most consumers browse from residential or mobile connections. Traffic from data centre IPs (AWS, Google Cloud, DigitalOcean) often indicates automated scripts, bots, or proxies rather than real customers.
What to do: Flag for review. Some legitimate traffic comes from corporate VPNs that route through cloud providers, so don't hard-block. But it's a meaningful signal in combination with others.
Impossible Travel (High Signal)
If the same account makes a purchase from London and then another from Tokyo 30 minutes later, something is wrong. Either the account is compromised, or multiple people are sharing credentials.
What to do: Flag accounts that show purchases from geographically distant locations in unrealistic timeframes. This catches account takeover fraud that other checks miss.
How Fraudsters Try to Beat Geolocation
Understanding the evasion tactics helps you defend against them.
Residential Proxies
The most sophisticated fraudsters use residential proxy networks that route traffic through real consumer IP addresses. This makes their traffic look like it's coming from a normal home connection in the target country.
Defence: Residential proxies are harder to detect by IP alone, but they still leave traces. The IP might be in the right country but the wrong city. The connection might show characteristics of a proxy (latency patterns, header anomalies). And critically, the other fraud signals still apply — a disposable email is a disposable email regardless of what proxy is used.
Geolocation Spoofing
Browser-based geolocation (the "allow this site to know your location" prompt) can be spoofed easily. Never rely on browser-reported location for fraud detection.
Defence: Always use IP-based geolocation. It's server-side, not client-side, and can't be spoofed by the user's browser.
Mobile Hotspots and Carrier NAT
Mobile carriers sometimes share IP addresses across many users through Carrier-Grade NAT. This can make geolocation less precise and occasionally show the wrong city.
Defence: Focus on country-level matching rather than city-level for mobile connections. The country is reliable even when the city isn't.
Building a Geolocation Check into Your Flow
The most effective approach layers geolocation with other signals rather than using it in isolation.
At Signup
Check the IP when the user creates an account. Store the signup country so you have a baseline for future transactions.
At Payment
Compare the payment IP against:
- The signup IP country
- The billing address country
- The card-issuing country (available from Stripe's charge object)
If all three match the current IP, risk is low. Each mismatch increases the score.
At Login (Account Takeover Prevention)
After a purchase, monitor login IPs. A sudden change from the UK to Russia isn't necessarily fraud — but it's worth flagging, especially if followed by a shipping address change or large purchase.
What Not to Block
Geolocation is powerful but produces false positives if you're too aggressive.
Don't block:
- All VPN traffic — too many legitimate users
- All foreign transactions — you might have international customers
- Mismatched cities within the same country — IP city-level data isn't precise enough
- Mobile carrier IPs — they often geolocate to the carrier's headquarters, not the user
Do block or review:
- Tor exit nodes for purchases
- Country mismatches combined with other risk signals
- Data centre IPs making consumer purchases
- Impossible travel patterns
Measuring Impact
After adding geolocation checks, track:
| Metric | What to watch |
|---|---|
| Fraud-related chargebacks | Should decrease within 30-60 days |
| False positive rate | Monitor legitimate customers getting blocked |
| Review queue volume | Should be manageable — if too high, loosen thresholds |
| Transaction approval rate | Shouldn't drop significantly |
The goal is to catch more fraud without rejecting more legitimate customers. If your approval rate drops significantly after adding geolocation checks, your thresholds are too tight.
Getting Started
Fidro's API includes full geolocation analysis in every validation request. Pass an IP address and get back:
- Country, city, and region
- ISP and connection type
- VPN, proxy, and Tor detection
- Country match against billing address
No separate geolocation API needed. It's part of the same risk score you're already getting for email validation.
- Sign up for a free API key — 200 validations per month
- Add the
ipparameter to your existing validation calls - Include
country_codeto enable automatic billing country matching - Review flagged transactions for 2 weeks to calibrate your thresholds
- Tighten or loosen rules based on your false positive rate
Want to see what geolocation data an IP reveals before integrating? Try the free IP checker.