ipasis
Blog/Security Engineering

IP-Based Fraud Signals Every Fintech Should Monitor

January 09, 20265 min read

In the fintech sector, the IP address is often the first immutable data point available during a transaction or login event. While device fingerprinting and behavioral biometrics are valuable, they require client-side execution. IP intelligence, conversely, is a low-latency, server-side defense layer that can preemptively block malicious traffic before it reaches your core logic.

This guide outlines the specific IP-based signals engineering teams must monitor to mitigate Account Takeover (ATO) and synthetic identity fraud.

1. ASN Context and ISP Types

Not all ISPs are created equal. A legitimate user accessing a banking app is typically routed through a Residential ISP (Comcast, Verizon, BT) or a Mobile Network Operator (T-Mobile, Vodafone).

Traffic originating from hosting providers (AWS, DigitalOcean, Linode) or datacenters suggests automation or a proxy. Monitoring the Autonomous System Number (ASN) and the associated ISP Class is critical.

Implementation Strategy

Block or challenge traffic where the ISP type is hosting or datacenter for critical endpoints like /signup or /transfer.

import requests

def validate_ip_context(ip_address):
    # Example using IPASIS API
    response = requests.get(f"https://api.ipasis.com/v1/{ip_address}")
    data = response.json()

    # Risk Logic
    if data['asn']['type'] in ['hosting', 'datacenter']:
        return False, "REJECT: Traffic from hosting provider detected."
    
    return True, "ACCEPT"

2. Proxy and VPN Detection

Fraudsters use anonymizers to hide their location or bypass geo-fencing. While simple blocklists catch known datacenter VPNs, sophisticated attackers use Residential Proxies (hijacked IoT devices) to mimic legitimate users.

Your IP intelligence provider must distinguish between a standard residential connection and a residential proxy exit node. Look for high fraud scores associated with specific IP ranges or real-time threat feeds.

Key Signals to Monitor:

  • Is_Proxy: Boolean flag for generic proxies.
  • Is_VPN: Commercial VPN detection.
  • Is_Tor: Exit nodes (immediate red flag for fintech).

3. Geo-Velocity (Impossible Travel)

Geo-velocity checks calculate the speed required to travel between two subsequent login locations associated with a single User ID. If a user logs in from London, and 10 minutes later logs in from Singapore, the velocity implies a shared account or compromised credentials.

Implementation Strategy

Calculate the Haversine distance between the current IP coordinates and the last known valid IP coordinates.

// Node.js Example: Simple Impossible Travel Check
const haversine = require('haversine-distance');

function checkVelocity(lastLogin, currentLogin) {
    const distanceMeters = haversine(lastLogin.coords, currentLogin.coords);
    const timeDeltaHours = (currentLogin.timestamp - lastLogin.timestamp) / (1000 * 60 * 60);
    
    // Assume max travel speed of 1000 km/h (plane)
    const speed = (distanceMeters / 1000) / timeDeltaHours;

    if (speed > 1000) {
        throw new Error("FRAUD_SIGNAL: Impossible travel velocity detected.");
    }
}

4. Subnet-Level Anomalies

Sophisticated botnets rotate IPs for every request to bypass rate limits. However, these IPs often belong to the same CIDR block or subnet.

Instead of rate-limiting single IPs, fintechs should implement sliding window rate limits on /24 (IPv4) or /64 (IPv6) subnets. If a specific subnet generates 50 failed login attempts from 50 different IPs, the entire subnet should be temporarily greylisted.

// Go Example: CIDR Parsing for Subnet Grouping
package main

import (
	"net"
	"strings"
)

func GetSubnetKey(ipStr string) string {
	ip := net.ParseIP(ipStr)
	if ip.To4() != nil {
		// Return the /24 prefix for IPv4
		mask := net.CIDRMask(24, 32)
		maskedIp := ip.Mask(mask)
		return maskedIp.String()
	}
	// Return the /64 prefix for IPv6
	mask := net.CIDRMask(64, 128)
	maskedIp := ip.Mask(mask)
	return maskedIp.String()
}

5. Connection Type Mismatches

Analyze the consistency between the User-Agent and the Connection Type.

  • Anomaly: A User-Agent identifying as iOS / iPhone originating from a Fixed Line / Landline connection type (via Wi-Fi) is normal. However, if the connection type is Data Center, it is likely a mobile emulator running on a server farm.
  • Anomaly: A desktop User-Agent originating from a Cellular network is plausible (hotspot) but warrants a lower trust score than a fixed residential line.

FAQ

Q: How do we handle false positives with VPNs? A: Not all VPNs are malicious. Corporate VPNs are common. Instead of a hard block, trigger a step-up authentication (2FA/OTP) when a new VPN connection is detected on an account.

Q: What about Carrier-Grade NAT (CGNAT)? A: Mobile networks often share one IP across thousands of users. This is why blocking single IPs is dangerous. Rely on a combination of IP Reputation + Device Fingerprinting, rather than IP banning alone.

Q: Does IPv6 change fraud detection? A: Yes. Attackers have access to quintillions of IPv6 addresses. Rate limiting individual IPv6 addresses is useless. You must aggregate reputation logic at the /64 subnet level.

Secure Your Perimeter with IPASIS

Building internal datasets for ASN mapping and proxy detection is resource-intensive and prone to staleness.

IPASIS provides real-time, high-accuracy IP intelligence via a developer-friendly API. We process millions of signals daily to ensure you can distinguish between a legitimate customer on a coffee shop Wi-Fi and a botnet launching a credential stuffing attack.

Get your API Key and start filtering traffic today.

Start detecting VPNs and Bots today.

Identify anonymized traffic instantly with IPASIS.

Get API Key