How to read a Predax score

The score is a confidence measure, not a guilt measure

risk_score runs 0–100 and answers one question: how much evidence is there that this address is not an ordinary residential connection? It does not estimate the probability that a person is committing fraud. Those are different questions, and conflating them is the most common way teams end up blocking paying customers.

A corporate VPN, a privacy-conscious shopper and a card tester can all produce a similar score. What separates them is context you have and we do not: what they are trying to do, whether the account is established, whether the shipping address matches. Use the score as one input into that decision.

The flags are not synonyms

These get used interchangeably in this industry and they should not be. Each answers a different question, and treating them as one bucket is how "block anonymised traffic" turns into "block anyone on office wifi".

is_tor

Traffic from a Tor exit relay. The most reliable flag we publish, because exit relays are required to announce themselves publicly — this is a matter of record, not inference.

is_vpn

A commercial VPN service. Tractable, because these operate at known scale and advertise their own endpoints. Note that VPN use is overwhelmingly ordinary privacy behaviour, not fraud.

is_datacenter / is_hosting / is_cloud

The address belongs to server infrastructure rather than a consumer ISP. Highly reliable as a statement about routing. It is not a statement about intent — monitoring tools, link previewers and corporate egress all live here.

is_proxy

An open or commercial proxy. Reliability varies sharply by type — see the limitations below, because this is the flag most likely to be wrong in both directions.

is_crawler / is_web_crawler

A bot identifying as a crawler. Verified search engines are confirmed by forward-confirmed reverse DNS, not by trusting the user agent string, which anyone can set to anything.

is_private_relay / is_warp

Apple iCloud Private Relay and Cloudflare WARP. Called out separately on purpose: these are consumer privacy features shipped on by default to millions of ordinary people. Treating them as anonymisation threats blocks a large population of perfectly good customers.

is_residential / is_mobile

A consumer ISP or mobile carrier. Usually reassuring — but see residential proxies below, which is precisely the case where this reassurance is misplaced.

Where this data is weak

Every provider in this space has these limitations. Not every provider writes them down.

• Residential proxies are the hard case. They route through real consumer ISP addresses — often on devices whose owners do not know it is happening. The address genuinely is residential, so the signal that normally reassures you is the signal being abused. Any vendor quoting you a single confident detection rate here is describing a benchmark they built themselves.
• Addresses are shared and they get recycled. Carrier-grade NAT can put thousands of mobile users behind one address. ISPs reassign addresses between customers. An address with a bad history may have an entirely new occupant today.
• An IP is not a person. Offices, universities, cafés and households share one address across many people. Blocking the address blocks all of them.
• Geolocation is approximate. City-level accuracy is normal for the industry, and it degrades on mobile networks and on any address that is proxied or relayed. Do not use it for anything that must be exact.
• Freshness is a real constraint. Infrastructure changes constantly. New endpoints appear before any provider knows about them, and stale entries linger. A flag is a recent observation, not a permanent property of the address.

Setting a threshold

The right threshold depends on what the visitor is doing and what a mistake costs you in each direction. One sitewide number is almost always wrong somewhere.

• Login and registration tolerate more friction. A wrongly challenged user retries; a compromised account is expensive. Acting on medium scores is defensible here.
• Checkout is the expensive place to be wrong. A rejected legitimate order is revenue you never see and a customer who does not come back to tell you. Prefer extra verification over refusal, and reserve outright blocking for high scores with corroborating evidence.
• Anything public-facing — content, search, pricing pages — should very rarely block on IP at all. The downside of a false positive is losing a reader or a buyer silently.
• Do not block on a single flag. Our default scoring deliberately places a bare commercial VPN below the plugins' default block threshold, because VPN use on its own is not evidence of wrongdoing. If you want that traffic blocked, that is an explicit choice you make, not something we make quietly on your behalf.
• Challenge before you refuse. A verification step converts a false positive into a minor annoyance. A hard block converts it into a lost customer.

What we deliberately do not do

• We do not publish an accuracy table. The percentages that circulate in this industry rarely trace to a method anyone can audit, and a single figure for residential proxy detection is not a claim that can be honestly made.
• We do not describe our sources or thresholds in detail. Publishing the exact rules would mainly serve the people trying to route around them, which helps nobody paying for this.
• We do not return a block/allow verdict. We return evidence. The policy decision stays with you, because only you know what the traffic was trying to do.

If we get one wrong

Misclassifications happen and we would rather hear about them. Send the address and what you expected to [email protected]. Corrections apply to everyone using the data, so a report from one customer improves results for the rest.

If you are not a customer and a site blocked you, our explainer for blocked visitors covers what usually causes it and how to get back in. Note that only the site owner can lift a block on their own site — we supply the data, they set the policy.