IP-based fraud detection was built on a set of assumptions that no longer hold. The core assumption was that a fraudulent session would originate from an identifiable source: a datacenter IP block, a known-bad IP range, a country mismatch. Those signals were useful when attackers operated from fixed, identifiable infrastructure. That era ended several years ago.
The residential proxy market is the mechanism that ended it. Residential proxies route traffic through the IP addresses of real consumer devices, typically through SDK-level integrations in mobile apps that users have installed without understanding what they consented to. The attacking session arrives at your fraud system from a residential broadband IP in the account's home city. Every IP-based check passes.
What residential proxies actually look like to fraud systems
A residential proxy session is indistinguishable from a legitimate session at the IP layer. The IP is not in a datacenter block. It is not on a known-bad list. Its geolocation matches the account's registration location. The ASN is a consumer ISP, not a hosting provider. If your fraud system's IP checks give a clean bill of health to a residential broadband IP, a proxy session through that IP will also pass.
IP reputation lists capture known-bad proxies after they have been reported. But the residential proxy market has enough inventory to rotate through addresses faster than those lists can be updated. A large-scale residential proxy network has millions of nodes. The adversary doesn't need to reuse flagged IPs.
The deeper problem: IP is a network property, not a behavioral one
Even if residential proxies didn't exist, IP reputation would have a structural limitation as a fraud signal: it tells you about the network path, not about the person on the other end. Two sessions from the same IP can be one legitimate and one fraudulent. A VPN-using power user and a fraudster both route through the same provider's IP range.
The IP address is a property of the request routing, not a behavioral property of the session. You can attach risk signals to IP characteristics, but they are always indirect. They are inferences about the person based on the network, not observations of the person's actual behavior.
Behavioral signals do not have this indirection. Input cadence, session navigation patterns, and device interaction traces are properties of the specific human operating that session. A residential proxy routes the network traffic, but it cannot simulate a human's motor patterns, cognitive load signatures, or browsing behavior. Those remain specific to the actual operator of the session.
Where IP still has signal value
IP-based signals are not worthless. They remain useful as weak signals in a composite score, and they are still effective against unsophisticated attackers who haven't adopted residential proxies. A session from a datacenter IP range with no other risk indicators is legitimately suspicious. A session from a Tor exit node warrants additional scrutiny.
The mistake is treating IP reputation as a primary signal or as a signal that can stand alone as a block criterion. At a high block threshold, IP-based blocking catches many legitimate users: travelers using hotel wifi, remote workers on corporate VPNs, privacy-conscious users on commercial VPNs. At a low block threshold, it misses most sophisticated attackers. The sweet spot, if there is one, is narrow enough that IP needs to be a secondary input rather than a primary decision driver.
What to use instead
The signals that are resilient to the proxy market are the ones that require simulating a specific human's behavior, not just routing through a residential IP. Input cadence and timing patterns are the hardest to simulate at scale because they require injecting human-like variance into automation, and that variance needs to match the account owner's specific historical patterns, not just generic human-input distributions.
Session warm-up patterns are also resilient. A proxy session begins from a request, not from a browse. The absence of the navigation history that precedes a legitimate login session is a behavioral absence that cannot be supplied by the proxy network itself.
Device consistency signals, when compared against account history rather than static blocklists, have similar resilience: the proxy network controls the IP, but not the device environment. Hardware profiles, browser configurations, and timezone-location consistency are properties of the actual device running the session.
None of these signals are individually definitive. Combined into a behavioral trust score, they produce a detection layer that does not share the evasion surface of IP-based systems. Bypassing behavioral scoring requires simulating a specific account owner's behavioral history, not routing through a residential IP. That is a much harder problem for attackers to solve at scale.
