1.  Executive Summary

This whitepaper compares four CAMARA APIs that deliver trust/risk signals around a mobile phone number:

• SIM Swap: provides information about the most recent change of the subscription profile associated with a phone number (MSISDN)—including both physical SIM and eSIM. The API either returns the timestamp of the last change or a boolean indicating whether a change occurred within a specified look-back window. Note the API is form-factor agnostic; it reflects operator-recorded changes to the SIM/eSIM subscription profile tied to the MSISDN. Administrative re-provisions may or may not be counted as “changes” depending on each operator’s policy."

  • Purpose: prevent SIM hijacking (attackers intercepting SMS/OTP, Number Verification, or pretending to be the victim on a phone call).

• Device Swap: detects whether the phone number is now used on a different physical device. It mirrors SIM Swap’s I/O shape (timestamp or boolean-in-window), but the tracked event is the device change, not the SIM.

  • Purpose: detect access or requests from an unexpected handset.

• Tenure: checks whether the phone number has had continuous service since a specified date, returning a boolean and, optionally, the contract type (postpaid, prepaid...).

  • Purpose: use a phone number tenure as a proxy for trustworthiness or fraud risk.

• Number Recycling: checks whether a phone number has changed ownership (if has a different contract holder) since a specified date with the same provider, returning a boolean.

  • Purpose: avoid sending OTP/data to a new owner of a recycled number, avoid locking of accounts protected by SMS 2FA due to outdated number, and flagging outdated CRM contact details.

Unambiguous overlap statements:

• SIM Swap and Device Swap share the same endpoints patterns and response structures; they differ only in what changed (SIM vs device).

• Tenure and Number Recycling both answer “since-date” questions, but different focus: Tenure measures the period of time the phone number has been active with its current provider (and will reset in case of portability), while Number Recycling checks whether the ownership of the phone number has changed or not since the given date with its current provider.

2. Scope & Sources

This document focuses on functional semantics, I/O, error families, and practical interpretation. Sources: CAMARA Github (link), CAMARA Wiki Page (link) and CAMARA website (link).

3. Comparative Matrix – Data Semantics

The following table positions the four APIs side by side, focusing on what question they answer, the kind of data they return, the time horizon they cover, and how the signal is usually applied in risk or trust decisions. This helps highlight their distinct roles and avoid confusion when evaluating overlaps.

4. API Deep Dives

4.1.    SIM Swap (v2.1.0)

Data provided:

• latestSimChange (timestamp) or null if no visible changes within the operator’s observable window.

• Optional monitoredPeriod (days) when no date is returned (use to interpret null).

• /check returns swapped (true/false) evaluated over a window in hours (e.g., 24, 48, …).

How to Read It:

• latestSimChange = timestamp → SIM change; the more recent, the higher risk for SMS‑based authentication.

• latestSimChange = null + monitoredPeriod = N → no SIM swap events within N days (not “no data exists”).

• swapped = true in X‑hour window → apply friction (challenge, deny, etc.).

If the operator’s policy forbids keeping older data, you may see null even if the line exists; use monitoredPeriod for context.

Endpoints and I/O:

• POST /retrieve-date returns latestSimChange (timestamp or null), optionally monitoredPeriod (days). If there is no swap event, the SIM activation date on the network is used.

• POST /check an input maxAge (1-2400 hours), returns swapped (boolean). If the requested window exceeds local policy/retention, expect 400 OUT_OF_RANGE with a human-readable reason.

Example – How SIM Swap responses should be interpreted:

Given following situation for several lines:

Open

We expect following result from the API:

4.2. Device Swap (v1.0.0)

Data provided:

• latestDeviceChange (timestamp) or null with optional monitoredPeriod (days), which indicates the maximum observable period supported by the operator due to local data-retention regulations or internal privacy policies.

• /check returns swapped (true/false) over a window in hours.

If no swap ever occurred and policy allows, it may return the first time the number was used in a device.

How to Read It:

• Same as SIM Swap but the event is “device change”. A Very recent change might imply higher impersonation risk or new device used by legitimate user (it could be useful to update device fingerprinting).

• null + monitoredPeriod means “no events in that observable period.”

Endpoints and I/O:

• POST /retrieve-date returns latestDeviceChange (timestamp or null), optionally monitoredPeriod (days). If no device swap has ever occurred and the operator supports it, the API may return the first time the phone number was used in a device; otherwise it may return null and optionally monitoredPeriod

• POST /check a input maxAge (1-2400 hours), returns swapped (boolean).

4.3. Tenure (v0.2.0)

Data Provided:

• tenureDateCheck (true/false) answering “Has the phone number been active since tenureDate?”

• Optional contractType: PAYG, PAYM, Business.

How to Read It:

• true → mobile phone number has been active since that date (tenure ≥ threshold).

• false → more recent phone number activation or interruptions (change from postpaid<->prepaid): higher reputational risk.

• contractType useful for different policy tiers (prepaid, postpaid, enterprise). There is a higher correlation of frauds with origin in prepaid plan types, it is a signal of higher risk as well.

Endpoints and I/O:

• POST /check-tenure a input tenureDate (YYYY-MM-DD), optional phoneNumber (two-legged only); output tenureDateCheck (boolean) and optional contractType (PAYG/PAYM/Business).

Examples:

Given following situation for several lines:

Open

Note on 0608 line: on Jan 1st, 2024 we have a MSISDN change for this line. The 0608 is not anymore used for this line and 0604 is the new number. It was intentionally included to illustrate a non-existent or deactivated MSISDN, where /check-tenure returns 404 not found (no active record within the operator’s current numbering plan).

We expect following result from the API:

4.4. Number Recycling (v0.2.0)

Data Provided: phoneNumberRecycled (true/false) compared to a specifiedDate.

How to Read It:

• true → ownership (contract holder) within the same MNO changed since the specifiedDate. Treat as potential misdelivery risk. Note a port-in from other MNO is not mapped as a change of ownership as the owner could be still the same, neither is it a new phone activation as could be the first time the number is assigned to someone.

• false → no ownership change has occurred since that specifiedDate, provided the reference date is processable for the provider.

• 400 OUT_OF_RANGE → the specifiedDate is not a processable reference point for that provider in that period (e.g., no active subscriber at that date / unassigned gap / history not available). This does not simply mean “too old”.

Endpoints and I/O:

• POST /check a input specifiedDate (YYYY-MM-DD), optional phoneNumber (two-legged only); output phoneNumberRecycled (boolean).

Examples:

Given following situation for several lines:

Open

We expect the following result from the API request, call triggered 15 Sept 2025:

Note:

• OUT_OF_RANGE indicates that the provided specifiedDate is outside the API provider’s supported historical/evaluable window and is therefore not processable for that provider (e.g., no active subscriber at that date / unassigned gap / history not available for that period) - Sync26 meta-release will close this gap

• The true outcome in UC0607 @ 2021-12-15 assumes the provider can still evaluate that reference date. If it is outside the supported window (e.g., retention/implementation limits), it should be treated as 400 OUT_OF_RANGE (if number was not active on the date checked or was owned by another API Provider) rather than asserting a boolean.

5.  Where to Use Them

Each API brings value in different industries depending on the type of risk they face. Below are examples of how companies can apply the signals in real customer journeys.

6.  Overlap, Differentiation & How They Complement Each Other

The four APIs may look similar in structure, but their value lies in what type of change or continuity they track and how these signals complement each other.

6.1    SIM Swap vs Device Swap

• Similarity: Both expose the same endpoint patterns (/retrieve-date, /check) and responses (timestamp or boolean-in-window). Both could produce a positive response if the mobile phone is lost or stolen and it’s replaced by a new one.

• Difference: The event type differs: SIM replaced vs Device changed.