# OPS-054 — Revoking against an exempt message stops everything else too

> Where a consumer revokes in direct response to an exempted informational message, all further non-emergency robocalls and robotexts must stop.

- **Rule ID:** OPS-054
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `suppression scope after a revocation`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **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:** FCC
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-054/

## Why this rule exists

Some informational messages need no prior consent, and operators reason from that to "there is no consent here to revoke". The FCC settled it the other way: replying stop to an exempt message is a revocation of everything non-emergency. The practical failure is a delivery-notification programme that keeps notifying after a stop, on the grounds that notifications were never opt-in.

## How to fix it

Treat a revocation as brand-wide and category-blind unless the consumer narrowed it themselves. Done when a stop sent to a shipping notification also stops the marketing programme on the same number.

## Check this yourself

**Do your transactional and exempt flows — shipping notices, alerts, system messages — consult the suppression list before sending?**

1. Trace one exempt flow end to end and find the suppression check. Many are built as system notifications that bypass it entirely.
2. Test it: reply stop to a shipping notification and confirm the marketing programme on that number also stops.

*What wrong looks like:* Operators reason that informational messages needed no consent, so there is none to revoke. The FCC settled it the other way, and a delivery-notification programme that keeps notifying after a stop is the practical failure.

## Notes

Depends on which message a revocation answered, which only exists in the traffic. What the user has to check is whether their exempt or transactional flows consult the suppression list at all — many are built as system notifications that bypass it.