> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/identity-verification/fraud-prevention/ip-geolocation.md).

# IP Geolocation

Assess risk from a user's IP address — approximate location, network type, and anonymizer use — to detect location spoofing, high-risk geographies, and suspicious access patterns.

***

### Overview

IP geolocation derives an approximate physical location and network profile from the IP address a user connects from. During onboarding or authentication, it provides immediate context about *where* and *how* a user is connecting — without asking them for anything.

{% hint style="info" %}
IP geolocation is an estimate, not a precise position. Accuracy is typically strong at the country level and decreases for region and city. Treat it as a risk signal, not a definitive location. 
{% endhint %}

### What the check analyzes

When a user connects, the IP address is evaluated for attributes such as:

* **Geographic location** — Country, region, and city associated with the IP.
* **Network and ownership** — The internet service provider (ISP) and the autonomous system (ASN) that owns the address space.
* **Connection type** — Whether the IP belongs to a residential network, a mobile carrier, or a hosting/datacenter provider.
* **Anonymizer use** — Whether the connection is routed through a VPN, proxy, or the Tor network.

### Risk signals it surfaces

| Signal                            | What it may indicate                                                                               |
| --------------------------------- | -------------------------------------------------------------------------------------------------- |
| Connection via VPN, proxy, or Tor | The user may be hiding or misrepresenting their true location.                                     |
| Datacenter or hosting-provider IP | Traffic may be automated (bots/scripts) rather than a real person on a consumer device.            |
| Location mismatch                 | The IP country conflicts with the document country, phone country, or stated address.              |
| High-risk or sanctioned geography | The connection originates from a region the organization restricts or watches closely.             |
| Impossible travel                 | The same account connects from distant locations in a span of time too short to physically travel. |

### Benefits and use cases

* **Onboarding fraud detection** — Flag applicants who mask their location or connect from infrastructure rather than a personal device, a common pattern in synthetic-identity and bulk-account fraud.
* **Account-takeover (ATO) prevention** — Detect logins from unexpected countries or anonymizing networks and trigger step-up authentication.
* **Geographic and regulatory controls** — Restrict access from embargoed or out-of-scope regions to support compliance obligations.
* **Reducing friction for genuine users** — A consistent, residential IP that matches the rest of the identity can support a faster, lower-friction path.
* **Promotion and bonus-abuse prevention** — Identify many accounts originating from the same network or anonymizer, a hallmark of incentive abuse.

### Where it fits in the journey

Because it requires no user input, IP geolocation is well suited to running **at the very start of a journey** as a pre-check, and **continuously at each authentication** to watch for changes in connection behavior over time.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.1kosmos.com/identity-verification/fraud-prevention/ip-geolocation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.