What are the layers of phone number validation?
1. Normalize
Convert Unicode digits and plus signs, separate extensions, and preserve the original input.
Deterministic
2. Parse
Resolve country context and split the country code from the national significant number.
Deterministic when context is known
3. Numbering-plan check
Check possible length, allocated ranges, and line-type patterns against maintained country data.
Rules-based and date-sensitive
4. Portability/carrier lookup
Ask an authorised data source for the current routing network when the use case justifies it.
Provider-reported and time-sensitive
5. Reachability signal
Use a permitted network or delivery signal to estimate whether a route can currently accept traffic.
Operational signal, not certainty
6. Proof of control
Send a short-lived challenge when the user must demonstrate access to the phone or subscription.
Transaction-specific evidence
What can HLR and MNP checks tell you?
HLR and HSS are mobile-network data functions described in 3GPP architecture. Commercial lookup services may use network, portability, allocation, or routing data to report fields such as line type, original network, current network, roaming or reachability indicators. The exact fields and meanings depend on the provider, destination market, lawful access, and time of the query.
How should validation results be labelled?
| Output | Evidence type | Important limit |
|---|---|---|
| Normalized international value | Deterministic after successful parsing | Formatting only |
| Possible/valid format | Country numbering-plan rules | Does not show allocation, activity, or ownership |
| Line type | Allocation or provider lookup | Can be unknown, reassigned, or provider-dependent |
| Original carrier | Prefix/block allocation | May be stale after portability |
| Current carrier/routing network | MNP or carrier lookup | Timestamp the result; availability varies by market |
| HLR/HSS-derived status | Mobile-network/provider response | A signal at a point in time, not proof the person can answer |
| OTP/challenge completed | Successful short-lived challenge | Shows control during that transaction, not identity or consent forever |
What is a provider-neutral validation workflow?
result = {
original_input,
normalized_e164: null,
syntax: "unknown",
allocation: "not_checked",
carrier: null,
reachability: "not_checked",
control_verified_at: null,
warnings: []
}
normalize_and_parse(result)
if country_is_ambiguous: stop_and_request_country()
check_numbering_plan(result)
if use_case_justifies_lookup: query_mnp_or_carrier(result)
if ownership_matters: send_short_lived_challenge(result)
store_each_result_with_source_and_timestamp()Stop rather than guess when country context is ambiguous or the numbering plan is unsupported. Store the source and timestamp for time-sensitive carrier or reachability results, and set a retention period appropriate to the operational purpose.
How does the workflow change by use case?
SMS delivery
Normalize, validate country/range, classify line type when justified, attempt delivery, and record provider status without converting it into an ownership claim.
Outbound calling
Normalize, respect consent and suppression rules, check destination restrictions, and keep carrier/reachability data short-lived.
Signup or account recovery
Use a short-lived challenge and rate limits. Treat PSTN/SMS authentication as a risk-bearing channel, not phishing-resistant identity proof.
CRM data hygiene
Preserve the original input, store a normalized value separately, flag ambiguity for review, and avoid live lookups unless there is a defined operational need.
Fraud reduction
Combine phone signals with account, device, transaction, and velocity evidence. Never use one line-type or carrier result as an automatic fraud verdict.
A business validation workflow with explicit stop conditions
Choose validation layers from the operational decision, not from the fields a vendor happens to sell. The minimum workflow below keeps deterministic parsing, time-sensitive network evidence and user proof separate.
| Use case | Required input | Checks | Useful output | Stop or fallback |
|---|---|---|---|---|
| Transactional SMS | Raw number, country context, consent record | Normalize, numbering plan, destination/channel policy, delivery attempt | Canonical destination, parse warnings, provider status and timestamps | Ask for country when ambiguous; offer another verified channel after a terminal failure |
| Outbound calling | Raw number, country context, purpose and suppression status | Normalize, destination restrictions, current carrier only when routing requires it | Dialable destination, compliance decision, attempt outcome | Do not call when consent or suppression status fails; escalate routing errors to the carrier |
| Signup or recovery | Normalized number and authenticated session context | Rate limits, risk checks, short-lived challenge | Challenge state, expiry and verification time | Use a recovery alternative after limits or repeated failures; do not treat the number as permanent identity |
| CRM cleanup | Raw value, source system, country field and update provenance | Unicode cleanup, parse, allocation/range rules; selective lookup only | Raw and canonical fields, ambiguity, source and review date | Queue ambiguous or unsupported records for human review instead of guessing |
| Fraud investigation | Account, device, transaction and phone evidence | Normalize plus proportionate carrier, portability or control checks | Separate evidence fields with confidence, source and timestamp | Require corroborating evidence; never reject solely because of line type or porting |
Choose the right validation layer
The local checker handles syntax and reviewed country rules. The implementation guide covers form and CRM storage, while call troubleshooting addresses live routing symptoms.
Primary sources
- ITU-T E.164: The international public telecommunication numbering planInternational Telecommunication Union. Verified 2026-07-19.
- 3GPP TS 23.002: Network architecture3rd Generation Partnership Project. Verified 2026-07-19.
- Number portabilityOfcom. Verified 2026-07-19.
- NIST SP 800-63B: Authentication and authenticator managementNational Institute of Standards and Technology. Verified 2026-07-19.
See our editorial and sourcing methodology.