Cross-channel revocation and the 2027 rule

A revocation is one fact about a person, not a per-channel preference. Somebody who says stop calling me has not asked to keep hearing from you somewhere else, and a system that stores that fact once per channel has already decided otherwise on their behalf.

The rule, stated exactly

47 C.F.R. § 64.1200(a)(10) requires a revocation received through any medium to be honored across every channel the caller uses. The cross-channel portion of that requirement becomes mandatory on 2027-01-31, after two delays.

Read it once and the design consequence is hard to miss: the regulation does not care which door the request arrived through, so a stack that answers per door is going to be wrong at one of them.

Two numbers, and they are not the same number

This is where writing on the rule most often goes wrong, and the error is expensive because it travels from a blog post into a contract.

The rule allows up to ten business days to honor a revocation once it is received. That is a statutory bar: a ceiling on lateness, measured against a record after the fact.

Vocapable’s suppression lands in the same transaction that records the revocation. That is a property of a write path, and it is not a restatement of the rule.

Those are two different numbers about two different things. Merged one way, a ceiling on lateness reads as a demand for immediacy the regulation never makes. Merged the other way, a property of our write path gets restated in the statute’s units, which understates the software and gives it room to drift toward a deadline it has no need of.

Your Telecom Compliance Addendum §4.1 covers the revocations that reach you off the platform: the person who tells your rep to stop, in an email, on a form we never see. Everything that arrives through the platform lands in the write described below, which is the half of the problem you no longer have to staff.

Why a channel column is where this breaks

The common shape is a preferences table with a row per person per channel, written by whichever subsystem happened to take the request. Two failure modes follow from that shape, and both are ordinary engineering rather than negligence.

The write that lands in one subsystem does not reach the other, because nothing in the schema says it has to. And the read that decides whether to dial asks a different question from the read that decides anything else, so the two can disagree for as long as it takes somebody to notice.

Neither is visible until a person who revoked gets contacted again — which is precisely the moment it stops being an internal defect and becomes a record somebody else gets to read.

One write path, and no channel column

Vocapable holds one suppression row and it carries no channel column. There is nothing to propagate between, because there is no second place for the fact to live, and both readers ask the one row the same question.

Every entry point converges on the same transaction: a mid-call opt-out, a keypress, an inbound stop request, and your own API call. One write, whose statement order carries the guarantee. The internal do-not-call entry, the event, the withdrawal of the consent standing behind that number, and the dial-time fast path land together, or none of them land.

A revocation whose covered set cannot be resolved covers everything. It over-suppresses rather than under-suppresses, which is the only direction it is allowed to err in.

And it cannot be given an expiry. The endpoint refuses one rather than honoring it, because two of those writes are irreversible — the consent ledger is append-only and the dial-time flag is never re-derived — so a time-limited revocation would destroy the consent evidence permanently and then hand the number back as dialable.

Why we ship it before the date

The cross-channel requirement is mandatory on 2027-01-31. We propagate today.

That is not eagerness. Gating the behavior on a date would mean shipping the non-propagating version first and then trusting somebody to remember. The date is recorded as evidence and is deliberately not branched on: there is no code path that behaves one way before it and another way after.

What lands in the record

A revocation is not only a state change; it is an entry in the evidence file for every attempt that follows it. The next dial for that number carries the internal-suppression result read live at dial time rather than from cache, and where the dial is refused, the reason on the attempt names it.

The per-call anatomy is walked in full on the evidence file, and the engine that writes it is described on the compliance page. The duty split is in your Telecom Compliance Addendum, published on this site.

What to ask, of us or of anyone

• Where does a revocation get written, and how many places store it? Any answer above one is the answer.
• Is there a channel column on that row? If there is, ask what keeps the copies in agreement, and how anyone would find out that they stopped being.
• Can a revocation be given an expiry? If it can, ask what happens to the consent record it withdrew.
• What does the system do when it cannot resolve which channels a revocation covers? Over-suppressing is the only safe direction, and it should be the documented one.
• Which of the vendor’s stated timings is the statute and which is the software? A vendor who quotes one number has merged two facts, and you cannot tell from the outside which way.

What this does is make what your system did with a person’s request reconstructible by somebody who was not there, which is the part that is still true on the day you are asked to prove it.