The policy must say how the number was obtained
The requirementstatement
The privacy policy must describe how phone numbers are obtained, consistently with the registered message flow.
- Severityseverity
- HighHIGHRejected by at least one carrier or provider, and a common cause of failure at the rest.
- When it bitesphase
- Gates approvalapprovalGet this wrong and the brand or campaign is refused at registration.
- What is checkedobject
- privacy policy body
- Where it liveslayer
- Policy pagesPOLICY_PAGE
- How Ekas settles itdetectability
- AI · formAI_FORM
- A semantic question about what you wrote: whether a description matches a use case, whether a name looks like a filed entity. Judged by a model against written criteria.
- What the fix involvesfailureClass
- Fix the policyTERMINAL_POLICY
- The fix lives in your privacy policy or SMS terms. Ekas can generate the missing clauses.
- Who requires itauthorities
- TwilioAWS
- When it appliesapplicabilityText
- Applies to every 10DLC registration.
Why this rule existsrationale
How to fix itremediation
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.
A compliant exampleexample
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 codescodes
The code you get back when this rule is what failed, and whether that provider lets you resubmit.
| Provider | Code | Resubmit |
|---|---|---|
| Twiliogen2 | 30909 | Yes |
Notesnotes
Rules you will hit next
6 other rules read privacy policy body. Fixing one field to satisfy a single rule is how a resubmission trades one rejection for another, so read these before you change anything.
POL-091 is one of 157 policy pages rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.