# CMP-112 — A promotional programme cannot rest on spoken consent alone

> A campaign whose content requires express written consent must not declare a spoken opt-in as its only collection method.

- **Rule ID:** CMP-112
- **Layer:** Campaign (`CAMPAIGN`)
- **Checks:** `campaign.usecase + declared consent methods`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** Deterministic (settled in code from the submitted values)
- **Fix type:** Produce a document that does not exist yet
- **Required by:** FCC, Twilio, Infobip, Bandwidth
- **Applies:** Applies when consent was collected by live verbal and IVR.
- **Canonical URL:** https://ekas.io/rules/10dlc/campaign/cmp-112/

## Why this rule exists

Written consent exists so that what the consumer agreed to can be produced years later when a complaint arrives, and a phone call produces no such record — an agent's note that the customer said yes cannot show what they were told they were saying yes to. Businesses reach this honestly: the call centre already asks for consent for service messages, and adding the marketing programme to the same script looks like a small extension rather than a change of consent grade.

## How to fix it

Collect the promotional consent in writing — a signed form at the counter, or a web opt-in the customer completes themselves — and keep the spoken path for the service messages it is valid for. Done when every number receiving promotional content has a written record behind it.

## Common mistakes

- Numbers already collected verbally cannot be moved onto the written programme by re-characterising the consent; they have to be asked again.
- Reading the written disclosure aloud does not make the consent written. What matters is the record the consumer produced, not the words the agent said.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio | `30913` | yes |
| Bandwidth | `2101` | yes |

## Notes

The use-case condition lives in the check rather than in an applicability tag, because it is read off USE_CASE_REQUIREMENTS.consentGrade — a table row rather than a fixed list, so a use case added later is covered without editing this rule. The tag narrows to the spoken methods, which is what makes the rule inapplicable to a web or checkout opt-in instead of passing trivially on one. The legal layer records the Fifth Circuit *Bradley v. DentalPlans.com* carve-out; carriers do not honour it, so the registry does not either.