# Fraud console user guide

> Fraud console concepts: privacy, device integrity, identifiers, and the behaviors, warnings, and frauds that Ironchip detects, with worked examples.

URL: https://docs.ironchip.com/en/fraude/consola/guia-de-usuario/

This guide explains the concepts you need to read the fraud console: how Ironchip handles privacy and recognizes usual places, what the identifiers mean, and which behaviors, warnings, and frauds the engine detects, with examples.

To learn about risk levels and the evidence behind each assessment, see [Risk assessment](https://docs.ironchip.com/en/fraude/conceptos/evaluacion-de-riesgo/).

## Privacy

Ironchip develops all its products following the **privacy by design** framework: privacy is built into the solutions at every level, from the initial idea to the product launch.

The technology prevents access to information that could re-identify users. Ironchip **does not collect**:

- Unique static device identifiers, such as IMEI or MAC.
- Associated accounts, such as email or phone number.
- Civil identification data, such as name or social security number.
- Sensitive data: ethnicity, religion, political opinion, membership in religious, philosophical, political, or union organizations, and data about health, sex life, genetics, or biometrics.

The solution needs to collect data from mobile devices through an SDK. Once authorized, the Ironchip SDK starts collecting data without personally identifying any user. Users can **deny data collection** by opting out, which disables collection for them.

For more information, read the [privacy policy](https://www.ironchip.com/en/privacy-policy).

## Usual places and safe zones

### How Ironchip knows a place is usual

By repetition: once **several successful transactions** have been made from a place, it is considered usual for that user and device. Each user can have several safe or usual places, and recurring events or transactions from the same place are needed to classify it as such.

If user, device, and location are correctly correlated, Ironchip verifies that the user is who they claim to be and that they are operating from a usual place.

[Image: Diagram of user, device, and location data with the normal behavior, irregular behavior, and no secure behavior zones]

### What a safe zone is

A safe zone is an area from which the user usually operates. A fraudulent operation tends to take place far from safe zones. This dimension is added to fraud detection systems without violating customer privacy, because the system does not allow reverse geolocation.

The safe zone concept is complemented by the Ironchip device recognition system, which assigns a fingerprint linked to a unique, anonymous device.

## Business concepts

- **Transaction**: any customer-initiated action that needs to be analyzed for fraud detection.
- **Report**: the written analysis of the transaction, which specifies the fraud case.
- **Report details**: the context used to generate the report.
  - The user, device, and location information.
  - Related transactions (with a common user, device, or location).
  - Users who have used the same device before.
  - Users who have been reported at the same location before.
- **Reported cases**: the different results an analysis can report, based on the use cases.

## Device integrity

The Ironchip SDK sends fake GPS and root (or jailbreak) information to determine device integrity.

- **Fake GPS**: mobile apps that set a fake location on a user's device. Apps installed on the device receive illegitimate location data instead of the real location.
- **Root (or jailbreak)**: the process that gives full access to the mobile operating system, meaning access to permissions that let you change advanced elements of the device system.

:::caution[Why it matters]
The greatest risk of fake GPS for companies is its use for fraud: pretending to reside where you do not, committing identity fraud, and misleading market intelligence with false inferences.

A rooted phone cannot receive official updates and lets the user manipulate the device at will. Modified devices may contain malicious apps and modifications made for fraud.
:::

Ironchip applies different methodologies to identify forged GPS data and rooting or jailbreaking signals. These methodologies are part of the data returned by the Ironchip APIs in several use cases.

## Identifiers

- **Application ID**: the identification number the Ironchip SDK uses to identify your app. Ironchip generates it and it cannot be changed.
- **Transaction ID**: uniquely identifies each transaction. Ironchip customers generate it to represent each unique transaction in their app. It is required by the Transaction API and is used with the Report API to track the transaction.
- **User ID**: uniquely identifies each user account. Ironchip customers generate it to represent each unique user of their app. It is required by the Transaction API and is used with the Report API to track who makes the transactions.

## Behaviors

### New user

A new user on the platform, so there is no prior information about the user, device, or location.

[Image: New user diagram with the user, device, and location data circles in gray]

### Common usage

A previously registered user operates as usual, with their device and location already registered.

[Image: Common usage diagram with the user, device, and location data circles highlighted]

## Warnings

### Device swapping

Occurs when the user does not use their usual device.

[Image: Device swapping diagram with the user and location data highlighted and the device data in gray]

**Result**: warning, device swapping.

**Example**: the user makes a transaction with a new device.

Requirements:

- **User-1** must be registered.
- **Device-2** must be a new device.

Procedure:

1. **User-1** logs in and makes a transfer with **Device-1**.
2. **User-1** logs in and makes a transfer with **Device-2** from **Location-1**.

### Location swapping

Occurs when the user does not operate from their usual location.

[Image: Location swapping diagram with only the location data highlighted]

**Result**: warning, location swapping.

**Example**: the user makes a transaction from another user's usual location.

Requirements:

- **User-1** must be registered and have made transfers.
- **User-2** must register with a new device.

Procedure:

1. **User-1** logs in and makes a transfer from **Location-1**.
2. **User-2** registers with a new device.
3. **User-2** logs in and makes a transfer from the same location as **User-1**.

## Frauds

### Location fraud

Ironchip can detect location fraud. When a location is registered, its radio fingerprint is stored and is always tied to a geoposition. In later operations, Ironchip always compares these two variables. If they do not match, it assumes the location is fraudulent.

[Image: Location fraud diagram with the user, device, and location data circles]

### Phishing

Phishing is a social engineering attack often used to steal user data, including login credentials and credit card numbers. It occurs when an attacker repeatedly defrauds through SIM swapping.

[Image: Phishing diagram shown as two repeated SIM swapping attacks on user, device, and location data]

**Result**: fraud, phishing.

**Example**: a user makes a transaction with another user's device from an unusual location.

Requirements:

- **User-1** must be registered.
- **User-2** must be registered.
- **Location-3** must be a new location.

Procedure:

1. **User-1** logs in and makes a transfer with **Device-1**.
2. **User-2** logs in and makes a transfer with **Device-2**.
3. **User-2** logs in and makes a transfer with **Device-1** from **Location-3**.

### SIM swapping

SIM swapping fraud is an account takeover scam that exploits a weakness in some forms of two-factor authentication, where a call or text message to a mobile phone is the second factor.

**Result**: fraud, SIM swapping.

**Example**: a user makes a transaction with another user's device from their usual location.

Requirements:

- **User-1** must be registered.
- **User-2** must be registered.

Procedure:

1. **User-1** logs in and makes a transfer with **Device-1** from **Location-1**.
2. **User-2** logs in and makes a transfer with **Device-2** from **Location-2**.
3. **User-2** logs in and makes a transfer with **Device-1** from **Location-1**.

### Synthetic identity

**Synthetic identity fraud (SIF)** is the use of a combination of personally identifiable information (PII) to fabricate a person or entity in order to commit a dishonest act for personal or financial gain. In other words, it is a combination of fabricated credentials where the implied identity does not belong to a real person.

[Image: Synthetic identity diagram with only the location data highlighted]

**Result**: fraud, synthetic identity.

**Example**: a new user registers with a device already registered by another user.

Requirements:

- **User-1** must be registered and have made transfers.
- **User-2** must register with **User-1**'s device.

Procedure:

1. **User-1** logs in and makes a transfer with **Device-1**.
2. **User-2** registers with **Device-1**.
3. **User-2** logs in and makes a transfer with **Device-1**.
