# OPS-037 — On a shared address, STOP must stop everything

> 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.

- **Rule ID:** OPS-037
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `subscription registry keyed by number and application address`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Falls due after approval, once you are live and sending
- **How it is detected:** Not knowable before submission — reported with its deadline
- **Fix type:** Wait on an external system or a required interval
- **Required by:** CTIA
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-037/

## Why this rule exists

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 it

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.

## Example of a compliant value

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

## Check this yourself

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

1. List the programmes sending from the address.
2. Ask your platform how suppression is scoped. Per programme is the common default and it is the wrong one.
3. Test 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.

## Notes

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.