This works	This doesn't
A live, functional website that matches the brand name you registered	A website that returns errors, isn't live yet, or is still under construction
Website URL clearly connected to your business name and registration	A URL that redirects to a different brand or unrelated business
Corporate email domain matching your brand (e.g., name@yourbrand.com)	Gmail, Yahoo, or other free email addresses for corporate brand registrations
Consistent branding across your website, registration, and sender profile	Brand name, website, and email domain all pointing to different entities

 

Part 4: Messaging Use Case & Campaign Details

Your use case description and campaign details are where reviewers assess whether your program is legitimate and properly scoped. A compliant use case is one where your messages are directly tied to your relationship with the user, triggered by something the user did or an event related to your product or service, and matching what users consented to receive.

Describing Your Use Case

What makes a compliant use case:

• Messages are directly tied to your relationship with the user
• They're triggered by a user action or an event related to your product or service
• The content matches what users consented to receive

What gets rejected:

• Sharing personal data with affiliates (lead generation or affiliate marketing doesn't pass)
• Collecting opt-in on behalf of a third party
• Opt-in must come directly from your own users

Compliant use case examples

Campaign Description

Your campaign description needs to answer three questions:

1. Who is sending the message?
2. Who is receiving it?
3. Why are they receiving it?

Your description must match the campaign type you selected and your sample messages. Keeping these consistent helps your registration get approved. If your brand name, website, or other details have changed since you registered your brand, make sure your campaign description reflects the current registered info to avoid rejection.

Don't include any Personal Identifiable Information (PII) in the campaign description field. Publicly available info like brand names and phone numbers is fine.

If you're a financial institution engaged in direct, first-party lending, you must mention "Direct Lending" in your description, even if you're only sending OTP/2FA messages.

What Triggers Messages

Describe the actions or events that cause your sender to send a message. Include:

• When the first message is sent after opt-in
• Whether messages go out on a consistent schedule
• Whether user actions (like a purchase) or external triggers (like a package delivery) initiate messages

Business Information

You'll need to provide the following business details:

• Legal business name: Enter the exact company name shown on your CP 575 EIN Confirmation Letter from the IRS. For non-US entities, use the name as registered with your local tax authority.
• Business registration number: Your Employer Identification Number (EIN) or Federal Tax Identification Number (FTIN)
• Company type: Select the type that most closely matches your business
• Business industry: Select the industry that most closely matches your business
• Brand contact phone number: A mobile phone number for the brand, in E.164 format (e.g., +14085980387)
• Business address: The legal address associated with your business registration number
• Stock exchange and stock symbol: Required for publicly traded companies only

Traffic Estimates

• Monthly organic website traffic: The average monthly website traffic associated with this use case
• Existing short code traffic (if applicable): Provide the short code number(s) and estimated monthly traffic volume
• Expected monthly RCS sender traffic volume: Your estimated monthly message volume for this RCS sender

Part 5: Opt-In & Consent Requirements

This is where most rejections happen. Carriers use this information to verify your opt-in process and make sure your sender is trustworthy. Take the time to get this right.

You'll need to provide a full description of every opt-in method your program uses, whether it uses online forms, verbal scripts, QR codes, paper forms, account settings, or any other method. For each, explain where the user starts, what steps they take, and what they see at each stage. Reviewers need to be able to follow your description and verify that required disclosures appear at the point of opt-in.

What Makes a Compliant Opt-In

The consent language at your opt-in point must name your brand explicitly and describe the specific types of messages the user is agreeing to receive. "Transactional messages" alone doesn't pass. It's too vague.

Message Frequency

Message frequency must be stated at the point of opt-in. Use a specific number or "Message frequency varies." The phrase "up to X messages per month" is not accepted.

Required Disclosures (Recurring Messages)

The following disclosures must appear on the same screen where users opt in. They can't be hidden behind a link, tooltip, or separate page.

Important: Both the Terms of Service and Privacy Policy links must appear at the point of opt-in, pointing to the public-facing URLs on your primary customer-facing domain (e.g., yourcompany.com, not an internal tool, subdomain used for another purpose, or a third-party hosted page).

For OTP/MFA/2FA programs: HELP and STOP disclosures aren't required for single-message programs, but the rates disclosure is a best practice, so it’s best to include it.

Opt-In Rules

These rules apply across all opt-in methods, regardless of how consent is collected.

• Channel-specific consent only:  If your consent language covers multiple channels (email, calls, texts), each needs its own separate opt-in. They can be on the same page but must use separate checkboxes or toggles.

• No pre-checked boxes: All checkboxes, toggles, and radio buttons must be unchecked or off by default. Users must actively choose to opt in.

• Pop-ups need an exit option: If your opt-in appears in a modal or pop-up, it must include a visible close button (an X or "No thanks") so users can decline without being forced to complete the opt-in.

• Separate use cases need separate opt-ins: If your sender covers both transactional and marketing messages, each needs its own opt-in with language that describes what that specific program sends. One checkbox for billing alerts, one for marketing. A single opt-in that enrolls users in both won't pass review.

• Consent must be voluntary: Users can't be required to opt in as a condition for completing unrelated actions like creating an account, making a purchase, or accessing services. Messaging consent must be separate from terms of service, privacy policies, or other agreements. Enrolling a customer into multiple campaigns based on a single opt-in will get your registration rejected. Consent also isn't transferable, can't be assigned to others, and can't be buried in general terms and conditions.

• All disclosures must be visible on the same screen: CTIA disclaimers can't be hidden, placed on a separate page, or revealed only when a user hovers over a tooltip or icon. Everything must appear clearly and explicitly on the same screen as the opt-in.

Providing Proof When Opt-In Isn't Publicly Visible

Reviewers need to be able to verify the opt-in method you're describing. If your opt-in happens in any of the following situations, you'll need to provide a publicly accessible link to a screenshot (for example, via Google Drive or OneDrive) directly in your opt-in description:

• Behind a login or gated page
• On a paper form
• Via verbal script (IVR or agent)
• Not yet published publicly
• Part of an in-app flow

For text (keyword) opt-in, you must also submit proof showing where users see the phone number and keyword opt-in instructions. You can provide any of the following along with the opt-in disclaimer:

• Screenshot of the webpage or app where the number is shown
• Copy of the sign-up form or landing page
• Email or message where the number was shared with users
• Screenshot of the ad where the number appears

Host a screenshot of the campaign collateral on a publicly accessible website (like OneDrive or Google Drive) and provide the URL in the opt-in description field.

Opt-Out Requirements

Your opt-out description should include the message a user receives when they opt out. It must confirm the user has been unsubscribed and won't receive further messages.

Cart Reminder Double Opt-In

If your RCS sender includes shopping cart reminders, double opt-in is required. This means that in addition to the standard opt-in described above, an additional confirmation message must be sent that explicitly tells users they're being enrolled in a program that includes shopping cart reminders.

Here's what compliant double opt-in messages look like:

"Reply YES to confirm your [Program Name] subscription (incl. Cart Reminders). Msg & data rates may apply. Msg freq varies. Reply HELP for help, STOP to cancel."

"Welcome to [Program Name] (incl. Cart Reminders). Msg & data rates may apply. Msg freq varies. Reply HELP for help, STOP to cancel."

Configure Advanced Opt-Out for RCS

To ensure your RCS sender is approved, you must have a functional opt-in/out flow. T-Mobile will also verify this prior to approval.

You can manage your START, STOP, and HELP  keywords using Twilio’s Advanced Opt-Out feature. Follow these steps to configure Advanced Opt Out for your RCS sender:

1. Create a Messaging Service in the Twilio Console.
2. Enable Advanced Opt-Out within the Messaging service settings.
3. Add your RCS Sender to the Messaging Service.
4. Define your replies for the mandatory keywords (HELP, STOP, and START).

For detailed instructions, refer to the Twilio Advanced Opt-Out Documentation.

OTP/MFA/2FA Programs

Single-message verification programs have lighter disclosure requirements, but a few specific rules apply:

• Alternative delivery method required: Carriers require that you also offer an alternative to text messages for verification codes (phone call, email, or push notification). That alternative option must be reflected in the opt-in experience itself.
• Rates disclosure is best practice: Include "Message and data rates may apply" even though it's not strictly required for single-message programs.
• HELP and STOP disclosures aren't mandatory for single-message programs per CTIA, but your system should still support these keywords.
• Opt-in confirmation is the only required sample message. It should include the brand name and describe what the message will contain. Example: "Your verification code for [Brand] will be sent to your number ending in XXXX."

Part 6: Sample Messages

Provide sample messages so reviewers can see exactly what your customers will receive. Use your real brand name consistently throughout. Don't use placeholder company names, and don't include real consumer names or phone numbers. Use brackets for any dynamic content: [Name], [1234], [Date].

Recurring messages

Submit at least 3 sample messages. If your sender covers multiple use cases, include at least one sample per use case. If your program includes cart reminders, include a cart reminder sample.

For recurring message programs, opt-out instructions (STOP) must appear at regular intervals (e.g. “at least once every 3 days” or “at least once every fifth message”) within the normal flow of messages, not just in the opt-in confirmation.

Single messages (OTP/MFA/2FA)

Submit at least 1 sample message showing the verification code format.

Opt-In Confirmation (Welcome Message)

Every sender needs an opt-in confirmation message that goes out immediately when a user subscribes. Include this as one of your samples.

Example (recurring): "Welcome to [Program Name]. Msg & data rates may apply. Msg freq varies. Reply HELP for help, STOP to cancel."

Example (OTP/MFA/2FA): "Your verification code for [Brand] will be sent to your number ending in XXXX."

HELP Response

The response your sender sends when a user texts HELP.

Example: "[Program Name] help: Call us at 1-800-XXX-XXXX or email support@brand.com. Msg & data rates may apply. Reply STOP to cancel."

STOP Response

The response your sender sends when a user texts STOP.

Example: "You've been unsubscribed from [Program Name]. No further messages will be sent. Reply START to resubscribe."