'Proxy: true' is not a fraud strategy

Proxy detection systems often provide a simple "true" or "false" result, which can be technically accurate but operationally ineffective. These systems typically flag an address as a proxy and may assign a confidence score, but leave it to the fraud team to decide whether to block a login, challenge a checkout, or disregard the signal.

The crucial missing piece is context. A commercial VPN exit used by many legitimate customers should not be treated the same as a residential proxy endpoint that just appeared. Similarly, a crawler operated by a known search engine should not be considered the same as a relay through an opaque bandwidth-sharing SDK.

The decision-making process is improved when we know not just "is this a proxy?", but also "which provider or network is behind it?". Understanding the type of access that provider sells is also important. Is the address residential, mobile, hosting, or a mix? When was it last observed behaving in this way? We should also consider the surrounding signals and their agreement.

The freshness of the data matters more than having a large historical list. VPN providers add new ranges, residential endpoints change frequently, and resellers alter upstream networks. It's more useful to preserve the observation time and source context, rather than assuming an IP has a permanent identity. We should ask how recently the address was seen, whether the observation repeated, and whether the network relationship still exists.

The system should provide enough information to the security team to apply decay. A recent observation can impact real-time decisions, while an older one may still aid an investigation but should not carry the same weight. Detection vendors should describe the infrastructure, while the application should decide how to use this information.

A simple policy might treat proxy or VPN status as one feature, never the final verdict. Recent residential or mobile proxy observations should increase weight. Additional provider-specific rules should only be added when the provider's product and sourcing model are well understood.

Network evidence should be combined with account age, device history, velocity, payment risk, and user behavior. Logging the fields that triggered a challenge or block is essential for later analyst explanation and helps to reduce false positives. A privacy-conscious customer using a mainstream VPN should be allowed to pass when the rest of the session looks normal. In contrast, an attacker rapidly switching through residential endpoints should accumulate enough evidence to trigger a higher response.

At Synthient, we built our system around these principles. Our lookup provides information about the observed provider, proxy or VPN type, network ownership, geography, behavior signals, timestamps, and a risk score. This data is available as bulk feeds and a live stream for continuous updates to security controls. The goal is not to create the largest blocklist, but to make the IP signal specific enough for fraud or security teams to justify their decisions.

You can try a lookup at synthient.com/context. I am particularly interested in the specific fields your team needs to trust a proxy signal in a production environment.