What to Look for When Choosing an SNA Provider

SNA is still relatively new technology compared to SMS, which has been around for over 25 years. Choosing the right partner for your deployment is therefore critical. Traditional CPaaS providers, whose core business is built on SMS, are not necessarily best positioned to help you implement a security solution that replaces SMS. So think carefully before choosing.

To ensure your transition from SMS OTP is a success and that SNA delivers its full potential, there are multiple dimensions you should evaluate. This guide covers what to look for in each, and the specific questions that reveal where providers actually differ.

1.  Consultative capability

Most SNA providers hand you an API key and leave you to figure out the rest. A genuine partner actively shapes your deployment before the integration starts — helping you choose the right user journey, structure a business case your CFO will back, design the metrics framework, and navigate internal sign-off. The quality of that pre-integration support determines how quickly you get to production and how well the first deployment performs.

  What to ask  

• Do you offer structured help with use case selection and journey prioritisation, or do you hand over an API spec and leave the design to us?
• Can you help us build the business case — including realistic conversion uplift estimates and fraud loss calculations based on your production data?
• Do you have reference deployments in our sector we can speak to directly?
• What does your pre-launch engagement look like — do you review our integration design, fallback architecture, and instrumentation plan before we go live?

2.  Technical performance

The most important performance metric is authentication success rate in production — not demo conditions against test numbers. Success rate is driven by whether carrier connections are direct or aggregated, the SDK’s ability to handle devices on Wi-Fi, and the speed of the check. Latency matters not just for user experience but because a slow check can create an apparent UI freeze if the host app is not built to handle it gracefully.

  What to ask  

• What is your real-world authentication success rate in production across your live customer base — not in a test environment?
• Are your carrier connections direct or aggregated through a third party? Direct connections produce materially better latency and higher success rates.
• What is your typical latency for the SNA check in production? How does this vary by market?
• Do you offer number discovery — automatic detection and verification of a user’s phone number without them typing it?

3.  Edge case handling

The happy path with SNA is easy to demo. Edge cases are where deployments break — and they are still quite common. Most users on most apps are on Wi-Fi at any given moment. A meaningful share of devices have VPNs active. Modern phones carry multiple SIMs. There is also a standards question worth understanding: the market is moving from NV1.0 towards TS.43. TS.43 extends coverage to browser-based flows on Wi-Fi, but current implementations require per-transaction user consent flows that suppress conversion. For native app flows today, NV1.0 typically delivers better outcomes. Ask providers if they support both and have them explain the TS.43 flow before committing.

  What to ask  

• How does your SDK handle Wi-Fi? Does it route the SNA check over cellular without disrupting the user’s Wi-Fi connection? What happens when there is no cellular signal?
• How do you handle device-level VPNs, which bypass the cellular path entirely?
• What is your approach to dual-SIM and eSIM — which SIM does the check target on a multi-SIM device?
• Which MVNOs are excluded from your headline coverage figures, and what happens for those users?
• Do you support NV1.0, TS.43/NV2.x, or both? For TS.43: can you explain the UX implications?
• How do you handle SNA on iOS mobile web?

4.  Product set

A binary Yes / No SNA check is the foundation. For most enterprise use cases it is not enough on its own. SNA verifies that the claimed mobile number matches that allocated to the SIM in the device. It does not tell you whether that SIM was recently swapped, whether the account holder name matches carrier records, or automatically detect the user’s number without them providing it. Each of these is a separate product. Providers who pitch SNA as a complete answer to SIM Swap fraud are overselling.

  What to ask  

• Do you offer SIM Swap detection, and how does it integrate with SNA at the architecture level? What is the data latency from a swap occurring to your API reflecting it?
• Do you offer any identity verification beyond the binary SNA result — for example, name or address verification against carrier records?
• Do you offer number discovery — automatic detection of the user’s phone number without them typing it?
• What are your fallback / failover options if SNA is unavailable?

5.  Security posture and compliance

For a bank or payments platform deploying SNA, security must be the provider’s core business — not a feature added to a messaging or CPaaS platform. The security and compliance credentials of your SNA partner will be scrutinised in your internal procurement process and by your regulators. Establish this early.

  What to ask  

• What are your security certifications — ISO 27001, SOC 2 Type II? Are audit reports available under NDA?
• Where is data processed and stored? What is your data residency architecture, and does it meet our regulatory requirements?
• How is network query data handled — is it logged, retained, and for how long? What is your data minimisation approach?
• Do you provide the option of a dedicated platform instance for complete data segregation and custom configuration?

6.  Coverage

Coverage figures need to be read carefully. A headline percentage — ‘80% of subscribers in Germany’ — means different things depending on whether it represents real-time MNO API access or a carrier lookup database. Real-time access checks the current state of the SIM-to-number binding at the moment of the request. A lookup database reflects historical data that may be hours or days old. MVNO coverage is the second question — providers often exclude MVNOs from headline figures without saying so.

  What to ask  

• Is your coverage based on real-time MNO API access or a carrier lookup database, for each market you quote a figure for?
• Are MVNOs included in your headline coverage figures? If not, which MVNOs in my target markets are outside your coverage?
• Are your carrier connections direct or through an aggregator?
• What does the fallback experience look like for users your SNA check cannot reach — what does the user see, and what does your API return?
• What is your coverage roadmap for markets we expect to expand into?

7.  Commercials

Commercial flexibility matters more in SNA than in most technology categories because the journey from pilot to production to scale spans significantly different volumes and use cases. Established players often price for large-scale deployments from day one. The right partner prices to reflect where you are in that journey, with a commercial model designed around your growth rather than their margin. Understand the full TCO model before you commit — per-auth pricing, volume tiers, minimum commitments, and what happens commercially as you expand use cases.

  What to ask  

• How does your pricing scale from initial proof of value through to full production deployment and multi-use-case expansion?
• What are your minimum commitments at pilot stage, and how do they change as we scale?
• Is pricing per-auth, per-user, or another model — and how does it compare to our current SMS OTP cost at equivalent volume?
• How are additional products (SIM Swap detection, KYC Match) priced relative to the core SNA product?
• What does the commercial relationship look like if we expand to new markets or additional use cases?

8.  Support and optimisation

The quality of support before, during, and after launch directly determines whether you get to production, how quickly, and what your success rates look like once you are there. Two failure modes appear repeatedly: documentation that covers the happy path but leaves error handling underspecified, and testing processes that delay time-to-production. Some providers require carrier registration approvals before testing can begin — adding weeks before a single live check can run. Post-launch, the best partners provide analytics that surface optimisation opportunities, not just uptime monitoring.

  What to ask  

• How long from API access to the first live SNA check? Is there a carrier registration or approval step that creates a delay?
• How are error codes structured? Can you show us your error documentation, including what fallback behaviour is appropriate for each failure type?
• Do you offer a shadow mode PoV — running SNA silently alongside the existing OTP flow before going live?
• What analytics and reporting are available post-launch? Can we see coverage gaps, fallback rates by segment, and latency distribution?
• Do you share deployment best practices proactively, or only respond to issues when raised?

9.  Innovation and roadmap

SNA standards are evolving. NV1.0 is the established production standard today; TS.43 extends coverage to browser-based Wi-Fi flows and is the direction the market is moving. Beyond standards, the arrival of AI agents is changing the authentication landscape: every control built around ‘a human reads the screen and confirms’ will need to adapt. Possession-based, network-verified authentication is structurally better positioned for an agentic world than any knowledge or biometric factor. A partner with a credible roadmap on both dimensions is building the foundation you will need — not just solving today’s problem.

  What to ask  

• What is your current standard support — NV1.0, TS.43, or both? What is your roadmap for TS.43 and NV2.x deployment in production markets?
• How are you thinking about authentication in an agentic world, where a meaningful share of transactions will be agent-initiated rather than human-initiated?
• How do you stay current with GSMA Open Gateway and CAMARA standards evolution?
• What new products or capabilities are on your roadmap in the next 12–24 months?

The questions that reveal the most

Across all nine dimensions, these are the questions that most reliably separate providers who perform in production from those who perform in demos:

• Will you help us design the deployment, or just hand us an API spec?
• What is your real-world authentication success rate across your live production customer base?
• How does your SDK handle a device on Wi-Fi with no accessible cellular path — specifically on iOS mobile web?
• Do you offer SIM Swap detection alongside SNA, and how do the two integrate?
• What security certifications do you hold, and have you completed enterprise security review at regulated financial institutions?
• How does your pricing scale from pilot to full production?
• Can you show us your error code documentation, including fallback behaviour for each failure type?

The answers to these questions will tell you more about how a deployment will perform than any demo or coverage slide.

About the author: Paul McGuire

Paul McGuire is CEO of IDlayr. He has spent over two decades at the intersection of mobile, telecoms, and digital identity. He works directly with banks, payment platforms, and large consumer apps deploying Silent Network Authentication to replace SMS OTP, eliminating ATO and SIM Swap fraud risk. He has held senior leadership roles across mobile and technology businesses in the USA and internationally.

What is the most important factor when choosing an SNA provider?

Consultative capability — does the provider help you make the right decisions before the integration starts? Use case selection, business case design, metrics framework, and deployment architecture are all decisions that a genuine partner shapes with you. Beyond that, real-world authentication success rate in production (not demo performance) is the most reliable technical differentiator.

What is the difference between direct and aggregated carrier connections?

A direct carrier connection means the SNA provider has a bilateral integration with the mobile network operator. An aggregated connection routes through a third-party intermediary. Direct connections produce lower latency, higher authentication success rates, and faster resolution of production issues.

Does SNA work on Wi-Fi?

SNA requires the cellular data path. On a Wi-Fi connected device, the SNA SDK must temporarily route the check over cellular without disrupting the user’s connection. Not all implementations handle this cleanly — it is one of the most common failure points in production. Ask any provider to demonstrate this on a device actively connected to Wi-Fi.

What is the difference between NV1.0 and TS.43?

NV1.0 is the established SNA standard available in production with strong coverage. TS.43 extends verification to browser-based flows on Wi-Fi. However, current TS.43 implementations require per-transaction user consent flows that can suppress conversion. For native app deployments today, NV1.0 typically delivers better outcomes. TS.43 is the longer-term direction.

Do I need SIM Swap detection in addition to SNA?

For most enterprise use cases, yes. SNA verifies the correct SIM is in the device right now. SIM Swap detection tells you whether the SIM-to-number binding was recently changed — flagging accounts where a swap occurred before a high-value transaction. For high-value onboarding, step-up authentication, and account recovery, both together is the recommended architecture.

What security certifications should an SNA provider hold?

Look for ISO 27001, SOC 2 Type II, and PCI DSS where applicable. For deployments in regulated financial services, ask whether the provider has completed enterprise security review at tier-1 financial institutions and can provide references. Data residency, data minimisation approach, and retention policies are equally important in regulated markets.

How should SNA be priced?

SNA is typically priced per authentication check, often with volume tiers. The right commercial model reflects the journey from pilot to production to scale — not a single rate designed for full deployment volume from day one. Compare the full TCO including minimum commitments, multi-product pricing, and expansion terms, not just the per-auth rate.

What coverage should I expect from an SNA provider?

In mature markets (US, UK, Germany, France, Spain, Mexico), real-time MNO coverage of 80%+ of mobile subscribers is achievable. Ask for coverage broken down by network, not by country, and confirm whether MVNOs are included in headline figures. Ask specifically which MVNOs in your target markets are outside coverage and what the fallback experience is.