Verifying an address matches its stated postal code before checkout
A mismatched postal code and city on an order form looks like a small typo until it turns into a delivery sent to the wrong part of the country entirely.
Flagging risky signups with IP-based fraud checks
An online lender kept approving applications that looked fine on paper and turned into chargebacks a month later. The pattern was always the same: a burst of signups from addresses that had never touched a residential network, all landing within a few hours of each other.
The fix did not require new fraud rules or a bigger review team. It required knowing more about the connection behind each signup, at the moment it happened. Every application already carries an IP address. The question is whether that address belongs to a home internet connection, a data center, or a known open proxy, and whether it shares a network with dozens of other signups from the same week.
That is what a call to /v1/ip returns: country, region, city, postcode, coordinates, time zone, ASN and organization for the address making the request. With mg_extras=1 or the X-MG-Extras header, the same call also returns threat and network detail, the kind of signal that shows an address sits inside a hosting range rather than a home broadband pool. A residential ISP and a commercial data center have very different ASN and organization fields, and that difference is often the first sign that a signup is not what it claims to be.
The lender wired this into the signup handler itself, server-side, before the application record was even created. A signup from a known hosting ASN did not get auto-rejected, it got routed to a manual queue. A signup where the IP's country did not match the billing address entered on the form got the same treatment. Neither signal is proof of fraud by itself. Applied consistently across thousands of signups, together they cut the number of applications needing a human look, because the clean ones stopped competing for review time with the obviously suspicious ones.
This kind of check sits alongside, not instead of, the identity and income verification a regulated lender already runs as part of its know your customer process. IP geolocation will not confirm someone's income or identity. What it does well is confirm or contradict the story a signup form is telling, cheaply and in real time, before anything else happens.
Cost mattered here too. The lender stayed inside the 2,500 free requests a day that come with every My Geocode key, since one IP check per signup is a light workload for most sites. Past that allowance the calls settle into prepaid credit at €0.0001 a request, which for a check running on every signup form is a small line item next to the cost of a single bad loan.
None of this replaces a fraud team's judgment. It gives that team better material to judge. A queue full of signups from data center ranges and mismatched countries is a queue worth reviewing by hand. A queue where the network data lines up with the applicant's own story can move faster, and that is the actual point of running the check at all.
Full request and response details for both address families live at /docs/ipv4-lookup/ and /docs/ipv6-lookup/, with the available key methods covered at /docs/authentication/.