# POL-091 — The policy must say how the number was obtained

> The privacy policy must describe how phone numbers are obtained, consistently with the registered message flow.

- **Rule ID:** POL-091
- **Layer:** Policy pages (`POLICY_PAGE`)
- **Checks:** `privacy policy body`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the submitted form
- **Fix type:** Fix the privacy policy or SMS terms
- **Required by:** Twilio, AWS
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-091/

## Why this rule exists

This is the sentence a reviewer compares against the message flow, and a disagreement between them reads as two different programmes — the registration says checkout, the policy says "when you contact us". It is also the answer to the first question anyone asks about an unexpected text, which is how did you get my number.

## How to fix it

Name every collection surface the registration declares, using the same words the message flow uses. Done when the policy and the message flow describe the same opt-in.

## Example of a compliant value

```text
We collect your mobile number when you tick the text-messaging box at checkout on acmecoffee.com. That is the only way we add a number to the programme.
```

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio (gen2) | `30909` | yes |

## Notes

The SMS-terms twin is POL-181, which asks the terms to describe every method, and POL-232 asks the same of the surfaces found by crawling. All three can disagree independently, which is why they are separate.