A Managed Access Provider (MAP) is what connects a business to the Hub, so switching data can move securely between providers. What that connection actually includes, though, depends entirely on the model behind it. A Full Management MAP runs the whole thing on your behalf including the connection itself, the security credentials, keeping everything up and running, and fixing problems when they come up usually backed by a service agreement that guarantees uptime and response times. A Self-Managed MAP just gets you connected. Everything beyond that, from managing credentials to handling errors, is left to your own team to build and maintain. The choice comes down to one question: how much of this do you want to own, and how much do you want someone else to be accountable for?
What each model actually covers
The split between the two models isn’t about access, both get you connected to the Hub, and on paper, both satisfy the same basic requirement. Where they diverge is in who runs the operational layer sitting behind that connection: credentials and their renewal, caching and how fresh it stays, ongoing monitoring, and what happens the moment something fails. That layer doesn’t disappear under either model, it just lands on a different desk. One model absorbs it as a service, with someone else accountable for keeping it running. The other leaves it fully in your hands, with your own team on the hook for building it, maintaining it, and fixing it when it breaks. Everything below breaks down exactly what each one owns in practice, function by function.
Full Management MAP
A Full Management MAP operates as the technical layer between your business and the Hub. It holds the credential relationship on your behalf and takes ownership of the operational detail your engineers would otherwise have to build and operate:
- Certificate issuance, rotation, and renewal, tracked so nothing lapses silently
- Security token refresh, handled automatically with no manual intervention
- Directory and reference data kept current on a set refresh schedule
- Error detection and first-line resolution, caught before it becomes your problem
- Escalation with counterparties on your behalf when a failure sits on their side
- Ongoing monitoring for spec or policy changes, with updates rolled in as they land
Your team interacts with the Hub exclusively through the MAP’s interface; every function beneath that abstraction layer like credential management, monitoring, and fault remediation that falls under the MAP’s operational responsibility rather than yours. This is the core value proposition of the model: a predictable, recurring service fee in exchange for transferring operational ownership, including incident response for failures that occur outside standard business hours, when internal engineering resources are typically unavailable to respond.
Self-Managed MAP
A Self-Managed MAP provides network access and endpoint connectivity to the Hub; the operational layer beyond that point is entirely your organisation’s responsibility to design, implement, and maintain:
- Certificate lifecycle management, including issuance, rotation, and renewal scheduling
- Token refresh logic, built, tested, and monitored internally
- A caching layer for directory and reference data, refreshed on a schedule you define and maintain
- Error-handling logic for both synchronous and asynchronous failure paths
- Escalation processes with counterparties, managed directly by your team
- Continuous monitoring of specification and policy updates, tracked and implemented internally
This model is best suited to a team that already operates comparable infrastructure elsewhere and prioritises control over implementation choices above a fully managed outcome. It exchanges a lower recurring cost for a genuine, sustained engineering commitment. The operational scope isn’t reduced relative to Full Management, but it’s simply relocated in-house, with your team assuming full accountability for its reliability.
Where the risk actually sits
Going Self-Managed 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 represents an identical failure mode under either model; the material difference lies in which party bears responsibility for detection, remediation, and any downstream impact.
Full Management is structured specifically to transfer that operational risk to the MAP, which is compensated to assume it as a core component of the service agreement. Self-Managed retains that risk within your organisation, in exchange for a reduced recurring cost and full control over implementation decisions.
For an organisation with an established API gateway and mature certificate management practices already in place, the incremental risk of adopting a Self-Managed model is comparatively low, since the required operational discipline already exists within the team. For an organisation lacking that infrastructure, Self-Managed effectively means constructing a new operational capability from first principles, which introduces material execution risk during the build and stabilisation phase.
Cost and Speed, Weighed Against Each Other
Full Management and Self-Managed differ not only in who owns the operational risk, but in how that risk translates into cost and time-to-market. The two dimensions are worth examining separately, since a model that looks cheaper on cost may not be faster to deploy, and vice versa.
Cost Structure
Full Management constitutes a recurring service expense, structured as a predictable fee in exchange for the MAP absorbing engineering effort, incident response, and ongoing maintenance. Self-Managed removes that recurring cost but redirects the expense into internal engineering effort developing the handling logic, the caching layer, and the dual error-resolution paths, then validating all of it against an internally managed timeline and budget.
At low or uncertain transaction volumes, the Full Management fee generally represents better value than the engineering investment required to build and sustain a compliant Self-Managed implementation. At higher volumes, where fixed engineering costs are amortised across a larger transaction base and existing infrastructure reduces incremental build effort, that calculation reverses in favour of Self-Managed.
Speed to Operational Readiness
Full Management typically delivers a shorter path to operational readiness, as it is built on infrastructure the MAP has already validated and operates at scale across multiple clients, reducing the testing and certification burden on your side. Self-Managed requires building each operational component from scratch, certificate handling, token refresh, caching, and error resolution and validating it independently before go-live, which extends the timeline in proportion to the maturity of the infrastructure your team already has in place. An organisation with existing API gateway and PKI operations will close that gap faster than one starting without it.
Which one fits your Organisation
Pick based on what already exists inside your team, not on company size:
- Choose Full Management if you don’t already run certificate lifecycle, token refresh, and caching elsewhere, or you’d rather pay a predictable fee than staff an ongoing operation.
- Choose Self-Managed if you already run comparable infrastructure, your volume justifies the build, and control matters more than offloading the work.
Building the muscle for the first time under deadline pressure is the expensive path more often than teams expect. TOTSCo’s own Business Switching User Guide walks through onboarding steps for both paths if you want the primary-source detail.