# OPS-061 — A later form fill does not undo an earlier opt-out

> A consumer who opted out must not be re-subscribed on the strength of a subsequent form submission without a fresh, separately documented opt-in.

- **Rule ID:** OPS-061
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `consent record against opt-out record`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Falls due after approval, once you are live and sending
- **How it is detected:** Not knowable before submission — reported with its deadline
- **Fix type:** Wait on an external system or a required interval
- **Required by:** FCC
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-061/

## Why this rule exists

Somebody who unsubscribed in March and buys something in June has given you their number for the order, not permission to restart the programme they left. Systems do it automatically because the checkout writes the number to the marketing list the same way it always did, and the result is a consumer receiving messages from a programme they explicitly quit — the pattern that produces the angriest complaints.

## How to fix it

Check the suppression list before writing any new consent, and require an explicit, separately recorded opt-in — not a pre-ticked box on a checkout — before removing a number from it. Done when a previously-opted-out number stays suppressed through an ordinary purchase.

## Example of a compliant value

```text
Checkout writes consent → suppression list hit → consent stored as pending, no messages sent, and the customer is shown the opt-in box unticked.
```

## Common mistakes

- Treating the new consent as newer and therefore controlling is the intuitive data model and the wrong one; an opt-out is a standing instruction, not a timestamped preference.

## Check this yourself

**Does a previously opted-out number stay suppressed through an ordinary purchase?**

1. Check the order of operations at every signup surface: most write consent first and reconcile later, if at all.
2. Require an explicit, separately recorded opt-in — not a pre-ticked checkout box — before removing anyone from the suppression list.
3. Test it with a number that opted out months ago.

*What wrong looks like:* Someone who unsubscribed in March buys something in June and the checkout writes their number back to the marketing list. Treating the newer record as controlling is the intuitive data model and the wrong one.

## Notes

A comparison between two records that only exist after launch. What the user has to check is the order of operations at their own signup surfaces — most write consent first and reconcile later, if at all.