Skip to main content

Why MVNO Unit Economics Break at Scale — and What Platform Architecture Has to Do With It

A mid-sized MVNO reached 400,000 prepaid subscribers and something unexpected happened: margin per subscriber started falling, despite a recently renegotiated wholesale rate with the host MNO. The finance director couldn't explain it. The wholesale rate had improved. ARPU was stable. But the unit economics were worse.

The problem, when they found it, was in the billing platform. The system was rating data usage against subscriber balances in near-real-time — but not quite real-time. There was a 90-second polling window. On average, each affected subscriber consumed around €1.80 in unrecoverable data during that window before the session was terminated. Not every subscriber triggered this condition, but enough did that at 400,000 subscribers, the monthly leakage was material. And because it showed up as slightly lower revenue per subscriber rather than as a specific error event, it had been invisible in standard reporting for months.

This is a predictable story. It plays out repeatedly across MVNOs at scale, for a simple reason: billing architecture is a cost-structure decision, not a feature decision. Most organisations evaluate it as the latter.

The wholesale rate is not the whole story

Negotiating the host MNO rate — per gigabyte, per-minute termination, SMS interconnect — gets most of the attention at launch. Rightly so: it is the largest single component of cost of goods sold.

The problem is that wholesale rates are fixed between renewals. Operational costs driven by platform architecture accumulate continuously and compound with subscriber growth. By the time an MVNO is at several hundred thousand subscribers, operational cost efficiency matters at least as much as the wholesale deal.

The platform-related cost drivers that tend to be underestimated at launch: revenue leakage from billing latency, exception handling volume, roaming reconciliation gaps, and the cost of running separate billing systems as the product range expands.

Real-time charging: the risk is in the window

Prepaid billing requires a fundamental architectural choice: does the platform rate usage in real-time — deducting from the subscriber's balance as sessions progress — or does it rate in batches at intervals?

Batch billing is simpler and cheaper to operate at low volumes. Real-time charging needs a rating engine that processes usage as it flows, queries and updates balance records continuously, and terminates sessions the moment a balance is exhausted. The infrastructure cost is higher. The operational result is that the window in which a subscriber can consume services beyond their available balance approaches zero.

That window matters. For a video streaming session, 90 seconds of uninterrupted consumption represents roughly 80–100 MB at standard SD quality. At €0.012 per MB — a common prepaid data rate in mid-market MVNOs — that is approximately €1.00–€1.20 per event. At scale, the arithmetic is not forgiving.

What makes this worse is that the subscribers most likely to trigger the condition are high-usage subscribers — the ones worth retaining. Revenue assurance tools can identify the pattern. They cannot recover the revenue. The only fix is architectural.

Roaming reconciliation: the deferred cost problem

When a prepaid subscriber uses data while roaming, the MVNO incurs the cost immediately. Clearing records from the international roaming hub arrive 24–48 hours later.

Real-time roaming charging — where the MVNO maintains a live signaling connection back through the host MNO's network — closes that gap. Without it, the MVNO carries un-billed cost exposure for every active roaming session.

For postpaid subscribers, the delay is mostly a cash flow issue: the cost gets recovered at month-end billing. For prepaid subscribers, it is a potential write-off. If the subscriber's balance is gone by the time the clearing records arrive, the roaming cost cannot be recovered. The subscriber received value the MVNO paid for.

At low roaming volumes this is manageable. For MVNOs serving business travellers, diaspora communities, or dual-SIM users, it becomes a predictable margin drain at scale.

Exception handling: the invisible headcount cost

Every billing platform generates exceptions — subscriber lifecycle events that don't resolve cleanly. A subscriber who ports out with an active data session. A plan change that triggers mid-cycle proration applied differently than the product catalogue specifies. A bundle re-enrolment that creates a duplicate active plan.

On a well-architected platform, most of these are resolved automatically through defined state transitions and event-driven logic. On a platform with gaps in lifecycle management, they become a queue of manual work items — reviewed and corrected by an operations team.

That team costs money. It doesn't appear in the platform licensing fee. At 10,000 subscribers, an exception rate of 0.5% generates 50 items per month. Manageable. At 500,000 subscribers, the same rate generates 2,500 items per month. That is a real operations function, and it scales directly with subscriber growth.

The platform architecture determines whether that cost is fixed (automated resolution) or variable (headcount).

Convergent billing: the question to ask before you need it

Many MVNOs launch with one billing model — prepaid only, or postpaid only. This is rational at launch. The problem comes when the product range expands.

A prepaid-only MVNO that adds postpaid family plans, IoT SIMs for enterprise clients, or wholesale plans for resellers faces a choice: extend a platform that may not support it, run parallel billing systems for different product lines, or migrate to a new platform. None of these options is cheap or fast.

A convergent billing engine — one that handles prepaid, postpaid and hybrid models within a single rating architecture — removes that fork. Not a feature that matters on day one. A feature that determines whether the organisation can execute its product roadmap without rebuilding billing infrastructure in two years.

The right question during platform evaluation is not "does it support prepaid?" but "if a subscriber moves between prepaid and postpaid plans, does that happen in one system, and how does mid-cycle proration work?"

The compounding effect

Each of the cost drivers above is modest at launch. That is exactly why they tend to get accepted.

They do not stay modest. Exception handling scales linearly with subscriber growth. Real-time charging gaps scale with usage intensity. Roaming exposure scales as the subscriber mix changes. An organisation that accepts a billing architecture with these gaps — because the platform was cheaper, faster to deploy, or simpler to operate at low volumes — is making a rational short-term decision. It is also making the problem hardest to fix at the worst possible time: when subscriber volumes are high, migration is disruptive, and the finance team wants to know why the unit economics don't match the original model.

What to evaluate in a billing platform

These questions surface architectural differences rather than feature differences:

  • Does the charging engine process usage events in real-time, or in batches? What is the maximum latency between usage and balance deduction?
  • How does the platform handle roaming data charging? Is there a real-time signaling connection to the host network, or does it rely on clearing record reconciliation?
  • Which lifecycle events are resolved automatically, and which require manual intervention?
  • Does the platform support convergent billing — prepaid, postpaid and hybrid — within a single rating engine, or are these separate systems?
  • How does the platform handle mid-cycle plan changes? Can the proration logic be configured by product?

A vendor that has deployed in production at scale will answer these questions specifically. One that hasn't will describe capabilities.

How Avante MVNx Suite addresses this

Avante MVNx Suite includes a real-time charging engine that handles prepaid, postpaid and convergent billing within a single architecture. The platform supports real-time balance management for prepaid subscribers and is designed to handle roaming charging through live signaling integration where the host MNO supports it. Subscriber lifecycle events — plan changes, port-outs, bundle re-enrolments — are managed through event-driven logic that reduces manual exception handling at scale. Avante has deployed MVNx in more than 20 operator environments, including markets with high prepaid penetration and significant roaming usage.

FAQ

What is the main cause of revenue leakage in MVNO billing?

The most common cause is a gap between when usage occurs and when it is rated against the subscriber's balance. In prepaid billing, this creates a window in which services can be consumed beyond the available balance. The size of that window depends on whether the charging engine processes usage events in real-time or in batches — and how that choice was made when the platform was selected.

What is convergent billing and why does it matter for MVNOs?

Convergent billing means handling prepaid and postpaid within a single rating and charging engine rather than separate systems. It matters when the product range expands — which most MVNOs find it does within two to three years of launch. Without a convergent architecture, adding a second billing model requires either extending a system that may not support it or running parallel billing platforms with all the data integrity risk that implies.

How does billing architecture affect MVNO operational costs?

Platforms that resolve lifecycle events automatically reduce the volume of manual exception work. Platforms that don't require operations staff to handle exceptions by hand — a cost that scales directly with subscriber growth. The billing platform licence fee and the operations headcount cost are not independent figures. The first significantly determines the second.

Contact Us

Fill in this form and our experts will contact you shortly.
I agree with the Privacy Policy