IP intelligence explained: what an IP address can tell a reviewer, and what it cannot
IP intelligence is the practice of enriching the IP address behind a digital submission with contextual data, such as approximate geographic location, the type of network it belongs to, whether it is associated with a VPN, proxy or hosting provider, and any reputation history attached to it. The output describes a network path. It does not identify a person.
Also written as IP enrichment or IP reputation depending on the vendor, it turns up in claims intake, remote inspection flows, account opening and any process where material arrives from somewhere you cannot see.
What does IP intelligence tell you?
- Approximate location: country level is usually reliable. City level is weaker, and on mobile networks it is often wrong by a wide margin.
- Network type: residential broadband, mobile carrier, corporate, hosting or data centre. A submission from a data centre range is a different proposition from one on a home connection.
- Anonymisation status: whether the address is associated with a commercial VPN, a proxy service or the Tor network.
- Reputation: whether the address has appeared on abuse or blocklist feeds, and in what context.
- Reuse: whether the same address has appeared across your own cases before, which is often the most useful signal of the set and the most easily misread.
How accurate is IP geolocation?
Less accurate than most dashboards imply, and the gap widens on mobile. Carrier-grade NAT, standardised around the shared address space reserved in RFC 6598 (100.64.0.0/10), lets a single public address front very large numbers of subscribers at once. The address a geolocation database resolves is the carrier's gateway, not the handset.
Three consequences follow. A mobile submission can appear hundreds of kilometres from where it was made. Thousands of unrelated subscribers can share one address at the same moment. And because carrier pools get reassigned, a database entry can be stale within hours.
IP intelligence example: three claims, one address
Three unrelated damage claims land within a fortnight from the same IP address, and the reuse signal escalates all three for review. The address belongs to a body shop, and the customers each completed their capture on the guest wifi while waiting at reception.
A near-identical pattern appears in households, where two members of the same family submitting separate claims share one address by definition. The signal fired correctly in both cases. The inference behind it would have been wrong.
Where IP signals mislead
- VPN as ordinary hygiene: consumer VPN use is now mainstream and bundled with antivirus subscriptions and browsers. A VPN flag on a genuine claimant is unremarkable.
- Corporate routing: a submission made from an office can egress in another country entirely, depending on how the employer routes traffic.
- Shared addresses: carrier NAT, shared premises, student housing, hotels and any guest network break the assumption that one address means one household.
- Reputation contamination: when one subscriber behind a shared address behaves badly, the reputation attaches to everyone behind it.
- Absence proves little: a clean residential address is trivially available to anyone who wants one, so its presence carries less weight than its absence appears to.
Is an IP address personal data?
Treat it as such. In Breyer (Case C-582/14, 19 October 2016) the Court of Justice of the European Union held that a dynamic IP address can be personal data in the hands of a party that has legal means to identify the subscriber with the help of a third party. That brings IP enrichment inside the GDPR, with the usual consequences: a lawful basis, retention limits, transparency and a place in your record of processing.
Recital 47 recognises fraud prevention as a legitimate interest, which supports the use case without ending the analysis. Where IP enrichment is combined with device fingerprinting across a customer journey, the combined profile is what a regulator will look at, not each signal on its own.
How to weigh IP intelligence in a case
The discipline is the same as for every other technical signal. It sets review priority and it never sets the outcome.
- Corroborate: an IP signal alone is thin. Read alongside device history, claim history and what the submission actually shows, it starts to be worth something.
- Grade it: an ignore, informational, amber and red ladder handles the volume problem better than a binary flag, and keeps the routing decision inside your own risk policy.
- Write it down: if an IP signal changed how a file was handled, record that in the file as you would any other fraud indicator.
- Keep it in proportion: it belongs with the rest of the control points around a submission, alongside receipt time, hashing and session history. Those together are what a reviewer can defend later. See evidence integrity for how the layers fit.
A signal is a reason to look. It is never a verdict, and an IP address is one of the weakest signals in the set to build a decision on.