Buyer Guide

How to Evaluate a Network API Provider for Fraud and KYC

Most network API pilots stall for structural reasons rather than technical ones. Before committing to a provider, check four things: how they define coverage, whether pricing scales with your call pattern, how many integrations you actually end up managing, and how honestly they report a signal they cannot return. Get those four right and the technology question mostly answers itself.

Ask for coverage by market and by operator, not a headline number

"Broad coverage" usually means broad somewhere else. A provider connected to three operators in a market with fifteen will happily quote you an aggregate reach figure that says nothing about whether your actual customer base is covered. Ask for the named operator list per market you care about, and ask what happens for a number outside that list: a silent failure, a generic error, or an explicit status.

The honest answer is a tri-state response, not a binary one. A SIM swap check should be able to say it does not know, distinctly from saying nothing happened. If a provider's API only ever returns a positive or negative result, ask what it returns when the underlying carrier has no data, because "no swap detected" and "no data available" are very different things to build a fraud decision on.

Match the pricing model to when you actually need to call it

Flat platform fees and seat-based pricing assume you're calling the API constantly. Most fraud teams aren't. The useful pattern is calling a signal like SIM swap at specific decision points, a new device, a high-value transfer, a geo mismatch, rather than on every transaction. If your provider's pricing doesn't scale down with that usage pattern, the cost model fights the way you'd actually deploy it.

Per-successful-query pricing solves this by construction: at 0.05 USD per successful lookup, cost only accrues where you're actually using the signal, and there's no annual commitment or monthly fee sitting underneath it regardless of call volume. See cost control on per-query APIs for how to think about caching on top of that.

Count the integrations you'll actually be managing

Operator fragmentation is real: a handful of markets can mean a double-digit number of individual operators, each with its own onboarding, contract and data format if you go direct. The question to ask an aggregator is not whether they cover an operator, but whether that coverage sits behind one API contract or whether you're still managing several underneath their layer. See CAMARA versus direct carrier APIs for the trade-offs between routes.

Check what an honest "we don't know" looks like in the response

A response contract that can only say yes or no will eventually lie to you by omission. Here's what a real lookup returns today for a GB number, ahead of SIM swap going live in that market:

{
  "phoneNumber": "+447700900000",
  "active": true,
  "carrier": "EE",
  "country": "GB",
  "numberType": "mobile",
  "simSwap": "UNKNOWN", // carrier registration in progress for GB
  "simSwapAt": null
}

UNKNOWN is a real, distinct value here, not a placeholder. It tells a risk team to fall back to another signal rather than silently treating an unswapped and an unchecked number the same way. See the response field reference for the full contract.

Check what happens when your use case isn't in the standard catalogue

SIM swap, number verification and carrier lookup cover most fraud and onboarding use cases, but not all of them. If you have a use case outside the standard set, ask upfront whether the provider can extend to it and on what timeline, rather than discovering the gap mid-integration. This matters less if you've scoped the evaluation tightly around the signals you actually need for fraud decisioning before you start comparing providers.