SMS Compliance for Aggregators: A Destination-Led Checklist
Compliance for a messaging launch is not one global rulebook. It is a set of destination-specific answers, gathered before traffic moves and refreshed as markets change. The operational failure mode is almost always the same: a team satisfies one rule set and assumes it has satisfied the others.
Four rule sets that are not interchangeable
- Local law: statutory rules on marketing consent, privacy and personal data in the destination market.
- Carrier and network policy: sender registration, template approval, content restrictions and traffic classification enforced by the network regardless of what the law permits.
- Sender arrangements: whether your alphanumeric sender, long number or short code is permitted, registered and consistently supported for that market and use case.
- Service terms: what your own provider agreement allows you to send, and through which route.
Satisfying local law does not make a network accept your sender. A network approval does not make your content lawful. And labelling traffic as transactional does not help if the message body also promotes a product — mixed content is generally judged on what the message actually does, not on the category you filed it under.
A destination matrix you actually maintain
One row per market and use case, kept where the launch team and the routing team can both see it.
| Column | What goes in it |
|---|---|
| Market | Destination country, and networks if requirements differ between them |
| Use case | Authentication, service notification, two-way support or promotional |
| Recipient category | Individual subscriber or corporate subscriber, since treatment can differ |
| Permission and evidence | Basis relied on, how it was captured, where the record is held |
| Sender requirements | Sender type, registration status, template or content approval needed |
| Number or route requirements | Any required number type, registration reference or route restriction |
| Opt-out and suppression | Required wording, how requests are captured, how suppression is enforced |
| Data handling | Controller or processor role, retention rule, any international transfer position |
| Owner, source and review date | Who is accountable, the primary source used, when it was last confirmed |
The last column is the one that keeps the matrix honest. A rule confirmed eighteen months ago and never revisited is a risk carried forward, not a control.
A worked example: the UK
The UK is used here purely as an illustration of how these layers interact, not as a statement of global rules; a cross-border campaign can be affected by the requirements of more than one jurisdiction. Under the Privacy and Electronic Communications Regulations, the electronic mail marketing rules cover text messages as well as email. The ICO's current guidance on complying with those rules, updated on 28 April 2026, explains the consent requirement and two conditional soft opt-ins for unsolicited electronic-mail marketing to individual subscribers: one for an organisation's own similar products and services, and one available only to charities for their charitable purposes. Each has detailed conditions, including how the details were obtained and the opportunities given to opt out; neither is a blanket permission. Confirm all applicable conditions against the current guidance before relying on one.
Business-to-business messaging is treated differently again: the ICO's business-to-business marketing guidance distinguishes corporate subscribers from individual subscribers, including sole traders and some partnerships, and makes clear that UK data protection obligations still apply to the personal data you process either way. "It's B2B" is not, on its own, an answer.
Claims to avoid making internally
- That a single privacy framework such as UK GDPR sets identical messaging rules across markets.
- That encryption is universally mandated for message content, or that encrypting content resolves a consent question.
- That a country's rules are known because a competitor appears to send there.
- That an old successful test proves a sender or template is still acceptable today.
- That buying capacity from any provider transfers your compliance obligations to them.
Country-specific positions need a current primary source — a regulator, a network's published requirements or your own legal advisers — recorded with a date. Second-hand summaries, including this one, age.
Before a launch
Confirm the destination and network requirements, the sender arrangement, the permission position and evidence, the suppression mechanics and the data-handling roles, and confirm route availability and eligibility for the traffic class with your provider. For interconnect and wholesale arrangements that discussion sits with the SMSC gateway for carriers and SMS aggregators service, where route type, sender handling and current availability are checked per destination rather than assumed. Where market rules are the binding constraint, carrier relations can help confirm current network requirements; obtain legal advice where required.
This article is general operational guidance and not legal advice. Before launching into any market, confirm the current destination and network rules with appropriate advisers, and record what you confirmed and when.
Discuss destinations, senders and traffic types
Tell us the markets you want to launch in, the recipient categories and use cases involved, and the sender arrangements you have today. We can then discuss what needs confirming for those destinations before traffic moves.
Sources and further reading
Independent references are general context, not evidence of MessageTrade capabilities, partnerships or performance.
Related guides
- Carrier Relations in A2P Messaging: Beyond the Rate Card
Carrier relations is where commercial agreements, route suitability, compliance intelligence and incident response meet — and where messaging becomes more predictable when conditions change.
- SMS Aggregator Security: Controls, Abuse and Due Diligence
A practical set of controls to design and evidence to request — including the abuse and logging problems that are specific to sending messages.