CAMARA-aligned Network APIs give MNOs and MVNEs a more consistent route to expose capabilities such as number verification, SIM swap checks and device location to MVNO channels. The commercial question is no longer whether an API can be integrated. It is who controls consent orchestration, who carries the service commitment, and which party absorbs losses when an API response drives a failed transaction, fraud decision or regulatory complaint.
CAMARA standardisation narrows the technical gap, not the governance gap
CAMARA and GSMA Open Gateway have moved API exposure into board-level wholesale discussions. Enterprise demand is concentrating around fraud controls, identity signals and quality on demand rather than undifferentiated access to network data. That concentration improves the commercial case for common interfaces, but it also directs investment toward capabilities carrying material privacy, security and customer-outcome risk.
A CAMARA-aligned interface can specify request fields, authentication patterns, error handling and response behaviour. It does not determine whether the MNO, exposure-platform operator, MVNE or MVNO acts as data controller, processor, contracting party or customer-support owner. Those roles depend on the deployment, contractual chain and purpose of processing. They cannot be inferred from conformance to an API definition.
Fraud and identity APIs are reaching commercial catalogues ahead of mature allocation rules for false positives, stale signals and unavailable responses.
KYC-supporting signals and device-location services attract greater scrutiny because the response may influence onboarding, authentication or access decisions.
Standard access does not automatically confer authority to package a capability under an MVNO brand or resell it through enterprise contracts.
API roadmaps are progressing faster than wholesale templates covering consent evidence, audit rights, incident ownership and downstream use restrictions.
A Tier-1 MNO, Western Europe, ~35M subscribers, can retain control of the core-network function while permitting an MVNE to operate the partner-facing exposure layer. That division may be operationally efficient, but it creates at least three control boundaries: collection of customer authority, enforcement of API policy, and production of evidence during an audit or complaint. The wholesale schedule must identify which party can retrieve each record, how quickly it must do so, and who leads an incident involving both network and channel data.
The immediate market signal is therefore mixed. Technical comparability is improving, procurement discussions are becoming more concrete, and enterprise channels are testing repeatable use cases. Yet controlled monetisation still depends on bilateral terms that common API specifications do not supply.
Consent must follow the service journey, not the network boundary
Contracts should map every invocation from the enterprise application through the MVNO, MVNE or aggregator layer to the MNO’s NEF, SCEF or equivalent exposure function. The map should identify the API client, subscriber reference, policy decision, network source and response recipient. Without that chain, an operator may be able to prove that its network answered correctly but remain unable to prove that the query was permitted.
Consent language needs to cover purpose, data category, retention period, geography, revocation handling and the initiating party. It should distinguish a request initiated by the subscriber from one initiated by an enterprise customer or authorised delegate. A generic permission for mobile services provides weak operational certainty for repeated location or identity-signal queries, particularly where the MVNO owns the customer relationship and the MNO never presents the relevant notice.
The MVNO should warrant the validity of authority collected through its channel. The MNO or MVNE should retain tamper-evident invocation logs linking each request to the client credential, subscriber reference, timestamp, applicable policy and outcome. Log retention must align with complaint, billing and regulatory time frames. A technically complete log that expires before the contractual dispute window has limited evidential value.
A Greenfield MVNO, post-2023, multi-IMSI stack, faces an additional attribution problem. The serving network, commercial issuer and customer-facing brand may differ by country or session. Consent records must therefore identify the footprint and policy context under which the capability was invoked, not merely the subscriber account held in the MVNO’s central customer system.
MNP creates a separate edge case. A number-verification or SIM-swap request must establish whether the queried MSISDN remains within the serving operator’s authority at the point of invocation. Porting events, number quarantine and reassignment can make a previously valid association obsolete. Routing the request successfully is not evidence that the responding party still has authority to disclose the signal.
SLA ownership should be separated into network, platform and commercial commitments
A single headline availability figure obscures the failure domains that determine whether an MVNO can meet an enterprise commitment. MNO obligations should be limited to measurable areas under network control: capability availability, source-data freshness, latency at the exposure boundary, planned-maintenance notice and incident notification. Even within those areas, the measurement point matters. Core-function availability does not establish that an external client received a usable response.
An MVNE operating API gateways, OAuth flows, partner portals, mediation and settlement should carry separate availability and support obligations. Passing a blended SLA to the MVNO makes root-cause allocation difficult and can produce service credits from a party that did not cause the outage. It also weakens operational incentives where the failing layer incurs no direct remedy.
The contract should state whether each result is authoritative, probabilistic, cached or subject to delayed network-state propagation. That distinction is material when an enterprise uses SIM-swap age or number status as an input to fraud and authentication policy. An accurate response based on data that trails the network event by several minutes may still be unsuitable for the downstream decision. Data freshness should therefore be measured separately from gateway latency.
An MVNE servicing 12+ tenants in EMEA should maintain a service model that separates common platform incidents from tenant-specific configuration failures and upstream MNO outages. Severity thresholds, joint incident bridges, escalation contacts, root-cause reports and correction periods for erroneous usage records should be agreed before launch. The MVNO also needs a route to challenge an incident classification where enterprise impact exceeds the platform operator’s initial assessment.
Service credits should attach to the accountable layer and normally be capped against recurring charges for that layer. They should not act as a proxy for downstream enterprise losses that the operator cannot observe or control. Consequential exposure belongs in the liability framework, with specific treatment for conduct that falls outside ordinary service failure, including wilful misuse, confidentiality breach or unlawful processing.
Multi-country offerings require country-level schedules. A regional wrapper cannot conceal differences in 4G, NSA 5G and SA 5G exposure capability, data freshness, maintenance practice or regulatory treatment. The commercial schedule can remain regional, but its service commitments must reflect the underlying footprint.
Liability allocation will determine whether Network APIs become a repeatable wholesale product
The viable model is layered liability. Responsibility should follow control over consent collection, client authentication, network data, policy enforcement and downstream decisioning. The MNO should not accept liability for an enterprise’s credit, access or fraud decision merely because a network signal formed one input. The enterprise or MVNO determines the decision rule, sets thresholds and combines the response with other data.
The MVNO should remain accountable for customer contracts, sales representations, use-case restrictions and the conduct of enterprise API clients it onboards. That includes screening proposed use cases, issuing credentials through the agreed chain and suspending clients that breach permitted-use rules. If the MVNO promises an enterprise that a probabilistic signal guarantees identity, the resulting exposure should not transfer upstream through a generic service warranty.
The MVNE or API platform operator should accept responsibility for authentication failures, credential compromise within its estate, faulty policy enforcement, gateway outages and mis-metering where those functions sit within its control. The boundary needs precision. A stolen enterprise credential, an incorrectly issued platform credential and an MNO policy defect are distinct events with different evidence, containment and remedy paths.
Indemnities should address defined events rather than rely on a broad reciprocal clause. Unlawful data processing, intellectual-property infringement, security breach, unauthorised API use and violation of permitted-use restrictions require different triggers and evidential standards. The agreement should also distinguish third-party claims from direct remediation costs, regulatory investigation expense and mandatory customer notification.
Usage records are part of the liability design because they determine what was delivered and billed. Each record should show settlement status and distinguish successful, failed, retried and rate-limited calls. The parties need an agreed source of truth, correction process and dispute window. Without those controls, revenue assurance becomes a bilateral reconciliation exercise, and disagreements over technical outcomes migrate into invoice disputes.
Commercial governance should include quarterly review of catalogue changes, deprecation periods, pricing amendments, regulatory developments and material changes to sub-processors or hosting locations. New API versions can alter response fields, policy logic or data provenance without changing the headline use case. Wholesale governance must therefore examine both catalogue expansion and modifications to existing capabilities.
CAMARA can make Network APIs easier to expose, but it does not make their wholesale economics automatic. MNOs and MVNEs that define consent evidence, control boundaries, SLA domains and liability before onboarding MVNO channels will be better placed to scale API revenue without inheriting unpriced regulatory and enterprise risk.