Fraudsters rarely attack from their own local ISP connections. To scale credential stuffing, account takeovers (ATO), or credit card fraud, they rely on anonymization layers—specifically hosting networks, residential proxies, TOR nodes, and VPNs.

For engineering teams, the challenge lies not just in blocking malicious IPs, but in implementing granular decisioning logic that stops fraud without increasing friction for legitimate users. This guide details how to integrate IP intelligence into your authentication and checkout pipelines.

The Anatomy of an Anonymized Attack

Sophisticated fraud rings do not use static data center IPs often, as those are easily blacklisted. Instead, they utilize:

Residential Proxies: Routed through compromised IoT devices or legitimate user machines, making the traffic appear as a standard residential ISP connection.
Hosting/Data Centers: High-throughput servers used for brute-force attacks.
VPNs: Commercial VPNs used to mask location during geo-restricted transaction attempts.

Static lists are ineffective against these vectors. Dynamic lookups via an API like IPASIS are required to assess the metadata associated with the connection in real-time.

Key Signals for Decisioning

When querying IP intelligence, you are looking for specific boolean flags and risk scores. The most critical signals for fraud prevention are:

is_proxy / is_vpn: Indicates the user is hiding their identity.
asn_type: hosting vs isp. Hosting ASNs interacting with consumer endpoints (like /checkout) should almost always be challenged.
is_tor: Traffic from the TOR exit node list is rarely legitimate commerce traffic.
Geo-mismatch: Comparing the IP's resolved location against the user's billing address or device GPS.

Implementation Architecture

IP intelligence should be queried at the edge (middleware) or immediately upon hitting your backend controller. Do not defer this check until after database writes occur.

Python Implementation (Flask/Django Context)

The following example demonstrates a decision engine that segments traffic into ALLOW, CHALLENGE, and BLOCK buckets based on IPASIS data.

import requests
from enum import Enum

class Action(Enum):
    ALLOW = "allow"
    CHALLENGE = "challenge" # e.g., 2FA, Email Verify, 3DS
    BLOCK = "block"

def evaluate_ip_risk(ip_address: str, billing_country: str = None) -> Action:
    # 1. Query IPASIS API
    try:
        response = requests.get(f"https://api.ipasis.com/v1/{ip_address}?key=YOUR_API_KEY", timeout=0.5)
        data = response.json()
    except requests.RequestException:
        # Fail open or closed depending on risk appetite
        return Action.ALLOW

    # 2. Hard Blocks
    # Block known crawlers or TOR nodes on sensitive endpoints
    if data.get('security', {}).get('is_tor') or data.get('security', {}).get('is_crawler'):
        return Action.BLOCK

    # 3. ASN Context Analysis
    # Hosting providers (AWS, DigitalOcean) usually shouldn't be making purchases
    asn_type = data.get('connection', {}).get('asn_type')
    if asn_type == 'hosting':
        return Action.CHALLENGE

    # 4. Proxy/VPN Logic
    if data.get('security', {}).get('is_proxy') or data.get('security', {}).get('is_vpn'):
        # If it's a residential proxy, risk is higher for fraud
        if asn_type == 'isp':
            return Action.BLOCK
        return Action.CHALLENGE

    # 5. Geolocation Velocity/Mismatch
    ip_country = data.get('location', {}).get('country_code')
    if billing_country and ip_country != billing_country:
        return Action.CHALLENGE

    return Action.ALLOW

Node.js Implementation (Middleware)

In a Node environment, this logic sits well within an Express middleware function.

const axios = require('axios');

const ipRiskMiddleware = async (req, res, next) => {
  const ip = req.headers['x-forwarded-for'] || req.socket.remoteAddress;
  
  try {
    const { data } = await axios.get(`https://api.ipasis.com/v1/${ip}?key=${process.env.IPASIS_KEY}`);
    
    // Block high-risk hosting traffic
    if (data.connection.asn_type === 'hosting' && data.security.is_proxy) {
      return res.status(403).json({ error: 'Connection rejected due to high risk.' });
    }

    // Attach intelligence to request for downstream logic
    req.ip_intelligence = data;
    next();
  } catch (err) {
    console.error('IP Intelligence Lookup Failed', err);
    next(); // Fail open
  }
};

Handling False Positives

Aggressive blocking leads to lost revenue. A "Challenge" response is preferable to a "Block" for ambiguous signals (like legitimate VPN users).

If is_vpn is true but the IP is not blacklisted:

Pre-Authentication: Trigger CAPTCHA.
Authentication: Trigger 2FA/OTP.
Checkout: Force 3D Secure (3DS) on the card transaction.

Frequently Asked Questions

Q: How does this impact API latency? A: IPASIS is architected for low-latency lookups (sub-50ms). However, we recommend setting a tight timeout (e.g., 200ms) on the request and "failing open" (allowing the user) if the API call fails, to ensure user experience isn't degraded during network partitions.

Q: Can we trust IPv6 geolocation? A: IPv6 adoption is increasing, but geolocation precision is generally lower than IPv4. Rely more on ASN reputation and Proxy detection for IPv6 addresses rather than precise city-level targeting.

Q: What about mobile carrier networks (CGNAT)? A: Mobile IPs often rotate rapidly. IPASIS identifies these via the connection.isp type. You should avoid rate-limiting strictly by IP on mobile networks to prevent blocking legitimate user clusters.

Secure Your Stack with IPASIS

Fraud moves fast. Your security infrastructure needs accurate, real-time data to distinguish between a paying customer on a VPN and a botnet using residential proxies.

Get your free IPASIS API Key today and start filtering malicious traffic with enterprise-grade precision.

Implementing IP-Based Fraud Prevention: A Technical Guide