Mobile Number Validation Done Right: Stop Fake Signups Without Blocking Real Users

Why mobile number validation matters

A phone number field looks simple, but it sits on the front line of onboarding fraud, SMS cost control, and KYC compliance. Fake or malformed numbers waste OTP and SMS spend, break delivery-notification flows, and let bot signups through registration forms. Getting validation right is a layered problem — no single check catches everything, and the layer most guides lead with (a checksum) is not actually checking what most people assume it's checking.

The Luhn/MOD10 checksum — and the misconception around it

Most "phone validation" tutorials open with the Luhn algorithm (also called MOD10) — the same checksum that protects credit card numbers. Here's the part they usually skip: telephone numbers don't carry a check digit. The ITU's E.164 numbering plan has no built-in checksum, so running a Luhn check against a phone number is checking a mathematical property the number was never designed to have.

Understanding the mechanics is still useful — it's the same technique behind IMEI and card validation you'll likely need elsewhere in a fraud-prevention stack:

// Luhn / MOD10 checksum — validates IMEI numbers, credit cards,
// SIM ICCIDs. Does NOT validate telephone numbers (E.164 has no check digit).
function luhnValidate(digits) {
  let sum = 0;
  let alternate = false;
  for (let i = digits.length - 1; i >= 0; i--) {
    let digit = parseInt(digits.charAt(i), 10);
    if (alternate) {
      digit *= 2;
      if (digit > 9) digit -= 9;
    }
    sum += digit;
    alternate = !alternate;
  }
  return sum % 10 === 0;
}

Worked example: validating IMEI 490154203237518 — double every second digit from the right (9→18→9, 4→8, 2→4, 3→6, 2→4…), sum all digits, and the total must be a multiple of 10. This exact process is what phone manufacturers use to generate a valid IMEI's final check digit — it has nothing to do with the subscriber's phone number.

Open source and library-based validation

// npm install libphonenumber-js
import { parsePhoneNumberFromString } from 'libphonenumber-js';

function validatePhone(number, defaultCountry) {
  const parsed = parsePhoneNumberFromString(number, defaultCountry);
  if (!parsed) return { valid: false, error: 'Invalid format' };
  return {
    valid: parsed.isValid(),
    e164: parsed.number,          // e.g. +14155552671
    country: parsed.country,
    type: parsed.getType(),       // MOBILE, FIXED_LINE, VOIP, etc.
  };
}

Real-time API-based validation

Format checks and libraries confirm a number is well-formed. To know whether it's actually reachable, who carries it, or whether it's been recently reassigned, you need a live API:

curl -X GET "https://lookups.twilio.com/v2/PhoneNumbers/+14155552671?Fields=line_type_intelligence" \
  -u $TWILIO_ACCOUNT_SID:$TWILIO_AUTH_TOKEN

GSMA Open Gateway: network-based verification without an OTP

The GSMA Open Gateway Number Verification API takes a different approach entirely: instead of sending an SMS code and asking the user to type it back, your backend asks the mobile network operator directly whether the phone number matches the SIM currently making the request. The carrier confirms possession over its own infrastructure — no OTP, no SMS delay, and no exposure to SIM-swap or OTP-interception fraud, since the check never leaves the carrier's trusted network path.

POST /number-verification/v1/verify
Authorization: Bearer {access_token}
{
  "phoneNumber": "+14155552671",
  "hashed": false
}

The trade-off: it only works when the request originates from the user's own mobile data connection (not WiFi, in most implementations), and coverage depends on which operators in a given country have joined the federation.

Comparing the validation layers

Step-by-step: layering validation in practice

Best practices

• Always store E.164 format. Consistency here prevents an entire class of matching and deduplication bugs later.
• Don't rely on a checksum that doesn't exist. Skip Luhn/MOD10 for the phone number field itself — reserve it for IMEI, SIM ICCID, or card numbers where it actually applies.
• Cache validated numbers. Live API tiers have rate limits; re-validating on every page load burns budget for no new signal.
• Match the validation layer to the risk. A newsletter signup and a payment authorization don't need the same validation cost.
• Combine, don't replace. Format checks, library-based checks, and live API checks answer different questions — use them together, not as alternatives to each other.

Common use cases

India-specific context: Sanchar Saathi and Chakshu

India's Department of Telecommunications runs the Sanchar Saathi platform, a citizen-facing complement to enterprise-side validation. Its Chakshu feature lets citizens report suspected fraud calls, SMS, and WhatsApp messages; the platform has also been credited with recovering several hundred thousand lost or stolen handsets by working with telecom operators and police in real time. If you're building for the Indian market, it's worth knowing this exists as a citizen reporting channel — it isn't a developer API, but it shapes what "spam" and "fraud" mean in the regulatory conversation around telecom data.

Troubleshooting common issues

Key takeaways

• The Luhn/MOD10 checksum does not apply to telephone numbers — E.164 has no check digit. It's the right tool for IMEI, SIM ICCID, and card numbers, not the phone number field.
• Format validation (libphonenumber) is free and should be the first layer for every number your system accepts.
• Carrier, line-type, and fraud signals require a live API — Twilio Lookup and Numverify are the two most established options, at different price points.
• GSMA Open Gateway's network-based verification removes OTP friction entirely, at the cost of narrower device/network coverage.
• Match validation cost to risk — not every form field needs the most expensive layer.