USA A2P SMS FAQs

basic questions about the A2P registration process

Erica Hoelper avatar
Written by Erica Hoelper
Updated over a week ago

A2P 10DLC and Toll-free Verification registrations are the result of a massive overhaul of existing messaging networks in the USA and Canada and the introduction of new messaging protocols.

Many CloudTalk customers might understandably have questions on why these requirements are being introduced, or why the process with CloudTalk needs to ask for so much information in order to activate SMS on your account numbers.

We have compiled this guide of FAQs surrounding the A2P framework and registration process

FAQS

What is A2P registrations?

A2P (application-to-person messaging) registration is a new mandatory protocol for any party that wants to send business messages/non-consumer messages to the USA, and in some cases Canada, from commercial platforms.

It revolves around submitting your basic legal business information, messaging use case, and process for obtaining your customers' permission to send them SMS to the USA operators.

The full process can be seen here for local (10DLC) and Toll-free number registrations.

Who needs to register?

ANY PARTY that wants to send SMS/MMS to USA from USA or CANADA numbers, or wants to send SMS to Canada from Canadian toll-free numbers.

Why is this happening now?

T-Mobile has an exhaustive FAQ section that explains why A2P or non-consumer messaging rules are coming into play now.

There are 2 types of routes for sending SMS: P2P and A2P

P2P (Peer-to-peer or person-to-person) routes are used for interpersonal traffic between two individual parties and are conversational in nature. P2P/SMPP routes are typically only used on standard mobile networks, and they are no longer allowed to be used to send commercial messages, even if they are only conversational in nature.

A2P (Application-to-person) routes and messages are defined as any kind of messaging sent from commercial platforms, including follow-ups, notifications, marketing messages, OTPs (one-time passwords), 2FA, etc

  1. A2P networks were built by USA networks in 2020-2021, with the intention of consolidating all commercial (non-consumer) SMS to this new better-equipped network instead of general consumer messaging networks.

    Even if you are only sending conversational messages to known contacts, USA Operators will still classify this as A2P or non-consumer messaging, since they are being sent from a VoIP Platform.

  2. Use of these networks comes with specific sender requirements designed to identify which party sending SMS and protect consumers from spam, unsolicited messaging, fraud, and potentially restricted content.

  3. All carriers should have fully switched all non-consumer traffic to A2P networks as early as possible, but many were not able to do this immediately. Now in 2023, operators are insisting that carriers and providers become compliant, and impose deadlines or a strict implementation plan when this needs to be done.

  4. These are not regulations from CloudTalk, but from USA operators and CTIA (Cellular Telecommunications Industry Association). Unfortunately, neither CloudTalk nor our SMS carriers are able to offer exceptions.

Why do I have to do this with CloudTalk? I didn’t need to do this with my last provider.

From 2020 to present, A2P regulations have evolved and gotten more strict. In the past, it was sufficient to send fewer details like simple business information and use cases.

However, since January 2023, additional details have been required, so CloudTalk may need to ask you for more details than your previous provider had to ask you for.

  • evidence or documentation of the opt-in process

  • if customers opt-in on your website, you need to include specific phrasing in your company’s privacy policy and terms and conditions

    • statement of non-sharing

    • disclosure of potential message and data rates

    • disclosure of message frequency

I only send a few messages a month. Why do I need to do this?

USA operators have created a framework for all non-consumer messages, and do not grant exemptions based on low volumes of messages.

Why do I need a documented opt-in if I only send conversational messages?

An Opt-in use case is mandatory in all use cases for non-consumer/commercial/A2P messages and all companies and their use cases (brands and campaigns) need to be registered with The Campaign Registry (TCR), the inter-carrier database of all message-sending parties.

  • Carriers bear a huge risk of fines or restrictions from USA operators if they send “unsolicited messages” from their networks so they have made opt-in workflow mandatory. However, your company’s opt-in can be something simple, like

    • adding a line to the contact section of your website stating something like “account holders may receive follow-up support SMS, but can opt-out at any time”

    • submitting a call script or standard onboarding email template where you ask your customers if they prefer to be contacted by SMS

    • CloudTalk’s team can help you document your opt-in process in the easiest way possible for your business use case.

Why can’t I send XYZ-related (Gambling/CBD/Tobacco/3rd Party Loans or Debt Collection) SMS in CloudTalk?

  • The USA operators have set specific parameters against industries or use cases that they deem to have

    • high spam and nuisance potential (ex. third-party lead generation)

    • fraud or abuse potential (ex. high-interest loans, third-party loans or debt collection, high-risk financial services, financial consulting, and cryptocurrencies)

    • industries that they deem operate in a legal gray area: (ex. Vape, CBD, online gambling sites)

    • industries that require age-gating: each subcarrier reserves the right to set their own extenuating rules about these industries as they ultimately will bear the fines and penalties for improper age-gating (ex. alcohol, tobacco, firearms)

CloudTalk has written a guide of the specific use cases that USA operators or our carriers do not allow. Providers like ours take a hard line against these use cases since it can cause fines and penalties if the operators see a pattern of knowingly sending these types of messages.

Did this answer your question?