Quick answer: A litigator scrub blocks sends to numbers on a known-litigator list before the message dispatches — the recipients who answer one unsolicited SMS with a lawsuit under 47 U.S.C. § 227. On Devotel Orbit the scrub resolves every SMS/MMS send to a US destination against a layered lookup (import-time contact flag, 24-hour verdict cache, live Numeracle call, seeded list), blocks non-consented sends to US numbers, and lets a consented send through with an audit record either way. The feed behind it reflects roughly 36 months of TCPA lawsuit history refreshed on a daily cadence, and both the block and the consent it consults are exportable as CSV/JSON for a discovery request.
This field note covers the exposure model, how the scrub resolves, what the history window and re-scrub cadence actually mean, why the gate reads the same consent/suppression ledger as the rest of the send path, and how to pull the audit evidence out. It is a tenant rundown, not legal advice — the 10DLC registration side of compliant SMS is covered in Why 10DLC Campaigns Get Rejected.
1. TCPA exposure from known litigators
The statutory numbers: $500 per violation of the TCPA, trebled to $1,500 when the violation is willful, under 47 U.S.C. § 227(b)(3). What makes known litigators a separate problem from garden-variety non-consensual sends is that the exposure is manufactured — professional plaintiffs keep answerable numbers specifically to receive unsolicited A2P traffic and file on the first one that lands. Their model depends on you not scrubbing; one message to one listed number is the entire complaint.
Two operational consequences follow from the model:
- Per-message economics flip the remediation order. At $500–$1,500 per send, a 100-recipient campaign that includes one litigator number is the most expensive line item on the campaign. Pre-flight scrubbing is cheaper than any complaint response.
- "We only send to consented contacts" is a consent defense, not a scrub defense. A strong opt-in record answers a litigator's complaint legally — but the gate lets you avoid the send entirely, and the consent record answers the ones that still get through. The two layers are complementary, which is why the Orbit scrub checks both.
Voice carries its own federal exposure surface (the dialing-window guard, a platform-level hard guard with no opt-out), but the Litigator-Known scrub is scoped to SMS and MMS — the TCPA channels where the plaintiff lists are populated.
2. How the Litigator-Known scrub works on Orbit
The gate is off by default — a tenant-owned control you opt into per organization, not a platform screen. US operators turn it on in Settings → Compliance or by setting tcpa_check_enabled: true in general settings; non-US operators leave it off because a US statutory check on traffic that never touches +1 recipients adds latency and audit noise for no benefit. Once enabled, every SMS/MMS send on the organization resolves the recipient through a layered chain, cheapest first:
- Import-time contact flag. A bulk import that already stamped the contact as a known litigator settles the lookup with no network call — one computation per import, not per send. This is the layer that makes the scrub cheap at campaign volume.
- Cached verdict. Recent verdicts live in a 24-hour cache so campaign-scale traffic doesn't re-call upstream — the freshness tradeoff is bounded by the one-day TTL.
- Live lookup. When the operator has a list-provider key configured, the chain calls the upstream feed and caches the verdict. On hosted Orbit the key is provisioned for you.
- Seeded list. The platform-shipped list is the last-resort source when the live lookup is unavailable.
When the chain puts a US destination on the list with no matching opted-in consent, the send is blocked with 403 TCPA_KNOWN_LITIGATOR_BLOCKED — and the block resolves before billing, so a scrubbed send never charges. The response names which layer flagged the recipient (contact_flag, cache, the upstream feed, the seed, or a manual override) and, when the feed provides one, a 0–100 risk score. Non-US destinations are a soft warn, not a hard block: the send proceeds and the flag is recorded for post-hoc review, because the TCPA hard-block scope is NANP.
Failure mode: the scrub fails open. A Redis, database, or upstream-feed outage does not block outbound — the send goes through and the fault is logged. That is deliberate: a preflight outage must never black-hole all outbound messaging. If you want fail-closed during a live complaint, the manual-override surface force-flags numbers independent of the upstream chain.
3. Why 36-month history with a daily re-scrub cadence is the performant shape
The history window and the re-scrub cadence are the two knobs that determine whether the scrub actually protects you, and both matter more than the list brand.
History window. Phone numbers get recycled, and the seed-list providers track lawsuit history over a dozens-of-months window, not the current month's complaints. A 36-month lawsuit-history lookback is the window that catches the plaintiff who filed in 2024, changed numbers, and re-entered with a fresh identity — a scrub backed by only this quarter's complaints misses exactly the litigators with the oldest and most practiced playbooks. The 36-month figure is what the known-litigator feeds aggregate; shorter windows trade recall for recency and lose the long-tail plaintiff.
Re-scrub cadence. A list that is current as of some historical date is itself the exposure — plaintiffs file, settle, change numbers, and new numbers get flagged every day, so a monthly re-scrub means the average verdict is two weeks stale. The daily re-scrub cadence is what the scrub layers (import flag, 24-hour cache, live lookup) decompose to:
- Upstream lists refresh daily; the live-lookup layer reads the current day's state.
- A cached verdict is guaranteed fresh to within one day (the 24-hour TTL).
- Admin-set manual overrides land immediately and persist across both the cache and the seed.
The consequence for a multi-channel campaign: numbers cleared by yesterday's list are re-validated at send time, not once at import, so a number that got flagged between the audience build and the send is still blocked.
4. One ledger, every send gate
The Litigator-Known scrub is one of several gates that read tenant consent and suppression state — DNC, quiet hours, the TCPA block-and-bypass, the outbound-dialer pre-flight — and on Orbit they all resolve against the same consent and suppression ledger, not per-channel silo lists. That matters for three reasons:
- An opt-out (STOP to SMS, DNC to the dialer) enters one ledger and every gate enforces it from the next send forward — there is no "respected on the campaign tool but not on the dialer" window.
- The consented-bypass the scrub uses — a flagged recipient with a matching opted-in consent record is allowed through, with an audit record of the decision — is only meaningful because the consent it consults is the same record the message and voice gates also honor. One set of books, one source of truth.
- Campaigns and dialers with different tooling share suppressions; a suppression recorded by one outbound channel constrains the others, because the ledger is tenant-owned and cross-channel.
This is also why the gate can run at the send boundary rather than at audience-build time: the ledger the gates read is the same one, so the check does not go stale between build and send.
5. Export suppression + consent as audit evidence
The controls above are exact but internal until they can be shown. Two admin/owner-scoped exports produce the proof — one row per consent event, one row per suppression record — as CSV or JSON, with the export itself audited:
- Consent proof-of-record —
GET /api/v1/compliance/consent/export: one row per consent event (opt-in, opt-out, unknown) joined to the contact, filterable by channel, state, contact, and a date window carrying the fixed-column schema a discovery request consumes with no reformatting. - Suppression ledger —
GET /api/v1/compliance/suppression-list/export: the durable (channel, address) suppression entries, including bulk imports, filterable by channel, active/revoked status, and date window.
For a scrub-blocked send, the evidence package is three artifacts: the block decision audit entry (which layer flagged the recipient, and the verdict source and risk score), the consent export showing the absence of opted-in consent for the recipient and channel at that point in time, and the suppression export showing the address set the gates were enforcing. All three are produced without a manual database pull, and the exports themselves land in the audit log, so the evidence trail includes the act of producing it. The endpoint shapes and the worked example of a bounded-window pull are in Export Consent & Suppression Records.
Frequently asked questions
Does the litigator scrub apply to outbound voice calls too?
No — the Litigator-Known scrub is scoped to SMS and MMS sends to US destinations. Outbound voice carries its own TCPA dialing-window guard (a platform-level hard guard with no opt-out, not tenant-scoped). To screen recipients before a voice campaign, use the manual-override surface or pre-flag contacts at import time.
What happens if my recipient has opted in but is on the litigator list?
With a matching opted-in consent record, the gate allows the send and records a consented bypass in the audit log — the decision to allow is deliberately documented, so a post-hoc compliance review can inspect that the bypass was intentional and which layer flagged the number.
How fresh is the list — is a 24-hour cache stale enough to matter?
The upstream feed refreshes daily, and the scrub's verdict cache has a 24-hour TTL, so a cached verdict is at most one day old at the send boundary. A number flagged between the audience build and yesterday's cache deadline is caught by the live-lookup or seed layer; admin manual overrides take effect immediately.
Can I prove a scrubbed number was blocked when the complaint arrives?
Yes — the blocked send writes a decision audit entry naming the flag layer, source, and risk score; the consent export shows the lack of opted-in consent for that channel; and the suppression export shows the address set in effect. All three are export artifacts the tenant can produce per discovery window.
Who enables the Litigator-Known scrub?
The organization admin. It is a tenant-owned, opt-in control: US-bound operators toggle it on in dashboard Compliance settings (or set tcpa_check_enabled: true in general settings), and it then runs on every SMS/MMS send from that organization.
The takeaway
A litigator scrub is per-message insurance at complaint prices Orbit tenants can't afford — and it only works if the feed is deep (36-month history), the re-scrub is daily (24-hour cache bound), the gates read one consent/suppression ledger across channels, and the blocks and bypasses are exportable as audit evidence. The four are the design of the Devotel Orbit Litigator-Known scrub; enable it per organization in Compliance settings and the send path enforces it on every SMS/MMS send to US destinations.