Direct Participation means signing TOTSCo’s Hub User Agreement and running the GPLB stack yourself like certificates, tokens, caching, error handling etc for as long as you switch business customers. A Managed Access Provider runs that same stack on your behalf instead. Both are fully compliant. What decides between them is whether your team already carries this kind of operational load somewhere else in the business.
The question isn’t whether you’re big enough to build this yourself. A 40-person CP already running a certificate rotation schedule for other systems is in a stronger position than a 300-person telco that’s never had to track a token refresh. TOTSCo gives 30 days’ notice before a specification change takes effect, someone on your team either owns turning that notice into a shipped update before the clock runs out, or they don’t, and that gap matters more than anything on an org chart.
This blog works through what each path commits you to, four questions that surface where you stand, where the operational risk lands once you’ve picked, and how cost and speed pull against each other.
What each model commits you to in practice
Both routes connect a CP to the Hub and satisfy the same GPLB requirement on paper. What differs is who owns the operational layer sitting behind that connection such as certificate and token lifecycle, directory caching, dual-path error handling, and ongoing monitoring of TOTSCo’s specification changes. Neither of both models shrinks that scope of work. Direct Participation puts it permanently on your team’s roadmap. A Managed Access Provider puts it on a third party’s roadmap instead, under a service agreement that makes them accountable for it. Before the four decision questions below, it’s worth being precise about what each commitment actually looks like in practice, because “own it” and “outsource it” both hide a lot of detail that matters once you’re past the certification stage and running live traffic.
Direct Participation
Signing the Hub User Agreement and connecting directly means your organisation owns every piece of the GPLB stack, indefinitely, not just through go-live. In practice that means:
- Certificate and token lifecycle management across whichever of the five permitted security combinations you pick, with OAuth tokens needing automated hourly refresh and mutual TLS certificates needing renewal tracking a year out.
- A directory caching layer that refreshes on schedule rather than on someone remembering to run a script, because a stale directory routes messages to providers that have moved MAP or changed status.
- Error-handling logic that correctly separates synchronous rejections, which are yours to fix, from asynchronous delivery failures, which may need chasing with a trading partner.
- Ongoing monitoring of TOTSCo’s specification changes, delivered on a minimum 30-day notice, so your build doesn’t quietly drift out of compliance after go-live.
- Peer-to-peer certification testing with real trading partners, on top of internal Hub testing, before you’re cleared to go live.
None of this is a one-time build. It’s a standing operational commitment that competes for space on your roadmap for as long as you switch business customers, which is exactly why the four questions in the next section matter more than a feature checklist.
Managed Access Provider
A Full Management MAP absorbs the same operational weight, indefinitely, so the work doesn’t disappear, it just moves to someone else’s team:
- Certificate and token lifecycle management, so PKI rotation and OAuth refresh cycles run on the MAP’s schedule rather than yours.
- Directory caching and refresh, kept current by the MAP so your systems never route against a stale list of active providers.
- Dual-path error handling, with the MAP separating synchronous rejections from asynchronous delivery failures and resolving or escalating each correctly.
- Ongoing alignment with TOTSCo’s specification changes, tracked and implemented by the MAP as notices land.
- Certification and testing overhead, carried by the MAP as part of onboarding you onto its existing, already-certified connection.
Your team still needs to understand what the MAP is responsible for and how to judge whether it’s doing that job well, a MAP handling this well removes a permanent maintenance burden; a MAP handling it poorly becomes a compliance risk you can’t see into directly. That oversight requirement is smaller than building the stack yourself, but it isn’t zero, which is worth factoring into the decision questions that follow.
The questions Deciding Between Direct and Managed Access
Company size is a weak predictor here. A 40-person CP that already runs API gateway infrastructure and manages its own certificate lifecycle for other systems is closer to “build” than a 300-person CP that has never operated anything like it. Rather than starting from headcount or budget, work through the four questions below in order. Each one narrows the decision further, and by the fourth question most teams already know which way they’re leaning, the questions are designed to surface that instinct with something concrete behind it, rather than leaving the call to a gut feeling about company size or ambition.
1. Do you already operate certificate lifecycle management at scale?
This is the single strongest predictor of fit. If your team runs mutual TLS certificate rotation, token refresh automation, or equivalent PKI operations for other integrations today, GPLB Direct Participation is an extension of a muscle you already have: the tooling, the on-call rotation, and the institutional knowledge for handling expiry and renewal already exist, and GPLB just becomes one more system under that umbrella. The marginal effort is real but small, because the hard part, building the operational discipline itself, is already done.
If certificate expiry has ever caused an incident because nobody was tracking it, that’s your answer. It points firmly toward a Managed Access Provider instead of building this capability for the first time under a compliance deadline, where the cost of a missed renewal is a blown certification window, not just an internal fire drill.
2. Who owns “the spec changed” on your team?
TOTSCo commits to 30 days’ notice on document changes. Direct Participation means someone on your team is accountable for reading every notice, assessing its impact on your build, and shipping updates before the change takes effect, not eventually, but within that 30-day window every time. There’s no partial credit here: a spec update implemented on day 35 carries the same compliance exposure as one never implemented at all.
If that ownership doesn’t clearly sit with a named role today, it won’t appear on its own after go-live. It’ll surface as a missed update discovered during an incident, usually the worst possible time to learn who was supposed to be watching. A Managed Access Provider absorbs this monitoring as part of its service, which is often the single biggest ongoing time saving it offers relative to Direct Participation, precisely because it turns a diffuse responsibility into someone’s named job.
3. What does your engineering roadmap look like for the next two years?
Direct Participation isn’t a project that finishes at certification. It’s a recurring line-item competing with product work indefinitely, showing up in every sprint planning cycle for as long as your business keeps handling customer switches. That’s the real cost most teams underprice: not the initial build, but the permanent claim it stakes on engineering time that would otherwise go to product.
If GPLB compliance would be the only reason your team builds and maintains this class of infrastructure, that maintenance cost rarely justifies itself against the alternative of paying a MAP to specialise in it. You’d be standing up PKI and API gateway discipline from scratch, for one use case, indefinitely. If your roadmap already includes comparable PKI or API gateway work for other reasons, GPLB adds relatively little marginal effort on top of it. In that case, the infrastructure pays for itself twice over, and Direct Participation stops looking like a cost at all.
4. How much visibility do you need into the switching pipeline itself?
Some CPs want direct, unmediated access to Hub responses and fault codes for their own monitoring and customer support workflows. Surfacing a specific rejection reason to a support agent in real time, rather than waiting on a MAP’s escalation, is the clearest example of what that buys you. It’s the difference between a support agent reading a fault code off your own dashboard and that same agent waiting on a ticket update from someone else’s platform.
If synchronous and asynchronous failure handling needs to plug directly into systems you already run, such as a support tool, a customer-facing status page, or an internal alerting pipeline, Direct Participation gives you that without a third party in the loop.
If you’re comfortable with a MAP’s reporting and escalation process instead, this requirement disappears and stops being a factor in the decision. Most CPs without a real-time support use case fall into this camp.
Where the risk actually sits
Whichever way the four questions point you, it’s worth being clear-eyed about what changes and what doesn’t. Choosing a MAP doesn’t remove the underlying operational requirements of connecting to the TOTSCo Hub, it just moves who carries them. A lapsed certificate, an expired token, or a stale cache entry is an identical failure mode under either model; the difference is which party bears responsibility for detection, remediation, and any downstream impact on switching customers.
Direct Participation is structured to transfer that operational risk fully to your organisation, in exchange for more control and more visibility. A Full Management MAP is structured specifically to transfer that risk to the provider, which is compensated to assume it as a core part of the service agreement. For a team with existing PKI and API gateway maturity, the incremental risk of Direct Participation is genuinely low. For a team without it, the risk isn’t hypothetical, it shows up during the build and stabilisation phase, right when a missed certification window is most costly to recover from.
Cost and speed, weighed against each other
Once the four questions point you toward a model, it’s worth sanity-checking that answer against cost and time-to-market, since they don’t always move in the same direction. Direct Participation redirects spend into internal engineering effort, building the handling logic, the caching layer, and the dual error-resolution paths validated against an internally managed timeline. A Managed Access Provider is a recurring service fee in exchange for the provider absorbing that effort and the incident response that comes with it.
At low or uncertain switching volumes, the MAP fee usually beats the engineering investment required to build and sustain a compliant direct connection. At higher volumes, with existing infrastructure reducing incremental build effort, that calculation can reverse but only when the infrastructure is genuinely reusable outside GPLB. On speed, a MAP is almost always faster to operational readiness, since it’s onboarding you onto an already-certified connection rather than building and clearing peer-to-peer certification from scratch.
The honest default
If your organisation isn’t already running certificate lifecycle management and API gateway infrastructure at production scale, a Full Management MAP is the safer starting point not a fallback for smaller CPs, but the lower-risk choice for any team building this capability from zero. Building that operational muscle from scratch under a regulatory deadline is where compliance projects slip. You can always revisit Direct Participation later once GPLB switching volume justifies the investment; nothing in the Hub User Agreement locks you into one model permanently. Reversing a rushed in-house build after a missed certification window is much harder than starting with a MAP and moving off it once your answers to the four questions above have changed.