The Reassigned Numbers Database (RND) is the FCC's safe-harbor tool for one specific, expensive problem: you got consent to call a number, the consumer switched carriers or dropped the line, that number got reassigned to someone new, and your dialer keeps calling it as if nothing changed. That single scenario now accounts for a meaningful share of TCPA class action filings, and most outbound operations still handle it as an afterthought bolted onto list hygiene rather than a core part of the dialer stack.

This isn't a "what is TCPA" primer — if you need that grounding, our outbound calling compliance guide covers the broader regulatory picture. This post is about the RND specifically: what it does, what it doesn't do, how to wire it into a VICIdial or Asterisk-based dialer, and where it intersects with AMD accuracy in ways most compliance teams never think about.

What the RND Actually Checks

The Reassigned Numbers Database went live for production queries in November 2021, built by Neustar under FCC contract. It answers exactly one question: has this number been permanently disconnected and reassigned to a new subscriber since a date you specify?

You submit a phone number plus a "date of consent" — the date you got permission to call that number. The database returns one of three answers:

  • No — the number has not been reassigned since your consent date. You have a defensible safe-harbor position if you rely on this in good faith.
  • Yes — the number was disconnected and reassigned after your consent date. Calling it now means calling someone who never consented.
  • No data — the carrier hasn't reported reassignment status for that number, or it falls outside the database's coverage window.

That last category matters more than most compliance teams realize. RND coverage isn't universal — it depends on carrier reporting, and smaller carriers and MVNOs have historically had gaps. A "no data" response is not the same as a "no" response, and treating it as clearance is exactly the kind of good-faith argument that falls apart in front of a judge.

Why This Keeps Showing Up in Litigation

Reassignment isn't rare. Industry estimates put annual U.S. number reassignments in the tens of millions — people switch carriers, cancel service, port to a new provider, or simply stop paying a bill and the number gets recycled after a dormancy period (typically 45–90 days depending on carrier). Every one of those numbers might still be sitting in your dialer's lead list under the original consenting party's name.

The exposure compounds with list age. A number obtained through consent 18 months ago has had far more opportunity to churn than one obtained last week. If your dialer doesn't distinguish list freshness or re-verify aging numbers, you're accumulating silent risk with every list that sits untouched in a campaign queue.

TCPA class action filings have climbed sharply — plaintiffs' firms specifically target high-volume outbound operations because reassignment claims are easy to prove (phone records plus a declaration that the defendant never consented) and statutory damages of $500–$1,500 per call add up fast across a multi-thousand-number list.

Where RND Checks Belong in Your Dialer Workflow

The operational challenge isn't understanding the RND — it's integrating per-query checks into a live dialing pipeline without destroying pacing or adding cost that outweighs the risk you're mitigating. Three integration patterns, in order of maturity:

1. Pre-campaign batch scrubbing. Before a list goes live, bulk-query every number against the RND and drop or flag "yes" responses. This is the minimum viable approach — cheap, simple, works with any dialer including stock VICIdial. The gap: it only protects you at the moment of the scrub. A list dialed over three weeks has numbers that could reassign mid-campaign.

2. Rolling re-verification on list age. Re-query numbers on a schedule tied to how long they've sat in a campaign — for example, any number not dialed in 30+ days gets re-checked before the next attempt. This catches mid-campaign reassignment without querying every number on every call, which keeps query costs manageable.

3. Real-time query at dial time. The most defensible but most expensive pattern — query the RND (or a cached/pooled version of recent results) immediately before the dialer places the call. This requires custom middleware between your dialer's outbound agent script and the RND API or a third-party reseller, since neither stock VICIdial nor base Asterisk has native RND query support.

Most mid-size operations land on a hybrid: batch scrub at list load, rolling re-verification for anything older than 30 days, with real-time checks reserved for their highest-penalty campaign types (debt collection, healthcare outreach) where per-call exposure is highest.

The AMD Connection Nobody Talks About

Here's the part that gets missed even by compliance-focused teams: a bad AMD engine actively increases your reassignment exposure, independent of whatever RND process you have in place.

When AMD misclassifies a live answer as a machine — a false positive — standard practice on most dialers is to either drop the call silently or route it to a prerecorded voicemail drop. If that number was reassigned and the new subscriber picks up, a silent hangup or an unsolicited prerecorded message to a non-consenting party is precisely the fact pattern TCPA plaintiffs' attorneys look for. You've now stacked a reassignment violation on top of an AMD false positive, and the voicemail drop itself becomes evidence of a prerecorded-message violation.

Conversely, when AMD misses a real answering machine and treats it as a live answer, an agent might leave a manual voicemail on what could be a wrong number's machine — again, without ever confirming who's on the other end. Every AMD misfire is a moment where your dialer takes action on a call whose actual owner you haven't verified, and reassignment is one of the reasons the number you think you're calling isn't the number you're actually reaching.

Asterisk's stock AMD algorithm, running at a 15–25% false positive rate, doesn't just cost you agent time and answer-rate metrics — it multiplies the number of calls where an automated action (drop, voicemail drop, or misrouted agent greeting) happens without human confirmation of who actually answered. Tightening AMD accuracy doesn't replace RND compliance, but it shrinks the number of automated touchpoints where a reassignment error turns into a documented violation. We cover how to actually measure that false-positive rate in our AMD accuracy audit framework, and the cost math in our AMD false positive ROI framework.

A Practical Checklist

Before your next campaign launch:

  • Confirm your RND query provider (Neustar direct, or a reseller like Numeracle, TrueCNAM, or your carrier's bundled service) and know your per-query cost
  • Establish a documented "date of consent" field per lead — not per list, per lead — since consent dates drive the RND query
  • Set a re-verification threshold (commonly 30 days) for numbers that sit in a campaign without being dialed
  • Log every RND response with timestamp — "no data" responses need the same retention as "no" responses for your safe-harbor defense
  • Audit what your dialer does automatically on AMD-detected machines (voicemail drop vs. silent drop) and whether that action is appropriate for a number you haven't reassignment-checked recently
  • Route high-penalty campaign types (debt collection, healthcare, insurance) through your tightest RND and AMD accuracy combination first

Where This Fits in the Bigger Compliance Picture

The RND solves reassignment risk specifically — it doesn't touch consent scope, Do Not Call registry status, time-of-day restrictions, or state-level calling laws, all of which need their own controls. Treat it as one layer in a stack, not a silver bullet.

But it's a layer worth getting right, because it's one of the few compliance controls that's entirely within your technical control — unlike consent language disputes or state law interpretation, RND compliance is a data pipeline problem. Query the number, respect the answer, log the result.

Pairing clean RND practice with accurate AMD is what actually closes the loop: you're not just avoiding reassigned numbers on paper, you're making sure the automated actions your dialer takes — drops, voicemail messages, agent routing — are happening based on who's actually on the line rather than a stale guess. amdify.io's AI-powered AMD engine cuts false positive rates from Asterisk's default 15–25% down to 1–3%, which means fewer automated actions firing on calls where the answer was wrong in the first place. If you're auditing your compliance stack this quarter, it's worth checking both boxes at once — see how amdify.io improves AMD accuracy.