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: confirms the period the phone number has been active with its current provider (or the activation date) and optionally returns 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: (Line) 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 a 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 a 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 a returns latestDeviceChange (timestamp or null), optionally monitoredPeriod (days) - If there is no swap event, the SIM activation date on the network is used.

• 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 → number still belongs to same person; safe to proceed. Note the MNO can only confirm there has not been a change of ownership while the phone number belonged to him, so within the phone number Tenure.

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 submitted on September 15, 2025:

*: Note this is a case an API provider can confirm a contract which is one with other MNO before a port-in date.

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.

• Complementarity: Used together, they provide a stronger signal of suspicious recent change. A legitimate SIM replacement without a device change is lower risk than both happening simultaneously. Both are very useful to keep up to date device fingerprints associated to a given person.

6.2    Tenure vs Number Recycling

• Similarity: Both answer “since-date” questions.

• Difference: Line Tenure within its current operator (phone number activation date) vs Phone Number ownership change within its current operator (phone number recycled and assigned to someone else). Tenure does not specify the source of activation while number recycling only refers to line activations from a contract owner to another one in the same provider (MNO). Also, note that SIM cards can be handed to a person who is not the contract owner (for example, in family contracts where multiple lines are in use by family members but the MNO only keeps track of the contract holder).