SIM swap fraud: detection accuracy, false-positive economics, signal interpretation
SIM swap fraud: detection accuracy, false-positive economics, signal interpretation
A SIM swap detection signal is a timestamp. It says: the IMSI bound to this MSISDN changed at this moment, or in this window. Everything downstream of the signal (the risk decision, the transaction hold, the step-up challenge, the account freeze) is a policy choice made by the relying party. The signal is not a verdict. Treating it as one produces the wrong outcomes on both sides of the error surface: fraud that gets through because "recent swap" was treated as a blocker rather than a ranking feature, and legitimate users locked out because a routine upgrade got read as an attack.
This post describes what the signal actually is, what the academic literature says about its false-positive economics, and how to use it responsibly in an authentication flow.
What SIM swap fraud is, briefly
A SIM swap is the reassignment of an MSISDN from one SIM card to another in the operator's HSS or HLR. It is a routine operation. People lose phones, upgrade handsets, switch to eSIM, and damage SIMs. It is also the primary account-takeover vector for SMS-based authentication. An attacker who can persuade or coerce an operator's customer-service process into reissuing an MSISDN on a SIM they control becomes the legitimate recipient of every SMS one-time password sent to that number, and they can walk through password reset and step-up flows on the victim's behalf.
The attack's structure is consistently documented. It runs in three phases: harvesting enough personal information to answer the operator's KYC questions, inducing the operator to reissue the SIM, and then exploiting the captured number for account takeover. The weakest link across published incidents is not a signalling vulnerability in SS7 or Diameter but the human process at the carrier's retail or support channel. That is why no amount of protocol-layer hardening makes the attack disappear, and why the most useful intervention is not to stop the swap but to detect it early enough that the downstream authentication flow can respond.
The documented financial surface is large. A single-victim loss of $5.3 million in a cryptocurrency theft has been recorded, alongside another six-figure loss in the same cohort. Median losses in published case studies are smaller but still routinely in four and five figures, which is bank-account-sized rather than petty-cash-sized. US legal scholarship has gone as far as arguing that wireless providers should be held to a common-law negligence standard, on the reasoning that carriers are the least-cost avoider of SIM-swap losses. The argument is an open question in law. The engineering implication is that a carrier-side SIM-swap signal is the cleanest place to break the attack, because it happens before the attacker reaches the downstream financial provider.
The signal is a timestamp, not a verdict
A SIM swap signal is a last-changed-at value. The CAMARA SIM Swap API returns either a date-time of the most recent IMSI change on the MSISDN or a boolean indicating whether a change occurred within a caller-specified window. Behind the API, the operator is consulting its own provisioning audit trail, which is the record of writes to the HSS that paired a new IMSI with the MSISDN. External queries via MAP SRI-for-SM against the HLR can also reveal the change, by comparing the IMSI in a current response with the IMSI from a prior query. The cost of that approach is that the exact moment of the swap is unknown, only that it happened between the two probes.
The claim underneath the signal is limited and precise. It says the subscriber identifier bound to this phone number changed recently. It does not say the swap was fraudulent, that the subscriber is at risk, or anything about who is on the other end of the line. Any authentication or transaction decision made from a SIM swap signal is a policy decision made on top of that limited fact.
Teams that get this wrong build one of two failure modes. The first is a hard block: any swap within N hours is treated as a blocker. This prevents some account-takeover attempts and generates a large false-positive population, including everyone who switched to eSIM that afternoon, replaced a broken SIM that week, or ported their number to a new carrier. The second is a silent overlay: the signal is logged for later review but does not change the authentication flow. This catches nothing during the window in which account-takeover is occurring.
The literature points at a middle path. Location-anomaly detection layered on top of the SIM-swap signal can cut the false-positive rate while preserving attack-detection recall. A study of SIM-toolkit-based mobile-money applications in Kenya and neighbouring markets showed that a haversine-distance check, comparing the location of the SIM-swap request against recent connectivity or transaction location with a plausible-speed threshold, runs in about 160 milliseconds per request and materially reduces unauthorised reissuance. The point is not that haversine-distance is the right feature for every deployment. The point is that the SIM-swap timestamp alone is a ranking feature, and pairing it with at least one orthogonal signal (location, device attestation, account-history tenure) is how the false-positive rate gets down to something a customer-support team can work through.
False-positive economics in African fintech
In African fintech the cost asymmetry is sharper. Mobile-money penetration in Kenya, Tanzania, Uganda, Ghana, and increasingly Nigeria means that a blocking SIM-swap policy may stop a person from paying a bill, receiving a salary, or transferring money to a family member in the same hour, not merely delay a login. A false positive in this environment is a failed transaction for a customer who often has no bank-account fallback.
The implication is that the ranking function has to be calibrated to the vertical. A cryptocurrency exchange with a concentrated high-value customer base can afford a tight policy that holds transactions for manual review on any swap within 48 hours, because the downside of a false positive is an annoyed user and the downside of a false negative is a $5 million loss. A mobile-money wallet serving a large agent network cannot. The same signal, applied with the same policy, produces different outcomes by vertical.
The detection literature supports this framing. Published studies of SIM-swap countermeasures consistently recommend a layered approach: a signal at the carrier layer, plus at least one orthogonal contextual signal (location, behaviour, device), plus an escalation path that is something other than a hard block. The recommendation is consistent because the alternative of single-signal hard blocks has a measured false-positive cost that is not acceptable at scale.
The eSIM wrinkle
eSIM changes the attack surface, and not in the direction marketing materials usually suggest. A traditional SIM swap requires the attacker to take physical possession of a SIM card or to induce physical issuance at a retail outlet. An eSIM reissue happens over-the-air through a provisioning server, with no physical token handoff. That removes one class of friction from the fraudulent-issuance step.
In jurisdictions that are rolling eSIM out aggressively, including the UAE, Saudi Arabia, and large parts of the EU, the SIM-swap detection signal gains importance rather than loses it. The carrier's internal provisioning audit trail is still the authoritative record of when the IMSI bound to an MSISDN changed. The mechanism of the swap shifts, but the fact of the swap remains observable at exactly the same place in the operator's subscriber database. A relying party integrating TensorShield's SIM-swap signal does not need to distinguish between physical and eSIM swaps, because the signal returns the same fact either way: the IMSI changed at this moment.
That said, the base rate of legitimate eSIM swaps is higher than the base rate of legitimate physical swaps, which means the policy tuning moves with the market. If 12 percent of a given operator's subscribers swap within a 90-day window because eSIM upgrades concentrate in product launches, a policy calibrated for 2 percent base-rate swaps will generate six times the false-positive volume. The signal does not change. The policy on top of the signal must.
What operator-side data sourcing buys
The claim for a licensed operator offering a SIM-swap signal is that the data is sourced from the home operator's provisioning audit trail rather than inferred from observable signalling. Aggregator-mediated signals are often derived from SRI-for-SM comparisons, where an aggregator probes the HLR periodically, stores the IMSI, and reports a change when the IMSI differs between probes. This works, but the timestamp granularity is whatever the probe interval was. For a relying party running a step-up auth flow in real time, the difference between "swap happened in the last hour" and "swap happened between our last two probes, which were yesterday" is load-bearing.
The operator-side signal comes from the HSS provisioning event itself. The timestamp is exact to the moment the IMSI record was updated. For fintech customers choosing between a signal with minute-level granularity and a signal with last-24-hours granularity, the decision is a function of how tight their own policy window is.
That is the practical product argument. It is not a universal argument. For some relying parties a 24-hour window is fine. The argument is what actually separates a licensed operator from an aggregator that federates HLR probes.
How TensorShield ships the signal
TensorShield's SIM-swap signal returns one of two shapes. The first is a timestamp: the instant of the most recent IMSI change bound to the MSISDN, resolved against the home operator's provisioning data when Tensormobile is the home operator, and resolved against CAMARA SIM Swap API federation when Tensormobile is not. The second is a window-boolean: a true or false for whether a change occurred within a caller-specified number of hours, ranging from one to 2,400.
The output is the signal. The policy is the caller's. The source is published per region (direct HSS audit trail where Tensormobile is the home operator, CAMARA federation where Tensormobile is not, SRI-for-SM probe where neither is available) so that the integrator can weight the signal accordingly. TensorShield does not return "fraud: true" or "fraud: false." There is no such field because there is no such fact available at the signalling layer. What is available is the timestamp and the uncertainty envelope around it.
The signal works as a ranking feature in a risk model. Treated as a verdict, it generates false positives in proportion to the base rate of legitimate swaps, which in an eSIM-heavy or high-churn market is not small. The structured response gives integrators what they need to compose their own policy on top of the timestamp.
