or a bank, an OTP is not a notification. It is a control on the most security-sensitive customer flows — login, transaction confirmation, beneficiary addition, card activation, device binding. The cost of an OTP that does not arrive is a stuck customer; the cost of an OTP that does arrive but is intercepted, replayed, or exhausted by automated probing is direct fraud loss and a regulator conversation. Banks therefore need a sharper OTP operational practice than other A2P senders: better instrumentation, more aggressive fraud-pattern alerting, and a documented playbook for the failure modes that are predictable. This is what that practice looks like.
The five KPIs that belong on the wall
Most banks measure OTP delivery as a single number — 'delivery rate' — and that number is almost always wrong, because the delivery rate the messaging provider reports is the submission success rate, not the rate at which an OTP actually reached a customer who used it. Five numbers, tracked per channel and per destination operator, give the real picture.
- End-to-end delivery rate — fraction of OTP requests where the destination operator returned a positive DLR within the OTP validity window. This is the real delivery number, not the submission acceptance rate.
- Latency p50, p95, p99 — submission to handset, per channel, per destination operator. Tracked as a time series, not a single number; the alerting condition is degradation against a rolling baseline rather than an absolute threshold.
- Retry rate — fraction of OTP requests that resulted in a user-triggered or system-triggered resend within the validity window. A rising retry rate is the earliest signal that primary delivery is degrading; it almost always precedes the explicit delivery-rate drop.
- Sender-ID rejection rate — fraction of submissions rejected at the operator boundary on sender-ID grounds. A non-zero number here is a registration problem; it should be alerted on as zero-tolerance.
- OTP completion rate — fraction of OTP requests where the user successfully entered the code. This is the only KPI that matters commercially; everything else feeds into it. A 99% delivery rate paired with a 70% completion rate tells you the message arrived too slowly or the UX around entry is broken; delivery without completion is not success.
The fraud signals worth alerting on
OTP infrastructure is also OTP attack surface. Three categories of abuse are common, all detectable from data the bank already collects.
1. Repeated OTP requests for the same MSISDN
An attacker probing the OTP flow on a single account — manually, or via a script — produces a characteristic signature: many OTP requests for one phone number, often clustered tightly in time, sometimes with rotating IP addresses or User-Agent strings on the originating session. The legitimate equivalent (a user who genuinely cannot find the code) tops out at three to five attempts in a few minutes; an attack profile is dozens or hundreds. Alert thresholds should be tight: more than ten OTP requests for one MSISDN in fifteen minutes is almost always either an attack or a broken integration, both of which deserve attention.
2. Geographic and behavioural anomalies
An OTP requested from a session originating in one country, for a phone number historically associated with another country, is not necessarily fraud — it could be a customer travelling — but it is worth elevating to a step-up authentication, not silently honoring. Pair this with device-fingerprint changes (new browser, new device ID, new application install) and the signal is stronger. The bank's risk engine should already do this for transaction authorisation; extending it to OTP issuance is a quick win.
3. Throttled enumeration and credential-stuffing
A more sophisticated attacker enumerates account identifiers through the password-recovery flow, deliberately staying under the per-account OTP throttle but probing many accounts in parallel. The signature is a high rate of OTP requests across many distinct MSISDNs from a small source range, often with low individual per-MSISDN counts that fly under per-account alerting. Detection requires aggregating across source origins (IP, device class, session pattern) rather than per-account. This is exactly the pattern of SMS pumping attacks that some attackers run against OTP infrastructure to monetise the per-message provider rebates; protecting against it protects against both fraud and provider-cost inflation simultaneously.
The operational playbook for the predictable failure modes
Three classes of OTP incident recur at every bank. Having a written playbook for each — not a runbook generated under pressure — separates a 15-minute recovery from a 4-hour one.
Playbook 1 — destination operator route degradation
Signal: latency p95 climbing on a specific destination operator while the others stay flat, delivery rate to that operator dropping. Action: confirm the degradation is route-side and not internal (submission acceptance is still 100%), failover OTP traffic for that operator to the secondary route in the routing engine, notify the provider's NOC for confirmation and ETA. Recovery: once the primary route's metrics return to baseline for 30 minutes, restore. The full playbook should be ten lines and exercised quarterly.
Playbook 2 — sender-ID rejection spike
Signal: sender-ID rejection rate jumps from zero to non-zero, almost always for one destination market. Action: check whether the sender-ID registration has lapsed or been revoked at the destination regulator (most common cause), confirm with the local aggregator, fall over to a backup registered sender ID for the affected market if available, escalate the registration. Recovery time is governed by the regulator, not the bank; the playbook's job is to limit blast radius while waiting.
Playbook 3 — coordinated OTP-pumping attack
Signal: cost per successful OTP rises sharply; submission volume to specific number ranges (often premium-rate-adjacent or specific country prefixes) spikes; completion rate on those submissions is near zero. Action: enable destination-prefix allow-listing if not already on (this is the single most effective control), throttle OTP issuance from the affected origination paths, contact the messaging provider's fraud team. Recovery: turn off the allow-listing once the attack ceases — for most banks it is not safe to keep it permanently disabled. See HLR Lookup pre-flight as a structural mitigation against this class.
Architecture choices that make the playbooks possible
The playbooks above all depend on architectural decisions made before the incident, not improvisations during it. Three are worth being deliberate about.
- Multi-channel OTP from day one — at minimum SMS and voice; ideally SMS, WhatsApp Authentication template, and voice with documented automatic failover. Failover is a control, not a fallback; it should be invokable per route and per category without code changes.
- Per-channel and per-operator delivery and latency telemetry — without it, the dashboards above are aspirational. The data has to come from the messaging provider as structured DLR feeds, not as monthly PDF reports.
- Documented sender-ID inventory with renewal dates — the bank's compliance team should own this register, not the messaging provider; lapses caused by a provider's renewal oversight are still the bank's problem when traffic stops arriving.
Talking to the provider — what data should flow back
A bank-grade messaging contract specifies the operational data the provider returns, not just the unit-pricing schedule. Expect, at minimum:
- Real-time DLR webhooks the bank can authenticate (for example a shared-secret HMAC-SHA256 signature if the provider signs callbacks, or IP allow-listing) so the bank can reconcile submissions against actual delivery in its own SIEM.
- Daily delivery and latency reports broken down by destination operator, sender ID, and route, suitable for ingestion into the bank's observability stack.
- Monthly incident summaries with timeline, root cause, and mitigation for any provider-side incident that affected the bank's traffic.
- Direct escalation contacts at the provider's NOC and fraud team, on a SLA with named response times.
BroadNet's OTP service ships per-channel and per-operator delivery, latency, and completion analytics as structured feeds — and the same fraud-detection layer that protects the operator side is available to enterprise OTP customers as pre-flight scoring against requests before they convert to billable sends.
Regulator-readiness — the often-overlooked dimension
Central banks and financial-services regulators increasingly ask explicit questions about OTP delivery infrastructure during inspections: what is the SLA, what is the failover, what is the audit trail, how are fraud patterns detected and responded to. Banks that can answer in five minutes from a standing operational dossier sail through; banks that have to assemble the answer in the middle of an inspection do not. The KPIs and playbooks above are the inputs to that dossier; treat them as compliance artefacts as well as operational ones.
A common anti-pattern to retire
Many banks instrument OTP as a feature of the auth service rather than as a system with its own ownership. The result: the messaging integration is owned by whoever built the auth flow originally, often someone who has since changed teams; nobody is paying attention to per-operator delivery telemetry; the first sign of degradation is a customer-support spike that the support team cannot tie back to a messaging issue. The remediation is structural — a named owner for OTP infrastructure with a small standing team (or a clearly-named partner team), a quarterly review of the KPI dashboard, and an annual end-to-end exercise of the playbooks above against a realistic incident scenario. The institutional bank-grade messaging providers all do quarterly joint reviews with their customers as part of the engagement; if yours does not, ask for it.
What good looks like, in numbers
A well-run bank OTP infrastructure, sending into a regulated GCC market on direct operator routes, with the fallback chain and the fraud controls described above, should reach: 99%+ end-to-end completion rate (not just delivery — the customer actually verified), p95 latency under five seconds on the primary channel, sender-ID rejection rate of zero, retry rate under 3% (above which the user experience and the cost are both degrading), and fraud-related OTP request blocking under 1% of legitimate traffic (false positives matter — blocking too aggressively is its own customer-experience problem). Banks materially below these numbers have one or more of the seven failure causes in the OTP delivery troubleshooting guide live in production; diagnose before tuning.
Related reading
- Why OTP messages fail and how to fix delivery issues
- How flash-call verification affects operator A2P revenue
- Omnichannel messaging strategy for ecommerce and logistics
- Glossary — what is OTP, what is SMS pumping, what is a DLR
- Product pages — OTP service and MyOTP voice OTP
- Coverage — UAE OTP and TDRA-compliant routing