IP address reputation is the cornerstone of non-invasive fraud detection. Unlike device fingerprinting or behavioral biometrics, IP analysis requires zero client-side code execution. However, treating reputation scores as a binary 'good/bad' signal often leads to high false-positive rates.

This guide breaks down the composition of IP scores and provides implementation patterns for integrating IPASIS intelligence into your security stack.

The Anatomy of a Reputation Score

A raw IP address conveys little information. To derive a reputation score (typically normalized 0–100 or 0–1.0), intelligence providers aggregate data across four primary vectors:

Connection Type: Classification into Residential, Mobile, Data Center (hosting), or Tor/VPN. Data Center IPs generally carry higher inherent risk for B2C applications.
Threat Intelligence Feeds: Cross-referencing the IP against known blocklists (spam, malware C2, botnets).
Behavioral Velocity: The frequency of requests observed across the provider's global network within a sliding time window.
Open Port Analysis: Detection of open proxies or misconfigured servers acting as exit nodes.

Threshold Logic for Engineering Teams

Blindly blocking traffic with a score > 50 is an anti-pattern. Sophisticated fraud systems use Dynamic Friction. Instead of a hard block, the score dictates the level of verification required.

Recommended Risk Tiers

Score 0-30 (Low Risk): Allow request. Typically ISP-assigned residential or mobile IPs with clean histories.
Score 31-75 (Medium Risk): Soft challenge. Often Cloud/Hosting IPs or residential IPs with minor historical anomalies. Trigger 2FA, Email Verification, or CAPTCHA.
Score 76-100 (High Risk): Hard block or shadow-ban. Known TOR exit nodes, active proxies, or IPs currently engaged in brute-force attacks.

Implementation: Dynamic Friction Workflow

The following Python snippet demonstrates a middleware approach using IPASIS. It assesses the IP score and connection type to determine the authentication flow.

import requests
from flask import Flask, request, jsonify, abort

app = Flask(__name__)

IPASIS_API_KEY = 'your_api_key'

def get_ip_reputation(ip_address):
    url = f"https://api.ipasis.com/v1/reputation?ip={ip_address}&key={IPASIS_API_KEY}"
    try:
        response = requests.get(url, timeout=0.5)
        response.raise_for_status()
        return response.json()
    except requests.exceptions.RequestException:
        # Fail open or closed depending on business risk tolerance
        return None

def evaluate_risk(ip_data):
    if not ip_data:
        return "ALLOW" # Fallback

    score = ip_data.get('risk_score', 0)
    is_crawler = ip_data.get('is_crawler', False)
    is_vpn = ip_data.get('is_vpn', False)

    # Allow known search engine crawlers regardless of score
    if is_crawler:
        return "ALLOW"

    # High Risk: Block immediately
    if score > 85 or (is_vpn and score > 70):
        return "BLOCK"

    # Medium Risk: Trigger Step-Up Auth
    if score > 50 or is_vpn:
        return "CHALLENGE"

    return "ALLOW"

@app.route('/login', methods=['POST'])
def login():
    client_ip = request.remote_addr
    ip_intelligence = get_ip_reputation(client_ip)
    action = evaluate_risk(ip_intelligence)

    if action == "BLOCK":
        abort(403, description="Access denied due to high-risk IP.")
    elif action == "CHALLENGE":
        return jsonify({"status": "2fa_required", "message": "Please verify identity."}), 200
    
    # Proceed with standard login logic
    return jsonify({"status": "success", "token": "jwt_token_here"})

Handling False Positives: CGNAT and Mobile Data

A common pitfall in IP scoring is the mishandling of Carrier-Grade NAT (CGNAT). Mobile networks often pool thousands of users behind a single public IP. If one user on that IP acts maliciously, the score spikes, potentially affecting legitimate users.

To mitigate this:

Check the ISP Type: If connection_type is mobile, increase your blocking threshold. Avoid hard blocks on mobile IPs unless the score is critically high (>90).
Combine Signals: Never rely on IP reputation alone for mobile traffic. Combine it with User-Agent analysis or device fingerprinting.

FAQ

Q: What is the optimal cache time (TTL) for an IP reputation score? A: IP ownership and behavior are dynamic. We recommend a TTL of 10 to 60 minutes. Caching for 24+ hours renders the velocity data useless.

Q: Should I block all Data Center IPs? A: Not necessarily. While high risk for account creation, Data Center IPs are legitimate for B2B API traffic or VPN users who are technically inclined but not malicious. Context is key.

Q: How does IPv6 impact scoring? A: IPv6 addresses are often rotated more frequently by ISPs. IPASIS aggregates reputation at the /64 subnet level for IPv6 to ensure scoring continuity.

Enhance Your Security Stack

Stop relying on static blocklists. Integrate real-time intelligence that adapts to modern threats.

Get your free API key at IPASIS and start scoring traffic in under 5 minutes.

Implementing IP Reputation Scoring: A Technical Guide for Fraud Teams