No relaying one-time passcodes on behalf of other service providers

The requirementstatement

Campaign content must not promote persistent relaying of one-time passcodes for other service providers.

Severityseverity: BlockingBLOCKINGBreaking this rule gets the submission rejected. There is no partial credit.
When it bitesphase: Gates approvalapprovalGet this wrong and the brand or campaign is refused at registration.
What is checkedobject: campaign.description + campaign.sample[] + campaign.message_flow
Where it liveslayer: Message contentMESSAGE_CONTENT
How Ekas settles itdetectability: AI · formAI_FORM; A semantic question about what you wrote: whether a description matches a use case, whether a name looks like a filed entity. Judged by a model against written criteria.
What the fix involvesfailureClass: Hard stopHARD_STOP; Not remediable. Resubmitting will not help, and anyone offering to fix it is selling you a rejection.
Who requires itauthorities: Telnyx
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

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.

How to fix itremediation

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.

Provider rejection codescodes

The code you get back when this rule is what failed, and whether that provider lets you resubmit.

Provider	Code	Resubmit
Telnyx	40322	No

Notesnotes

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.

Rules you will hit next

6 other rules read campaign.description + campaign.sample[] + campaign.message_flow. Fixing one field to satisfy a single rule is how a resubmission trades one rejection for another, so read these before you change anything.

MSG-137No unsolicited bulk messagingBlockingBLOCKING MSG-161SHAFT screening covers every campaign field, not a sample of themBlockingBLOCKING MSG-164No underage, non-consensual or illegal sexual themesBlockingBLOCKING MSG-170No content promoting, glorifying or inciting violenceBlockingBLOCKING MSG-182No explosives, fireworks or pyrotechnics contentBlockingBLOCKING MSG-183No weapons that are not legal in all fifty statesBlockingBLOCKING

All message content rules

MSG-243 is one of 122 message content rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.