VPN Detection Without Blocking Legitimate Travelers

VPN detection estimates whether an event IP sits on a known VPN, proxy, or hosting range. It is useful. It is also loud. Corporate exit nodes, campus networks, and travelers will look risky. A blanket BLOCK on VPN is how you train good customers to call support, then to leave.

Treat VPN as a REVIEW signal, not as a conviction. The IP is one attribute on the event. The decision still has to be a sentence you can read to a customer who is sitting in an airport.

Write the combination, not the single flag

VPN and a new device and failed-login velocity is stuffing. VPN and a known-good device on a quiet account is often travel. VPN and a payout-detail change ten minutes after the first login from that address is worth a hold. The flag alone is not.

List IPs after confirmed abuse, not after a single enrichment hit. Enrichment is a hint. A listed address is a policy. If you promote every VPN range into a denylist, you will catch the same office gateway every Monday morning.

Pair the IP signal with a device fingerprint and customer.externalId. Attackers rotate addresses. They are slower to rotate the device in front of them. A known customer on a known phone, arriving from a VPN, should not get the same outcome as an unknown fingerprint on a hosting range after forty failures.

If your current stack is still an IP list, device intelligence versus IP-only checks is the comparison to read before you write the rule. Device context is what lets you leave the traveler alone.

What operations will see if you get this wrong

Support will see "risky IP" on a customer who logged in from a hotel, a client site, or a corporate laptop. Risk will see a queue full of VPN flags and stop trusting the queue. Engineering will be asked to turn the rule off. That cycle is how teams end up with no IP signal at all.

A better week looks like this. The rule fires REVIEW when VPN is present and the device is new, or when VPN is present and login velocity is already hot. Analysts close the travel cases. They list the fingerprints and IPs from the stuffing cases. You then enforce BLOCK on the listed identifiers, not on the enrichment flag.

Naiza enriches events with IP geolocation and VPN detection. Combine these signals with device history and velocity in rules that return ALLOW, REVIEW, or BLOCK. Use risk scores to prioritize investigation and rule context to explain the action. The docs cover event fields and integration.

Connect network signals with AML evidence

Use IP and device signals to assess the session, and AML screening to check the customer and counterparties against watchlists. Label each source in the case so investigators can review network behavior alongside identity matches.

Keep both event and screening identifiers on the case. A clear timeline connects login context, transaction activity, and watchlist evidence for investigation.

Travelers, privacy-conscious customers, and people on corporate networks are a large share of VPN traffic. You will not win that argument by blocking all of them. You win it by combining the flag with device history and velocity, starting in REVIEW, and listing only what you have already confirmed.

The signal is fine. The automatic BLOCK is the mistake.