TL;DR: To audit your SMS vendor's OTP delivery, send test messages through your production route to independent handsets with real SIM cards on destination networks. Compare what actually arrives against what your vendor reports as delivered. TelQ runs this across 180+ countries using physical handsets — your vendor's dashboard reflects their system's output, not what users' phones received.
Somewhere between the API response and the user's phone, OTPs are vanishing — and the vendor's own reporting can't tell you where. The delivery dashboard says 98%. The login completion rate says something else. You've built internal dashboards around the vendor's data, and the numbers look healthy right up until customer support tickets start telling a different story.
This is a common gap at fintech companies handling digital payments. In one documented case from May 2024, a US consumer fintech with roughly 200,000 monthly OTPs saw its SMS bill jump from $2,500 to $48,000 in a single month — fraudulent traffic to three African country codes was generating 12,000 fake OTP requests per day, and the vendor's reporting showed nothing unusual until the invoice arrived. The disconnect isn't always that dramatic. But it's always invisible if you're only looking at the vendor's data.
Here's how to audit what's actually happening.
Why your vendor's delivery dashboard isn't an audit
When your SMS vendor sends an OTP, their system generates a delivery report (called a DLR in telecom). That report travels back through the routing chain and surfaces in your vendor's dashboard as "delivered."
The problem: a DLR reflects what the vendor's infrastructure reported, not what the recipient's handset received. The confirmation can be generated before the message reaches the destination carrier, or by a system that never checked whether the phone actually got it. A delivery report is a record of what the routing system said happened. It's not proof of receipt.
This means treating your vendor's dashboard as audit evidence is circular. You're asking the vendor whether the vendor delivered. The data comes from the same infrastructure you're trying to verify.
For OTP traffic specifically, the stakes are concrete: a "delivered" status that doesn't correspond to a received message means a user staring at a login screen, waiting for a code that won't arrive.
What an OTP delivery audit actually checks
A real audit goes beyond the vendor's reporting. Four things matter for OTP traffic:
Actual delivery vs. reported delivery. Did the message reach a real phone on the destination network, or did the vendor's system report success without confirmed handset receipt? When these diverge, you have what the industry calls a fake DLR: a delivery report claiming success while the handset received nothing.
Sender ID integrity. Did the message arrive showing your company name or shortcode, or was it changed in transit? In some markets, carriers modify or strip Sender IDs without notification. A user receiving an OTP from an unfamiliar sender instead of your brand name may ignore it or flag it as suspicious. The Sender ID guide covers how this varies by country.
Latency. Did the OTP arrive within the code's validity window? NIST SP 800-63B recommends short-lived OTP codes, and most implementations use 30- to 120-second windows. An OTP that lands 90 seconds after the user requested it, on a 60-second expiry, is functionally undelivered. Your vendor's report will show it as a successful delivery. Your user sees an expired code.
Content integrity. Did the OTP code arrive intact? Message content can be modified in transit: characters altered, text truncated, encoding broken. If the 6-digit code your system sent arrives as a 5-digit code on the handset, the authentication fails regardless of delivery status.
Each of these failures looks like a successfully delivered message in your vendor's reporting. None of them is visible without checking from outside the vendor's system.
How to run an independent delivery audit
The method is straightforward: send a test message through the exact route your production OTPs use, to a real phone with a real SIM card on the destination network, and record what arrives.
Three things make the result meaningful.
First, the test has to go through your production route. If you send through a separate test channel or a different API endpoint, you're auditing a route your OTPs don't travel. The whole point is to see what the production path does to your messages.
Second, the receiving phone has to be independent of your vendor's infrastructure. A handset with a real SIM on the actual destination carrier, not a virtual number, not an emulator, not anything your vendor controls. You need a receiver that has no relationship with the routing chain you're verifying.
Third, the test can't be detectable as a test. Some routes treat known test traffic differently from production messages. If the route recognizes the test number as belonging to a testing service, it may process that message with higher priority or different handling than your real OTPs get. The SMS whitelisting guide explains why this matters and how to account for it.
Once the message arrives (or doesn't), you compare: Did the handset receive it? What Sender ID appeared? How long did delivery take? Was the content intact? And what did your vendor's DLR report for the same message?
The gap between those two data points is your audit finding.
What the results tell you
The comparison between vendor reporting and handset receipt produces a few distinct patterns.
When the vendor reports delivered and the handset received the message with correct Sender ID, intact content, and acceptable latency, the route works for that destination. That's the outcome you want.
When the vendor reports delivered and the handset received nothing, the route has a delivery gap. Your vendor's system generated a success confirmation for a message that never arrived. For OTP traffic, every instance of this pattern is a failed login your analytics can't attribute to delivery.
When the Sender ID changed in transit, you have a brand integrity problem in that market. The OTP arrived, but from a number or alphanumeric string your user doesn't recognize. Completion rates drop even when delivery technically succeeds.
When latency exceeds your OTP validity window, the code expires before arrival. Your vendor will report this as delivered. Your user can't use the code. If you're running 60-second or 30-second OTP windows, even moderate routing delays become authentication failures.
When the message content was modified, the OTP code may have been altered or truncated. The user enters what they received, it doesn't match what your system generated, and the authentication fails. The vendor shows a clean delivery.
Scaling the audit across markets
If your fintech company sends OTPs to users in a handful of countries, you could run this audit manually with local SIM cards and some spreadsheets. Most fintech companies send to dozens of markets.
Manual handset checking doesn't scale. You need test numbers across the markets your users are in, on the actual carrier networks they use, with SIM cards that aren't detectable as test infrastructure.
TelQ runs this across 180+ countries and 1,500+ networks, using real SIM cards on physical handsets. The platform records actual delivery, Sender ID as displayed, content as received, and latency, then compares it against the vendor's DLR. Since 2016, TelQ has processed over 100 million tests using this approach. For a broader view of how delivery auditing fits into an SMS testing methodology, the SMS Testing Guide covers the full framework.
Your vendor's reporting tells you what their system did. An independent audit tells you what your users received. If you're running OTP traffic and want to close that gap, start testing with TelQ.
FAQ
What is an SMS vendor delivery audit?
An SMS vendor delivery audit verifies whether your vendor's reported delivery metrics match what recipients' phones actually receive. It works by sending test messages through your production route to independent handsets on destination networks and comparing actual receipt against the vendor's delivery reports. The audit checks delivery confirmation, Sender ID accuracy, message latency, and content integrity.
Can I audit OTP delivery using my vendor's own reports?
No. Your vendor's delivery reports reflect what their routing infrastructure reported, not what the recipient's handset received. A delivery report can show success when the message never arrived, when the Sender ID was changed, or when the content was modified in transit. An independent audit requires checking from outside the vendor's system, on a real phone on the destination network.
How often should I audit my SMS vendor?
Route quality changes over time. A route that delivers reliably today can degrade next month due to carrier policy changes, routing adjustments, or supplier decisions you won't be notified about. For OTP-critical traffic, continuous monitoring catches degradation before it affects login completion rates. At minimum, audit after any route change and periodically across your highest-volume markets.
What does it mean when the vendor says delivered but the OTP never arrived?
It means the vendor's system generated a success confirmation without verified handset receipt. The delivery report was produced by the routing infrastructure before the message reached the user's phone, or the system confirmed delivery without checking. This is called a fake DLR. For OTP traffic, each instance is a failed authentication that appears as a successful delivery in your vendor's data.
How do I audit SMS delivery across multiple countries?
You need test numbers on real SIM cards in each destination country, on the actual carrier networks your users are on. TelQ provides this across 180+ countries and 1,500+ networks using physical handsets. Each test sends through your production route to a real device on the destination network, recording delivery, Sender ID, latency, and content, and compares the result against your vendor's delivery report.
