ISV A2P 10DLC Onboarding Overview

1. A2P 10DLC overview

This onboarding overview is for ISVs who want to register their customers for A2P 10DLC messaging capabilities to phone numbers in the U.S.

This registration can be done via the Twilio Console (Messaging > Regulatory Compliance > Onboarding) or via API calls. Below you will find directions and links to other documents addressing both alternatives.

US Application-to-Person 10-Digit Long Code (A2P 10DLC) messaging is the latest offering from US carriers to help support the growing number of businesses texting their customers while protecting end-users from unwanted messages. 10-digit long codes have traditionally been intended for Person-to-Person (P2P) traffic only, causing businesses to be constrained by limited throughput and heightened filtering.

The launch and support of A2P 10DLC across all carriers in the United States provides good actors with increased deliverability and throughput, but also requires additional registration to build trust with carriers. There are associated fees with this registration process and also per-message carrier fees.

Please see our support article for details of associated fees.

It’s best to think of US A2P 10DLC as comprising two operations: routes and registration. First, carriers prepare their routes for traffic on 10-digit long codes, after which they charge additional fees per outbound message segment. Second, the carriers require that a message originator register their US A2P brand and messaging campaign. Registered traffic immediately benefits from reduced filtering. Twilio has created a centralized process that allows customers to add and manage all required information via the Twilio Console.

1.1 A customer requirements example

Let’s quickly run through an example of an ISV use case and what actions would be required to enable US A2P 10DLC messaging.

As shown in the diagram below, Owl Inc. is a new software company. Two retailers, Acme Corp and Buy n Large, use Owl’s platform to send SMS messages to their own customers.

Owl requires two-factor authentication to login to their platform, and they use Twilio to deliver their one-time passcodes.

Owl has separated its two retail customers, Acme and Buy n Large, into subaccounts to separate billing:

• Acme sends order status updates by SMS to its customers.
• Buy n Large sends promotional content, such as coupon codes, by SMS. It also offers private shopping appointments with their sales team.

In order to comply with the new US A2P 10DLC changes, Owl needs to create the following:

1. Owl needs to register the Owl Inc. Brand. its Brand consists of a Customer Profile and a US A2P brand. Owl pays a registration fee via Twilio to TCR, and TCR returns Owl’s Trust Score.
2. Owl now needs to create a campaign use case for the messages that it sends directly for 2FA to its own customers.
3. Since each of Owl’s customers (Acme and Buy n Large) can control their own message content, Owl must register those Brands, using a Secondary Customer Profile and a separate US A2P brand for each retailer. To do so, it needs to gather information from the retailers, directly or by building a registration portal with Twilio’s APIs for its customers to self-register.
4. Finally, Owl must register a campaign use case for each type of traffic that its customers will be sending:
   • For Acme’s order status updates, it will register a campaign use case with Type=Account Notifications.
   • For Buy n Large, which sends promotional content, such as coupon codes, it will need to register a campaign use case with Type=Marketing.
   • Additionally, Owl will need to register a campaign use case for Buy n Large’s sales appointments use case with Type=Conversational Messaging. This is because these messages typically have a large number of back-and-forth interactions as Buy n Large’s customers find a good time slot.

In this guide, you will find links to detailed explanations of how to register:

1. A Twilio Business Profile.
2. Access to the US A2P 10DLC ecosystem.
3. SMS campaign use cases within the ecosystem.

2. Overview of ISV architectures for A2P 10DLC

We’ve seen many different patterns of how accounts, subaccounts, and messaging services are organized amongst our ISV customers. The diagrams and discussion below represent the six main architectures that clients have used up to the present for the organization of accounts, subaccounts and messaging services.

Please note, however, that these different architectures are NOT all equally viable going forward, given the requirements for A2P 10DLC registration that will enforced as of the Summer of 2023. In general, patterns #3, #5 and #6 below will not be viable for A2P 10DLC registration, and any clients using these architectures currently will need to migrate to patterns #1, #2 or #4. Of these latter three, we suggest that pattern #1 will prove the most useful in the longer term. These points will be explained below with reference to specific patterns.

ISVs using subaccounts

For ISVs who use subaccounts for their customers, each subaccount contains the secondary business profile. Campaign use cases map to the secondary business profile and a Messaging Service.

If, as an ISV, you have a direct offering, you can use your US A2P brand directly and associate it with a campaign use case at the parent-account level.

In the Customer requirements example given above, the ISV (Owl) used subaccounts in which to create the Profiles, Brands and Campaigns of each of their secondary customers, Acme Corp and Buy n Large. The diagram for this has been reproduced below, so it can be more easily contrasted with an example architecture that uses no subaccounts:

ISVs using a single, top-level project (no subaccounts)

For ISVs who do not use subaccounts for their customers, the parent account contains all of the secondary business profiles. Campaign use cases map to the secondary business profile and a Messaging Service.

Identify your ISV type

Identify your ISV type in the table below, based on your architecture and organization. As noted above, architecture types 3, 5 and 6 will not be viable for A2P 10DLC registration going forward.

ISV architecture #1

You use subaccounts for each customer. You will need to collect the required information from customers to fill in the business profile and campaign use case registration forms that make up US A2P 10DLC onboarding.

Information architecture

• Each subaccount contains a secondary business profile associated with that customer.
• Each campaign maps to that secondary business profile and a messaging service within that subaccount.
• Refer to the diagram for ISVs using subaccounts.

NOTE: We would recommend this as the preferred architecture for A2P 10DLC Brand and Campaign registration. In this architecture, the messaging traffic of each end customer is clearly separated from that of every other end customer. In a case where one of your customers is a bad actor and sends non-compliant messages, Twilio could decide to suspend their account. Having each subaccount mapped to an individual customer allows you to minimize impact when this happens because the noncompliant traffic is isolated. Moreover, separating your customers into subaccounts allows much easier analytics tracking of individual customers’ messaging activity.

ISV architecture #2

You use subaccounts for logical separation other than for an individual customer. You instead utilize a Messaging Service for each customer. Customers may have multiple Messaging Services attributed to them, each in a different subaccount.

Information architecture

• The parent account contains all the secondary business profiles for your customers.
• Each campaign maps to that secondary business profile and a Messaging Service.
• Refer to the diagram for ISVs using a single, top-level project (no subaccounts).

Note: This architecture, with all secondary business profiles contained within the single parent account, can be used for compliant A2P 10DLC registration going forward, since each messaging service maps to a distinct secondary client. However, since in this pattern there is no logical separation at the account level, if one of your secondary clients begins sending noncompliant messages, there is a risk that Twilio might need to suspend the entire parent account which would impact all of your secondary accounts.

ISV architecture #3

You use subaccounts for each of your customers but do not currently use A2P 10DLC SMS messaging. If you plan to send US A2P 10DLC SMS going forward for any or all of your secondary customers, you will need to create a Messaging Service within each of your subaccounts and then collect the required information from the customer associated with that subaccount, in order to fill in the Business profile and Campaign use case registration forms that make up US A2P 10DLC onboarding. At that point your architecture will be essentially identical to ISV Architecture #1. Please see the implementation details for that architecture above.

ISV architecture #4

You use a Messaging Service for each customer, but do not use subaccounts. You need to collect the required information from customers to fill in the Business profile and Campaign use case registration forms that make up US A2P 10DLC onboarding.

Information architecture

• The parent account contains all the secondary business profiles for your customers.
• Each campaign maps to that secondary business profile and a Messaging Service.
• Customers that have multiple use cases will have multiple Messaging Services and Campaign use cases or mixed-use Campaigns. (See "Mixed/Marketing Use Case" in Support's list of Campaign use case types)
• Refer to the diagram for ISVs using a single, top-level project (no subaccounts).

Note: Technically this architecture is also valid for A2P 10DLC registration going forward. As with architecture #2 above, however, here again there is no logical separation between your primary (ISV) account and the accounts of your secondary customers. This means, again, that there is no way to isolate the activity of any one of your secondary customers should they begin sending noncompliant A2P messages, and it might become necessary to suspend your primary account, thus impacting all of your other secondary customers as well. Separate analytic tracking of each customers’ messaging activity is also not possible.

ISV architecture #5

You use Messaging Services as a pooled resource shared amongst your secondary customers, and do not use subaccounts. Sharing of Messaging Services among customers is not allowed for A2P registration, as each Messaging Service must be associated with a single Campaign, and that Campaign associated with a single Brand and Customer Profile. Thus at a minimum, to be A2P compliant you would need to transition to Architecture #4 to provide a logical separation of your customers’ messaging services.

As noted above, there are significant benefits to Architecture #1 over Architecture #4, in that Pattern 1 uses subaccounts and therefore offers a logical separation of customer accounts from each other as well as from your primary ISV account. We recognize that this would entail a more significant restructuring; and notably, moving to a subaccount architecture will reset the opt-out mechanisms that Twilio manages, since these are set at the account level. You would therefore need to ensure that you have an up-to-date opt-out list to avoid sending messages to end-users who have opted out. But we suggest that the one-time effort of this restructuring will be worth it in the long term, in allowing you to better manage and track your individual customers’ accounts.

ISV architecture #6

You do not use currently subaccounts or Messaging Services for any of your customers. Again, the first question here is whether you plan to use SMS messaging Campaigns with 10DLC numbers for any of your customers going forward. If not, then you do not need to worry about A2P compliance in general. If you DO expect to use A2P 10DLC messaging going forward, for any customers who intend to message to U.S. end users, then you are in essentially the same situation as Architecture #5 above. At a minimum you would need to adopt Architecture #4 (create a separate Messaging Service to associate with a Profile/Brand/Campaign for each customer). See above for the rationale for moving to Architecture #1 instead, for a better separation among customer accounts.

3. Create your secondary client's Business Profile, Brand and Campaign via the Twilio A2P Compliance Console

The steps you will follow to create your secondary client's Business Profile, Brand and Campaign via the Trust Hub Console are essentially identical to those you would follow if you were creating a Profile, Brand and Campaign for yourself (in other words, as a direct customer) via the Console, with some very specific exceptions in process, which will be noted below:

1. When you log in to the Twilio Console using your own ISV account, you will need to switch customer profile before you can proceed. Select Messaging > Regulatory Compliance from the left navigation if this link is pinned there; otherwise you can search for "Regulatory Compliance". This link will take you to the Customer Profile page. By default this will show your own ISV (or "primary") customer profile, as shown here. For our purposes, "Customer Profile" as labeled in the Console is identical to "Business Profile" as used here and in other linked guides:

You will select the Switch Customer Profile link on the right, which will open a Select a Customer Profile dialogue, where you will select the + New Customer Profile button:

This will take you to a Customer Profile New Registration Page, where you will begin creating your secondary client's new profile. From this point on, the business and contact information you enter will pertain to your client, NOT your own business as an ISV.

In this workflow you will first indicate whether the business entity you're registering is located in the U.S. or Canada. If you indicate yes, the page will then expand to ask whether this business entity has a Tax ID, such as a US EIN. If the answer is yes, then you must create this client's Profile and Brand as either a Standard or Low-Volume Standard Brand (learn more about Standard vs Low-Volume Standard Brands here). If your client does NOT have such a Tax ID, they could be created as a Sole Proprietor Brand (this would be rare for most ISVs' secondary clients, but conceivable if your client were either a hobbyist or a sole-proprietor businessperson who used their own Social Security number for tax filing purposes).

2. Whether you are registering your client here as a Standard, Low-Volume Standard or Sole Proprietor Brand, you will be asked in the next step of Profile creation to confirm that you want to create this profile as a Secondary profile. Your answer will be yes. From this point on, you can follow the Standard/LVS or Sole Proprietor Profile, Brand and Campaign registration processes exactly as detailed in the guides linked below, keeping in mind again that all business and contact information you provide will in all cases pertain to your secondary client, not to yourself as ISV.

3.1 Detailed Walkthroughs for Standard/Low-Volume Standard and Sole Proprietor Brand registration via Twilio Console

4. Create your secondary client's Business Profile, Brand and Campaign via Twilio API calls

ISV's with only a few secondary clients may elect to use the Trust Hub Console, as detailed above; this provides a much more guided experience. If you are less familiar with A2P registration in general it may be worthwhile to follow this process for at least one secondary client, even if you have many others to register, simply to make it easier for you to visualize the sequence of steps and the inputs involved at every point. However, if you have many secondary clients to register, you will ultimately want to do most if not all of them using Twilio's APIs.

5. Special Cases: Registration for Government Agencies, 527 Political Organizations, and K-12 Education entities

5.1 Registration for Government agencies

To successfully register and unlock increased throughput, it is critically important that you register your public sector customers as Government.

• If you are registering your client via the Twilio Console, in the Brand Registration step you will select Government for Company Type.
• If you are registering your client via Trust Hub API, under Step 2 you will indicate a company_type of Government (see specifically the sample call under 2.3.4)

Providing accurate information about your government agency customer and creating a brand with the Government company type during brand registration will trigger automatic vetting of your customers’ organization. If confirmed by TCR as a government entity, the above increased throughput will be applied.

Use Cases: ISVs can register government agency customers with all Standard Campaign use cases, and those customers will also be eligible for the Emergency Special Use Case. If your customers will be sending alerts that meet the definition of the Emergency use case, please see our support article on Special Use Cases for more information.

5.2 Registration for 527 Political Organizations

Campaign Verify

All 527 Political Organizations including political action committees (PACs) sending political communications on behalf of a Federal, State, or Local political campaign must be verified by Campaign Verify in order to onboard successfully onto 10DLC and unlock the "Political" Special Campaign Use Case with increased messaging limits. Campaign Verify is a secure, non-partisan verification solution for U.S. Political organizations who wish to engage with voters via text messaging. For more information on the 527 Political Organization use case, see this FAQ

Listed below are some important pieces of information about Campaign Verify registration:

• There is a one-time $95 fee from Campaign Verify per entity verification per two-year election cycle.
• If a Committee EIN is set during Campaign Verify verification (for state, local, or tribal verification only), this EIN will be cross referenced with the EIN used to register your A2P brand and must match.
• If you have additional questions about Campaign Verify registration, please refer to their FAQ or email support@campaignverify.org

Campaign Verify Tokens

Verification will involve submitting information about your political organization to Campaign Verify, as well as verifying your identity as an authorized person associated with the political organization. Successfully importing a Campaign Verify token will assert your brand status as a verified 527 Political Organization with the carrier ecosystem.

After completing verification with Campaign Verify, you will receive a Campaign Verify Token (CV token) that you will then use during the Brand registration stage of A2P 10DLC registration.

If you are registering a 527 political organization via API, see this step. If you are registering via the Twilio Console, see the next section for detailed directions.

A full CV token is composed of 6 pipe (|) delimited fields, for example:

cv|1.0|tcr|10dlc|9957c339-d46f-49b7-a399-2e6d5ebac66d|GQ3NMEjED8xSlaAgRXAXXBUNBT2AgL-LdQuPveFhEyy

Listed below are some important pieces of information about CV tokens:

• CV tokens expire after a period of time and will need to be periodically updated.
• A single Campaign Verify token cannot be imported or used across multiple brands. If a 527 organization is a customer of multiple text messaging providers that will each create an A2P brand on their behalf, a unique CV token will need to be generated and provided to each vendor.

527 Political Organization Console Registration

In the Twilio A2P Compliance Console, providing a Campaign Verify token is done as part of the A2P brand registration step. You must select "Nonprofit" as your Company type on this screen. CV tokens will only be accepted for brands with this entity type. Then, select Yes to confirm that you are a registered 527 Political Organization. You will then need to paste your CV token to verify your Organization's identity.

Final Notes on 527 Political Registration

As you register an A2P brand for your 527 Political organization, please note the following:

• 527 status will not be automatically detected and applied upon brand registration, unlike 501(c)(x) nonprofit and government entity verification. Importing the Campaign Verify token proves 527 status and activates the special A2P benefits for this entity type.
• Updating a Campaign Verify token after brand registration is currently only available via Twilio’s A2P APIs and not in the Twilio Console.
• Once a Campaign Verify token is imported, the A2P brand will qualify for the Political use case and all other standard use cases will be disabled.

5.3 Registration for K-12 institutions

ISVs registering with the K-12th grade (K-12 Education) special use case are not required to create secondary brands for each K-12 school. This means that as an ISV, you may register a single K-12 Education campaign under your company’s Primary A2P Brand and associate multiple schools' phone numbers within your own Brand.

Note: Public, Private, Nonprofit, and Government entity types all qualify to register for the K-12 Education Use Case.

A2P 10DLC Messaging Limits

Note: If you serve some of your messaging traffic at no cost to your client school(s), we recommend registering that traffic as a separate second K-12 Education campaign in case of potential fee benefits that are currently being considered by carriers.

For the K-12 Education use case, throughput will be enforced per phone number. Daily message caps on T-Mobile will depend on your brand score.

For more information on registering a K-12 Education campaign use case, see the "Registering Campaign Use Cases" section of the guide.

What’s next?

To learn more about A2P 10DLC, please read the following resources:

• What is A2P 10DLC? (Support)
• List of Campaign use case Types for A2P 10DLC registration (Support)
• How do I register to use A2P 10DLC messaging? (Support)
• How to send SMS Messages with Messaging Services