The loophole that got closed
Imagine you submitted a quote request on a home insurance comparison site in 2022. You checked one box. Over the next 72 hours, eleven different carriers called or texted you. Each one claimed you had given prior express written consent to be contacted. Technically, under the rules at the time, they were right.
That was the lead generator loophole. A single consent checkbox on a comparison or aggregator site could be written broadly enough to cover an unlimited list of “marketing partners.” The FCC’s December 2023 order, which took effect January 27, 2025, killed it. Now prior express written consent must be one-to-one: one consumer, one seller, obtained in a context that clearly identifies that specific seller by name.
If you are running outbound SMS or voice campaigns sourced from any kind of third-party lead flow, that change hits you directly.
What “one-to-one” actually means in practice
The new rule requires that consent be given to a specific seller, not a category of sellers and not a list disclosed somewhere in a privacy policy. The consumer has to take an affirmative step, on a form or interface you control or are explicitly named on, that makes clear they are agreeing to be contacted by you.
Shared lead forms where your brand appears as one of twenty logos in a disclosure paragraph? That is now on very shaky ground. Co-registration flows where a consumer opts in to a “network of partners”? Same problem.
What survives is consent collected on your own web property, your own SMS keyword opt-in, your own IVR, or a co-registration arrangement where your brand is the only one named and the call-to-action is unambiguous about who is going to contact them.
The documentation burden also went up. You need to be able to show: when the consent was recorded, what the form or interface looked like at that moment, what phone number was submitted, and that the number matched a real, reachable line at the time of submission. That last point is where phone validation stops being optional.
Why line type is the threshold question
The TCPA draws a hard line between mobile numbers and everything else. Autodialed or prerecorded calls and texts to a mobile number require prior express written consent. Calls to a residential landline only require prior express consent (no “written” requirement). Calls to a business line have even more flexibility.
So before you decide what consent flavor you need, you have to know what you are calling.
This sounds obvious, but in practice lead forms collect a phone number and nothing else. A consumer can type in a Google Voice number, a VoIP line, a ported-away number, or a landline. You cannot tell by looking at it. The 10-digit format is identical.
CheckThatPhone’s nanpType field returns mobile, landline, or not-mobile in real time. That one field determines your consent requirement. If nanpType returns mobile, you need the full prior express written consent record. If it returns landline, your obligation is lighter, though you should still verify the number is reachable.
dipCarrierSubType gives you more granularity: it will distinguish a traditional wireless line from a VoIP or virtual number. That matters because VoIP lines assigned to a mobile-style DID can show up in consumer flows and courts have not been uniform about how they treat them. Knowing the subtype lets you flag those for manual review rather than loading them straight into your dialer.
What a defensible consent record looks like now
A defensible record has four components:
First, a timestamped screenshot or server-side render of the exact form the consumer saw, with your brand name visible and the consent language legible.
Second, the submitted phone number with a validation result attached. This is your evidence that the number was a real, active, mobile line at the moment of opt-in, not a mistype or a Google Voice placeholder.
Third, the dipPorted flag. If a number has ported since consent was collected, it may now belong to a different person. Running periodic re-validation on your list and logging ported status gives you a defensible chain of custody.
Fourth, a litigator scrub result. Serial TCPA plaintiffs are well documented. Adding litigatorFilter: true to your lookup request returns litigator, litigator_type, and litigator_name. Calling a known litigator is not automatically losing, but it is expensive to defend and you will have a hard time explaining why you did not check. The TCPA litigator scrub use case walks through exactly how to integrate this into a signup flow.
A single API call to POST https://api.checkthatphone.com/v1/lookup with your Authorization: Bearer <key> header can return all of this at once. You store the response alongside your consent record in your CRM. That is your paper trail.
What to do with your existing list
The one-to-one consent requirement does not automatically invalidate consent you collected before January 27, 2025, but it does mean you should be able to demonstrate, for each record, that the consent you have would meet the new standard. Blanket “network of partners” opt-ins almost certainly do not.
For any large list you are unsure about, the fastest path to an answer is running it through bulk validation. In the CheckThatPhone dashboard, go to Dashboard, then Bulk CSV, upload your file, and the system deduplicates, runs carrier and line type validation (plus litigator scrub and landline SMS lookup if you enable those add-ons) on every row, then produces a downloadable result file. Uploaded files and results are deleted within 24 hours of delivery. For real-time per-form validation during signup, use the /v1/lookup endpoint directly.
From the bulk results, I would segment three ways: numbers where nanpType is mobile and litigator is false and deliverable is true, those go into your verified contact pool. Numbers where litigator is true, pull those out completely. Numbers where deliverable is false or deactivationDate is populated, those are dead lines and should be suppressed regardless of what consent you think you have. See the contact list hygiene use case for a fuller walkthrough.
Landlines are a separate question. If you want to send SMS to a landline number through a carrier that supports it, landlineSmsLookup: true on the request returns dipMessagingLookup, dipMessagingEnabled, and dipMessagingProvider. You might be surprised how many landlines now support text delivery through providers like Bandwidth or Syniverse. That does not change your consent obligations, but it does change what channels are actually reachable.
The practical bottom line
The 2024 FCC change is annoying if your acquisition stack relied on aggregator leads, and there is no clean workaround. The answer is tighter consent collection, better documentation, and real-time validation at the point of opt-in so you know exactly what you collected and when.
For every new mobile opt-in, run nanpType at form submission, store the full API response with your consent record, and enable the litigator scrub. For your existing list, run a bulk validation pass before your next campaign. The pricing page shows what that costs at volume, and the API docs have the full field reference.
None of this is a legal opinion, and if you are running high-volume outbound you should have TCPA counsel review your specific flows. But the validation layer is table stakes now, and it is not complicated to implement.