A2P SMS Sender ID Exceptions: Approval, Scope, and Review

What a Sender ID exception means

In this guide, an exception is an internal decision to allow a specific use of a Sender ID that does not fit an organization’s standard registration or approval rules. It is not a universal regulatory category: the general sources available do not establish a common definition or procedure that applies to every country, carrier, or provider.

It is useful to distinguish three decisions: the company’s internal policy, the official requirements applicable in the destination market, and the carrier’s or provider’s commercial or operational terms. Internal approval addresses only the first. It does not prove that the use is externally authorized.

• Standard approval: the case meets the organization’s usual process and criteria.
• Internal exception: an authorized person permits a defined departure from those criteria.
• External authorization: this must be verified separately for the country, carrier, and provider involved.

Risks of an exception without limits

An ambiguous approval may be reused for a brand, campaign, destination, or route different from the one assessed. It also makes it harder to determine who accepted the risk, what evidence they reviewed, and whether the reason for the exception still applies.

The purpose of internal controls is not to bypass external rules, but to restrict the decision to what was assessed and identify when it should no longer apply. If a relevant condition cannot be verified, the request should remain pending or be rejected in accordance with the organization’s policy.

• Use for a purpose different from the one requested.
• Sending to destinations, carriers, or providers not included in the assessment.
• A change in brand, content, traffic type, or volume that alters the reviewed case.
• Continued use after approval expires or external conditions change.

Minimum documentation for assessing a request

Use a case file that allows someone else to reconstruct what was requested and decided. The fields below are a suggested internal control, not a universal list of official requirements.

Record details at a level that makes the scope verifiable. If traffic is requested for multiple markets, identify each one; do not assume that a decision for one destination applies to another.

• Requesting entity and responsible contact; the brand or entity that will appear to the recipient.
• Requested Sender ID and a description of its relationship to the brand.
• Message purpose and traffic type, such as OTP, transactional, or legitimate marketing.
• Planned countries or destinations and, where known, the carriers and providers involved.
• Expected traffic volume or pattern, noting whether figures are internal estimates.
• Reason for departing from the standard process.
• Available evidence: brand documentation, authorization from the owner, description of the flow, and external requirements consulted.
• People responsible for the request, review, and decision, and the decision date.

Verify rules, carriers, and providers separately

Verification should be carried out for the specific market and route. Consult official sources from the relevant regulator and official carrier or provider documentation where available. Record the link, consultation date, geographic scope, and any applicable conditions; if the information is ambiguous, seek confirmation from the relevant contact.

Do not infer Sender ID rules from general documents about numbering or networks. ITU-T Recommendation E.164 concerns the international public telecommunications numbering plan, but the available evidence does not show that it sets out how A2P SMS Sender ID exceptions should be approved. Similarly, general pages about 3GPP specifications or mobile networks are not enough to confirm the requirements for a specific market.

If you cannot confirm the applicable requirements, record that uncertainty and do not present internal approval as external authorization. Rules may differ between markets and change; this guide does not determine which rules are in force in any specific country, for any carrier, or for any provider.

• Identify the market, carrier, provider, and sending method before checking requirements.
• Prioritize official sources and documentation relevant to the specific party and destination.
• Archive the reference and consultation date alongside the conclusion and any open questions.
• Escalate ambiguous cases to compliance or the relevant official contact before enabling use.

Approval with assigned owners and a documented decision

Define an internal workflow appropriate to the risk and size of the organization. As a prudent control, avoid having the person requesting or directly benefiting from an exception act as its sole approver. This separation is an internal governance recommendation, not an external requirement verified by the available sources.

The decision should state whether the request is approved, rejected, or pending; explain the reason; summarize the evidence reviewed; and list the conditions that limit use. If there is disagreement or an essential external check is missing, document the escalation and do not treat silence as approval.

• Business or case owner: explains the purpose and need.
• Operations: assesses whether the flow is feasible and the limits can be enforced.
• Compliance: reviews the risk and relevant verification of external requirements.
• Designated approver: records the decision and its conditions under internal policy.
• Audit record: preserves who decided, when, based on what evidence, and why.

Limit the scope and set a validity period

Each approval should clearly describe what is authorized. To make the control enforceable, limit permission to the assessed destinations and providers, the stated purpose and traffic type, and the recorded conditions. If a system cannot enforce a limit, specify who will check it and how deviations will be detected.

Set a start date and an expiration date or review date, in accordance with internal policy. The available evidence does not establish a universal duration for these exceptions. The interval should be selected based on risk, the stability of the case, and conditions that may change; it should not be interpreted as a validity period recognized by regulators or carriers.

• Authorized Sender ID and brand.
• Permitted purpose, traffic type, and conditions of use.
• Countries or destinations, and carriers or providers included where they have been verified.
• Volume or pattern limits, if the organization sets them for the case.
• Start date, expiration or review date, and the person responsible for renewal.
• Planned action if traffic outside the approved scope is detected.

Changes, renewal, and evidence retention

Reopen the assessment before expanding or changing the use. Changes to the brand, purpose, content, markets, providers, or traffic pattern may mean that the previous evidence no longer describes the case. Determine internally which changes require a new approval and which only require updating the case file.

Renewal should not be automatic simply because the traffic has worked. Review whether the need, scope, evidence, and consulted external conditions are still valid. Retain the request, decision, sources and verification dates, subsequent changes, and outcome of each review for the period set by the organization’s retention policy.

• Request revalidation when the purpose, brand, destination, provider, or external conditions change.
• Compare observed use with the approved scope, if operational records are available.
• Document renewals, changes, and the reasons for closing or maintaining the exception.
• Apply the organization’s internal policy for record retention and access.

Monitoring, suspension, and closure

Define review signals before enabling the exception. These may include traffic to an unapproved destination, a provider change, a discrepancy between observed use and the stated purpose, evidence that is no longer valid, or the expiration date. These are suggested criteria for an internal policy, not universal regulatory triggers.

When a signal occurs, follow a proportionate procedure: limit or pause only the affected scope if this can be done safely; investigate and document; and decide whether to reinstate, modify, renew, or close the exception. Where possible, avoid affecting unrelated legitimate traffic that can be distinguished, while still meeting applicable external obligations.

• Assign an owner and a channel for reporting deviations.
• Record the event, affected scope, evidence, and action taken.
• Escalate cases that indicate potential non-compliance or loss of external authorization.
• Close the exception when it is no longer needed, its basis cannot be verified, or it has expired without renewal.