One Market, Four Possible Causes: Untangling OTP Delivery Anomalies

Signals to watch

• delivery anomaly clustering in one market
• mixed signal stack
• upstream routing unknown

Composite industry case. This page describes a reusable operating problem and decision method. It does not represent a named customer, real conversation, contract, revenue result or testimonial.

You notice it first in the Monday review: a cluster of one-time passcode delivery failures concentrated in a single market. The number of complaints is still small, but the pattern is real. You cannot yet say whether the cause is a number format the gateway handles poorly, a carrier with degraded reach, a risk control rule that recently tightened, or an upstream routing table that shifted overnight. The signals are all mixed together.

If you treat them as one problem, you will either overreact—changing something that was working—or underreact while the next complaint wave arrives before you finished isolating the variables.

Why the mixed-signal trap is so common

Operations leads in identity verification inherit a stack they did not build. Number formatting, carrier selection, risk evaluation, and upstream routing are maintained by different teams or vendors. When delivery anomalies cluster in one market, each team looks at its own layer and declares it clean.

The carrier team checks latency and sees normal values. The risk team reviews recent rule changes and finds nothing deployed last week. The routing team confirms the upstream path is active. Individually, every layer looks innocent. Collectively, the delivery failure persists.

The default response is to escalate everything at once. That floods engineering with unprioritized signals and guarantees a slow, reactive cycle. The real gap is not technical—it is the absence of a lightweight separation method that one person can run before pulling in anyone else.

A four-layer evidence review framework

Before you file a single ticket, separate the four variables using logs and timestamps you already have. You do not need a new tool for this step.

Layer one—number format. Pull all failed delivery attempts in the affected market and group them by number format pattern. Compare against a random sample of successful deliveries from the same period. If one format family appears disproportionately in the failure group, the gateway or carrier may handle that format differently. Flag the format and move on.

Layer two—carrier. Within the format that looks suspicious, group failures by carrier. If failures spread evenly across carriers, the format is the more probable cause. If failures cluster under one carrier, that carrier deserves a deeper look. You now have a directional hypothesis instead of a generic escalation.

Layer three—risk control. Examine the last timestamp change for any risk control rule that applies to the affected market or format. Compare matched and unmatched examples: pull one delivery the rule blocked and one it allowed during the same minute. If the allowed example shares the same surface characteristics, the rule may be misconfigured rather than correctly protective.

Layer four—upstream routing. If the first three layers show no clear divergence, check whether the upstream route for the affected market changed in the past 72 hours. Route tables often update without a corresponding operations notification. A route change that redistributes traffic to a less reliable peer can produce exactly the clustered pattern you see.

Document each layer’s finding in a single table with three columns: evidence seen, evidence missing, and decision window (how long you have before the next review cycle). This table is your action document.

The next step belongs to a human reviewer

Once the four-layer evidence is organized, one person must decide what to act on first. This decision cannot be automated because it depends on factors outside the logs: vendor relationship maturity, compliance calendar windows, and whether the market is strategic or exploratory. A rule engine cannot weigh those contexts.

The human reviewer picks one layer, assigns an owner, sets a decision deadline based on the evidence table, and defers the other layers to the next cycle. This prevents the whiplash of trying to fix everything at once.

What continuous signal discovery adds

A framework run manually each week catches clustered anomalies after they appear. When the same separation logic runs continuously—comparing format, carrier, risk, and routing signals against their own recent baselines—the clustering is visible before complaints accumulate. The evidence table fills in as signals drift, and the human reviewer inherits a pre-sorted set of candidate actions instead of a raw log dump.

The method stays the same. The separation of variables is what makes the review productive. Technology accelerates the signal discovery and evidence assembly, but the review itself—choosing which action, with which owner, by when—remains a human skill that no log aggregation can replace.

Frequently asked questions

How do I know whether the carrier or the number format caused a delivery drop?

Compare delivery rates for the same carrier across two number formats that share the same upstream route. If the gap persists, the format is the more likely variable. If the gap disappears, the carrier or route was the dominant factor.

What is the minimum evidence I need before asking engineering to change risk controls?

A log showing the exact control rule that triggered, the message content it evaluated, and at least one matched and one unmatched example of that rule from the same time window. Without the contrast example you cannot tell whether the rule is too broad or misconfigured.