Quick answer: Under the TCPA, consent follows the subscriber, not the phone number. When a number gets recycled to a new subscriber, prior-express consent for the old owner stops covering that destination — and the recycled number inherits the previous owner's opt-out history and known-litigator exposure along with it. Devotel Orbit's Reassigned Numbers Database (RND) scrub checks each destination against the FCC-mandated reassignment registry before the send goes out, and its verdict trail — not a memo — is what the FCC safe harbor credits. This post covers why recycled numbers poison lists, what the RND actually is, where the check fires in the send-gate chain, why a live check beats trusting a last-scrub date, and how to procure it as a different control than the behavioral litigator scrub. The endpoint contracts live in the RND scrub docs.
1. Why recycled numbers poison lists
Consent under 47 U.S.C. § 227 attaches to the human, not the handset. When a carrier permanently disconnects a number and reassigns it to a new subscriber, the destination re-points — and three bad things travel with it:
- Your consent stops covering the destination. The new owner's
relationship with you never existed, so every send to that number is an unsolicited message to a stranger.
- The previous holder's preferences pollute your records. Opt-outs
the old subscriber filed do not carry over to the new one — but the yes verdict of a registry-style scrub does, meaning a sender that skips subscriber-side screening has no defense when the new owner complains.
- Known-litigator exposure follows. Lists of dialers that land on
TCPA-aware filers and plaintiff-side entities (see the litigator scrub explainer) are built over actual received outbound; a number that is known on those lists but was never checked pre-send is one of the highest-information exposures a sender carries.
Recycled numbers are not rare — the FCC's reporting rules make carriers publish disconnections precisely because churn keeps poisoning audiences at scale. "We scrubbed the list at import" degrades to "we have no idea who is on the other end" within weeks.
2. The Reassigned Numbers Database, in one move and one truth
The FCC required carriers to report permanent disconnects into a centralized registry (47 CFR § 64.1200(m); operated at reassigned.us by the database administrator Somos). The reporting upstream means a caller can answer one concrete question before placing a send:
> Was this number permanently disconnected after the date I obtained > prior-express consent?
When the registry answers no, the FCC's safe harbor shields the caller from reassigned-number liability for that send — a deliberate evaluation, logged, is the credit. When it answers yes, you have the exposure and the check is what bought you the chance to suppress it. The registry is subscriber-side evidence; it is not a do-not-call registry and it is not a read on whether the current owner has opted out. The only claim it underwrites is the reassignment check.
3. How Orbit's RND scrub sits in the send-gate chain
The scrub is an explicit, per-organization opt-in (default off): until enabled, an attempt to check returns a gate error rather than a false "clear" verdict. Once an RND disconnect snapshot is ingested, enabling the flag opens the single-number check at GET /api/v1/compliance/rnd/check, taking phone (E.164) and consent_date (YYYY-MM-DD) — the date on which prior-express consent was most recently verified for the recipient.
The check answers with a verdict that the FCC frame was defined for:
- `yes` — a permanent disconnect occurred after the consent date;
no safe harbor; suppress the destination.
- `no` — no permanent disconnect after the consent date; the safe
harbor applies.
- `no_data` — the synced feed holds no record for the number, or no
feed is loaded. Treated as unknown, never as passed; route it to the same suppressed bucket as yes per your own risk policy.
The verdict it returns carries the fields an audit review needs — safe_harbor, last_disconnect_date, the consent date, and whether an ingested snapshot backed the answer — and every check, allowed or denied, writes an audit entry with the phone truncated. The check composes alongside the DNC scrub, quiet-hours evaluation, and the TCPA litigator scrub as one of the independent pre-send gates your organization's send path consults — see Send Gates for where the RND leg sits in the chain. It is a gate you own, not a platform-side blocker: it filters your audience before the send pipeline launches rather than hard-refusing traffic you never asked it to screen.
4. Why a live check outperforms the list's last-scrub stamp
Carriers feed the registry continuously, so a number that cleared the RND when a list was imported has a verdict with an age. The audiences rest between campaigns, portfolios run parallel sends, and a verdict from audience-build time stops answering the question the safe harbor makes creditable a few days later. The durable pattern the scrub supports:
- **Re-scrub right before the campaign sends, not when it was
assembled.** A in-flight yes from the current snapshot suppresses the destination; a no from a two-week-old snapshot is not the defense you think it is.
- Read `feed_synced` every time. While no snapshot is ingested,
every answer degrades to no_data — and no_data is not a pass. On the Orbit platform the feed is synced centrally; self-hosted operators connect the carrier snapshot their deployment conforms to.
- Batch with the per-check loop. There is no bulk endpoint by
design — a pre-campaign batch is a loop over the single check within the authenticated-read budget, which keeps the audit trail one verdict per recipient.
The loop-plus-single-endpoint shape keeps every refusal auditable: a pre-campaign "cleared" that means "we scrubbed it once at import" is not the same claim as "the gate was consulted at send time and it returned clean."
5. Procurement: RND as location-evidence, litigator lists as behavior-evidence
Procurement frames the two scrubs as answering different risk questions, which is what decides whether they overlap or stack:
- RND (Reassigned Numbers Database) answers a location question:
does the phone number still bind to the subscriber who gave consent? It is a relationship-to-the-number claim.
- RMD / TCPA-known-litigator lists answer a behavior question:
does the destination sit on a register built from who actually received your outbound and then filed? It is a the-number-is-on-a-risk-list claim.
A RND verdict says nothing about observed behavior; a litigator verdict says nothing about reassignment. Both are cheap, both are auditable, and missing either one leaves a category of exposure the other does not see. Evaluate them the way you evaluate two legs of a send gate — in series, each clearing its own dimension — not as substitutes. Cross-reference the behavioral side at TCPA Known Litigators and the reassignment side at RND Scrub.
Frequently asked questions
Is the RND the same as the DNC registry?
No. The DNC registry records whether the person opted out of telemarketing. The RND records whether the carrier permanently disconnected the number. The two answer orthogonal questions and the scrubs stack, not overlap.
Does a no_data verdict count as scrubbed?
No. no_data means nothing was on the synced feed for the number, or no snapshot was loaded. It is a non-answer, and a gate that treats unknown as cleared is a gate that no longer gates. Route it the same as yes unless your risk desk says otherwise.
How often does a list need re-scrubbing?
The registry updates continuously as carriers report disconnection. For audiences held more than a couple of days, re-scrub right before send rather than trusting the stamp from audience-build.
Who decides whether contacting a yes number is actionable?
The scrub is a tenant-owned control; it returns evidence, and your counsel owns the go/no-go decision. Orbit's verdict fields and audit trail are what that evidence is made of. This post, like the docs, is not legal advice.