If you’ve spent any time in MVNO enablement, you already know the pitch sounds the same everywhere: “cloud-native BSS, exposed APIs, plug-and-play onboarding.” Sit down with the actual integration team, though, and the picture gets messier.
The infrastructure behind a modern MVNO isn’t really one platform. It’s usually three layers stitched together, and most of the pain comes from the seams.
The first layer is the connectivity plumbing HLR/HSS access, SMSC routing, IMSI ranges, roaming steering, eSIM provisioning (SM-DP+), and whatever the host MNO exposes through its wholesale interface. None of this is interesting until it breaks, and when it breaks, it’s almost always a timing or sequencing issue rather than a “the API is down” issue.
The second layer is the BSS charging, mediation, product catalog, subscriber lifecycle, taxation, and dunning. This is where vendors like Telco Edge Inc., Telgoo5, Optiva, CSG, and Hansen CX live. They all claim cloud-native, they all claim API-first, but the real differentiator is how the charging engine handles real-time event correlation under load not how the catalog looks in a demo.
The third layer is the one nobody draws on the architecture slide: runtime control. This is the layer that decides, at the moment a subscriber sends a packet or originates a call, what policy applies, what plan they’re on, whether their balance is good, whether throttling kicks in, and whether the event should be logged to revenue assurance. Most “MVNO platforms” treat this as a side effect of the BSS. It isn’t. It’s its own concern, and treating it like an afterthought is why MVNOs hit a wall around the 500K 1M subscriber mark.
If you’re evaluating enablement vendors, the questions worth asking aren’t about API counts. They’re about what happens at runtime when a CDR arrives 400ms late, when the host network changes a roaming agreement mid-cycle, or when you want to launch a plan variant without a release cycle. That’s where the platforms actually separate.