MVNO BSS Development: Why Your Real Margin Only Appears After Someone Reconciles the Host Operator by Hand

Why MVNO economics hide inside a reconciliation nobody owns

The MVNO story that gets told is about brand and distribution. The story that decides whether the business survives is a spreadsheet somebody opens on the eighth of the month, when the host operator's wholesale invoice and usage detail land. On one side sits what the host says you consumed: data volumes by APN, voice minutes by destination band, SMS counts, and a set of line items for things your commercial team negotiated but nobody encoded anywhere, such as a pooled data allowance across the base, a per-active-SIM access fee, or a step discount that only applies once you cross a volume threshold in the quarter. On the other side sits what you charged retail. The gap between those two numbers is the entire business, and it is being computed by hand.

That reconciliation is not a finance chore. It is the only place your unit economics exist. Until it is done, nobody in the company knows whether the new 30GB plan is profitable, whether the roaming bundle is bleeding, or whether the wholesale rate you renegotiated last quarter is actually being applied. So pricing decisions run a month behind reality, and marketing launches promotions against numbers that were true in a previous billing cycle.

The second problem is that the reconciliation is one person. In every MVNO we have worked with, there is a single analyst who understands the host's file format, knows which rate card version applies to which date range, and remembers the manual adjustment that has to be applied because the host bills a rounding convention different from the one in the contract. When that person is unavailable, the close slips. When they leave, the company loses the ability to answer its most important question.

Problem 1: the host operator's usage feed is not a rating engine

What arrives from the host is wholesale cost data, formatted for the host's convenience. It is usually a CDR or TAP-style feed, delivered on the host's schedule, with the host's own identifiers, aggregation windows and late-arriving corrections. Records for the same subscriber can arrive days apart. Roaming records arrive later still, because they route through clearing before your host passes them on.

Your retail rating has to run on a different clock. A subscriber checks their remaining data in the app and expects it to be right now, not right as of the last host file. That means you need a real-time or near-real-time usage counter fed by whatever notification path your host offers, reconciled later against the authoritative billing feed, with a documented policy for what happens when the two disagree. MATRIXX and Optiva are genuinely strong at exactly this convergent, real-time rating problem, and if you are large enough to afford them and generic enough to fit them, they are a serious option. Comarch and Nexign bring full carrier-grade BSS suites with the same trade-off: they encode a large operator's assumptions, and configuring them into your shape is a systems integration programme, not a settings screen.

What a custom build does: model the wholesale side and the retail side as two separate ledgers over the same subscriber and the same time window, and treat reconciliation as a first-class scheduled process rather than an export. Every host record is ingested with its own arrival timestamp and its own rate card version, so a correction that lands on the twelfth for usage on the second is applied to the second and the delta is visible. Every retail charge carries the rating rule and rule version that produced it. Then the margin query is a join, not a spreadsheet, and it can be run on any day of the month rather than after the close.

Problem 2: your retail proposition is the product, and templates fight it

MVNOs win on a proposition the host cannot or will not offer. Data that rolls over indefinitely. A family pool where the parent controls per-line caps. A diaspora plan with unlimited calls to three specific countries and a hard cap elsewhere. A prepaid product with top-up bonuses that expire on a schedule. An enterprise product where the account, not the SIM, is the billing subject and the finance director wants a single invoice with cost centre breakdown.

Every one of those is a modelling decision made at the level of the charging engine, not at the level of a plan configuration form. Ask a packaged BSS to represent rollover data with a per-tranche expiry and a consumption order, and you either find it supports the shape you want or you discover that supporting it means a customisation ticket with the vendor and a release train you do not control. That is the real cost of buying: not the licence, the latency between having a commercial idea and being able to sell it.

What a custom build does: make the product catalogue a modelled object with allowances, counters, consumption precedence, expiry rules and eligibility conditions as data, so a product manager can compose a new plan and simulate it against last month's actual usage before it goes live. Simulation is the difference between launching a bundle and knowing what it will cost you at your current traffic mix.

Problem 3: SIM and eSIM stock is a logistics business you did not plan for

Physical SIMs arrive from a vendor in batches with ICCID ranges, get allocated to retail partners or fulfilment, and then sit in states that need tracking: manufactured, allocated, shipped, sold, activated, suspended, reclaimed. eSIM adds a parallel inventory of profiles held on an SM-DP+ with their own activation codes and download states. Most launches treat this as a spreadsheet plus the SIM vendor's portal, and it works until the first time a retail partner reports a batch stolen, or a customer says the QR code was already used.

Then porting arrives on top. A subscriber bringing a number in wants their old service to keep working until the port completes, and wants the new SIM to activate the moment it does. That is a state machine spanning your system, the host's provisioning API, and a porting process with regulated timers. When it fails, the customer has no phone service, and that is the single most expensive support event an MVNO generates.

What a custom build does: hold SIM and eSIM inventory in one model with an explicit state machine and an audit trail on every transition, wire activation and porting into that same state machine rather than as separate flows, and give care agents a single screen that shows the subscriber, the SIM or 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. Collapsing that is one of the fastest measurable wins in the whole build.

Problem 4: care and dunning decide your churn, and both run on the same record

Prepaid MVNOs churn on top-up friction. Postpaid MVNOs churn on billing disputes. Both are the same underlying problem: the agent on the phone cannot see why the charge happened. If your rating engine cannot explain a line item back to the usage records and the rule that priced it, every dispute becomes a goodwill credit, and goodwill credits are pure margin loss on a business whose margin is already thin.

Build the explainability in from the start. Each invoice line links to the rated events, and each rated event links to the source host record and the catalogue rule version. An agent should be able to answer why a customer was charged for data on the fourteenth in one click. Dunning then hangs off the same record: a policy engine that suspends, restricts to a captive portal, or barred-outbound-only, based on rules you can change without a deployment, because collections policy changes more often than software does.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, the honest shape is this. A launch-ready BSS core, meaning subscriber lifecycle, catalogue and rating, SIM and eSIM inventory with provisioning against one host, porting orchestration, invoicing or top-up, and a care console, runs $90,000 to $200,000 across 14 to 22 weeks. A full platform adding a branded self-service app, a second host operator, dealer and reseller hierarchies with commission, dunning automation, and wholesale margin reporting runs $250,000 to $600,000 phased across 9 to 15 months.

What drives price up in this category specifically: the number of host operators, because each one is a fresh integration against different provisioning APIs and a different usage file dialect, and the second host is where a naive data model breaks. Prepaid real-time control, if your host offers it, because that means integrating charging in the signalling path rather than batch. Roaming, because clearing introduces late records and disputes. Regulatory obligations in your market, which vary enormously and should be scoped with counsel before engineering. And the commercial construct in your host agreement, which is genuinely the hardest thing to price sight unseen.

What keeps price down: launching with one host, one SIM form factor, and three plans. You will learn more from three plans in market than from thirty in a spec.

Build versus buy, and when buying is right

Buy if you are testing a market. A full-stack MVNE such as Effortel or Transatel gives you connectivity, BSS 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, that is the correct decision and we will say so.

Build when at least two of the following describe you. Your differentiation is a plan structure the packaged platforms do not represent natively. You are running or planning more than one host operator, including a multi-country footprint. Your subscriber base is past roughly 50,000 and the per-subscriber platform fee has become a visible line in your P&L. You sell through dealers or enterprise accounts where the billing subject is not the SIM. Or your reconciliation currently takes more than three working days and depends on one person.

The tipping point is control over time-to-market. An MVNO's only durable advantage is moving faster on proposition than the host can. If every pricing idea has to queue behind a vendor release, that advantage is gone and you are just a reseller.

How to choose a developer for MVNO platform work

Ask them to model your wholesale schedule on a whiteboard before contract. Someone who has done this will immediately ask whether the pooled allowance is calculated across active SIMs or provisioned SIMs, how mid-cycle plan changes prorate against the wholesale side, and what happens to a late-arriving roaming record after the retail invoice has issued. Someone who has not will draw customers and plans and start talking about a dashboard.

Ask what they have integrated against. A host provisioning API, an SM-DP+ for eSIM, a payment gateway with stored credentials and retry logic for failed recurring charges, and a porting counterparty are four different classes of problem. Ask for the specific host and the specific interface, not a claim about telecom experience.

Ask how they handle rate card versioning and retroactive corrections, because that single design decision determines whether your finance team trusts the system in year two. If the answer does not include effective-dated rates and immutable rated events, keep looking.

Ask who owns the code, the repository and the cloud accounts, and get it in writing before kickoff. At Digital Heroes the client keeps the repository and cloud accounts from day one. In a business where your platform is your margin control, a developer who wants to hold the keys is selling you a dependency. Send us your host agreement's commercial schedule and your target plan structure, and we will come back with a scoped first release rather than a brochure.