What Is an OTP Sender? How One-Time Password Delivery Works

A one-time password (OTP) is something almost everyone encounters every day — the six-digit code that appears on your phone when you log into your bank, complete an online payment, or verify a new device. But the OTP sender — the infrastructure that generates, routes, and delivers that code in under three seconds — is far less understood.

This guide explains exactly what an OTP sender is, how the entire delivery chain works from the moment your application generates a code to the moment it lands on a user's phone, what happens when delivery fails, how voice OTP fallback works, how retry logic is implemented, and what expiry and security best practices look like in production systems.

No product recommendations. No sales copy. Just a thorough, technical explanation of how OTP delivery actually works.

What Is an OTP Sender?

An OTP sender is the system — or combination of systems — responsible for transmitting a one-time password to the end user through their preferred delivery channel. It is distinct from the OTP itself and distinct from the OTP generator (the algorithm that creates the code).

The OTP sender sits between your application and your user. It receives a generated OTP from your authentication backend, packages it into a delivery payload (an SMS message, a voice call, an email, a push notification), and routes it through the appropriate communication channel to reach the user.

To use an analogy: if the OTP is the letter, the OTP generator is the person who writes it, and the OTP sender is the postal service — responsible for routing, delivery, confirmation, and retry if the first attempt fails.

A complete OTP sender system handles:

• The delivery channel (SMS, voice, email, push notification, WhatsApp)

• The routing infrastructure (which carrier, which gateway, which API endpoint)

• The message composition (template, code embedding, sender ID)

• The delivery confirmation (delivery receipt from the carrier)

• The retry logic (what happens if delivery fails on the first attempt)

• The fallback channel (voice call if SMS fails)

• The status reporting (delivering confirmation or failure back to your application)

The OTP Delivery Flow — Step by Step

Understanding the complete path from application trigger to user handset is essential for anyone designing or debugging an OTP system. Here is the full flow for an SMS-based OTP sender:

Stage 1 — User Initiates an Authenticated Action

The flow begins in the user's browser or app. The user enters their username and password, clicks "Login," or attempts a high-value transaction. Your application determines that this action requires OTP verification.

Stage 2 — OTP Generation (Application Backend)

Your application's authentication backend generates a one-time password. The generation algorithm is covered in detail in the next section. At this point, the OTP exists only in your backend — it has not been sent anywhere yet.

The backend also:

• Stores the OTP (or a hash of it) in a temporary data store (e.g., Redis) with a TTL (Time To Live) matching the OTP's validity window

• Associates the OTP with the specific user session, device fingerprint, and action context

• Records the generation timestamp for time-window validation

Stage 3 — API Call to the OTP Sender Service

Your application makes an HTTPS POST request to the OTP sender API. This is typically a third-party SMS gateway or CPaaS (Communications Platform as a Service) provider. The request payload includes:

{
  "to": "+919876543210",
  "from": "MYBNK",
  "template_id": "tmpl_otp_login_001",
  "variables": {
    "otp": "847203",
    "action": "login",
    "validity": "5 minutes"
  },
  "priority": "otp"
}

The priority: "otp" field tells the gateway to route this message through the OTP express queue — separate from promotional and standard transactional queues — because OTP delivery latency is directly tied to user experience and conversion.

Stage 4 — Gateway Validation and Routing

The SMS gateway receives the API call and performs several operations in rapid sequence:

Authentication: Validates the API key or Bearer token against the sender's account.

Template validation (India): For Indian mobile numbers, the gateway validates that the message content matches the DLT-registered template structure. If there is a mismatch, the API returns a 422 error with a template mismatch reason — and nothing is sent. This happens at the gateway layer, before the carrier is involved, saving both time and cost.

Number validation: The destination number is validated against E.164 format. Invalid numbers are rejected immediately with an error code, preventing the gateway from attempting delivery to an unreachable destination.

Route selection: The gateway's routing engine queries real-time carrier health scores (updated every 15–30 seconds on a well-engineered platform) and selects the optimal carrier route for the destination number's network. For an Airtel subscriber in India, the engine selects the Airtel SMPP connection. For a Jio subscriber, the Jio route. Route selection is transparent to your application.

Priority queuing: The message enters the OTP priority queue — a dedicated processing pipeline that bypasses all promotional and standard transactional traffic. On high-traffic platforms, this queue separation is the difference between 2-second and 45-second delivery times.

Stage 5 — SMPP Transmission to Carrier

The gateway transmits the OTP to the carrier using the SMPP (Short Message Peer-to-Peer) protocol — the binary protocol standard for high-throughput, low-latency SMS delivery between aggregators and carriers.

SMPP connections are persistent (always-on TCP connections, not HTTP request-response cycles), which eliminates the connection setup overhead of HTTP for each message. For OTP delivery, where every millisecond of latency matters, persistent SMPP connections are the correct architecture.

The SMPP transmission includes:

• The message content (the OTP text)

• The source address (your registered sender ID, e.g., MYBNK)

• The destination address (the user's phone number)

• The data coding scheme (GSM-7 for standard English OTP messages)

• A priority flag indicating high-priority delivery

• A validity period for the message (how long the carrier should attempt delivery before abandoning)

Stage 6 — Carrier Processing and Radio Network Delivery

The carrier receives the SMPP-submitted message at their Short Message Service Centre (SMSC). The SMSC:

1. Looks up the subscriber's current serving cell (the cell tower they are connected to)

2. Forwards the message to the subscriber's serving Mobile Switching Centre (MSC) or, for modern 4G/5G networks, the IP Multimedia Subsystem (IMS)

3. The message is transmitted over the radio access network to the subscriber's handset

For a phone that is online and within coverage, this stage takes 200–800 milliseconds — the radio transmission part of OTP delivery is fast. The bottleneck, if any exists, is in the SMSC queuing layer, not the radio network.

If the phone is unreachable (switched off, out of coverage, in flight mode), the SMSC stores the message and retries delivery according to the carrier's retry policy — typically retrying every few minutes for up to 24–48 hours. This is called store-and-forward delivery.

Stage 7 — Delivery Receipt (DLR) Return

Once the carrier confirms the message was delivered to the handset, it generates a Delivery Receipt (DLR) — a status notification sent back through the SMPP connection to the gateway, and from there to your application via webhook or polling.

The DLR contains:

• The message ID (to correlate with your original API call)

• The final delivery status: DELIVRD (delivered), UNDELIV (undeliverable), EXPIRED, REJECTED

• The carrier-assigned timestamp of delivery

Your application receives the DLR and can update its internal state: "OTP for user session X delivered at 10:04:01.243 UTC."

Total wall-clock time for a successful OTP delivery on a well-engineered platform:

• Gateway processing: 50–150ms

• SMPP transmission: 10–50ms

• Carrier SMSC processing: 100–500ms

• Radio delivery: 200–800ms

• Total: 400ms – 1.5 seconds (median under normal conditions)

Delivery times exceeding 5 seconds are typically caused by SMSC congestion during peak traffic, suboptimal routing, or shared queue infrastructure that does not segregate OTP from bulk SMS traffic.

OTP Generation Algorithms — TOTP and HOTP

Understanding how OTPs are generated clarifies why they are secure, why they expire, and why replay attacks fail.

HOTP — HMAC-Based One-Time Password (RFC 4226)

HOTP generates a one-time password using a shared secret key and a counter value that increments with each authentication attempt. The algorithm:

HOTP(K, C) = Truncate(HMAC-SHA-1(K, C))

Where:

• K = the shared secret key (stored on both the server and the user's authenticator)

• C = the counter value (synchronised between server and client)

• HMAC-SHA-1 = a cryptographic hash function applied to the counter using the secret key

• Truncate = a function that extracts a 6 or 8-digit numeric code from the hash output

Key property of HOTP: The counter increments with every request, not with every second. This means an HOTP code does not expire based on time — it expires when the next code is generated. HOTP is used in hardware tokens (RSA SecurID, YubiKey) where the user presses a button to generate the next code.

Challenge with HOTP: Counter synchronisation. If the client generates several codes without the server being notified (e.g., the user pressed the button multiple times out of curiosity), the counters fall out of sync. Well-implemented HOTP systems maintain a "look-ahead window" that accepts a small range of future counter values.

TOTP — Time-Based One-Time Password (RFC 6238)

TOTP is an extension of HOTP that replaces the counter with a time-based value — specifically, the number of time steps (typically 30-second intervals) elapsed since the Unix epoch.

TOTP(K, T) = HOTP(K, (current_time - T0) / X)

Where:

• T0 = Unix epoch (January 1, 1970 00:00:00 UTC)

• X = the time step in seconds (typically 30)

• current_time = current Unix timestamp

Key property of TOTP: The same code is valid for a maximum of 30 seconds (one time step). Both server and authenticator generate the same code for the same 30-second window using the shared secret. The code becomes invalid after the window expires — regardless of whether it has been used.

Clock synchronisation requirement: Since TOTP depends on time, the server and the authenticator must be synchronised to the same time. Most implementations tolerate one or two time steps of clock drift (±30 or ±60 seconds) to account for minor discrepancies. If clocks are more than 90 seconds apart, authentication will consistently fail.

TOTP is used in authenticator apps (Google Authenticator, Microsoft Authenticator, Authy) and is the basis for the TOTP standard in OATH (Open Authentication).

OTPs Delivered via SMS vs. TOTP in Authenticator Apps

OTPs sent via SMS are not TOTP or HOTP in the cryptographic sense — they are randomly generated codes (typically 6 digits, using a cryptographically secure random number generator) that are stored temporarily in your backend's datastore and matched against the user's input.

The SMS delivery mechanism is entirely separate from the OTP generation algorithm. When a banking app sends you a "Your OTP is 847203" text, that code was generated by a random number generator (not HOTP or TOTP) and stored with a TTL. Your login is verified when you enter it and it matches what the server stored — it has nothing to do with a shared secret or time step counter.

The confusion between these two systems arises because both produce 6-digit codes. The difference:

Property	SMS OTP	TOTP (Authenticator App)
Generation method	CSPRNG (random)	HMAC-SHA-1 + time step
Delivery method	SMS, voice, email	Displayed in authenticator app (no network needed)
Validity period	Set by server (1–10 minutes typical)	30-second time window
Requires internet for delivery	Yes (SMS needs carrier)	No (code generated locally)
Attack surface	SMS interception, SIM swap	Shared secret compromise, device theft
Use case	One-time authentication, transactions	Ongoing 2FA for account access

Types of OTP Senders — Delivery Channels Compared

1. SMS OTP Sender

The most widely used OTP delivery channel globally and the universal standard in India. SMS OTP reaches every mobile phone — not just smartphones, not just internet-connected devices. A basic feature phone on a 2G network in rural Rajasthan receives SMS OTPs just as reliably as a flagship iPhone on 5G in Bengaluru.

Delivery characteristics:

• Sub-3 second delivery on express routes under normal conditions

• Requires mobile signal only (no data/internet)

• Delivery receipt confirms handset-level confirmation

• Works across all carriers globally

• No app installation required

When SMS OTP is the right choice:

• User base includes non-smartphone or feature phone users

• Regulatory requirement for SMS-based OTP (RBI, NPCI mandates for banking)

• Highest reach requirement — no user left behind

• India DLT compliance environment (SMS is the compliant commercial channel)

Security considerations for SMS OTP:

• SIM swap attacks (see Security section)

• SS7 protocol vulnerabilities (carrier-level interception, rare but documented)

• OTP displayed on lock screen (visible without unlocking the phone)

• Device theft combined with immediate OTP use

2. Voice OTP Sender (Voice OTP / Call OTP)

Voice OTP delivers the one-time password as a spoken message via an automated phone call. Instead of a text appearing on the screen, the user's phone rings and a text-to-speech (TTS) or pre-recorded audio file reads the code aloud: "Your one-time password is eight-four-seven-two-zero-three. I repeat: eight-four-seven-two-zero-three."

Voice OTP is not a replacement for SMS OTP — it is a fallback channel that activates when SMS delivery fails or when the user requests it.

The voice OTP delivery chain:

1. Your application triggers the voice OTP API after an SMS delivery failure is detected (based on DLR status or timeout).

2. The gateway initiates an outbound call to the user's registered phone number via the PSTN (Public Switched Telephone Network) or VoIP network.

3. When the user answers, the TTS engine reads the OTP digit by digit (and optionally repeats it).

4. The user manually enters the spoken code into the authentication interface.

5. The call terminates automatically after reading the code (typically 2–3 repetitions).

When voice OTP activates:

• SMS delivery failed (DLR returned UNDELIV or EXPIRED)

• SMS delivery timed out without a DLR after a defined threshold (e.g., 15–30 seconds without confirmation)

• User explicitly requests "Call me instead" on the OTP screen

• User's SMS inbox is full and cannot receive additional messages

• User is on a roaming network where SMS delivery is unreliable

Voice OTP advantages:

• Works when the SMS inbox is full

• Accessible to visually impaired users (screen reader + spoken code)

• Slightly harder to intercept than SMS (requires call interception, not just SIM swap)

• Useful for international numbers where SMS termination is unreliable

Voice OTP limitations:

• Requires the user to be available to answer the call (asynchronous, not instant)

• TTS pronunciation of digits can be unclear — best practice is to read digits individually with a pause between each, plus a repetition

• Higher cost than SMS per delivery

• Requires a quiet environment for the user to hear the code clearly

• Does not work if the phone is on silent and the user misses the call

Best practice for voice OTP implementation:

Design the voice OTP as an automatic fallback with a manual request option. The user should never need to know the fallback exists unless they need it.

1. SMS OTP sent → wait up to 20 seconds for DLR
2. If DLR = DELIVRD → done
3. If DLR = FAILED or timeout → show user "Didn't receive the code?"
4. If user clicks "Send again" → SMS retry on alternate carrier route
5. If user clicks "Call me instead" → Voice OTP triggered immediately
6. If second SMS DLR = FAILED → auto-trigger Voice OTP (no user action needed)

The OTP code used in the voice fallback should be the same code as the SMS — not a newly generated code. Issuing a new code invalidates the SMS that may still arrive (delayed, not failed) and creates confusion for the user.

3. Email OTP Sender

Email OTP delivers the one-time password to the user's registered email address. It is the most common fallback for users without a registered mobile number.

When email OTP is appropriate:

• The user has not registered a mobile number

• Mobile OTP is unavailable (e.g., user is travelling without their registered SIM)

• The action's risk level is low enough that email-level security is sufficient

• The platform is primarily email-first (productivity tools, SaaS applications)

When email OTP is NOT appropriate:

• High-value financial transactions requiring regulatory compliance (RBI mandates SMS/mobile OTP for banking in India)

• Any context where the email account itself might be compromised — if the attacker has the user's password AND their email access, an email OTP provides zero additional protection

• Time-critical actions where the user may not have immediate email access

Email delivery challenges:

• Spam filters may delay or block OTP emails

• Email delivery has no reliable delivery receipt equivalent to SMS DLR

• Email open rates are far lower than SMS open rates — many users do not see email OTPs for minutes or hours

• "From" spoofing and phishing of OTP emails is a documented attack vector

4. Authenticator App OTP (TOTP)

Authenticator apps (Google Authenticator, Microsoft Authenticator, Authy, Duo) generate TOTP codes locally on the user's device using a shared secret established during enrolment. Unlike SMS and email OTP, authenticator app codes do not travel over any network — they are computed locally using the shared secret and the current time.

Enrolment flow:

1. During account setup, the server generates a shared secret (a random Base32-encoded key).

2. The server displays this secret as a QR code.

3. The user scans the QR code with their authenticator app, which stores the secret.

4. From this point, both the server and the app independently compute TOTP codes that match for the same 30-second window.

Security advantages of authenticator apps over SMS:

• No SMS transmission means no SIM swap attack surface

• No carrier interception is possible (code never travels over a network)

• Works offline — no internet or mobile signal required after enrolment

• Phishing-resistant in conjunction with origin binding

Challenges with authenticator apps:

• Requires smartphone and app installation (excludes feature phone users)

• If the user loses their phone, account recovery becomes complex

• Users must back up their TOTP seeds or risk permanent lockout

• Higher user friction for setup compared to SMS OTP

5. Push Notification OTP

Push notification OTP sends the code (or a verification prompt) via a push notification to the user's registered mobile app. The user taps "Approve" (for push-based MFA) or reads the code from the notification.

This requires your application to have a native mobile app installed on the user's device with push notification permissions granted.

Best for: Applications with high smartphone penetration in the user base, where a native app is already installed and actively used.

Not suitable for: Web-only applications, users on feature phones, or scenarios where the phone may be locked and push notifications not visible.

6. Hardware Token OTP

A hardware token is a physical device (key fob, USB token, smart card) that generates HOTP or TOTP codes without requiring a mobile phone. The user presses a button on the device to generate the current code.

Best for: High-security enterprise environments, government use cases, banking staff authentication, situations where mobile phones are not permitted in the work area.

Not suitable for: Consumer-facing applications, mass-market use cases, or any context where issuing physical devices is operationally impractical.

Retry Logic — What Happens When OTP Delivery Fails

Retry logic is one of the most important and least-documented aspects of OTP sender design. Poor retry logic leads to users never receiving their code. Over-aggressive retry logic leads to OTP flooding (multiple copies of the code arriving simultaneously) and user confusion.

What Triggers a Retry?

A retry is triggered by one of three conditions:

Explicit failure DLR: The carrier returns a UNDELIV (undeliverable), EXPIRED, or REJECTED status in the delivery receipt. This is a confirmed failure — the carrier has told you definitively that the message cannot be delivered.

Timeout without DLR: No delivery receipt is received within a defined timeout window (typically 15–30 seconds for OTP, longer for standard transactional SMS). This indicates the carrier has accepted the message but confirmation is delayed — common during SMSC congestion.

User-requested retry: The user clicks "Resend code" on the OTP screen. This should be limited (see Rate Limiting below).

What a Retry Should Do

A retry should not simply resend the same message on the same route — that would fail for the same reason the first attempt failed. A good retry strategy:

Step 1 — Route change: Retry on a different carrier route or via a different carrier aggregator. If Airtel's SMSC is congested, retry via Jio's route.

Step 2 — Same OTP code, new delivery attempt: The retry sends the same OTP code (not a newly generated one). Issuing a new code each retry causes problems: if the first OTP arrives late (after the retry), the user sees two different codes and does not know which to enter.

Step 3 — Escalating fallback: After two SMS retry attempts both fail, escalate to voice OTP automatically, or show the user the "Call me instead" option.

Retry Timing

Retries should be spaced to avoid flooding the user:

Attempt	Action	Wait Before Next
Attempt 1	SMS via primary route	15 seconds (await DLR)
Attempt 2	SMS via alternate route (if DLR = fail or timeout)	20 seconds
Attempt 3	Show "Resend" button to user (manual trigger)	User controls
Attempt 4	Voice OTP (if user clicks "Call me" or auto after 2 failures)	—

Rate Limiting Retries

Without rate limiting, your retry logic becomes a tool for OTP bombing — a denial-of-service attack where a malicious actor floods a victim's phone with repeated OTP requests. Rate limits:

• Maximum 3–5 OTP requests per phone number per hour

• Maximum 10 OTP requests per phone number per 24 hours

• Cooldown period after failed attempts: 60 seconds minimum between retries

• CAPTCHA gate on the "Resend" button after the first resend request

These limits must be enforced at the application layer (before the SMS gateway API is called) — not just at the gateway level. If your application calls the OTP API without application-side rate limiting, a gateway-level block is a second line of defence, not a primary one.

Voice OTP Fallback — Implementation Design

Building voice OTP fallback correctly requires decisions at the application layer, not just the gateway configuration layer.

Should Voice OTP Be Automatic or User-Triggered?

Both approaches are used in production. The tradeoffs:

Automatic fallback (voice call triggered after SMS failure without user action):

• Better for users who are not tech-savvy and would not know to click "Call me"

• Risk: if SMS is delayed (not failed), the user receives both the SMS and the voice call, which is confusing

• Mitigated by checking DLR status before triggering voice — only trigger voice on confirmed failure, not timeout

User-triggered fallback (voice OTP available on request):

• Better UX for the majority of users who receive SMS successfully (no unsolicited phone calls)

• Requires the user to recognise and click the "Call me instead" option

• Best practice: show this option 15–20 seconds after sending the SMS, not immediately

Hybrid approach (recommended):

• Show SMS "Resend" for the first 20 seconds

• After 20 seconds without user entering a code, show "Call me instead"

• After SMS retry failure (confirmed DLR failure), auto-trigger voice without user action

TTS Design for Voice OTP

The quality of the text-to-speech delivery affects whether the user successfully hears and transcribes the code. Best practices:

Digit-by-digit reading with pauses: "Your one-time password is: eight — four — seven — two — zero — three" is far clearer than "Your one-time password is eight-four-seven-two-zero-three" spoken at normal speech pace.

Repetition: Read the code twice. Many users miss the first read while reaching for a pen or switching apps.

Explicit instruction: "Please enter this code on the screen within five minutes" — tell the user what to do with the code.

Language matching: If your application supports regional languages, offer voice OTP in the user's preferred language. A user who is more comfortable in Tamil should hear the code read in Tamil.

Short call duration: The entire call should last under 30 seconds. Users become anxious if the call is long — they wonder whether to stay on the line.

Handling Missed Voice OTP Calls

If the user does not answer the voice OTP call, your application has three options:

1. The call goes to voicemail — this is a security risk. If the voicemail is accessible, the OTP is exposed. Best practice: if the call is not answered within a specified ring count, disconnect without leaving a voicemail. Do not leave OTPs on voicemail.

2. Show the user a "Call me again" option with a brief delay.

3. Offer an alternative channel (email OTP as the final fallback, if appropriate for the risk level).

OTP Expiry — Best Practices

The OTP expiry window is one of the most consequential security decisions in OTP system design. The tradeoff is between security (shorter validity reduces attack window) and usability (longer validity reduces frustration for users who are slow to retrieve the code).

Recommended Validity Windows by Use Case

Use Case	Recommended Validity	Rationale
Banking login OTP	3–5 minutes	RBI guidelines, high security requirement
Payment transaction OTP	3–5 minutes	NPCI recommendations, time-critical
Account registration OTP	10–15 minutes	User may be slow to check phone for first-time setup
Password reset OTP	10–15 minutes	User may need to switch between email/app
E-commerce checkout OTP	5 minutes	Checkout context maintains urgency
Appointment confirmation OTP	30–60 minutes	Low-risk confirmation, user may not be at device
Email verification OTP	15–30 minutes	Low-risk, user may be on desktop without phone

What Happens When an OTP Expires

When an OTP's TTL (Time To Live) in your backend datastore (Redis, Memcached, or your application database) reaches zero, two things should happen automatically:

1. The stored OTP is deleted or marked invalid — any subsequent attempt to submit this code is rejected with an "OTP expired" error.

2. The user is shown a clear expiry message — "This code has expired. Request a new one." with a resend option. Never show a generic "Invalid code" message for an expired OTP — the user does not know whether they mistyped or the code expired.

Single-Use Enforcement

An OTP must be invalidated immediately upon successful verification — not after the validity window expires. This prevents replay attacks where an attacker who observed an OTP used by the legitimate user tries to reuse it within the validity window.

Implementation: when the user submits a code and it matches, update the OTP record's status to "used" (or delete it from the datastore) before completing the authentication. Any subsequent submission of the same code — even within the validity window — should fail.

Avoiding OTP Reuse Across Sessions

An OTP should be bound to a specific session or action context, not just a user. An OTP generated for login should not be valid for a password reset, and vice versa. Bind the OTP to:

• The user's account ID

• The session or action type (login, password_reset, transaction_authorisation)

• The device fingerprint (for new device verification OTPs)

OTP Sender ID — What It Is and How It Works

The OTP sender ID (also called the sender name, header, or originator) is the identifier that appears in the "From" field when the user receives the OTP on their phone.

For SMS-based OTP delivery, the sender ID appears at the top of the message on the user's phone screen — before they have even opened the notification. A recognisable sender ID builds instant trust: "HDBANK" means the user knows the OTP is from their bank before reading a single word of the message.

Types of OTP Sender IDs

Alphanumeric Sender ID: A 6-character text string representing your brand. Examples: MYBNK, TECHTO, CLINC1, FLIPKR. Alphanumeric sender IDs cannot receive replies (they are one-way). They are the standard for transactional OTP delivery in India and most of Europe and Asia.

Numeric Sender ID: A phone number (10 digits in India, 11 with country code). Numeric sender IDs can receive replies, making them suitable for two-way messaging. For OTP delivery, numeric sender IDs are less desirable because they appear less trustworthy and are indistinguishable from random spam at a glance.

Short Code: A 5 or 6-digit number approved for high-volume, application-to-person messaging. Short codes are recognisable (consistent across campaigns) and support high throughput. Used for OTP in some markets.

OTP Sender ID Registration in India (DLT)

In India, every commercial SMS — including OTP delivery — must comply with TRAI's DLT mandate. For OTP senders:

Sender ID registration: Your 6-character alphanumeric OTP sender ID (e.g., MYBNK) must be registered on the DLT portal (Jio, Airtel, Vi, BSNL, or TATA) under the Service Implicit category. Service Implicit is the correct category for OTP and transactional messages — it indicates the customer has an implied relationship with the service and expects these communications.

Template registration: The exact structure of every OTP message template must be registered on the DLT portal before it can be used. Dynamic fields (the OTP code, the action description, the validity period) are marked as {#var#} placeholders. The static text of the template must match exactly — a comma in the wrong place causes carrier-level rejection.

No DND restriction: OTP messages registered under Service Implicit bypass India's DND (Do Not Disturb) registry. This is by design — a user who has opted out of promotional SMS still needs to receive OTPs for their bank, e-commerce, or service accounts. TRAI's framework specifically accommodates this by categorising transactional and OTP messages separately from promotional communications.

Time restriction: Service Implicit / OTP messages have no time restriction — they can be sent and delivered 24 hours a day, 7 days a week, including nights, weekends, and public holidays. A banking OTP triggered at 2 AM goes through without restriction.

OTP Delivery Latency — What Is Acceptable?

Latency expectations for OTP delivery differ from those for bulk SMS marketing. In bulk marketing, a 30-second delivery delay is inconsequential. In OTP delivery, a 30-second delay causes user abandonment, support calls, and transaction failure.

What Users Experience at Different Latency Levels

Delivery Time	User Experience	Business Impact
Under 3 seconds	Seamless — code arrives before user reaches for phone	Optimal conversion
3–8 seconds	Slightly noticeable pause — user may check phone once	Acceptable
8–15 seconds	User notices delay — may click "Resend" prematurely	Increased support load
15–30 seconds	User frustration — likely to click "Resend," creating retry traffic	Session abandonment risk
30–60 seconds	High abandonment — user may reload page or abandon transaction	Revenue impact
Over 60 seconds	Severe UX failure — user abandonment near-certain	Significant churn

Factors That Determine OTP Delivery Speed

Queue separation: Is the OTP message in a dedicated express queue, or is it competing with bulk promotional traffic? A platform that processes all message types in a single queue will have OTP delivery times that vary with promotional traffic volume — spiking to 30–90 seconds during peak marketing hours.

SMPP vs. HTTP routing to carrier: SMPP persistent connections eliminate HTTP handshake overhead for each message — reducing latency by 50–150ms per message. For OTP at scale, SMPP is the correct architecture.

Carrier SMSC load: Carrier SMSCs experience congestion during peak traffic periods. Direct carrier connections with priority routing agreements give OTP traffic preferential handling within the carrier's own infrastructure.

Number of routing hops: A message that passes through three intermediary aggregators before reaching the carrier introduces latency at each hop. Direct carrier connections, or single-hop aggregator connections, minimise this.

Geographic proximity: The physical distance between the SMS gateway's data centres and the carrier's SMSC affects latency. India-native platforms with Mumbai or Delhi data centres have lower latency to Indian carrier SMSCs than US or European-based platforms routing through transatlantic infrastructure.

OTP Security — Threats and Defences

Attack 1: SIM Swap (Account Takeover via Carrier Social Engineering)

How it works: The attacker calls the victim's mobile carrier pretending to be the victim. They convince the carrier to transfer the victim's phone number to a new SIM card in the attacker's possession. From that point, all SMS messages (including OTPs) are delivered to the attacker's device.

Prevalence: SIM swap attacks are disproportionately targeted at high-value accounts — cryptocurrency wallets, large bank balances, and social media accounts with monetisation potential. They are not mass-scale attacks; they require targeted effort.

Defences:

• Silent network authentication (SNA): A server-to-carrier API call that verifies whether the user's SIM has changed recently without sending any SMS to the user. If a SIM change was detected in the last 24–72 hours, the system can require additional verification before accepting the OTP.

• Step-up authentication: For high-value actions, require an additional factor (biometric, backup email, knowledge question) if the account has a recent SIM change flag.

• TOTP authenticator as primary: For the highest-security use cases, replace SMS OTP with an authenticator app (TOTP) as the primary 2FA method, relegating SMS to a less-privileged fallback.

• Carrier SIM lock: Advise users to enable SIM lock (PIN protection for SIM changes) with their carrier.

Attack 2: OTP Phishing (Real-Time Phishing)

How it works: The attacker creates a fake login page for your service. When the victim enters their credentials on the fake page, the attacker simultaneously logs in to the real service, triggering a genuine OTP. The fake page then asks the victim to enter their OTP ("Please verify your account"). The victim enters the genuine OTP on the fake page, which the attacker immediately uses on the real site.

Defences:

• Origin binding: Associate OTP generation with a specific origin (domain or app) and reject OTP submissions from other origins. FIDO2/WebAuthn passkeys implement this natively.

• Short validity windows: A 3-minute OTP limits the attacker's exploitation window.

• Rate limiting on OTP attempts: After 3 failed OTP submissions for a session, lock the session and require fresh authentication.

• User education: Real-time phishing is difficult to detect technically; user awareness ("never enter your OTP on a site you navigated to via a link in a message") is the most effective complement to technical controls.

Attack 3: OTP Bombing (Denial of Service via OTP Flood)

How it works: A malicious actor programmatically sends hundreds or thousands of OTP requests for a victim's phone number, flooding the victim's SMS inbox with OTP messages. The attack has two goals: harassment (flooding the victim's phone) and account access (hoping to guess one of the many OTPs in flight within the validity window).

Defences:

• Application-layer rate limiting: Maximum 3–5 OTP requests per phone number per hour. Maximum 10 per 24 hours. These limits must be enforced before the SMS gateway API is called.

• CAPTCHA gate: Require CAPTCHA completion before allowing an OTP request. Google reCAPTCHA v3 (invisible) is the least intrusive option for mobile flows.

• Device fingerprinting: If the same device is generating OTP requests for multiple different phone numbers, flag and rate-limit that device.

• IP rate limiting: Maximum N OTP API calls per IP address per minute at the application layer.

Attack 4: SS7 Protocol Vulnerabilities (Network-Level Interception)

How it works: SS7 (Signalling System No. 7) is the legacy protocol that underlies much of the global telephone network. Known SS7 vulnerabilities allow a sophisticated attacker with access to the SS7 network (typically nation-state actors or well-resourced criminal groups) to intercept SMS messages in transit by redirecting calls and texts from one subscriber's MSISDN to another location.

Prevalence: SS7 attacks are highly sophisticated and require either carrier-level network access or access to the SS7 backbone itself. They are not realistic threats for the vast majority of consumer applications. They are a documented threat model for high-value targets (journalists, government officials, activists).

Defences: For most applications, SS7 attacks are outside the practical threat model. For the highest-security contexts (government authentication, cryptocurrency exchanges, high-net-worth banking):

• Move primary 2FA from SMS to TOTP authenticator apps or hardware tokens.

• Implement Silent Network Authentication (SNA) for anomaly detection.

• Consider FIDO2/WebAuthn passkeys as a phishing-resistant, SS7-immune alternative.

OTP Message Content — Composition Best Practices

The content of an OTP message is as important as the delivery infrastructure. A poorly written OTP message causes user confusion, support calls, and security complaints.

Length: 6 Digits vs. 8 Digits vs. Alphanumeric

6-digit numeric OTP: The universal standard. Balances security (10^6 = 1,000,000 possible values) with usability (short enough to read and type from a notification). Combined with a 3-attempt limit, a 6-digit OTP is cryptographically sufficient for all consumer authentication use cases.

8-digit numeric OTP: Used in some high-security financial contexts (card-not-present transactions, large value transfers). Marginally more secure (10^8 = 100,000,000 values) but noticeably harder for users to transcribe accurately. The incremental security benefit rarely justifies the UX cost for consumer-facing applications.

Alphanumeric OTP: Mixed letters and numbers (e.g., A4B7C2). Significantly larger keyspace but dramatically worse usability — users confuse I/1, O/0, and struggle with capitalisation. Not recommended for SMS OTP unless the verification interface has an auto-complete or auto-read mechanism.

4-digit PIN: Used for low-security confirmations (in-person delivery confirmation, low-value transaction approval). Not recommended for account authentication — 10^4 = 10,000 possible values with a patient attacker is insufficient.

Required Elements in Every OTP Message

TRAI and security best practices both require specific elements in OTP message content:

The code itself: Clear, legible, unambiguous. "Your OTP is 847203" — use bold or isolation if the channel supports formatting.

What the OTP is for: "Your OTP for login," "Your OTP for payment of ₹4,999," "Your OTP for password reset." This helps the user verify the action is one they initiated and builds context that makes phishing attempts more detectable.

Validity period: "Valid for 5 minutes." Required by TRAI for financial OTPs in India. Essential for user experience (user knows how urgently to act).

Do not share warning: "Do not share this with anyone." Required by TRAI for financial OTPs. Reinforces social engineering awareness.

Brand/sender identification: The message should clearly identify who sent it — usually accomplished by the sender ID (e.g., MYBNK), but reinforced in the message body for important actions.

Example compliant OTP message:

"MYBNK: Your OTP for net banking login is 847203. Valid for 5 minutes. Do not share this with anyone. If you did not request this, call 1800-XXX-XXXX. -MYBNK"

This message is 152 characters — just within the 160-character GSM-7 single-segment limit. Keeping OTP messages within one segment prevents multi-part billing and ensures the full message arrives as a single unit.

OTP Sender in the Context of Multi-Factor Authentication (MFA)

OTP delivery is the most common implementation of the "something you have" factor in multi-factor authentication (MFA). Understanding how OTP fits into the broader MFA framework helps clarify when SMS OTP is the right choice and when a different approach is warranted.

MFA Factor Types

Something you know: Password, PIN, security question answer. This is the first factor in most authentication systems.

Something you have: An OTP delivered to a registered device (phone, email, hardware token, authenticator app). The assumption is that only the legitimate user has access to the registered device. This is where OTP senders operate.

Something you are: Biometric factors — fingerprint, face recognition, iris scan. These are increasingly used as the primary factor on mobile devices, with OTP as a fallback for account recovery.

Somewhere you are: Location-based factors — IP geolocation, GPS, network context. Used as a risk signal to escalate or waive additional authentication factors.

OTP as Step-Up Authentication

"Step-up authentication" refers to requiring an additional authentication factor for elevated-risk actions, rather than requiring it for every login. Examples:

• Login from a new device → OTP required

• Login from an unusual geography → OTP required

• Transaction above ₹50,000 → OTP required

• Changing account settings (phone number, email, password) → OTP required

• Standard login from a trusted device → OTP not required

Well-designed OTP sender integrations trigger OTP delivery contextually — only when the risk signals warrant it — rather than requiring OTP for every single login. This reduces OTP fatigue (users becoming careless about reviewing OTPs) while maintaining security for high-risk actions.

OTP and Passkeys — Where Authentication Is Heading

The FIDO Alliance's WebAuthn standard and the passkey implementations by Apple, Google, and Microsoft represent the most significant shift in consumer authentication in a decade. Passkeys replace passwords and OTP entirely with a public-key cryptographic credential stored on the user's device (Secure Enclave on iPhone, Trusted Platform Module on Android and Windows).

How passkeys eliminate the need for SMS OTP:

• Login requires biometric authentication on the device (face/fingerprint), not a code

• The credential is device-bound — no code travels over any network

• No SIM swap vulnerability (no SMS involved)

• No phishing vulnerability (credentials are origin-bound — they cannot be used on fake sites)

Current state (2026):

• Passkeys are widely supported on iOS 16+, Android 9+, macOS Ventura+, Windows 11, and all major browsers

• Adoption by services is growing but far from universal — banking, government, and legacy enterprise applications are slower to adopt

• SMS OTP remains the fallback for users without passkey-compatible devices and for account recovery

What this means for OTP senders: SMS OTP is not going away in the near term — particularly in India, where the regulatory requirements for SMS-based OTP in banking (RBI, NPCI) are codified, and where the user base spans devices from flagship smartphones to basic feature phones that will never support passkeys. The OTP sender will continue to be the primary authentication delivery mechanism for India's online economy for the foreseeable future.

The evolution to watch is gradual passkey adoption among smartphone-first applications (fintech apps, e-commerce) that serve a younger, tech-comfortable demographic — reducing SMS OTP volume on those platforms over time while SMS OTP remains essential for regulatory compliance use cases and for reaching users on older devices.

OTP Sender Glossary

A2P (Application-to-Person): SMS sent from a software application (like a bank's authentication system) to a person's phone. OTP delivery is the most common A2P use case.

CSPRNG (Cryptographically Secure Pseudo-Random Number Generator): The algorithm used to generate the random digits in an SMS OTP. Must be cryptographically secure — a standard random number generator is predictable to a sophisticated attacker.

DLR (Delivery Receipt): A status notification from the carrier confirming whether an OTP message was delivered to the handset. Used by the OTP sender to determine whether retry logic should trigger.

DLT (Distributed Ledger Technology): TRAI's regulatory framework in India requiring registration of SMS senders and templates. Applies to OTP senders operating in India.

HOTP (HMAC-Based One-Time Password): An OTP algorithm (RFC 4226) that generates codes using a shared secret and an incrementing counter. Used in hardware tokens.

MSISDN (Mobile Subscriber Integrated Services Digital Network number): The technical term for a mobile phone number — including country code and subscriber number.

OTP Bombing: A denial-of-service attack that floods a victim's phone with repeated OTP SMS messages by making repeated OTP generation requests.

P2P (Person-to-Person): SMS sent between two individuals via their carrier's messaging service. Distinct from A2P and subject to different carrier routing and pricing.

Sender ID: The "from" name or number displayed on the recipient's phone when they receive an OTP. In India, must be a DLT-registered 6-character alphanumeric header for transactional messages.

Service Implicit: The TRAI DLT category for transactional and OTP messages. Permits DND bypass and 24/7 delivery.

SIM Swap: An account takeover attack where the attacker convinces the carrier to transfer the victim's phone number to a new SIM card, redirecting all SMS (including OTPs) to the attacker.

SMPP (Short Message Peer-to-Peer): The binary protocol used between SMS gateways and carrier SMSCs for high-throughput, low-latency message delivery. Preferred over HTTP for OTP delivery.

SMSC (Short Message Service Centre): The carrier's messaging infrastructure that receives, stores, and forwards SMS messages to subscriber handsets.

SS7 (Signalling System No. 7): The legacy protocol that routes calls and texts across carrier networks globally. Contains documented vulnerabilities that allow sophisticated network-level SMS interception.

TTS (Text-to-Speech): The technology used to convert OTP text into spoken audio for voice OTP delivery.

TOTP (Time-Based One-Time Password): An OTP algorithm (RFC 6238) that generates codes using a shared secret and the current time. Used in authenticator apps.

TTL (Time To Live): The duration for which an OTP is stored and valid in the backend datastore. When the TTL expires, the OTP is automatically deleted or invalidated.

Voice OTP: An OTP delivered via an outbound automated phone call that reads the code aloud using TTS. Used as a fallback when SMS delivery fails.

Frequently Asked Questions

What is the difference between an OTP sender and an OTP generator? An OTP generator creates the one-time password — it is the algorithm (TOTP, HOTP, or CSPRNG) that produces the code. An OTP sender delivers that code to the user through a communication channel (SMS, voice, email, push). In most implementations, the generator is part of your application backend, while the sender is a third-party SMS gateway or CPaaS service.

Why does my OTP sometimes arrive late? OTP delivery latency has several causes: SMSC congestion at the carrier, routing through shared SMS queues that mix OTP traffic with bulk promotional messages, geographic routing that adds unnecessary hops, or your SMS gateway not prioritising OTP traffic separately. Well-engineered OTP platforms use dedicated express queues and direct carrier SMPP connections to deliver OTPs within 1.5–3 seconds under normal conditions.

What is voice OTP and when should I use it? Voice OTP delivers a one-time password via an automated phone call that reads the code aloud. It is used as a fallback channel when SMS delivery fails — for example, when the user's SMS inbox is full, they are in an area with poor SMS coverage, or the carrier returns a delivery failure. Voice OTP should be the automatic fallback after two failed SMS attempts, and should always be offered as a manual option for users who cannot receive SMS.

Why is the same OTP code sent on retry, not a new one? Because the original OTP may still be in transit. If you issue a new OTP on each retry, and the original SMS arrives shortly after the retry, the user sees two different codes and does not know which to enter. Always retry delivery of the same code through a different route or channel.

What is OTP bombing and how do I prevent it? OTP bombing is an attack where a malicious actor sends repeated OTP requests for a victim's phone number, flooding their device with messages. Prevention: enforce rate limits of 3–5 OTP requests per phone number per hour at the application layer (not just the SMS gateway), require CAPTCHA for OTP requests on web interfaces, and implement IP-level rate limiting.

How long should an OTP be valid? For financial transactions and banking, 3–5 minutes is the standard (and in some cases regulatory requirement). For account registration and password reset, 10–15 minutes balances security with user convenience. For very low-risk confirmations (appointment acknowledgements), 30–60 minutes is acceptable. Always display the validity window in the message body — "Valid for 5 minutes" — so users know how urgently to act.

Can an OTP be used more than once? No — by definition and by implementation. When an OTP is successfully verified, it should be immediately invalidated in your backend datastore (deleted or marked as used). Any subsequent submission of the same code within the validity window should fail with an "OTP already used" error.

What is the DLT requirement for OTP senders in India? All OTP messages sent to Indian mobile numbers must be sent using a DLT-registered sender ID under the Service Implicit category. The message content must match a DLT-registered template with {#var#} placeholders for the variable OTP value. Unregistered or mismatched messages are blocked by carriers before delivery.

Is email OTP secure enough for financial transactions? For most financial transactions — particularly in India's banking context — SMS OTP is the regulatory standard (RBI and NPCI guidelines). Email OTP is acceptable for lower-risk actions (account creation, non-financial setting changes) but is generally not considered sufficient for payment authorisation because email account compromise can chain directly into financial account compromise.

What is the difference between TOTP and SMS OTP? TOTP (Time-Based One-Time Password) is generated locally on the user's authenticator app using a shared secret and the current time — no network delivery is required. SMS OTP is generated on the server and delivered to the user's phone via the carrier's messaging network. TOTP is more phishing-resistant and eliminates the SMS attack surface (SIM swap, SS7) but requires a smartphone with an authenticator app. SMS OTP works on all phones, requires no app installation, and has broader reach — making it the practical standard for consumer-facing applications in India.

Why do some OTPs say "Do not share this with anyone"? This warning is required by TRAI for financial and transactional OTP messages in India. It serves as a reminder to users that they should not be pressured into sharing their OTP with anyone — not a caller claiming to be from the bank, not a customer service agent, nobody. Social engineering attacks (where attackers call victims pretending to be bank representatives and ask for the OTP) are common in India, and this warning is a regulatory and security best practice.

Summary — What Makes an OTP Sender Work

An OTP sender is not a single component — it is a chain of systems, each of which must function correctly for the code to arrive in time and intact:

The application generates a secure random OTP and stores it with a TTL. The gateway receives the API call, validates the template and number, selects the optimal carrier route, and transmits via SMPP. The carrier's SMSC receives the message, routes to the subscriber's serving cell, and delivers via the radio network. The delivery receipt travels back through the chain to your application. If delivery fails, retry logic triggers — same code, alternate route, escalating to voice OTP if SMS attempts exhaust. The user receives the code, enters it, and is verified. The OTP is immediately invalidated.

The difference between an OTP that arrives in 1.8 seconds and one that arrives in 45 seconds — or not at all — lies in the quality of every link in that chain: queue architecture, carrier relationships, SMPP vs. HTTP routing, retry logic design, and the validity windows that determine how long each attempt has to succeed.