Starlink and Satellite IPs: Geolocation Surprises in Fraud Rules

Fraud rules lean heavily on IP geolocation. “Block signups from outside our markets.” “Challenge logins from a new country.” “Flag a device whose IP country changed within the hour.” Those rules assume an IP address says roughly where a person is. Satellite internet breaks that assumption more often than most rule authors expect, and the people it hurts are rural customers who often have no other option.

Why satellite IPs geolocate strangely

With a low-earth-orbit service like Starlink, your packets go from the dish to a satellite, possibly across satellites, down to a ground station, and onto the internet at a point of presence (PoP). The public IP address your servers see belongs to that exit path, not to the dish.

That has a few practical effects:

• Distance. The PoP can be far from the user. City-level geolocation then lands in the PoP’s metro area, not the user’s town.
• Cross-border exits. In some regions traffic exits in a neighboring country, so the IP’s country can differ from the user’s.
• Shared addresses. For IPv4, Starlink residential service generally uses carrier-grade NAT. Many subscribers share one public address, the same pattern described in CGNAT and shared IPs.
• Mobility. Portable and in-motion plans exist for RVs, boats and aircraft, so a legitimate user’s network location can really move a long way.

Starlink publishes geolocation data for its address ranges that geolocation providers can consume. That helps, but it can’t make an exit-based location match the dish. The limits of IP geolocation covers the general problem. Satellite networks are an extreme case of it.

Rules that misfire

Country allow and deny lists

A rule like country in [allowed markets] reads the IP country. A customer in a border region whose traffic exits in the neighboring country gets refused at signup, even though they live in your market and have a local address and local payment method.

Timezone vs IP country

A common VPN heuristic compares the browser’s timezone with the IP’s country. A mismatch suggests the network location is being hidden. For a satellite user exiting abroad, the timezone is honestly local and the IP country isn’t. The heuristic fires on someone who isn’t hiding anything.

In Prynt, that check is one of several methods behind the vpn Smart Signal, and the event says which methods fired:

"vpn": {
  "result": true,
  "methods": ["timezoneCountryMismatch"],
  "timezoneCountry": "AR",
  "ipCountry": "CL"
}

A vpn result supported only by timezoneCountryMismatch is far weaker evidence than one backed by vpnProvider (a known commercial VPN range) or datacenterIP. Your rules should treat them differently.

Impossible travel

Prynt’s risk engine flags impossibleTravel when one device shows more than one IP country within an hour, ignoring unknown countries. That’s a strong signal on fixed broadband, where it usually means a proxy or a hijacked session. A satellite user can produce it by switching from the dish to mobile data, or by moving between exit points near a border. Impossible travel detection covers the general tuning. Satellite networks are where the exceptions cluster.

Adjusting the rules

1. Know when the network is satellite

The event’s IP context includes the ASN and its organization:

const event = await prynt.getEvent(requestId);
const loc = event.smartSignals?.ipLocation || {};
// loc.country, loc.city, loc.asn, loc.asnOrg, loc.asnType, loc.timezone

const SATELLITE_ASNS = new Set([/* maintain your own list, e.g. the Starlink ASN */]);
const onSatellite = SATELLITE_ASNS.has(loc.asn) || /starlink|spacex/i.test(loc.asnOrg || '');

Keep the list in config rather than code. Satellite providers are few, but your users’ mix will change.

2. Downweight location-only evidence on satellite

const vpn = event.smartSignals?.vpn;
const locationOnlyVpn =
  vpn?.result && vpn.methods?.length === 1 && vpn.methods[0] === 'timezoneCountryMismatch';

if (onSatellite && locationOnlyVpn) {
  // don't count this as a VPN; record it for analytics instead
}

Do the same for impossible travel. On a satellite network, an IP country change within the hour is a reason to look at the other signals, not a block by itself.

3. Check market eligibility against more than the IP

For “are you in our market?” questions, use evidence the network path doesn’t distort: billing address, phone country, document country, the browser timezone and locale. The IP country becomes one vote among several. That alone fixes most rural false positives.

4. Keep the device signals at full weight

None of this weakens the signals that don’t depend on IP location. A satellite connection doesn’t excuse a headless browser, a tampered environment, a virtual machine or a device that has already opened several accounts. Those stay at full strength:

const strong =
  event.decision === 'block' ||
  event.smartSignals?.bot?.result ||
  event.smartSignals?.tampering?.result ||
  event.accountsOnDevice?.count >= 2;

That’s the right trade. You stop penalizing an honest rural customer for their network path, and an abuser who happens to use satellite internet still meets the same device-level rules as everyone else.

Encoding it in console rules

If you manage policy in the Prynt console rules engine, express the same idea with rule priority. Put a rule on country lower than your device rules, and only add country-based challenges where you’ve confirmed the false-positive rate is acceptable for your customer base. Rules can also key on asnType, which separates hosting and datacenter networks from consumer ISPs. That’s a much stronger signal than country for spotting automation. VPN and proxy detection describes the network signals available.

Measure before and after

Before changing anything, pull a month of challenged or blocked events and split them by ASN. If the satellite share of your challenges is far higher than its share of your traffic, your rules are taxing rural users. After the change, watch two numbers: challenge rate on satellite ASNs, which should fall, and confirmed fraud from satellite ASNs, which shouldn’t rise.

Wrap-up

Treat a satellite IP’s location as approximate, its country as one vote and a satellite network as a context flag rather than a risk score. Keep the device signals at full weight. That way a customer in a rural town isn’t flagged as a fraudster because of where their traffic exits.