Do Not Call (DNC) scrubbing for AI voice outbound

Call signals passing through a deterministic pre-dial suppression gate
Call signals passing through a deterministic pre-dial suppression gate

Do Not Call (DNC) scrubbing determines whether an outbound call should be blocked before a dialer or AI voice agent receives it. The engineering challenge is keeping registry data, company opt-outs, exception evidence, queued calls, and audit records consistent at the moment of dial. Here is a production design for that control layer.

DNC scrubbing in one minute

DNC scrubbing compares a phone number and its campaign context with the suppression sources that apply to the call. The result should be a deterministic decision such as ALLOW, BLOCK, or REVIEW, plus evidence explaining why.

A clean National Do Not Call Registry result does not prove that a call is lawful. A production decision may also depend on:

  • applicable state lists and state-specific rules;
  • the seller's company-specific do-not-call records;
  • the call purpose and recipient jurisdiction;
  • valid consent or exception evidence;
  • the freshness and availability of every required data source; and
  • separate rules for calling time, caller identity, recording, and use of an artificial or prerecorded voice.

Treat DNC status as one mandatory input to call eligibility, not as a compliance certificate. This is operational education, not legal advice. Counsel should map the rules, definitions, exemptions, and evidence requirements to the actual campaign and jurisdictions before engineering turns them into policy.

Model suppression as three layers

"The DNC list" is not one complete source. A useful model starts with three layers and keeps their meanings separate.

1. National Registry data

For calls within the Telemarketing Sales Rule (TSR), the federal safe-harbor process uses a National Registry version obtained no more than 31 days before the call. The safe-harbor rule also depends on written procedures, training, company-specific DNC records, monitoring, enforcement, and the prohibited call being an error. A scrub within 31 days is one condition. It is not a guarantee of compliance.

Store the registry version or retrieval identifier used for a decision. A Boolean national_dnc_match without source provenance cannot show which data supported a call.

2. State requirements

Resolve the recipient's likely jurisdiction before selecting source data and rules. State law can change the lists, definitions, exceptions, calling windows, disclosures, and internal suppression duties that apply. For example, Florida maintains a state no-sales-solicitation framework, Washington covers telephone solicitation received in the state, and California defines its own restrictions and exceptions around calls to listed numbers.

An area code is weak evidence of a person's location. Use the best location evidence available, record its source and confidence, and send unresolved conflicts to REVIEW or BLOCK under the approved policy.

3. Company-specific suppression

Someone may tell a brand to stop calling during a live call, through a web form, by text, through a human agent, or through another reasonable channel. This suppression layer changes faster than registry files and should be checked from the authoritative store at dial time.

A company-specific request overrides an established business relationship under the TSR. Do not attach a five-year expiry to the preference. The five-year requirement is a record-retention floor for these requests, not permission to resume calls when the record reaches its fifth anniversary.

Build a deterministic pre-dial gate

Keep call eligibility outside the language model. A model can extract an opt-out utterance for review, but it should not invent legal exceptions, choose an applicable jurisdiction, or override a suppression match. Put those decisions in a versioned policy service owned by your application.

A reliable workflow has two gates: one when a record enters a campaign and another immediately before the call is placed.

  1. Normalize the number. Retain the raw input, parse it to a canonical international format, and record the parsing result. Ambiguous or invalid numbers should not enter the callable queue.
  2. Resolve context. Identify the responsible seller or brand, campaign, call purpose, recipient jurisdiction, call technology, and any consent or exception evidence. Eligibility belongs to this complete context, not to a phone number alone.
  3. Load required sources. Retrieve the current National Registry dataset, applicable state data and rules, company-specific suppression state, and the approved policy version. Reject stale or unavailable mandatory inputs.
  4. Apply ordered rules. Company-specific suppression should win before any business-relationship analysis. Registry matches and exceptions should use explicit, counsel-approved conditions. Unresolved evidence gets a stable reason code.
  5. Write the decision record. Commit the input digest, data versions, policy version, result, reason, and evidence references before scheduling the call.
  6. Recheck at dial time. Repeat all mutable checks. A decision made during a nightly batch cannot authorize a call after a new opt-out, a source expiry, or a policy change.
  7. Bind the call to the decision. Send the decision ID and short expiry with the call job. The dial worker should reject a missing, expired, or context-mismatched decision.

The core evaluator can be simple:

if required_source_missing_or_stale: return BLOCK("SOURCE_UNAVAILABLE") if company_suppression_matches(seller, phone): return BLOCK("COMPANY_DNC") if jurisdiction_is_ambiguous: return REVIEW("JURISDICTION_AMBIGUOUS") if registry_matches(phone) and not approved_exception_is_valid(context): return BLOCK("REGISTRY_MATCH") return ALLOW(expires_at, policy_version, source_versions)

BLOCK is the safer production result for an automated dialer. REVIEW is useful only when a real review queue exists and no call can proceed while the record waits.

Make stale data fail closed

Registry recency is an outer legal limit, not a good cache time-to-live for call decisions. Use separate freshness rules for source data and for individual decisions:

  • Registry source age: reject a dataset after the counsel-approved maximum age. Alert well before that boundary so a failed refresh cannot stop the campaign without warning.
  • Company suppression age: read from the authoritative store at dial time or consume a strictly ordered change stream with measurable lag. A daily export is too slow for a live opt-out path.
  • Decision lifetime: make ALLOW short-lived. Its expiry should reflect how quickly suppression or exception evidence can change.
  • Policy version: invalidate queued decisions when a material ruleset update is activated.
  • Source health: expose last successful refresh, row count or digest, validation result, replication lag, and error status. Never silently reuse an unknown or partially loaded file.

Monitor the control plane, not only the scrub job. Useful alerts include source age, failed refreshes, sudden match-rate changes, decision latency, suppression replication lag, manual overrides, and calls blocked after they had already been queued.

Close the opt-out race

The dangerous race is straightforward:

  1. A campaign batch marks a record callable.
  2. The record enters a queue.
  3. The person opts out through another call, a text, the website, or a human agent.
  4. A worker uses the older result and starts the queued call.

The dial-time gate closes that gap only if suppression writes and reads have clear consistency rules. Implement these controls:

  • One authoritative preference key. Key suppression by responsible seller or brand, normalized phone number, and the scope approved by counsel. A campaign-local flag alone can let another campaign call the same person.
  • Idempotent writes. Retrying the same opt-out event must produce the same suppression state. Give each source event a stable idempotency key and retain its first-seen timestamp.
  • Monotonic state. A routine lead import must never change SUPPRESSED back to CALLABLE. Reversal needs a separate, authorized event with its own evidence.
  • Atomic dial claim. At the last call transition, compare the current suppression revision and decision expiry with the values on the job. If either changed, cancel the job and evaluate again.
  • Cross-channel ingestion. Accept spoken requests, keypad input, text, web forms, customer relationship management (CRM) updates, and human-entered requests into the same write path.
  • Immediate propagation. The current Federal Communications Commission (FCC) rule generally requires honoring a clear revocation request within 10 business days and permits reasonable revocation methods. Treat that as an outer limit. The system should suppress future automated calls as soon as it accepts the request. See the FCC calling rules.

Test the race directly. Pause a queued call, write an opt-out, resume the worker, and assert that no dial request leaves the system. Repeat the test during suppression-store latency, duplicate events, policy deployment, and registry refresh.

Treat exceptions as expiring evidence

An established business relationship (EBR) is not a universal pass. Under the TSR definition, it can arise from a transaction within the preceding 18 months or an inquiry or application within the preceding three months. The exact EBR definition includes conditions, and a company-specific DNC request still overrides it.

Represent any exception as evidence with scope:

  • seller and called party;
  • phone number and channel;
  • campaign purpose covered;
  • evidence type and source artifact;
  • event time, effective time, and expiry;
  • revocation state;
  • policy version that accepted it; and
  • reviewer or system actor.

Do not convert a CRM label such as customer=true into a standing authorization. The evaluator should be able to explain which condition applied, which evidence proved it, and whether that evidence was still valid when the call began.

Keep an audit record for every decision

The audit record should reconstruct the callability decision without relying on mutable CRM fields. This engineering decision log does not replace regulatory recordkeeping. For telemarketing covered by the TSR, map the design to every applicable record category in 16 CFR 310.5. Those categories include advertising and scripts, call-level data, customer and EBR records, consent evidence, service-provider contracts, company-specific DNC requests, and the National Registry version used. The rule generally requires covered records to be retained for five years, with category-specific starting points. Other laws, claims, contractual duties, or legal holds may require different records, longer retention, or suspended deletion. Counsel should approve the retention schedule and hold workflow.

At minimum, retain these fields for each callability decision:

FieldWhat it proves
Decision ID and timestampWhich evaluation authorized or blocked the job
Seller, campaign, and purposeWhose rules and exception scope applied
Raw-input reference and normalized numberWhich record was evaluated and how it was parsed
Jurisdiction evidenceWhich state rules were selected and why
Registry and list versionsWhich suppression data was checked
Policy versionWhich ordered rules produced the result
Match sources and reason codesWhy the record was blocked, allowed, or reviewed
Consent or exception referencesWhich artifacts supported an exception
Actor and override recordWhich system or authorized person changed the outcome
Dial-time recheck IDWhether the last gate ran against current state

Make the log append-only or otherwise tamper-evident. Restrict who can read raw phone numbers and consent artifacts. A digest can identify an input file without copying the full lead list into every record. Define deletion, legal hold, and access logging with the same care as collection. Our guide to voice AI data security covers the wider evidence lifecycle.

Evaluate a DNC vendor or application programming interface by failure behavior

A vendor application programming interface (API) can supply data, matching, policy tooling, or a complete decision service. The boundary must be explicit. Ask these questions before connecting it to a production dial path:

  1. Which sources are included? Get the National Registry, state, internal, and optional risk-data coverage separately. "Complete DNC" is too vague.
  2. How is source freshness exposed? Require a version, retrieval time, digest, and status that your policy service can evaluate.
  3. Can it support batch and dial-time checks? Batch throughput does not establish point-of-dial latency or availability.
  4. What happens on timeout or partial failure? Your integration must distinguish NO_MATCH from UNKNOWN. An error must never become an allow.
  5. Can internal opt-outs be written idempotently? Check scope, conflict handling, propagation time, and whether later imports can overwrite suppression.
  6. Are exceptions explainable? Require stable reason codes and evidence references, not a bare callable=true response.
  7. Can you reproduce an old decision? Audit exports need source and policy versions, timestamps, and override history.
  8. How is sensitive data handled? Review encryption, access boundaries, subprocessors, deletion, regional handling, and tenant isolation against your requirements.
  9. Can you switch providers? Keep your canonical suppression events, policy definitions, and decision records in a customer-controlled system so a data-vendor change does not erase history.

Test with a fixed fixture set that covers clean numbers, each suppression layer, stale data, conflicting jurisdictions, expired evidence, an internal opt-out, duplicates, and upstream timeouts. Run the same fixtures on every ruleset or vendor update and diff the reason codes.

Where Dasha fits

In an outbound voice product built on Dasha, your application remains the owner of call eligibility. It sends a call to our managed voice runtime only after the external DNC and policy gate returns a current ALLOW decision. During a call, the agent can invoke your approved external tool or API to record an opt-out through the same authoritative write path.

We do not position Dasha as a registry scrubber, consent validator, or compliance guarantee. We provide the production voice runtime around the customer-controlled compliance layer, including outbound call execution by API and calls to approved external tools. For the broader operating model, see our guides to AI telemarketing and AI cold calling.

DNC scrubbing FAQ

How often should a calling list be scrubbed?

For the TSR safe-harbor process, the National Registry version must be obtained no more than 31 days before the call. That is not a recommended cache lifetime for a complete decision. Check company-specific suppression at dial time, apply the approved freshness rule to each state source, and give every ALLOW result a short expiry.

Can an established business relationship override a DNC match?

An EBR may support a limited exception to a National Registry restriction when every condition is met. It does not override a company-specific request to stop calling. Store the relationship as expiring evidence tied to the correct seller, recipient, purpose, and policy version.

Does a clean scrub mean an AI voice call has consent?

No. The FCC has confirmed that AI-generated human voices fall within the Telephone Consumer Protection Act's artificial or prerecorded voice treatment. Its AI voice ruling states that telemarketing or advertising calls using such a voice require prior express written consent unless an applicable exemption applies. A DNC result and consent evidence answer different questions.

Is there a general federal rule requiring every AI caller to say it is AI?

The current federal calling rules do not create a general AI-specific spoken-disclosure mandate. Artificial or prerecorded voice messages have identification requirements for the responsible entity and callback information, plus an automated opt-out method where the rule applies. Campaign-specific federal and state duties still need counsel review.

Ready to connect a customer-controlled pre-dial gate to a managed real-time voice runtime? Evaluate Dasha for production voice AI.

Related Posts

We use cookies for functional and analytical purposes. Please refer to our Privacy Policy for details.