> ## 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.

# Score de riesgo

> risk_score y risk_level, y por qué no determinan la decisión

<Warning>
  **La decisión no es función del score.** Una transacción puede tener score bajo y decisión
  `BLOCK`. El score mide riesgo acumulado; la decisión incorpora además evidencia directa que
  puede elevarla por sí sola. **Actúa siempre sobre `decision.type`, nunca sobre el score.**
</Warning>

Esta es la primera distinción que hay que tener clara antes de integrar: el score y la
decisión son dos campos separados de la respuesta. Esta sección los recorre uno por uno,
empezando por qué mide `risk_score`.

## `risk_score`

Un número de 0 a 100 que resume el riesgo acumulado de la transacción. Es un campo plano de
`data` — no viene anidado dentro de un objeto `risk`. Es útil para priorizar, ordenar y
hacer analítica; no es la señal que debes usar para decidir qué hacer con una transacción.

## `risk_level`

Una banda cualitativa derivada del score, con 4 valores posibles:

| `risk_level` | Qué significa      |
| ------------ | ------------------ |
| `low`        | Riesgo bajo        |
| `medium`     | Riesgo intermedio  |
| `high`       | Riesgo elevado     |
| `critical`   | Riesgo muy elevado |

## Ejemplo real: score bajo, decisión BLOCK

Este caso real ilustra por qué el score y la decisión son ejes independientes:

```json theme={null}
{
  "risk_score": 29.07,
  "risk_level": "medium",
  "decision": { "type": "BLOCK" }
}
```

Un score de `29.07` cae en la banda `medium` — no es un score alto. Sin embargo la decisión
fue `BLOCK`, porque la evidencia directa presente en la transacción (ver
[`flags`](/referencia/respuesta)) fue suficiente por sí sola para rechazarla,
independientemente de dónde cayera el score acumulado.

## `risk_score` no sirve para recomputar decisiones

Además de lo anterior, hay una razón concreta por la que ninguna lógica tuya debe derivar la
decisión del score: **`risk_score` es la escala mostrada, no la escala operativa.**

La decisión se computa sobre una escala interna que no se expone en la respuesta, y
`risk_score` está expresado en términos relativos al tráfico de tu propia empresa. La
consecuencia práctica es directa:

* **No puedes recomputar** una decisión a partir de `risk_score`.
* **No puedes predecir** qué decisión saldría con otro score.
* Comparar `risk_score` contra un límite propio te va a dar resultados que no coinciden con
  lo que devuelve la API.

Para lo que sí sirve `risk_score`: **mostrar** el riesgo en tu interfaz, **ordenar** una
cola de revisión y **priorizar** qué mirar primero. Para saber qué hacer con la transacción,
la única fuente es [`decision.type`](/conceptos/decisiones) (decisiones de transacción).

## `decision.confidence`

Un número de 0 a 1 que mide **qué tan adentro de su banda cayó el score** para la decisión
basada en score: cerca de `1.0` cuando el caso está holgadamente dentro de su banda, cerca
de `0.0` cuando queda pegado a un límite entre bandas.

Sirve para una cosa: detectar casos limítrofes. Un `confidence` bajo indica una transacción
que estuvo a punto de caer en otra decisión, y por eso es buena candidata a revisión manual
o a monitoreo.

<Warning>
  `confidence` **no** es una medida de certeza de la decisión final. Describe siempre la
  decisión basada en score. Cuando la decisión final se elevó por otra vía —evidencia directa,
  una regla tuya, tu lista de entidades— `confidence` sigue describiendo la decisión previa,
  no la que recibiste en `decision.type`. Un `BLOCK` con `confidence` bajo no significa "un
  bloqueo dudoso".
</Warning>

Para saber qué hacer con una transacción, lee siempre
[`decision.type`](/conceptos/decisiones) — nunca `risk_score`, `risk_level` ni
`decision.confidence`.

Siguiente paso: [Decisiones de transacción](/conceptos/decisiones).