APIs are standardized. Semantics are shared. Operators are aligned. Developer sandboxes exist. Reference implementations are open.
Telecom operators have long believed that their networks contain latent platform value. Mobile networks authenticate devices, bind phone numbers to physical infrastructure, and observe behavior that applications cannot see directly. In an era of AI-driven fraud and automated attacks, those signals appear uniquely valuable.
I’m not neutral on this idea. I have been a booster of it for a long time. More than a decade ago, while at Ericsson, I worked on this problem during the Wholesale Applications Community era, alongside Sam Ramji, who at the time was leading strategy at Apigee as the industry tried to make operator capabilities consumable by application developers.
With GSMA Open Gateway and CAMARA, the industry has finally addressed the technical failures that undermined earlier attempts. APIs are standardized. Semantics are shared. Operators are aligned. Developer sandboxes exist. Reference implementations are open.
And yet usage remains marginal.
This gap is often framed as a “developer experience” problem. That diagnosis is incomplete. The deeper issue is economic: What kind of business telco APIs can realistically be, and what type they cannot.
What makes an API business real
An API becomes a business when it meets three conditions at the same time.
First, it solves a problem that customers already pay to solve. Successful APIs rarely invent new spending; they displace inefficient or fragile solutions that already exist.
Second, it creates a sharp wedge. Early APIs do not address broad markets. They solve one painful problem so clearly that adoption feels obvious rather than speculative.
Third, it establishes durable dependency. Developers build on APIs when switching away later would be costly, risky, or operationally disruptive.
These conditions explain why cloud storage, payments, and communications APIs scaled. They also explain why many technically correct APIs never do.
What telco API programs have genuinely fixed
It matters to be precise about progress, because without it the rest of the discussion would be theoretical.
CAMARA has done something earlier initiatives did not. It has defined network APIs with shared semantics in code, backed by open reference implementations. This reduces integration risk and long-term maintenance cost. Without this, no serious third-party adoption is possible.
GSMA Open Gateway solved a different problem. It created credible alignment across operators, reducing the fear that any integration would be stranded inside a single network. For anyone considering an investment of engineering effort, that signal matters.
Several operators have also adopted the right posture toward developers. Vodafone and Telefónica now offer free, contract-free sandboxes. This mirrors the cloud model and reflects a simple truth: no rational developer should pay before they know whether an API works.
Vonage’s role adds another important ingredient. By distributing network APIs alongside communications primitives developers already use, it lowers discovery friction and acknowledges that distribution, not exposure, is the scarce resource.
These are necessary conditions. They remove historical blockers. But they do not, by themselves, create demand.
Fraud as the right stress test
Fraud is often cited as the strongest use case for telco APIs, and for good reason. Account takeover is real, costly, and growing. Banks, fintechs, marketplaces, and consumer platforms already spend billions annually trying to prevent it. The budget exists.
To understand where telco signals fit, it helps to describe a modern fraud stack plainly.
Most large enterprises already deploy:
- Identity orchestration platforms such as Okta, Auth0, or Microsoft Entra
- Device intelligence services like Fingerprint, Kasada, or iovation
- Behavioral biometrics from vendors such as BioCatch or Feedzai
- Network and IP intelligence from Cloudflare, Akamai, or similar providers
- Risk engines that combine these signals to decide when to step up authentication
These systems already score risk, balance fraud loss against user friction, and evolve continuously. They are not placeholders waiting to be replaced.
Against this backdrop, telco networks offer two distinctive signals:
- whether a device actually possesses the phone number it claims
- whether that phone number has recently experienced a SIM change
From an engineering standpoint, these are valuable signals. From a market standpoint, they are incremental, not substitutive.
That distinction drives everything that follows.
Why embedding in workflows is the real adoption test
Incremental signals live or die by how easily they fit into existing decision flows.
Fraud teams do not build new workflows for each signal. They operate inside established systems that look roughly like this:
signals in → risk score → action (allow, step-up, block)
To be adopted, a telco signal must appear as one more input into a graph that already exists, not as a new subsystem that requires separate reasoning, procurement, and compliance review.
Concretely, this means:
- Embedding in identity orchestration
The telco signal shows up as a policy condition inside Okta/Auth0/Entra, not as a separate service engineers must reason about. - Embedding in fraud decision engines
The output is a normalized risk attribute with clear semantics (“recent SIM change within X hours”), not raw telecom metadata. - Embedding in observability and audit pipelines
Logs, alerts, and evidence flow into the same SIEM/SOAR systems already used for fraud operations. - Embedding in procurement and compliance
Consent posture, data lineage, and retention rules are pre-packaged, not rediscovered customer by customer.
This is why embedding in workflows is not a UX concern. It is the mechanism by which incremental signals overcome their own marginality.
Hyperscalers learned this early. Telco APIs are only beginning to.
TAM and unit economics
To understand whether telco fraud APIs can support a platform-scale business, we need to run the numbers carefully.
Start with customers. There are roughly 300,000 mid-to-large enterprises globally with online accounts. Only a fraction have fraud exposure large enough to justify advanced signals. A reasonable estimate is about 10 percent, or 30,000 serious buyers.
Next, transactions. Assume each such enterprise has 20 million user accounts, with five authentication events per account per year. That yields 100 million authentication events annually.
But only a subset of these events are fraud-sensitive: account recovery, new device login, password reset, and high-value actions. Empirically, this is on the order of 5–15 percent. Using 10 percent yields 10 million candidate events per enterprise per year.
Across 30,000 enterprises, that implies 300 billion high-risk events annually. This is the theoretical maximum surface where telco signals could apply.
Now apply reality.
Not all of these events occur on mobile networks. Many happen on desktops, Wi-Fi, or VPNs. Conservatively, mobile applicability may be around 30 percent. That reduces the surface to 90 billion events.
Regulatory and consent constraints further limit applicability. Silent checks are not universally permitted. Removing another 30 percent leaves 63 billion events.
Fraud teams will not invoke telco signals on every remaining event. They will use them selectively where lift justifies cost. Assuming usage on half of applicable flows yields 31.5 billion events.
Pricing is the final constraint. Competing signals such as device fingerprinting and IP intelligence often cost between $0.0005 and $0.001 per event and require no carrier dependency. To be competitive, telco signals must price at or below this range.
At $0.001 per successful decision, the resulting annual market is approximately $31 million.
Annual market size (USD)
| Authentications per account per year | Telco invoked on 25% of eligible flows | Telco invoked on 50% of eligible flows | Telco invoked on 75% of eligible flows |
| 5 (very conservative) | ~$16M | ~$31M | ~$47M |
| 10 | ~$31M | ~$63M | ~$94M |
| 20 | ~$63M | ~$126M | ~$189M |
Even in an optimistic scenario, the market struggles to exceed ~$200M annually at $0.001 per event.
To reach $1B+, at least one of the following must be true:
- price rises materially above competing signals (unlikely),
- telco signals replace, rather than supplement, existing fraud signals (unlikely),
- or telco APIs become mandatory via regulation or structural dependency (a very different business).
The outcome seems clear: this is not hyperscaler-scale. It is infrastructure-scale.
A more realistic definition of success
Taken together, these observations point toward a different conclusion than many industry narratives suggest.
Telco APIs are unlikely to become hyperscaler-style developer platforms. Their natural role is as standardized, regulated infrastructure consumed indirectly by platforms that already own developer relationships.
In this model:
- telcos focus on reliability, coverage, and compliance
- APIs are priced with wholesale economics
- value accrues through ubiquity, not visibility
- success is measured by partner dependency, not developer mindshare
China’s experience, where meaningful API-like revenues appear tied to vertically integrated platforms rather than open developer ecosystems, reinforces this interpretation rather than contradicting it.
This would not make telco APIs failures. It would make them comparable to other critical but invisible layers of the internet.
The decision the industry must make
The real strategic question is not how to further polish telco APIs. It is whether operators are trying to build platforms, or infrastructure for platforms.
If the goal is platforms, one narrow use case must be made dramatically better and cheaper than alternatives, and the organization must accept that most experiments will fail before one succeeds.
If the goal is infrastructure, success should be measured by quiet dependency, not public enthusiasm.
The engineering problem has largely been solved. What remains is an economic and organizational choice about what kind of business telco APIs are meant to be.
