The Reassigned Numbers Database: why it matters for compliance

Here is a problem that trips up even careful outreach teams: you have valid consent from a customer, you text the number they gave you, but months later that number was disconnected and reassigned to a stranger. Your consent does not transfer to the new person — so a message they never agreed to can become a violation. The Reassigned Numbers Database (RND) exists to help you catch this. This guide explains it at a framework level. It is general information, not legal advice; confirm how it fits your program with your compliance team.

Why reassigned numbers are a compliance risk

Consent under the TCPA attaches to the person, not the phone number. When a number is given up and reassigned, the new subscriber has given you nothing. If you keep contacting that number based on the old consent, you may be calling or texting someone who:

• Never consented to hear from you, and
• Can potentially bring a TCPA claim, with the same per-message statutory damages that apply elsewhere.

Numbers churn constantly — people change carriers, close accounts, and let numbers lapse — so any list that ages will accumulate reassigned numbers over time. The larger and older your list, the bigger the exposure.

What the Reassigned Numbers Database is

The RND is an official database, created to address exactly this problem, that lets callers check whether a phone number has been permanently disconnected on or after a specific date. The logic works like this:

• You know the date you obtained consent (or last confirmed the number belonged to your contact).
• You query the RND for that number and that date.
• The database tells you whether the number was permanently disconnected since then — which signals it may have been reassigned to someone new.

If the number shows a disconnection after your consent date, that is a red flag that the person you have consent from may no longer hold the number, and you should stop contacting it until you re-verify.

The safe harbor concept

A key reason the RND matters is that using it properly can support a safe harbor against liability for certain calls to reassigned numbers. The general idea is that if you check the database correctly and it returns a "no" (no disconnection found) — but the number had in fact been reassigned in a way the database did not reflect — you may be protected from liability for that specific mistake. The protection depends on actually performing the check as intended. Because the exact conditions and limits of any safe harbor are legal specifics, confirm the current requirements with counsel rather than assuming coverage.

How to build reassigned-number checks into your workflow

• Track consent dates. You cannot query the RND meaningfully without knowing when you obtained consent for each number. Store that date.
• Check older numbers before contacting them. Newly captured numbers are low risk; numbers that have sat on your list for months are where reassignment accumulates.
• Suppress flagged numbers. If a number shows a post-consent disconnection, stop contacting it and route it for re-verification rather than sending anyway.
• Keep records of your checks. Documenting that you queried the database — and what it returned — is part of what makes any safe-harbor protection meaningful.
• Combine with DNC and internal suppression. RND checking is one layer; it works alongside registry scrubbing and your internal do-not-call list, not instead of them.

How Fivra fits

Fivra's compliance layer is built around screening contacts before they are messaged and keeping an exportable audit trail of that screening. Maintaining accurate consent dates, deciding your re-verification policy for aged numbers, and performing reassigned-number checks in the manner required to rely on any safe harbor are part of how you operate a compliant program. Fivra provides the screening-and-logging plumbing; the legal judgments remain yours, and this is not legal advice.

FAQ

What is the Reassigned Numbers Database?

It is an official database that lets callers check whether a phone number has been permanently disconnected on or after a specific date, which signals the number may have been reassigned to a new subscriber since then.

Why do reassigned numbers create TCPA risk?

Consent attaches to the person, not the number. If a number is reassigned, the new subscriber never consented, so continuing to contact it based on old consent can result in messages to someone who can potentially bring a claim.

How does the RND work?

You query the database with a phone number and the date you obtained consent. It tells you whether the number was permanently disconnected since that date, flagging numbers that may have changed hands.

Is there a safe harbor for using the database?

Using the database correctly can support a safe harbor against liability for certain calls to reassigned numbers where the database did not reflect the reassignment. The exact conditions and limits are legal specifics, so confirm current requirements with counsel.

When should I check numbers against the RND?

Focus on older numbers that have been on your list for a while, since that is where reassignment accumulates. Track each number's consent date so you can query the database meaningfully, and re-verify flagged numbers before contacting them.

How does Fivra help with reassigned numbers?

Fivra screens contacts before messaging and keeps an exportable audit trail of screening activity. Maintaining consent dates, setting your re-verification policy, and performing checks in the manner required to rely on a safe harbor are your responsibility. This is general information, not legal advice.