Reviewing Changes to A2P SMS Templates: How to Spot Risks Before Publishing

Why a Small Change Deserves a Full Review

A change of just a few words can alter the message's meaning, how the sender is perceived, or the information the recipient receives. It can also introduce an unexpected variable, change a link, or affect SMS encoding and length. That is why comparing only the text at a glance is not enough.

In A2P traffic, traceability is an important operational concern: analysis by Telefónica and Analysys Mason links traffic growth with greater difficulty tracing the origin of SMS messages and with security and fraud risks. An internal change log helps identify who proposed, reviewed, and approved a version; on its own, it does not verify origin to third parties or guarantee that a message will be delivered.

• Treat every change as a new version, even if it seems minor.
• Review the content and technical impact separately.
• Do not present internal approval as a guarantee of acceptance by an operator, provider, or regulator.

What to Record for Each Version

Create a record for each template and version. Include a stable identifier, date, reason for the change, and status—for example, draft, under review, approved, or retired. Keep the previous approved version so the comparison has a clear reference point.

Record the message's purpose, intended audience, destinations, and configured sender. Add the exact text, permitted variables and their expected formats, intended links, and any conditions of use. Also note which team or person proposed the change, who reviewed each control, and who made the final decision.

Destination and sender information helps define the scope of the review, but applicable requirements may vary by country, operator, provider, and traffic type. Do not assume that a template accepted for one destination can be used unchanged for another.

• Identity: template ID, version number, date, and status.
• Use: purpose, audience, destinations, and sender.
• Content: exact text, variables, format, and links.
• Governance: author, reviewers, approver, decision, and associated evidence.

Compare Substantive Changes, Not Just Text Differences

Compare the proposal with the latest approved version and retain both. A diff view can help locate insertions and deletions, but the review must interpret what changes for the recipient and for operations.

Classify changes by impact: purpose or audience; sender or destination; meaning of the offer or notification; variables; link; and technical characteristics. Replacing one word can change a condition, while a formatting correction may not alter the meaning. The team should justify its classification rather than rely solely on an automated comparison.

If a change expands the intended use, adds a new destination, or alters the purpose, pause publication until internal authorizations and applicable requirements have been reviewed. If it is unclear whether the new version remains within the approved scope, treat it as a substantive change.

• Compare against the authorized version, not a recent unapproved draft.
• Review meaning, audience, and context as well as literal differences.
• Mark any change with unclear scope or authorization as pending.

Validate Variables, Links, Encoding, and Segments

Maintain an explicit list of permitted variables for each template. For each one, specify its name, whether it is required, and the expected value type or format. Check that no variables are missing, no unknown placeholders appear, and sample substitutions do not produce ambiguous or inappropriate text. If values can vary widely in length, test representative cases across the expected range.

Review links separately: confirm that the destination is expected, the generated format is not truncated, and any redirect path is authorized by the internal process. Do not include personal data or secrets in test links. A technical review does not prove that a web destination is safe in every context or that an operator will accept the message.

Check the effective encoding of the text that will be sent. Available characters and how they are represented can affect message length; characters outside the GSM 03.38 repertoire may require Unicode encoding, depending on the implementation. Calculate segments using the same component or configuration that will be used for sending, and verify the result against the provider's or route's technical documentation. Do not assume a universal limit: capacity and calculation depend on encoding and implementation.

• Reject undefined variables, variables that are empty when not allowed, or values in an unexpected format.
• Validate the fully assembled message, not just the template with placeholders.
• Check encoding and segments using the effective sending configuration.
• Document the calculation tool or method; do not extrapolate limits from one route to another.

Separate Internal Controls from Local Obligations

An internal workflow may require a documented purpose, a variable list, approval, and evidence of testing. These controls help maintain consistency and traceability, but they do not replace a review of the rules that apply to the country, operator, provider, sector, and message type.

Before approval, confirm that the audience and content are consistent with the applicable authorization basis and recorded contact preferences. Also review how opt-out requests are handled where relevant. Specific requirements for consent, disclosures, record retention, and opt-outs are not the same in every jurisdiction; consult official sources or qualified advice for each destination.

Colombia's CRC has put forward a proposal to verify who sends business messages, determine whether they are legitimate, and ensure their traceability. The source describes this as a proposal, not as a general obligation currently in force. Do not turn this initiative into a rule for other countries or make claims about the current status of a regulation.

• Identify which local requirement was checked, for which destination, and against which source.
• Verify that the content matches the authorized purpose and audience.
• Do not infer consent, identity, or delivery from a technical validation.

Test Against Defined Acceptance Criteria

Before testing, define what counts as correct: complete variables in valid formats, expected link, correctly rendered text, verified encoding and segments, and a sender and destination within the approved scope. Record the result and the configuration used.

Use controlled test data and recipients authorized for testing, in accordance with local rules and provider policies. Do not send a template to real users if it has not yet been authorized for that use. A technical test checks specific aspects of the process, but does not prove that an entire audience has consented or guarantee acceptance, delivery, or display on a device.

If the provider returns a delivery status, preserve its meaning and level of certainty. A received DLR does not necessarily mean receipt has been independently verified on the device. Record reported statuses, errors, and any available observations separately, without presenting them as a guarantee.

• Set acceptance criteria before running tests.
• Record the date, version, configuration, result, and responsible person.
• Keep technical testing, authorization to use, and delivery evidence separate.

Publish, Monitor, and Be Ready to Roll Back

Publish only the approved version and link the sending configuration to its identifier. If the system allows the scope to be limited, apply the change in a controlled way within the authorized destinations and uses; do not expand the audience just because a test worked.

After publication, monitor rejections, formatting errors, reported behavior changes, and differences between expected and observed results. A coinciding change does not by itself prove that the template caused the issue: compare the version, destination, configuration, and available provider information.

Decide in advance who can stop sending and how to restore the last approved version. In the event of an incident, record what was stopped, which version was active, who decided to roll back, and what evidence supported the decision. Reverting reduces exposure to a known change, but does not guarantee acceptance or delivery of subsequent messages.

• Link publication to the approved version.
• Set owners and pause or rollback criteria before launch.
• Keep the incident and corrective-action outcome in the history.

Checklist and Auditable Closeout

Close each change with an explicit decision: approved, rejected, or pending. Attach enough evidence to reconstruct what was reviewed, without retaining more personal data than necessary. Make sure the published template matches the approved version and that the previous version can be located.

A useful record does not need to promise that it will prevent filtering or delivery problems. Its value is more concrete: it lets you explain the scope of a change, repeat validations, identify owners, and respond accurately to an incident or compliance inquiry.

• Is there an approved reference version and an identifiable proposal?
• Were the purpose, audience, sender, and destinations documented?
• Were differences in meaning and scope reviewed?
• Are the variables and links permitted and validated?
• Were encoding and segment count checked using the effective configuration?
• Were the applicable requirements checked for each destination?
• Were tests run with defined criteria, data, and authorized recipients?
• Are approvers, evidence, the decision, and rollback procedure recorded?