# How banks should monitor OTP delivery and fraud

> The KPIs banks need on the dashboard, the fraud signals worth alerting on, and the operational playbook for the OTP failure modes most likely to cost money.

- Canonical URL: https://www.broadnet.me/blog/bank-otp-delivery-monitoring-fraud-playbook
- Language: en
- Last updated: 2026-09-24
- Publisher: BroadNet (https://www.broadnet.me)

- Published: 2026-04-30
- Author: BroadNet Industry Research

For 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.

1. End-to-end delivery rate — fraction of OTP requests where the destination operator returned a positive [DLR](https://www.broadnet.me/answers/what-is-dlr) within the OTP validity window. This is the real delivery number, not the submission acceptance rate.
2. 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.
3. 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.
4. 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.
5. 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](https://www.broadnet.me/answers/what-is-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](https://www.broadnet.me/products/hlr-lookup) 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](https://www.broadnet.me/answers/hmac-sha256-dlr-signing) 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](https://www.broadnet.me/products/otp) 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](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting) live in production; diagnose before tuning.

## Related reading

- [Why OTP messages fail and how to fix delivery issues](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting)
- [How flash-call verification affects operator A2P revenue](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact)
- [Omnichannel messaging strategy for ecommerce and logistics](https://www.broadnet.me/blog/omnichannel-messaging-ecommerce-logistics-strategy)
- Glossary — [what is OTP](https://www.broadnet.me/answers/what-is-otp), [what is SMS pumping](https://www.broadnet.me/answers/what-is-sms-pumping), [what is a DLR](https://www.broadnet.me/answers/what-is-dlr)
- Product pages — [OTP service](https://www.broadnet.me/products/otp) and [MyOTP voice OTP](https://www.broadnet.me/products/myotp)
- Coverage — [UAE OTP and TDRA-compliant routing](https://www.broadnet.me/coverage/uae)