# Vetting inbound leads: the phone signals that flag obvious fraud > Learn which phone-validation API fields fintech and crypto teams should score at signup to catch fraud before it costs you anything. Published 2026-07-20, updated 2026-10-03 by Marcus Whelan. Canonical: https://checkthatphone.com/blog/vetting-inbound-leads-the-phone-signals-that-flag-obvious-fraud ## The lead that looked fine until it wasn't Picture a crypto exchange that onboards 400 new users on a Tuesday. Forty of them pass ID checks, verify a phone number, and initiate withdrawals within 72 hours. The phone numbers all look like US mobiles. None of them are. They're VoIP lines spun up through a reseller, tied to synthetic identities, and the accounts are drained before the compliance team flags the pattern. The frustrating part of a pattern like that is that the signal is there at signup. The phone data would show it. Nobody looks. The fix isn't a longer KYC form. It's scoring the phone number the moment it arrives, before you send an OTP, before you write a row to your database, before you spend a dollar on verification infrastructure for someone who was never a real customer. ## Why is VoIP the clearest fraud signal? Because VoIP numbers are cheap, quick to obtain in bulk and easy to discard, which is exactly what someone creating many fake accounts needs. Not every VoIP number belongs to a fraudster. Plenty of legitimate users have Google Voice or a business line through RingCentral. But in fintech and crypto onboarding, a VoIP number is worth flagging. The field you want is `dipCarrierSubType`. Where `dipCarrierType` tells you the broad category (`mobile`, `landline`, `invalid`, or `undefined`), `dipCarrierSubType` goes narrower: VoIP shows up as `IPES` (IP-enabled service), alongside values like `WIRELESS`, `PCS`, `CLEC` and `WRSL` (wireless reseller). Paired with `dipCarrier`, which names the actual carrier, you can tell a number on a VoIP provider from one on a major wireless carrier. In practice, I'd build a tiered response here rather than a binary block. A first-time signup with a VoIP `dipCarrierSubType` and a small deposit might just get flagged for manual review. A VoIP number submitting a $10,000 wire request on day one should hard-stop until a human sees it. The cost of a false positive is a 10-minute delay. The cost of ignoring this signal is the scenario I opened with. You also want `dipCarrierType` in this check. If the number comes back as `landline`, it can't receive SMS OTPs in the normal sense, and it's a strong indicator the user either mistyped or is trying to game your verification flow. Mobile is the expected value for almost every real consumer signup. ## What about SIM swaps? Not the classic kind. In a SIM swap, the attacker convinces the victim's carrier to move the number to a new SIM they control, so the number stays on the same carrier and carrier data doesn't change. Catching that needs a dedicated SIM-swap signal, which this API doesn't provide. What carrier data can show is a port-out: the number moving to a different carrier. `dipPorted` is `"true"` when a number sits with a different carrier than the one it was originally assigned to. It doesn't say when the port happened, and most ported numbers belong to people who simply switched carriers, so on its own it's a weak signal. Combined with other factors, such as an account less than 30 days old attempting a withdrawal, it's worth pausing on. The more useful application in crypto is ongoing monitoring, not just signup. Store the carrier snapshot (`dipCarrier`, `dipOcn`, `dipPorted`) at registration and re-query the number on a sensitive action (large withdrawal, password reset, linked bank account change). If the carrier has changed since registration, the number has been ported since you last saw it, which is exactly the port-out pattern you want a human to look at. That's a check worth running in real time against `POST https://api.checkthatphone.com/v1/lookup` with your `Authorization: Bearer ` header. [Improving 2FA with phone validation](/blog/improve-2fa-phone-validation) covers the login side of this. ## IP and phone geography mismatch Pass the user's IP in the `ip` field and the geo fields (`geoCountry`, `geoState`, `geoCity`, `timezone`) describe where that IP is, with `geoSource` set to `"ip"`. `ipResult` only tells you whether the IP itself is valid (`"valid-v4"` or `"valid-v6"`). The comparison is yours to make: IP location against the phone's area code and the address the user gave. A mismatch here doesn't mean fraud. Someone signing up from a coffee shop in Miami with a Chicago area code is completely normal. But a signup IP resolving to a data center in Eastern Europe paired with a phone number ostensibly from a US carrier is a different story. Build a simple coherence check from those fields. If the IP country doesn't match the phone geography and the timezone is inconsistent with both, that's three signals pointing the same direction, and a combination worth routing to its own review queue. Data center IPs are the clearest version of this. Consumer residential IPs moving around is normal. An IP registered to a cloud provider's data center is not a human sitting at a computer. Our API doesn't classify IPs that way, so take that signal from an IP-intelligence source you already use. ## Building a score, not a binary block The worst implementation mistake is treating any one of these fields as a kill switch. You'll block real users. The better approach is additive scoring. Here's a simple starting model: - `dipCarrierSubType` is `IPES` (VoIP): add 30 points - `dipCarrierType` is not `mobile`: add 25 points - `dipPorted` is `"true"` on a new account: add 20 points - IP-derived `geoState` or `geoCountry` doesn't match the phone or the stated address: add 15 points - The IP belongs to a data center (from your IP-intelligence source): add 25 points Over 50 points: route to manual review. Over 80 points: require additional verification before any financial action. Over 100: consider declining the session outright. You tune these thresholds against your actual fraud data over the first few weeks. The numbers above are a starting point, not gospel. Your fraud pattern will differ from a competitor's based on your product, geography, and acquisition channels. ## Running this at scale For real-time signup flows, you call `POST https://api.checkthatphone.com/v1/lookup` per number as it arrives. Latency is low enough that you can do this synchronously before returning a response to the client. The user never sees it. For batch work, like auditing a list of existing accounts you're worried about, or cleaning up a lead list before a campaign, the right tool is [bulk CSV verification](/bulk-phone-validation) through the CheckThatPhone dashboard. Upload your file, and we deduplicate it and run the carrier dip, line type, and any add-ons you've enabled across every unique number, then return a downloadable result file. The upload and the result file are hard-deleted within 24 hours, which matters if you're handling consumer data under any state privacy law. If you're also thinking about downstream liability from contacting any of these numbers, the litigator scrub add-on is worth running at the same time. Pass `litigatorFilter: true` in your request and you get back `litigator`, `litigator_type`, and `litigator_name`. A fraudulent number that also belongs to a serial TCPA plaintiff is a very specific problem you don't want to discover after the fact. See the [TCPA litigator scrub use case](/use-cases/tcpa-litigator-scrub) for how teams integrate this. ## What this doesn't catch Phone validation is one layer, not a complete fraud stack. It won't catch a fraudster using a real postpaid mobile number they bought off a grey market. It won't detect a synthetic identity if the phone number attached to it is otherwise clean. And it won't catch a classic SIM swap, which leaves the number on the same carrier. Those are real limitations. But catching the VoIP farms, the obviously mismatched geos, and numbers that changed carrier right before a large transaction removes a lot of low-effort fraud without touching legitimate user experience. That's the trade worth making. If you want to see what the fields actually return for a number before building your scoring logic, [the docs](/docs) walk through the full response schema, and [choosing phone validation API features](/blog/choosing-phone-validation-api-features) covers what to look for in a provider. Pricing for the lookup and add-ons is on the [pricing page](/pricing). For a broader view of how this fits into identity verification workflows, the [KYC phone verification use case](/use-cases/kyc-phone-verification) covers the integration pattern in more detail, and [phone validation for KYC in fintech](/blog/phone-validation-kyc-identity-verification-fintech) covers the compliance side. --- CheckThatPhone is a phone validation API for US and Canada numbers: https://checkthatphone.com (docs: https://checkthatphone.com/docs.md, pricing: https://checkthatphone.com/pricing.md).