Mobile number portability: why carrier lookups can be wrong

A carrier lookup can be wrong because a phone number's digits describe the network its range was allocated to, not the network that serves it today. When a subscriber keeps their number and switches operator, which regulators in most competitive markets guarantee, every prefix-based guess about that number becomes outdated. Reliable answers need current data about the specific number.

#Why doesn't the prefix tell you the network any more?

Numbering plans hand out numbers in blocks. A regulator gives an operator a range, and for years the first digits of a mobile number really did identify the network. Many systems still work that way: a table maps prefixes to operators, and the table is right as long as nobody moves.

Mobile number portability (MNP) broke that link on purpose. It lets a subscriber take their number to a competitor, so that changing operator no longer means changing number. After the move, the number stays in the old operator's block, but calls and texts must go to the new one.

The prefix table doesn't know. It still says "Operator A" for a number now on Operator B. Even open-source numbering libraries document this. Google's libphonenumber ships a carrier mapper that returns the original range holder, not the current network (Google, 2026). That is the right answer to a different question.

#How common is porting, and where does it apply?

Portability is a regulatory obligation in the markets most businesses message:

Outside these, most countries with competitive mobile markets offer MNP in some form, but the mechanics differ. Some run one central database that every operator queries. Others leave the number with its original operator, which forwards traffic onward. The practical point is the same everywhere: after two decades of porting, you should assume any given number may have moved, and in the US it may also have changed line type.

#How do networks find a ported number?

Networks need to route calls and texts correctly, so they keep track of ports. The common designs:

• Central database. A national database lists every ported number and its current network. Operators query it or keep a synchronized copy.
• Distributed copies. Each operator keeps its own list, updated by messages from the others.
• Onward routing. Traffic goes to the original range holder first, which knows where the number went and passes it on.

Commercial lookups read the result of these processes in one of two ways. A database lookup reads porting data, directly where licences allow or from a regularly refreshed replica. A live network query (an HLR lookup) asks the number's home register, whose reply shows the network that holds the subscription as an MCC/MNC code, the network identity defined in ITU-T E.212 (ITU). The comparison is in HLR vs MNP vs number validation.

#In what ways can a carrier lookup be wrong?

Even with current data, several things produce a wrong or confusing carrier:

None of these mean the data is useless. They mean the carrier field is a fact with a timestamp, not a permanent property of the number.

#Why does a wrong carrier matter?

Three kinds of cost follow from a carrier error:

• Routing and pricing. Some messaging routes and wholesale rates are set per destination network. Routing a ported number by its prefix can send traffic down a more expensive or less reliable path.
• Wrong line-type assumptions. Where numbers move between services, as in the US, a range-based "fixed line" might now be a mobile, and a range-based "mobile" might now be VoIP. Filtering SMS by range type drops good numbers and keeps bad ones. See line type.
• Missed fraud signals. In a port-out scam, a criminal moves a victim's number to a SIM they control and then receives the victim's one-time passcodes. NIST's 2025 authentication guidelines list number porting, next to SIM change and device swap, among the risk indicators a verifier should consider before sending a code by phone (NIST, 2025).

The last point is why you shouldn't treat porting as noise to filter out. A port is ordinary, but a port right before an account-recovery attempt is exactly the pattern to catch.

#How do you detect a ported number with MobileValidate?

The carrier lookup returns carrier, the network serving the number as far as our data shows, and original_carrier, the network its range was allocated to. original_carrier appears only when it differs, so its presence is the porting signal. It covers all countries in real time or bulk and is labelled beta because coverage varies by country; a number we hold no data for returns unknown with reason NO_DATA and is free.

For US and Canadian numbers, the US/CA carrier lookup returns line_type and the current carrier in bulk jobs. This matters there because numbers move between landline, wireless and VoIP.

A real test-mode job with network.carrier_us (excerpt of one result row):

{"e164": "+12025550143", "country": "US",
 "checks": {"network.carrier_us": {"status": "completed", "registered": true,
   "attributes": {"line_type": "mobile", "carrier": "Test Carrier"},
   "checked_at": "2026-09-25T16:14:46.219Z", "billed": false, "reason": null}}}

Test data never includes a port. Live answers add original_carrier to network.carrier results when the number moved. The HLR lookup, coming soon, will add a live ported flag and the current network's mcc_mnc.

#How should your code handle porting?

Treat the carrier as time-stamped data and compare it with what you saw before. A minimal pattern in TypeScript:

type Carrier = { carrier?: string; original_carrier?: string; line_type?: string };

function portingSignals(now: Carrier, checkedAt: string, previous?: Carrier & { checkedAt: string }) {
  return {
    ported: Boolean(now.original_carrier),          // present only when it differs from carrier
    carrierChanged: previous ? previous.carrier !== now.carrier : false,
    lineTypeChanged: previous ? previous.line_type !== now.line_type : false,
    checkedAt,
  };
}

Then act on the signals in context:

Store checked_at with every stored carrier. A carrier seen a year ago is a hint; one seen today is evidence.

#How often should you refresh carrier data?

It depends on what you use it for:

• Routing live traffic: look up at send time, or cache for a short window. Our account cache serves repeat checks of the same number inside the freshness window for free; max_age: 0 forces a fresh, billed check.
• Account security: check when contact details change and before sensitive actions, then compare with the stored value.
• Lists and CRM hygiene: refresh in a bulk job before each campaign to consented contacts, or on a schedule such as quarterly. See cleaning a phone list in bulk.

You're not charged for inconclusive results (unknown, unsupported country, timeout, invalid, duplicate). See pricing.

#What are the key takeaways?

• A prefix identifies the network a range was allocated to. After a port, it names the wrong network.
• Portability is a legal right in the US (since 2003–2004), Canada (since 2007) and the EU (activation within one working day), and exists in most other competitive markets.
• Carrier data can still lag, hide MVNOs or show old brand names. Treat it as a timestamped fact.
• Route and price by current network; use a change of carrier as context, especially right before account recovery.
• In MobileValidate, original_carrier in the carrier lookup marks a port; the US/CA lookup covers North America in bulk; a live ported flag arrives with the HLR lookup.