At a Tier-2 MNO, Western Europe, ~18M subscribers, the wholesale team was reviewing an MVNO launch agreement just as the host’s BSS/OSS release calendar moved forward by two quarters. The commercial schedule described implementation milestones, but not who carried the cost, regulatory exposure or subscriber-impact risk when a core dependency changed. The missing instrument was a workable BSS/OSS change-control process before the programme reached scale.
The launch schedule concealed the real dependency chain
The immediate issue in the Western European programme was not whether the planned release could proceed. The host had already committed engineering resources and aligned the change with its wider platform roadmap. The unresolved question was whether the MVNO had a contractual right to defer the release, require additional testing, reject the change or recover the cost of adapting its own operating environment. The implementation schedule recorded dates. It did not allocate authority.
That omission matters because an MVNO dependency chain extends well beyond the branded front end. A host release can alter tariff configuration, OCS rating, SIM and eSIM profile handling, HLR and AuC data, MNP workflows, fraud controls, billing extracts, CRM interfaces and customer-care tooling. Any one of these can become release-sensitive. Several can fail together if a shared data model, API contract or provisioning sequence changes.
Early contracts often classify this as implementation detail. In practice, change control is a continuing allocation of operational authority across the host MNO, the MVNE and the MVNO. A requested change normally has an identifiable sponsor, a stated business purpose and a budget. A host-initiated change is different. It may be necessary for security, vendor support, regulation or platform consolidation, yet still impose material integration cost and service risk on a tenant that did not request it.
A Tier-2 head of wholesale recently observed: “The contract said we would maintain the platform. It did not say which party had to absorb the cost of maintaining a tenant through a platform migration.”
A workable clause therefore needs objective triggers rather than a general duty to cooperate. It should identify the impact threshold that invokes formal control, the affected service domains, the evidence required before production deployment, the feasibility of rollback, the applicable notice period and the person authorised to accept residual risk. It should also define a route for disagreement. Without one, a technical steering group can identify a material problem but remain unable to stop the release or assign its cost.
The Tier-2 MNO, Western Europe, ~18M subscribers case was representative rather than exceptional. The commercial tension emerged before any outage because the parties had priced the launch but not the continuing cost of platform evolution. Once engineering capacity, regulatory deadlines and customer communications were committed, the absence of decision rights became more consequential than the release defect the parties were trying to avoid.
Governance mechanics determine whether change control works
Formal change control is only useful if the parties can determine when it applies. Materiality should not depend solely on implementation cost. A change may be inexpensive to develop but material because it affects activation volumes, rating accuracy, number-porting performance, regulated data or the ability to reverse a failed deployment. Thresholds should combine financial exposure, subscriber count, service duration and regulatory consequence. They should also distinguish a local tenant configuration from a shared-platform release that affects several MVNOs.
Test evidence needs the same precision. A host may regard successful regression testing on the common platform as sufficient. The tenant may require evidence against its tariff catalogue, provisioning journeys, billing rules and care processes. The contract should identify the relevant environments, test-data responsibilities, entry and exit criteria, defect severity levels and the period allowed for review. Silence on these points tends to convert acceptance into a deadline rather than an engineering judgment.
Acceptance authority must sit with named operational roles, not an undefined project team. Architecture can confirm interface compatibility. Finance can validate rating and settlement outputs. Security and data-protection functions can assess control changes. The wholesale sponsor must decide whether the remaining commercial exposure is acceptable. Where approval is deemed after a period of silence, that period should begin only after the complete evidence pack has been delivered. Otherwise, the host can obtain contractual acceptance while material questions remain unanswered.
Rollback feasibility should be established before approval, including the last safe decision point and the ownership of reconciliation work. For changes that cannot be reversed cleanly, the parties need a staged deployment, restricted subscriber cohort or dual-running period. The cost of those controls should follow the cause of the change and the benefit it creates. Treating every mitigation measure as chargeable tenant work gives the host little economic incentive to reduce migration risk.
Escalation also needs a clock. An operational dispute should move from delivery leads to accountable executives within defined periods, with an interim rule for production deployment. Security or regulatory changes may justify host action before full agreement, but emergency rights should be narrow, evidenced and followed by retrospective review. For ordinary roadmap changes, the default should preserve the last accepted state until the designated authority approves a departure from it.
Liability and exit terms decide whether a programme can survive scale
Liability provisions should follow the dependency map. Aggregate caps are commonly negotiated as a percentage or multiple of annual charges, but annual charges are not a reliable proxy for operational loss. A prolonged provisioning or rating failure can produce churn, manual remediation, regulatory investigation, wholesale settlement disputes and brand damage. The party controlling the failed process may face a modest contractual exposure while the tenant carries the larger subscriber and revenue consequence.
Ordinary service credits can address short-duration performance misses. They are less suited to persistent failure to provision, material MNP breakdown, loss or corruption of subscriber data, unlawful processing, fraud-control failure or refusal to provide agreed transition support. These events require separate treatment because their effect is not captured by a monthly availability calculation. The remedy may need to include remediation costs, regulatory cooperation, data reconstruction and funded migration support.
Carve-outs from the liability cap require discipline on both sides. Broad exclusions can make a negotiated cap commercially illusory and difficult for the host to price. Narrow exclusions can leave the MVNO exposed where the host controls the relevant BSS/OSS or network process. The drafting should connect each exception to conduct, control and measurable consequence. It should not rely on a long list of loss categories detached from the operating model.
Exit terms expose the same dependency problem. Before scale, the parties should establish ownership and access rights for subscriber data, number ranges, IMSI allocations where relevant, eSIM profile continuity, tariff records, billing history and the interfaces required to move operations to another MVNE or host MNO. Legal ownership alone is insufficient if the data cannot be extracted in a usable format, reconciled to the active base or supplied within the migration window.
A Greenfield MVNO, post-2023, multi-IMSI stack faced this issue while reviewing its initial host terms. Its architecture reduced dependence on a single serving network, but the commercial exit language still assumed that generic data exports and reasonable assistance would support migration. They would not. Profile status, routing policy, charging history and porting state had to remain aligned across multiple systems. The architecture created options, but only an executable transition schedule could make those options usable.
That schedule should specify system access, extraction frequency, data formats, validation responsibilities, migration testing, support staffing, transition charges and cutover governance. It should state how service incidents are managed during dual running and how post-cutover records are reconciled. It should also address stranded minimum commitments. An exit mechanism that requires the departing MVNO to pay the full remaining minimum while also funding migration may be legally clear but operationally unusable.
The commercial asymmetry is straightforward. A host MNO may regard an MVNO exit as a low-probability exception within a larger wholesale portfolio. The MVNO must regard the same event as a solvency and service-continuity scenario. Both parties benefit from pricing it before subscriber scale creates negotiating pressure. The host gains a bounded support obligation and recoverable transition charges. The tenant gains a credible route to preserve service, data and regulatory compliance.
Wholesale contracting should treat platform change and exit as operating conditions, not legal backstops. As an MVNO base grows, the value of precise approval rights, bounded liability and tested transition obligations rises faster than the cost of negotiating them at launch. The difficult disputes rarely begin with an outage. They begin when a necessary platform change reveals that neither party agreed who could decide, who would pay or how the service would continue if agreement failed.