My Geocode

Guides

Build a simple IP reputation check for signups

· 4 min read · My Geocode · #ip-lookup#fraud-prevention#signups#security

A dedicated fraud detection service is more than most small signup forms need. A simple check comparing what an IP address suggests against what a signup form claims catches a reasonable share of obviously mismatched attempts on its own.

Getting IP details at signup

GET /v1/ip?ip=198.51.100.200
{
  "status": "ok",
  "ip": "198.51.100.200",
  "version": 4,
  "found": true,
  "country": "Brazil",
  "country_code": "BR",
  "region": "Sao Paulo",
  "city": "Sao Paulo",
  "postcode": "01310",
  "lat": -23.5505,
  "lon": -46.6333,
  "timezone": "America/Sao_Paulo",
  "asn": 8901,
  "org": "Example Cloud Provider"
}

Comparing country against form input

If the signup form asks for a billing country and the value entered does not match country_code from the IP lookup, that alone is not proof of anything wrong, since travel and VPN use are both common and legitimate. Treat a mismatch as one point added to a simple score rather than an automatic rejection.

Weighing network type

The org field often reveals whether an address belongs to a residential ISP or a data center or cloud hosting provider. A signup coming from a cloud hosting network, where a real individual customer would rarely be browsing from, is worth a higher score than one from a recognizable residential ISP, though again not an automatic rejection on its own.

A second example: a small known-ASN list

If you have noticed particular ASN values showing up repeatedly around abusive signups, keeping a short list of those specific asn numbers and adding a fixed score whenever a new signup matches one is a lightweight way to encode that pattern going forward, without needing a full third-party ASN reputation database for a check this modest in scope.

if ip_info["asn"] in known_abuse_asns:
    score += 2

Combining signals into a score

Add up a small number of simple checks: country mismatch, hosting network origin, and anything else specific to your own signup flow, into a single numeric score. Route anything above a threshold you set to manual review or an extra verification step, such as email confirmation, rather than blocking outright.

A common mistake to avoid

Do not score every VPN or hosting-range signup as automatically high risk without any other context. Plenty of legitimate customers browse from a company network that happens to route through a data center IP range, or from a VPN they use for entirely ordinary privacy reasons. Weighting network type as one signal among several, rather than a single disqualifying flag, keeps the check from turning away real customers over a false positive.

An edge case: many signups from one shared address

A shared office network or a large mobile carrier's carrier-grade NAT can put a lot of unrelated, legitimate signups behind the same IP address in a short window. If you are also tracking signup volume per IP as part of your check, set that threshold generously enough to allow for this, or watch it alongside the country and network signals rather than as a rule on its own.

Keeping it proportionate

This kind of check is meant to catch obviously low-effort abuse, not to replace a real fraud prevention system for a business where fraud losses are a serious concern. Treat it as a first filter, not a final verdict.

Request cost

One lookup per signup attempt is one request. Even a form receiving a steady stream of signups stays well inside the 2,500 free requests a day included with every key for typical volumes. The X-Quota-Used and X-Quota-Free-Remaining response headers are a simple way to keep an eye on how much of that allowance a sudden spike in signup attempts is consuming.

A lightweight score built from a couple of IP-derived signals catches more than doing nothing, without the overhead of a dedicated fraud platform. The IPv4 lookup docs list every field available for this kind of check.

More in Guides