Regional messaging in the Gulf: why global platforms underperform here

A platform can be excellent everywhere and mediocre here, for reasons that have nothing to do with its engineering.

In Saudi Arabia, A2P traffic goes through licensed aggregators, overseen by the Communications, Space and Technology Commission. Sender IDs must be approved, and restrictions on international alphanumeric senders frequently push a foreign business toward a registered brand or a local number.

A global platform without local licensing reaches this market through a partner. That can work perfectly well — but it means an extra party in the delivery path, in the support path, and in the incident path.

In the UAE, promotional SMS must carry the AD- prefix — mandatory since November 2020 — and promotional traffic is classified by category, with pre-approval by the TDRA. Promotional and transactional streams are registered separately and do not share a sender ID.

A product that models "sender identity" as one account-level setting cannot express this. It has to be per stream, per category, per market.

In much of the Gulf and wider MENA, a small business's entire customer relationship already lives inside a messaging app. Not as a supplement to email and phone — instead of them.

This inverts the usual design assumption. A product that treats messaging as an additional channel bolted onto a CRM is solving a problem this market does not have, while ignoring the one it does: everything is already in the thread, and none of it is structured.

SMS with non-Latin characters uses an encoding with far fewer characters per segment. The same message costs several times more to send in Arabic than in English.

Any pricing model, margin calculation or campaign budget built on English message lengths is materially wrong here. This is not a rounding error and it does not average out.

Interrogate "global coverage". Ask specifically whether the provider is licensed in each market you care about or reaching it through a partner. Both are viable; only one is what most buyers assume.

Budget registration time as procurement time. Sender ID approval and category classification take weeks in some cases, and no amount of commercial urgency compresses a regulator's queue.

Test with real Arabic content, at real lengths. Both for cost and for rendering. A demo in English tells you very little about what you are buying.

The regional advantage is not better software, and it cannot be out-engineered. It is standing with operators and regulators, plus a product designed for how business is actually conducted here rather than translated into Arabic after the fact.

Both halves are required. Local licensing with a translated product loses to a well-localised competitor; a beautifully localised product with no route to the operator does not deliver.

The technical integration is identical everywhere. What differs is the set of permissions you need before the integration is allowed to carry traffic, and those permissions are held by parties a software contract cannot reach.

Look at 10DLC, at India's DLT platform, and at the Gulf's registration regimes together. Different regulators, no coordination, and strikingly similar conclusions: identified senders, declared categories, registered content, evidenced consent.

Build registration as a first-class concept — sender identities, approved categories, per-market status, consent evidence — rather than as a spreadsheet. Every market you add will want the same fields, and the ones that do not exist yet will want them too.

The integration is the easy half. Licensing, sender approval and category classification are serial, slow, and decide your launch date. Ask who holds the licence, budget weeks not days, separate promotional from transactional in the data model, and price Arabic at the correct segment length.