We were reporting a university as a VPN
An audit of our ASN list against the regional registry found an entry labelled 'WindScribe' that was actually Wake Forest University. Here is how a comment became a false positive against real students.
A customer's Proton VPN address came back with a risk score of 0 and every signal clean. Chasing that miss turned up something worse than the miss itself.
The list nobody could check
VPN detection partly rests on a list of autonomous system numbers — the identifiers networks announce their addresses under. Ours was a plain set of numbers with brand names in comments:
// WindScribe (TOTALLYACAB / own ranges) 40245,
AS40245 is not Windscribe. It is Wake Forest University. Every address that university announces was being reported to our customers as commercial VPN egress. Windscribe's actual ASN, 397540, was not in the list at all.
The mechanism matters more than the individual mistake: a comment cannot be verified by anything. No test reads it, no build step checks it, and it will happily contradict the number beside it forever.
Why a false positive is the expensive kind
Missing a VPN costs you one signal out of several. Flagging a university blocks real people who did nothing wrong, and they have no idea why. Worse, they cannot tell you — the failure appears on someone else's signup form, not on ours.
Our own documentation warns that blocking every VPN is the most common false-positive complaint about fraud tools. We were doing something narrower and worse: blocking one specific institution, silently.
Making the claim checkable
Both lists are now maps from ASN to the holder name registered with the regional internet registry, so every claim is data rather than prose:
export const VPN_PROVIDER_ASN_HOLDERS: Record<number, string> = {
9009: "M247 M247 Europe SRL",
199218: "ProtonVPN-2 Proton AG",
397540: "WINDSCRIBE - Windscribe",
};A script re-queries RIPEstat and fails on any entry whose holder no longer matches. That matters beyond catching typos: ASNs get transferred between organisations, and a transfer silently turns a correct entry into a false positive against whoever holds it now.
A second check reads PeeringDB, where networks declare what kind of operator they are, and hard-fails if anything classified Educational/Research or Government appears in either list. That is the specific check that would have caught Wake Forest on the day it was added.
What we did not do
PeeringDB is self-reported, so we deliberately do not consult it at scoring time. A hosting company that mis-files itself as a consumer ISP would suppress a real VPN signal in production — trading a visible false positive for an invisible false negative, which is the worse of the two. It runs as a lint, where a human sees the result.