Aadhaar OTP Timeouts Strand 14% of KYC at Step 2

Roughly 14% of Aadhaar-based KYC attempts on Indian online gaming platforms fail at the second step — the OTP verification stage — and the dominant cause is not fraud or mismatched data but timeout: the one-time password expires, the SMS arrives late or not at all, and the session is abandoned. The figure comes from an operational review of KYC funnel logs across a sample of operators, and it points to something the sector rarely discusses in public: a meaningful share of compliance friction is infrastructural, not behavioural. When a sixth of your onboarding cohort stalls on a six-digit code, the problem is less about player diligence than about the plumbing underneath.

Where the funnel actually breaks

Aadhaar KYC, in the form most operators use, runs through a UIDAI-authorised AUA/KUA endpoint that returns an OTP to the mobile number registered against the Aadhaar record. The flow looks simple on paper: enter Aadhaar number, trigger OTP, enter OTP, match demographic data, proceed. In practice, step two absorbs almost all the variance.

The review data suggests three distinct failure modes, and they behave differently:

• True timeout (OTP expired before entry): the largest single bucket, at roughly 6.5–7% of all attempts. UIDAI OTPs carry a short validity window, and players who trigger the code, get distracted, or wait for a second device to hand over the message routinely cross it.
• Delivery latency or non-delivery: another 4–5%. This clusters around specific telecom circles and around DND (Do Not Disturb) registrations that were never reconciled with the Aadhaar-linked number.
• Session and retry exhaustion: the remainder, where repeated OTP requests hit rate limits or the operator's own session token expires mid-flow.

The distinction matters because the first bucket is fixable with interface design, the second is a telecom integration problem, and the third is a policy-and-configuration problem. Lumping them together as "KYC failure" hides where the leverage is.

The timeout bucket is an interface problem

A 6.5% loss to OTP expiry is, in most product organisations, an unacceptably large avoidable drop. The mechanics are mundane: a player initiates KYC on a desktop, the OTP lands on a phone in another room, and by the time it's retrieved the code is dead. Operators who surface a live countdown, auto-detect the SMS on Android via the SMS Retriever API, or offer a one-tap resend without restarting the flow report materially lower abandonment at this step. None of these are exotic; they are standard onboarding hygiene that much of the sector has not adopted because KYC is treated as a compliance cost centre rather than a conversion surface.

There is a regulatory wrinkle. Any redesign has to stay inside UIDAI's permitted request patterns and the operator's AUA obligations, and aggressive auto-retry can run foul of rate limits that exist precisely to prevent enumeration attacks. The design space is narrower than a typical signup funnel, but it is not empty.

The telecom variable nobody prices in

Delivery latency is the failure mode operators control least and understand poorest. OTP delivery depends on the player's carrier, the routing between the AUA gateway and that carrier, and whether the Aadhaar-linked number is on DND. A number registered under DND can still receive transactional OTPs in principle, but misconfigured sender IDs and stale DND reconciliation produce silent failures that look, from the operator's dashboard, identical to a player who simply gave up.

This is where the 14% figure becomes more than an onboarding statistic. If a meaningful slice of failures is telecom-side, then operators are declining or delaying legitimate players for reasons that have nothing to do with the player's eligibility, age, or document integrity. In a market where the compliance posture is already under scrutiny, misattributing infrastructure failure to player behaviour is both a commercial error and a fairness problem.

The practical response is instrumentation. Operators who log OTP request timestamp, delivery receipt, carrier circle, and DND status separately — rather than collapsing everything into a single "KYC failed" event — can see which circles and carriers are dragging. Without that telemetry, the 14% is a number you can measure but not act on.

What the retry-exhaustion tail tells you

The smallest bucket is also the most revealing. Session-token expiry and rate-limit exhaustion at step two usually indicate that the operator's KYC flow is tightly coupled to a single session with no graceful resume. A player who requests three OTPs in quick succession — a natural response to non-delivery — can trip a rate limit and land in a state where the only path forward is to start over, often after a cooling-off period. Each restart adds friction and, for a proportion of players, ends the attempt permanently.

Why this is a compliance question, not just a UX one

It is tempting to file all of this under product optimisation. But KYC delays have downstream regulatory consequences. Under the PMLA framework and the RBI's master directions on KYC, operators are expected to complete verification within defined timelines before allowing full account functionality; a player stuck at step two sits in a limbo state that is awkward to document and easy to handle inconsistently. If 14% of attempts stall, the operator's own audit trail shows a large population of partially-verified accounts, and how those accounts are treated — frozen, restricted, or quietly allowed limited play — becomes a supervisory question.

There is also the matter of the players themselves. Aadhaar OTP failure disproportionately affects users on older handsets, on carriers with weaker routing in semi-urban circles, and on numbers where DND status was set years ago and forgotten. That is not a random sample of the player base; it skews toward exactly the demographic that online gaming regulators and responsible-gambling advocates worry about — less digitally fluent users who may not understand why their verification keeps failing and who have no clear channel to resolve it. A timeout that a savvy user retries past can be a full stop for someone else.

Operators have a responsible-gambling interest here too, independent of compliance. A player who cannot complete KYC cannot set deposit limits, cannot access self-exclusion tooling tied to a verified account, and may drift toward unregulated alternatives that ask fewer questions. Friction at the verification gate is not neutral; it redistributes players toward venues with weaker safeguards.

The open question: who owns the 14%?

The uncomfortable part of the 14% figure is that no single party owns it. UIDAI sets OTP validity and request patterns. Telecom operators control delivery. AUA gateways sit in between. Operators own the interface and the retry logic. Each can point at the others, and in practice each does. The result is a failure mode that is visible in aggregate but unattributed in detail, which is precisely the condition under which it persists.

The question worth putting to the sector is not whether 14% is acceptable — it plainly isn't, as either a conversion number or a compliance one — but whether operators will build the telemetry to decompose it. An operator that can say "our step-two failure is 6% timeout, 5% delivery, 3% retry exhaustion, concentrated in these four circles" can fix most of it within a quarter. One that can only report "14% failed KYC" will keep treating an infrastructure problem as a player problem, and keep declining legitimate users for the sin of owning a phone that received a text four seconds too late. Until someone publishes that decomposition, the 14% will remain a number the industry measures and quietly declines to explain.