Periodic Review of A2P SMS Routes: An Operational Guide

Why Initial Approval Is Not Enough

An approval describes a route within a specific scope and under specific conditions. It does not prove those conditions are still in effect or that observed behavior will remain the same across all destinations, operators, senders, and traffic types. Messaging rules can vary by country, sender identification, and content.

Treat approval as a documented baseline, not a permanent guarantee. 3GPP specification 23.040 sets out technical aspects of the SMS service, but it does not certify the performance of a particular commercial route. Similarly, E.164 provides a structure for international numbers; it does not confirm SMS coverage or a delivery route.

• Precisely define the approved combination: provider, route or connection, destination, operator where known, sender, and traffic class.
• Record which conditions are provider statements and which have been observed in tests or operational traffic.
• Treat review as an internal governance practice: the technical references consulted do not set a universal review frequency for commercial routes.

What to Review for Each Route

Review a route by destination and use combination rather than assuming a general description applies to all traffic. Conditions can differ by country and sender; alphanumeric Sender IDs, for example, are not uniformly accepted, and some destinations require registration.

Include the intended use. A2P traffic can include OTPs, notifications, and marketing, but consent requirements and other rules depend on the jurisdiction and context. A technically available route does not make the traffic sent over it authorized.

• Destination and stated coverage scope; normalize the international number where appropriate, without treating normalization as proof of coverage.
• Included or excluded operators, if that information is available, and any communicated limitations.
• Sender type: number, alphanumeric Sender ID, or another stated format; note any registration or approval requirements.
• Message class and purpose: OTP, transactional, or marketing, as well as applicable content and consent conditions.
• Volume limits, time windows, content restrictions, or other conditions only when confirmed in documentation or provider communications.
• Connection status and the route used by your own platform; do not attribute changes to the route if they may stem from local configuration.

Set a Risk-Proportionate Review Schedule

There is no single interval supported by the sources for all routes. Set the frequency using an explicit operational rationale: the greater the impact of an outage, the sensitivity of the traffic, or the uncertainty about conditions, the shorter the review cycle may be.

Also conduct ad hoc reviews when warranted by signals such as a provider notice about changes, new or persistent errors, observed degradation, DLR discrepancies, or changes to the sender or use. A signal starts an investigation; it does not, by itself, prove that the route has changed.

• Classify each route by operational impact, volume or service criticality, uncertainty, and dependence on local conditions.
• Set a regular interval for each level and assign an owner who can bring the review forward when a relevant signal appears.
• Increase monitoring while an anomaly is being investigated or after a confirmed change.
• Define in advance which events require contacting the provider and which justify temporarily limiting traffic.
• Document that the schedule is an internal decision, not a universal obligation attributed to 3GPP, ITU, or GSMA.

Keep Evidence That Makes Events Traceable

A useful review links stated conditions with observed behavior. Keep dated versions of provider communications, their scope, and the tests performed. For messages, retain identifiers, sender, destination, timestamps, initial and subsequent statuses, and available error codes.

Status callbacks can arrive late or out of order. Preserve the event history and reconcile statuses before comparing periods; otherwise, delayed or missing callbacks can look like a change in performance.

• Provider communications, attachments, and confirmations, including dates, scope, and stated conditions.
• Test records: date, destination, operator if known, sender, traffic type, result, and method limitations.
• Available operational data: message ID, status, timestamps, destination, sender, and error code.
• Relevant configuration version and changes made during the period under review.
• A clear distinction between internal test results and live traffic; neither alone guarantees future delivery.

Compare Against the Baseline Without Treating Variations as Certainties

Compare periods with equivalent scope. Break down results by destination, operator, sender, service, status, and error code where those data are available. An aggregate figure may change because the mix of destinations or messages changed, without evidence of a route modification.

Distinguish confirmed facts from signals. An explicit provider notice about a changed condition may confirm that change within the stated scope. More errors, different latency, or more unknown statuses are signals to investigate possible causes; they do not automatically identify where the problem originated.

• Align time windows and inclusion criteria before comparing.
• Check that subsequent statuses have been reconciled and that the messages being compared have a similar scope.
• Look for changes in the mix of destinations, operators, senders, and traffic types.
• Record hypotheses separately from confirmed findings, and request more data when the cause cannot be located.
• Do not compare a one-off test with a different volume of operational traffic as though they were equivalent samples.

Choose Whether to Retain, Clarify, Limit, or Reassess

The decision should reflect the evidence and the risk, not a single status label. Retaining a route may be reasonable if its conditions are confirmed and comparable results show no signals requiring action. If information is incomplete, request clarification before expanding the scope.

Limiting traffic or starting a new assessment are management options when there is a confirmed change, a material discrepancy, or uncertainty relevant to the service. Any measure should be proportionate and tied to the affected destination, sender, or traffic type; do not extrapolate a localized issue to the entire route without evidence.

• Retain: the scope remains clear, the relevant conditions are current according to the available evidence, and there are no outstanding signals requiring investigation.
• Request clarification: the statement is ambiguous, confirmation is missing for a destination or sender, or the data cannot explain the variation.
• Limit: uncertainty or a signal has enough potential impact to justify a preventive reduction in scope while it is checked.
• Reassess: a change in conditions is confirmed, the destination or sender scope expands, the intended use changes, or the evidence no longer represents the current configuration.
• Define escalation and rollback criteria; record who authorized the decision and what evidence will trigger a review.

Record the Decision and Its Next Review

Close each review with a concise but traceable record. State what was assessed, what was excluded, what information was obtained from the provider, and what limitations affect the conclusions. This lets another person distinguish a confirmed condition from an assumption or an unresolved signal.

Assign an owner and follow-up date, even when the decision is to retain the route. Periodic review helps identify when a condition needs attention; it does not replace operational monitoring or the obligations applicable to the traffic.

• Route and scope: provider, identifiable connection, destinations, senders, and included traffic types.
• Date, owner, sources consulted, and data period analyzed.
• Confirmed conditions, observed signals, hypotheses, and outstanding questions in separate fields.
• Decision, rationale, temporary restrictions, and the person responsible for approving changes.
• Next review date and events that would bring the follow-up forward.

Mistakes That Distort a Review

Do not treat coverage as stable merely because it was previously stated or tested. Keep the scope specific and reconfirm conditions when the destination, sender, or use changes. Nor should a one-off test be extrapolated to all operators, times, or traffic types.

Interpret delivery statuses according to what the provider actually reports. A “sent” status may indicate acceptance by an upstream operator; “delivered” may reflect a confirmation received from the operator and, when available, the handset. It does not automatically constitute independent verification that a person received or read the message. A missing, late, or uninterpretable DLR also does not, by itself, prove delivery failure.

Finally, include route integrity and authorization in the review, but do not infer fraud from an isolated signal. GSMA resources on bypass and A2P fraud support considering this risk and its controls; they do not establish that a specific route is fraudulent without specific evidence.

• Do not confuse stated coverage with confirmed coverage for each destination and sender combination.
• Do not present internal tests as a delivery guarantee.
• Do not interpret a DLR as independent proof of human receipt.
• Do not attribute an aggregate variation to the route without reviewing traffic mix, statuses, and errors.
• Do not turn a risk signal or data gap into an accusation of fraud.