Table of Contents
MVNO Billing Modernization: Fixing BSS for eSIM and IoT
A regional MVNO launches an eSIM bundle for a connected-fleet client. The provisioning API can’t activate it. The rating engine can’t apply per-device usage pricing in real time. Sales already sold the plan to three enterprise accounts, and now support is fielding the fallout.
That failure is a symptom, not a vendor problem. The back-office was built for physical SIMs. MVNO billing modernization fixes it without a full platform rebuild: extract the specific functions, real-time charging, mediation, and provisioning, that eSIM and IoT actually stress, and rebuild them as cloud-native services while the rest of the platform keeps billing customers.
Quick answer: modernizing MVNO billing safely
- Legacy BSS platforms built for physical SIMs can’t provision eSIM activations or rate IoT usage bundles in real time.
- The fix isn’t a full rebuild or a new MVNE. Extract charging, mediation, and provisioning into cloud-native services one piece at a time.
- This strangler-pattern approach keeps you billing customers through the whole migration; you route traffic over only once each new service is proven.
- AI-augmented delivery rebuilds rating and mediation logic faster, with higher test coverage, than a traditional in-house rebuild.
- Full documentation transfer means you own the modernized system, instead of trading one black-box MVNE dependency for another.
A side-by-side view of a physical-SIM-era BSS next to the cloud-native charging, mediation, and provisioning layer that replaces it piece by piece.
The eSIM/IoT Bundle Your Back-Office Can’t Provision or Rate
The provisioning request needs SGP.32 remote SIM profile management, an over-the-air handshake most physical-SIM-era provisioning modules were never built to perform. The rating engine needs to price data by the megabyte, per connected device, close to real time, not batch-rate a monthly bucket overnight. Both requirements hit a BSS designed around a different problem entirely: activate a physical card, meter voice and SMS, run one nightly rating batch.
Nexa has spent years inside an MVNO’s operations, including a carrier scaling its connectivity products well beyond what its original systems were sized to support. We have watched this play out more than once. The failure never shows up in a demo; it surfaces about three weeks after launch, when volume hits the provisioning queue and support tickets pile up faster than anyone can clear them by hand.
Built for Physical SIMs: Why the 2026 Product Mix Breaks Legacy BSS
Your BSS wasn’t broken when it shipped. It was built for a world where every SIM arrived as a physical card, activation took days, and usage meant voice minutes plus a monthly data bucket. eSIM readiness wasn’t part of the original spec, and neither was per-device IoT metering. That world is mostly gone.
eSIM, SGP.32 and remote provisioning at scale
For MVNOs, eSIM has already moved from a future trend to the current sales motion. According to GSMA Intelligence’s Mobile Economy 2026 report, eSIM-enabled smartphone connections are forecast to reach roughly 2.5 billion globally by 2028, with eSIM expected to account for 42% of all SIM technologies by 2030. That shift underpins broader 5G monetization strategies industry-wide too, not just eSIM logistics. Every one of those connections needs SGP.32 provisioning: instant, over-the-air profile downloads instead of a physical card mailed to a customer.
A provisioning module built around physical logistics fails quietly. It queues requests, batches what should be instant, and lets a backlog grow between the moment a customer buys a plan and the moment their device actually connects.
IoT and usage-based bundles the rating engine never anticipated
IoT connectivity billing multiplies the problem. A fleet-tracking device, a smart meter, and a connected vending machine don’t generate a predictable monthly usage pattern the way a phone plan does. They need metered, usage-based billing that rates small, frequent transactions accurately, close to real time, across potentially thousands of devices per customer account.
Grand View Research puts the U.S. MVNO market at roughly $30 billion in 2024, on pace to exceed $52.9 billion by 2032. Growth like that is coming disproportionately from IoT and connected-device plans, not traditional consumer mobile. A rating engine tuned for human subscriber behavior was never built for that shape of demand.
How an SGP.32-based eSIM activation request flows through provisioning, the product catalog, and the rating engine in real time.
What MVNO Billing Modernization Must Actually Do: Real-Time Charging, Mediation, Provisioning
Three capabilities separate a BSS that can handle the 2026 product mix from one that can’t: real-time charging, clean CDR mediation, and provisioning tied to a flexible product catalog. Everything else is implementation detail.
Real-time / convergent charging and rating
Convergent charging means one real-time rating engine handles voice, data, SMS, and IoT usage together, instead of running separate batch processes for each product line. A customer on a hybrid plan, unlimited voice plus metered IoT data for a connected device, needs a single rated bill, not three systems reconciled after the fact.
Mediation and the CDR pipeline
Mediation takes raw call detail records from the network and turns them into something the charging engine can actually rate: normalized, deduplicated, and matched to the right product and customer. When eSIM and IoT triple the volume and variety of CDRs flowing through that pipeline, a mediation layer sized for a smaller, more uniform dataset starts dropping or misrouting records it was never designed to parse.
Automated provisioning and the product catalog
Provisioning has to talk directly to the charging engine and the product catalog, not sit in a separate queue waiting for someone to reconcile them by hand. SIM provisioning automation means the product catalog defines a new bundle once, with provisioning, rating, and mediation all reading from that same definition instantly, not three weeks later after someone updates each system separately.
The Hidden Cost: CDR Mediation Lag and the Revenue You’re Not Auditing
Every rejected CDR is unbilled usage. Every hour of mediation lag is a delayed invoice and a slower fraud signal. Neither shows up on a dashboard until finance asks why margin is shrinking.
This is the cost nobody puts in a modernization business case, because it doesn’t look like a system failure. The BSS is up. Customers are getting bills. But a rating engine that can’t process eSIM and IoT usage in real time does something worse than slow down. It drops or misprices a share of usage records it can’t parse correctly, and that’s where revenue assurance breaks down quietly, cycle after cycle, at a scale that compounds fast for an MVNO.
A bigger dashboard won’t surface this; an audit will. Pull your CDR rejection rate and average mediation lag for the last three billing cycles, and compare them against what your current product catalog actually needs to support. If nobody on your team can produce that number quickly, that’s the real finding. For a deeper look at how legacy platforms accumulate costs that never show up on a single invoice, see why legacy platforms quietly cost more every quarter.
Rip-and-Replace vs. the Strangler Pattern: Modernizing BSS Without Going Dark
A full BSS rebuild sounds clean on a slide deck. It also asks you to stop billing customers for the length of the migration, which is the one thing an MVNO can never actually do.
Extract charging, mediation and provisioning into cloud-native microservices
The strangler pattern, a term coined for exactly this kind of incremental legacy replacement, works by pulling one function out of the legacy platform at a time and standing it up as an independent, API-driven service. Charging comes first, since it’s the function most stressed by eSIM and IoT. Mediation and provisioning follow, each built and tested against real production traffic before either takes over anything. A cloud-native BSS/OSS emerges service by service this way, never in one all-at-once cutover.
How the strangler pattern extracts charging, mediation, and provisioning from a legacy BSS one proven service at a time.
Route traffic over once each service is proven, decommission legacy last
Each new service runs in parallel with its legacy counterpart, processing a shadow copy of live traffic, before any real customer data routes through it. Once the results match, and keep matching under real volume, you cut over. The legacy component that handled that function gets decommissioned only after its replacement has proven itself, never before.
Why a big-bang rebuild risks the one thing you can’t stop: billing customers
A rewrite-everything-at-once project has one massive cutover date, and everything downstream of it, invoicing, collections, regulatory reporting, depends on that single event going perfectly. Delay it and you’re running two systems in parallel anyway, just without a plan for it. The strangler pattern gets you the same architectural outcome without betting the business on one weekend.
A big-bang rebuild is almost never the right call for an operator who can’t stop billing. It sounds more impressive in a boardroom and survives contact with production far less often.
Build vs. Buy, Revisited: Why Another MVNE Isn’t the Fix
Moving to a new MVNE feels like progress. Usually it’s a lateral move: you trade the black box you understand for one you don’t, and you still don’t own the platform running your revenue.
As Ashwin Ballal, CIO at Freshworks, states: “Legacy systems have become so complex that companies are increasingly turning to third-party vendors and consultants for help, but the problem is that, more often than not, organizations are trading one subpar legacy system for another. Adding vendors and consultants often compounds the problem, bringing in new layers of complexity rather than resolving the old ones.”
None of this rules out ever using an MVNE. It rules out treating a vendor swap as modernization. An MVNE can get a new operator to market fast. It doesn’t solve the ownership problem for an operator who already has years of customer data, billing history, and operational process built into an existing platform.
Legacy integration, including legacy BSS 5G integration specifically, is a widely shared problem, not a telecom-specific one. Deloitte’s 2025 analysis found that nearly 60% of AI leaders name legacy-system integration as their primary modernization barrier. Swapping one closed platform for another leaves that barrier fully in place; all it changes is who controls it.
Owning the Modernized System: AI-Augmented Delivery and Full Documentation Transfer
The goal of modernization was never a newer platform for its own sake. What you actually want is an operator who understands, controls, and can extend the system running their own revenue, without calling a vendor for permission first.
Rebuilding rating/mediation logic faster and with higher test coverage
Rewriting rating and mediation logic by hand, function by function, is exactly the kind of work AI-augmented delivery speeds up without cutting corners, generating test cases alongside the new charging service and catching CDR-parsing edge cases a rushed manual QA pass might miss. According to HFS Research’s 2026 analysis, agentic AI-augmented modernization delivers 40 to 60% productivity gains and cuts migration timelines by 30 to 50% compared with traditional approaches. Applied to a strangler-pattern migration, that’s the difference between a modernization that takes a year per component and one that takes a quarter.
The documentation package handed to the operator at the end of a modernization engagement: architecture diagrams, API references, and test coverage reports.
Documentation transfer so the operator owns the system, not the vendor
Every extracted service comes with architecture diagrams, API references, and test coverage reports, transferred to the operator unconditionally, whether or not the engagement continues afterward. Documentation transfer is what separates modernizing a system you own from quietly re-creating the MVNE dependency you were trying to escape in the first place. how documentation transfer works walks through what a complete handoff actually includes.
Your BSS doesn’t need a funeral. It needs the three or four functions that eSIM and IoT are stressing pulled out, rebuilt cloud-native, and proven before anything gets decommissioned. That’s the modernization path that keeps you billing customers on day one and owning your system on the last day of the project too.
If you want a clearer picture of where the strangler pattern applies first inside your own BSS, talk to our team about mapping your charging, mediation, and provisioning stack before you commit to any rebuild.
FAQ
What is MVNO billing modernization?
MVNO billing modernization means upgrading the charging, mediation, and provisioning logic inside your BSS to support real-time rating, eSIM activation, and IoT usage-based billing, typically without replacing the entire platform at once.
How does the strangler pattern work for BSS modernization?
The strangler pattern extracts one function at a time, like charging or provisioning, into a new cloud-native service running alongside the legacy BSS. You route traffic over once it’s proven, then repeat until the old platform is retired.
Why can’t legacy BSS platforms support eSIM provisioning?
Most legacy BSS platforms were architected around physical SIM logistics: manual activation, batch processing, and static rate plans. eSIM and SGP.32 provisioning need real-time API calls and instant rating, which those systems weren’t built to handle.
Should a mid-market MVNO switch to a new MVNE instead of modernizing?
Switching MVNEs can solve a speed problem, but it usually doesn’t solve an ownership problem. You still don’t control the platform or its documentation. Modernizing the system you already run gives you both speed and long-term control.
How long does BSS modernization take without a full rebuild?
A strangler-pattern modernization typically rolls out service by service over several months, not years, because each extracted component ships and proves itself independently while the legacy system keeps billing customers throughout.