If you have wired an IP fraud score into your app, you have probably asked the obvious question: what score should I block at? The honest answer is that a single global cutoff is the wrong mental model — and using one is quietly costing you real customers while letting the most expensive attacks slip through. The right threshold depends on which action the request is performing and which signals produced the score. This guide gives you concrete starting thresholds for login, signup, and checkout, and shows why an explainable 0-100 score beats a black-box number.
Why there is no single "block at" number
The web is no longer mostly human. As of December 2025, automated traffic overtook human traffic: human requests fell to about 47% of HTML traffic, with bots making up the rest (Cloudflare Radar 2025 Year in Review). At the same time, credential stuffing reached a median 19% of all login attempts, spiking to 44% on peak days (Verizon 2025 DBIR). That pressure is unevenly distributed across your endpoints — a login page sees credential stuffing, a checkout sees card testing — so the same score should not trigger the same action everywhere.
This is exactly how mature systems already work. Cloudflare's own bot score runs 1-99 and customers set different thresholds to block, challenge, or allow rather than relying on one hard cutoff (Cloudflare Bot scores). Your IP risk score deserves the same treatment.
What an IP fraud score actually measures
A 0-100 IP fraud score is an aggregate of underlying signals: proxy / VPN / Tor flags, the connection type (residential, datacenter, or mobile), ASN reputation, and known-abuse history. A bare number is not actionable — two requests can both score 75 for completely different reasons, and they call for different responses.
That is why explainability matters. GeoIPHub returns the explainable 0-100 risk score alongside the individual flags that produced it — proxy, VPN, Tor exit, datacenter connection type, ASN reputation, and abuse history — so you can set thresholds on the signal that actually matters instead of guessing at a black-box value. A score driven by a Tor exit node is a deliberate-anonymizer signal; a score nudged up only by a shared mobile-carrier IP is not.
The model that works: allow, challenge, block
Instead of one cutoff, map score bands to three graduated actions:
- Allow (low scores) — consistent residential or mobile consumer IP, no anonymizer flags, geo consistent. Pass with minimal friction.
- Challenge (medium band) — VPN or proxy without other red flags, minor geo mismatch. Step up with MFA, CAPTCHA, email/phone verification, or 3-D Secure rather than rejecting.
- Block or review (high scores) — deliberate anonymizers plus corroborating risk, or abuse history. Hard-block or send to manual review.
This is the approach the standards bodies endorse. OWASP states that IP blocking "should not be the sole or primary defense" because modern toolkits distribute requests across many IPs, and recommends a graduated, multi-layered response (OWASP Credential Stuffing Cheat Sheet). NIST SP 800-63B treats IP and geolocation as risk-based-authentication signals that must drive step-up, not stand alone as a basis to grant or deny access (NIST 800-63B). And the medium band is cheap insurance: OWASP cites analysis that MFA would have stopped 99.9% of account compromises.
GeoIPHub flags Tor exit nodes and anonymizers separately from ordinary VPNs, so you can hard-block deliberate anonymizers while routing everyday VPN users to a step-up challenge instead of a hard decline.
Starting thresholds by action
Use these as calibration starting points on a 0-100 scale, not gospel — then tune against your own confirmed-fraud data.
| Action | Challenge (step-up) | Block | Why |
|---|---|---|---|
| Login | 50–70 → require MFA | ≥ 70 (or ≥ 80 + Tor/abuse) | Credential-stuffing context; MFA stops almost all compromise |
| Signup | 50–65 → email/phone verify | ≥ 65 | Disposable / abuse-account focus; protect onboarding quality |
| Checkout | 45–60 → 3-D Secure | ≥ 60 | CNP fraud is costly; route borderline to liability-shifting 3-DS |
| API / read | 70–85 → rate-limit | ≥ 85 | Looser; avoid breaking legitimate integrations and shared IPs |
Combine the score with boolean logic for the clear-cut cases — for example, block if risk_score >= 90 OR known_abuse == true OR tor_exit == true, and challenge if risk_score >= 50 OR proxy == true. Checkout runs the strictest threshold on purpose: global card-not-present fraud losses are projected to hit $28.1 billion by 2026 (e-commerce fraud statistics), so letting a bad order through costs far more than a 3-DS prompt.
Why a low global cutoff costs more than the fraud it stops
The instinct to "just set the block threshold low to be safe" backfires. False positives cost online merchants more than actual fraud — false-decline losses run into the tens of billions annually, and over 40% of customers abandon their cart after a single declined payment (Incognia). A low cutoff turns your fraud tool into a revenue leak.
Three categories of legitimate traffic get punished hardest by IP-only blocking:
- VPN users. About one in four internet users runs a VPN, mostly for privacy (Security.org). Auto-blocking a VPN flag blocks paying customers.
- Carrier-grade NAT. RFC 6598 reserves
100.64.0.0/10for CGNAT, where one public IP is shared by hundreds or thousands of subscribers. Cloudflare found CGNAT IPs get rate-limited 3× more often despite a comparable bot rate (Cloudflare on CGNAT). - iCloud Private Relay. Apple's two-hop relay egress is legitimate consumer traffic and must never be scored as datacenter or proxy risk (Cloudflare on Private Relay).
GeoIPHub returns connection_type (residential, datacenter, or mobile) so you can dampen IP-only risk for mobile and CGNAT traffic and avoid blocking thousands of real users hiding behind one shared address.
Score the right IP, or every threshold is meaningless
Garbage in, garbage out: if you score a spoofed X-Forwarded-For value, your carefully tuned thresholds are instantly defeated. RFC 7239 warns that Forwarded-header values cannot be trusted to be correct because any node — including the client — can set them (RFC 7239), and MDN's rule is to only trust IPs added by a trusted reverse proxy, resolving the client IP by counting back a known number of hops (MDN: X-Forwarded-For). GeoIPHub scores whatever client IP you send it, so derive the real IP from your trusted proxy chain first.
How to tune and ship your thresholds
Start from the table, then calibrate with evidence. Because GeoIPHub exposes each contributing signal, log the score and its flags on every login, signup, and checkout decision — then move your cutoffs based on your own confirmed-fraud and chargeback data, not a vendor's default. Keep step-up as the default for the medium band; it preserves the sale or session while shifting risk. And since GeoIPHub ships as a free REST API, you can wire per-action thresholds into all three flows in an afternoon.
If you are still mapping out the broader signal set, see our guides on detecting anonymized traffic without blocking real customers, residential vs. datacenter proxy fraud detection, stopping account takeover and credential stuffing, and adding IP fraud detection with a free API. The thresholds above are a starting line — the explainable, per-signal score is what lets you move them with confidence.
Frequently Asked Questions
What is a good IP fraud score to block at?
There is no single universal cutoff. On a 0-100 scale, allow low scores, challenge with step-up verification (MFA, CAPTCHA, or 3-D Secure) in the medium band, and hard-block only high scores — commonly 90 and above, or 80+ when a deliberate-anonymizer flag like Tor exit is present. The right number depends on the action: a login can tolerate a higher block threshold than a checkout, because the cost of a fraudulent card-not-present order is far higher than a re-prompted password.
What does an IP fraud score of 75 mean?
On a 0-100 explainable scale, 75 sits in the medium-to-high band: enough risk that you should not silently allow the request, but usually not enough to hard-block without collateral damage. The right move is to challenge — require MFA at login, step up to 3-D Secure at checkout, or add email/phone verification at signup. Always read the contributing flags: a 75 driven by a Tor exit node is very different from a 75 driven only by a shared mobile-carrier IP.
Should I block VPN and proxy users automatically?
No. Roughly one in four global internet users uses a VPN, mostly for legitimate privacy and security, so an automatic hard block on any VPN or proxy flag rejects large numbers of real customers. Treat a VPN or proxy flag as a reason to add friction — a step-up challenge — not as an automatic decline. Reserve hard blocks for deliberate anonymizers such as Tor exit nodes combined with other high-risk signals.
Why use a 0-100 IP risk score instead of a simple IP blocklist?
Distributed attacks spread requests across thousands of unique IPs to keep per-IP volume low, so static blocklists and pure rate limits miss them. A continuous, explainable score lets you take graduated action and tune per endpoint, and the per-signal breakdown lets you justify and refine each decision. OWASP explicitly warns that IP blocking should not be your sole or primary defense.
Why is the block threshold lower at checkout than at login?
Card-not-present fraud is expensive and hard to recover through chargebacks — global CNP losses are projected to reach $28.1 billion by 2026 — so the cost of letting a fraudulent transaction through is high. That justifies accepting slightly more friction at checkout by setting a lower (stricter) block threshold and routing borderline orders to 3-D Secure, while a login can use a higher threshold and lean on step-up MFA.
