On a shared address, STOP must stop everything

The requirementstatement

Where several programmes share one application address, STOP must terminate every one of the consumer's active programmes on it, and any keyword menu must offer a STOP ALL option.

Severityseverity: BlockingBLOCKINGBreaking this rule gets the submission rejected. There is no partial credit.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: subscription registry keyed by number and application address
Where it liveslayer: OperationalOPERATIONAL
How Ekas settles itdetectability: Post-submissionUNDETECTABLE_PRE_SUBMISSION; The subject does not exist yet at submission time: a reply window, an expiring PIN, a queue position. Reported with its deadline.
What the fix involvesfailureClass: Wait on someone elseTERMINAL_EXTERNAL; Needs an external system or a waiting period, such as IRS propagation, a vetting result, or a carrier queue.
Who requires itauthorities: CTIA
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

From the consumer's side there is one number sending them things, and stopping it means stopping it. A registry keyed per programme instead honours the opt-out for whichever one they last received and leaves the others running, so the messages keep coming from the same number they just unsubscribed from — which reads as deliberate evasion even when it is a data model.

How to fix itremediation

Key suppression on the pair of consumer number and application address, not on the programme, so one STOP clears every subscription on that address. Where a menu offers per-programme choices, put STOP ALL in it. Done when a subscriber to two programmes on one short code receives nothing after a single STOP.

A compliant exampleexample

Keyword menu: "Reply 1 to stop offers, 2 to stop order updates, or STOP ALL to stop everything."

Check this yourselfattestation

No tool can settle this one for you. Here is the check, and what wrong looks like.

Does this application address carry more than one programme — and if so, does one STOP clear all of them?

1List the programmes sending from the address.
2Ask your platform how suppression is scoped. Per programme is the common default and it is the wrong one.
3Test it: subscribe to two programmes on the address, send one STOP, and confirm neither sends again.

What wrong looks like: The messages keep coming from the same number the consumer just unsubscribed from. It reads as deliberate evasion even when it is only a data model.

Notesnotes

Applies to shared short codes and multi-programme addresses, which no registration field identifies. What the user has to establish is whether their address carries more than one programme, and if so, how their platform scopes suppression — per programme is the common default and it is the wrong one.

Rules you will hit next

Other operational rules at the same severity. A registration is judged as a whole, not rule by rule.

OPS-026The universal opt-out keyword set must be declaredBlockingBLOCKING OPS-027Opt-out keyword handling must be declared, not assumedBlockingBLOCKING OPS-029A revocation must survive punctuation, case and surrounding wordsBlockingBLOCKING OPS-031A plainly-worded opt-out counts even with no keyword in itBlockingBLOCKING OPS-033STOP must never come back as an errorBlockingBLOCKING OPS-038Opt-out must not be reduced to one prescribed methodBlockingBLOCKING

All operational rules

OPS-037 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.