Porting and SIM swap are both routine and both a reason to trust a number less right now, and a check built only to confirm the number is real answers neither.
Not "is this a valid number", and not even "has this number been ported or swapped". It is do you trust this number as a security channel for this transaction, at this moment, because a number proves control and control transfers in minutes without anything visible changing. Every signal below is a partial answer to that one question.
A phone number is an authentication channel and a fraud sensor at the same time, and most stacks have bought only the first half. The channel that carries your one-time codes is the same channel an attacker takes over first, so the honest design is one where the channel also reports whether it can be trusted right now.
Number intelligence covers line type, tenure, porting history, recent SIM swap, known exposure in breach data, and whether the line is currently in service. Each is a different question with a different answer, set out below.
Delivery runs through the same integration: one-time codes and step-up prompts over the messaging channel a customer already uses, and number masking so two parties reach each other without either learning the other's number. Both are activated per market.
Putting the two together is the point. Sold apart, these are a messaging product and a data product. Sold together, the risk check gates the channel: a code is not dispatched to a number that just changed hands, and a case that fails reachability steps up instead of timing out silently while somebody waits for a message that will never arrive.
Used as an identification signal inside KYC and as a standalone risk signal inside Risk Intelligence, one canonical check either way.
A phone check that returns one score has combined several answers into one and discarded which of them fired. That is tolerable until an analyst has to explain a decision, and then it is the whole problem. The middle column is the one most of the market leaves out.
| Signal | What it proves | What it cannot prove | When it is worth asking for |
|---|---|---|---|
| Fraud risk assessment on the number | That the number carries characteristics associated with abuse, taken together rather than one at a time. | Who is holding the phone, and whether this particular transaction is the bad one. | As a default on every inbound case, because it is the one signal that says something about a number you otherwise know nothing about. |
| Number age and tenure | That the number has an established history rather than being freshly issued or recycled from somebody who let it lapse. | That the history belongs to the person in front of you, since lapsed numbers are reassigned to somebody new. | At account opening, where a number with no past is the least demanding kind of disposable identity to obtain. |
| SIM swap and porting history | That control of the number moved to a different device or a different carrier, and roughly when it moved. | Whether the move was fraud or an ordinary upgrade, holiday or carrier switch, because most of them are ordinary. | Just before anything a one-time code is meant to protect, since a swap is only interesting relative to what happens next. |
| Breach exposure of the number | That the number appears in known compromised data, so it is available to somebody other than its owner. | That it has been used, or that the exposure is recent, since breach corpora surface long after the event they describe. | On step-up decisions and on password or credential recovery, where reuse of exposed data is the actual attack. |
| Live activity and reachability | That the line is in service and the device is reachable on the network. | That the reachable device is the enrolled one, which is precisely what a swap changes. | Before sending anything, so a code is not dispatched into a number that will silently absorb it. |
None of these is the phone check. Each answers one question, and the reason to keep them apart is that your policy needs different ones at different moments in a case.
Phone intelligence reaches 230 countries and territories, on direct carrier and telecom data rather than lookup lists, so the answer reflects the line's current state and the carrier that holds it now.
A just-ported number still passes a check that only confirms it is real. That is exactly the moment a SIM-swap fraud happens. The failure runs in the other direction too, and it is the one nobody counts: treat every porting event as fraud and you block people who changed carrier, which is ordinary behaviour being punished. That cost arrives as support volume and abandoned applications rather than as a fraud number anybody reports.
Phone intelligence is at its best deciding when to escalate. At full strength, it shows that somebody controls this line and how recently that control changed, which is different from proving who they are.
A swap or a porting event is not a fraud finding. The ordinary case dominates by a wide margin, and a product that implies otherwise is a false-positive machine sold as a fraud tool. What the signal actually does is change what the next step should cost: a code becomes a step-up, a step-up becomes a review.
Where you need to know who somebody is rather than whether to trust their line, use data verification, photo ident or an identity they already hold. Phone intelligence decides which of those a case has earned.
Which signals block, step up, or are logged only, set per market and per use case. The temporal part is what makes it operational: the same signal means different things at different distances from the event, so a threshold here is a window as much as it is a value. A swap six months ago is history. The same swap twenty minutes before a password reset is the case.
Every one-time code you send is a cost and a drop-off point, and the ones sent into numbers that will never answer are pure loss. Gating delivery on whether the line is reachable and whether it just changed hands cuts the wasted sends and takes the takeover cases out of the flow before they become chargebacks and written-off accounts.
The individual factors, not a combined score with no way to see inside it. When a decision is questioned, the file has to show which signal fired, what it said, and how far from the transaction it sat, because "the phone check flagged it" is not an explanation anybody can defend.
Numbers change hands legitimately all day, so the thresholds are the work. Too tight and the support queue fills with customers who switched carrier; too loose and the channel you authenticate over is one an attacker already holds. Both settings are configurable per market, which means both are yours to tune rather than a vendor default you inherit.
Written once, used from both programs. A change to the underlying data reaches every place phone risk is checked instead of drifting between two integrations that started identical and stopped being identical. The risk signals and the delivery channel come from the same integration, which is what lets one govern the other rather than running beside it.