The opt-out confirmation is worth sending inside five minutes

The requirementstatement

The single permitted opt-out confirmation should reach the consumer within five minutes of the revocation.

Severityseverity: MediumMEDIUMUsually survives review, but lowers your trust score or invites a manual look you would rather avoid.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: opt-out confirmation latency
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: FCC
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

A prompt confirmation is what buys the presumption that the revocation was honoured, and it is also the only signal the consumer gets that anything happened. Sent late it does the opposite work: a confirmation arriving the next day reads as another unwanted message from a programme they already left, and it is a common trigger for the complaint the confirmation was meant to prevent.

How to fix itremediation

Send the confirmation from the same handler that performs the suppression, synchronously, rather than from a batch job. Done when the confirmation arrives while the consumer still has the conversation open.

A compliant exampleexample

STOP received 09:12:03 → suppressed 09:12:03 → confirmation delivered 09:12:05.

Check this yourselfattestation

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

Does the opt-out confirmation arrive while the consumer still has the conversation open?

1Send STOP to your own programme and time the confirmation.
2Check it is sent synchronously by the same handler that performs the suppression, not by a batch job sharing a queue with marketing.

What wrong looks like: A confirmation arriving the next day reads as another unwanted message from a programme they already left — and triggers the complaint it was meant to prevent.

Notesnotes

A latency only measurable against real receipts. What the user has to confirm is that the confirmation is not queued behind an unrelated batch — the common cause of a slow one is that it shares a sending queue with marketing.

Rules you will hit next

Other operational rules at the same severity. A registration is judged as a whole, not rule by rule.

OPS-032A help request containing a stop-word is not an opt-outMediumMEDIUM OPS-042Somebody has to own revocations that arrive in conversationMediumMEDIUM OPS-051Only ask which messages to stop when there is more than one kindMediumMEDIUM OPS-057Log the sends you did not makeMediumMEDIUM OPS-062An opted-out consumer must be able to come backMediumMEDIUM OPS-063Opt-out records must not be shared onwardMediumMEDIUM

All operational rules

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