OTP delivery benchmarks - what good looks like
A one-time passcode is only useful if it arrives before the user gives up. Here are the latency and conversion numbers we consider healthy, the route decisions that move them, and how to keep artificially inflated traffic from quietly eating the budget.

Measure conversion, not delivery - Most OTP dashboards report a delivery rate, and most delivery rates look fine. The number that matters is conversion: of the codes you sent, how many were entered correctly before they expired. A route can return a delivered receipt for 97 per cent of messages and still convert at 70 per cent because the code arrived forty seconds later, after the user had already tapped resend twice and abandoned the sign-up. Conversion is the metric your product team feels, and it is the one we tune routes against.
Latency benchmarks worth holding a route to - On direct operator connections in mature markets, a median time from API request to handset delivery under five seconds is normal, and the 95th percentile should stay under fifteen to twenty seconds. Once a route's 95th percentile drifts past thirty seconds, resend behaviour kicks in, duplicate codes confuse users and conversion falls off a cliff even though delivery still reports as successful. Routes that traverse hubs or grey channels routinely show medians of ten seconds or more with wide variance. We alert on 95th-percentile latency per operator, not on averages, because averages hide the users who are suffering.
Conversion benchmarks by context - Verified conversion of 85 to 95 per cent is realistic for a well-run flow on direct routes in most markets, with the higher end reached where sender IDs are registered and the code sits at the very start of the message. Sign-up flows convert lower than login flows because a share of sign-up attempts are simply not real people. Markets with heavy filtering or SIM-registration friction can sit ten points lower for reasons outside the route. If your verified conversion is under 80 per cent in a country where delivery reports above 95 per cent, the problem is latency, message format or fraud, and each has a different fix.
Route strategy is most of the difference - The largest lever is whether your provider terminates through direct binds to the destination operator or through a chain of aggregators. Direct routes cost more per message and less per verified user, because they deliver faster, return honest receipts and are not silently swapped when a hub finds a cheaper path on a Tuesday afternoon. The second lever is sender-ID registration: DLT headers and templates in India, 10DLC brand and campaign registration in the United States, alphanumeric sender registration where the regulator requires it. Unregistered traffic is throttled or filtered by design. The third lever is failover: a good verification service retries over voice, WhatsApp, flash call or a silent network check when SMS has not converted within a timer you set, per country, because the right fallback in Brazil is not the right fallback in Germany.
Message format is a free win - Put the code first, keep the message short, and include a brand name and an expiry. Modern handsets and browsers extract codes automatically when the message follows the origin-bound pattern, which removes the copy step that costs seconds and typos. Six digits and a five-minute lifetime is the sensible default. Do not rotate templates without re-registering them where registration is mandatory, or the filters will treat the new wording as spam.
Artificially inflated traffic is a cost problem before it is a fraud problem - AIT, sometimes called SMS pumping, is the practice of triggering OTP sends to number ranges where somebody in the chain earns a share of the termination fee. It looks like a burst of sign-ups from one country with near-zero conversion, often to consecutive numbers, often at three in the morning your time, and a delivery-rate dashboard shows nothing wrong. Watch the ratio of sends to successful checks per country and per hour; a healthy flow converts a large majority, and a range converting under ten per cent for an hour is not a marketing success.
Controls that stop AIT without hurting real users - Rate-limit by phone number, IP address and device, with tighter limits for countries where you have no customers. Add a number lookup before you send, so unallocated ranges and obvious virtual numbers are rejected without spending anything. Put a per-country daily budget on verification and let it trip. Use a CAPTCHA or a small delay only after the first suspicious signal, because friction on the first try costs conversion everywhere. On our side, the SMS firewall scores destination ranges on live conversion data across customers, so a pumped range is blocked for you before it has finished costing somebody else.
Read the receipts sceptically - A delivered receipt from a direct operator bind means the handset acknowledged the message. A delivered receipt from a hub can mean anything from handset delivery to acceptance by the next hop, and some routes fake receipts outright. If your provider cannot tell you which operator delivered each message, when, and via which connection, you cannot investigate a conversion problem; you can only change vendor and hope. Insist on per-message operator identity and timing in the API, and use those fields to build the two charts that actually predict user experience: 95th-percentile latency by operator, and verified conversion by country.
A weekly review that keeps the numbers honest - Once a week, list every country with more than a few hundred verifications and look at four things: verified conversion, 95th-percentile latency, sends per successful check, and cost per verified user. A move of more than a few points on any of them is a route change, a registration lapse or an AIT attempt, and each is worth a message to your provider the same day. Verification is a small line on the invoice and a large part of whether new users ever become customers; it deserves the same attention as the checkout page.


