USSD Governance for Digital MVNO Operations

For a digital MVNO, the USSD service-code namespace is not a residual legacy interface. It is a controlled customer-operation surface spanning activation, balance enquiry, voucher flows, self-care, SIM Toolkit menus and selected fraud interventions. Governance fails when the host MNO treats the namespace as a core-network default while the MVNO treats it as a branded channel, with neither party owning routing changes, tariff treatment, audit evidence or settlement outcomes.

Define channel ownership before technical provisioning

Commercial ownership must be assigned before the first HLR entry, USSD gateway rule or OTA parameter is provisioned. Ownership of a short code does not automatically confer control over its menu tree, routing policy, data source, charging trigger or customer-support outcome. A balance-enquiry service, for example, may use an MNO-allocated code, MVNO-authored content, host-controlled routing and an MVNO OCS account query.

The control model should follow the complete transaction path. The handset submits a dial string to the MSC or an IMS interworking function. The gateway normalises the string, identifies the subscriber, applies a routing rule and hands the session to an application. That application may query the HLR or AuC, invoke the OCS, call an MVNO backend, or combine several of those actions before returning a response. Each transition needs a named control owner and an evidence source.

The service-code register should distinguish network-reserved codes, MNO retail codes, MVNO-exclusive allocations, shared codes with IMSI-based branching, and regulatory or emergency functions that the MVNO cannot alter. The register, rather than a gateway export or a BSS process note, should be the contractual source of truth. It should state the active version, effective date, environments, permitted tariff treatment and retirement status.

Service-code owner

Party authorised to request allocation, amendment and retirement

Routing owner

Party controlling gateway logic, IMSI lookup and application destination

Charging owner

Party accountable for OCS configuration, tariff classification and revenue records

Content owner

Party approving menu text, languages, consent wording and customer journeys

Incident owner

Party providing first response, escalation and root-cause evidence

SIM Toolkit requires a separate governance schedule. The MVNO may control the applet and menu language while the host retains OTA delivery, SMSC transport, profile capacity and security-key custody. The RACI must therefore cover code creation, route changes, menu publication, content approval, outage communications, CDR retention, fraud-rule changes and retirement.

A Tier-2 MNO, Southeast Asia, ~18M subscribers found that three MVNO tenants used the same balance code but relied on different application destinations and tariff rules. The code appeared uniform in gateway documentation. It was not commercially uniform. Moving the controls into a tenant-specific service-code register exposed the differing charging owners and removed ambiguous change authority.

Engineer routing and provisioning as a versioned control plane

Availability depends on coordinated state across the SIM profile, core routing, subscriber databases and application estate. For each code, engineering documentation should show the decision sequence: called-string normalisation, MCC/MNC and IMSI-range identification, optional HLR interrogation, subscriber-state validation, gateway selection and application hand-off. A route is not complete merely because the application endpoint answers. It must resolve correctly for the intended subscriber states and access conditions.

Multi-IMSI propositions add a separate branch. The active profile may change after roaming steering, a host migration or a commercial profile switch. The same dialled code can then reach another gateway, be rejected by the visited network or resolve to an MNO retail journey. Routing policy must identify which IMSI ranges receive the code and menu treatment before and after switching. The operating model should not assume consistency across profiles.

Release sequencing and acceptance states

Gateway rules, SIM Toolkit definitions, OTA payloads and backend contracts should share a release identifier. Promotion into production requires explicit dependencies and rollback criteria. Acceptance testing must cover pre-active, active, barred, port-in-pending, port-out-pending, suspended and reactivated subscribers. Tests should also validate MNP outcomes where the MSISDN and serving IMSI no longer imply the same commercial ownership.

Timeouts require an end-to-end budget. The MSC, gateway, application and OCS should not each consume an independently selected limit. Otherwise a downstream debit may complete after the handset session has closed. The acceptance plan should state the intermediate allocation, final customer response and fallback behaviour when the application or charging dependency fails.

Called-string normalisation

Canonical treatment of prefixes, trailing hash and local dialling variants

Subscriber selector

IMSI range, MSISDN range, HLR state or BSS segment used for routing

Response timeout

End-to-end limit, intermediate timeout allocation and defined fallback

Release dependency

Gateway rule, application release, OCS policy, SIM menu or OTA campaign

Rollback trigger

Failure threshold and party authorised to revert the active configuration

Make charging, settlement and revenue allocation observable

Technical success does not establish commercial treatment. Each code should be classified as zero-rated customer care, chargeable self-service, premium or third-party value-added service, authentication, voucher interaction, or an internal operational function. The classification must identify the tariff rule, liable party, tax treatment where applicable and settlement basis. It must also state whether access while roaming changes the charge.

Choose an authoritative event for each outcome

The parties should identify the authoritative record for every charge and reversal. Candidates include the gateway CDR, OCS debit record, mediation output, BSS transaction, third-party application receipt or roaming settlement record. No single record is inherently authoritative for every journey. A gateway event proves session handling, but it may not prove that a voucher was issued, a balance transfer completed or a downstream purchase was fulfilled.

Revenue allocation may follow session initiation, completed response, successful OCS debit, fulfilled downstream transaction or a composite rule. The last option is often required for multi-step services. The agreement should specify exception treatment for a timeout after debit, duplicate request, OCS reservation expiry, application confirmation failure and customer retry within a defined interval. Reversal ownership and execution time should be measurable obligations, not informal operational practice.

Reconciliation should compare code-level sessions with charging outcomes and complaints. Segmentation by IMSI range, tariff plan, access network, visited network and application version makes release defects and routing leakage visible. Monthly aggregate volumes cannot establish which party owes a correction, particularly where several tenants share a code or gateway.

An MVNE servicing 12+ tenants in EMEA found that gateway totals matched mediation within the monthly tolerance, while one tenant showed a material excess of successful debits over fulfilled transactions. Tenant-level application receipts exposed a timeout introduced by a backend release. Aggregate reconciliation had concealed the loss because other tenants moved in the opposite direction.

Where the MNO retains the gateway, the MVNO needs auditable extracts with session identifiers, timestamps, subscriber selectors, route result, application response, charging reference and failure code. Access can be governed through retention and privacy controls. It cannot be replaced by a monthly spreadsheet containing only attempts and completions.

Use the channels as controlled fraud and operations surfaces

USSD and SIM Toolkit can initiate account changes and payment events, so their controls should match the risk of the transaction. SIM presence or a matching IMSI is insufficient assurance for SIM-swap handling, PIN reset, balance transfer, tariff migration, account recovery or DCB consent. Higher-risk flows may require a second factor, recent-account-change check, transaction ceiling or assisted-care referral.

Rate limits should operate by MSISDN, IMSI, handset identifier where available, cell or location pattern, and code family. A single global threshold is likely to block legitimate customer-care use while leaving distributed attacks undetected. Policy owners should separate enquiry traffic from actions that move value or modify credentials.

Investigation records should correlate menu selection, session timestamps, gateway route, OCS result, backend decision, OTA campaign version and final response. That common record reduces the time spent reconciling separate host and tenant timelines. The emergency procedure must identify who can remove a route, suppress a menu, reverse a charging policy and brief customer operations. Authority should exist outside a standard change window for confirmed compromise.

Roaming needs its own test and policy set. Visited-network USSD support, CAMEL or OCS interaction, latency, character handling and local restrictions can change accessibility and chargeability. Multi-IMSI switching may also expose a different code namespace. The home-network result is therefore not sufficient evidence of the roaming customer journey.

Channel governance belongs inside the wider MVNO operating model. Host and tenant responsibilities for provisioning, charging, evidence access, fraud response and release approval should be negotiated together rather than distributed across unrelated technical schedules. Averon structures these controls within operator partnership and enablement programmes where service-code ownership intersects with core access, eSIM, multi-IMSI and billing responsibilities.

USSD and SIM Toolkit should be governed as shared operator channels, with named control owners and event-level evidence from provisioning through settlement. As digital MVNO portfolios add multi-IMSI, eSIM and DCB use cases, undocumented service-code arrangements become a direct source of revenue leakage, incident risk and host-MNO friction.