# OPS-071 — Group messaging needs a member opt-out and anti-abuse controls

> A group-messaging programme must let any member leave at any time, carry anti-abuse controls proportionate to the distribution size, and prevent recursive group messaging.

- **Rule ID:** OPS-071
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `campaign.message_flow + campaign.description`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the submitted form
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** CTIA
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-071/

## Why this rule exists

In a group thread the sender is not the only person who can reach the recipient, so the ordinary opt-out is not enough — a member who leaves can be added back by anyone else in the group, and a recursive group can amplify one message into thousands. The three controls exist together because each one alone is defeated by the other two failure modes.

## How to fix it

Describe how a member leaves and stays left, what limits the size and rate of a distribution, and what stops a group creating another group. Done when the flow answers all three without the reader inferring any of them.

## Example of a compliant value

```text
Any participant can reply STOP to leave a thread and cannot be re-added without opting in again; threads are capped at 25 participants, and participants cannot create new threads through the service.
```

## Notes

Applies only to group or multi-recipient threading, which the registration has no attribute for. The condition is carried in the criteria — the judge PASSes immediately where the campaign describes ordinary one-to-one messaging — and this note records that the applicability model could not express it.