A mobile number is treated as a credential by almost every digital service that uses SMS one-time passwords. The problem is that a phone number was never designed to be one. It can be moved from one physical SIM to another, and when that happens, every code sent to “verify” the account holder goes to whoever is now holding the number — not the person the account actually belongs to.

A Princeton University study of five major US prepaid carriers found that 80% of first-attempt SIM swap requests succeeded, largely because the carriers relied on authentication challenges that were easy for an attacker to work around.

From a Phone Number to an Account Takeover

A simple workflow can be represented as:

Fraudster → Carrier Authentication Challenge → SIM Swap → SMS OTP Redirected → Account Takeover

The application never sees this happen. It only sees a correct OTP entered on time, because from the network’s perspective, the swap has already succeeded before the login attempt ever begins.

This pattern supports several well-documented fraud categories:

• Bank account and payment app takeover
• Cryptocurrency wallet theft
• Email and social media hijacking
• Password reset abuse across any service using SMS OTP

Why the OTP Itself Isn’t the Weak Point

The one-time password is doing exactly what it was designed to do — proving that a code sent to a number was entered correctly. The weakness sits one layer below that, in the assumption that the number still points to the same physical SIM it did yesterday.

A Check a Swapped SIM Cannot Pass

Silent Network Authentication works differently. Instead of sending a shared secret to a phone number, it queries the mobile network directly to confirm that the SIM currently active on that number matches the SIM associated with the account.

Application → Silent Network Authentication API → Network API Gateway → Mobile Network → SIM Match Result

A swapped SIM fails this check by definition, because the fraud depends on the number pointing to a different physical SIM than the one on record. There is no code to intercept, because nothing is sent to intercept.

Where PAiCore Fits

PAiCore’s Network API Gateway exposes Silent Network Authentication as a standard, CAMARA-aligned API, bridging modern applications directly to the underlying telecom signaling that can confirm SIM identity in real time — without adding a step for the user.

Explore PAiCore Network API Gw

Get in touch

References

• An Empirical Study of Wireless Carrier Authentication for SIM Swaps — Princeton University / IEEE SPW 2020
• A Deep Dive into the Growing Threat of SIM Swap Fraud — Thomson Reuters Institute
• PAiCore Network API Gw

A phone number can be redirected. A silent, network-verified check on the SIM behind it cannot.

Mobile networks contain capabilities that can be useful far beyond traditional connectivity.

Subscriber verification, location, authentication and other network functions have historically required specialised telecom integrations. Applications that wanted to use these capabilities often had to work through operator-specific systems or telecom-focused interfaces.

Network APIs introduce a different model.

They provide a standardised interface through which applications and digital services can access selected capabilities of mobile networks without having to manage the underlying telecom infrastructure directly.

The industry is building around this model through initiatives such as GSMA Open Gateway and CAMARA, which aim to make network capabilities easier for developers and enterprises to consume. GSMA describes Network APIs as a way for businesses to access capabilities such as identity verification and location through standardised interfaces.

From Telecom Capability to Enterprise Application

The basic progression can be represented as:

Mobile Network → Network Capability → Standardised API → Enterprise Application

The important change is not necessarily the creation of a new network capability.

In many cases, the capability already exists.

The change is the way that capability becomes accessible to software outside the traditional telecom environment.

For example, an application may need to verify a mobile number.

Instead of directly integrating with telecom infrastructure, it can consume a Number Verification API.

Similarly, an application may need to check whether a device is within a particular area.

A Location Verification API can provide the required result through a standardised interface.

The application can then incorporate that result into its own workflow.

Why This Matters to Enterprises

Enterprises increasingly build services across multiple technology environments.

Their applications may use cloud platforms, databases, identity services and external APIs.

Network APIs add another potential source of information and functionality:

The mobile network itself.

This can be particularly relevant where the network has information that an application cannot obtain as easily from conventional application infrastructure.

Examples include:

• Mobile number verification
• Network-based location
• Device-related information
• Authentication
• Service entitlement

The value depends on the business workflow around the capability.

A verification result may become part of an identity process.

A location result may become part of a transaction or service decision.

A network capability therefore becomes another building block within enterprise software.

Where Does PAiCore Fit?

The PAiCore Network API Gateway provides the infrastructure layer between modern API applications and telecom network environments.

It supports REST/HTTP, SS7/MAP and Diameter interworking and provides access to selected CAMARA-aligned capabilities including Location Retrieval, Location Verification, Geofencing Subscriptions and Number Verification.

This creates a separation between the application and the underlying network.

The application communicates through the API.

The gateway connects that request to the relevant telecom environment.

The network continues to provide the underlying capability.

Why the API Layer Is Important

A standardised API does not mean that every operator has identical network infrastructure.

An operator may continue to use different network functions, protocols and deployment architectures underneath.

The API layer provides a more consistent way for applications to consume selected capabilities.

This is one of the central ideas behind the broader Open Gateway ecosystem.

CAMARA develops standardised APIs, while GSMA Open Gateway provides the wider framework for exposing those capabilities through participating operators.

The Resulting Architecture Can Be Viewed As

Enterprise Application → Standardised Network API → Network API Gateway → Telecom Network → Network Capability

This creates a bridge between two environments that have traditionally been separated.

The application works at the API level.

The network continues working with its existing infrastructure.

The gateway provides the connection between them.

Explore PAiCore

Explore the PAiCore Network API Gateway

Explore PAiCore Products

Industry Standard References

• GSMA — Understanding Network APIs
• GSMA — Open Gateway
• CAMARA Project
• CAMARA — API Overview

Network APIs are creating a new interface between capabilities that already exist inside telecom networks and applications that can put those capabilities to work.

Network APIs started with a simple idea:

Make selected telecom network capabilities available through modern APIs.

For decades, telecom networks have generated and managed information that can be highly valuable to digital services — from subscriber identity and device information to location, authentication, connectivity and network quality.

The challenge was never simply whether this information existed.

The challenge was how easily applications could access and use it.

Network APIs are changing that relationship.

Instead of requiring developers to understand complex telecom protocols, signaling systems and network architecture, selected capabilities can be exposed through standardized, developer-friendly interfaces.

This creates a new layer between telecom infrastructure and digital applications.

And that raises a bigger question:

What happens when telecom networks become programmable infrastructure for digital businesses?

The opportunity goes beyond creating more APIs. It is about creating a more accessible way for applications, enterprises and digital services to interact with network capabilities.

From Network Access to Digital Services

The progression can be viewed as:

Telecom Network → Network Capability → API → Application → Digital Service → Business Outcome

Each layer plays a different role.

The telecom network provides the underlying infrastructure and capabilities.

The network capability represents something useful that the network can provide — such as location verification, number verification, device information or network quality.

The API provides a standardized interface through which software applications can access that capability.

The application integrates the API into an existing workflow or customer experience.

The digital service turns that capability into something meaningful for the end user.

And finally, the business outcome is where the value becomes measurable — better security, improved customer experience, faster transactions, operational efficiency or new revenue opportunities.

This distinction is important because an API by itself does not create business value.

The value comes from what applications can build with the capability exposed through the API.

PAiCore’s Network API Gateway sits within this architecture by connecting modern HTTP/API-based applications with telecom network signaling and capabilities. Its platform supports CAMARA-compliant use cases and enables interworking between modern applications and telecom technologies such as SS7 and Diameter.

Why Programmability Matters

Traditional telecom infrastructure was primarily designed around connectivity and communication.

Applications connected to the network, but they generally did not interact deeply with network capabilities.

Programmability changes this model.

When selected network capabilities become available through APIs, developers can incorporate network context directly into application workflows.

For example:

A financial service could use network-based signals as part of a fraud-prevention workflow.

A digital platform could use location information to provide more relevant services.

A security application could use number or device-related signals during authentication.

A latency-sensitive application could potentially use network capabilities to improve service performance.

The important point is that these capabilities become software-consumable building blocks.

This is also the direction being pursued by the wider telecom ecosystem. GSMA Open Gateway describes a framework for common network APIs intended to provide developers and cloud providers with more consistent access to mobile network capabilities.

From Individual APIs to Composable Capabilities

The first stage of Network API adoption focused heavily on individual capabilities.

Location.

Number Verification.

Device Information.

Authentication.

Network Quality.

But real-world business processes rarely depend on one signal alone.

A digital service may need to combine several pieces of network information before making a decision.

For example:

Subscriber → Device → Location → Network Context → Service Decision

Each capability provides a different part of the context.

When these capabilities can be accessed programmatically and combined into application workflows, Network APIs become more than individual endpoints.

They become building blocks for digital services.

This is where the larger programmable telecom opportunity begins to emerge.

The ecosystem is already expanding beyond a narrow set of APIs. Current GSMA and CAMARA API portfolios include capabilities across authentication and fraud prevention, location services, communication quality, device information, computing, payments and other areas.

The Network Becomes Part of the Application Stack

Traditionally, application architecture has been dominated by components such as:

Application → Database → Cloud → External APIs

Network APIs introduce another important layer:

Application → Network APIs → Telecom Network

This means the network can become an active participant in the application’s decision-making and service delivery process.

The application does not need to understand every underlying telecom mechanism.

Instead, it interacts with an abstraction layer that exposes specific network capabilities through standardized interfaces.

CAMARA describes this transformation as a way of abstracting underlying telecom complexity into service APIs that are easier for customers and developers to consume.

That abstraction is critical.

Developers should not need to become telecom signaling experts simply to use a network capability.

The API layer makes the capability accessible while the underlying telecom infrastructure continues to handle the complexity.

What Comes Next?

The future opportunity is not simply about exposing more APIs.

It is about making telecom infrastructure more:

Programmable.

Accessible.

Interoperable.

Composable.

Useful to digital businesses.

This could lead to several areas of growth:

More Network Capabilities

As standardization progresses, more capabilities can become available through developer-friendly interfaces.

More Enterprise Use Cases

Financial services, digital commerce, gaming, logistics, media, IoT and other industries can explore how network context can improve their services.

Greater Use of Network Intelligence

Applications can use relevant network information as another input into authentication, security, personalization and service delivery.

New Digital Services

Developers can build experiences that were previously difficult to implement because the required network information was inaccessible or difficult to integrate.

New Revenue Opportunities for Operators

For telecom operators, Network APIs create another way to expose network capabilities to enterprises and digital platforms, turning infrastructure capabilities into programmable services.

GSMA’s current work around standardized Network APIs highlights this broader business opportunity, including the role of common APIs in reducing integration complexity and enabling scalable enterprise use cases.

Standardization Is a Critical Part of the Opportunity

Programmability alone is not enough.

If every operator exposes network capabilities differently, developers still face fragmented integrations.

That is why standardization matters.

The GSMA Open Gateway initiative provides a global framework for common network APIs, while the CAMARA Project defines and develops many of the service APIs used within that ecosystem.

CAMARA’s API portfolio already covers multiple categories, including location, authentication and fraud prevention, device information, communication quality, computing and payments.

This creates the possibility of moving from:

Operator-Specific Integration

to

Standardized Network Capability

and eventually toward:

Portable Digital Applications

The more consistent the interfaces become across operators and markets, the easier it becomes for developers and enterprises to build services that can scale beyond a single network.

A New Telecom Application Layer

This evolution can be viewed as the emergence of a new application layer around telecom infrastructure.

Mobile Network

↓

Network Capabilities

↓

Network API Platform

↓

Digital Applications

↓

Business Workflows

↓

Customer & Business Outcomes

The network remains the foundation.

Network APIs provide the programmable interface.

Applications determine how those capabilities are used.

Businesses determine where they create value.

This separation is important because it allows telecom infrastructure and digital innovation to evolve together without requiring every application developer to understand the underlying network architecture.

PAiCore’s Role in the Programmable Telecom Journey

PAiCore’s Network API Gateway is designed to help bridge the gap between modern API-based applications and telecom network infrastructure.

It provides CAMARA Project-compliant APIs and supports use cases including Location Retrieval, Location Verification, Geofencing Subscriptions, Number Verification and Know Your Customer Age. It also connects HTTP/API-based applications with mobile network signaling through technologies such as SS7 and Diameter.

This type of architecture provides a practical foundation for operators and telecom environments looking to expose network capabilities through modern interfaces while continuing to work with existing network infrastructure.

The broader PAiCore portfolio also covers areas including messaging, signaling, geolocation and business solutions, creating an ecosystem around telecom infrastructure rather than treating Network APIs as an isolated capability.

Explore PAiCore

To understand how programmable telecom capabilities can connect modern applications with telecom infrastructure, explore PAiCore’s technology portfolio and Network API Gateway.

Explore PAiCore Products
PAiCore Products

Explore the PAiCore Network API Gateway
PAiCore Network API Gateway

Industry Standards & References

The programmable telecom ecosystem is being shaped by several industry initiatives and standards organizations.

GSMA Open Gateway

GSMA Open Gateway provides a global framework for common network APIs designed to simplify access to mobile operator network capabilities for developers, cloud providers and enterprises.

GSMA Open Gateway

CAMARA Project

CAMARA is an open-source Linux Foundation project focused on defining, developing and testing standardized APIs for exposing telecom network capabilities.

CAMARA Project

GSMA Open Gateway API Specifications

GSMA publishes descriptions of mature Open Gateway APIs, covering areas such as authentication, fraud prevention, location, device information, communication quality and computing.

GSMA Open Gateway API Descriptions

CAMARA API Overview

The CAMARA API Overview provides the current view of mature and developing APIs within the project, offering a useful reference for developers and telecom stakeholders exploring network capabilities.

CAMARA API Overview

The Bigger Opportunity

The evolution from Network APIs to programmable telecom is ultimately about changing how digital businesses interact with telecom infrastructure.

The opportunity can be summarized as:

Network Capability → Standardized API → Programmable Access → Digital Application → Business Value

Network APIs are not replacing telecom networks.

They are creating a new way for the digital world to access, combine and build on what those networks already know and can do.

As standardization progresses and more capabilities become available through consistent interfaces, telecom infrastructure can become an increasingly programmable part of the digital application stack.

The bigger opportunity is therefore not simply more APIs.

It is a telecom ecosystem where network capabilities become accessible building blocks for the next generation of digital services.

The future of telecom is not only about connecting people and devices. It is about making the network itself programmable.

A Network API is only an interface.

The bigger opportunity is what happens when that interface is connected to a real business service. A location capability can support fraud prevention. A verification capability can support digital identity. A subscriber-related capability can support service eligibility.

The API is the connection point. The service is where the value is created.

Mobile networks already contain capabilities that can be useful beyond traditional connectivity. Network APIs provide a way to make selected capabilities available to applications and enterprises through standardised interfaces, reducing the need for every application to understand the underlying telecom environment.

From Capability to Service

The progression can be represented as:

Network Capability → API → Application → Business Workflow → Customer Outcome

This changes how operators can think about Network APIs.

Instead of asking:

“Which API should we expose?”

the more useful question becomes:

“Which customer problem can our network capability help solve?”

CAMARA defines Service APIs as APIs intended for developers to invoke specific telco capabilities. Its approach is designed to abstract underlying telecom complexity and make network capabilities easier for customers to consume. (CAMARA Project)

PAiCore’s Network API Gateway supports CAMARA-aligned capabilities including Location Retrieval, Location Verification, Geofencing Subscriptions, Number Verification and Know Your Customer Age. These capabilities connect modern REST-based applications with selected telecom network functions. (PAiCore Network API Gateway)

Each capability can become part of a different digital workflow.

Why Packaging Matters

An enterprise rarely wants to manage telecom capabilities in isolation.

It wants a capability that fits into an existing application or business process.

For example:

Transaction → Network Verification → Risk Decision

Or:

Network Location → Application → Service Action

Or:

Subscriber Verification → Application → Identity Decision

In these examples, the API is not the final service. It provides information or functionality that becomes useful when connected to the application’s own business logic.

This distinction is important for Network API adoption.

A catalogue can tell an enterprise what APIs are available.

A service needs to explain what those APIs can help the enterprise accomplish.

From Network Capability to Business Workflow

The same network capability can potentially support different applications depending on how it is integrated.

Location, for example, can be used for Location Retrieval, Location Verification or Geofencing Subscriptions. These are different API capabilities, but each can become part of a broader application workflow.

Similarly, Number Verification can become part of an identity or account-related workflow, where the application needs to verify the relationship between a user and a mobile number.

This creates a model where the network provides the capability, while the application determines how the resulting information contributes to its own decision-making.

The architecture therefore becomes:

Network Capability → Standardised API → Application Logic → Business Workflow

Where Does the Network API Gateway Fit?

Standardised APIs provide the application-facing interface, but the underlying network still needs to provide the actual capability.

This is where the Network API Gateway becomes an important part of the architecture.

PAiCore’s Network API Gateway provides CAMARA-compliant APIs and integrates with PAiCore GMLC and signaling platforms. It connects modern HTTP/API-based applications with mobile network signaling through SS7 and Diameter, providing an interworking layer between the IT and telecom domains. (PAiCore Products)

A simplified architecture can therefore be represented as:

Enterprise Application → Network API → PAiCore Network API Gateway → Network Capability → Mobile Network

The application works through the API.

The gateway handles the connection to the underlying telecom environment.

The network remains the source of the capability.

Why Standardisation Matters

For Network APIs to become useful across a broader ecosystem, developers need a consistent way to consume them.

This is one of the reasons CAMARA is important to the Network API ecosystem.

CAMARA develops and tests standardised Service APIs for telco capabilities and works with the GSMA Operator Platform Group to align API requirements and definitions. Its objective includes making network capabilities easier to consume across operators and countries. (CAMARA Project)

This helps move the industry away from individual, operator-specific integrations toward a more consistent API experience.

The underlying operator infrastructure does not have to be identical.

Instead, the API layer provides a common way for applications to access selected capabilities.

From API Catalogue to Digital Service

This creates an important distinction between an API catalogue and a digital service portfolio.

An API catalogue answers:

“What capabilities are available?”

A digital service answers:

“What can I do with those capabilities?”

That difference becomes increasingly important as Network APIs move from technical demonstrations toward real enterprise applications.

For an operator, the opportunity is to identify network capabilities that have practical demand and expose them through interfaces that enterprises can integrate into existing workflows.

For enterprises, the opportunity is to use network-derived information alongside their own application data.

For developers, the API abstraction reduces the need to work directly with specialised telecom interfaces.

The Resulting Architecture Can Be Viewed As

Telecom Network → Network Capability → Standardised API → Enterprise Application → Business Workflow → Customer Outcome

This is where Network APIs move beyond technical exposure and become part of the operator’s digital service strategy.

The network provides the underlying capability.

The API makes that capability accessible.

The application provides the business context.

And the resulting workflow creates the customer value.

Explore PAiCore

PAiCore’s Network API Gateway provides the API and interworking layer for exposing selected telecom capabilities through modern interfaces.

Explore the PAiCore Network API Gateway

For a broader view of PAiCore’s telecom infrastructure and business solutions:

Explore PAiCore Products

Industry Standard References

• CAMARA — Project Scope and Service APIs
• CAMARA — API Overview
• CAMARA — Network APIs
• GSMA Open Gateway

The API is not the final product. The outcome it enables is.