Reassigned Numbers Database: What It Is and When to Check

Consent is tied to a person, not a phone number. When someone gives you permission to call and then gives up that number, the permission doesn't transfer to whoever gets it next — but your dialer has no way of knowing that happened. The FCC's Reassigned Numbers Database exists to close that gap.

Why reassigned numbers are a problem

Phone numbers get recycled constantly. A customer changes carriers, cancels a line, or switches to a new number, and after a waiting period their old number is reassigned to somebody else. If that number is still sitting in your CRM marked "consented," every call you place to it is now going to a stranger who never agreed to anything.

This is one of the more common ways a genuinely well-run calling operation ends up with TCPA exposure. You did collect consent. You have the record. It just stopped being valid at a moment nobody told you about.

What the database actually does

The Reassigned Numbers Database, operated under FCC authority, lets callers check whether a number has been permanently disconnected since a date you specify — normally the date you obtained consent. You submit the number and that date, and you get one of three answers:

• No. The number has not been permanently disconnected since your consent date, so your consent is still attached to the same subscriber.
• Yes. The number was permanently disconnected after that date. Treat the consent as dead.
• No data. The database can't answer for that number and date combination.

The safe harbour, and its limits

The reason callers use the database is the safe harbour attached to it. If you check a number, get a "no" answer, and then call it and reach a new subscriber anyway, the safe harbour is designed to protect you from liability for that call — because you did the check the regulator asked you to do and the database gave you a clean answer.

Two important limits. The protection depends on the database actually returning "no" — a "no data" response is not the same thing and doesn't carry the same protection. And it only covers the reassignment problem. It says nothing about whether the number is on the DNC registry, whether the person is a serial litigator, or whether you had valid consent in the first place.

Where this sits alongside scrubbing

It's worth being clear that these are different checks answering different questions:

• DNC scrubbing asks: has this person opted out of telemarketing calls?
• The Reassigned Numbers Database asks: is this still the same person who gave me consent?
• Litigator and honeypot checks ask: is calling this number unusually likely to end badly?

A number can pass one and fail another. Clean on the DNC registry tells you nothing about whether it was reassigned last month, and a reassignment check tells you nothing about whether the new subscriber has their number on the registry.

When it matters most

The older your consent, the more this matters. Calling a list where consent was collected last week carries very little reassignment risk. Calling a list where consent was collected two years ago carries quite a lot, because two years is plenty of time for a meaningful share of those numbers to have changed hands. If you're reactivating an old database, this is the check that's easy to forget and expensive to skip.

Building it into the workflow

Reassignment checks work best as a step in the same pass as everything else — you already have the list open, you're already cleaning it, and the numbers you drop for one reason don't need checking for the others. We wrote about sequencing all of this in building a compliant calling workflow.

Carrier Fence handles the DNC, litigator and honeypot side of that pass — upload a file, get every number checked, and get a report you can hand to compliance. Start with 500 free coins and see what your current list looks like.

This article is general information about how the rules work, not legal advice. Check your specific obligations with counsel who knows your business.