Everything you need to know about IP risk checking — what it measures, how to use it, and how to build risk-aware systems.
An IP risk checker evaluates the likelihood that traffic from a given IP address represents a threat to your service. Unlike a simple blacklist lookup — which is binary (listed or not listed) — a risk check is probabilistic. It combines dozens of signals to produce a nuanced assessment of risk that you can act on proportionally rather than with a blunt allow/block decision.
Risk checking sits at the foundation of modern fraud prevention, bot mitigation, and access security. Every time you log in to a bank, make an online purchase, or create an account on a major platform, an IP risk check is running behind the scenes in milliseconds, shaping how the service treats your request.
A comprehensive risk check evaluates signals across several dimensions:
Historical behaviour — What has this IP done in the past? Has it sent spam, participated in DDoS attacks, hosted malware, or generated abuse reports? How recently? How many distinct sources reported it?
Connection characteristics — Is this a residential IP, a mobile carrier IP, a hosting provider IP, or a corporate gateway? Is it using Tor, a commercial VPN, an open proxy, or a residential proxy service?
Geographic signals — Where does the IP geolocate? Does the geolocation match the user's stated location, billing address, or browser timezone? Is it from a high-risk country for the type of activity being attempted?
Network-level signals — What ASN is this? Does the ASN have a history of abuse? Is there a discrepancy between the IP's ASN registration and its claimed or apparent location?
Real-time threat intelligence — Is this IP currently active in known threat campaigns? Is it listed on any live threat feeds? Has it been observed in honeypot interactions in the last hour?
The fundamental advantage of a risk score over a binary blacklist is proportional response. Consider these two IPs:
Both IPs might fail a simple blacklist check for different reasons. But a risk-scored system can treat them very differently: IP A might be asked to complete a CAPTCHA; IP B might be hard-blocked from any sensitive operations. This proportional response reduces false positives (blocking legitimate users) while maintaining strong protection against confirmed threats.
Risk checking can be integrated at multiple points in a user flow:
At login — Flag or step up authentication for high-risk IPs attempting to log into existing accounts. A legitimate account owner connecting from an unusual high-risk IP is a classic account takeover signal.
At registration — Require email verification, phone verification, or CAPTCHA for high-risk IPs creating new accounts. This reduces the effectiveness of bulk account creation attacks.
At checkout — Incorporate IP risk as a factor in payment risk scoring. A medium-risk IP on a low-value order might be approved; the same IP on a high-value order might trigger additional verification.
At the API layer — Protect API endpoints from automated abuse by rate-limiting or blocking high-risk IPs before they can hammer endpoints at scale.
At content access — Enforce geo-restrictions more effectively by combining IP geolocation with risk scoring. A low-risk IP from the expected region is allowed; a high-risk IP claiming to be in an allowed region faces additional scrutiny.
While thresholds should be tuned to your specific application and risk tolerance, common starting points for IPQS fraud scores are:
These are starting points. A service with high fraud costs or handling very sensitive data should set lower thresholds. A service where false positives (blocking legitimate users) are very costly should set higher thresholds and invest more in step-up authentication rather than hard blocks.
IP risk checking is most effective as one layer in a multi-signal defence. Alone, it can be fooled by residential proxies with clean IPs or defeated by attackers with access to large pools of unblacklisted addresses. Combined with device fingerprinting, behavioural analysis, email address reputation, and velocity checks, it becomes part of a robust defence that's much harder to systematically evade.
A user arriving from a moderate-risk IP with a clean device fingerprint, a verified email address, and normal usage patterns presents very different risk than the same moderate-risk IP with a headless browser fingerprint, a freshly created email address, and bot-like request timing. The IP score is the same; the full-picture risk is completely different.
Need proxy detection, VPN detection, or abuse scoring in your own application?