If you spend any amount of time around 10DLC, you will hear an alphabet of acronyms thrown around: Brand, CSP, CNP, DCA, MNO, TCR, OSR, NNID, ESS. People will use them in sentences like "Make sure your CSP elects the right DCA so the campaign reaches the MNO without OSR issues." That sentence is real, but if you are not in the industry, it might as well be in another language.

This section is the decoder ring. By the end of it, you will know who every player is, what they do, and how the structure fits together. We will start with the actual people on the actual phones and work our way up to the systems that make it all run.

The cast of characters

Picture the journey of a single text message: say, your bank texting you a one-time passcode. Here are the actors on stage, in the order the message visits them:

The Brand

The Brand is the company the consumer thinks is sending the message. In our example, that is the bank.

The Brand is the entity that owns the relationship with the end user, owns the content of the message, and is ultimately accountable for whether that message is wanted or unwanted, compliant or non-compliant. The Brand is whose name appears on the consumer's phone screen, in spirit if not literally.

In the 10DLC ecosystem, the Brand has to be registered with The Campaign Registry, identified by its legal name, and tied to its EIN or equivalent tax ID. The Brand carries the trust score that determines a lot of what happens downstream.

Most Brands do not actually send their own messages. They use software platforms to do it.

The CSP — Campaign Service Provider

The CSP is the software platform that the Brand uses to send messages. CSPs are platforms that developers build on, the Software as a Service (SaaS) tools that marketing teams use, the APIs that engineering teams integrate with.

In the 10DLC framework, the CSP is the primary user of The Campaign Registry. The CSP is the one who registers Brands on behalf of their customers, declares Campaigns (we will get to those), attests to compliance, pays the registration fees, and takes responsibility for ongoing campaign management.

CSPs are also the layer most businesses interact with day-to-day. When a Brand opens a support ticket because messages are not going through, that ticket usually goes to their CSP first. Most of what feels like the "10DLC system" to most users is actually the CSP's interpretation and packaging of the 10DLC system.

The CNP — Connectivity Partner

The CNP is the entity that connects a CSP into a DCA, which in turn provides the direct connections into the carrier networks. CNPs do not have direct carrier connections themselves. They sit between the CSP and the DCA, providing the routing, technical integration, and commercial relationship that lets a CSP's traffic reach a DCA without the CSP having to build that relationship from scratch.

This is the part that gets confusing, because the same company can wear more than one hat. A single company can be a CSP for one set of customers, a CNP for another set, and a DCA for yet another. There are companies in the U.S. ecosystem that operate as all three. The role is determined by the function the company is performing in a given transaction, not by the company itself.

Smaller CSPs typically elect a CNP to handle their carrier connectivity. Larger CSPs often act as their own CNP, and may also serve as a CNP for other smaller CSPs reselling on top of their platform. The CNP layer can be invisible from the Brand's perspective, but it is doing real routing and accountability work in the chain.

The DCA — Direct Connect Aggregator

This is us. This is Syniverse.

A DCA is a company with direct aggregator connections into the carrier networks themselves. Not many of these exist. Direct connections are not granted lightly. There is a vetting process, a contractual relationship, and ongoing operational requirements that are not trivial to maintain.

When a campaign has been registered, vetted, and accepted up through the CSP and the CNP layers, it eventually arrives at a DCA. The DCA's main job is technical and API integration between Brands or CSPs on one side and the carriers on the other. We handle the final layer of compliance review, the actual provisioning of campaigns onto the carriers' platforms, and the technical delivery of messages once campaigns go live.

In practical terms, DCAs are the technical and operational interface between the entire universe of CSPs and Brands on one side, and the carrier networks on the other. We help operationalize the carrier codes of conduct. We see network-layer behavior that other parts of the chain do not see directly.

This is why the DCA perspective is worth publishing. Different layers of the 10DLC ecosystem see different things. None of us see the whole picture alone, and the industry benefits when each layer's perspective is shared openly.

The MNO — Mobile Network Operator

The MNO is the carrier. These are the companies that own the cell towers, the spectrum, the network, and ultimately the relationship with the end consumer holding the phone.

In the 10DLC framework, the MNOs set the rules. They publish the codes of conduct. They define the message classes and brand tiers and throughput limits. They decide whether a particular campaign type is allowed on their network. They impose the fees, the audits, and the penalties for non-compliance.

The DCAs, CNPs, CSPs, and Brands all operate within the rules the MNOs set. When you read about a "carrier requirement" in the 10DLC world, that is an MNO requirement. The whole system below them exists to give the MNOs a sanctioned, accountable, manageable way to allow business messaging on their networks without overwhelming the consumer experience.

The supporting cast — the systems and registries

The five entities above are the players. The next group is the systems that hold the whole thing together.

TCR — The Campaign Registry

TCR is the central registry where every Brand and every Campaign in the U.S. 10DLC ecosystem is registered. It is not a carrier, not an aggregator, not a CSP. It is an independent third-party platform that the carriers chose to act as the system of record.

TCR collects the Brand information, runs identity verification, assigns each Brand a unique ID, and tracks all Campaigns associated with that Brand. CSPs interact with TCR directly through a web portal and an API. The carriers pull from TCR to know who is sending what across their networks.

TCR is not a compliance organization. They do not decide if your campaign content is acceptable. They do not approve or reject campaigns. Their role is identity verification and registration management. Compliance review happens elsewhere in the chain.

For TCR's official documentation, processes, and fee schedules, see The Campaign Registry.

NetNumber, the routing layer, and the NNID

NetNumber is another third party in this story, separate from TCR. They run the routing infrastructure that tells the carrier networks how to handle 10DLC traffic, and they issue the identifiers that the routing infrastructure depends on.

The routing database used to be called the Override Service Registry, or OSR, and is now formally known as the nnSR (NetNumber Service Registry). When a campaign is registered in TCR and accepted up the chain, it eventually ends up associated with phone numbers in the nnSR. The nnSR is what tells the carrier networks: "When you see traffic on this phone number, it belongs to this campaign, registered by this Brand, served by this CSP, terminated through this DCA." Without proper number association in the nnSR, registered campaigns cannot deliver traffic. Registration in TCR alone is not enough.

The NNID, which stands for NetNumber Identification, is the identifier NetNumber assigns to a CSP, CNP, or DCA so that the routing layer knows whose traffic is whose. Think of it as a filing system at the routing layer. When carriers see traffic from a number tied to a particular NNID, they know which entity is responsible for that traffic.

NetNumber, the nnSR, and NNIDs are plumbing, but they matter when something goes wrong with routing.

The flow, in plain language

Here is what actually happens when a Brand decides to send messages:

1. The Brand picks a CSP to use as their messaging tool.

2. The CSP registers the Brand with TCR. TCR runs identity verification and assigns a Brand ID.

3. The CSP registers a Campaign for that Brand, declaring what kind of messaging the Brand will send.

4. The CSP elects a CNP, which is the entity that will provide the actual carrier connectivity for the campaign.

5. The CNP either handles connectivity directly or further elects a DCA, like Syniverse, that has direct connections into the carrier networks.

6. The DCA reviews the campaign, ensures it complies with the carrier codes of conduct, and provisions it onto each carrier's platform.

7. The campaign goes live. Phone numbers are associated to the campaign in the nnSR. Messages start flowing.

8. Throughout the campaign's life, the DCA monitors compliance, the carriers monitor traffic patterns, and any issues are routed back through the chain.

That is the whole story. The acronyms, decoded.

Why this structure exists

If you are new to all of this, you might reasonably ask: why is there so much layering? Why not just have the Brand register directly with the carrier?

The answer is partly historical, partly practical.

Historically, this structure evolved from the existing relationships between carriers, aggregators, and software platforms before 10DLC was formalized. The aggregators were already there providing connectivity. The CSPs were already there providing software. When the carriers decided to formalize A2P messaging, they built the framework around the existing players rather than starting from scratch.

Practically, the layering provides specialization. The carriers do not want to deal with hundreds of thousands of individual brands directly. Brands do not want to build their own carrier connections. CSPs are great at software but most do not want to manage carrier relationships. CNPs and DCAs handle connectivity. TCR handles registration. NetNumber handles routing. Each layer does what it specializes in.

The structure can feel complicated when you are first learning it. Once you have the mental model, the pieces fit together logically.

Where Syniverse fits

Syniverse is a DCA. We sit at the layer just below the carriers. We work with most of the major CSPs in the U.S. and Canada, either directly or through CNP relationships. When messages flow through us, we see them, we know who registered them, we know the campaigns they belong to, and we know how the carriers will treat them.

Our position is the reason we are publishing this Knowledge Center. We see the system from a vantage point that is worth sharing publicly. Our perspective is not better than a CSP's perspective. It is different, and the industry benefits when both perspectives are out in the open.

In the rest of this Knowledge Center, we go deeper on the topics most worth understanding from the DCA perspective: why campaigns get rejected, how content monitoring works at the network layer, and how 10DLC compares with the other A2P channels. You now have the map. The rest is the terrain.

This Knowledge Center is also intentionally complementary to other industry resources, not a replacement for them. For CTIA messaging principles and best practices, please refer to ctia.org.

RELATED SECTIONS

• What is 10DLC, Really?

• Why Campaigns Get Rejected

• Spam, Phishing, and What We See at the Network Layer

• 10DLC vs Short Code vs Toll-Free