{
  "id": "MSG-243",
  "slug": "msg-243",
  "title": "No relaying one-time passcodes on behalf of other service providers",
  "statement": "Campaign content must not promote persistent relaying of one-time passcodes for other service providers.",
  "rationale": "A verification code is the most trusted message a consumer receives, and its trust rests entirely on it coming from the service being logged into. A sender relaying codes for other companies breaks that: the recipient cannot tell whose login is being confirmed, and the sending brand cannot be held to the consent because it has no relationship with the recipient. It is also the exact shape traffic-pumping fraud takes, which is why it is refused as a pattern rather than assessed message by message.",
  "layer": "MESSAGE_CONTENT",
  "layerSlug": "message-content",
  "object": "campaign.description + campaign.sample[] + campaign.message_flow",
  "severity": "BLOCKING",
  "detectability": [
    "AI_FORM"
  ],
  "failureClass": "HARD_STOP",
  "authorities": [
    "Telnyx"
  ],
  "codes": [
    {
      "provider": "Telnyx",
      "code": "40322",
      "remediable": false
    }
  ],
  "applicabilityText": "Applies to every 10DLC registration.",
  "universal": true,
  "remediation": "Register each business that owns the login under its own brand and campaign so the codes go out under the name the consumer is signing into. Where you are the platform, that means registering on behalf of each customer rather than pooling them under yours. Done when every sample names a service the registered brand actually operates.",
  "notes": "Telnyx 40322 is recorded as \"Permanent — fix content\" in one source and as remediable in another; the strict reading is kept. Telnyx is the only source that publishes this in these words, so the rule is left universal rather than provider-tagged: it is the same consent-chain and sender-identity requirement the whole framework applies, and tagging it Telnyx-only would drop a real obligation for every other route. Twilio and Bandwidth reach the same outcome through the ISV-versus-end-business rules instead.",
  "phase": "approval",
  "automated": true,
  "url": "https://ekas.io/rules/10dlc/message-content/msg-243/",
  "markdown": "https://ekas.io/rules/10dlc/message-content/msg-243.md",
  "registry": "https://ekas.io/rules/10dlc/",
  "updated": "2026-07-25",
  "licence": "CC BY 4.0 — https://creativecommons.org/licenses/by/4.0/"
}