HLR Lookup for Mobile Network Operators
HLR Lookup for Mobile Network Operators A number range table goes stale the moment a subscriber ports out. That's the core problem HLR lookup exists to...
Ethan works on phone-number normalization, E.164 formatting, country-code rules, carrier metadata, and line-type detection. His editorial work turns verification signals into practical workflows for CRM cleaning, SMS preparation, lead review, and bulk data operations.
View full author profile →HLR Lookup for Mobile Network Operators
A number range table goes stale the moment a subscriber ports out. That’s the core problem HLR lookup exists to solve — and it’s why mobile network operators use it even when they already own their own number blocks.
HLR is short for Home Location Register, the core-network database that stores every subscriber’s status and current location. An HLR lookup queries that register in real time over SS7 signalling and returns three things no static range file can give you: whether the number is actually active, which network currently serves it (the real answer after porting), and whether it’s roaming.
For an MNO, that last point is the one that quietly costs money. A number that looks domestic on paper but is roaming in another country is a different routing and billing decision. Static prefixes never tell you that.
The check itself is not the whole workflow. It’s the step that adds enough signal to route the row, hold it, repair it, or keep it out of the next run.
Where operators use the result
| Workflow point | Problem before the check | Decision after export |
|---|---|---|
| Intake | Rows arrive from several systems with uneven formatting. | Normalize and keep the source row ID. |
| Routing | The team doesn’t know which records fit the next channel. | Segment by network_name and country_or_region. |
| Review | High-value or suspicious rows need a slower decision. | Send them to a review queue with reason codes. |
| Reporting | Nobody knows which source created weak records. | Report result groups by source and segment. |
The fields that actually matter
| Field | Why it matters |
|---|---|
record_id |
Keeps the row tied to the CRM, warehouse, or upload file. |
source |
Shows where bad records entered the list. |
network_name |
The HLR-specific signal — tells you the current network, not the range owner. |
country_or_region |
Splits market and regional patterns. |
reason_code |
Explains whether the row should move, wait, or be suppressed. |
network_name is the one worth understanding. A number ported from one operator to another will still sit in the old operator’s range block. HLR returns the network that actually holds the subscription now, which is the only thing that matters for routing and settlement.
Run a pilot before you commit
Start with 500 to 1,000 rows that look like the real list — old records, fresh records, duplicates, and rows from the sources you already suspect. The pilot answers whether the full run is worth the spend before you pay for a million lookups.
record_id,phone,source,segment,owner
row_1001,+14155552671,crm_export,active_accounts,ops
row_1002,020 7183 8750,legacy_import,stale_accounts,ops
row_1003,+61491570156,partner_feed,new_leads,opsAfter the check, keep the result file next to the source file. The fastest way to know whether the lookup is pulling its weight is to compare a row before and after — if the result didn’t change a routing decision, a retry rule, or a cleanup step, you’re probably running it at a scale where it isn’t paying for itself.
Decide the routing rules before the full run
Write these down first. Otherwise the export becomes another spreadsheet waiting for someone to interpret it.
| Result | Default action | Override when… |
|---|---|---|
| usable | Send to the planned workflow. | Hold VIP or high-value records if another field looks wrong. |
| repair | Fix formatting, country, or missing source data. | Suppress if the same source keeps sending bad rows. |
| retry | Run the row once more later. | Skip when the input is empty or clearly malformed. |
| review | Route valuable or risky rows to a person. | Auto-resolve if the risk is low and the volume is high. |
| suppress | Keep it out of the next campaign or import. | Review before suppressing if the account is already active. |
What to report
The useful report is short: upload size, usable rate, repair rate, unknown rate, the source with the most bad rows, and cost per usable row. That’s enough to improve the next list instead of only judging the current one.
When another step should come first
Don’t run a deeper lookup just because the tool is available. Skip it when:
| Situation | Better next step |
|---|---|
| No stable row ID | Add IDs before upload so the export can be merged back. |
| Mixed country formats | Normalize or split the file before running product-specific checks. |
| One-off support question | Use manual review instead of a batch workflow. |
| No routing rule | Agree on usable, repair, retry, and suppress groups first. |
Cheap problems first. A lookup on top of broken source data just produces a more expensive version of the same mess.
Next step
Use HLR Lookup when the file is ready for this specific check. If you’re still deciding which check belongs in the workflow, start from the product directory or pricing instead.
FAQ
What does an HLR lookup tell an operator that a range table can’t?
Three things: whether the number is active, which network currently serves it after porting, and whether it’s roaming. Range tables are static; they tell you who originally owned the block, not where the subscription is now.
Where does ZelNum fit?
Use HLR Lookup when you want the check to run across a list and export usable fields — network_name, country_or_region, reason_code — instead of checking rows one by one.
What should I do after a HLR check?
Split the export into usable rows, rows that need repair, rows to suppress, and rows worth one retry. The point of the split is a clear next action, not a bigger spreadsheet.
Related ZelNum pages
If you already have a file ready, start at the HLR Lookup product page.