> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fraudeg.com/llms.txt
> Use this file to discover all available pages before exploring further.

# FraudEG Risk Scoring: How Your Score Is Calculated

> Learn how FraudEG calculates risk scores using machine learning, velocity, device signals, and behavioral data to assess transaction fraud risk.

Every transaction processed through FraudEG receives a **risk score** — a single numeric value from **0** (lowest risk) to **100** (highest risk) — computed in real time before your application makes an allow, challenge, or block decision. The score consolidates signals from multiple detection layers: your user's device, their behavior during the session, the velocity of recent activity, payment method attributes, and geographic data. Rather than forcing you to reason across dozens of raw signals yourself, FraudEG distills them into one actionable number you can branch on immediately.

## How the Score Is Calculated

FraudEG's scoring pipeline runs each transaction through several parallel analysis layers and combines their outputs using a gradient-boosted machine learning model trained on hundreds of millions of labeled fraud events. Each layer contributes weighted evidence for or against risk.

The layers that feed the final score are:

* **ML model outputs** — a trained ensemble model scores the transaction against historical fraud patterns specific to your industry vertical.
* **Device fingerprint** — the trustworthiness and history of the device used, including whether it has been seen before, associated with fraud, or shows bot/emulator characteristics.
* **Velocity checks** — the rate of transactions, login attempts, or identity submissions from the same user, device, IP address, card, or email within configurable time windows.
* **User history** — the account's prior transaction behavior, chargeback history, and identity verification status.
* **Payment method signals** — BIN-level risk, card type, issuing bank reputation, card freshness, and BIN/email mismatch detection.
* **Geographic signals** — IP geolocation, shipping/billing address distance, high-risk country flags, and proxy or VPN detection.
* **Behavioral patterns** — typing cadence, session navigation, copy-paste usage, and other session-level interaction signals collected via the FraudEG JS snippet or mobile SDK.

## Score Bands

Use the following bands as a starting point for your decisioning configuration. All thresholds are fully adjustable in Platform → Risk Rules.

| Score Range | Risk Level     | Typical Default Action             |
| ----------- | -------------- | ---------------------------------- |
| 0 – 29      | Low risk       | Auto-allowed                       |
| 30 – 59     | Medium risk    | Step-up challenge (3DS, OTP)       |
| 60 – 79     | High risk      | Flagged for review or step-up auth |
| 80 – 100    | Very high risk | Auto-blocked                       |

<Note>
  These thresholds are defaults, not fixed rules. Adjust them per use case in **Platform → Risk Rules** to match your business's risk tolerance and fraud cost model. For example, a high-value wire transfer might warrant blocking at 60, while a low-value digital purchase might allow up to 70.
</Note>

## The `signals` Array

Every score response includes a `signals` array alongside the numeric score. Each signal is a short, machine-readable string that explains which factors drove the score up or down. Use signals to:

* **Display explanations** to your fraud operations team in review queues.
* **Log structured evidence** alongside transactions for audit trails and chargeback disputes.
* **Trigger business logic** — for example, routing a transaction to manual review only when `email_high_risk` is present.

### Common Signal Names

| Signal               | Meaning                                                                                          |
| -------------------- | ------------------------------------------------------------------------------------------------ |
| `device_trusted`     | The device has a positive history and matches the user's known device profile.                   |
| `velocity_normal`    | Transaction and login rates for this user and IP are within expected thresholds.                 |
| `email_high_risk`    | The email address is associated with prior fraud events or disposable domain patterns.           |
| `ip_proxy_detected`  | The originating IP resolves to a known proxy, VPN, or anonymization service.                     |
| `card_bin_mismatch`  | The card's BIN-level issuing country does not match the billing address country.                 |
| `behavioral_anomaly` | Session interaction patterns deviate significantly from this user's established baseline.        |
| `new_device`         | The device has not been seen before for this user account.                                       |
| `bot_detected`       | Automated browser or scripted interaction signals detected during the session.                   |
| `velocity_high`      | An unusually high rate of transactions or attempts has been detected within the lookback window. |
| `geo_risk`           | The transaction originates from or targets a high-risk geographic region.                        |

## Customizing Thresholds in the Rules Engine

The risk rules engine lets you override default score-band behavior with precise, no-code rules. You can create rules that combine a score range with additional conditions — for instance, block only when the score is above 70 **and** `ip_proxy_detected` is present, or challenge whenever `new_device` appears regardless of score.

To configure rules, navigate to **Platform → Risk Rules → New Rule** and select:

1. **Trigger condition** — score range, signal match, or both.
2. **Scope** — apply the rule globally or to a specific product area (checkout, login, onboarding).
3. **Action** — allow, challenge, or block.
4. **Priority** — rule evaluation order when multiple rules match.

Changes to rules take effect within seconds and apply to all subsequent transactions without a code deployment on your side.

## Sample Score Response

<CodeGroup>
  ```json Score Response theme={null}
  {
    "transaction_id": "txn_4kR9mXpL2vQw",
    "score": 72,
    "risk_level": "high",
    "decision": "challenge",
    "signals": [
      "new_device",
      "ip_proxy_detected",
      "velocity_normal",
      "behavioral_anomaly"
    ],
    "recommended_action": "3ds_challenge",
    "processing_time_ms": 38,
    "created_at": "2024-11-14T09:22:11Z"
  }
  ```
</CodeGroup>

The `score` field is the primary value to branch on in your application. The `signals` array gives you the supporting evidence. The `decision` field reflects the outcome of your configured rules engine — see [Automated Fraud Decisioning](/concepts/decisioning) for how to consume and act on decisions.