# Ekas 10DLC Rule Registry — Policy pages > The 157 policy pages rules Ekas checks during A2P 10DLC registration. - Source: https://ekas.io/rules/10dlc/ - Rules in this document: 157 - Registry last updated: 2026-07-25 - Licence: CC BY 4.0 — https://creativecommons.org/licenses/by/4.0/ - Layer: `POLICY_PAGE` --- ## POL-001 — A privacy policy URL is required on the campaign > Every campaign registration must carry a non-empty privacy policy URL. - **Rule ID:** POL-001 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `campaign.privacyPolicyUrl` - **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:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth, AWS, Telnyx, Sinch, Plivo, Bird - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-001/ ### Why this rule exists The policy is the document a consumer is entitled to read before handing over a number, so a registration without one is asking carriers to approve a programme nobody can inspect. Twilio codes the missing field separately from a failed policy review precisely because the usual cause is mechanical — integration code written before the field became mandatory simply never sends it, and every campaign that integration creates fails the same way. ### How to fix it Set the privacy policy URL on the campaign to the https address of the published policy page. Done when the field holds a URL you can open in a private window and read. ### Example of a compliant value ```text privacy_policy_url: https://acmecoffee.com/privacy ``` ### Common mistakes - If campaigns are created through an API integration, the empty field is in your code rather than on the form — check the request body before re-filing, or the next campaign fails identically. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30933` | yes | | Twilio (gen1) | `30908` | yes | --- ## POL-002 — A terms and conditions URL is required on the campaign > Every campaign registration must carry a non-empty terms and conditions URL. - **Rule ID:** POL-002 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `campaign.termsOfServiceUrl` - **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:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth, AWS, Sinch, AT&T, T-Mobile - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-002/ ### Why this rule exists The terms are where the messaging programme is documented for the person receiving it — what it sends, how often, how to leave — so an empty field leaves the consumer with nothing to consult and the reviewer with nothing to check the samples against. TCR calls the field optional while its own guide says compliant terms are required, which is how a registration ends up submitted without one and rejected for not having one. ### How to fix it Set the terms URL on the campaign to the https address of the SMS terms page. Done when the field holds a URL that opens the messaging terms rather than the general site terms. ### Example of a compliant value ```text terms_and_conditions_url: https://acmecoffee.com/sms-terms ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30934` | yes | | Twilio (gen1) | `30882` | yes | ### Notes TCR marks the field optional in its schema and requires compliant terms in its CSP guide. Treated as required here, per the strict-superset model: supplying it costs nothing at the destinations that do not demand it. --- ## POL-003 — An uploaded policy document must fit the provider file constraints > Where a policy is uploaded rather than linked, the file must be a PDF, PNG or JPEG within the tightest provider size cap. - **Rule ID:** POL-003 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `campaign policy document upload` - **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:** Fix the field — a better value in the form clears it - **Required by:** AWS, TCR, Bandwidth, Telnyx - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-003/ ### Why this rule exists Uploading is the sanctioned route for a brand with no website or an offline opt-in, and the caps differ by an order of magnitude — 500 KB at AWS against 10 MB at TCR — so a file that uploads cleanly at one destination is rejected at another with an error about the campaign rather than about the file. A scanned policy from an office printer is several megabytes without anyone intending it to be. ### How to fix it Re-export the document as a PDF under 500 KB — print to PDF rather than scanning, or downsample the scan to 150 dpi — and re-upload. Done when the file is one of PDF, PNG or JPEG and under half a megabyte. ### Example of a compliant value ```text acme-privacy-policy.pdf · application/pdf · 210 KB ``` ### Common mistakes - A hosted URL is preferred wherever a website exists; WEB-054 fails a PDF that stands in for a page the brand could have published. ### Notes Applies only where a document was uploaded, which no applicability dimension expresses — the check passes immediately when the registration carries none. The 500 KB ceiling is AWS's, taken as the tightest cap so a submission survives a destination that has not been chosen yet. --- ## POL-005 — The terms and conditions attestation must be set > The campaign's terms-and-conditions attestation flag must be set to true, alongside supplying the URL. - **Rule ID:** POL-005 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `campaign.termsAndConditions attestation` - **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:** Fix the field — a better value in the form clears it - **Required by:** TCR, Bird, Bandwidth, Azure ACS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-005/ ### Why this rule exists The flag is a declaration by the registering party, not a pointer to a document: at TCR it attests that the campaign runs no affiliate marketing, and at Bandwidth and Bird that the programme follows the CTIA principles. Its enum permits only true, so an unset flag is rejected before any document is fetched — and because the form shows it next to the URL field, people assume filling one satisfies the other. ### How to fix it Set the terms-and-conditions attestation to true on the campaign, and make sure the statement it carries is actually true of your programme before you do. Done when both the flag and the URL are set. ### Example of a compliant value ```text terms_and_conditions: true · terms_and_conditions_url: https://acmecoffee.com/sms-terms ``` ### Common mistakes - At TCR the flag attests that the campaign involves no affiliate marketing. Setting it true on a campaign that does is a false attestation, not a form-filling step — fix the campaign instead. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | TCR | `501` | yes | ### Notes Absorbs POL-006, which states the same flag together with the reminder that the flag alone is not enough. The URL half is POL-002. --- ## POL-010 — Both policy URLs must resolve and return content anonymously > The privacy policy and terms URLs must resolve in DNS and return a successful response to an anonymous fetch — no session, no cookie, no member wall. - **Rule ID:** POL-010 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy URL + terms URL fetch` - **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:** Fix the privacy policy or SMS terms - **Required by:** TCR, Twilio, Bandwidth, AT&T, T-Mobile, AWS, Sinch - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-010/ ### Why this rule exists The reviewer's fetcher has no account and no cookies, so a policy behind a member area or a consent wall is indistinguishable from a policy that does not exist — and the rejection says the policy failed review rather than that it was never read. The common causes are all invisible from the inside: a page that requires the site's own cookie banner to be accepted, a URL that 404s after a redesign, a host that resolves only on the office network. ### How to fix it Open both URLs in a private browser window with no session, from a network that is not yours, and fix whatever stops the page rendering. Done when both return the policy text to a plain fetch with no login and no interstitial. ### Common mistakes - A page that renders only after the cookie banner is accepted returns an empty body to a fetcher. Serve the policy text before the banner, not behind it. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | | Bandwidth/DCA | `7101` | yes | ### Notes Absorbs POL-011 (HTTP status), POL-012 (liveness) and POL-013 (anonymous access): DNS, status and an access wall are three ways one anonymous fetch fails, on either document, with one fix. --- ## POL-015 — The policy host must serve a valid certificate of its own > The host serving the policy pages must present a valid TLS chain, checked independently of the brand website host. - **Rule ID:** POL-015 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy + terms URL TLS chain` - **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:** Fix the privacy policy or SMS terms - **Required by:** Bandwidth, TCR, AT&T, T-Mobile, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-015/ ### Why this rule exists Policy pages are routinely hosted somewhere else — a docs subdomain, a help centre, a legal-template service — so the website's certificate says nothing about them, and a certificate failure on the policy host alone is enough to reject a brand whose marketing site is perfect. Bandwidth codes it as a standalone reject reason for exactly that reason. ### How to fix it Renew or reissue the certificate for the policy host, including any subdomain the policy sits on, and test it from outside your network. Done when an external SSL checker reports a complete valid chain for both policy URLs. ### Common mistakes - A wildcard certificate for *.acmecoffee.com does not cover a policy hosted on a vendor domain. Check the host in the URL you actually submitted, not the one you think of as yours. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7105` | yes | | Bandwidth | `1103` | yes | ### Notes Severity divergence in the catalog: TCR and the carriers rate a TLS failure MEDIUM, Bandwidth and AWS treat 7105 as a standalone rejection. Strictest kept. The website equivalent is WEB-073, and the two fail independently because the two hosts often differ. --- ## POL-016 — The privacy policy URL must open an actual privacy policy > The privacy policy URL must resolve to a real privacy policy — not the homepage, a stub, a placeholder, or a generic landing page. - **Rule ID:** POL-016 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body (document classification)` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Bandwidth, Telnyx, AWS, Ringover - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-016/ ### Why this rule exists A URL that opens something other than a policy is read as a policy that failed review, so the rejection blames the document rather than the link. It happens through ordinary site maintenance: the policy path is retired in a redesign and the server helpfully serves the home page instead of a 404, which is worse than the 404 because nothing looks broken. ### How to fix it Point the field at the page whose content is the policy, and confirm what it opens rather than trusting the path. Done when the URL loads a document headed as a privacy policy and containing its sections. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7102` | yes | --- ## POL-018 — Policy pages must be machine-crawlable > The policy pages must be fetchable by an automated vetter — no robots.txt disallow, no noindex, no JS-only render, no geofence. - **Rule ID:** POL-018 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy URL + terms URL` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-018/ ### Why this rule exists Vetting fetches your policy with a headless client, not a browser. A page that renders only after JavaScript, or that robots.txt forbids, is indistinguishable from a page that does not exist — so a perfectly compliant policy fails because the reviewer's crawler saw nothing. ### How to fix it Serve the policy as server-rendered HTML, remove any robots.txt disallow or noindex on those paths, and confirm the page returns content with JavaScript disabled and from a US IP address. --- ## POL-020 — A non-English site needs an English policy > Where the site is published in another language, an English version of the policy pages must exist. - **Rule ID:** POL-020 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `policy page language` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-020/ ### Why this rule exists US 10DLC review is performed in English, and machine translation of a legal document fails in exactly the places that matter — the non-sharing clause reads as a general privacy promise once it has been through a translator. A business serving a non-English-speaking market has every reason to publish only in that language and no reason to expect this. ### How to fix it Publish an English version of the privacy policy and SMS terms at their own URLs, and submit those URLs on the campaign. Done when the registered links open English documents, whatever the rest of the site is in. ### Notes Single unverified secondary source in the catalog, hence MEDIUM. The site-side equivalent is WEB-018; both can fail independently, since a bilingual site frequently has monolingual policy pages. --- ## POL-021 — Policy URLs must not redirect > A URL submitted for a policy page must resolve directly rather than returning a 30x redirect. - **Rule ID:** POL-021 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy URL + terms URL` - **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 crawled website or policy page - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-021/ ### Why this rule exists TCR forbids redirection on fetched URLs, so a link that bounces from http to https, or from a marketing path to a canonical one, can fail even though a human browser follows it invisibly. This is one of the least intuitive rejections because the link works perfectly when you click it. ### How to fix it Submit the final canonical URL — the one you land on after every redirect — including https and any trailing path normalisation. ### Example of a compliant value ```text Submit https://acmecoffee.com/privacy-policy rather than http://acmecoffee.com/privacy ``` --- ## POL-022 — The policy must be the brand's own, not a platform's > A reseller's, platform's, ISV's or generic vendor privacy policy must not be submitted in place of the brand's own. - **Rule ID:** POL-022 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body (authorship)` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Telnyx, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-022/ ### Why this rule exists The policy is a promise by the business that collected the number, and a platform's policy promises nothing on the brand's behalf — so the consumer has no commitment from anyone they actually deal with. Telnyx names the specific version of this it sees most: Google's policy submitted as the brand's, because the business runs on Google services and assumed that covered it. ### How to fix it Publish a policy in the brand's own name covering the brand's own data handling, and link the platform's policy separately if you want to. Done when the document names the registered business as the party making the promises. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7102` | yes | ### Notes About authorship, and distinct from POL-021, which is about where the document is hosted. A brand-authored policy hosted on a vendor domain passes this and fails that; a vendor-authored policy on the brand's own domain does the reverse. --- ## POL-023 — A social profile is not a policy page > A social-media profile or post must not be submitted as the privacy policy or terms URL where the brand has a website. - **Rule ID:** POL-023 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy URL + terms URL host` - **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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-023/ ### Why this rule exists A profile page is not a document: it has no stable URL for a specific text, no version, and no guarantee the platform will show the same thing to a logged-out reviewer. Businesses do it because they published their terms as a pinned post and that is the only link they have, which is exactly the situation the fix addresses. ### How to fix it Publish the policy as a page on the brand website and submit that URL. Done when the policy URL opens a document on your own domain rather than a profile on somebody else's. ### Example of a compliant value ```text privacy_policy_url: https://acmecoffee.com/privacy, not https://facebook.com/acmecoffee/about ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `1100` | yes | ### Notes Single secondary source in the catalog with no carrier code behind it, so HIGH rather than BLOCKING. Fires only where a website exists — a brand with no site at all should upload the document instead, which is POL-003. --- ## POL-024 — The site hosting the policy must itself be live and real > Where consent is collected offline, the site hosting the policy pages must still be a live, authentic site rather than a shell built to hold them. - **Rule ID:** POL-024 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `policy host site` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Aerialink, AWS - **Applies:** Applies when consent was collected by paper form, QR code, point of sale, live verbal and IVR. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-024/ ### Why this rule exists An offline programme can be flawless on paper and still sink on the site nobody thought was being assessed, because the policy has to live somewhere and that somewhere gets crawled like any other brand site. A single-page host stood up to carry two documents looks exactly like the shell sites the authenticity screen exists to catch. ### How to fix it Host the policy pages on the business's real website. Where there is none, publish a small but genuine site describing the business alongside the documents, rather than a bare page carrying only the policy text. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `807` | yes | ### Notes Tagged to the offline consent methods, which is where the catalog states it and where it bites: a web opt-in already puts the site itself under WEB-024, so this rule adds nothing there. --- ## POL-025 — Exactly one privacy policy must be discoverable > The brand domain must present a single discoverable privacy policy, not several copies or versions. - **Rule ID:** POL-025 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `all discoverable privacy policies on the brand domain` - **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 crawled website or policy page - **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-025/ ### Why this rule exists Two policies mean a reviewer has to guess which one governs, and Twilio treats that ambiguity as preventing review rather than as a tidiness problem. The usual cause is a platform default left in place beside a custom one — a Shopify or Wix policy page still reachable at its original path while the real one lives somewhere else — so both are live and neither is wrong. ### How to fix it Delete or redirect every policy page except the canonical one, including the platform default at its original path, and point every link at the survivor. Done when searching your own site for "privacy" returns one document. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | ### Notes Needs a multi-page crawl to settle. Against a single-page fetch the judge can only report what it saw, so it must say which pages it read rather than treating one policy found as one policy existing. --- ## POL-026 — The policy on the site and the policy attached to the registration must agree > Where a policy document is uploaded with the registration and a policy also exists on the site, the two must not conflict. - **Rule ID:** POL-026 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `crawled policy body vs uploaded policy document` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-026/ ### Why this rule exists A reviewer holding two versions reads the weaker one as the truth, so an uploaded document that has been carefully updated does not rescue an old page still live on the site. This happens whenever the upload is prepared for the registration and the website is left alone, which is the normal order of events. ### How to fix it Publish the uploaded version on the site so the two are the same document, and upload the published page rather than a separately maintained file. Done when the attached document and the live page carry identical messaging clauses. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | ### Notes Different comparison from POL-025: that one is about duplicates on the site, this one about the site disagreeing with the submission. Applies only where a document was uploaded, which the criteria carry as an immediate pass. --- ## POL-027 — The policy URLs must stay live after approval > The registered privacy policy and terms URLs must remain reachable after the campaign is approved. - **Rule ID:** POL-027 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `registered policy URLs after approval` - **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:** Twilio, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-027/ ### Why this rule exists Approval is not the end of the checking: the URLs are re-crawled afterwards, and a page that disappears triggers re-vetting rather than a request to restore it. Sites get redesigned and paths get renamed months later by people who have never heard of the registration, so the failure arrives long after anyone connects it to a cause. ### How to fix it Keep both URLs live for the life of the campaign, and redirect rather than delete if a path has to change. Done when the registered links still open the documents months after approval. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | ### Check this yourself **Are the two registered policy URLs on whatever you use to monitor your own site, and does a redesign count as a registration event?** 1. Add both URLs to your uptime or link monitoring. 2. Redirect rather than delete if a path has to change. 3. Tell whoever owns the site that these two paths are registered, because they will be renamed by someone who has never heard of the registration. *What wrong looks like:* A redesign renames a path months after approval. The re-crawl finds nothing, triggers re-vetting rather than a request to restore it, and nobody connects the two events. ### Notes Absorbs OPS-269, which states the same monitoring duty with its re-vetting consequence. Nothing at submission time can settle it. The user has to add the two registered URLs to whatever they use to watch their own site, and to treat a redesign as a registration event. --- ## POL-028 — Keep a dated copy of both documents as submitted > Both policy pages should be captured at submission so the exact version that was reviewed can be produced later. - **Rule ID:** POL-028 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy + terms as submitted` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-028/ ### Why this rule exists An appeal turns on what the reviewer actually saw, and by the time one is filed the pages have usually been edited — often in response to the rejection itself. Without a capture there is no way to show that the document met the requirement on the day, so a winnable appeal becomes an argument nobody can settle. ### How to fix it Save a dated PDF or archive capture of both pages at the moment you submit, and keep it with the registration record. Done when you can produce the exact text that was live on the submission date. ### Check this yourself **Do you hold a dated capture of both policy pages exactly as they were on the day you submitted?** 1. Print both pages to PDF, or take an archive capture, before pressing submit. 2. Store it with the registration record. 3. Done when you can produce the exact text that was live on the submission date. *What wrong looks like:* The appeal turns on what the reviewer saw, and by then the pages have been edited — often in response to the rejection itself. A winnable appeal becomes an argument nobody can settle. ### Notes Product hygiene rather than a published carrier rule — the catalog records it as a recommendation. Nothing we hold proves a capture was taken, so this is on the user: print both pages to PDF, or archive them, before pressing submit. --- ## POL-030 — Both documents must be linked from the site footer on every page > The privacy policy and the terms must be linked from the footer of every page on the brand site. - **Rule ID:** POL-030 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `site footer link set` - **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 crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA, CCPA, Plivo, AT&T, Bird - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-030/ ### Why this rule exists CTIA asks for the policy to be conspicuously displayed and CCPA for a conspicuous link on the homepage, and a footer link satisfies both wherever a consumer happens to land — which for a messaging programme is usually a deep link, not the home page. A policy reachable only from the home page is unreachable from the page the messages point at. ### How to fix it Put both links in the site-wide footer template rather than on individual pages. Done when an interior page — a product, a post, a landing page — shows both links without navigating anywhere. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `805` | yes | ### Notes CTIA MPBP §5.2.1 requires conspicuous display; the specific "every page footer" formulation comes from a secondary source. The requirement that the policy be reachable at all is WEB-045, which fails a site with no link anywhere. --- ## POL-041 — Offline and keyword opt-in copy must carry the route to the policy > Verbal, IVR, keyword and email opt-in copy must state where the privacy policy can be found, or carry the disclosures inline. - **Rule ID:** POL-041 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `verbal script, IVR prompt, keyword CTA or opt-in email body` - **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:** AI judgement over the submitted form - **Fix type:** Produce a document that does not exist yet - **Required by:** Bandwidth, AWS - **Applies:** Applies when consent was collected by live verbal, IVR, text-to-join keyword and email. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-041/ ### Why this rule exists None of these surfaces has a link: a caller cannot click, and a keyword instruction on a poster is read rather than tapped. So the route has to be spoken or printed — a typeable address — or the disclosures have to be said out loud, and a script that mentions neither collects consent from someone who was never told where the terms are. ### How to fix it Add one sentence to the script or the opt-in copy naming where the terms and privacy policy live, spoken as a typeable address. Done when someone who only heard or read the opt-in knows where to find the policy. ### Common mistakes - Naming the policy in the confirmation text is too late — the consumer has already consented. It has to be in the copy that asks. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `7107` | yes | ### Notes Absorbs POL-042, which states the same requirement for keyword and email opt-in. A spoken or printed reference does not substitute for a compliant page: the policy it points at still has to satisfy the rest of this layer. --- ## POL-043 — Print, QR and point-of-sale calls to action need a typeable policy URL > A printed, QR or point-of-sale call to action must show a spelled-out, typeable URL for the terms and the privacy policy. - **Rule ID:** POL-043 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `printed CTA artifact or POS screen` - **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:** AI vision over a consent artifact (screenshot, scan, MMS media) - **Fix type:** Produce a document that does not exist yet - **Required by:** CTIA, Postscript, Aerialink - **Applies:** Applies when consent was collected by paper form, QR code and point of sale. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-043/ ### Why this rule exists A hyperlink does not exist on paper. The consumer standing at a counter or holding a flyer can only type what they can read, so a URL rendered as "click here", hidden behind a QR code, or shortened past recognition leaves them with no way to reach the terms at all — and the reviewer with nothing to follow either. ### How to fix it Print both addresses in full and legibly beside the call to action, short enough to type. Done when someone reading the printed piece can type the policy address without a phone. ### Example of a compliant value ```text Terms: acmecoffee.com/sms-terms · Privacy: acmecoffee.com/privacy ``` ### Common mistakes - Aerialink accepts the inline non-sharing statement printed instead of the privacy URL, but only that specific substitution — the terms address is still required. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `805` | yes | ### Notes VISION because it is a question about the artifact as printed: whether the address is legible and typeable cannot be answered from a text transcript of it. --- ## POL-044 — The QR landing page must link a compliant policy and message-programme terms > A QR opt-in landing page must link both a compliant privacy policy and compliant message-programme terms. - **Rule ID:** POL-044 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `QR landing page link set` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Aerialink, CTIA - **Applies:** Applies when consent was collected by QR code. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-044/ ### Why this rule exists The landing page is the entire disclosure surface for a QR opt-in — there is no checkout, no footer the consumer arrived through, and nothing behind them. If the two documents are not linked there, the consumer consents having seen neither, and the printed piece cannot carry them because it has no links. ### How to fix it Put both links next to the consent control on the landing page, not in a footer below the fold. Done when the page that collects the number also shows the way to both documents. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `852` | yes | ### Notes The linked documents still have to satisfy the rest of this layer — a link to a non-compliant policy discharges this rule and fails POL-050 onward. --- ## POL-045 — An offline opt-in does not relax the policy content requirements > The policy pages must satisfy the full content requirements even where opt-in never happens on the web. - **Rule ID:** POL-045 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body + terms body` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** AWS, Twilio, Bandwidth - **Applies:** Applies when consent was collected by live verbal, IVR, paper form, point of sale and imported list. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-045/ ### Why this rule exists Programmes that collect consent on a call, on paper or at a counter tend to treat the website as decoration, so the policy is whatever was published years ago — and the reviewer applies exactly the same content checks to it as to an e-commerce brand. Nothing about collecting consent offline reduces what the consumer is entitled to read. ### How to fix it Bring the published policy and SMS terms up to the same standard a web opt-in would need — the mobile non-sharing clause, the programme description, frequency, rates, STOP and HELP — before submitting the offline flow. Done when the documents would pass on their own, with the consent method left out of it. ### Notes An anti-exemption rule: it exists to be applied to registrations that assume the requirements are lighter, and it points at the rest of the layer rather than adding a requirement of its own. --- ## POL-050 — Privacy policy must state mobile opt-in data is not shared or sold > The privacy policy must explicitly state that mobile information and SMS consent are not shared or sold to third parties or affiliates for marketing. - **Rule ID:** POL-050 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, Twilio, T-Mobile, Bandwidth, AWS, Telnyx - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-050/ ### Why this rule exists This is the single most frequently cited cause of 10DLC rejection in the entire corpus. Carriers require it because SMS consent is non-transferable: the clause is the written promise that the number you collected will not become someone else's marketing list. Note it is a carrier and TCR requirement, not a CTIA one — CTIA never asks for this sentence, so guidance attributing it there is wrong and leads people to skip it. ### How to fix it Add an explicit mobile-data clause to the privacy policy. Paste the language below verbatim — reviewers look for this specific formulation, and paraphrases that soften "will not be shared" routinely fail. ### Example of a compliant value ```text No mobile information will be shared with third parties or affiliates for marketing or promotional purposes. All the above categories exclude text messaging originator opt-in data and consent; this information will not be shared with any third parties. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | | Twilio (gen2) | `30932` | yes | --- ## POL-053 — The clause must say NOT SHARED, not merely "not sold" > The non-sharing statement must separately state that data is not shared — "we do not sell your data" alone is insufficient. - **Rule ID:** POL-053 - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, T-Mobile, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-053/ ### Why this rule exists Sharing covers non-monetary transfer, including passing numbers to an affiliate or sister company at no charge. A policy promising only not to SELL leaves the most common abuse route wide open, which is exactly why reviewers require both words. ### How to fix it Amend the sentence to cover both verbs explicitly: "will not be sold, rented, or shared". ### Example of a compliant value ```text We do not sell, rent, or share your mobile phone number or SMS consent with third parties or affiliates. ``` --- ## POL-058 — A service-provider carve-back is required, not prohibited > The policy should permit disclosure to the vendors that actually deliver the messages, while prohibiting everything else. - **Rule ID:** POL-058 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-058/ ### Why this rule exists An absolute "we never disclose your number to anyone" is factually false — your platform, aggregator and the carriers all handle it — and a reviewer who spots the impossibility distrusts the rest of the policy. The correct shape is a narrow carve-back for message delivery. ### How to fix it Add a narrow carve-back naming the delivery chain, immediately after the non-sharing sentence. ### Example of a compliant value ```text We share your mobile number only with the service providers who deliver our messages (our messaging platform, aggregators, and wireless carriers), and for no other purpose. ``` --- ## POL-060 — No exception may permit sharing SMS opt-in data > The privacy policy must contain no exception, carve-out or "except where" clause that permits SMS opt-in data to be shared. - **Rule ID:** POL-060 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body (whole document)` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Bandwidth, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-060/ ### Why this rule exists Bandwidth's reviewer reads the prohibition as admitting no exception at all, so a policy that promises not to share and then lists the circumstances in which it will is read on the list rather than on the promise. The exceptions are almost always drafted for good reasons — a merger, a partner integration, an analytics vendor — and each one reopens exactly the door the clause was written to close. ### How to fix it Delete every exception attached to the messaging non-sharing clause, keeping only the narrow service-provider carve-back for the vendors that deliver the messages. Done when the clause has no "except", "unless" or "other than" hanging off it besides that one. ### Example of a compliant value ```text No mobile information will be shared with third parties or affiliates for marketing or promotional purposes. We disclose it only to the service providers who deliver our messages, and to no one else. ``` ### Common mistakes - A merger or acquisition clause counts as an exception here, even though it is standard in every other part of a privacy policy. Exclude messaging data from it explicitly rather than relying on it being obviously different. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `7109` | yes | ### Notes Genuine implementation divergence, recorded rather than resolved: Bandwidth 7109 as written admits no exception, while Infobip, Telnyx and Alive5 require the service-provider carve-back that POL-058 asks for. The product has to draft that carve-back narrowly enough to survive a 7109 reviewer, and a policy carrying both patterns is worth a human look. Absorbs POL-059, which names the common shape — an exception for partners, advertisers or lead buyers. --- ## POL-061 — The non-sharing prohibition must hold even with consumer consent > The prohibition must be unconditional — an "unless you consent" or "except where you have authorised" escape clause fails. - **Rule ID:** POL-061 - **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:** TCR, T-Mobile - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-061/ ### Why this rule exists A consent-conditional promise is not a promise: any dark-pattern checkbox re-opens the sharing the clause was meant to close. Carriers require the prohibition to be absolute because consumer "authorisation" to share is precisely the mechanism lead-generation operations use. ### How to fix it Delete any conditional qualifier from the non-sharing sentence so it reads as an unconditional commitment. ### Example of a compliant value ```text No mobile information will be shared with third parties or affiliates for marketing or promotional purposes. ``` --- ## POL-062 — A general permission to share data with other companies fails even where SMS is never named > A policy permitting personal data to be shared with other companies is rejected whether or not it mentions SMS. - **Rule ID:** POL-062 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body (whole document)` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-062/ ### Why this rule exists Naming SMS is what makes a non-sharing clause count in the brand's favour, but not naming it does not let a general sharing clause escape — the phone number is personal data, so a permission covering personal data covers it. Businesses reason the opposite way round, adding a careful SMS paragraph while leaving the general sharing section untouched because it says nothing about texting. ### How to fix it Narrow the general sharing section to named categories of service providers acting for you, or exclude messaging data from it in the section itself. Done when no clause in the document permits personal data to reach another company for that company's own use. ### Example of a compliant value ```text We share personal information only with service providers acting on our behalf. We do not share personal information with other companies for their own purposes, and text messaging opt-in data and consent are excluded from all sharing. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7103` | yes | ### Notes Fenced against its neighbours: POL-064 is about clauses permitting sharing FOR MARKETING, this one about a general permission with no purpose stated; POL-069 is the contradiction between such a clause and the SMS one, and POL-070 the same contradiction across two documents. --- ## POL-063 — A policy that says mobile opt-in data is shared is refused outright > A privacy policy stating affirmatively that mobile opt-in data or consent is shared with third parties or affiliates is rejected. - **Rule ID:** POL-063 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Sinch, AWS, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-063/ ### Why this rule exists This is the loudest version of the defect and it is treated as evidence about the business rather than as bad drafting — AWS maps it to a spam-association reason, not to a document problem. It is what a lead-generation operation's policy says when it is being honest, so a legitimate business with an over-broad template inherits that reading without having done anything. ### How to fix it Delete the sentence and replace it with the non-sharing clause, then check the business actually operates that way before publishing it. Done when nothing in the document says mobile data goes to anyone but the delivery vendors. ### Example of a compliant value ```text Mobile information, including your number and your consent to receive text messages, is never sold, rented, traded or shared with third parties or affiliates for their own marketing or promotional purposes. ``` ### Common mistakes - Do not fix this by deleting the sentence while the practice continues. The rule that follows is POL-108, and a policy that misdescribes what the business does is a worse position than an accurate one. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30932` | yes | --- ## POL-064 — No clause anywhere in the policy may permit sharing data for third-party marketing > The whole policy — not just the SMS section — must contain no clause permitting sale, rental, or sharing of personal data for third-party marketing. - **Rule ID:** POL-064 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body (whole document)` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, Twilio, T-Mobile, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-064/ ### Why this rule exists Ranked the #3 most-missed check in the catalog. Policies routinely carry the required non-sharing sentence in an SMS block while a general data-sharing clause three sections earlier says the opposite. Reviewers read the whole document and treat the permissive clause as controlling, so a tool that only looks for the good sentence passes a policy that will be rejected. ### How to fix it Find and remove or narrow every clause permitting data sharing for marketing. Where you must keep a sharing clause for other purposes, carve messaging data out of it explicitly with "excluding text messaging originator opt-in data and consent". ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30932` | yes | --- ## POL-065 — Boilerplate "trusted partners" language must be removed or narrowed > Generic policy-generator output such as "we may share with trusted partners" must be removed or narrowed to service providers. - **Rule ID:** POL-065 - **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:** TCR, Twilio, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-065/ ### Why this rule exists Ranked #4 most-missed. Free privacy-policy generators emit permissive sharing language by default, and the business pasting it in has no idea it contradicts their messaging programme. It is the most common source of the inverse trap because nobody wrote the sentence deliberately. ### How to fix it Replace vague partner language with a specific, closed list of processor categories, and state that messaging data is excluded from all of them. ### Example of a compliant value ```text We share personal information only with service providers who perform functions on our behalf (payment processing, order fulfilment, and message delivery). We do not share personal information with third parties for their own marketing purposes. ``` --- ## POL-066 — CCPA sold/shared disclosure must exclude phone numbers and SMS consent > Where the policy carries a CCPA "categories of personal information sold or shared" table, it must explicitly exclude phone numbers and SMS consent data. - **Rule ID:** POL-066 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy CCPA disclosure` - **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:** TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-066/ ### Why this rule exists Ranked #5 most-missed. A CCPA table listing "identifiers" as sold or shared directly contradicts the non-sharing promise, because a phone number is an identifier. Businesses complying carefully with California law thereby create a 10DLC rejection, and the fix is a carve-out rather than a removal. ### How to fix it Add an explicit exclusion beneath the CCPA table so the two disclosures do not contradict each other. ### Example of a compliant value ```text All the above categories exclude text messaging originator opt-in data and consent; this information will not be shared with any third parties. ``` --- ## POL-067 — A Do-Not-Sell link must not appear to reopen the SMS carve-out > Where the brand publishes a "Do Not Sell or Share My Personal Information" link, the policy must make clear that the SMS exclusion applies regardless. - **Rule ID:** POL-067 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body + Do-Not-Sell link` - **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:** CCPA, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-067/ ### Why this rule exists The link is an admission that the business sells or shares something, and a reviewer who finds it reads the messaging carve-out as one of the things a consumer must opt out of rather than as a promise already made. Businesses publishing it are complying carefully with California law, which is what makes this trap so unfair: the more diligent the CCPA work, the more likely the 10DLC rejection. ### How to fix it State next to the Do-Not-Sell disclosure that messaging opt-in data is never sold or shared and is therefore outside the request entirely. Done when a reader can see the exclusion holds without submitting anything. ### Example of a compliant value ```text We honour Do Not Sell or Share requests for the categories listed above. Text messaging opt-in data and consent are never sold or shared in any case, so no request is needed for them. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7103` | yes | ### Notes Conditional on the brand publishing the link, which no applicability dimension expresses; the criteria pass immediately where no such link exists. The catalog records the rule as a research judgement grounded in CCPA §7011 and Twilio 30932 rather than as published vendor wording. --- ## POL-068 — An override sentence should say the SMS clause prevails > The policy should state explicitly that the SMS non-sharing clause prevails over any other sharing language in the document. - **Rule ID:** POL-068 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy SMS section` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-068/ ### Why this rule exists Large policies are edited by several people over years, and no amount of care stops a future section from contradicting the messaging clause. An override sentence is what makes the document survive that — it decides the contradiction in advance, in the brand's favour, instead of leaving a reviewer to decide it against them. ### How to fix it Add one sentence to the messaging section saying it controls wherever the rest of the document says otherwise. Done when the policy answers the question "which clause wins?" without anyone having to interpret it. ### Example of a compliant value ```text Where anything else in this policy appears to permit sharing of personal information, this section controls for mobile numbers, text messaging opt-in data and consent. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7103` | yes | ### Notes Sourced from the research's own generation-validation table rather than from a published carrier rule: it is the mitigation for POL-064, POL-066 and POL-069 rather than an independent requirement, which is why it is graded HIGH and worded as an expectation. --- ## POL-069 — The general policy and the SMS clause must not contradict each other > Where the policy contains both a general sharing disclosure and an SMS-specific non-sharing clause, the two must be reconciled rather than left to contradict. - **Rule ID:** POL-069 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body (intra-document consistency)` - **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:** Telnyx - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-069/ ### Why this rule exists A document that promises two opposite things has told the reviewer nothing except that nobody read it end to end, and the reviewer resolves it against the brand by taking the permissive clause as controlling. It is the standard outcome of adding a compliance paragraph to an existing policy: the new text is correct, the old text is untouched, and both are live. ### How to fix it Edit the general section so it agrees with the SMS clause — narrow it, or exclude messaging data from it by name — rather than adding a third paragraph explaining the relationship. Done when a reader can find only one answer to "is my number shared?". ### Example of a compliant value ```text General section: "We share personal information with service providers acting on our behalf, and with no one else. Text messaging opt-in data and consent are excluded from all sharing and disclosure." ``` ### Notes The contradiction itself is the finding, which is why this is separate from POL-062 and POL-064: those fail the permissive clause on its own terms, and this one fails the document for holding both. Where only the permissive clause exists, report it there and pass here. --- ## POL-070 — No other document on the domain may contradict the SMS non-sharing clause > The terms of service, the cookie policy and any separate data-sharing page must not contradict the SMS non-sharing clause in the privacy policy. - **Rule ID:** POL-070 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `all policy-bearing pages on the brand domain` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-070/ ### Why this rule exists Reviewers read the whole domain, not the one URL on the form, so a data-sharing page written for advertisers overrides a perfect privacy policy. The other documents are usually owned by other people — marketing writes the cookie notice, legal writes the terms — and nobody is comparing them against a clause added for a messaging registration. ### How to fix it Search every policy-bearing page on the domain for sharing language and bring each into line with the messaging clause. Done when the terms, the cookie notice and any data-sharing page all say the same thing about mobile data. ### Common mistakes - The cookie policy is the one people forget, because it feels unrelated to SMS — and it is the one most likely to carry a permissive advertising-partner clause. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30932` | yes | ### Notes Needs a multi-page crawl. Against a single-page fetch the judge can compare only the documents it holds — the privacy policy and the terms — and must say which pages it could not read rather than clearing the domain. --- ## POL-071 — No document may reserve the right to sell or share consent itself > Neither the privacy policy nor the terms may reserve a right to sell, rent or share the consumer's consent. - **Rule ID:** POL-071 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy and terms body` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** T-Mobile, AT&T, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-071/ ### Why this rule exists Consent names a sender; it is not an asset that can change hands, and a document claiming otherwise describes the business model the whole framework exists to stop. Twilio treats this as making the business noncompliant rather than the document, so it is a much worse finding than an over-broad data-sharing clause — and it usually arrives through a template borrowed from an affiliate network. ### How to fix it Delete any clause reserving rights over the consent itself — to sell it, rent it, share it, or pass it to partners — from both documents. Done when the only thing either document says about consent is how to give it and how to withdraw it. ### Example of a compliant value ```text Your consent to receive text messages from Acme Coffee applies only to Acme Coffee. We do not sell, rent, share or transfer it to anyone. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30932` | yes | ### Notes Distinct from the data-sharing rules: those are about the number and what is known about the person, this one about the permission. A policy can be impeccable about data and still claim a right over the consent. --- ## POL-072 — Consent must not be described as transferable or assignable > The policy and the SMS terms must not describe messaging consent as transferable or assignable between businesses. - **Rule ID:** POL-072 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy and SMS terms body` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-072/ ### Why this rule exists CTIA states plainly that an opt-in should not be transferable or assignable, because the consumer agreed to hear from one named business and cannot be taken to have agreed to hear from its successors or affiliates. The wording usually arrives inside a boilerplate assignment clause covering the whole agreement, drafted with contracts in mind rather than consent. ### How to fix it Exclude consent from the assignment clause explicitly, and state in the SMS terms that the opt-in applies to this brand alone. Done when no clause lets the consent travel with a sale of the business. ### Example of a compliant value ```text We may assign this agreement, but your text messaging consent applies only to Acme Coffee and is not transferred or assigned with it. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30932` | yes | ### Notes The positive form of the same requirement is POL-191, which asks the SMS terms to state that the opt-in is programme-specific. This one fails a document that says the opposite; that one fails a document that says nothing. --- ## POL-073 — The policy should say the brand does not use rented or purchased lists > The policy or SMS terms should state affirmatively that the brand does not message rented, sold or shared opt-in lists. - **Rule ID:** POL-073 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy or SMS terms 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:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-073/ ### Why this rule exists CTIA asks senders not to use such lists, and the affirmative statement is what a reviewer can actually check — the absence of purchased numbers is not visible in any document. It also matters to the consumer question underneath: someone receiving a message wants to know how the sender got their number, and this is the sentence that answers it. ### How to fix it Add a sentence to the messaging section stating that every number was collected directly from the person it belongs to and that no rented, purchased or shared lists are used. Done when the document says where the numbers come from. ### Example of a compliant value ```text Every number in the Acme Coffee text programme was given to us directly by its owner. We do not rent, buy or use lists of numbers collected by anyone else. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7108` | yes | --- ## POL-074 — An explicit SMS opt-in carve-out belongs in the policy either way > The policy must carry an explicit sentence excluding SMS opt-in data and consent from any sharing, whether or not it discloses sharing elsewhere. - **Rule ID:** POL-074 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy carve-out sentence` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Infobip, Bird, Telnyx, Aerialink, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-074/ ### Why this rule exists Reviewers grep for this sentence, so a policy that is silent about sharing gets no credit for its silence — the absence of a bad clause is not the presence of the promise. Telnyx publishes the exact wording, which is a strong hint that what is being checked is the formulation rather than the sentiment, and paraphrases that soften it routinely fail. ### How to fix it Paste the published carve-out sentence immediately after whatever the policy says about sharing — or, in a policy that discloses none, at the end of the data-collection section. Done when the words "text messaging originator opt-in data and consent" appear in the document. ### Example of a compliant value ```text All the above categories exclude text messaging originator opt-in data and consent; this information will not be shared with any third parties. ``` ### Common mistakes - Placing the sentence in a section of its own, far from the sharing disclosure, weakens it: the point is that it visibly overrides the categories immediately above it. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `852` | yes | ### Notes Absorbs POL-075, which states the same requirement for a policy that discloses no sharing at all. The sentence to add is identical in both cases, which is why they are one obligation. --- ## POL-076 — The privacy policy must describe data handling, not sell the programme > The privacy policy must describe how data is handled rather than marketing the messaging programme. - **Rule ID:** POL-076 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body (document purpose)` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-076/ ### Why this rule exists A policy written as promotional copy — how great the offers are, why to sign up — answers none of the questions a policy exists to answer, so a reviewer looking for the data-handling terms finds none and rejects the document. It happens when the page is written by whoever writes the rest of the site, from a brief that said "explain the text programme". ### How to fix it Rewrite the page around what is collected, why, who it goes to and how to get it removed, and move the programme pitch to a marketing page. Done when the document reads as a description of data handling rather than an invitation to join. ### Example of a compliant value ```text When you join the Acme Coffee text programme we collect your mobile number, the date and source of your consent, and the delivery status of the messages we send. We use them only to send the messages you asked for. ``` --- ## POL-078 — A political brand is held to the same data-sharing ban > The third-party data-sharing prohibition applies to a political brand's policy exactly as it does to a commercial one. - **Rule ID:** POL-078 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Twilio - **Applies:** Applies when the use case is POLITICAL. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-078/ ### Why this rule exists Political organisations routinely share supporter lists with allied committees and vendors, and treat it as normal practice rather than as data sharing — Twilio names political campaigns that buy, sell or share consumer information specifically. The consumer protection is identical: someone who consented to hear from one committee did not consent to hear from every committee it works with. ### How to fix it Exclude mobile numbers and messaging consent from every list-exchange, coalition or vendor-sharing clause in the policy, and stop the practice for the numbers in this programme. Done when the policy says supporter mobile data is not shared with allied organisations. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30951` | no | ### Notes An anti-exemption rule. It exists because the sector reads the general prohibition as aimed at commercial marketing, so stating it for political brands separately is what makes it land. --- ## POL-079 — A charity policy must bar anyone but the charity from using subscriber data > A charity or donation programme's policy must state that no entity other than the charity itself may use the subscriber data. - **Rule ID:** POL-079 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** T-Mobile - **Applies:** Applies when the use case is CHARITY. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-079/ ### Why this rule exists T-Mobile requires this because donor lists are traded more freely than almost any other consumer data, and the donor who gave a number to one cause did not agree to hear from every cause its fundraising agency serves. Charities work through agencies and platforms as a matter of course, so the clause has to say the agency may deliver the messages and nothing else. ### How to fix it State in the policy that subscriber data is used only by the named charity, and that agencies and platforms handle it solely to deliver the charity's own messages. Done when no other organisation is permitted to use it for anything. ### Example of a compliant value ```text Numbers given to Riverside Shelter are used only by Riverside Shelter. Our messaging vendor sends the texts on our behalf and uses the numbers for nothing else; no other organisation receives them. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7103` | yes | --- ## POL-080 — A political donation programme must put its policy in front of donors > A political organisation soliciting donations by text must communicate its privacy policy to donors and enforce it. - **Rule ID:** POL-080 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body + donor-facing disclosure` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies when the use case is POLITICAL. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-080/ ### Why this rule exists CTIA's political guidelines ask for more than a published document: the donor giving money over a text message has to be shown the policy at the point of giving, because that is the moment their number, their name and their giving history are collected together. Political programmes are run at speed by volunteers and consultants, so the policy is usually a link in a footer nobody following a donation link ever sees. ### How to fix it Link the policy on the donation page itself and in the messages that ask for money, and hold the programme to it — including the third-party sharing ban that POL-078 applies. Done when a donor can reach the policy from the page they give on. ### Common mistakes - A link in the site footer is not communication to a donor arriving from a text on a donation URL. Put it on the donation page. ### Notes Conditional on donations being solicited as well as on the political use case. The use-case half is tagged; the donation half sits in the criteria, which pass immediately for a political programme that asks for nothing. --- ## POL-090 — The policy must say what messaging data is collected > The privacy policy must describe what data the messaging programme collects. - **Rule ID:** POL-090 - **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, Bandwidth, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-090/ ### Why this rule exists A consumer handing over a number is entitled to know that the consent timestamp, the source, the delivery status and in many programmes the message content are kept alongside it — none of which is obvious from typing a phone number into a box. Twilio asks directly for "what customer data you collect", and a policy that names only "contact information" answers a different question. ### How to fix it Add a short list to the data-collection section naming the messaging fields specifically. Done when a reader can see that consent metadata is kept, not just the number. ### Example of a compliant value ```text For the Acme Coffee text programme we collect your mobile number, the date and time you consented, the page or call it happened on, and the delivery status of each message we send. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | --- ## 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. --- ## POL-092 — The policy must say what the messages are for > The privacy policy must describe the purpose of the texting, consistently with the registered use case. - **Rule ID:** POL-092 - **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:** AWS, TCR, Twilio, Klaviyo - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-092/ ### Why this rule exists The use case sets the consent standard the campaign is held to, so a policy describing promotions behind a transactional registration tells the reviewer the wrong standard was applied. From the consumer's side it is the difference between agreeing to delivery updates and agreeing to weekly marketing, which is the whole substance of what they consented to. ### How to fix it Name the message categories in the policy and check them against the registered use case before submitting. Done when the two describe the same programme. ### Example of a compliant value ```text We use your number to send Acme Coffee promotional offers and rewards balance updates — the programme you joined at checkout — and for nothing else. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | --- ## POL-093 — A non-marketing programme's policy must not describe promotional texting > Where the campaign is not registered for marketing, the policy must not describe promotional or marketing texting. - **Rule ID:** POL-093 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body vs campaign.usecase` - **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:** AWS - **Applies:** Applies when the use case is NOT MARKETING, MIXED and SWEEPSTAKE. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-093/ ### Why this rule exists The inverse of the use-case match, and the one with the different fix: here the policy is broader than the registration, so a reviewer reads it as a marketing programme registered as transactional to get an easier consent standard. It usually arrives through a policy written for the whole business being pointed at a single transactional campaign. ### How to fix it Either narrow the policy so its messaging section describes only the transactional programme, or register the marketing use case and collect promotional-grade consent. Done when the policy claims no more than the registration does. ### Example of a compliant value ```text Non-marketing policy text: "We text you about your open support ticket. We do not send promotional messages to numbers collected this way." ``` ### Notes The converse of POL-077, which forces the marketing use case when the policy mentions promotions. Same pair of documents, opposite direction, different fix — narrow the policy rather than widen the registration. --- ## POL-094 — The policy must describe how information is collected, used and shared > The privacy policy must describe how the sender collects, uses and shares consumer information. - **Rule ID:** POL-094 - **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:** CTIA, Bandwidth, Klaviyo - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-094/ ### Why this rule exists This is CTIA's actual privacy requirement, and it is far weaker than the carrier non-sharing overlay everyone argues about — which is why it gets skipped: businesses focused on the non-sharing sentence forget the document also has to describe ordinary handling. A policy that promises not to share and never says what it does with the data has answered only half the question. ### How to fix it Give the document the three ordinary sections — collection, use, disclosure — around whatever it already says about messaging. Done when a reader can follow the data from where it is collected to who ends up handling it. ### Example of a compliant value ```text We collect your number at checkout, use it to send the messages you asked for, and disclose it only to the messaging vendor that delivers them. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7102` | yes | --- ## POL-095 — The policy must say how to contact the sender > The privacy policy must describe how consumers can contact the sender about their information. - **Rule ID:** POL-095 - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Bandwidth, Sakari, MessageDesk - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-095/ ### Why this rule exists Every right the policy grants — access, deletion, opting out — depends on there being someone to ask, so a document with no contact route grants nothing it can deliver. The address is also what a reviewer uses to corroborate the brand, which is why a bare web form fails where an email address on the brand domain passes. ### How to fix it Add a privacy contact block with an email address on the brand domain and the business postal address. Done when a reader can write to a person without using a form. ### Example of a compliant value ```text Privacy questions: privacy@acmecoffee.com, or Acme Coffee Co, LLC, 1240 Mission St, Suite 400, San Francisco, CA 94103. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7102` | yes | --- ## POL-096 — The policy must state who the business is > The privacy policy must identify the business: legal name, any DBA, postal address, email address and phone number. - **Rule ID:** POL-096 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy identity block` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** GDPR, Twilio, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-096/ ### Why this rule exists The identity block is the mechanism by which a vetter binds a policy to a brand record — without it, the document could belong to anyone, and a reviewer comparing it against the registration has nothing to compare. It is also what a consumer needs in order to exercise any of the rights the rest of the document grants them: a policy that promises deletion and names nobody to ask is not a promise. ### How to fix it Add a "Who we are" block carrying the registered legal name, the trading name, the postal address, a privacy email and a phone number, and make those values the same as the brand record. Done when a reader can identify and contact the business without leaving the document. ### Example of a compliant value ```text Acme Coffee Co, LLC, trading as Acme Coffee · 1240 Mission St, Suite 400, San Francisco, CA 94103 · support@acmecoffee.com · 415-555-0134 ``` ### Common mistakes - A contact form link is not a contact route for this purpose — the address and at least one direct channel have to be in the text, because the reviewer is matching strings against the brand record. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `807` | yes | --- ## POL-097 — The policy must carry opt-out instructions of its own > The privacy policy must give opt-out instructions inside the policy itself. - **Rule ID:** POL-097 - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Twilio, Ringover, Sakari, MessageDesk - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-097/ ### Why this rule exists The policy is where someone looks when the last message has scrolled away and they want out, so pointing at the messages rather than restating the route leaves them where they started. It costs one sentence and it removes the most common reason a consumer complains to the carrier instead of to the brand. ### How to fix it Add the keyword and one other route to the messaging section of the policy. Done when a reader who has never received a message still knows how to stop them. ### Example of a compliant value ```text Reply STOP to any Acme Coffee message to unsubscribe, or email support@acmecoffee.com and we will remove you. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | ### Notes Naming one route as the only one fails POL-117 — list the keyword and say other reasonable requests are honoured too. --- ## POL-098 — The policy must disclose message frequency > The privacy policy must disclose how often the programme sends messages. - **Rule ID:** POL-098 - **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 - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-098/ ### Why this rule exists Twilio asks for the frequency in the privacy policy while CTIA locates it in the terms, so a business that put it in one document and not the other is complying with a real standard and failing a different one. The consumer interest is the same in both places: how often is the thing they just agreed to going to reach them. ### How to fix it Add the frequency claim to the messaging section of the policy, worded identically to the one in the SMS terms and at the opt-in. Done when all three say the same thing. ### Example of a compliant value ```text Message frequency varies. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | ### Notes A genuine provider divergence, resolved by requiring it in both documents: Twilio 30908 and 30909 demand it in the privacy policy, CTIA in the terms and conditions. POL-172 is the terms-side rule. --- ## POL-099 — The policy must carry the message-and-data-rates disclosure > The privacy policy must carry the "message and data rates may apply" disclosure. - **Rule ID:** POL-099 - **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 - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-099/ ### Why this rule exists The disclosure exists so nobody is billed by their carrier for something they did not know they were agreeing to, and it is required in the policy as well as the terms for the same reason frequency is: the two standards disagree about where it lives, so it has to be in both. It is one sentence and it is the single most mechanically-screened string in the framework. ### How to fix it Add the sentence to the messaging section of the policy. Done when the phrase appears in the policy as well as in the SMS terms. ### Example of a compliant value ```text Privacy policy, "Text messaging" section: "Acme Coffee Rewards is a recurring programme. Message and data rates may apply." ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30924` | yes | ### Notes The catalog exempts Free-To-End-User programmes, where the consumer is not billed. We hold no FTEU fact, so the rule fires universally; an FTEU programme should record the exemption rather than treating the finding as wrong. --- ## POL-101 — The registered brand name must appear in the privacy policy > The registered brand name or DBA must appear in the privacy policy the campaign links to. - **Rule ID:** POL-101 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body vs brand.displayName / brand.dba` - **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:** Fix the privacy policy or SMS terms - **Required by:** AWS, Sinch, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-101/ ### Why this rule exists A vetter matches the name on the registration against the name in the policy, and a mismatch is reported as a policy mismatch rather than as a naming question — so a business trading under a shorter name than it registered fails on two documents that are both correct. It is also what tells the consumer whose promise they are reading, which the campaign's samples cannot do for them. ### How to fix it Put the registered brand name or DBA in the policy text — the identity block is the natural place — and register whichever name the document uses as the brand DBA. Done when the name on the campaign and the name in the policy are the same string. ### Example of a compliant value ```text The policy names "Acme Coffee", which is the registered DBA of Acme Coffee Co, LLC. ``` ### Notes Absorbs POL-100 (the policy names the company the consumer is consenting to hear from) and BRD-142 (the same entity-naming requirement across the policy and terms). POL-225 makes the stricter comparison across all three documents; this rule is the one-document form, so a brand whose terms page is missing still gets a specific finding here. --- ## POL-104 — The policy must say how message content is handled > The privacy policy must state how message content is stored, for how long, who can read it, and whether it is used for analytics or AI. - **Rule ID:** POL-104 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-104/ ### Why this rule exists Two-way programmes accumulate conversations that people treat as private, and the number of platforms now feeding message content to analytics or model training makes silence on this a live consumer question rather than a formality. A business that has never thought about it usually finds the answer is in its vendor's settings rather than in its own practice. ### How to fix it Add two sentences to the messaging section covering storage, access and any secondary use. Check what your platform actually does before writing them. Done when the policy describes the real handling rather than the intended handling. ### Example of a compliant value ```text Replies to our texts are stored in our support system for 24 months and are read only by the Acme Coffee support team. We do not use message content for advertising or to train automated systems. ``` --- ## POL-105 — The policy must describe its security safeguards at a high level > The privacy policy must describe the safeguards protecting the information, at least at a high level. - **Rule ID:** POL-105 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, MessageDesk - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-105/ ### Why this rule exists CTIA asks senders to describe how information is protected, and the value to the consumer is a signal that somebody thought about it at all. The trap is the opposite of omission: a generated policy that invents a certification the business does not hold turns a missing sentence into a false statement, which is a much worse position. ### How to fix it Describe the measures you actually have in one or two sentences, and name no standard you have not been audited against. Done when everything the section claims is true of your systems today. ### Example of a compliant value ```text We encrypt data in transit and at rest, and limit access to the numbers in the text programme to the staff who operate it. ``` ### Common mistakes - Do not name a compliance standard to fill the section. POL-242 exists because invented certifications are the specific failure this section attracts. --- ## POL-106 — The policy must state retention and consumer rights > The privacy policy must state how long data is kept and how consumers can access or delete it. - **Rule ID:** POL-106 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Sakari, GDPR, FTC - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-106/ ### Why this rule exists Retention and deletion are what a consumer actually wants after they have unsubscribed — the number is out of the programme, and they want to know whether it is gone. Several statutes require the disclosure independently, and the COPPA amendments make a published retention policy mandatory wherever children's data is in scope. ### How to fix it State a period or a rule for messaging data, and give the route for access and deletion requests. Done when a reader knows how long you keep their number and how to ask you to delete it. ### Example of a compliant value ```text We keep opt-in records for four years after you unsubscribe, because we may need to show that consent existed. Email privacy@acmecoffee.com to see or delete what we hold. ``` ### Common mistakes - Consent records are usually the one thing that should outlive a deletion request, because they are the evidence that the messages were lawful. Say so, rather than promising a deletion you will not perform. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | --- ## POL-107 — The policy must be consistent with applicable privacy law > The privacy policy must be consistent with the privacy law that applies to the business. - **Rule ID:** POL-107 - **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:** Human check — only someone holding the document can settle it - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-107/ ### Why this rule exists CTIA requires it, and which law applies turns on where the customers are, what is collected and how large the business is — none of which a document check can establish. The consequence of getting it wrong is a regulator rather than a carrier, so it is the one requirement in this layer where passing the registration is not the point. ### How to fix it Have the policy reviewed by someone who knows which statutes apply to your business, before publishing rather than after a complaint. Done when a reviewer has confirmed the applicable regimes are covered. ### Check this yourself **Has someone who knows which privacy statutes apply to this business read the policy?** 1. Establish which regimes are in play: where the customers are, what is collected, and how large the business is. 2. Route the document to counsel or a qualified privacy adviser before publishing, not after a complaint. 3. Treat the CCPA, GDPR and COPPA sections this registry checks as a floor, not a legal opinion. *What wrong looks like:* The document passes every automated check and misses the regime the business is actually in. The consequence here is a regulator rather than a carrier, so approval of the registration is not the point. ### Notes Not machine-decidable and not something the registry should pretend to settle. The individual statutory elements this layer does check — the CCPA sections, the GDPR addendum, the COPPA sections — are a floor rather than a legal opinion, and the user has to route the document to counsel for the rest. --- ## POL-108 — The policy must describe what the business actually does > The practices described in the policy must match what the site and the programme actually do. - **Rule ID:** POL-108 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body vs observed site behaviour` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-108/ ### Why this rule exists A policy that misdescribes the business is worse than a thin one: it is a public statement that is not true, which is an FTC deception question as well as a carrier one. The machine-checkable half of it is easy — a policy that says "we do not use cookies" while an analytics tag loads on every page — and that half is usually a generated document nobody reconciled with the site. ### How to fix it Read the policy against what the site loads and what the programme does, and correct whichever is wrong. Done when every practice the document describes is one you can point at. ### Notes Only partly decidable: a crawl can catch a cookie claim contradicted by a tracker, and nothing we fetch can confirm a retention period or an access control. The generation-side twin is POL-250; full verification is POL-107, which is a human question. --- ## POL-109 — A cart-reminder programme must say how abandonment is detected > Where the programme sends shopping-cart reminders, the policy must state explicitly how cart abandonment is detected. - **Rule ID:** POL-109 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** T-Mobile, CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-109/ ### Why this rule exists T-Mobile asks for this in almost these words, because a cart reminder is triggered by watching what someone did rather than by anything they asked for — so the policy has to say that cookies, a plugin or an account session are doing the watching. A retailer who switched an abandoned-cart flow on inside a platform has usually never seen the mechanism, let alone described it. ### How to fix it Add a sentence naming the mechanism — website cookies, a store plugin, a logged-in session — and what triggers the message. Done when the policy explains how the business knows a cart was left. ### Example of a compliant value ```text If you add items to your basket on acmecoffee.com and leave without checking out, a cookie on your browser lets us link that basket to your number so we can text you a reminder. ``` ### Common mistakes - The T&C has to reflect the cart programme as well (POL-110), and the opt-in disclosure has to name it (WEB-068). Fixing only the policy leaves two of the three. ### Notes Conditional on cart-reminder traffic, which no applicability dimension expresses — there is no cart-reminder attribute. The criteria pass immediately when nothing indicates the programme sends them. Severity divergence: T-Mobile and TCR grade it BLOCKING, CTIA SCMH Sev-2 MEDIUM. Strictest kept. --- ## POL-110 — A cart-reminder programme must be reflected in the terms > Where the programme sends shopping-cart reminders, the SMS terms must describe them. - **Rule ID:** POL-110 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms 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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** T-Mobile, CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-110/ ### Why this rule exists T-Mobile requires the terms to reflect the cart programme, and the reason is the same one behind the privacy-policy rule: a message triggered by watching what somebody did is not what "promotional offers" prepared them for. A retailer switching the flow on inside a platform changes what the programme sends without touching any document. ### How to fix it Add cart reminders to the message types the terms describe, and say how the number is linked to the basket. Done when the terms name them alongside whatever else the programme sends. ### Example of a compliant value ```text Acme Coffee Rewards sends promotional offers, rewards updates, and reminders when you leave something in your basket. ``` ### Common mistakes - The privacy policy owes the detection mechanism (POL-109) and the opt-in disclosure owes the message type (WEB-068). Fixing the terms alone leaves two of the three. ### Notes Conditional on cart-reminder traffic being in scope, which no applicability dimension expresses. The check reads the campaign copy for the signal and passes where it finds none. --- ## POL-111 — An incentivised opt-in needs a financial-incentive notice that agrees with the SMS clause > Where joining the programme earns a discount or other reward, the policy must carry a CCPA Notice of Financial Incentive that does not contradict the messaging clause. - **Rule ID:** POL-111 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body + opt-in offer text` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-111/ ### Why this rule exists Offering ten per cent off for a phone number is a financial incentive under California law and needs its own notice, and the notice has to explain the value of the data — which is exactly the sentence that can undo a non-sharing promise if it is drafted carelessly. The offer is usually designed by marketing and the policy by someone else, so the two are rarely read together. ### How to fix it Add the notice — what the incentive is, what data it relates to, how to withdraw, and a good-faith estimate of value — and state that messaging opt-in data is still never shared. Done when the two sections agree. ### Common mistakes - The value estimate is the sentence that can contradict the non-sharing clause. Base it on the value of the customer relationship rather than on what the data would fetch if sold. ### Notes Conditional on the opt-in offering an incentive, which no applicability dimension expresses; the criteria pass immediately where none is offered. The terms-side twin is POL-234. --- ## POL-112 — Location-triggered messaging must be described in the policy > The privacy policy must describe how location data is collected and why, where messaging is triggered by location. - **Rule ID:** POL-112 - **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:** Klaviyo - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-112/ ### Why this rule exists A message that arrives because someone walked past a shop is the kind of thing consumers find startling, and the policy is the only place they can find out it was going to happen. Location tracking is usually switched on inside a marketing platform rather than built deliberately, so the practice exists long before anyone thinks to document it. ### How to fix it Describe the collection method, the messaging use and the opt-out in the messaging section. Done when someone who receives a location-triggered message can find out why in the policy. ### Example of a compliant value ```text If you enable location in the Acme Coffee app we use it to text you when you are near a store with an offer on. Turn location off in the app to stop those texts without leaving the programme. ``` ### Notes Conditional on the programme being location-triggered, which no applicability dimension expresses; the criteria pass immediately where nothing in the registration indicates location triggering. --- ## POL-113 — The policy needs a children's-data section > The privacy policy must carry a children's-data section with a parental-consent route and a deletion route. - **Rule ID:** POL-113 - **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:** FTC, CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-113/ ### Why this rule exists A messaging programme cannot tell how old the person holding the phone is, so the policy has to say what happens when a child ends up in it — and the FTC's amended rule raises the bar on what that section must contain. Ordinary businesses are in scope more often than they expect, because the question is whether children are reachable rather than whether they are the audience. ### How to fix it Add a children's section giving the age position, the parental route and the deletion commitment. Done when a parent reading it knows exactly who to contact and what will happen. ### Example of a compliant value ```text The Acme Coffee text programme is not directed at children under 13 and we do not knowingly collect their information. A parent can email privacy@acmecoffee.com to see what we hold about a child and we will delete it. ``` ### Notes The FTC amended rule took effect on 2025-06-23 with full compliance required from 2026-04-22, so this is live rather than forthcoming. --- ## POL-114 — A child-directed service owes the full COPPA notice > Where the service is directed at children, the policy must carry the COPPA online-notice elements, including the categories of third parties that receive children's data and the purpose. - **Rule ID:** POL-114 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy children's section` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** FTC - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-114/ ### Why this rule exists A general "we do not target children" section is not a COPPA notice, and a service that is child-directed needs the full one — including the third-party disclosure, which is precisely what the messaging non-sharing clause has to be reconciled with. The FTC enforces this directly, so it is the one place in this layer where the regulator rather than the carrier is the risk. ### How to fix it Publish the COPPA online notice: what is collected from children, how it is used, every category of third party that receives it and why, the parental-consent mechanism, and the parental review and deletion routes. Done when each element is present and specific. ### Common mistakes - The third-party categories element and the SMS non-sharing clause have to agree. If the notice lists recipients of children's data, exclude messaging opt-in data from that list explicitly, or the two contradict. ### Notes Conditional on the service being child-directed, which no applicability dimension expresses. The criteria pass immediately where nothing in the registration indicates a child-directed service, and record the condition rather than leaving the rule looking universal. --- ## POL-115 — Children's data needs a published retention policy > The privacy policy must publish a written data-retention policy for children's data, with the purpose, the justification and the deletion timeframe. - **Rule ID:** POL-115 - **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:** FTC - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-115/ ### Why this rule exists The 2025 COPPA amendments require the retention policy to be published rather than merely held, which is a change most businesses have not noticed. The substance matters as much as the publication: a retention rule with no deletion timeframe is a commitment to keep a child's data indefinitely, stated in public. ### How to fix it Add the retention rule to the children's section: what is kept, why, and for how long. Done when the section states a period rather than a condition. ### Example of a compliant value ```text Where we learn that a subscriber is under 13 we delete the number and its consent record within 30 days, keeping only the fact of the deletion. ``` ### Notes Conditional on children's data being in scope, which no applicability dimension expresses; the criteria pass immediately where it is not. --- ## POL-116 — A written internal do-not-call policy must exist > The business must maintain a written internal do-not-call policy and make it available on demand. - **Rule ID:** POL-116 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `internal do-not-call policy document` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** FCC - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-116/ ### Why this rule exists The FCC requires the written policy from anyone doing telemarketing-adjacent outreach, and "available on demand" means a consumer or a regulator can ask for it — so its absence surfaces at the worst possible moment. It is an internal document rather than a published one, which is why businesses that have every public policy in order still do not have this one. ### How to fix it Write the internal policy — who maintains the list, how a request is recorded, how long entries are kept, how staff are trained — and be able to send it to anyone who asks. Done when a copy exists and someone owns it. ### Check this yourself **Does a written internal do-not-call policy exist, and do you know who would produce it if a consumer or the FCC asked?** 1. Find the document. It is internal rather than published, which is why businesses with every public policy in order still do not have this one. 2. Confirm it covers who maintains the list, how a request is recorded, how long entries are kept, and how staff are trained. 3. Name the person who owns it. *What wrong looks like:* "Available on demand" means the absence surfaces at the worst possible moment — when a consumer or a regulator has already asked for it. ### Notes Nothing in the registration reveals whether this document exists. The user has to confirm they hold one, and to know who would produce it if a consumer or the FCC asked. Where it is published on the site, a crawl can find it; where it is not, only the business knows. --- ## POL-117 — No document may designate an exclusive way to revoke consent > No policy, terms or message copy may state that a single named method is the only way to opt out. - **Rule ID:** POL-117 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy + SMS terms body` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** FCC - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-117/ ### Why this rule exists The FCC settled in 2024 that a consumer may revoke consent by any reasonable means, so a document naming one exclusive route is asserting a restriction the rule removes — and the consumer who emails instead of texting STOP, and keeps receiving messages, has a complaint the brand cannot answer. The language is usually written to be helpful: "to unsubscribe, reply STOP" becomes "STOP is the only way to unsubscribe" in an effort to be clear. ### How to fix it Remove any wording that makes one route exclusive and say the opposite: name the easy route and confirm that other reasonable requests are honoured too. Done when no sentence in either document contains "only way", "must be submitted through", or an equivalent. ### Example of a compliant value ```text Reply STOP to any message to unsubscribe. You can also email support@acmecoffee.com or call 415-555-0134 — we honour any reasonable request to stop. ``` ### Common mistakes - The exclusivity often lives in a portal or account-settings sentence rather than in the SMS section: "opt-out requests must be submitted through your account" is the same defect wearing different clothes. --- ## POL-121 — The policy must say what it covers > The privacy policy must state its scope — which sites, apps and offline channels it applies to. - **Rule ID:** POL-121 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-121/ ### Why this rule exists A policy scoped to "this app" while the opt-in happens on the website is the wrong document for the programme being registered, and a reviewer reads the scope line before anything else. Businesses inherit the mismatch from whichever product the policy was first written for. ### How to fix it Open the policy with a scope sentence naming every surface it covers, including the messaging programme. Done when the document plainly covers the surface where consent is collected. ### Example of a compliant value ```text This policy covers acmecoffee.com, the Acme Coffee mobile app, our stores, and the Acme Coffee text messaging programme. ``` --- ## POL-122 — The policy must list the categories of personal information collected > The privacy policy must list the categories of personal information collected, using the statutory category names. - **Rule ID:** POL-122 - **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:** CCPA, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-122/ ### Why this rule exists California requires the statutory names rather than a plain-English list, and the same section answers Twilio's demand to know what customer data is collected — so it is one of the few CCPA elements that carries direct 10DLC weight. It is also the section that most often contradicts the messaging clause, because "identifiers" includes the phone number. ### How to fix it List the statutory categories that apply and give an example of each in plain words alongside. Done when a reader sees both the legal category and what it means for them. ### Example of a compliant value ```text Identifiers — including your name, email address and mobile phone number. ``` ### Common mistakes - This list feeds the sold-or-shared table two sections later. Whatever appears here must be excluded there for messaging data, or POL-066 fires on the contradiction. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | --- ## POL-123 — The policy must list where the information came from > The privacy policy must list the sources of the personal information it collects. - **Rule ID:** POL-123 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-123/ ### Why this rule exists The sources list is where a policy either confirms or quietly contradicts the claim that every number was given directly by its owner — a list naming data brokers or partners tells a reviewer the opposite of what the messaging section promises. That makes a nominally low-relevance CCPA element load-bearing for a messaging registration. ### How to fix it List the sources honestly and make sure none of them contradicts the messaging section. Done when the sources list and the opt-in description tell the same story. ### Example of a compliant value ```text We collect personal information directly from you — at checkout, in your account, and when you contact us. ``` --- ## POL-124 — The policy must state the purpose of each category > The privacy policy must state the business or commercial purpose for each category of information, in terms a consumer can understand. - **Rule ID:** POL-124 - **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:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-124/ ### Why this rule exists The statute asks for a meaningful understanding rather than a list, which is a deliberate rejection of the "to improve our services" formulation that says nothing. For a messaging programme it is also the section where the purpose of holding the number is either stated plainly or lost in a generic paragraph. ### How to fix it Give each category its own purpose, in the words a customer would use. Done when a reader can tell why you hold each thing you listed. ### Example of a compliant value ```text Identifiers — to fulfil your orders, to answer support requests, and to send the text messages you asked for. ``` --- ## POL-125 — The policy must list who the information is disclosed to > The privacy policy must list the categories of third parties personal information is disclosed, sold or shared to, and why. - **Rule ID:** POL-125 - **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:** CCPA, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-125/ ### Why this rule exists This is the section carrier reviewers grep hardest, because it is where a policy admits what actually happens to the data — the research calls it the section that trips Bandwidth 7103. A careful CCPA disclosure and a compliant messaging clause pull in opposite directions here, and reconciling them is the whole job. ### How to fix it List the recipient categories accurately and add the messaging exclusion immediately after the list. Done when the section is both a truthful CCPA disclosure and consistent with the non-sharing clause. ### Example of a compliant value ```text We disclose personal information to our payment processor, our fulfilment partner and our messaging vendor, each acting on our behalf. All of the above exclude text messaging originator opt-in data and consent. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7103` | yes | --- ## POL-126 — The policy must say whether data was sold or shared in the last 12 months > The privacy policy must state whether personal information was sold or shared in the preceding twelve months, or affirmatively that it was not. - **Rule ID:** POL-126 - **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:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-126/ ### Why this rule exists The statute wants a yes or a no, and the answer is read by carriers as a statement about the business model rather than as a compliance artefact. A business that says yes for its advertising data and never carves out the messaging data has contradicted its own non-sharing clause in the most explicit way available. ### How to fix it State the answer plainly and, where it is yes, exclude messaging opt-in data from it in the same paragraph. Done when the twelve-month statement cannot be read as covering the text programme. ### Example of a compliant value ```text In the last 12 months we have not sold or shared personal information. Text messaging opt-in data and consent are never sold or shared in any case. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7103` | yes | ### Notes Must not contradict the non-sharing clause; where it does, POL-066 reports the contradiction. --- ## POL-127 — The policy must state its position on minors under 16 > The privacy policy must state whether the business has actual knowledge that it sells or shares the personal information of consumers under 16. - **Rule ID:** POL-127 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-127/ ### Why this rule exists California treats under-16 data as requiring opt-in rather than opt-out, so the statement is the business declaring which regime it is in. For a messaging programme the answer should be trivially no, and saying so removes a question a reviewer would otherwise have to resolve from silence. ### How to fix it Add the sentence to the CCPA section. Done when the document answers the question rather than leaving it to inference. ### Example of a compliant value ```text We do not have actual knowledge that we sell or share the personal information of consumers under 16. ``` --- ## POL-128 — The policy must state its position on sensitive personal information > The privacy policy must state whether sensitive personal information is used beyond the permitted purposes. - **Rule ID:** POL-128 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-128/ ### Why this rule exists The statement decides whether the business owes a Limit-the-Use link, so getting it wrong adds an obligation or drops one. Messaging programmes rarely touch sensitive information at all, which makes the honest answer short — and its absence a gap a reviewer has to fill by guessing. ### How to fix it Add the sentence, and where the answer is no, say so plainly rather than omitting the section. Done when the document states the position either way. ### Example of a compliant value ```text We do not use or disclose sensitive personal information beyond the purposes permitted under California law. ``` --- ## POL-129 — The policy must name or categorise its processors > The privacy policy must name or categorise the third-party processors that handle personal information. - **Rule ID:** POL-129 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-129/ ### Why this rule exists The service-provider carve-back the messaging clause depends on is only meaningful if the reader can tell who the service providers are — otherwise "vendors acting on our behalf" is an open door with a friendly label. Naming the messaging platform and the carriers is also the sentence that makes the carve-back obviously narrow rather than obviously convenient. ### How to fix it List the processor categories, naming the messaging vendor explicitly. Done when the carve-back in the messaging clause points at a list a reader can actually see. ### Example of a compliant value ```text Our processors are: our messaging platform and the wireless carriers that deliver the texts, our hosting provider, our payment processor, and our analytics provider. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `7109` | yes | --- ## POL-130 — The policy must disclose cookies, pixels and tracking > The privacy policy must disclose the cookies, pixels, SDKs and tracking it uses, and how to opt out of them. - **Rule ID:** POL-130 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-130/ ### Why this rule exists For most brands this is ordinary privacy law with no messaging consequence — except where cart reminders are in scope, when the cookie section is what explains how the message was triggered at all. It is also the section most often contradicted by the site itself, which is what POL-108 catches. ### How to fix it Describe the tracking the site actually loads and give the route to turn it off. Done when the section matches what a browser sees on the home page. ### Example of a compliant value ```text We use cookies to keep your basket, to measure how the site is used, and — if you have joined the text programme — to tell when a basket was left unfinished. You can manage them from the cookie settings link in the footer. ``` --- ## POL-131 — The policy must describe how opt-out preference signals are handled > The privacy policy must describe how it honours browser opt-out preference signals such as Global Privacy Control. - **Rule ID:** POL-131 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-131/ ### Why this rule exists California requires the signal to be honoured, and the disclosure is how a consumer who has set it knows whether it reached anyone. It carries no direct 10DLC weight, and it sits beside the sections that do — so the cost of adding it is a sentence and the cost of leaving it out is a gap in a document reviewers read end to end. ### How to fix it Add a sentence stating that the signal is recognised and what it does. Done when a reader who has set GPC knows what your site does about it. ### Example of a compliant value ```text We recognise the Global Privacy Control signal and treat it as a request to stop sharing your personal information. ``` --- ## POL-133 — A brand handling EU or UK data needs a GDPR addendum > The privacy policy must carry a GDPR addendum naming the controller, the legal bases, transfers, withdrawal of consent and the right to complain. - **Rule ID:** POL-133 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** GDPR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-133/ ### Why this rule exists A US messaging programme picks up EU or UK subjects the moment it has customers who travel or move, and the addendum is what makes the same document work for them. The withdrawal-of-consent element is the one that overlaps with messaging directly: it has to describe the same route the SMS terms describe, or the two documents disagree about how to leave. ### How to fix it Add the addendum as its own section rather than weaving it through the document, and make its consent-withdrawal route the same one the SMS terms give. Done when each element is present and the two documents agree. ### Example of a compliant value ```text For visitors in the EU and UK: the controller is Acme Coffee Co, LLC. We rely on your consent to send marketing texts; you can withdraw it at any time by replying STOP or emailing privacy@acmecoffee.com, and you may complain to your local supervisory authority. ``` ### Notes Absorbs POL-132, which states the legal-bases element on its own — one element of the addendum rather than a separate obligation. Conditional on the brand processing EU or UK data, which no applicability dimension expresses; the criteria pass immediately where nothing indicates it. --- ## POL-134 — The policy must enumerate the CCPA consumer rights > The privacy policy must enumerate the CCPA and CPRA consumer rights. - **Rule ID:** POL-134 - **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:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-134/ ### Why this rule exists The rights section is what turns a policy from a description into something a consumer can act on, and California requires the specific list rather than a summary. For a messaging programme it also carries the deletion right, which is the one people exercise after they unsubscribe and find they are still on file. ### How to fix it List all six rights explicitly. Done when each appears by name rather than being implied by a general statement. ### Example of a compliant value ```text You have the right to know what we hold, to delete it, to correct it, to opt out of its sale or sharing, to limit our use of sensitive information, and not to be treated differently for exercising any of these. ``` --- ## POL-135 — The policy must say how to exercise those rights > The privacy policy must give instructions for exercising consumer rights, including submission methods, verification and authorised agents. - **Rule ID:** POL-135 - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-135/ ### Why this rule exists A list of rights with no route to exercise them is the commonest way a policy looks compliant and does nothing — the consumer knows what they are entitled to and not who to ask. The verification step in particular has to be described in advance, because a business that invents an identity check when a request arrives looks like it is refusing. ### How to fix it Give the submission routes, the verification step and the agent route in the rights section itself. Done when a reader can start a request from the policy without hunting. ### Example of a compliant value ```text To make a request, email privacy@acmecoffee.com or call 415-555-0134. We will ask for the email address or mobile number on your account to verify it is you. An authorised agent may act for you with your written permission. ``` --- ## POL-136 — A business that sells or shares must publish the Do-Not-Sell link > Where the business sells or shares personal information, the "Do Not Sell or Share My Personal Information" link must be published on the site. - **Rule ID:** POL-136 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `site-wide Do-Not-Sell link` - **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 crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-136/ ### Why this rule exists California requires the link wherever the business does either, and its absence is a compliance failure in its own right. It is worth pairing with the messaging carve-out deliberately rather than by accident: publishing the link invites a reviewer to ask whether the messaging data is inside the request, which is the question POL-067 exists to answer in advance. ### How to fix it Publish the link in the site footer and state next to it that messaging opt-in data is excluded from sale or sharing in any case. Done when the link is present and the exclusion is unambiguous. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7103` | yes | ### Notes Conditional on the business selling or sharing personal information, which no applicability dimension expresses; the criteria pass immediately where the policy discloses neither. Pair with POL-067 — publishing the link without the carve-out statement is the trap. --- ## POL-137 — Other state-law addenda are needed where thresholds are met > Where the business meets the applicability threshold of another US state privacy statute, the policy must carry that state's addendum. - **Rule ID:** POL-137 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy state addenda` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** External record we cannot query — reported as a warning to verify - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** State law - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-137/ ### Why this rule exists A dozen states now have their own thresholds based on resident counts and revenue, and crossing one is invisible from inside the business — nobody gets a letter. The addenda are close enough to each other that adding them is cheap, and the cost of missing one falls on a consumer whose rights simply do not appear in the document. ### How to fix it Count residents by state against each statute's threshold once a year, and add the addendum for any state you have crossed. Done when the document covers every regime the business is actually in. ### Check this yourself **Have you counted residents by state and revenue against each state privacy statute's threshold in the last year?** 1. Pull the numbers: consumers by state, and annual revenue. 2. Compare against the Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana and Delaware thresholds. 3. Add the addendum for any state you have crossed. They are close enough to each other that adding them is cheap. *What wrong looks like:* Crossing a threshold is invisible from inside the business — nobody gets a letter. The cost falls on a consumer whose rights simply do not appear in the document. ### Notes Deciding this needs a count of consumers by state and a revenue figure, neither of which the registration carries and neither of which we can look up. The user has to check their own numbers against the Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana and Delaware thresholds; the catalog records the 10DLC relevance as none, so this is a legal exposure rather than a registration risk. --- ## POL-138 — The policy should offer an accessible alternative format > The privacy policy must carry an accessibility statement or a route to an alternative format. - **Rule ID:** POL-138 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-138/ ### Why this rule exists A consumer who cannot read the page cannot exercise any right in it, and California expects a route for people with disabilities. It costs one line and it is the kind of omission that reads badly next to a document otherwise full of rights. ### How to fix it Add a line offering the policy in an alternative format on request, with a contact route. Done when the document says how to get it in another form. ### Example of a compliant value ```text Need this policy in another format? Email support@acmecoffee.com or call 415-555-0134 and we will provide one. ``` --- ## POL-139 — The policy should be printable > The privacy policy should be available in a form a consumer can print or save. - **Rule ID:** POL-139 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy page rendering` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-139/ ### Why this rule exists A policy that exists only as an expanding accordion, or that prints as a single blank page, cannot be kept by the person it governs — and California asks for a printable format for exactly that reason. It is a rendering accident rather than a decision, so nobody discovers it until somebody tries. ### How to fix it Render the full text in the page rather than behind toggles, and add a print stylesheet or a downloadable copy. Done when printing the page produces the whole document. ### Notes Only partly decidable from a text crawl: a fetch that returns the full body is good evidence the text is in the page, and it says nothing about how the page prints. The judge should report which of the two it could see. --- ## POL-140 — Both documents must say how changes are communicated > The privacy policy must carry a section describing how changes to it are communicated. - **Rule ID:** POL-140 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-140/ ### Why this rule exists A policy that can change silently is a promise with an expiry date nobody is told about, and the section is what lets a consumer know a change has happened without re-reading the document. It matters more for a messaging programme than for most, because a material change to the programme is supposed to be reflected in these documents and dated. ### How to fix it Add a "Changes to this policy" section to both the privacy policy and the terms, saying how notice is given and when a change takes effect. Done when both documents carry it. ### Example of a compliant value ```text We may update this policy. We will change the Last updated date above and, where the change is material, post a notice on acmecoffee.com for 30 days before it takes effect. ``` ### Notes Absorbs POL-218, the same clause required of the terms — one requirement across both documents rather than two. --- ## POL-141 — The published documents must show when they were last updated > The privacy policy and the terms must each display the date they were last updated. - **Rule ID:** POL-141 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy + terms date block` - **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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA, CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-141/ ### Why this rule exists The date is how a reviewer, and a consumer, tell a maintained document from an abandoned one — CTIA asks for up-to-date, accurate programme information and CCPA requires the date outright. It also settles an argument later: when a programme changes and somebody asks what the terms said at the time, an undated document cannot answer. ### How to fix it Add a "Last updated" line carrying a full date at the top or bottom of each document, and change it whenever you change the text. Done when both pages show a date a reader can compare against today. ### Example of a compliant value ```text Last updated: 1 July 2026 ``` ### Common mistakes - A date generated from the page build changes every deploy and tells a reader nothing about the text. Set it by hand when the wording changes. ### Notes Absorbs POL-142 (a distinct effective date where the two differ), POL-159 (dating the SMS terms) and POL-160 (dating the ToS) — one dating requirement across all three documents. Whether the date is recent enough for the programme it describes is POL-233. --- ## POL-150 — The SMS terms must exist as a document of their own > The SMS terms must be published as a distinct, directly accessible document rather than only as a clause inside the general website terms. - **Rule ID:** POL-150 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms document` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Bandwidth, TCR, Sinch, Plivo, Twilio, Klaviyo, Infobip - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-150/ ### Why this rule exists A consumer who wants to know what they signed up for should not have to read a commercial terms-of-sale document to find it, and a reviewer given a general ToS has to hunt for the messaging clauses and decide whether what they found is the programme. Both problems disappear with a page whose whole subject is the text programme, which is why most providers ask for one. ### How to fix it Publish a dedicated SMS terms page — /sms-terms is the conventional path — and register that URL on the campaign, keeping a cross-referencing section in the general ToS. Done when the terms URL opens a page whose subject is the messaging programme. ### Common mistakes - Registering the general ToS URL and relying on a reader scrolling to the SMS section satisfies POL-211 and fails this rule. The two are kept separate because providers genuinely differ, so the safe build is a dedicated page plus an anchored section. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `TFV 1504` | yes | | Twilio (gen1) | `30882` | yes | ### Notes Contested in the catalog: no primary source mandates a dedicated page over an anchored ToS section, and the canonical position taken here is to generate both. POL-211 is the relaxed form — an anchored section satisfies that and fails this. --- ## POL-151 — The SMS terms must be about the messaging programme > The SMS terms must cover the messaging programme specifically rather than restating general website terms. - **Rule ID:** POL-151 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms 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, TCR, Infobip, AWS, Sinch - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-151/ ### Why this rule exists A page titled "SMS Terms" that turns out to be the standard site terms with a heading changed tells a reviewer that nobody wrote terms for this programme — and the consumer still has no idea what they will receive. It happens when the terms page is produced to satisfy the registration field rather than to document anything. ### How to fix it Write the terms around this programme: what it sends, how often, who it is for, what it costs, how to stop and how to get help. Done when nothing in the document would be true of a different business. ### Example of a compliant value ```text Acme Coffee Rewards sends weekly promotional offers and rewards balance updates to customers who joined at checkout. Message frequency varies. Message and data rates may apply. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30882` | yes | --- ## POL-152 — The SMS terms must be findable rather than buried > The SMS terms must be near the top of the document or reachable by their own anchor, not buried inside terms about other services. - **Rule ID:** POL-152 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms section position and anchor` - **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; AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, T-Mobile, Twilio, Bandwidth, AWS, Telnyx - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-152/ ### Why this rule exists CTIA and T-Mobile both treat consent details buried in unrelated terms as a consent defect rather than a formatting one, because a consumer who cannot find the terms has not been told what they are agreeing to. The usual shape is a fifty-clause commercial ToS with the messaging paragraph at clause 34, which is compliant on a word count and useless to a reader. ### How to fix it Give the messaging section its own anchor and link that anchor from the opt-in, or publish the terms as their own page. Done when the registered link lands the reader on the messaging terms rather than at the top of a long document. ### Example of a compliant value ```text terms_and_conditions_url: https://acmecoffee.com/terms#sms — the link lands on the messaging section itself. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30909` | yes | ### Notes Absorbs POL-153, which states the same findability requirement as a prohibition on burying opt-in details in unrelated terms. Severity divergence in the catalog: CTIA, Telnyx and Bandwidth grade the buried-consent form BLOCKING; that stricter form lives in the consent-surface layer, and this is the document-side variant, kept at HIGH. --- ## POL-156 — Published policy must not contain unreplaced template tokens > The live privacy policy and terms must contain no {curly brace} or {{PLACEHOLDER}} tokens left from a template. - **Rule ID:** POL-156 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy body + terms 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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-156/ ### Why this rule exists An unreplaced token proves the document was generated and never finished, which invalidates the whole page in a reviewer's eyes — if the company name is still a placeholder, no promise in the document is attributable to anyone. It is trivially detectable and embarrassingly common. ### How to fix it Search the published pages for "{" and "[" and replace every remaining token with real values, then re-publish. ### Example of a compliant value ```text Replace "{{COMPANY_NAME}}" with "Acme Coffee Co, LLC" and "[EFFECTIVE DATE]" with a real date. ``` --- ## POL-157 — The documents must describe the programme as it runs today > The terms and the privacy policy must give up-to-date, accurate information about the programme's details and functionality. - **Rule ID:** POL-157 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy + SMS terms 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:** CTIA, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-157/ ### Why this rule exists CTIA asks for accuracy rather than mere presence, and a document describing a programme that has since changed is worse than a missing one — a consumer relying on a frequency cap that no longer holds has been misled by a compliance document. Programmes drift constantly: a new message category, a different keyword set, a platform migration, and the terms are rarely part of the change. ### How to fix it Read both documents against the campaign as registered and correct anything that has moved on — categories, frequency, keywords, contact routes. Done when every factual claim in either document is true of the programme today. ### Example of a compliant value ```text Terms updated alongside the campaign: "up to 6 messages per month" replaced by "message frequency varies" when the weekly send was added. ``` ### Notes Whether the documents carry a date is POL-141; whether the date is recent enough for the programme is POL-233. This rule is about the substance rather than the dating. --- ## POL-170 — Terms must contain a dedicated SMS/messaging section > The terms of service must contain a section covering the messaging programme, or a dedicated SMS terms page must exist. - **Rule ID:** POL-170 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms body` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-170/ ### Why this rule exists The terms are where the programme is described in full: what it sends, how often, what it costs, and how to leave. A general commercial ToS with no messaging section leaves a reviewer unable to confirm the programme exists as described anywhere the consumer can read it. ### How to fix it Add an "SMS / Text Messaging Terms" section covering programme description, frequency, rates, STOP and HELP keywords, carrier non-liability, and a support contact. A separate dedicated SMS terms page is equally acceptable and often clearer. --- ## POL-171 — The terms must describe the programme > The SMS terms must carry a description of the programme — what the messages are about. - **Rule ID:** POL-171 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms body` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, Telnyx, Sinch, AWS, TCR, Bandwidth, Aerialink - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-171/ ### Why this rule exists Every other element in the terms is a parameter of a programme the reader has to already understand, so without the description the frequency, the rates and the keywords are attached to nothing. It is the single element most consistently required across providers, and the easiest to leave out because the author knows what the programme is. ### How to fix it Open the terms with a sentence or two naming the programme and saying what it sends and to whom. Done when a stranger reading only the first paragraph knows what they would receive. ### Example of a compliant value ```text Acme Coffee Rewards is a text messaging programme for Acme Coffee customers. We send promotional offers, seasonal sale notifications and rewards balance updates. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30886` | yes | ### Notes The research's own validator uses a floor of roughly fifteen words for the description, which is a useful sanity check rather than a published threshold. --- ## POL-175 — The terms must carry opt-out information > The SMS terms must state how to stop the messages — "Reply STOP to cancel" or a clear equivalent. - **Rule ID:** POL-175 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms body` - **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:** Fix the privacy policy or SMS terms - **Required by:** CTIA, AWS, Bandwidth, Sinch, Telnyx, TCR, Infobip, T-Mobile - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-175/ ### Why this rule exists This is the one element every provider screens for mechanically, because it is the consumer's exit and the thing a complaint is measured against. Terms drafted as a legal document rather than as instructions often describe the right to withdraw consent without naming the keyword, which reads as compliant to the author and fails the string match. ### How to fix it Add the keyword sentence to the terms in plain words. Done when the document contains the word STOP as an instruction rather than a description of a right. ### Example of a compliant value ```text To stop receiving messages, reply STOP to any message from us. ``` ### Common mistakes - Naming STOP as the only route fails POL-117. Give the keyword and say other reasonable requests are honoured as well. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30908` | yes | ### Notes The catalog exempts single-message programmes and lets T-Mobile accept the opt-out in the advertisement instead of the terms for print CTAs. Neither exemption is expressible as a tag we hold, and both are narrower than the registrations this registry is aimed at, so the rule fires universally. --- ## POL-176 — SMS terms must state message frequency and that rates may apply > The SMS terms section must disclose message frequency and that message and data rates may apply. - **Rule ID:** POL-176 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms 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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-176/ ### Why this rule exists These are the same two disclosures required at the point of opt-in, repeated where a consumer can find them later. A reviewer checking consistency between the opt-in and the terms will treat their absence here as evidence the programme is not documented. ### How to fix it Add both statements to the SMS terms section, and make the frequency claim match what you tell people at the opt-in — a reviewer comparing the two will notice if one says "varies" and the other promises four a month. ### Example of a compliant value ```text Message frequency varies. Message and data rates may apply. ``` --- ## POL-177 — The terms must say one final message follows an opt-out > The SMS terms must state that a single confirmation message follows an opt-out and that nothing further is sent. - **Rule ID:** POL-177 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms opt-out section` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-177/ ### Why this rule exists CTIA expects exactly one confirmation after STOP, and a subscriber who receives it without warning reads it as the opt-out having failed — which is the most common trigger for a complaint filed immediately after someone has successfully unsubscribed. One sentence in the terms turns that message from evidence of a broken system into evidence of a working one. ### How to fix it Add the sentence next to the opt-out instruction. Done when the terms set the expectation that one confirmation arrives and nothing after it. ### Example of a compliant value ```text After you reply STOP we will send one confirmation message, and then no further messages. ``` --- ## POL-178 — The terms should say how to re-subscribe > The SMS terms should describe how someone can rejoin the programme after opting out. - **Rule ID:** POL-178 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms opt-out section` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-178/ ### Why this rule exists People opt out during a busy period and want back in later, and without a documented route the only options are to guess a keyword or to contact support — so the business loses a subscriber who wanted to return. It also prevents a worse outcome: a business re-adding a number without fresh consent because the customer asked verbally and nobody recorded it. ### How to fix it Name the re-subscription route beside the opt-out instruction — a keyword, the original sign-up page, or a support contact. Done when the terms answer "how do I come back?". ### Example of a compliant value ```text Changed your mind? Reply START to rejoin, or sign up again at acmecoffee.com/rewards. ``` ### Common mistakes - A re-subscription route is a fresh opt-in and has to collect fresh consent with the full disclosure. Do not describe it as "we will just turn you back on". --- ## POL-180 — SMS terms must state consent is not a condition of purchase > The SMS terms must contain the statement that consent is not a condition of any purchase. - **Rule ID:** POL-180 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms 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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** FCC, CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-180/ ### Why this rule exists The same TCPA element required at the opt-in is required in the terms, so the promise survives the consumer forgetting what the checkout page said. Reviewers check both places, and the terms are the easier of the two to forget. ### How to fix it Add the sentence to the SMS terms section, worded as an unconditional statement. Check it is actually true of your checkout before publishing it, because the claim is verified against the live form by a separate rule. ### Example of a compliant value ```text Consent to receive text messages is not a condition of any purchase. ``` --- ## POL-181 — The terms must describe every opt-in method actually used > The SMS terms must describe every way people join the programme, consistently with the registered message flow. - **Rule ID:** POL-181 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms body vs campaign.message_flow` - **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, CTIA, Vonage - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-181/ ### Why this rule exists Vonage asks for all of them rather than the primary one, because a subscriber who joined at a counter and reads terms describing only a web form cannot tell whether the document applies to them. Programmes accumulate entry points over time — a keyword added for an event, a tick box added at checkout — and the terms are written once. ### How to fix it List every entry point in the terms — the checkout box, the keyword, the paper form, the phone call — and keep the list the same as the message flow. Done when the two documents name the same set. ### Example of a compliant value ```text You can join Acme Coffee Rewards by ticking the box at checkout on acmecoffee.com, or by texting JOIN to 55512. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30909` | yes | ### Notes Three rules read the same fact from three sources and can disagree independently: POL-091 asks the privacy policy, this one asks the terms against the declared flow, and POL-232 asks the terms against the surfaces found by crawling the site. --- ## POL-182 — SMS terms must carry a carrier non-liability disclaimer > The SMS terms must state that wireless carriers are not liable for delayed or undelivered messages. - **Rule ID:** POL-182 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-182/ ### Why this rule exists Carriers require this disclaimer as a condition of carrying A2P traffic — it is the clause that stops them being sued when a message arrives late. Its absence is a standard, mechanically-checked omission in SMS terms review. ### How to fix it Add the standard carrier disclaimer to the SMS terms section, naming the carriers rather than only limiting your own liability. Done when the terms say delivery is not guaranteed and that the carriers are not answerable for it. ### Example of a compliant value ```text Delivery is not guaranteed. Neither Acme Coffee nor the wireless carriers are liable for delayed or undelivered messages. ``` --- ## POL-184 — SMS terms must list the supported opt-out and help keywords > The SMS terms must name the keywords the programme honours for opting out and getting help. - **Rule ID:** POL-184 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms 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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-184/ ### Why this rule exists The terms are where a consumer looks up how to leave when the last message they received has scrolled away. The keywords listed here must match the keywords the platform actually honours, which is the registration-side twin of a runtime obligation. ### How to fix it List the keywords in the SMS terms, and make the list identical to the keywords declared on the campaign — a mismatch between the two is itself a finding. ### Example of a compliant value ```text To stop receiving messages, reply STOP, QUIT, END, REVOKE, OPTOUT, CANCEL, or UNSUBSCRIBE. For help, reply HELP. ``` --- ## POL-185 — The terms should state a minimum age > The SMS terms should state the eligibility and minimum age for the programme, consistently with the privacy policy. - **Rule ID:** POL-185 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms eligibility clause` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-185/ ### Why this rule exists The age line is what makes the children's section of the privacy policy operative for the messaging programme rather than for the website in general, and it is the only place a subscriber is told whether they are eligible at all. Where the two documents give different ages the pair contradicts itself, which is the defect POL-231 catches. ### How to fix it State the minimum age in the terms and make it agree with the privacy policy's children's section. Done when both documents give the same number. ### Example of a compliant value ```text You must be 18 or older, or 13 or older with a parent's permission, to join Acme Coffee Rewards. ``` --- ## POL-186 — The terms should say the subscriber warrants the number is theirs > The SMS terms should state that the subscriber warrants the number is their own and will tell the brand if it changes or is deactivated. - **Rule ID:** POL-186 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, Klaviyo - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-186/ ### Why this rule exists Numbers are recycled constantly, so a consented number becomes a stranger's number without anybody doing anything wrong — and the stranger receives marketing they never asked for. The clause is what makes the carrier deactivation files the brand is expected to check into a shared responsibility rather than a one-sided cleanup. ### How to fix it Add the warranty and the notification duty to the terms, and pair it with checking deactivation data on your side. Done when the terms say the number must belong to the person who gave it. ### Example of a compliant value ```text By joining you confirm the mobile number you gave us is yours. Please tell us if it changes or you stop using it, so we do not text someone else. ``` --- ## POL-187 — The terms should state the right to change or end the programme > The SMS terms should state that the brand may change or terminate the programme, and how notice will be given. - **Rule ID:** POL-187 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Klaviyo - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-187/ ### Why this rule exists Programmes end, and a subscriber who simply stops hearing from one has no way to tell whether it closed or whether their opt-out was mishandled. The notice half is what matters: a right reserved with no notice route reads as the business being able to change the deal silently, which is the reading a reviewer takes. ### How to fix it State the right and the notice route together. Done when the terms say both that the programme may change and how you would tell people. ### Example of a compliant value ```text We may change or end the Acme Coffee Rewards text programme at any time. We will post any change on acmecoffee.com/sms-terms and text subscribers before it takes effect. ``` --- ## POL-188 — SMS terms and privacy policy must link to each other > The SMS terms must link to the privacy policy, and the privacy policy should link back to the SMS terms. - **Rule ID:** POL-188 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms body + privacy policy body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-188/ ### Why this rule exists A consumer reading either document should be able to reach the other, and reviewers follow those links to confirm the two belong to the same programme. Orphaned documents also tend to drift apart in content, which produces the contradictions the inverse-trap rules catch. ### How to fix it Add a link from the SMS terms to the privacy policy and a link back the other way, so a consumer landing on either document can reach the other and a reviewer can confirm the two belong to the same programme. ### Example of a compliant value ```text See our Privacy Policy at https://acmecoffee.com/privacy for how we handle your information. ``` --- ## POL-189 — The terms must distinguish transactional from promotional messages > Where the programme sends both transactional and promotional messages, the terms must distinguish them and describe the separate consent. - **Rule ID:** POL-189 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms 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 - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-189/ ### Why this rule exists The two categories carry different consent standards, and a subscriber who agreed to order updates has not agreed to weekly offers — bundling them is the defect Twilio codes at the campaign level. A document that lumps them together makes the bundling official, which is worse for the brand than the practice alone. ### How to fix it Describe the two categories separately in the terms and say that promotional messages need their own opt-in. Done when a reader can tell which consent covers which messages. ### Example of a compliant value ```text Order updates are sent to every customer who places an order. Promotional offers are sent only to customers who ticked the marketing box — you can receive one without the other. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30913` | yes | ### Notes Applies only where both categories are sent; the criteria pass immediately for a single-category programme, since there is nothing to distinguish. --- ## POL-190 — SMS terms must give a working support contact > The SMS terms must provide a support email or phone number a consumer can actually reach. - **Rule ID:** POL-190 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-190/ ### Why this rule exists CTIA requires help routes not to be dead ends: the contact in your terms must lead to a human. A support address on a domain the brand does not own, or one that bounces, converts a compliance document into a broken promise. ### How to fix it Include a monitored support email on the brand's own domain, or a phone number that is answered, in the SMS terms. ### Example of a compliant value ```text For help with our messaging programme, email support@acmecoffee.com or call 415-555-0134. ``` --- ## POL-191 — The terms must say the opt-in applies to this programme only > The SMS terms must state that the opt-in applies only to this brand's programme and is not transferable or assignable. - **Rule ID:** POL-191 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms 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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-191/ ### Why this rule exists CTIA states that an opt-in should not be transferable, and putting it in the terms is what turns the principle into something the subscriber has been told. Its absence is what a reviewer reads when they are deciding whether a brand understands that consent names a sender — the whole affiliate-marketing prohibition rests on the same idea. ### How to fix it Add the sentence to the terms, naming the brand rather than saying "us". Done when the document states that the consent covers this programme and travels nowhere. ### Example of a compliant value ```text Your consent covers the Acme Coffee Rewards programme only. We do not transfer or assign it to any other business, including any company that might acquire us. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30932` | yes | ### Notes The positive form of POL-072, which fails a document that describes consent as assignable. This one fails a document that says nothing. --- ## POL-192 — A sweepstakes campaign needs its sweepstakes terms in the T&C > A Sweepstakes campaign's terms must contain the sweepstakes terms, or a link to them. - **Rule ID:** POL-192 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms 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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Sinch - **Applies:** Applies when the use case is SWEEPSTAKE. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-192/ ### Why this rule exists Prize promotions are separately regulated — eligibility, odds, the no-purchase-necessary route, the sponsor — and a subscriber entering by text has been given none of it if the messaging terms do not carry or link the rules. It is also the fastest way for a reviewer to tell a real promotion from a device for harvesting numbers. ### How to fix it Publish the official rules and link them from the SMS terms, or reproduce the material terms there. Done when someone entering by text can reach the rules from the terms in one click. ### Example of a compliant value ```text Full sweepstakes rules, including eligibility and the free entry route, are at acmecoffee.com/sweepstakes-rules. ``` --- ## POL-193 — The programme described in the terms must match the registered use case > The programme description in the SMS terms must relate to the use case the campaign is registered under. - **Rule ID:** POL-193 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms body vs campaign.usecase` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** AWS, Twilio, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-193/ ### Why this rule exists The terms are the public description of the programme and the use case is the private one, so a disagreement means one of them is wrong about what will be sent — and the reviewer resolves it by refusing the campaign. It happens most often when a terms page written for the whole business is attached to a narrower campaign. ### How to fix it Make the terms describe the categories the campaign is registered for, or register the use case the terms describe. Done when the two describe one programme. ### Example of a compliant value ```text Use case MARKETING · terms describe promotional offers and rewards updates — the same programme. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30893` | yes | --- ## POL-194 — The terms must not say consumer data is shared > The SMS terms must not indicate that consumer data or opt-in information is shared with third parties. - **Rule ID:** POL-194 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms and ToS body` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-194/ ### Why this rule exists Twilio treats a sharing statement in either the policy or the terms as making the whole business noncompliant, so a careful privacy policy does not protect a terms page that says the opposite. The terms are usually drafted by whoever handles commercial contracts, who has no reason to know the messaging clause exists. ### How to fix it Remove any sharing language from the terms and mirror the privacy policy's non-sharing clause there instead. Done when both documents say the same thing about who gets the number. ### Example of a compliant value ```text We do not share your mobile number or your consent with anyone except the service providers who deliver our messages. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30932` | yes | ### Notes The same defect in the privacy policy is POL-062 and POL-063; POL-070 is the cross-document contradiction. This rule fails the terms on their own terms, whether or not the policy agrees. --- ## POL-195 — No affiliate-marketing or lead-generation language in the terms > The SMS terms must contain no affiliate-marketing or lead-generation language anywhere. - **Rule ID:** POL-195 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms and ToS body` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** AWS, Twilio, TCR, Bird - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-195/ ### Why this rule exists AWS and Twilio both mark this non-remediable: a rejection under it ends the campaign rather than starting a fix, because the language is read as a description of the business model rather than as a clause. Terms copied from a template that came from an affiliate network carry it without anyone reading it, which is a very expensive way to inherit somebody else's wording. ### How to fix it Delete every reference to affiliates, partners, referral commissions and lead sharing from the terms before submitting, and check the source of any template you used. Done when nothing in the document suggests the subscriber's details reach another business. ### Example of a compliant value ```text Replace "our partners may contact you with related offers" with "only Acme Coffee will text you, and only about the Acme Coffee programme you joined." ``` ### Common mistakes - The codes are non-remediable, so this must be fixed before submission rather than after a rejection. A campaign rejected under 30951 cannot be edited back into life. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30951` | no | | Bandwidth/DCA | `708` | no | --- ## POL-196 — Opt-out information must appear in all three places > Opt-out information must appear in the call to action, in the terms and conditions, and in the opt-in confirmation message. - **Rule ID:** POL-196 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `T&C body + call to action + opt-in confirmation` - **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:** AI judgement over the submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-196/ ### Why this rule exists CTIA asks for all three because they reach the subscriber at three different moments — before consenting, when checking later, and in the first message they receive — and the exit has to be visible at each. Satisfying one of them is the normal state of a programme that has never had this checked, and it is not a partial pass. ### How to fix it Put the STOP instruction in the opt-in disclosure, in the terms, and in the confirmation message. Done when all three carry it in the same words. ### Example of a compliant value ```text All three say: "Reply STOP to opt out." ``` ### Notes A three-surface conjunction. The confirmation-message half is also checked from the message side; this rule is the one that reports the set as incomplete rather than reporting one surface. --- ## POL-197 — The programme name must appear on the call to action and in the terms > The programme name or product description must appear both on the call to action and in the terms and conditions. - **Rule ID:** POL-197 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `T&C body + call-to-action text` - **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:** AI judgement over the crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-197/ ### Why this rule exists The name is what lets a subscriber recognise a message months later as one they agreed to, and it only works if the same name is used where they consented and where the programme is documented. Businesses use a marketing name on the sign-up and the legal entity in the terms, which reads as two programmes. ### How to fix it Use one programme name in the opt-in copy and in the terms, and register it as the brand DBA or display name. Done when both surfaces name the same programme. ### Example of a compliant value ```text Both the checkout box and the terms say "Acme Coffee Rewards". ``` --- ## POL-198 — STOP and HELP instructions must be legible — bold is not required > The STOP and HELP instructions must be legible in the rendered terms; bold typeface is no longer required. - **Rule ID:** POL-198 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms typography as rendered` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI vision over a consent artifact (screenshot, scan, MMS media) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-198/ ### Why this rule exists The bold requirement came from the legacy MMA guidelines and was withdrawn in CTIA SCMH v1.8, but it survives in circulated checklists — so brands are still being told to reformat documents and tools still flag compliant terms. What survives is the plain requirement underneath: a reader has to be able to find the instructions. ### How to fix it Leave the formatting alone if the instructions are readable. Where they are set in small print or the same weight as a wall of text, give them their own line rather than bolding them. Done when a reader can find the STOP instruction at a glance. ### Example of a compliant value ```text A short paragraph of its own: "To stop receiving messages, reply STOP to any message from us." ``` ### Notes Recorded so a legacy checklist does not reintroduce the withdrawn requirement. SCMH v1.8 Appendix B footnote 20 states that opt-out information no longer needs to appear in bold typeface — never report a lack of bold as a defect. --- ## POL-200 — The terms need an acceptance clause > The terms of service must include an acceptance clause saying that using the service constitutes agreement. - **Rule ID:** POL-200 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-200/ ### Why this rule exists Without it the document is a statement of intent rather than an agreement, and nothing in it binds anybody — which matters the first time a business needs to rely on a term. It is also the clause whose absence most obviously marks a page as a stub somebody generated to fill a field. ### How to fix it Open the document with the acceptance sentence. Done when the terms say what the reader is agreeing to and by doing what. ### Example of a compliant value ```text By using acmecoffee.com or placing an order with us, you agree to these terms. ``` ### Notes The acceptance clause must not be used as the SMS consent mechanism — agreeing to terms is not agreeing to receive text messages, and treating it as such is a consent-surface defect rather than a drafting one. --- ## POL-201 — The terms must name the contracting entity and its address > The terms of service must identify the legal entity the consumer is contracting with, and its address. - **Rule ID:** POL-201 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `ToS entity block vs brand.company_name` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, Twilio, Telnyx - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-201/ ### Why this rule exists The contracting party is who the subscriber has an agreement with, and a reviewer matches that name against the brand record — so terms that say "we" throughout leave the registration with no way to bind the document to the business. Trading names make this fail honestly: the site says Acme Coffee, the registration says Acme Coffee Co, LLC, and the terms say neither. ### How to fix it Name the registered legal entity and its address in the opening clause of the terms, alongside the trading name if you use one. Done when the entity in the terms is the entity on the brand record. ### Example of a compliant value ```text These terms are between you and Acme Coffee Co, LLC, 1240 Mission St, Suite 400, San Francisco, CA 94103. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `807` | yes | ### Notes POL-225 makes the stricter comparison — the same entity name across the policy, the terms and the brand record. This rule is the one-document form, so terms that name no entity at all get a specific finding rather than a mismatch. --- ## POL-202 — The terms should state a minimum age > The terms of service must include an eligibility clause stating who may use the service and any minimum age. - **Rule ID:** POL-202 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-202/ ### Why this rule exists The age line decides which privacy regime the business is in, so a document silent on it leaves the children's section of the policy floating free. It also has to agree with the SMS terms, and where the two differ the pair contradicts itself in a way a reviewer can spot instantly. ### How to fix it State the minimum age in the eligibility clause and make it the same number the privacy policy and the SMS terms use. Done when all three agree. ### Example of a compliant value ```text You must be at least 18 to use this site and to place an order. ``` ### Notes The conflict between this age and the privacy policy's children's section is POL-231. --- ## POL-203 — The terms should cover accounts and credentials > The terms of service must include a clause covering accounts, registration and credential security. - **Rule ID:** POL-203 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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:** TCR - **Applies:** Applies when the use case is NOT M2M. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-203/ ### Why this rule exists Where the service has logins, the account clause is what puts the duty to keep a password safe on the person who holds it — without it the business carries the whole risk of a compromised account. For a messaging programme it also matters that account settings are often where a subscriber manages their preferences. ### How to fix it Add the accounts clause where the service has user accounts. Done when the document says who is responsible for a login and what happens when it is misused. ### Example of a compliant value ```text You are responsible for keeping your Acme Coffee account password secure and for anything done using your account. Tell us at once if you think someone else has used it. ``` ### Notes Conditional on the service having user accounts, which no applicability dimension expresses; the excludeUseCases tag only keeps it away from machine-to-machine programmes, and the criteria carry the real condition. --- ## POL-204 — The services in the terms must match the campaign description > The services or products described in the terms must be consistent with what the campaign description says the business does. - **Rule ID:** POL-204 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `ToS services section vs campaign.description` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-204/ ### Why this rule exists The two documents describe the same business to two different audiences, and a reviewer reads them together — terms describing a software subscription behind a campaign describing a coffee shop is the shape of a registration assembled from someone else's material. It also happens innocently when a business pivots and the terms are the last thing updated. ### How to fix it Bring the services section into line with what the business actually sells, and check it against the campaign description before submitting. Done when both describe the same business. ### Example of a compliant value ```text Terms: "Acme Coffee sells roasted coffee, subscriptions and brewing equipment." Campaign description names the same business. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30886` | yes | --- ## POL-205 — A retail brand's terms should cover orders and payment > The terms of service must include a commerce section covering orders, pricing, payment, taxes, subscriptions and auto-renewal. - **Rule ID:** POL-205 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies when the vertical is RETAIL. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-205/ ### Why this rule exists For a retailer these clauses are the actual agreement — what a price means, when an order is accepted, what happens when a subscription renews — and their absence is what leaves a business arguing with a customer over a charge with nothing to point at. The auto-renewal element carries independent legal weight in several states. ### How to fix it Add the commerce section covering ordering, pricing, payment and any recurring charge. Done when a customer can find out what happens when their subscription renews. ### Example of a compliant value ```text Coffee subscriptions renew every four weeks at the price shown when you subscribed. We email you three days before each renewal, and you can cancel any time from your account. ``` --- ## POL-206 — A retail brand's terms should cover shipping and returns > The terms of service must include a section covering shipping, returns, refunds and cancellations, or links to those pages. - **Rule ID:** POL-206 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies when the vertical is RETAIL. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-206/ ### Why this rule exists These are the terms customers actually look for, and for a messaging programme they are frequently the subject of the messages — an order update points at a delivery promise that has to exist somewhere. A link to a dedicated page is fine; silence is what leaves the business with no stated policy at the moment it is being asked to honour one. ### How to fix it Cover the four, or link the pages that do. Done when a customer reading the terms can find the returns window. ### Example of a compliant value ```text Shipping, returns and refunds are covered at acmecoffee.com/shipping and acmecoffee.com/returns, which form part of these terms. ``` --- ## POL-207 — The terms should include an acceptable-use clause > The terms of service must include an acceptable-use or prohibited-conduct clause. - **Rule ID:** POL-207 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-207/ ### Why this rule exists The clause is what lets a business remove a user who is abusing the service, and without it every enforcement decision is unsupported. For a brand running a two-way messaging programme it also covers the inbound side, where abusive replies otherwise have no stated consequence. ### How to fix it Add the acceptable-use clause naming the prohibited conduct and the consequence. Done when the terms say what would get someone removed. ### Example of a compliant value ```text Do not use our site or our text programme to send unlawful, abusive or fraudulent content. We may suspend access for anyone who does. ``` --- ## POL-208 — The terms should cover user-generated content > The terms of service must include a user-content clause covering licence, takedown and a DMCA agent. - **Rule ID:** POL-208 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-208/ ### Why this rule exists Where customers post reviews, photos or replies the business needs permission to display them, and the licence clause is that permission — without it every republished review is unlicensed. The DMCA agent is what preserves the safe harbour when somebody complains about a post. ### How to fix it Add the user-content clause where the service accepts any user submissions, including reviews. Done when the terms say what you may do with what customers post and how to complain about a post. ### Example of a compliant value ```text When you post a review or photo you give Acme Coffee permission to display it. To report content, email legal@acmecoffee.com. ``` ### Notes Conditional on the service accepting user content, which no applicability dimension expresses; the criteria pass immediately where it does not. --- ## POL-209 — The terms should state intellectual-property ownership > The terms of service must include a clause stating who owns the site content and the marks. - **Rule ID:** POL-209 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-209/ ### Why this rule exists The clause is what the business relies on when its product photography or its name is copied, and its absence is one of the markers of a generated stub. It is also the section a reviewer scanning for template output notices first, because it is the one that names the brand most often. ### How to fix it State ownership in the brand's own name and say what use is permitted. Done when the clause names your business rather than a template's. ### Example of a compliant value ```text The Acme Coffee name, logo and all content on this site belong to Acme Coffee Co, LLC. You may not use them without our permission. ``` --- ## POL-210 — The terms should disclaim third-party links and services > The terms of service must include a third-party links and services disclaimer. - **Rule ID:** POL-210 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-210/ ### Why this rule exists A messaging programme sends links, and some of them lead off the brand's own site — to a delivery carrier, a booking platform, a payment page — so the disclaimer covers destinations the business does not control. Without it, the terms implicitly stand behind every page a message can reach. ### How to fix it Add the disclaimer and name the kinds of third-party service you link to. Done when the terms make clear which destinations you stand behind. ### Example of a compliant value ```text Our site and our messages link to services we do not control, such as delivery tracking. Their own terms and privacy policies apply there. ``` --- ## POL-212 — Email and other-channel marketing terms must be kept separate from SMS consent > Marketing terms for email and other channels must be kept separate from the SMS consent terms. - **Rule ID:** POL-212 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `ToS marketing-communications section` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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 - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-212/ ### Why this rule exists One control covering several channels is the bundled-consent defect Twilio codes at 30913, and the document is where the bundling is usually written down first — "by subscribing you agree to receive email and text messages" makes it official. Separating them in the terms is what lets a subscriber take one and not the other, which is the whole point. ### How to fix it Give the SMS programme its own section, with its own consent statement, rather than describing it inside a general marketing-communications clause. Done when a reader can see that agreeing to one channel does not sign them up for the other. ### Example of a compliant value ```text Email newsletter and text messaging are separate programmes with separate sign-ups. Joining one does not join you to the other. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30913` | yes | ### Notes Graded LOW because the document form of the defect is a drafting question; the BLOCKING form — a single control collecting consent for both — lives in the consent-surface layer, where the harm actually happens. --- ## POL-213 — The terms should allocate risk > The terms of service must include a disclaimer of warranties, a limitation of liability and an indemnity. - **Rule ID:** POL-213 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-213/ ### Why this rule exists These three clauses are the entire risk position of the agreement, and a business without them is exposed to consequences it never priced. For a messaging programme the limitation matters specifically: undelivered or delayed messages are outside anybody's control, and the carrier disclaimer the SMS terms carry needs a limitation clause behind it to mean anything. ### How to fix it Add all three, and make the limitation consistent with the carrier disclaimer in the SMS terms. Done when the document says what you do not promise and what you are not liable for. ### Example of a compliant value ```text The site is provided as is. To the extent the law allows, Acme Coffee is not liable for indirect or consequential loss, and you agree to indemnify us against claims arising from your misuse of the site. ``` --- ## POL-214 — Arbitration and class-waiver language needs a lawyer > Arbitration, class-action-waiver and governing-law language must be reviewed by counsel rather than generated. - **Rule ID:** POL-214 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `ToS arbitration and dispute-resolution clauses` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-214/ ### Why this rule exists These clauses are jurisdiction-sensitive, increasingly challenged, and drafted wrongly they are struck out — taking the protection with them and sometimes more of the document besides. A generated arbitration clause is the single highest-risk thing a document tool can emit, because it reads as authoritative and its defects are invisible until it is relied on. ### How to fix it Have counsel draft or review the dispute-resolution clauses for the states you operate in, before publishing. Done when a lawyer has signed off on the arbitration and class-waiver wording specifically. ### Check this yourself **Has a lawyer signed off on the arbitration and class-waiver wording specifically, for the states you operate in?** 1. Identify the dispute-resolution clauses in the terms: arbitration, class-action waiver, governing law. 2. Have counsel draft or review them before publishing — not the document in general, these clauses in particular. *What wrong looks like:* A generated arbitration clause reads as authoritative and its defects are invisible until it is relied on. Drafted wrongly it is struck out, taking the protection with it and sometimes more of the document besides. ### Notes Absorbs POL-245, which states the same escalation for generated clauses. Not something the registry should settle or the product should generate unreviewed: the user has to route these clauses to a lawyer, and a draft that contains them should say so at export. --- ## POL-215 — The terms should state governing law and venue > The terms of service must include a governing-law and venue clause. - **Rule ID:** POL-215 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-215/ ### Why this rule exists Without it a dispute starts with an argument about where the dispute happens, which is expensive before anything about the substance is discussed. It is also one of the clauses whose absence marks a document as generated rather than drafted, because generators frequently leave the jurisdiction as a placeholder. ### How to fix it Name the state whose law governs and the courts that hear disputes. Done when neither is a placeholder. ### Example of a compliant value ```text These terms are governed by the laws of the State of California, and disputes are heard in San Francisco County. ``` --- ## POL-216 — The terms should cover termination > The terms of service must include a termination and suspension clause. - **Rule ID:** POL-216 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-216/ ### Why this rule exists Both sides need a stated way out — the customer to close an account, the business to end a relationship — and without one every ending is improvised. For a messaging programme it pairs with the right to end the programme that the SMS terms carry. ### How to fix it Add the clause covering both directions and what survives. Done when the terms say how the relationship ends. ### Example of a compliant value ```text You can close your Acme Coffee account at any time. We may suspend or close an account that breaches these terms. Sections on liability and governing law survive. ``` --- ## POL-217 — The terms should carry the standard boilerplate > The terms of service must include the standard boilerplate: severability, assignment, entire agreement, waiver, force majeure and notices. - **Rule ID:** POL-217 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms of service body` - **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own. - **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:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-217/ ### Why this rule exists Each of these does one job that only shows up when something goes wrong — a struck-out clause taking the rest with it, a right lost because it was not enforced once — and their absence is the clearest signal that a document was assembled rather than drafted. The assignment clause needs care for a messaging programme: consent must be excluded from it, which is POL-072. ### How to fix it Add the boilerplate block, and exclude messaging consent from the assignment clause explicitly. Done when all six are present and the assignment clause names the carve-out. ### Example of a compliant value ```text If any part of these terms is unenforceable the rest continues to apply. We may assign these terms; your text messaging consent is not assigned with them. ``` --- ## POL-219 — The terms must carry a contact block > The terms of service must carry a contact block naming the entity, its address, an email address and a phone number. - **Rule ID:** POL-219 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `ToS contact block` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, Sinch, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-219/ ### Why this rule exists The contact block doubles as the customer-care route the messaging framework separately requires, so a terms page without one leaves both a contractual and a messaging obligation unmet. It is also the block a reviewer reads to corroborate the brand, which is why a bare contact-form link does not do the job. ### How to fix it Close the terms with a contact block carrying the entity, the postal address, a monitored email and a phone number, matching the brand record. Done when a reader can reach a person without using a form. ### Example of a compliant value ```text Questions? Acme Coffee Co, LLC, 1240 Mission St, Suite 400, San Francisco, CA 94103 · support@acmecoffee.com · 415-555-0134 ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `852` | yes | ### Notes Overlaps deliberately with POL-190, which asks the SMS terms for a support contact: a brand that publishes dedicated SMS terms satisfies both from one block, and a brand that does not still owes the contact here. --- ## POL-225 — Legal entity name must be identical across policy, terms and brand record > The legal entity named in the privacy policy, in the terms, and on the TCR brand record must be the same name. - **Rule ID:** POL-225 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy + terms + brand.company_name` - **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:** Fix the privacy policy or SMS terms - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-225/ ### Why this rule exists Reviewers use the entity name to confirm the policy actually belongs to the registering brand rather than being borrowed from a parent, a franchisor, or another business entirely. Three different names across three documents reads as exactly that, and it is a fast rejection because it needs no judgement. ### How to fix it Use the exact registered legal name in both documents. If a parent company owns the policy, add a line naming this brand as a covered entity rather than leaving the mismatch unexplained. ### Example of a compliant value ```text All three read "Acme Coffee Co, LLC". ``` --- ## POL-226 — The brand name must be identical across samples, SMS terms and the opt-in disclosure > The brand or DBA used in the message samples must match the brand name in the SMS terms and the name shown in the opt-in disclosure. - **Rule ID:** POL-226 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `campaign.sample[] + terms body + consent disclosure` - **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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, CTIA, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-226/ ### Why this rule exists A consumer encounters the brand name three times — when they opt in, in the messages, and in the terms they consult later — and reviewers check that all three describe one sender. Marketing teams routinely use a shortened trading name in messages and the legal name in the terms, which reads as two different businesses sharing a programme. ### How to fix it Choose one customer-facing name and use it identically in the samples, in the SMS terms, and in the opt-in disclosure. Register that name as the brand display name or DBA so the registration matches too. ### Example of a compliant value ```text All three use "Acme Coffee" (registered as the DBA of Acme Coffee Co, LLC). ``` --- ## POL-228 — The terms, the use case and the samples must promise the same messages > The message types described in the SMS terms, the registered use case and the sample messages must all agree. - **Rule ID:** POL-228 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms message types + campaign.usecase + samples` - **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-228/ ### Why this rule exists Three artifacts describe the same programme and a reviewer compares all three, so the weakest one sets the verdict — samples showing promotions under a transactional use case with terms describing order updates is three different answers to one question. Each is written at a different time by a different person, which is exactly why they drift. ### How to fix it Pick the true description of the programme and make all three match it, widening the use case if the samples need it. Done when the categories in the terms, the use case and the samples are the same set. ### Example of a compliant value ```text Use case MIXED · terms describe offers and order updates · samples show one of each. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30893` | yes | ### Notes POL-193 compares the terms against the use case alone. This rule adds the samples, which is the surface most likely to reveal a category nobody declared. --- ## POL-229 — The support contact in the terms must match the HELP reply > The support email or phone number in the SMS terms must be one the HELP auto-reply also gives. - **Rule ID:** POL-229 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms contact block vs campaign.help_message` - **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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-229/ ### Why this rule exists A subscriber who texts HELP and a subscriber who reads the terms should reach the same place, and when they do not, one of the two routes is usually a mailbox nobody watches. The mismatch appears when support changes address and only the auto-reply is updated, because that is the one somebody tests. ### How to fix it Use the same support address and number in the HELP reply and in the terms. Done when at least one contact route appears in both, and both are monitored. ### Example of a compliant value ```text HELP reply and SMS terms both give support@acmecoffee.com. ``` ### Notes Requires an overlap rather than an identical set: a HELP reply that gives an email and a phone number while the terms give only the email is consistent, and failing it would push brands to pad both documents. --- ## POL-230 — Keywords in the SMS terms must match the keywords declared on the campaign > The opt-out keywords listed in the published SMS terms must be the same set declared on the campaign registration. - **Rule ID:** POL-230 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `terms body + campaign.optout_keywords` - **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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-230/ ### Why this rule exists A consumer relies on the terms, a reviewer relies on the registration, and the platform honours whatever it was configured with. When those three disagree, someone texts a keyword that is published but not honoured — which is a Severity-0 style failure dressed up as a documentation inconsistency. ### How to fix it Make the published keyword list and the declared keyword list identical, and confirm your platform honours every keyword in it. ### Example of a compliant value ```text Both list: STOP, QUIT, END, REVOKE, OPTOUT, CANCEL, UNSUBSCRIBE. ``` --- ## POL-231 — The ages in the terms and the privacy policy must not conflict > The minimum age in the terms' eligibility clause must not conflict with the age threshold in the privacy policy's children's section. - **Rule ID:** POL-231 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `ToS eligibility age vs privacy policy minors section` - **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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-231/ ### Why this rule exists Terms admitting thirteen-year-olds next to a policy promising to collect nothing from anyone under eighteen is a document pair that cannot both be true, and a reviewer reading them together sees a business that has not read its own paperwork. The two are almost always written by different people from different templates, which is why the numbers diverge without anybody deciding anything. ### How to fix it Pick one age for the business and use it in the terms, the privacy policy and the SMS terms. Done when the same number appears in all three. ### Example of a compliant value ```text Terms: "You must be at least 18." Privacy policy: "We do not knowingly collect information from anyone under 18." ``` ### Notes The check compares only explicit numbers it can find in both documents. Where either is silent it reports PASS rather than inventing a conflict — the absence of the age itself is POL-202 and POL-113. --- ## POL-232 — Every opt-in surface on the site must appear in the terms > Every opt-in surface found by crawling the site must be represented in the list of opt-in methods in the SMS terms. - **Rule ID:** POL-232 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `crawled opt-in surfaces vs SMS terms opt-in list` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-232/ ### Why this rule exists This is the same question as POL-181 asked from the other side, and it catches the case the declared flow cannot: a sign-up form somebody built for a campaign months ago, still live, feeding the same programme. A subscriber who joined through it reads terms that do not describe how they got there. ### How to fix it Inventory every form on the site that collects a mobile number for messaging, then either list it in the terms or take it down. Done when the terms describe every live route into the programme. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30909` | yes | ### Notes Decided from the crawl rather than the declared flow, which is why it is separate from POL-181 — the two disagree independently, and this is the one that finds the surface nobody remembered. --- ## POL-233 — The document dates must not predate the last change to the programme > The last-updated dates on the privacy policy and the terms must be no older than the last material change to the messaging programme. - **Rule ID:** POL-233 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy + terms dates vs the last programme change` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-233/ ### Why this rule exists A programme that gained a message category last month, documented by terms dated two years ago, is telling subscribers about a programme that no longer exists — and CTIA asks for up-to-date information rather than merely dated information. The dates are the cheapest way for a reviewer to spot it, which makes a stale date an invitation to read the rest more carefully. ### How to fix it Update both documents whenever the programme changes materially — a new message category, a new opt-in surface, a changed frequency — and set the date by hand when you do. Done when both dates are at least as recent as the last change. ### Example of a compliant value ```text Programme gained cart reminders in June 2026; both documents now read "Last updated: 1 July 2026". ``` ### Notes Authored as a judgement rather than as a predicate on purpose. Comparing a published date against a change that happened "N days ago" needs a clock, and a rule whose verdict changes with the calendar cannot be pinned by a fixture — the corpus would drift silently. The judge is given the campaign fields, which carry how long ago the programme last changed where the caller knows it. Whether a date is present at all is POL-141. --- ## POL-234 — An opt-in incentive must be described in both documents > Where joining the programme earns a discount or reward, both the SMS terms and the privacy policy's financial-incentive notice must describe it. - **Rule ID:** POL-234 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `SMS terms + privacy policy incentive language vs the opt-in offer` - **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 - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CCPA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-234/ ### Why this rule exists The offer is the reason most people join, so it is part of the deal rather than a marketing detail — and California treats it as a financial incentive with its own disclosure. A discount described on the checkout box and nowhere else leaves the subscriber unable to check what they were promised. ### How to fix it Describe the incentive in the terms — what it is, what it requires, when it expires — and cover it in the policy's financial-incentive notice. Done when the offer on the opt-in is documented in both. ### Example of a compliant value ```text Join Acme Coffee Rewards by text and get 10% off your next order. The code arrives in your welcome message and is valid for 30 days. ``` ### Notes Conditional on the opt-in offering an incentive, which no applicability dimension expresses; the criteria pass immediately where none is offered. The policy-side twin is POL-111. --- ## POL-240 — Template policy and website content is a known reject cause > Policy and terms text recognisable as generator boilerplate must be flagged, because reviewers reject it as evidence the business is not real. - **Rule ID:** POL-240 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `privacy policy + terms body` - **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 submitted form - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** Plivo, Telnyx, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-240/ ### Why this rule exists Free generators produce documents that are word-for-word identical across thousands of sites, and reviewers have seen them all — so the document that took five minutes to produce is the one that costs a rejection. It is the most common surprise in this whole layer, because the business believes having a policy was the requirement. ### How to fix it Replace the generic sections with text about this business — the products it sells, the surfaces it collects numbers on, the vendors it actually uses. Done when nothing in the document would be true of an unrelated company. ### Example of a compliant value ```text Replace "We may collect information from you when you visit our website" with "We collect your mobile number when you tick the text box at checkout on acmecoffee.com." ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `7103` | yes | ### Notes The positive form is POL-241, which asks whether brand-specific facts are present. This one detects the generic text; that one detects its absence, and a document can fail both. --- ## POL-241 — A generated document must carry brand-specific facts > A generated policy or terms document must contain facts specific to this brand — real product names, the actual opt-in surfaces, the actual vendors. - **Rule ID:** POL-241 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `generated policy and terms 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:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-241/ ### Why this rule exists A document that could belong to anybody tells a reviewer that nobody described this business to whoever wrote it, and the reviewer's next question is whether the business exists. It is also the difference between a policy that is true and one that is merely plausible: the specifics are what make its promises checkable against the site. ### How to fix it Name the business, the site, the opt-in surfaces, the message categories and the delivery vendor in the document itself. Done when a reader could identify the business from the policy alone. ### Example of a compliant value ```text Acme Coffee Rewards collects your number at checkout on acmecoffee.com and sends it to our messaging vendor, who delivers the texts. Nobody else receives it. ``` ### Notes Absorbs OPS-377, which states the same warning from the operational side. POL-240 is the detection of generic text in an existing document; this is the requirement on one we produce. --- ## POL-242 — Never assert a fact about the business nobody has confirmed > A generated document must assert no fact about the business — retention periods, encryption, sub-processors, certifications, jurisdictions — that has not been sourced or confirmed by the user. - **Rule ID:** POL-242 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `generated policy factual assertions` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** FTC, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-242/ ### Why this rule exists Every invented fact in a privacy policy is a public representation the business will be held to, and the ones a generator reaches for are exactly the ones nobody checks: a thirty-day retention period, AES-256 at rest, a SOC 2 report that does not exist. The FTC treats a false privacy claim as a deceptive practice, so this is the one obligation in the layer where the consequence is an enforcement action rather than a rejection. ### How to fix it Confirm each factual claim with the person who would know — retention with whoever runs the database, encryption with whoever runs the infrastructure, certifications with whoever holds the audit report — and delete the ones nobody can confirm. Done when every specific in the document traces to somebody who said it. ### Check this yourself **Can you name a person who confirmed each specific claim in this document — retention periods, encryption, sub-processors, certifications?** 1. Read the document as a list of assertions about your own business. 2. For each specific, ask the person who would know: retention with whoever runs the database, encryption with whoever runs the infrastructure, certifications with whoever holds the audit report. 3. Delete every claim nobody can source. Invented SOC 2, ISO 27001 and HIPAA claims are the named ones. *What wrong looks like:* A thirty-day retention period and AES-256 at rest arrive in the draft because they are plausible. The FTC treats a false privacy claim as a deceptive practice, so the consequence is an enforcement action rather than a rejection. ### Notes Nothing in a registration reveals whether a claim was confirmed, which is why this cannot be settled here. The user has to read the generated document as a set of assertions about their own business and strike out everything they cannot personally source. Invented SOC 2, ISO 27001 and HIPAA claims are the specific ones the research names. --- ## POL-243 — Mark every unverified variable and block export until it is resolved > Every unverified variable in a generated draft must be visibly marked, and export must be blocked until each is resolved. - **Rule ID:** POL-243 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `draft policy placeholder tokens` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Produce a document that does not exist yet - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-243/ ### Why this rule exists The alternative to marking is guessing, and a guessed retention period ships as a fact — so the marker is what keeps POL-242 enforceable rather than aspirational. The published-document version of this failure is trivially detectable and embarrassingly common: a live policy with {{COMPANY_NAME}} still in it, which is what happens when a draft is exported past its own placeholders. ### How to fix it Leave every unconfirmed value as a visible token rather than a plausible default, and resolve each before publishing. Done when a search of the draft for "{" and "[" returns nothing. ### Check this yourself **Does a search of this draft for "{" and "[" return nothing?** 1. Search the draft for both characters before publishing. 2. Resolve each marked variable with a value somebody confirmed, rather than a plausible default. 3. Do not publish while any marker remains. *What wrong looks like:* A live policy with {{COMPANY_NAME}} still in it — trivially detectable, embarrassingly common, and what happens when a draft is exported past its own placeholders. ### Notes The publication-side twin is POL-156, which fails a live page carrying tokens; this is the gate before that page exists. We hold no draft, so the user owns it: do not publish a generated document until every marked variable has been replaced with a value somebody confirmed. --- ## POL-244 — Do not silently overwrite a policy the brand already publishes > Where the brand already publishes a policy, a generated replacement must be diffed against it and the removed clauses surfaced for review. - **Rule ID:** POL-244 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `existing published policy vs the generated draft` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-244/ ### Why this rule exists An existing policy usually contains commitments somebody made deliberately — a sector clause, a jurisdiction addendum, a promise made to a customer — and replacing it wholesale deletes them without anyone seeing what went. The business ends up less compliant than before, having run a compliance tool. ### How to fix it Diff the draft against the live page and read the removals before publishing, keeping anything that was there for a reason. Done when every clause the replacement drops has been looked at by a person. ### Check this yourself **Have you read what the replacement removes from the policy this brand already publishes?** 1. Diff the draft against the live page. 2. Read the removals, looking first for sector language and anything added after a complaint or a legal review. 3. Keep whatever was there for a reason. *What wrong looks like:* A wholesale replacement deletes a jurisdiction addendum and a promise made to a customer. The business ends up less compliant than before, having run a compliance tool. ### Notes We can fetch the live policy but we cannot know which of its clauses were deliberate. The user has to compare the two documents themselves and decide what to carry across — sector language and anything added after a complaint or a legal review are the clauses worth looking for first. --- ## POL-246 — Export must carry a visible not-legal-advice disclaimer > A generated policy or terms document must be exported with a visible disclaimer that it is not legal advice and should be reviewed by counsel. - **Rule ID:** POL-246 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `document export` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-246/ ### Why this rule exists A document that arrives formatted and complete reads as advice whether or not it was meant as such, and the businesses most likely to rely on it are the ones least able to absorb the consequences of it being wrong. Every vendor in this space carries the disclaimer, which is a fair indication of what happens without it. ### How to fix it Show the disclaimer where the document is exported, not buried in a terms page nobody opens. Done when the person pressing export has read that it is not legal advice. ### Check this yourself **Did the person exporting this document see, and read, that it is not legal advice?** 1. Show the disclaimer where the export happens, not buried in a terms page nobody opens. 2. Treat the output as a starting draft and route it for review — the dispute-resolution clauses first. *What wrong looks like:* A document that arrives formatted and complete reads as advice whether or not it was meant as such, and the businesses most likely to rely on it are the least able to absorb it being wrong. ### Notes A product obligation with no registration surface: nothing in a submission records what the export screen said. The user has to treat any generated document as a starting draft and have it reviewed, particularly the dispute-resolution clauses POL-214 flags. --- ## POL-247 — Do not claim a generated document makes the brand compliant > Neither the product nor its output may claim that a generated policy makes the brand compliant or approved. - **Rule ID:** POL-247 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `product export copy` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-247/ ### Why this rule exists Carriers and the DCAs make that determination, and nobody else can — so a claim of compliance is both untrue and the reason a business stops checking. It is a specific failure of tools like this one: the more confident the output looks, the less likely anyone is to read the rejection reasons when they arrive. ### How to fix it Describe what the document does — it covers the requirements the registry knows about — rather than what it achieves. Done when nothing in the output or the interface promises approval. ### Check this yourself **Does anything you say about this output promise compliance or approval, rather than describing what it covers?** 1. Read the interface copy and the document's own front matter for any claim of being compliant, approved, or carrier-ready. 2. Describe what it does — it covers the requirements the registry knows about — rather than what it achieves. 3. As a user: do not treat a clean run as an approval. *What wrong looks like:* The more confident the output looks, the less likely anyone is to read the rejection reasons when they arrive. Carriers and the DCAs make that determination and nobody else can. ### Notes Nothing in a registration records the claims made around it. The obligation is on whoever writes the product copy, and on the user not to treat a clean run here as an approval: the registry is a strict superset of what was researched, not a guarantee about any particular reviewer. --- ## POL-248 — Record who approved the document and when > The business should record who approved each published policy or terms document, and when. - **Rule ID:** POL-248 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `document approval record` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-248/ ### Why this rule exists An appeal or a complaint turns on who decided what and when they decided it, and a document with no approver is one nobody owns — which is exactly the state that lets a stale policy sit live for two years. The record costs a line and it is the difference between an audit trail and a reconstruction. ### How to fix it Keep a record of the approver, the date and the version alongside the published document. Done when you can say who signed off the text that is currently live. ### Check this yourself **Can you say who signed off the policy text that is live right now, and when?** 1. Record the approver, the date and the version alongside the published document. 2. Keep it where the submission-day capture lives — the two answer the same question about the same document. *What wrong looks like:* A document with no approver is one nobody owns, which is exactly the state that lets a stale policy sit live for two years. ### Notes Internal to the business and invisible to any registration. The user has to keep the record themselves — the same place the POL-028 capture lives is the natural home for it, since the two answer the same question about the same document. --- ## POL-249 — A regulated vertical needs a warning that sector rules sit on top > Where the brand is in a regulated vertical, the generated documents must be accompanied by a warning that sector rules apply on top of them. - **Rule ID:** POL-249 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `generated policy + product warning` - **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:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-249/ ### Why this rule exists A generated policy that satisfies every carrier requirement can still be badly wrong for a clinic, a lender, a school or an insurer, because HIPAA, GLBA and FERPA impose obligations no 10DLC checklist mentions. The danger is specific to generation: a document that looks finished stops the reader looking for what is missing. ### How to fix it Where the brand is in healthcare, financial services, insurance or education, say plainly that the sector's own rules are not covered here and route the document to someone who knows them. Done when the warning names the applicable regime rather than warning in general. ### Example of a compliant value ```text This policy covers the messaging requirements. It does not address HIPAA, which applies to Riverside Dental as a covered entity — have your privacy officer review it before publishing. ``` ### Notes Conditional on the vertical, which the registration carries as free text rather than as a controlled list, so the condition sits in the criteria rather than in a tag. The verticals named in the catalog are financial services, healthcare, education and insurance. --- ## POL-250 — A generated policy must not describe practices the site does not perform > A generated policy must not describe practices the brand does not actually perform. - **Rule ID:** POL-250 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `generated policy body vs the site's observed behaviour` - **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 crawled website or policy page - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-250/ ### Why this rule exists Generation makes this failure easy in a way that drafting does not: a template section about cookies goes into a document for a site that has none, or a "we do not use tracking" line goes into a document for a site loading three analytics tags. The result is a public statement that is false, which is an FTC deception question rather than a carrier one. ### How to fix it Check every practice claim against the live site before publishing, and delete the sections that describe things the business does not do. Done when each claim in the document can be pointed at on the site. ### Notes The machine-checkable half of POL-108, which asks the same question of a policy the brand already published. This one is the generation-time gate, so it is the one that can stop the false statement being made at all. --- ## POL-251 — Say that carriers, not CTIA, enforce the non-sharing language > The product should disclose that the SMS non-sharing language is a carrier and TCR requirement rather than a CTIA one. - **Rule ID:** POL-251 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `product export disclosure copy` - **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:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-251/ ### Why this rule exists Guidance across the industry attributes the mobile-data non-sharing clause to CTIA, and CTIA has never asked for it — so a business that goes to the source to check finds nothing and concludes the requirement is invented. Being explicit that the registry generates to the stricter carrier standard on purpose is what stops that conversation ending with the clause being removed. ### How to fix it State the attribution where the clause is generated: carriers and TCR require it, CTIA does not. Done when a user who checks the CTIA handbook and finds nothing still understands why the clause is there. ### Check this yourself **Does whoever decides whether to publish the non-sharing clause know that carriers and TCR require it, and CTIA does not?** 1. State the attribution where the clause is generated. 2. Done when someone who checks the CTIA handbook, finds nothing, and comes back still understands why the clause is there. *What wrong looks like:* Industry guidance attributes the clause to CTIA, the business goes to the source to check, finds nothing, concludes the requirement is invented — and deletes the sentence. ### Notes An honesty requirement about our own output, with no registration surface. POL-050 carries the same correction in its rationale; this rule is the obligation to repeat it to the user at the point they are deciding whether to publish the sentence. --- ## POL-252 — A sole proprietor still needs a published policy > Policy pages must be produced for a sole-proprietor brand on the same terms as for any other entity type. - **Rule ID:** POL-252 - **Layer:** Policy pages (`POLICY_PAGE`) - **Checks:** `brand.entityType vs the policy generation gate` - **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:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the privacy policy or SMS terms - **Required by:** TCR, Bandwidth - **Applies:** Applies when the brand is a sole proprietor. - **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-252/ ### Why this rule exists One vendor claims sole proprietors are exempt from a compliant privacy policy and another lists sole-proprietor campaigns among its own rejection categories, so acting on the exemption means betting the registration on a single unverified source. The people it would affect are the least equipped to absorb a rejection, which is why the safe reading is to generate the document anyway. ### How to fix it Publish a privacy policy and SMS terms for the sole-proprietor brand and register both URLs, exactly as for a company. Done when the sole-proprietor campaign carries the same two links a standard campaign would. ### Example of a compliant value ```text privacy_policy_url: https://janedoe.com/privacy · terms_and_conditions_url: https://janedoe.com/sms-terms ``` ### Notes The catalog records this as contested: Alive5 claims the exemption as a single unverified source, Bandwidth separately lists sole-proprietor campaigns as a rejection category. The exemption is treated as unproven rather than asserted either way.