A2P compliance basics by region: opt-in, sender IDs, and registration

Compliance is the only part of the messaging business that is invisible until it is the only thing that matters. Traffic flows for months, nobody asks a question, and then one of three things happens: a carrier filters your route without notice, a regulator writes a letter, or a client’s competitor files a complaint and the paperwork lands on your desk instead of theirs. This guide is the map most operators build the hard way. It covers the rules that are true everywhere, the regional regimes that actually catch people out, and the unglamorous platform features that turn a policy into something you can prove. It is information rather than legal advice, and the rules move: confirm the specifics for every country you send into, with your upstream provider and, where the money is serious, a local lawyer.

The three rules that travel everywhere

Strip out the acronyms and the regional filings and almost every A2P regime in the world is enforcing the same three ideas. Learn these and the paperwork becomes detail rather than doctrine.

Consent. The recipient agreed to hear from this sender, about this kind of thing. The bar rises with the content: a transactional message (an OTP, a delivery notice, a balance alert) is generally treated as implied by the transaction itself, while marketing usually needs an explicit, separate, affirmative act. The failure mode is almost never “we had no consent at all”, it is “we had consent for something else”. A customer who ticked a box to receive delivery updates did not consent to a Black Friday blast, and in the markets that care, that distinction is the whole case.

Identification. The recipient can tell who is messaging them, from the message itself, without detective work. That is what a sender ID is for, and it is why unbranded, rotating, or borrowed sender IDs are the fastest way to get filtered. In some markets identification is a formal registration; in others it is simply a rule that the brand name appears in the body. Either way, an anonymous A2P message is a suspicious A2P message.

Opt-out. Stopping is easy, obvious, free, and immediate. STOP is the near-universal keyword, with local equivalents in most markets, and “immediate” means the platform stops sending, not that a support ticket gets raised. This is also the rule most often broken by accident, because opt-out gets implemented in a marketing tool rather than at the gateway, and the next campaign, loaded from a stale CSV, sends to the person who left.

Everything below this line is regional. Nothing below this line rescues you if one of these three is missing.

Sender IDs, and why registration exists at all

A sender ID is what shows up in the “from” line: an alphanumeric string (a brand name, up to 11 characters on standard SMS), a long number, or a short code. It looks trivial. It is the single most contested object in the industry, because it is both the identification mechanism and the thing fraudsters most want to forge.

The reason registration regimes exist is spoofing. Alphanumeric sender IDs are, at the protocol level, a field you fill in. Nothing in SMS itself stops a bad actor from putting a bank’s name in it and sending a phishing message that lands in the same thread as the real bank’s OTPs. Regulators responded the only way they could: make the sender ID a registered, owned, checkable object, and refuse to deliver traffic that uses an unregistered one.

That gives you three practical consequences to design around. Registration takes time, from days to weeks depending on the market, so it belongs in your client onboarding schedule, not in the launch-day checklist. Sender IDs belong to the brand, not to you, which means they are registered per client, with the client’s documentation, and a shared or recycled sender ID across tenants is both a compliance problem and a support nightmare. Capabilities differ by ID type: in most markets an alphanumeric sender ID cannot receive replies, which quietly breaks any two-way flow, including the STOP handling you are relying on for rule three. If you need inbound, you need a number, and that changes the registration path.

Region by region: the highlights that catch people out

There is no world regime, only a patchwork, and the patchwork is the job. These are the four shapes you will meet most often.

India: DLT, the strictest regime in the world. Distributed Ledger Technology registration is a genuinely different model. Before a single message sends, the entity registers, the header (the sender ID) is registered and approved, and every content template is registered as a pattern with variable fields. At send time the operator scrubs the message against the registry: wrong template, unregistered header, or content that does not match the approved pattern, and the message is rejected rather than delivered. Consent itself is registered too. Operators new to India routinely underestimate the template step, because it forces a discipline most platforms are not built for: your message content is a pre-approved shape with holes in it, not free text. If you serve Indian traffic, template management is a product feature, not an admin task.

United States: 10DLC, and the expensive part is not the fee. Sending A2P traffic from a standard local number requires registering a brand and then registering the campaigns (use cases) that run under it. The direct costs are small: one-time brand registration in the region of 4 USD, campaign vetting around 15 USD, and recurring per-campaign carrier fees typically in the 2 to 10 USD per month range, all of which drift, so treat those as an order of magnitude rather than a quote. The expensive part is what happens without it: unregistered traffic gets throttled to a trickle or filtered outright, and the throughput you are actually granted depends on your trust score. Layered on top sits the TCPA, which is not a carrier policy but a statute with private right of action and statutory damages commonly cited at 500 to 1,500 USD per message. Per message. That is the number that turns a sloppy list into an existential number, and it is why the US market rewards paranoid consent records more than any other.

European Union and UK: nothing to register, everything to prove. There is generally no central sender ID or template registry. Instead, consent is governed by GDPR and the ePrivacy rules, and marketing typically requires opt-in that is freely given, specific, informed and unambiguous, with a narrow soft opt-in for existing customers regarding similar products. Two consequences follow. First, the burden of proof is on you: if you cannot produce the record, you did not have consent, and “the client said they had it” is not a defence. Second, the data itself is regulated, not just the sending, which is why data residency, retention, and sub-processor questions arrive during procurement rather than after. Enforcement is percentage-of-turnover shaped, so the ceiling scales with the business rather than the offence. This is the market where a self-hosted platform on your own servers answers half the questionnaire before you fill it in.

GCC and MENA: operator approval, per market, per sender. Across much of the Gulf the pattern is sender ID approval granted by each operator or the national regulator, usually with commercial registration documents, sometimes with a local entity requirement, and frequently with an approval that is per operator rather than national. Content restrictions are stricter and more culturally specific than most Western operators expect, and promotional traffic often faces time-of-day windows. The practical advice is to budget onboarding time in weeks, and to lean on an aggregator who already holds the relationships.

Everywhere else: ask, per country, before you quote. The mistake is treating “Africa” or “Latin America” or “Southeast Asia” as a policy. They are not. Registration exists in some markets and not others, sender ID rules vary by operator inside a single country, and the only reliable source is the aggregator terminating your traffic. Build the question into your route onboarding, alongside the price and the quality test in the reselling playbook.

WhatsApp and RCS: when the platform is the regulator

Channels outside SMS do not escape compliance, they add a second regulator on top of the first, and this one enforces automatically.

On WhatsApp, opt-in is a policy requirement before any business-initiated message, template messages are submitted and approved before use, and quality is scored continuously. Get it wrong and the consequences are mechanical rather than legal: your template is rejected, your quality rating drops, your messaging limit tier falls, and eventually the number is restricted. There is no letter, no negotiation, and the appeal path is a form. The upside is that the rules are legible and the same everywhere, which is genuinely easier than the SMS patchwork. The WhatsApp without a SaaS middleman guide covers how that ownership works in practice.

RCS carries the same shape: verified senders, brand verification, and carrier-side controls. The pattern to internalise is that on these channels compliance is enforced by code at the platform, and code does not accept “we are working on it”. Whatever your process is for consent and opt-out, it has to be the same process across every channel you run, because your recipients do not think in channels and neither will the complaint.

What compliance looks like as a platform feature

Policy that lives in a PDF is not compliance, it is intent. What survives an audit is a system where the compliant path is the default one. These are the features that do the work, and they are worth checking for by name in any platform you buy or build.

A consent record with a shape. Not a boolean flag on a contact. Who consented, which number, the exact wording shown, the source (web form, POS, import, API), the timestamp, and the IP or reference where it exists. Store the wording, not a pointer to a page that changes next quarter. This is the single highest-value field in your database on the day it matters, and the cheapest one to add before it does.

Opt-out at the gateway, not in the campaign tool. The suppression list is enforced at send time, per tenant, across every channel, and it wins over any list a user uploads. STOP handling is inbound-wired and instant. If a user can defeat the opt-out list by importing a CSV, you do not have an opt-out list, you have a suggestion.

Sender ID and template management per tenant. Sender IDs registered to and owned by each client, templates stored as approved patterns with variables where the market demands it, and a hard rejection at send time when the content does not match. This is what makes India survivable and what keeps a multi-tenant estate from cross-contaminating.

An audit trail per message. Every message, in a system of record, with the sender ID used, the tenant, the route, the template reference, the timestamp and the delivery receipt, retained and queryable. When the complaint arrives about one message six months ago, this is the difference between an afternoon and a crisis. It is the same ledger discipline that makes billing defensible, which is not a coincidence: both are answering the question “prove what happened”.

Spam and content flagging that flags rather than blocks. An automatic classifier on the hot path catches the obvious problems before your carrier does. It should mark and surface, not silently drop, because a false positive that kills a bank’s OTP traffic is a far more expensive mistake than a flagged message a human glances at.

Tenant isolation and a suspension switch. Per-client rates, per-client sender IDs, per-client traffic, and the ability to stop one tenant instantly without touching the others. Your acceptable use policy is only as real as the button that enforces it.

Note what all of this is: record keeping, defaults, and a switch. None of it is exotic. It is just work that is easy to defer and painful to retrofit, which is why platforms that ship it as standard are worth more than they look. Owning the server the records sit on, as a one-time licence rather than a tenancy, is the last piece: the audit trail is only useful if you can actually produce it, and that is a different conversation when the database is yours.

The operating rhythm: staying compliant after launch

Compliance is not a project with an end date, it is a maintenance schedule, and the failures are almost always drift rather than ignorance.

Registrations expire, and they expire quietly. Sender ID approvals lapse, 10DLC campaigns need to stay current, DLT templates need updating whenever marketing changes a word, and the notification, if there is one, goes to an inbox nobody reads. Put every registration in a calendar with an owner and a renewal date, per client, and review it monthly. Watch your complaint and opt-out rates per client as an early-warning system: a sudden spike is a list problem, and it will reach your carrier before it reaches you. Re-verify consent on imported lists, because a list bought, scraped, or inherited from a client’s old provider is the single most common source of a suspended route. And when a client asks you to send something you are not comfortable with, the cheap answer now is a conversation; the expensive answer later is your route.

The uncomfortable truth for resellers is the one in the FAQ above: your carrier sees your traffic, not your clients’. Compliance is not something you can fully delegate downstream, because the consequences do not flow downstream. They land on you. Which means the sane strategy is to make the compliant path the easy path inside your own platform, so that your clients comply by default rather than by diligence, and so that when the letter arrives you can answer it in an afternoon with a query instead of an apology.