This deep dive expands on the Loop Asia conversation with Alex Szomora, GSMA's Senior Go-To-Market Project Manager for Open Gateway.

Every fraud and identity team runs into the same wall: SMS one-time passcodes are the weakest link in an authentication chain, not the strongest. They can be intercepted, phished, or defeated by the same SIM-swap attack they're supposed to prevent. Alex Szomora touched this only in passing on The Loop Asia, noting that OTP "is something that in some countries are being replaced by number verification" — a line worth pulling apart: it points at a real architectural shift, moving verification off the SMS channel and onto the network itself.

What the carrier actually knows that you don't

A telco sits in a structurally different position than any app or bank verifying a user. It doesn't just send a code and hope the right person reads it — it knows, in real time, at the network layer, whether that SIM is the one that's been active on the number, whether the device has recently changed, and roughly where the handset is — knowledge Szomora packaged into four named APIs.

SIM swap detection answers the question OTP can't: has this number recently been ported to a new SIM? That's the most common precursor to account-takeover fraud, visible only to the network operator. Number verification goes further than an OTP: it confirms that the device making the request is genuinely tied to the claimed number, with no code traveling over SMS for an attacker to intercept. Device location and status confirm the phone is where it claims to be and hasn't been jailbroken, rooted, or otherwise compromised, before a high-value transaction clears.

Szomora's examples are concrete: Vinted, the European e-commerce marketplace, runs anti-fraud and authentication checks through these APIs directly; banks use the same signals to confirm an ATM withdrawal or phone transaction before it clears. These aren't hypothetical — they're live deployments across a federation of more than 240 mobile networks.

The architecture decision this actually creates

For a CTO evaluating this space, the question isn't whether these signals are useful — it's how you integrate them. Szomora made clear GSMA doesn't run developer relations for Open Gateway; it leaves that to aggregators and channel partners, betting on Camara's code-level standardization instead. You're unlikely to call a specific operator's API directly — you'll go through an aggregator already federated across your footprint, making its coverage map and reliability your real dependency, not GSMA's roadmap.

Treat that like any third-party dependency: coverage gaps (an aggregator is only as good as the operators it's federated with), fallback design (what happens when a network-side check isn't available), and the fact that "57 APIs by end of year," as Szomora put it, is a young, fast-moving catalogue, not a stable standard. None of that is a reason to avoid it — it's a reason to design the integration as a layer you can swap, not hardcode to one aggregator.

The organisations getting the most value treat carrier-side signals as one input into a risk-scoring pipeline, not a replacement for every other control — reducing OTP dependence where the signal is strong, keeping other checks where it isn't. That's the kind of integration governance call — build vs. federate, vendor-neutral evaluation of aggregators — worth an outside perspective before the architecture calcifies, not after.