# OPS-050 — The opt-out confirmation is worth sending inside five minutes

> The single permitted opt-out confirmation should reach the consumer within five minutes of the revocation.

- **Rule ID:** OPS-050
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `opt-out confirmation latency`
- **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review.
- **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-050/

## Why this rule exists

A prompt confirmation is what buys the presumption that the revocation was honoured, and it is also the only signal the consumer gets that anything happened. Sent late it does the opposite work: a confirmation arriving the next day reads as another unwanted message from a programme they already left, and it is a common trigger for the complaint the confirmation was meant to prevent.

## How to fix it

Send the confirmation from the same handler that performs the suppression, synchronously, rather than from a batch job. Done when the confirmation arrives while the consumer still has the conversation open.

## Example of a compliant value

```text
STOP received 09:12:03 → suppressed 09:12:03 → confirmation delivered 09:12:05.
```

## Check this yourself

**Does the opt-out confirmation arrive while the consumer still has the conversation open?**

1. Send STOP to your own programme and time the confirmation.
2. Check it is sent synchronously by the same handler that performs the suppression, not by a batch job sharing a queue with marketing.

*What wrong looks like:* A confirmation arriving the next day reads as another unwanted message from a programme they already left — and triggers the complaint it was meant to prevent.

## Notes

A latency only measurable against real receipts. What the user has to confirm is that the confirmation is not queued behind an unrelated batch — the common cause of a slow one is that it shares a sending queue with marketing.