SIM Swap Detection
How recent is too recent: interpreting SIM swap age for risk decisions
A SIM swap that happened yesterday carries a very different risk weight to one that happened six months ago. The simSwapAt timestamp in the Telebase response lets you set recency windows rather than treating all swaps the same. This page covers how to read the timestamp, which thresholds make sense for which actions, and how to avoid over-blocking legitimate customers who upgraded their handset.
What simSwapAt returns
When SIM swap detection returns SWAPPED, the simSwapAt field contains an ISO 8601 timestamp for the most recent SIM change registered by the carrier: for example, "2026-06-29T14:22:00Z". When the result is NO_SWAP or UNKNOWN, simSwapAt is null.
The timestamp precision varies by carrier. Some return it to the minute. Others return it to the day only. Build your logic to handle day-precision timestamps correctly: a timestamp of 2026-06-29T00:00:00Z should be treated as "sometime on 29 June" rather than "midnight exactly."
simSwapAt field semantics
simSwapAtis a string or null. It is an ISO 8601 datetime string whensimSwapisSWAPPED, andnullin all other cases.- The age of the swap is
Date.now() - Date.parse(simSwapAt)in milliseconds. Convert to hours for threshold comparisons. - Carrier precision varies. Some carriers report to the minute; others to the day. A day-boundary timestamp is not midnight.
Risk thresholds by recency window
There is no universal cutoff. The right threshold depends on the risk profile of the action being authorised. The following table reflects common practice across fraud teams in fintech and crypto, not a regulatory requirement.
| Window | Risk level | Recommended action |
|---|---|---|
| Under 24 hours | High | Block OTP dispatch and high-value actions. Require an alternative verification channel (email, ID document). Most SIM swap fraud is executed within hours of the swap. |
| 24 to 72 hours | High | The 72-hour window is the most commonly cited threshold in fraud policy. Step up to a secondary channel or hold the action for manual review. Do not block outright without a secondary signal. |
| 72 hours to 7 days | Medium | Flag for additional friction. A swap in this window is more likely to be a legitimate handset upgrade but warrants monitoring. Consider requiring re-authentication rather than blocking. |
| Over 7 days | Low | Treat as normal in most contexts. A swap this old is unlikely to be connected to an in-progress attack on the current session. Continue normal authentication. |
These thresholds are starting points. Review against your own fraud data after the first 30 days of live signal collection.
Why 72 hours is the standard reference point
The 72-hour window appears repeatedly in published fraud guidance and internal risk policies because it reflects the operational pattern of SIM swap fraud. An attacker who has successfully swapped a SIM needs to exploit it before the victim notices and contacts their carrier. The window between swap and fraud attempt is typically measured in hours, not days. By 72 hours, most attacks have either been executed or abandoned.
In practice, when a compliance team asks whether a product "checks for recent SIM swaps," a 72-hour recency window is usually the scope they have in mind. See SIM swap signals for FCA affordability and lending checks for the regulatory context.
Combining simSwapAt with other signals
Recency alone is a useful signal but works best combined with the broader context of the session. A 48-hour-old swap on a longtime customer making a routine payment carries a different weight to the same swap on an account opened three days ago attempting a first withdrawal.
A swap within 72 hours on an account less than 7 days old is a high-confidence fraud indicator. Both signals are available from your own data; the swap timestamp comes from Telebase.
Apply tighter recency windows to irreversible, high-value actions. A 7-day threshold may be appropriate for a £500 transfer; a 24-hour threshold is more appropriate for a £10,000 withdrawal or a crypto wallet address change.
A recent swap on a mobile number is a different risk profile to the same swap on a non-fixed VoIP number. Non-fixed VoIP numbers should be escalated at onboarding regardless of swap state. See number type detection for fraud prevention for how to layer these signals.
Avoiding over-blocking: legitimate swap reasons
Most SIM swaps are not fraud. Common legitimate reasons include upgrading to a new handset, switching to an eSIM, changing to a different carrier plan and replacing a lost or damaged SIM. Over-blocking on the basis of swap recency alone creates unnecessary friction for legitimate customers.
The practical mitigation is a stepped response rather than a hard block. For swaps in the 24-to-72-hour window, route to a secondary verification channel: an email OTP, a video ID check or a security question. For swaps under 24 hours combined with a high-value action, consider a temporary hold pending a brief manual review. Reserve outright blocking for the narrowest risk profile: very recent swap plus high-value action plus short account age.