The problem with running multiple MVNOs
If you run an MVNA (Mobile Virtual Network Aggregator) or manage a portfolio of virtual operators, you're operating one of the more architecturally complex SaaS products in telecom.
Each MVNO in your portfolio is effectively a separate business: its own plan structure, its own rate card, its own subscriber base, its own billing rules, its own MNO wholesale settlement, its own compliance requirements. But they all run on shared infrastructure — shared network interconnects, shared back-office tooling, shared support workflows.
The naive architecture is to give each MVNO its own isolated instance of your BSS. This is operationally clean but doesn't scale — you get N separate platforms to maintain, upgrade, and monitor, with no portfolio-level visibility and no shared infrastructure efficiency.
The right architecture is multi-tenant. One platform, isolated data and billing logic per tenant, unified operations layer. This is what TelcoEdge Inc. built for MVNAs. Here's what that looks like in practice.
Tenant isolation in a telecom BSS
Tenant isolation in a telecom context is more complex than in a typical SaaS application because the data that needs isolation isn't just customer records — it includes:
- Subscriber PII and usage records (regulatory requirements in most jurisdictions)
- Billing configuration and rate card data (commercially sensitive between operators in the same portfolio)
- MNO wholesale settlement data (each MVNO has its own settlement relationship)
- Plan and pricing structures (operators may compete with each other in the same market)
Our approach uses logical tenant isolation at the data layer with shared compute infrastructure. Each tenant has its own schema namespace. Billing engine instances are tenant-scoped — a billing event for MVNO A cannot touch MVNO B's rate card or subscriber records at the query level, not just the application level.
This matters for MVNAs whose portfolio includes operators in competitive market segments. The aggregator needs portfolio visibility; the individual operators need data isolation from each other.
The settlement layer: where multi-tenancy gets complicated
In a single-MVNO deployment, settlement is straightforward: match your subscriber billing records against the MNO wholesale invoice, identify discrepancies, settle.
In a multi-tenant MVNA deployment, settlement is a two-layer problem:
Layer 1 — MVNA to MNO. The MVNA holds the master wholesale agreement with the MNO. The invoice comes to the MVNA, covers all traffic from all MVNOs in the portfolio.
Layer 2 — MVNA to individual MVNOs. The MVNA needs to allocate that wholesale cost accurately to each MVNO in the portfolio, add its aggregator margin, and settle with each operator.
The technical requirement: every usage event needs to be tagged with its operator identity at ingestion, so that wholesale cost attribution at Layer 1 correctly maps to operator-level settlement at Layer 2. If this tagging is applied after the fact (at settlement time rather than at event time), you get allocation errors that compound.
TelcoEdge tags every CDR with operator identity at the point of ingestion. Settlement runs from that source data — not from a retrospective allocation model.
Automated settlement across the portfolio
Manual settlement for a portfolio of 5–10 MVNOs is a significant operational burden. The month-end process involves reconciling each operator's billing data against the wholesale invoice, calculating per-operator allocation, generating settlement statements, and managing disputes.
TelcoEdge Inc. automates this end-to-end:
MNO wholesale invoice received
→ Matched against per-operator CDR aggregates (tagged at ingestion)
→ Discrepancies flagged per operator
→ Settlement calculations run automatically
→ Per-operator settlement statements generated
→ Disputes raised before payment where discrepancies exist
The ops team reviews exceptions, not the full settlement. Portfolio-level visibility shows total exposure across all operators simultaneously — not operator by operator.
Portfolio dashboard vs operator dashboard
One design principle we've found important: the MVNA's view and the individual MVNO's view need to be architecturally separate, not just filtered views of the same data.
The MVNA needs aggregate metrics: total subscriber count across portfolio, total wholesale cost, per-operator margin performance, settlement status, anomaly alerts across all tenants. The individual MVNO needs its own subscriber data, its own billing detail, its own support queue — with no visibility into sibling operators.
We implement this as two separate dashboard layers with different permission scopes, drawing from the same underlying data model. The MVNA layer aggregates. The operator layer is scoped. The isolation is enforced at the API level, not the UI level.
Deployment and provisioning
For MVNAs onboarding new operators into the portfolio, provisioning speed matters. A new MVNO tenant on TelcoEdge Inc. is deployable in 3–4 weeks — network integration, billing configuration, and SIM/eSIM activation.
The MVNA doesn't provision from scratch each time. The shared infrastructure (network interconnects, payment gateway integrations, compliance tooling) is already operational. The per-tenant configuration is billing rules, plan structure, and operator-specific rate card setup.
Happy to go deeper
If you're building multi-tenant telecom infrastructure, working on BSS/OSS architecture, or thinking through the settlement data model for an aggregator product, we'd welcome a technical conversation.
Top comments (0)