Every Communication Provider preparing for Gaining Provider Led Business (GPLB) switching runs into the same fork in the road. The APIs are reviewed, compliance requirements are mapped, project timelines are approved, and then someone on the team asks whether to connect through the TOTSCo Hub or adopt MESH/Connected Services Framework (CSF) instead.
Both options exchange switching messages and meet UK industry requirements for business switching. That’s where the similarity ends. The TOTSCo Hub is a central message exchange: every switching request passes through a shared platform before reaching another provider. MESH/CSF removes that intermediary entirely, letting Managed Access Providers (MAPs) communicate directly using distributed directories and cryptographic trust instead.
This isn’t a low-stakes technical footnote. Ofcom has shown it will enforce switching rules with real money on the line, fining Virgin Media £28 million in July 2026 for making it unreasonably hard for customers to leave. Getting the compliance architecture wrong is not a theoretical risk, and the two models put very different amounts of that risk on your own team versus TOTSCo. This guide compares both architectures directly and gives you a clear way to decide which one fits your CP.
What Is the TOTSCo Hub?
The One Touch Switching Company (TOTSCo) is a not-for-profit organisation established by the UK telecom industry to implement the technical framework required by Ofcom’s One Touch Switching regulations. Rather than requiring every Communication Provider to build direct integrations with every other provider, TOTSCo operates a central message exchange platform known simply as the Hub.
Every participating provider connects to this shared platform, allowing switching messages to be validated, routed, and delivered using a common set of APIs and business rules. This “connect once, communicate with many” model dramatically reduces integration complexity. Instead of maintaining dozens of point-to-point connections, providers integrate with a single trusted platform that handles interoperability on their behalf. Since its launch, the Hub has processed millions of successful switching transactions, demonstrating that it has evolved from a regulatory initiative into critical UK telecom infrastructure.
What is MESH/Connected Services Framework (CSF)?
While the TOTSCo Hub centralizes message exchange, MESH/Connected Services Framework (CSF) takes a fundamentally different approach. Developed by the Telecom Technical Architecture Group (TAG), CSF is an open interoperability framework that enables Managed Access Providers (MAPs) to exchange switching messages directly, without relying on a central operator. Instead of routing every message through a shared Hub, participating MAPs communicate peer-to-peer.
Trust is established through:
- Public Key Infrastructure (PKI)
- Digital signatures
- Distributed directories
- DNS-based public key verification
Each MAP publishes information about the Communication Providers it represents, allowing other MAPs to discover routing information without relying on a centralized directory.
TOTSCo Hub vs. MESH/CSF: A Practical Comparison
Now that we’ve covered what each architecture does, the real question is: how do they compare in practice? While both enable secure message exchange for business switching, they differ significantly in how they handle trust, operations, scalability, and day-to-day management. Let’s break it down.
Architecture: Centralized Simplicity vs. Distributed Control
The most obvious difference lies in how switching messages are exchanged. With the TOTSCo Hub, every switching request passes through a centralized platform. The Hub validates the message, verifies participating Communication Providers (CPs), applies business rules, and forwards the request to the receiving provider. This “connect once, communicate with everyone” model minimizes integration effort and ensures all participants follow the same technical standards.
By contrast, MESH/Connected Services Framework (CSF) removes the intermediary, instead of routing messages through a shared platform, Managed Access Providers (MAPs) to communicate directly. Each MAP publishes directory information about the CPs it represents, allowing other MAPs to discover the correct destination and exchange messages securely.
Security: Different Trust Models, Similar Objectives
Security is often where providers assume the two architectures differ most dramatically. Both are designed to provide secure and reliable message exchange; they simply achieve it differently.
The Hub acts as a trusted intermediary. It validates incoming requests, checks message formats, confirms participating providers are authorized, and routes messages through a controlled platform. For Communication Providers, much of the operational responsibility for interoperability sits with the Hub.
Whereas, CSF removes the trusted intermediary and replaces it with cryptographic trust. Every message is digitally signed using Public Key Infrastructure (PKI). Receiving MAPs validate those signatures using public keys published via DNS, ensuring messages are authentic and haven’t been altered in transit. This distributed model eliminates dependence on a single routing platform but requires each participant to manage certificates, keys, and directory data correctly.
Operations, Onboarding, and Maintenance
This is where the decision becomes less about technology and more about operational capability. For most Communication Providers, onboarding is relatively straightforward. Once connected, the TOSTCO Hub handles message routing and interoperability, allowing internal engineering teams to focus on integrating business systems rather than managing external connectivity.
This makes it particularly attractive for providers with:
- Smaller engineering teams
- Limited operational resources
- Faster compliance deadlines
- Minimal appetite for infrastructure management
Several providers have publicly documented their onboarding experience, including RevK, whose implementation journey offers valuable insights into testing and certification. Whereas CSF offers greater independence but also more responsibility.
Participating MAPs must manage:
- Public Key Infrastructure (PKI)
- DNS records
- Certificate rotation
- Distributed directories
- High availability
- Monitoring
- Resilience planning
Onboarding also differs. Rather than registering through a central platform, new MAPs are typically sponsored by an existing MAP, creating a collaborative but decentralized onboarding model. For organisations already operating distributed telecom platforms, this may feel entirely natural. For others, it represents a significant operational commitment.
Scalability: Who Owns the Growth?
As switching volumes increase, so do operational demands. The key difference is where those demands are absorbed. Scaling the platform is largely TOTSCo’s responsibility. Communication Providers benefit from shared infrastructure without needing to expand their own routing capabilities. This is ideal for organisations that want predictable operations with minimal infrastructure ownership. Whereas in MESH/CSF, there is no shared infrastructure to absorb growth. As traffic increases, each MAP must ensure its own platform can scale while maintaining availability, security, and performance. This offers greater control but also shifts responsibility entirely to the participating organisations.
Where do TOSCO and Mesh/CSF Diverge
On paper, this sounds like a classic centralized vs decentralized debate, the kind engineers have been having since before the internet existed. In practice, the differences that actually matter to a CP show up in three very specific places: how messages get validated and secured, how much ongoing work your team signs up for, and what it costs to get connected in the first place.
It’s worth being honest about something here: neither model is objectively better, and this isn’t a low-stakes technical footnote either. The CSF specification itself is explicit that Hub routing stays mandatory for residential OTS switching, whatever a CP eventually chooses for business switching under GPLB. So, this isn’t really a contest between two competing standards. It’s a decision about which slice of your switching traffic, if any, you want to route outside the Hub once GPLB gives you that option. Understanding what changes underneath each model, not just what the marketing slide says, is the only way to make that call without guessing.
Which Should Your Communication Provider Choose?
There’s no universal winner. The right choice depends on your organisation not just your technology stack.
Choose the TOTSCo Hub if you:
- Need the quickest route to compliance
- Have a small or medium-sized engineering team
- Prefer lower operational overhead
- Want a standardized onboarding process
- Primarily support residential switching alongside GPLB
Consider MESH/CSF if you:
- Already operate resilient distributed platforms
- Have experience managing PKI and secure networking
- Exchange high volumes of switching messages
- Want greater architectural control
- Have dedicated platform engineering resources
Pro tip: For many larger organisations, this isn’t an either-or decision. A hybrid strategy using the TOTSCo Hub for broad interoperability while leveraging CSF for high-volume partner relationships can offer the best balance of flexibility and operational simplicity.
Why this Decision Matters:
Architecture decisions rarely become visible to customers, but they shape everything behind the scenes. Choosing between the TOTSCo Hub and MESH/CSF affects far more than how switching messages are exchanged. It influences:
- How quickly your organisation can go live
- The complexity of onboarding new partners
- Security responsibilities across your infrastructure
- Ongoing operational costs
- Platform scalability
- Long-term maintenance
For residential broadband switching, the decision has already been made. Under Ofcom’s One Touch Switching (OTS) regulations, Communication Providers must exchange switching messages through the TOTSCo Hub. Business switching under GPLB, however, provides greater flexibility. Eligible providers can continue using the Hub or adopt MESH/CSF, depending on their operational model and business requirements. That flexibility has prompted many providers to ask an important question:
Should we continue with a centralized platform, or is it time to move towards a distributed architecture?
There isn’t a universal answer, Although the TOTSCo Hub and MESH/CSF ultimately support the same objective secure and reliable switching they achieve it in fundamentally different ways. Think of them as two different approaches to solving the same problem. One centralizes communication. The other decentralizes trust.
Final Thoughts
Choosing between the TOTSCo Hub and MESH/Connected Services Framework (CSF) isn’t simply a technical decision, it’s an operational one. The Hub excels by reducing complexity. It provides a proven, centralized platform that allows Communication Providers to focus on delivering services rather than maintaining distributed infrastructure. CSF takes a different path. It gives organisations greater control, removes dependence on a central routing platform, and enables highly flexible peer-to-peer communication but only if they’re prepared to own the additional operational responsibilities that come with it.
For most Communication Providers, the TOTSCo Hub remains the most practical choice. For organisations with mature engineering capabilities, high switching volumes, and a long-term distributed architecture strategy, CSF can become a valuable complement or, in some scenarios, an alternative for eligible business switching. Ultimately, the best architecture is the one that aligns with your operational maturity, compliance requirements, and future growth plans not simply the one that offers the most technical flexibility.