A do-not-call request is recorded when it is made

The requirementstatement

A do-not-call request must be recorded, with the name and number, at the time the request is made.

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: internal do-not-call write 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

The obligation is about latency rather than storage: a request written up at the end of the week is a week in which the number can still be messaged, and the record then shows a delay nobody can explain. It is also the moment the identifying detail is available — the person is on the phone — and reconstructing a name from a number afterwards is exactly what does not happen.

How to fix itremediation

Make the request recordable during the contact — a field the agent sets before ending the call, not a form filed later — and write the name and number together. Done when the record timestamp matches the contact timestamp.

A compliant exampleexample

Agent sets Do Not Call on the account during the call: name, number, request received 2026-03-04T11:02Z.

Check this yourselfattestation

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

Does the record timestamp on a do-not-call request match the contact timestamp?

1Trace the workflow: is anyone asked to enter these after the fact? Batch entry at the end of a shift is common and it is what creates the latency.
2Make the request recordable during the contact — a field the agent sets before ending the call — and capture the name and number together.

What wrong looks like: A request written up at the end of the week is a week in which the number can still be messaged. The name is available while the person is on the phone and is never reconstructed afterwards.

Notesnotes

A workflow inside the brand. What the user has to check is whether their process asks anybody to do this after the fact; batch entry at the end of a shift is common and it is what creates the latency this rule is about.

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