# OPS-083 — Carrier deactivation files must be ingested daily

> The carrier deactivation feeds must be processed every day and the listed numbers removed from every opt-in list.

- **Rule ID:** OPS-083
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `deactivation feed ingest job`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Falls due after approval, once you are live and sending
- **How it is detected:** External record we cannot query — reported as a warning to verify; Human check — only someone holding the document can settle it
- **Fix type:** Wait on an external system or a required interval
- **Required by:** T-Mobile, AT&T, CTIA, AWS
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-083/

## Why this rule exists

Around a hundred thousand US numbers are deactivated daily and most are reissued to somebody else within months. A consent record follows the number, so an unscrubbed list sends order details, appointment reminders or marketing to a stranger who never opted in — and delivery succeeds, so nothing in the sending metrics reveals it. The carriers publish the feeds specifically to make this preventable, which is why failing to consume them reads as negligence rather than bad luck.

## How to fix it

Confirm which party consumes the feeds — most CPaaS platforms offer it, several charge for it, and a few leave it entirely to the sender — then run the ingest daily and log each run with its timestamp. Done when a number deactivated on Monday is off your list on Tuesday.

## Example of a compliant value

```text
Daily 06:00: pull the T-Mobile and AT&T deactivation files, suppress the listed MDNs, log run_at and record count.
```

## Common mistakes

- Delivery failures are not a substitute. A reassigned number delivers perfectly — to the wrong person — so bounce handling never finds these.

## Check this yourself

**Is a number deactivated on Monday off your list on Tuesday — and who is running that ingest?**

1. Establish which party consumes the carrier deactivation feeds: most CPaaS platforms offer it, several charge for it, and a few leave it entirely to the sender.
2. Confirm it is enabled on your account, runs daily, and logs each run with a timestamp.
3. Check the retention window on the report objects — several platforms delete them after a few days, so a missed run cannot be replayed.

*What wrong looks like:* Around a hundred thousand US numbers are deactivated daily and most are reissued within months. Delivery to a reassigned number succeeds perfectly — to a stranger — so bounce handling never finds these.

## Notes

Absorbs OPS-084 and OPS-086, the same daily ingest against a second carrier feed and against a platform-mediated deactivation report. The feeds are carrier data we cannot see. What the user has to establish is whether their provider ingests them on their behalf, whether it is enabled on their account, and what the retention window on those report objects is — several platforms delete them after a few days, so a missed run cannot be replayed. OPS-085 is the approval-side twin: whether the programme describes doing this at all.