A European retail bank decided to launch a mobile proposition for its current account customers. They wanted control — over subscriber data, over pricing logic, over the ability to connect mobile usage to transaction history. So they chose a full MVNO model and contracted a BSS platform vendor accordingly. The project took 34 months from commercial decision to live service. By that point, two fintech competitors had launched mobile propositions, attracted a combined 600,000 subscribers, and were bundling banking and mobile in ways the bank had originally planned as its own differentiator.
The full MVNO model was not wrong for a bank. It may have been right for a different bank, with a larger technology organisation and a longer strategic runway. For this bank, at this point in time, it was the wrong choice — and the error was made before they ever opened a vendor shortlist.
The operating model decision is the highest-leverage decision in an MVNO or MVNE project. It determines cost structure, time to market, integration complexity, and long-term optionality simultaneously. Most organisations make it after they've started evaluating platforms — which means they're making it under the influence of what vendors are selling, rather than what the business actually needs.
What the models actually mean
The terminology in this market is not standardised, which creates confusion early in project planning. For reference:
A light MVNO (also called a branded reseller or thin MVNO) relies on the host MNO or a third-party MVNE for virtually all network and BSS functions — SIM management, HLR/HSS, billing, interconnect. The MVNO manages the brand, distribution and customer relationship. Operational independence from the host is minimal.
An enhanced MVNO owns some core elements — typically its own HLR/HSS and SIM management — but relies on the host or an MVNE for billing and network layer management. Subscriber data is under the MVNO's control; billing logic is partially constrained by the enabler.
A full MVNO owns and operates all core network and BSS functions: its own HLR/HSS, its own billing and charging engine, its own number blocks, its own roaming agreements. The host MNO provides spectrum and capacity only.
An MVNE (Mobile Virtual Network Enabler) is not an MVNO — it is an infrastructure layer. An MVNE provides BSS/OSS, SIM management, interconnect and operational services to multiple MVNOs, sitting between the host MNO and its partners. Relevant not just to specialist infrastructure companies but to any MNO evaluating how to scale a wholesale MVNO portfolio.
The three decisions that determine the right model
Control appetite
What operational parameters does the business model actually require control over?
This question sounds simple. It tends to be answered incorrectly in both directions. Light MVNO projects often underestimate the control they need — discovering post-launch that they can't implement the product configurations or subscriber data integrations their proposition requires. Full MVNO projects often overestimate it — building complex operational infrastructure for capabilities they won't use for years.
The useful approach is to work backward from the product. If the mobile proposition is a standard SIM with branded packaging, a loyalty reward mechanism and basic bundles — a light MVNO is almost certainly sufficient. If the proposition requires real-time balance integration with a financial account, personalised pricing at the individual subscriber level, or direct access to network signaling — an enhanced or full MVNO model is probably necessary.
Operational capacity
A full MVNO is not just a platform decision. It is an organisational decision. Running one requires telecom operations capability: engineers who understand HLR/HSS configuration, billing system administration, number management, roaming agreements, network interconnect. Some of this can be outsourced, but not indefinitely, and not without risk.
Organisations building this capability from scratch face a hiring and training problem that runs in parallel with the platform project. It compounds implementation timelines in ways that tend to be underestimated. A light MVNO through an established MVNE inherits the operational infrastructure and staff the enabler has already built.
Strategic timeline
How long can the organisation wait before going to market? This question needs an honest answer.
A full MVNO with custom BSS integration in a new market typically takes 12–24 months from commercial decision to commercial launch. A light MVNO through an MVNE with a platform already in production can be live in 3–6 months. An enhanced MVNO sits somewhere between.
The cost of delay is not just revenue foregone. When the MVNO proposition is linked to a broader digital product — a bank's mobile app, a retailer's loyalty platform — a 24-month delay means the digital product evolves without the mobile component, integrations get built around its absence, and reconnecting them later becomes harder.
The upgrade path that isn't
A common project assumption: starting light reduces risk because "we can always upgrade to full MVNO later." True in principle. In practice, moving from a light MVNO to a full MVNO is not an upgrade — it is a migration.
The subscriber base, billing records, SIM inventory, number ranges and product catalogue all sit within the MVNE or host MNO's infrastructure. Moving them to a new platform requires a migration project of comparable complexity to the original launch. Subscribers need to move without service interruption. Billing history needs to be preserved. Number management needs to transfer. In some markets, regulatory notifications are required.
This is not an argument against starting light. For many organisations it remains the right choice. The point is that the path to a higher-control model is a discrete project, not a configuration change — and needs to be in the plan from the start.
The MVNE case: when enabling is more valuable than operating
For MNO wholesale teams, the question takes a different form. The choice is not between MVNO models — it is between managing each MVNO partnership as a direct bilateral relationship versus operating an MVNE function that enables partners through shared infrastructure.
At two or three MVNO partners, a direct relationship model works. Each partner has its own interconnect agreement, its own operational interface, its own BSS configuration, its own escalation path. The wholesale team manages each one individually.
At eight or ten partners, this model becomes a constraint. Each new partner requires new configuration work, new testing, new operational procedures. The operational cost of adding a partner is high and doesn't decrease with scale.
An MVNE architecture changes this. Partners are onboarded to a shared platform with standardised processes. SIM management, billing, interconnect and operational support run centrally. The tenth partner is materially cheaper to onboard than the third. The MNO's wholesale revenue scales without proportional operational cost growth.
This shift — from bilateral relationship management to platform-based enablement — is what separates MNO wholesale operations with three MVNO partners from those with twenty.
Decision comparison
| Dimension | Light MVNO | Enhanced MVNO | Full MVNO | MVNE operation |
|---|---|---|---|---|
| Time to market | 3–6 months | 6–12 months | 12–24 months | 9–18 months |
| Upfront investment | Low | Medium | High | High |
| Operational complexity | Low | Medium | High | High (shared) |
| Control over billing logic | Low | Medium | Full | Full |
| Access to subscriber data | Limited | Partial | Full | Full |
| Independence from host MNO | Low | Medium | Full | Medium |
| Ongoing operational cost | Low | Medium | High | Scales with partners |
| Long-term strategic optionality | Lower | Medium | High | High |
The right column depends on the specific intersection of control requirements, operational capacity, timeline and strategic intent. The table provides a comparison framework, not an answer.
Three mismatches and why they happened
The loyalty MVNO that chose full model. A retailer with a large customer base wanted to integrate mobile usage with points accrual at the individual transaction level. They assumed this required full MVNO — specifically, direct access to billing events in real-time. It didn't. An enhanced MVNO with a well-defined API layer between the billing platform and the loyalty engine would have provided the same integration. The project went 14 months over its original timeline.
The fintech that started light and got stuck. A digital bank launched through an established MVNE. Time to market was four months. Eighteen months later, they wanted dynamic data pricing based on account balance thresholds. The MVNE's billing platform didn't support the required product configuration. A migration to enhanced MVNO was necessary — not impossible, but it absorbed a full quarter of platform and operations capacity.
The MNO that managed each MVNO directly. A mid-sized operator had five MVNO partners. Each had its own operational interface, test environment and escalation path into the MNO's OSS. When a sixth partner signed, the wholesale team flagged a resourcing issue. The model that had worked at two partners had become a bottleneck at five. Transitioning to an MVNE architecture took 18 months — longer than any single MVNO onboarding — but significantly reduced the marginal cost of each new partner thereafter.
How Avante MVNx Suite addresses this
Avante MVNx Suite is designed to support multiple operating models within a single platform architecture — light MVNO, enhanced MVNO, full MVNO and MVNE. The platform's modular structure means organisations can start with the functional scope appropriate to their current model and extend it as requirements change, without migrating to a different platform. For MNO wholesale teams, the platform supports multi-tenant MVNE operation — enabling multiple MVNO partners through shared infrastructure while maintaining billing and operational separation between partners. Avante has deployed MVNx across more than 20 operator environments, covering multiple operating model configurations.
FAQ
Can a light MVNO convert to a full MVNO on the same platform?
It depends entirely on the platform's architecture. Modular platforms can extend their functional scope as requirements evolve — adding own HLR/HSS, migrating billing to a local instance, enabling additional network integrations. Platforms designed specifically for light MVNO reselling typically cannot support this extension. The question to ask during evaluation is not "can you support full MVNO?" but "if we start as a light MVNO, what is the specific migration path to enhanced or full MVNO, and has it been done in production on your platform?"
What is the main risk of choosing the wrong operating model?
Timeline and cost, in that order. An organisation that underestimates the control it needs will find gaps after launch and face either a capability constraint or a migration project at an operationally inconvenient time. An organisation that overestimates the control it needs will spend 12–24 months building infrastructure for capabilities it won't use, while a competitor with a 4-month time-to-market captures the available market.
How does the operating model choice affect platform vendor selection?
The operating model determines the functional scope the platform needs to support. A light MVNO project needs strong product configuration, customer management and API integration. A full MVNO project needs a billing and charging engine, HLR/HSS connectivity, and the operational tooling to manage network-layer functions. Starting vendor evaluation without model clarity typically means assessing vendors against requirements that haven't been properly defined — which produces an evaluation that doesn't distinguish between what matters and what doesn't.