Number portability detection: three regimes, three answers
Number portability detection: three regimes, three answers
Number portability is the regulatory commitment that a mobile subscriber can change operators while keeping their phone number. The subscriber gets continuity, the losing operator loses the customer, and the gaining operator picks up a number range it did not originally hold. Every regulator that has implemented portability (which is most of them) has done it with some variation on the same set of technical mechanics: an authoritative database of which MSISDN currently routes to which operator, with either all-call-query routing via that database or onward routing through the number's original operator.
From the outside, portability looks simple: a switch happens, the same number works on a new network, done. From inside a number-intelligence API that has to answer "which operator serves this MSISDN right now?" the complexity is real. Different regimes produce different signals, with different latency, for different prices, and an API that flattens the variance hides the cases where the answer is less reliable than it looks. This post describes the detection paths (signalling-based, database-based, aggregator-heuristic), explains why they produce different answers, and frames portability as a fraud signal alongside SIM swap.
The three detection paths
Three detection approaches produce different fidelity for the same underlying question.
Signalling-based detection: a MAP SRI-for-SM query against the MSISDN's number-range-owner HLR returns routing information. In a non-ported scenario, the response comes from the expected operator. In a ported scenario, the response carries either a redirect to the current serving operator or a routing prefix indicating the port. The signal is that the IMSI returned belongs to a PLMN that does not match the MSISDN's allocated range. This works but depends on the originating signalling reaching the number-range-owner HLR. In some regimes the number-portability database (NPDB) intercepts the routing query before it reaches the donor operator.
Database-based detection: the number-portability database is the authoritative record. In regimes that operate a centralised NPDB (most European jurisdictions, most of the GCC), a direct query to the NPDB returns the current serving operator with high fidelity and low latency. In regimes without a centralised NPDB, or where access is regulated to incumbent operators only, external parties cannot query directly and must fall back to signalling-based detection or aggregator-heuristic approaches.
Aggregator-heuristic detection: a commercial aggregator maintains its own observation of traffic patterns and infers portability from the cross-operator distribution of successful-delivery paths for a given MSISDN. This approach has meaningful coverage but variable latency, since the aggregator's data is updated as its own probe traffic encounters ported numbers. Published work on porting-behaviour research notes that this class of inference is consistently lower-fidelity than authoritative-database or signalling-based approaches.
The three paths produce different answers for the same MSISDN in several recurring cases. A number ported yesterday may show as ported to one operator via signalling, correctly, but as still registered to its allocation operator via aggregator-heuristic detection that has not yet observed traffic on the new network. A number in a regime with an NPDB but restricted external access may return "unknown" via external signalling and "ported" via an aggregator's inference of a carrier-change signal.
Why the regime matters
The practical differences across regimes are substantial.
ACQ-with-NPDB regimes (most of Europe, UAE, Saudi Arabia, South Africa) have centralised NPDBs that all operators must query before routing. The NPDB is the source of truth. External number-intelligence APIs in these regimes, if they can query the NPDB directly or via a gateway, produce authoritative responses. Latency is low, freshness is near-real-time, and ambiguity is minimal.
Onward-routing regimes (parts of Asia, some African markets) route all traffic to the number's allocation operator, which then onward-routes to the current serving operator. The signalling-based detection path works but with higher latency, with the signal being the allocation operator's response carrying a forwarded routing indicator. External query consistency depends on the allocation operator's support for the third-party query.
Mixed regimes (some African markets with partial portability implementations, Southeast Asian markets with recent regulator launches) have incomplete or unstable NPDBs. Portability exists in regulation but the detection infrastructure is immature. Aggregator-heuristic detection is often the only available external path, with the fidelity limits described above.
For a number-intelligence API claiming global coverage, the response shape that holds up to scrutiny includes the regime and the detection path used, not just the answer. A claim like "this number is ported to Carrier X" means different things depending on whether the answer came from an NPDB query, a signalling probe, or an aggregator inference.
Portability as a fraud signal
The fraud-relevance of portability is not universally appreciated. Porting and SIM-swapping are operationally fungible for attackers. Both are legitimate user-initiated operations that change the subscriber's binding, produce a timestamp of recent change, and can be socially engineered through the operator's customer-service channel.
An attacker executing account takeover has three plausible paths against a phone-verified account: swap the SIM, port the number, or compromise the device. The first two are related primitives. Published fieldwork on mobile-based fraud in Pakistan documents port-and-takeover flows alongside swap-and-takeover flows, with similar outcomes and similar defensive requirements. Legal literature on SIM-swap countermeasures explicitly includes porting in the threat model.
For an authentication or fraud-detection flow, the MNP-recency signal belongs in the same signal family as SIM-swap recency. A risk model that queries SIM swap but not MNP has a coverage gap that attackers can exploit by routing their attack through porting rather than swapping.
Header enrichment and the port-fraud timing window
An operator-side mitigation against both port and swap fraud is header-enrichment MSISDN match. In the header-enrichment pattern, the mobile network inserts a verified MSISDN header into HTTP requests from the device on cellular data sessions. The relying party compares the header MSISDN against the MSISDN the user presents. If they match, the device is demonstrably on the network that serves the presented MSISDN. If they do not, something is off.
Published work has applied this pattern to account-takeover prevention in financial mobile applications with measurable effect. The core insight is that header enrichment catches port-and-swap attackers who have captured the MSISDN but are using it on a device that is not the subscriber's. The header reveals the device's actual MSISDN, which differs from the captured one.
This is the same primitive as silent network authentication, and the port-fraud mitigation is a specific instance of the broader silent-auth value proposition. Where silent auth is available and integrated, the port-fraud case is already handled. For applications without silent auth in the stack, header enrichment via the cellular data session offers similar fraud-mitigation properties.
Published porting-behaviour research has documented the timing shape of port-related fraud. Attackers tend to execute the fraud within a relatively short window after the port completes, before the subscriber notices the service interruption and contacts the original operator. The specific window varies by jurisdiction and by operator but typically concentrates in the first 24 to 72 hours.
This timing shape has operational consequences. A fraud model that queries MNP recency and treats any port in the past 90 days as a flag will generate high false-positive volume because most legitimate ports sit in that window without any subsequent attack. A model that narrows the flag to the 24-to-72-hour window, applied conditionally to accounts attempting high-value transactions, captures most of the port-related attacks with a manageable false-positive rate. The analogous timing shape exists for SIM swap. The composition of the two signals, each with its own timing window and its own confidence level, produces a meaningfully tighter risk surface than either signal alone.
MVNOs and what the response should expose
MVNOs (virtual operators running on a host network's infrastructure) create additional ambiguity in portability detection. A subscriber porting from MNO A to MVNO B, where MVNO B is hosted on MNO A's network, may produce detection signals that look like a port (different serving operator) or like no port (same underlying network infrastructure), depending on the detection path.
An NPDB query resolves this correctly: the NPDB records the current serving MVNO as the serving operator. A signalling-based query may resolve it correctly or may return the host MNO's IMSI range, depending on the MVNO's network integration model. An aggregator-heuristic may miss the port entirely if it infers from traffic-pattern changes that do not accompany host-hosted MVNO moves.
For number-intelligence APIs, the MVNO case is another reason to expose the detection path and the source operator, not just the binary "ported: yes/no." Integrators running against customer bases that include MVNO subscribers need to know which kind of answer they are getting.
"Real-time global MNP detection" is a claim that cannot hold across all regimes. Regimes without NPDBs do not have a real-time authoritative signal. Regimes with NPDBs but restricted external access do not expose real-time data to third parties. A provider promising real-time global detection is either querying NPDBs in markets where external access is regulated to licensed operators only, or is using aggregator-heuristic detection and labelling it real-time. Accurate product copy names the regime per market: in EU markets, detection is NPDB-sourced with sub-minute freshness. In Nigeria, detection is signalling-based with sub-hour freshness. In markets without mature portability infrastructure, detection is best-effort aggregator inference with 24-hour freshness. The user of the API can then weight the signal appropriately for their use case.
How TensorSignal ships MNP detection
TensorSignal's MNP-status surface returns the current serving operator, the detection path (NPDB, signalling-based, or aggregator-heuristic), the timestamp of the most recent port where available, and the confidence level appropriate to the detection path. For EU and GCC markets, resolution is via NPDB. For African markets with active portability, resolution is via a mix of NPDB queries, signalling probes, and federating operator data. For markets without mature portability infrastructure, the response is documented as best-effort.
The MNP-recency signal is exposed in TensorShield's fraud-signal composition alongside SIM-swap recency. Integrators building fraud models get both signals as structured data with their own timestamps and provenance, rather than folded into a single recency number. The composition is what gives the signal its operational value: a port flag in the 24-to-72-hour window combined with a swap-recency check at the same window catches most of the fraud surface that targeting either signal alone would miss.
Portability is a signal most fraud models under-weight. A structured response that surfaces the regime, detection path, confidence level, and port timestamp gives a fraud model something to work with. A flat "ported: yes/no" field across all regimes carries less information than the same field labelled with where the answer came from.
