Pillar 03 — CAMARA & GSMA Open Gateway Network Exposure

Open Gateway is not won on the northbound API. Publishing a CAMARA-shaped REST endpoint is a sprint. Making SIM Swap return a truthful answer from a twelve-year-old HLR, in under two hundred milliseconds, every time, is the part that takes protocol engineers. That is the half we build.

CAMARA-conformant southbound adapters: SIM Swap, Number Verification, Device Location, KYC Match
Mapped onto the network you actually run — HLR, HSS, UDM, PGW/SMF, IN, AAA
Sub-second, cached where it is safe to cache, honest about freshness where it is not
Consent and audit hooks so the regulatory answer exists before the auditor asks
Your API gateway, your developer portal, your commercial terms — we stay underneath

Discuss an exposure programme

For partners

CAMARA

GSMA Open Gateway

SIM Swap

Number Verification

Device Location

KYC Match

MAP / Diameter / HTTP-2

HLR · HSS · UDM

PGW / SMF

Consent & audit

OAuth 2.0 / CIBA

The northbound is crowded. The southbound is not.

A lot of capable companies will sell you an Open Gateway front door: the developer portal, the API gateway, the marketplace, the billing and the partner management. That layer is genuinely well served, and if you already have it, you should keep it.

Then the programme reaches the network. SIM Swap needs the last IMSI change timestamp, which lives in an HLR that was never designed to be asked. Number Verification needs to correlate a data session to an MSISDN through the PGW or SMF. Device Location needs a location request the network will answer inside an API timeout. Each of those is a protocol integration against equipment with its own opinions.

There are not many companies who enjoy that work. We have been doing it for eight years, and we have the twenty-plus integration modules to show for it.

Southbound adapters

CAMARA-conformant on the north side. Whatever your network speaks on the south side.

CAMARA API	What it needs from the network	How we get it
SIM Swap	Time of the last SIM or IMSI change for an MSISDN	MAP interrogation or provisioning-event stream from HLR/HSS/UDM, with a change journal so the answer survives a database that overwrites history
Number Verification	Binding between the active data session and the MSISDN	PGW/SMF session correlation over Diameter Gx/Gy or N4 event exposure, with header-enrichment fallback where the architecture allows it
Device Location / Verification	Current serving cell or verified proximity	MAP ATI, Diameter SLh/SLg or NEF location exposure, with accuracy and freshness declared rather than implied
KYC Match	Subscriber registration data for comparison	Read-only projection from the BSS or subscriber database, with field-level consent enforcement and no raw data leaving the boundary
Device Status / Reachability	Attach state and roaming status	MAP or Diameter interrogation, cached with an explicit staleness contract
One-Time Password / Silent auth	Network-verified delivery or session proof	Bridged into the Mobees SMSC and Number Verification adapters as one flow

Where we fit in your programme

You own the north

Developer portal, API gateway, catalogue, quotas, partner management, rating and settlement. We do not build any of it and do not want to.

We own the south

Protocol adapters, network integration, latency budget, caching policy, failure semantics and the tests that prove the answer is correct.

Shared contract

A CAMARA-conformant interface between the two, versioned, documented and independently testable from both sides.

Consent and audit

Purpose-bound consent checks, full decision audit and data-minimisation at the adapter, because retrofitting this after launch is painful.

Logical architecture

CAMARA façade. Conformant REST resources, OAuth 2.0 and CIBA authorisation, consistent error semantics.

Adapter layer. One adapter per capability per network technology, so a 4G and a 5G core can answer the same API differently underneath.

Protocol modules. The same MAP, Diameter, SIP and HTTP/2 stacks that run in our messaging products, reused rather than rewritten.

Consent and audit service. Every request carries a purpose; every decision is recorded.

Assurance. ProBee measures API latency and success against the southbound dialogues that produced them — so an SLA breach can be attributed to the network element responsible.

Assurance integrations

Engineering services

Who this is for

Tier-2 and Tier-3 operators

You will not be first in the queue for a hyperscale vendor’s network exposure programme. You can still be live with four APIs this year.

MVNEs

Exposure across a tenant base is a product. The southbound complexity is per host network, and it is exactly what we absorb.

Aggregators and CPaaS

You need operator-side adapters in each market you sell into. We build them once per network and you resell the capability.

OSS/BSS vendors

You have the monetisation and partner layer. Adding southbound adapters turns a partial answer into a full-stack offer without hiring protocol engineers.

Have a northbound and no southbound?

That is the most common shape of this conversation. Send us your target API list and your core inventory; we will come back with a feasibility note per API.

Partner with us