MVNO Platform Problems: The 7 That Eat Your Wholesale Margin, and How to Avoid Them

Why does the launch scope quietly become a full carrier BSS?

The brief starts as a launch: three plans, one host, physical SIM, a care console. Then commercial asks for a family pool because that is the proposition. Finance asks for dunning because collections policy exists. Distribution asks for dealer commission because that is how the SIMs get sold. Someone mentions enterprise accounts, which changes the billing subject from the SIM to the account. Each request is reasonable and each one lands in the charging engine rather than in a settings screen.

The reason this happens specifically to MVNOs is that the whole point of the business is a proposition the host will not offer, so nobody wants to be the person who says the differentiator waits for release two. Six weeks of discovery turns a $90,000 to $200,000 launch core into the $250,000 to $600,000 full platform, and now you are 9 to 15 months from taking a subscriber.

The discipline that works is to launch with one host, one SIM form factor and three plans, and to say plainly that you will learn more from three plans in market than from thirty in a specification. What must be in release one is the shape of the data model, not the breadth of the catalogue: effective dated rates, immutable rated events, and a subscriber record that does not assume a single host. Those are the things that cannot be retrofitted. A fourth plan can be added on a Tuesday.

What goes wrong when you migrate subscribers and usage history off an MVNE?

Most MVNOs that build have already launched on an MVNE such as Effortel or Transatel and outgrown it, so the build starts with a migration under live traffic. Three things break in that migration and none of them are code.

The first is that the MVNE's subscriber record is shaped around their platform, so balances, bundle remainders and allowance expiry dates do not map cleanly onto your model. A prepaid subscriber with 4.2GB remaining and a bonus tranche expiring on the nineteenth has to arrive on the new system with both facts intact, or your first week of operation generates disputes you cannot answer.

The second is usage history. You need enough of it to explain past invoices when a customer queries them, and to compute your own margin trend, but the MVNE holds it in their format with their identifiers. Agree the extract format, the retention period and the cost in writing before you give notice, not after.

The third is the host relationship. If the MVNE holds the host agreement, migrating means renegotiating with the host directly, and the commercial schedule you end up with may differ from the one your build was designed against. Start that conversation before engineering, because the wholesale constructs in the agreement are the thing the system has to model.

Why do the host provisioning, eSIM and payment integrations break after launch?

Host provisioning breaks around state, not connectivity. Your system asks the host to activate a SIM, the host accepts, and then a downstream step in their network fails or lags. If your model treats the API response as the truth, you have a subscriber marked active who has no service, and a care agent with no way to see the difference. The design that survives holds the host response and the observed state separately and reconciles them, with a queue for divergence.

eSIM breaks around consumption. A profile on an SM-DP+ has its own download state, and the failure modes are unfamiliar: a QR code used on the wrong device, a download that started and never completed, a profile deleted by a customer who then wants it back. Each of those is a support call with an angry customer and no phone service, and each needs an explicit path rather than a manual intervention.

Payments break on recurring charges. Stored credentials expire, issuers decline, and retry logic that is too aggressive triggers fraud controls while retry logic that is too passive loses revenue. This is ordinary engineering, and it is routinely underscoped because it looks like a checkout.

The fix is to require named interfaces and named failure paths in the statement of work: this host, this provisioning method, this SM-DP+, this gateway, and what the care agent sees when each one disagrees with reality.

What happens when rate card versioning and retroactive corrections are not covered?

This is the failure that quietly destroys trust in the system. The host bills on its own schedule with its own aggregation windows, and it sends corrections. Roaming arrives late because it clears first. If your rated events are mutable and your rates are stored as current values, a correction landing on the twelfth for usage on the second gets priced at today's card, the delta disappears, and the wholesale ledger drifts from the host invoice by an amount nobody can explain.

The design that holds is effective dated rate cards, immutable rated events that carry the rule and rule version that priced them, and every host record ingested with its own arrival timestamp alongside the usage timestamp. Then a late correction is applied to the day it belongs to and the difference is a visible number rather than an absence.

The same property gives you the other thing you need, which is explainability. An agent handling a billing dispute should be able to click an invoice line, see the rated events behind it, and see the source host record and catalogue version. Without that, every dispute becomes a goodwill credit, and goodwill credits are pure margin loss in a business whose margin is already thin.

Should you build custom or configure what you already own?

If you are testing a market, buy. A full stack MVNE such as Effortel or Transatel gives you connectivity, business support systems and often the host relationship in one contract, and you can be live in months without an engineering team. The trade is revenue share and a proposition constrained to what their platform models. For a brand extension launching one simple plan to an existing audience, under roughly 20,000 expected subscribers, that is the correct decision and we say so.

If your problem is real time charging depth rather than proposition flexibility, look at MATRIXX or Optiva before you build. They are genuinely strong at convergent real time rating, and if you are large enough to afford them and generic enough to fit them, buying that engine is sensible. Comarch and Nexign bring full carrier grade suites with the same caveat: they encode a large operator's assumptions, and configuring them into your shape is a systems integration programme rather than a settings screen.

Build when two or more of these are true. Your differentiation is a plan structure no packaged platform represents natively. You are running or planning more than one host, including multi country. Your base is past roughly 50,000 and the per subscriber platform fee is a visible line in your profit and loss. You sell through dealers or enterprise accounts where the billing subject is not the SIM. Or your reconciliation takes more than three working days and depends on one person.

How do hidden costs get into the quote?

The first hidden cost is the second host operator. Systems built against one host tend to embed that host's identifiers, rate structure and provisioning semantics into the subscriber record, so adding a second means touching almost everything. If multi host or multi country is anywhere in your two year plan, say so during discovery even if you are launching with one, because designing for two costs modestly more now and saves a rewrite later.

The second is real time control. If your host exposes charging in the signalling path and you want genuine live balances, that is integration into a network path rather than a batch feed, and it is a different class of work. Quotes that promise real time balances without asking what the host exposes have not read your agreement.

The third is roaming. Clearing introduces late records, disputes and a settlement process, and every one of those is scope.

The fourth is regulatory obligation in your market, which varies enormously and should be scoped with counsel before engineering rather than discovered during certification. And the fifth is prepaid. Retrofitting prepaid balances and control policy into a postpaid only data model is one of the more expensive rewrites in this category, so if both are in your future, model both from the start even if you launch with one.

What separates an MVNO build that works from one that fails?

The first separator is whether the developer asks about your wholesale schedule before your screens. Someone who has done this will immediately want to know whether a pooled allowance is calculated across active or provisioned SIMs, how a mid cycle plan change prorates on the wholesale side, and what happens to a late roaming record after the retail invoice has issued. Someone who has not will draw customers and plans and start talking about a dashboard.

The second is effective dated rates and immutable rated events. If that is not in the answer when you ask about corrections, finance will not trust the system in year two and the spreadsheet will come back.

The third is one screen for care. An agent should see the subscriber, the SIM or eSIM profile, the port request state, the host provisioning response and the last usage record together. Agents currently move between four browser tabs to answer one question, and collapsing that is the fastest measurable win in the whole build.

The fourth is simulation. A product manager should be able to compose a plan and run it against last month's actual usage before launch, which is the difference between launching a bundle and knowing what it costs.

The last is ownership. The platform is the mechanism that controls your margin. At Digital Heroes the client keeps the repository, the cloud accounts and the host integration work from the first commit, because a developer who wants to hold those keys is selling you the dependency you left the MVNE to escape.