# SIM swap fraud: the signals to check before you trust an SMS code

> What a SIM swap is, which SIM-swap data exists and who can get it, and which signals to combine before you trust an SMS code when that data is missing.

Canonical: https://mobilevalidate.com/blog/sim-swap-fraud-signals · Last updated: 2026-09-25

![Cover: SIM swap fraud: the signals to check before you trust an SMS code](https://mobilevalidate.com/og/blog/sim-swap-fraud-signals.png)


By MobileValidate team (https://mobilevalidate.com/about) · Published: 2026-09-25 · Category: Fraud prevention · Tags: Sim swap, Account takeover, OTP, Fraud prevention, Porting

A SIM swap moves a phone number to a new SIM, so every SMS code for that number goes to whoever holds the new SIM. Direct SIM-change data comes only from operators and covers some countries. Where you can't get it, combine device, account and number signals, and step up to a factor that doesn't depend on the phone network.

## What is a SIM swap, and why does it break SMS codes?

A SIM swap is the transfer of a phone number from one SIM card or eSIM profile to another. Operators do it every day for customers who lose or replace a phone. In SIM swap fraud, a criminal gets the operator to move the victim's number to a SIM the criminal controls. Our [SIM swap glossary entry](/glossary/sim-swap) has the short definition.

The FBI describes three ways criminals do it: social engineering (impersonating the victim to the carrier), paying off an insider, and phishing carrier employees to plant malware. "Once the SIM is swapped, the victim's calls, texts, and other data are diverted to the criminal's device," the FBI wrote, and the criminal can then request password resets that arrive by SMS ([FBI IC3, 2022](https://www.ic3.gov/PSA/2022/PSA220208)).

That is why a swap defeats SMS one-time passcodes. The code is delivered correctly. It just arrives on the wrong phone. Nothing in the message, the delivery receipt or the code itself tells your app that the recipient changed.

## How is a SIM swap different from a port-out?

Both attacks move the number away from the victim. They differ in where it goes, and that decides which data can spot them.

| | SIM swap | Port-out |
|---|---|---|
| What changes | The SIM or eSIM behind the number | The operator that serves the number |
| Carrier reported by a lookup | Unchanged | Changes to the new operator |
| Who can see it | The operator (SIM-change records) | Anyone with current porting data |
| Typical attacker route | Carrier store or support desk | A porting request to another operator |
| Signal you can buy widely | SIM-change date, only where operators expose it | Current carrier and porting status |

In the US, the FCC adopted rules in November 2023 that require wireless providers to use secure methods to authenticate a customer before moving their number to a new device or provider, and to notify customers of SIM-change and port-out requests ([FCC, 2023](https://www.federalregister.gov/documents/2023/12/08/2023-26338/protecting-consumers-from-sim-swap-and-port-out-fraud)). The rules took effect in January 2024, with some parts delayed. Check the FCC's current status before relying on a specific requirement. Carrier-side protections reduce the risk. They don't remove it, so your own flow still needs defences.

## How big is the problem?

Public figures are few, and the best-known ones are dated. The FBI's Internet Crime Complaint Center received 320 SIM-swapping complaints with adjusted losses of about $12 million from January 2018 to December 2020. In 2021 alone it received 1,611 complaints with adjusted losses of more than $68 million ([FBI IC3, 2022](https://www.ic3.gov/PSA/2022/PSA220208)). Those are reported US cases only.

In Europe, ENISA published a study in December 2021 on how SIM-swapping attacks work and which measures operators can take against them ([ENISA, 2021](https://www.enisa.europa.eu/publications/countering-sim-swapping)).

Standards bodies treat the risk as structural. NIST's current authentication guidance classes one-time codes over the phone network as a **restricted** authenticator. It says verifiers "SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN to deliver an out-of-band authentication secret" ([NIST, 2025](https://csrc.nist.gov/pubs/sp/800/63/b/4/final)). The rest of this guide is about gathering those indicators.

## Which SIM-swap data exists, and who can get it?

SIM-change data lives with the operator. Getting it means going through an API that the operator exposes, directly or through a partner.

The main open specification is **CAMARA SimSwap**, maintained under the Linux Foundation and used by GSMA Open Gateway operators. Its latest public release, r3.3 (December 2025), defines two operations: `check`, which says whether the SIM was swapped within a period you give (`maxAge`, between 1 and 2,400 hours in the spec), and `retrieve-date`, which returns the latest SIM change. The spec also lets operators return `null` when local rules stop them keeping the date that long, optionally with the period they do monitor ([CAMARA, 2025](https://github.com/camaraproject/SimSwap)).

| Source | What it tells you | Coverage | Practical limits |
|---|---|---|---|
| Operator APIs following CAMARA SimSwap | Swapped within N hours, or the latest change date | Operators and countries that have launched it | Contracts per operator or aggregator; monitoring windows vary with local rules |
| Communications platforms that resell operator data | The same facts through one API | Usually a short list of countries, sometimes in beta | Check each country and the consent model |
| Your own records | A new device, a new number on the account, a reset request | Every user | Doesn't see what happens at the operator |
| Number intelligence (carrier, porting, line type) | Carrier and porting changes, line-type changes | Wide | Can't see a SIM change within the same operator |

The honest summary: if your users sit in countries where operators expose SIM-change data, buy it for your high-risk flows. Everywhere else, you are combining indirect signals.

## Does MobileValidate sell SIM-swap data?

No. We don't offer SIM-change dates, and we don't claim that any of our checks detects a SIM swap. Here is what we do provide and what each one can and can't tell you:

| Check (alias) | What it tells you | Helps against | Doesn't tell you |
|---|---|---|---|
| Carrier lookup (`carrier`) | `line_type`, current `carrier`, `country`, and `original_carrier` when it differs | Port-outs (compare with your last snapshot); VoIP or unexpected line types | A SIM change at the same operator |
| Messenger checks (`whatsapp`, `telegram`, `viber`) | Whether the number has an account | Choosing a non-SMS code channel the user already has | Whether the SIM changed; accounts usually survive a swap |
| Spam reputation (`spam`) | Report-based risk level, US, CA and DE, limited access | Numbers with regulator actions or fraud reports | Anything about the SIM |
| Live network status (`hlr`) | Reachable, `ported`, roaming (true or false) | Port detection from the network itself | Coming soon. It will never return the IMSI or other SIM identifiers |

That last line matters. SIM-change detection at the network level relies on subscriber identifiers such as the IMSI. We never expose them, by design. See the [account security use case](/use-cases/account-security) for how these checks fit a login and recovery flow.

## Which signals should you combine when SIM-swap data is missing?

Score the moment, not the number alone. Most attacks show several of these at once:

| Signal | Where it comes from | Why it matters |
|---|---|---|
| New or unknown device | Your session data | A swap is usually followed by a login from the attacker's device |
| Password or recovery reset requested by SMS | Your auth logs | The typical first move after a swap |
| Phone number changed on the account recently | Your account history | Attackers swap the number, then the recovery settings |
| Carrier differs from your last stored snapshot | Carrier lookup vs your records | Points to a port-out since the last check |
| `original_carrier` differs from `carrier` | Carrier lookup | The number was ported at some point. Normal on its own |
| Line type changed to `voip` | Carrier lookup | The number moved to an internet service |
| Country of the IP differs from the number and the account | Your session data plus `country` | Weak alone, strong combined |
| Large transfer, payout or contact change right after login | Your transaction data | The attacker's goal |

The strongest pattern is **timing**: an SMS-based reset, a new device and a high-value action within a short window. Each alone is common among real users.

## How do you compare carrier snapshots in code?

Store the carrier facts when the user first verifies the number, then compare before a sensitive action. A test-mode request:

```bash
curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["+447700900001"], "checks": ["carrier", "whatsapp"], "max_age": 3600, "wait": 5}'
```

Response (excerpt of `results[0].checks`, test mode):

```json
{
  "network.carrier": {"status": "completed", "registered": true,
    "attributes": {"line_type": "mobile", "carrier": "Test Carrier", "country": "GB"},
    "checked_at": "2026-09-25T19:03:29.021Z", "billed": false, "reason": null},
  "whatsapp.registered": {"status": "completed", "registered": true, "billed": false, "reason": null}
}
```

`max_age: 3600` accepts a cached answer up to an hour old, which is free. Then a small function turns the comparison into a signal:

```js
// stored = what you saved at enrolment; r = results[0] from the lookup.
function numberChangeSignals(stored, r) {
  const c = r.checks?.["network.carrier"];
  if (c?.status !== "completed") return [];          // unknown or pending: no evidence either way
  const a = c.attributes;
  const out = [];
  if (stored.carrier && a.carrier && a.carrier !== stored.carrier) out.push("carrier_changed");
  if (a.original_carrier && a.original_carrier !== a.carrier) out.push("ported_at_some_point");
  if (stored.line_type === "mobile" && a.line_type === "voip") out.push("now_voip");
  return out;
}
```

A carrier change is evidence of a port since your last snapshot, not proof of fraud. People switch operators all the time. Feed the result into the same score as your device and session signals.

## What should a step-up look like?

Decide in advance what each risk level triggers, so support staff can explain it to a real customer:

| Situation | Suggested action |
|---|---|
| No risk signals | Send the SMS code as usual |
| One weak signal (new device only) | Send the code; notify the user by e-mail or push |
| SMS reset + new device | Require a second factor that isn't SMS: passkey, authenticator app or e-mail link |
| SMS reset + carrier changed since the last snapshot | Step up, and hold payouts or contact changes for a cooling-off period |
| Any of the above + high-value action | Manual review or a verified call-back to a number you had before the change |
| Carrier data `unknown` | Treat as no evidence. Use your other signals |

NIST also requires services that accept a restricted authenticator to offer at least one alternative that isn't restricted ([NIST, 2025](https://csrc.nist.gov/pubs/sp/800/63/b/4/final)). Offering passkeys or an authenticator app to every user is the most durable fix, because it takes the phone network out of the login path.

## What else should you tell users?

Part of the defence sits with the customer and their operator. The FBI advises people not to post their phone number or financial assets online, to "be aware of any changes in SMS-based connectivity", and to use strong factors such as physical security tokens or standalone authentication apps. It asks carriers to set strict protocols for verifying customers before moving a number to a new device ([FBI IC3, 2022](https://www.ic3.gov/PSA/2022/PSA220208)). Useful prompts in your product:

- Suggest a passkey or authenticator app at the second login.
- Explain that many operators offer account PINs or port-out protection, and link to your help page on it.
- Tell users that sudden loss of mobile signal, with no explanation, is a reason to contact their operator straight away.

Keep the lookups proportional. Check the numbers of your own users, for the security purpose you told them about, and store only the facts you compare against. The [acceptable use policy](/legal/acceptable-use) applies, and people can object through the [opt-out form](/opt-out).

## What are the key takeaways?

- A SIM swap moves a number to a new SIM, so SMS codes reach the attacker without any visible error.
- SIM-change data comes from operators (for example through CAMARA SimSwap) and covers only some countries. Buy it where it exists for your high-risk flows.
- MobileValidate doesn't sell SIM-swap data. Our carrier lookup shows porting hints and line type, and the HLR lookup is coming soon. Neither sees a SIM change at the same operator.
- Where SIM-swap data is missing, combine device, account-history and number signals, and weight their timing.
- Step up to passkeys, authenticator apps or e-mail when signals line up, and offer non-SMS factors to everyone.

For the number facts behind porting, read [why carrier lookups can be wrong after porting](/blog/mobile-number-portability-why-carrier-lookups-can-be-wrong). The pre-send checks for every code are in [OTP fraud prevention: checks to run before sending a code](/blog/otp-fraud-prevention-checks-before-sending-a-code).

## Sources

1. [Criminals Increasing SIM Swap Schemes to Steal Millions of Dollars from US Public (I-020822-PSA)](https://www.ic3.gov/PSA/2022/PSA220208) — FBI Internet Crime Complaint Center, 2022
2. [Protecting Consumers From SIM-Swap and Port-Out Fraud (Report and Order)](https://www.federalregister.gov/documents/2023/12/08/2023-26338/protecting-consumers-from-sim-swap-and-port-out-fraud) — Federal Communications Commission, Federal Register, 2023
3. [Countering SIM-Swapping](https://www.enisa.europa.eu/publications/countering-sim-swapping) — ENISA, 2021
4. [CAMARA SimSwap API (release r3.3)](https://github.com/camaraproject/SimSwap) — CAMARA Project (Linux Foundation), 2025
5. [NIST SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management](https://csrc.nist.gov/pubs/sp/800/63/b/4/final) — NIST, 2025

## Frequently asked questions

### Does MobileValidate offer a SIM swap check?

No. We don't sell SIM-change dates. We provide related signals: line type, current and original carrier (a porting hint), messenger presence and, in limited access for US, Canadian and German numbers, spam reputation. A live network status check (HLR) is coming soon.

### What is the difference between a SIM swap and a port-out?

A SIM swap moves the number to a new SIM or eSIM at the same operator. A port-out moves the number to a different operator. Both hand the number to whoever controls the new SIM, but only a port-out changes the carrier a lookup reports.

### Can a messenger check detect a SIM swap?

No. A messenger account usually stays registered to the number after a swap, so presence neither confirms nor rules out a swap. It is useful for other things, such as offering a code channel the user already has.

### What should we do when no SIM-swap API covers a country?

Combine what you do know: device and session changes, a recent number change on the account, a carrier or porting change compared with your last snapshot, and the value of the action. Step up to a factor that doesn't depend on the phone network when several signals line up.