Evaluation guide
How to choose a phone intelligence API for fraud and KYC
The right phone intelligence API gives your fraud or KYC stack a set of signals that are hard to spoof and cheap to query: carrier identity, number type, active status and, increasingly, SIM swap detection. The wrong one returns stale data, hides costs behind seat licences, or locks you into a bundle you did not need. This guide covers eight criteria that separate the two.
What a phone intelligence API actually returns
Before comparing providers, it helps to know what you are buying. A phone intelligence API takes a phone number in E.164 format and returns metadata sourced from carrier network records. The core signals most providers offer are:
- Carrier name: which network operator currently serves the number. Useful for detecting ported numbers and cross-referencing with the country a customer claims to be in. See carrier lookup API for a deeper look.
- Country: the ISO country code the number is registered in.
- Number type: whether the number is mobile, landline, VoIP (fixed or non-fixed), toll-free or voicemail. Number type detection is one of the simplest and highest-value fraud signals at onboarding.
- Active status: whether the number is currently reachable on the carrier network. A disconnected number on a new account is a strong risk signal. More detail in the active status API guide.
- SIM swap detection: whether the SIM card associated with the number was recently changed. This is the highest-value signal for preventing account takeover, and is covered in depth at SIM swap detection for ATO prevention.
Some providers bundle these into a single call. Others split them across separate products with separate pricing. That difference matters more than it looks, and it is the first thing to check.
Eight criteria for comparing providers
These are the questions that matter when you are evaluating a phone intelligence API for a fraud, KYC or compliance use case. They are ordered by how often teams get them wrong, not by importance.
1. Signal coverage: what do you actually get back?
Not every provider returns the same fields. Some return carrier and country but not active status. Some return number type but not SIM swap. A few return everything in a single call.
The question to ask: for the markets you operate in, does a single API call return every signal you need, or will you need to stitch together multiple providers? Stitching is not fatal, but it adds latency, cost and integration surface.
Check coverage per market, not globally. A provider may advertise SIM swap detection but only support it in a handful of countries. Ask which specific markets return real data today and which are listed as coming soon.
2. Data freshness: network-level or cached?
Some providers query carrier records in real time. Others cache results and serve stale data for hours or days. The difference is invisible until a number gets ported, recycled or SIM-swapped between cache refreshes.
For fraud use cases, stale data is worse than no data, because it creates false confidence. Ask the provider whether results are queried live from the carrier network or served from a cache, and if cached, what the refresh interval is. The recycled phone numbers guide explains why this matters for carrier lookups specifically.
3. Pricing model: per query, per seat or bundled?
Phone intelligence APIs use three broad pricing models:
- Per-query pricing: you pay for each lookup. Costs scale linearly with usage. Simple to forecast and simple to audit.
- Seat or platform licensing: you pay a monthly fee for access, sometimes with a query cap. Cheaper at high volume, but you pay even when you do not query.
- Bundled pricing: phone intelligence is sold as part of a larger identity or fraud platform. You get the signal but you also pay for features you may not use.
For a team adding phone signals to an existing stack, per-query pricing is usually the simplest starting point. It avoids committing to a platform before you know the signal is valuable. For a detailed comparison of how pricing works across providers, see carrier lookup API pricing compared.
4. Latency: fast enough for inline decisioning?
If you are checking a phone number during a sign-up flow or before sending an OTP, the lookup needs to complete in time for the result to influence the decision. A lookup that takes three seconds is fine for batch enrichment but too slow for a real-time onboarding check.
Ask for the provider's typical response time, not the best case. Ask whether it varies by market. And test it yourself during a proof of concept rather than trusting the spec sheet.
5. GDPR and data protection: lawful basis and data residency
If you operate in the EU or UK, you need a lawful basis for processing a phone number through a third-party API. Most fraud and KYC lookups fall under legitimate interest, but the provider's data processing agreement needs to support that framing.
Questions to ask: does the provider act as a data processor or a joint controller? Where are the lookup requests processed and stored? Is there a clear data retention policy? The GDPR-compliant telecom data for KYC guide walks through the lawful basis analysis in detail, and the GDPR lawful basis for fraud prevention page covers the legitimate interest argument specifically.
6. SIM swap detection: live, launching or absent?
SIM swap detection is the signal most fraud teams want and the one most often overstated by providers. The challenge is that SIM swap data requires carrier-by-carrier registration and use case approval, which means coverage rolls out market by market rather than all at once.
When a provider says they support SIM swap, ask:
- Which specific markets return a definitive swapped or not-swapped result today?
- What does the API return for markets where SIM swap data is not yet available? A clear "unknown" status is better than a silent omission.
- Is SIM swap billed as part of the standard lookup or as a separate, higher-priced call?
For background on how SIM swap detection works and why it matters for account takeover, see the SIM swap API overview.
7. Automation readiness: can a machine act on the response?
This criterion is becoming more important as fraud decisioning moves from human-operated rule engines to automated workflows and AI agents. A phone intelligence API that is easy for a person to read in a dashboard is not necessarily easy for a machine to act on.
The signs of an automation-ready API: a flat JSON response with predictable field names, explicit null handling (not silent omissions), typed values (booleans for active, enums for number type), and clear documentation of every possible response shape. If the response requires interpretation or human judgement to act on, it slows down any automated pipeline it feeds into.
For more on what this looks like in practice, see phone intelligence tools for AI agents.
8. Documentation and time to first result
The fastest way to judge a provider's developer experience is to measure the time from sign-up to a real API response. Can an engineer get a working lookup running in under an hour, or does it take days of back-and-forth with a sales team to get credentials?
Look for: a publicly available API reference, a working code example in your language, a quickstart guide that covers authentication and a first call, and a free tier or trial that lets you test with real numbers before committing budget.
Running a proof of concept
Once you have narrowed the field to two or three providers, run a structured proof of concept rather than picking on spec sheets alone. A good PoC covers:
Use numbers from actual customers (with appropriate data protection controls) rather than test numbers. Test numbers often return idealised results that do not reflect real-world coverage gaps.
Try ported numbers, VoIP numbers, numbers from smaller MVNOs and numbers from your highest-risk markets. These are where providers differ most.
Track response time under realistic concurrency, not just single sequential calls. Check whether the fields you need are populated for the markets you care about. Count how many lookups return null or unknown for each field.
Some providers bill for failed lookups or charge differently for mobile versus landline queries. Ask for the billing rules before the PoC, then verify them against the actual invoice afterwards.
A note on carrier registration
Providers that source data from carrier networks need to complete a registration and use case approval process with each operator. This is especially true for SIM swap data, where carriers require a documented fraud prevention use case before granting access.
One advantage of using an API provider rather than going direct to carriers is that the provider handles this registration on your behalf. Without a provider, you would need to negotiate access with each carrier individually, a process that typically takes weeks to months per market. This is worth factoring into the build-versus-buy decision.
Request early access