ipasis
Blog/Security Engineering

Proactive Fraud Prevention: Leveraging IP Risk Signals Pre-Transaction

March 05, 20265 min read

Fraud detection strategies that rely solely on post-transaction analysis (chargebacks, behavioral analysis) are inherently reactive. By the time an anomaly is flagged, the resource has often already been consumed or exfiltrated.

For high-velocity platforms, the perimeter of defense must move to the initial TCP handshake. By analyzing IP reputation signals—specifically the detection of anonymizers like VPNs, proxies, and Tor nodes—engineers can implement conditional friction or hard blocks before a malicious payload is even processed.

The Anatomy of High-Risk IPs

Legitimate users rarely browse e-commerce sites or banking portals via datacenter proxies or Tor exit nodes. The presence of these connection types is a primary signal of intent to mask identity.

To effectively filter traffic, we categorize IP attributes into three risk vectors:

  1. Connection Type: Distinguishing between Residential (ISP), Business, wireless (Cellular), and Datacenter hosting.
  2. Anonymizer Status: Boolean flags for VPNs, Open Proxies (SOCKS/HTTP), and Tor.
  3. ASN Reputation: Analyzing the Autonomous System Number to detect hosting providers known for harboring botnets (e.g., specific budget VPS providers).

Implementation Strategies

Integrating IP intelligence should occur at the middleware level or API gateway. This prevents the request from reaching expensive business logic controllers if the risk signals are too high.

Python: Middleware Integration

In a Flask or Django environment, this logic sits within a before_request hook. The goal is to minimize latency while ensuring security coverage.

import requests
from flask import Flask, request, abort

app = Flask(__name__)

# Configuration
IPASIS_API_KEY = "your_api_key"
MAX_RISK_SCORE = 85

def get_ip_risk(ip_address):
    """
    Queries IPASIS to retrieve threat intelligence data.
    """
    try:
        response = requests.get(
            f"https://api.ipasis.com/v1/{ip_address}",
            headers={"X-API-Key": IPASIS_API_KEY},
            timeout=0.5 # Fail open or closed based on strictness requirements
        )
        return response.json()
    except requests.exceptions.RequestException:
        # Log failure, default to allow if strictly necessary
        return None

@app.before_request
def security_checkpoint():
    client_ip = request.remote_addr
    
    # Skip local dev environment
    if client_ip == "127.0.0.1":
        return

    risk_data = get_ip_risk(client_ip)
    
    if risk_data:
        # Rule 1: Hard block Tor exit nodes
        if risk_data.get('is_tor'):
            abort(403, description="Tor connections not permitted.")

        # Rule 2: Block datacenter proxies on checkout endpoints
        if request.path == "/api/checkout" and risk_data.get('connection_type') == 'datacenter':
            abort(403, description="Anonymizers not permitted during checkout.")
            
        # Rule 3: Dynamic Risk Score Evaluation
        if risk_data.get('fraud_score', 0) > MAX_RISK_SCORE:
            abort(403, description="High risk IP detected.")

Node.js: Express Middleware

For Node.js environments, we use an asynchronous middleware function. Note the use of Promise.all if you are combining this with other checks (like rate limiting) to keep the event loop non-blocking.

const axios = require('axios');

const ipCheckMiddleware = async (req, res, next) => {
    const clientIp = req.ip;
    
    try {
        const response = await axios.get(`https://api.ipasis.com/v1/${clientIp}`, {
            headers: { 'X-API-Key': process.env.IPASIS_KEY },
            timeout: 500
        });

        const { is_vpn, is_proxy, fraud_score } = response.data;

        // Scenario: Allow VPNs for login, but block for registration
        if (req.path === '/register' && (is_vpn || is_proxy)) {
            return res.status(403).json({ 
                error: 'Registration requires a non-proxied connection.' 
            });
        }

        next();
    } catch (error) {
        // Fallback strategy: Log error and allow traffic to prevent downtime
        console.error('IP Intelligence unavailable:', error.message);
        next();
    }
};

app.use(ipCheckMiddleware);

Defining Risk Thresholds

Not all VPNs are malicious. A corporate VPN user accessing a SaaS dashboard is legitimate; a datacenter proxy attempting to create 50 accounts in a minute is not. Do not treat risk as binary.

Recommended Logic:

  • Tor / Public Proxies: BLOCK. These have almost zero legitimate use cases for commercial transactions.
  • Datacenter IPs: CAPTCHA or 2FA. If the user is legitimate, they can pass a challenge. Bots cannot.
  • Residential VPNs: FLAG. Allow the transaction but mark it for manual review if the value exceeds a specific dollar amount.

FAQ

Q: Will checking IP reputation introduce latency?

A: API lookups add network overhead. However, high-performance APIs like IPASIS operate with sub-50ms response times. Combined with caching strategies (Redis/Memcached) for repeat visitors, the impact on UX is negligible compared to the security benefits.

Q: How do we handle IPv6?

A: Modern threat intelligence APIs support IPv6. However, because IPv6 allows for massive subnet rotation, reputation is often calculated at the /64 CIDR block level rather than the single IP address.

Q: What about false positives?

A: False positives occur, usually with corporate VPNs or iCloud Private Relay. This is why we recommend "conditional friction" (e.g., forcing 2FA or email verification) rather than hard 403 blocks for mid-risk signals.

Secure Your Perimeter

Hard-coding blacklists is unscalable. As fraudsters rotate through millions of residential proxies, you need a dynamic, API-driven solution to identify threats in real-time.

Get your free API Key from IPASIS and start filtering high-risk traffic today.

Start detecting VPNs and Bots today.

Identify anonymized traffic instantly with IPASIS.

Get API Key