The honouring clock starts when the revocation arrives

The requirementstatement

The time taken to honour a revocation is measured from receipt of the revocation, not from the confirmation, and must never exceed ten business days.

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 latency, measured from receipt
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

Ten business days is the outer federal limit, and it is not a target — anything a platform can do instantly it must do instantly. The anchor matters because the obvious instrumentation measures from the confirmation being sent, which hides any delay in recognising the revocation at all: a message that sat unread in an inbox for a week shows as zero elapsed time on that clock.

How to fix itremediation

Timestamp the revocation when it arrives, not when it is processed, and report the gap between that and suppression. Done when your own reporting would show a revocation that waited three days in a queue.

A compliant exampleexample

Opt-out record: received_at 2026-03-04T09:12Z, suppressed_at 2026-03-04T09:12Z, channel=SMS.

Check this yourselfattestation

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

Would your own reporting show a revocation that sat unread in a queue for three days?

1Check which timestamp the platform records — many record only the suppression, which makes the obligation unmeasurable in your own data.
2Timestamp the revocation on arrival, and report the gap between that and suppression.
3Ten business days is the outer federal limit, not a target.

What wrong looks like: The instrumentation measures from the confirmation being sent, so a message that waited a week in an inbox shows as zero elapsed time.

Notesnotes

A measurement across two runtime events. What the user has to check is which timestamp their platform records — many record only the suppression, which makes the obligation unmeasurable in their own data. OPS-056 covers the record this depends on.

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-046 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.