> For the complete documentation index, see [llms.txt](https://docs.idlayr.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.idlayr.com/enterprise-portal/verification-logs/sim-swap.md).

# SIM Swap logs

{% hint style="warning" %}
This is **work in progress,** the page is not available in the portal yet
{% endhint %}

The SIM Swap logs view lists every SIM Swap check made by your project, newest first. Click any row to drill into a specific check.

For background on what SIM Swap is and how it answers "has this phone number's SIM recently changed?", see the [SIM Swap product page](/products/risk/sim-swap.md).

## What you see in the list

Each row represents a single check. The columns typically include:

| Column            | What it shows                                                                                              |
| ----------------- | ---------------------------------------------------------------------------------------------------------- |
| **Check ID**      | The `check_id` returned on the check.                                                                      |
| **Phone number**  | The MSISDN that the check was made against.                                                                |
| **Status**        | `COMPLETED` or `ERROR`. SIM Swap is synchronous — there's no `ACCEPTED` in-flight state and no `EXPIRED`.  |
| **No SIM change** | `true` / `false` — the result. `true` means the SIM hasn't changed within the operator's reporting window. |
| **Created at**    | When the check was made.                                                                                   |

## Filters

* **Search by phone number** — finds every SIM Swap check for a specific MSISDN.
* **Filter by status** — narrow to `COMPLETED` or `ERROR`.
* **Filter by date range.**
* **Filter by `no_sim_change`** — pure clean signals vs. SIM-changed signals vs. errors.

## Drilling into a check

Clicking a row opens the check's detail view, which typically includes:

* **The original request** — MSISDN, `reference_id` (if you supplied one).
* **The synchronous response** — `status`, `no_sim_change`, and any `error_code` if the check ended in `ERROR`.
* **Network context** — the resolved MNO and country.
* **HTTP-response metadata** — exact response code and the `error_code` if one was returned.

See [SIM Swap error codes](/products/risk/sim-swap/error-codes.md) for what each `error_code` means.

## Common investigations

**A user reports their high-value transaction was blocked.** Search their phone number. Find the SIM Swap check made at the moment of the transaction. If `no_sim_change` was `false`, the SIM did change within the operator's reporting window — your risk policy correctly blocked. If the check ended in `ERROR`, your fallback path triggered; check the `error_code` for the cause.

**SIM Swap calls are returning `ERROR` more than expected.** Filter to `status: ERROR` over the period in question. Look at the distribution of `error_code` values:

* A spike of `mno_timeout` typically reflects a transient MNO-side issue. Check the [status page](https://gitlab.com/4auth/product-documentation/-/blob/main/help/status.md).
* A spike of `mno_user_not_found` may indicate the number population you're checking has drifted (porting, MVNO subscriber lookup, etc.).
* A spike of `mno_not_supported` indicates a coverage gap — pre-check with [Eligibility](/products/eligibility.md) to avoid these calls in the first place.

**Differentiating "couldn't determine" from "SIM changed".** A `status: ERROR` is **not** the same as `no_sim_change: false`. The first means IDlayr couldn't determine the state; the second means we determined the state and a change happened within the window. Your risk policy should treat them differently — see the SIM Swap product page for the recommended decision tree.

## Retention

Production checks are retained for the period specified in your IDlayr Trust Center attestations — see [Compliance & Security](https://gitlab.com/4auth/product-documentation/-/blob/main/help/compliance-and-security.md). Sandbox `ERROR` checks are **not persisted** and won't appear in this view.

## What's next

* [**SIM Swap product page**](/products/risk/sim-swap.md) — background, decision tree, and integration patterns.
* [**SIM Swap error codes**](/products/risk/sim-swap/error-codes.md) — what each terminal `error_code` means.
* [**Verification logs hub**](/enterprise-portal/verification-logs.md) — links to logs for the other products.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.idlayr.com/enterprise-portal/verification-logs/sim-swap.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.