A fintech reaches 99.4% OTP delivery in India on DLT-registered direct routes

The Customer - A digital payments and lending platform based in Bengaluru with roughly nine million monthly active users, sending around 42 million transactional SMS per month - one-time passwords, transaction confirmations and repayment reminders - almost entirely to Indian mobile subscribers.

The Situation - Transactional messages were routed through a single aggregator on a per-message price. Reported delivery sat around 94 percent, but the platform's own verification data told a worse story: a growing share of users requested a second OTP, and login-failure tickets were the largest support category. Median time from API submit to delivery receipt was 11 seconds, with a long tail beyond a minute at peak hours. The team also noticed a rising volume of OTP requests to number ranges with almost no completed verifications, and the SMS bill was growing faster than the user base.

The Challenge - Three problems were tangled together. First, part of the traffic was being routed through intermediate hops where messages were delayed and DLR status was generated by the intermediary rather than the operator, so the reported delivery figure was flattering. Second, the customer's DLT registrations had drifted: templates had been edited in the application faster than they were re-registered on the operators' DLT platforms, and messages that failed template matching were being scrubbed silently. Third, the abnormal OTP requests were artificially inflated traffic, with a fraud ring triggering the sign-up flow at scale towards revenue-share ranges. Any fix had to preserve throughput of several thousand messages per second at peak and could not interrupt authentication for live users.

What We Did - We moved the customer's transactional traffic to Dollu direct operator connections for all major Indian operators, with operator-originated delivery receipts and per-operator latency monitoring. Our messaging team audited every DLT header and template against what the application actually sent, re-registered 63 templates with correctly declared variables, and set up a change process in which template edits are registered and approved before the application is allowed to use them, with the API rejecting content that does not match an approved template rather than sending it into a scrub. On the AIT side we enabled per-number, per-IP and per-device velocity limits at the API, blocked the ranges showing request-to-verify ratios below threshold, and gave the customer's engineers real-time visibility of request and conversion rates by prefix. Voice OTP fallback over Dollu's Indian origination was added for the small share of handsets that consistently failed to receive SMS.

The Results - Measured against the customer's own verification events rather than reported DLRs, OTP delivery rose from 94.1 percent to 99.4 percent within a month of migration. Median submit-to-delivery latency fell from 11 seconds to 3.4 seconds, and the 95th percentile at peak hour dropped below nine seconds. Scrubbed messages fell to under 0.1 percent after the template clean-up. Artificially inflated traffic, which had reached roughly 6 percent of OTP volume, fell to a fraction of a percent, and monthly SMS spend fell 14 percent even as message volume grew with the user base. Login-failure tickets dropped by more than half over the following quarter, and the customer has since extended the same route and template governance to its promotional and RCS traffic.