# OPS-070 — A referral opt-out covers everything sent through the application

> In a viral or referral programme, an opt-out must be honoured across every message sent through that application, programme or software.

- **Rule ID:** OPS-070
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `suppression scope across a viral application`
- **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-070/

## Why this rule exists

In a referral programme the messages a consumer receives are triggered by other consumers, so per-sender suppression leaves them able to be re-invited indefinitely by anyone who has their number. From the recipient's side it is the same application messaging them again after they said stop, and no amount of "a different friend sent that one" survives a complaint.

## How to fix it

Hold suppression at the application level and check it before any referral send, whoever triggered it. Done when a number that opted out cannot be re-invited by a different referrer.

## Check this yourself

**Can a number that opted out be re-invited by a different referrer?**

1. Check whether suppression is scoped to the sender or to the application. Per-sender is the natural build and it does not satisfy this.
2. Test it: opt a number out, then have a second referrer invite the same number.

*What wrong looks like:* From the recipient's side it is the same application messaging them again after they said stop, and "a different friend sent that one" does not survive a complaint.

## Notes

Applies only to referral or viral messaging, which the registration does not record. What the user has to check is whether their suppression is scoped to the sender or to the application — per-sender is the natural build and it does not satisfy this. OPS-385 covers the registration-side prohibition on paying for forwards.