# CON-090 — The disclosure should say which number the messages come from

> The call-to-action should state the phone number or short code the programme will send from.

- **Rule ID:** CON-090
- **Layer:** Consent flow (`CONSENT_FLOW`)
- **Checks:** `consent disclosure text + campaign number set`
- **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the crawled website or policy page; AI vision over a consent artifact (screenshot, scan, MMS media)
- **Fix type:** Fix the website — no form edit clears it
- **Required by:** CTIA, T-Mobile
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/consent-flow/con-090/

## Why this rule exists

An unrecognised number is the most common reason a legitimate message gets reported as spam. Telling the consumer at signup which number to expect is what lets them recognise the first message instead of blocking it, and it is the cheapest protection a programme has against its own delivery rates.

## How to fix it

Add the sending number or short code to the consent block, and update it if you change numbers. Where you send from a pool, say so and name the range or the short code rather than listing every number. Done when the consumer knows what will appear on their screen.

## Example of a compliant value

```text
Messages come from short code 55512. Msg frequency varies. Msg & data rates may apply.
```

## Common mistakes

- Publishing a number you later migrate away from is worse than publishing none — treat the disclosure as something to keep current, not to set once.

## Notes

Graded MEDIUM, matching the catalog. CTIA lists it as element (2) of the call to action but no provider rejects on it alone, so it is surfaced as an improvement rather than a blocker.