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

# Decisiones de identidad

> Los estados de una verificación, qué hacer con cada decisión y qué guardar

Una verificación tiene un **estado**, y solo cuando llega a `DECIDED` tiene una **decisión**.

## Estados

| `status`    | Qué pasó                                                                          |
| ----------- | --------------------------------------------------------------------------------- |
| `PENDING`   | Creada; la persona todavía no termina                                             |
| `DECIDED`   | Llegó un resultado y tu política corrió. Trae `decision`                          |
| `ABANDONED` | Nadie terminó dentro del plazo                                                    |
| `UNKNOWN`   | Llegó algo que esta versión no sabe interpretar. **Nunca se trata como aprobado** |

Los campos nulos no se envían: una verificación sin decidir **no trae** la clave `decision`.
Comprueba ausencia, no `null`.

## Decisiones

| `decision` | Qué hacer                                               |
| ---------- | ------------------------------------------------------- |
| `APPROVED` | Déjala pasar                                            |
| `DECLINED` | No la dejes pasar                                       |
| `REVIEW`   | Todavía no. Alguien de tu equipo la resuelve en FraudEG |

**`REVIEW` no es una respuesta final.** Es final para ese campo hasta que una persona resuelve el
caso en el panel; cuando lo hace, `decision` pasa a `APPROVED` o `DECLINED`. En tu producto, `REVIEW`
se parece más a "estamos revisando" que a un rechazo: mantén a la persona en ese estado y espera el
segundo aviso.

**Una decisión que tu código no conoce se trata como `REVIEW`.** El vocabulario puede ganar valores
nuevos; dejar pasar a alguien por un valor que nunca viste es la única forma en que eso se vuelve
un problema de seguridad.

## Qué guardar

| Campo                 | Por qué                                                                                                                                               |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `decision`            | Es lo que tu producto ejecuta                                                                                                                         |
| `decision_rule`       | Un código estable que dice **qué** produjo esa decisión. Guárdalo: es lo que vas a querer el día que alguien pregunte por qué se rechazó a un cliente |
| `flow_config_version` | La versión de tu política con la que se decidió, congelada en ese momento                                                                             |
| `decided_at`          | Cuándo. En UTC                                                                                                                                        |

`decision_rule` es para explicar y auditar, no para decidir: **ramifica siempre sobre `decision`**.
Si aparece un código que no reconoces, trátalo como `REVIEW`.

`flow_config_version` no se mueve cuando editas tu política después. Por eso una decisión vieja
sigue siendo defendible: dice con qué reglas se tomó, no con las de hoy.

## Fechas

Todas las fechas de las respuestas REST son UTC y vienen sin offset en el texto. Interprétalas como
UTC. En los webhooks, en cambio, `occurred_at` y `decided_at` sí traen el offset (`Z`).

Mostrarlas como hora local sin asumir UTC corre cada verificación varias horas, en la dirección que
hace que una decisión parezca anterior a su propia solicitud.

## Siguiente paso

[Webhooks](/identidad/webhooks): cómo te avisamos y cómo compruebas que el aviso es nuestro.
La lectura por API está en [GET /verifications](/referencia/verificacion).