What device and IP signals can and cannot tell you

Device and IP signals tell you about the handset and the network connection, not about the person holding the phone. A few of them are strong warnings: an app running in an emulator, or a sign-up from a cloud hosting provider. Most are weak on their own: a phone shared by several people, many sign-ups from one IP address, or a location derived from an IP address.

So weight them as corroboration. Let the strong ones send a case to review, let the weak ones add to a score, and never let an IP address stand in for where someone lives. On mobile networks in particular, IP location is trustworthy at country level and not much finer.

Why are IP addresses such weak evidence of a person?

Because on many networks, one public IP address is used by many customers at once.

IPv4 addresses are scarce; RFC 6598 described the address space as "nearly exhausted" in 2012. The standard answer for operators is Carrier-Grade NAT (CGN): the operator gives each subscriber a private address and translates their traffic through a shared public address inside its own network. RFC 6888 (opens in a new tab), published in April 2013, describes a CGN as a function "used to share the same IPv4 address among several subscribers", placed in the operator's network and translating "the traffic of potentially many subscribers". RFC 6598 (opens in a new tab), published in April 2012, reserved an address block, 100.64.0.0/10, specifically to number the links between CGN devices and customers' equipment.

RFC 6888 also explains why the public address alone cannot identify anyone: to find the subscriber behind a shared address, the operator needs its own logs of the translated address, port and time. You do not have those logs. You have one address that many strangers are using at the same moment.

That has three consequences for fraud rules:

• IP velocity is noisy. Twenty sign-ups from one address in an hour might be a fraud farm, or twenty customers on the same mobile operator in the same region.

• Shared IP is not a relationship. Two customers on the same public IP may never have met.

• IP location describes the gateway. Location databases map the public address, which sits where the operator's gateway sits. A customer can appear to be in a different city for every session, with nothing wrong.

What each signal can and cannot tell you

Read the table as two groups. The top rows describe how the session was produced, which a genuine customer rarely changes. The lower rows describe ordinary life, which changes all the time.

How should you combine device and IP signals?

Follow three rules.

1. Never decide on one weak signal. A shared device or a foreign IP alone should not decline anyone.

2. Let strong signals route to people, not to automatic declines. An emulator or datacentre IP is a reason to look, and sometimes a developer testing your app.

3. Stack weak signals with identity evidence. A shared device plus a face match to another account plus a burst from one IP is a pattern. Any one of them is not.

An illustrative example: a lending app sees a loan application where the device has been used by four other verified borrowers this month, the IP belongs to a hosting provider, and the applicant claims to be in Kenya while the IP country is elsewhere. Each is explainable. Together they describe a pattern worth a closer look, and the right response is review before disbursement, not an automatic decline and not an automatic approval.

What about location evidence the customer gives you?

Location that comes from the customer's own device, such as a GPS pin they drop on a map, is a different kind of evidence from an IP lookup. It is still a claim, and it can be spoofed, but it describes the person's handset rather than their operator's network. Treat it as its own signal, and do not merge it with IP location in a way that lends the IP the pin's precision.

How Myaza Trust handles device and IP signals

Device Intelligence, the device and IP analysis in Myaza Trust workflows, is on by default. It looks for device reuse across people, emulator signs, datacentre IPs and IP velocity, and makes them available to decision rules as device.matchedEntities, device.emulator, ip.country, ip.type, ip.datacenter, ip.countryMismatch and ip.velocity1h (decisioning fields). These signals feed your decision; they never change the verification's own pass or fail result.

We deliberately report IP location at country level only. Mobile carriers route many subscribers through shared gateways, so a city derived from an IP address describes the gateway, not the person, and presenting it as if it were precise would mislead reviewers.

A device used by more than one person is not treated as fraud by itself; a shared-device finding recommends review and never blocks an account on its own (verification device findings). The workflow template library includes a device and IP fraud guard that routes multi-accounting, emulator and bot signals to review, which is a reasonable starting point to tune.

Before you write your next rule

1. Sort every device and IP signal you use into "how the session was produced" and "ordinary life".

2. Remove any rule that declines on a single weak signal.

3. Replace IP-city rules with country-level checks, or remove them.

4. Set shared-device thresholds as a count of other verified people, and raise them for low-risk products.

5. Check a sample of reviewed cases each month to see which signals actually predicted fraud in your customer base.