Proxy Score and Fraud Score

Back to Residential Proxies

A proxy score estimates how likely a request is to be using a proxy, anonymiser, VPN, Tor exit, residential proxy, mobile proxy, or other indirect network path. A fraud score estimates how risky the request, session, account, transaction, or event is for a business outcome.

They are related, but they are not the same. A high proxy score does not automatically mean fraud. A low proxy score does not mean the request is safe.

For IP context, start with IP quality and IP reputation databases.

What a proxy score should answer

A proxy score should help answer:

• Is the request likely routed through an intermediary?
• What type of intermediary is likely: datacenter proxy, VPN, Tor, residential proxy, mobile proxy, corporate proxy, or unknown?
• How fresh and confident is the evidence?
• Is the public IP shared by many legitimate users?
• Does the network behaviour fit direct user traffic?
• What evidence supports the score?

For residential proxies, the score should be close to the request. Static labels can miss fresh exits, and mobile carrier IPs can be shared through CGNAT.

What a fraud score should answer

A fraud score should include business and workflow context:

• Is the action sensitive?
• Is the account new, known, trusted, or already risky?
• Are credentials exposed or being tested repeatedly?
• Does the device match prior sessions?
• Is the behaviour normal for the route?
• Are payment, shipping, advertising, or conversion signals suspicious?
• Would enforcement create unacceptable customer impact?

The fraud score may use proxy evidence, but it should also include account, session, credential, transaction, and behavioural signals.

Why the distinction matters

Confusing proxy score with fraud score causes two common errors.

The first is over-enforcement. A legitimate customer using a VPN, mobile network, corporate proxy, or shared residential IP may receive a high proxy score. Blocking that user solely because of the proxy score can create false positives.

The second is under-enforcement. A credential stuffing attempt may use low-confidence or fresh residential proxy exits that do not yet score highly in reputation systems. If the fraud model waits for a perfect proxy label, it may miss the account-risk pattern.

The safer approach is to treat proxy score as one input to a wider decision.

Signals behind a proxy score

Proxy scores can use several signal families:

• IP allocation, ASN, geolocation, and hosting classification from IP intelligence.
• Known VPN, Tor, proxy, and anonymiser labels.
• Historical abuse and reputation data.
• Per-request residential proxy detection.
• Network, TLS, TCP, HTTP, and timing fingerprints.
• Route consistency and connection behaviour.
• Sharing and NAT context.

The score is stronger when it includes evidence and confidence, not just a number.

Signals behind a fraud score

Fraud scores usually need workflow-specific evidence:

• Account age, history, and trust state.
• Credential risk and failed attempts.
• Device, browser, and session continuity.
• Payment, shipping, refund, or promo behaviour.
• Ad click and conversion quality.
• Scraping, inventory, or API request patterns.
• Bot and automation signals from bot management.
• Proxy score and IP risk context.

A fraud score should also account for the action being taken. The same session may be safe for a public page view but risky for password reset, checkout, payout, or administrative access.

How to use scores in policy

Scores are most useful when they map to proportionate actions:

• Low risk: allow and monitor.
• Uncertain: log, add observability, or apply soft friction.
• Medium risk: challenge, step up authentication, or rate limit.
• High risk: block, hold for review, or require stronger verification.

Policy should avoid hidden single-threshold behaviour where every score above a number becomes a block. That is especially important for residential and mobile networks where false positives can affect many legitimate users.

Evaluation questions

When reviewing a score, ask:

• What signals contributed to it?
• Is it current or based on stale history?
• Does it distinguish proxy type?
• Does it handle mobile and shared IPs carefully?
• Can analysts review the evidence?
• Can the business tune different actions by route?
• Does the score improve outcomes, or only produce more blocks?

For vendor selection, see proxy detection vendor evaluation. For action design, see proxy signals and security decisions.

Good scoring does not remove judgement. It gives teams a clearer, reviewable basis for choosing the right level of friction.