A referral opt-out covers everything sent through the application

The requirementstatement

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

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: suppression scope across a viral application
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

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 itremediation

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 yourselfattestation

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

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

1Check whether suppression is scoped to the sender or to the application. Per-sender is the natural build and it does not satisfy this.
2Test 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.

Notesnotes

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.

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-037On a shared address, STOP must stop everythingBlockingBLOCKING

All operational rules

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