Why SMS OTPs Sometimes Arrive Late or Fail Entirely

Quick answer

When you send a message on WhatsApp, Signal, or iMessage, the text travels over the public internet through a persistent, bidirectional TCP/IP connection directly to the recipient's device in a fraction of a second.

When an online bank or retail website sends you a six-digit SMS One-Time Password (OTP), it does not travel over the internet to your phone. It is injected into the global telecommunication signaling network—an infrastructure designed in the 1980s that treats text messages as low-priority background traffic.

An SMS OTP does not fly directly from the server to your screen. It must complete a multi-stage relay:

1. The bank's web server generates the code and makes an HTTP API request to a telecom aggregator (such as Twilio, Infobip, or Gupshup).
2. The aggregator converts the request into telecommunication protocol packets (SMPP) and routes it to a regional telecom broker.
3. The message passes through regulatory compliance scrubbers (such as Distributed Ledger Technology gateways) to verify spam templates and sender IDs.
4. The destination cellular carrier receives the packet at its Short Message Service Center (SMSC), where it is written to a disk queue.
5. The carrier queries its Home Location Register (HLR) to determine which physical cell tower your phone was last registered with.
6. The local cell tower broadcasts a radio paging signal to wake up your phone's cellular modem and delivers the message payload.

If a queue fills up, a regulatory hash fails to match, or your phone momentarily loses line-of-sight with a radio tower at any point in this six-hop chain, your verification code is delayed—frequently arriving long after the website's 60-second expiration timer has expired.

The simple mental model: The Multi-Hop SMS Pipeline

Think of an internet message like an email sent directly between two mail servers, while an SMS is like a parcel handed through five different courier companies, customs inspection checkpoints, and regional delivery vans:

Chokepoint 1: Aggregator Queuing and Rate Limits

Modern businesses do not operate physical cellular towers. When an e-commerce platform or financial institution triggers an OTP, it sends an HTTPS POST request to a CPaaS (Communications Platform as a Service) vendor.

The aggregator's role is to convert modern web requests into the specialized protocol used by telecom operators: SMPP (Short Message Peer-to-Peer).

Web Application Server
      │  HTTPS / REST API (JSON)
      ▼
CPaaS Aggregator (Twilio / Sinch / Infobip)
      │  SMPP Protocol (Binary Bindings)
      ▼
Mobile Network Operator Core

The peak-event traffic bottleneck

During high-traffic events—such as morning banking rush hours, festival e-commerce sales, or tax filing deadlines—millions of users request OTPs simultaneously.

Telecom carriers strictly enforce TPS (Transactions Per Second) rate limits on aggregator connections to protect their signaling networks from being overwhelmed. If an aggregator's customer queue surges to 8,000 requests per second while their carrier pipe is throttled at 2,000 TPS, messages accumulate in an in-memory queue.

Even if every downstream network component functions perfectly, your message may sit in an aggregator's digital backlog for 45 seconds before it even enters the telecommunication system.

Chokepoint 2: Regulatory Scrubbing (DLT Gateways)

In many jurisdictions—most notably in India under Telecom Regulatory Authority of India (TRAI) directives—unsolicited telemarketing and phishing fraud led to the implementation of mandatory Distributed Ledger Technology (DLT) scrubbing platforms.

Before any transactional SMS can be routed to a subscriber, it must pass through an automated cryptographic verification engine:

Incoming Message: "Your OTP for transaction of Rs 500 is 839201. Valid for 5 mins."
                      │
                      ▼
[DLT Compliance Engine]
  ├─ 1. Header Validation: Is Sender ID "AX-HDFCBK" registered to this entity?
  ├─ 2. Consent Check: Has the user opted out of commercial SMS?
  └─ 3. Template Hashing: Does the text match registered template #91823?
                      │
                      ▼
        [Match: PASS]  or  [Mismatch: QUARANTINE / DROP]

Under DLT regulations, companies must register every single SMS format in advance as a rigid template with variables:

$$\text{"Your OTP for transaction of Rs. {#var#} is {#var#}."}$$

If an engineer modifies a single character of production code—such as changing "Rs." to "INR" or adding an extra space before a period—the cryptographic hash of the template fails to match the registry. The scrubber either silently drops the message or shunts it to a manual quarantine inspection queue, causing the OTP to vanish without an error code returning to the user.

Chokepoint 3: The SMSC "Store-and-Forward" Mechanism

Unlike internet protocols that stream data continuously, SMS was designed from day one around a Store-and-Forward architecture.

The core operational switchboard of a carrier's SMS infrastructure is the Short Message Service Center (SMSC):

1. When the SMSC receives an SMS, it writes the message to persistent disk storage.
2. It queries internal location registers to find the subscriber's phone.
3. If the phone is reachable, it delivers the payload.
4. If the phone is temporarily unreachable, it enters a retry loop.

SMS Received at SMSC ──► Attempt 1 (Failed: Tower reports handset paging timeout)
                             │
                             ▼ Sleep 30 seconds
                         Attempt 2 (Failed: Handset in elevator / switching cells)
                             │
                             ▼ Exponential backoff: Sleep 120 seconds
                         Attempt 3 (Success! Handset receives SMS)

Notice the fatal flaw for time-sensitive security codes:

• The SMSC's retry timer uses exponential backoff.
• If your phone momentarily drops signal while driving under an overpass or riding an elevator during Attempt 1, the carrier does not retry half a second later. It waits 30 seconds, then 60 seconds, then two minutes.

By the time Attempt 2 or 3 reaches your phone, the application's 60-second OTP countdown timer on your laptop has already expired, forcing you to click "Resend OTP" and restarting the entire queue cycle from zero.

Chokepoint 4: The Cellular Radio Layer (Paging Congestion)

Even when the message successfully navigates servers, aggregators, and carrier databases, it must cross the final boundary: the physical airwaves.

Cellular networks divide geography into hexagonal cells, each served by a Base Transceiver Station (BTS) or cellular antenna.

To deliver an incoming call or text, the cellular network must first discover which specific tower your phone is listening to. It queries two databases:

• HLR (Home Location Register): The master database holding subscriber identity, subscribed services, and general routing profiles.
• VLR (Visitor Location Register): A localized database at the Mobile Switching Center tracking the exact cell cluster where your handset was last observed.

Once located, the local cell tower broadcasts a transmission on the Paging Channel (PCH)—a shared, low-bandwidth radio channel that mobile devices periodically monitor to check for incoming traffic.

In densely populated environments (such as packed transit terminals, music festivals, or stadiums), the radio paging channel frequently suffers from paging exhaustion. When the tower's paging frame buffers fill up, radio packets are dropped, and your phone simply never receives the wake-up signal to download the message payload.

Chokepoint 5: "Grey Routes" and Least-Cost Routing

When a global internet company needs to deliver an SMS OTP to a user in another country, it rarely maintains direct connections with every local carrier on earth. It buys delivery capacity from international wholesale messaging brokers.

Brokers frequently use Least-Cost Routing (LCR) algorithms to optimize their profit margins:

To shave fractions of a cent off each transaction, aggressive brokers sometimes shunt traffic through cheaper indirect routes. These "grey routes" bounce messages across multiple national jurisdictions, bypassing legitimate interconnection fees until an intermediate firewall detects the evasion and blackholes the message mid-flight.

Why the World is Abandoning SMS for Authentication

The chronic unreliability, delivery latency, and severe security flaws of SMS have pushed the global software industry toward modern alternatives:

1. Time-Based Authenticator Apps (TOTP): Eliminates cellular dependency entirely. As detailed in How OTP and Two-Factor Authentication Actually Work, apps like Google Authenticator or Apple Keychain calculate verification codes locally using math and astronomical time, requiring no network connection.
2. Push-Notification Approvals: Banking applications use encrypted Apple APNs or Google FCM data channels to send a push notification directly over Wi-Fi/LTE, allowing users to tap "Yes, it's me" with biometric confirmation.
3. FIDO2 / WebAuthn Passkeys: Replaces one-time codes with asymmetric public-key cryptography built directly into browser and device operating systems.

Why this matters

The next time an online banking code takes two agonizing minutes to arrive on your screen, remember the physical journey that number had to make:

• It was not an instant internet ping.
• It was an analog voice control protocol from the 1980s navigating modern corporate APIs, carrier rate-limit buffers, regulatory cryptographic scrubbers, store-and-forward disk queues, and crowded radio frequencies.

SMS is a miraculous technology that connected humanity before smartphones existed. But it was built for casual human conversation, not the sub-second, mission-critical delivery demanded by modern cryptographic security.

To learn how local mathematics replaces the telecommunications network entirely, read the primary explainer on How OTP and Two-Factor Authentication Actually Work. You can also discover how cellular signaling carries banking without mobile data in How UPI Works Without Internet.