> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Estados de KYT: transacciones y casos > Didit: todos los estados de transacción, caso y Travel Rule, con sus transiciones. 1,000 transacciones al mes incluidas, luego $0.001 cada una. Transaction Monitoring tiene tres máquinas de estado independientes: la **transacción**, cada **caso** y (cuando corresponde) la **comprobación de Travel Rule**. Esta página es la referencia. ## Estado de la transacción Se asigna al crearla y se actualiza a lo largo de su ciclo de vida. | Estado | Significado | | - | - | | `APPROVED` | La transacción superó todas las reglas y se mantuvo por debajo del umbral de revisión. | | `IN_REVIEW` | La puntuación superó el umbral de revisión o una regla exigió revisión de forma explícita. Requiere la atención de un analista. | | `DECLINED` | La puntuación superó el umbral de rechazo o una regla la rechazó de forma explícita. La transacción queda rechazada. | | `AWAITING_USER` | El usuario debe actuar antes de que la transacción pueda liquidarse. Didit solo lo asigna mediante una regla: la acción `change_status` de una regla (por ejemplo, la regla opcional de la biblioteca `travel-rule-pending-action`, que se dispara con una transferencia de Travel Rule en `ON_HOLD`) o una acción de una regla que exigió una verificación adicional (se creó una sesión de remediación). Una transferencia de Travel Rule que necesita prueba de control de la wallet no lo asigna por sí sola: la transacción conserva el estado que le asignan tus reglas (normalmente `APPROVED`) y el bloque `action_required` incluye la URL de propiedad de la wallet siempre que haya una sesión del widget pendiente. Consulta el bloque `action_required` de la transacción para conocer la acción concreta y la URL. | ### Transiciones ```mermaid theme={null} stateDiagram-v2 [*] --> APPROVED: Score < review threshold, no blocking rules [*] --> IN_REVIEW: Score >= review threshold [*] --> DECLINED: Score >= decline threshold, or rule decline action [*] --> AWAITING_USER: Rule action change_status → AWAITING_USER IN_REVIEW --> APPROVED: Analyst cleared IN_REVIEW --> DECLINED: Analyst declined AWAITING_USER --> APPROVED: Remediation session approved AWAITING_USER --> DECLINED: Remediation session declined AWAITING_USER --> IN_REVIEW: Remediation session ended in review ``` Nota: fuera de la Travel Rule no existe ninguna transición directa desde `APPROVED` o `DECLINED` de vuelta a otros estados. Cuando una Travel Rule expira, tu `timeout_outcome` asigna `IN_REVIEW` (`HOLD`) o `DECLINED` (`REJECT`) sea cual sea el estado actual, y una regla que se dispara tras una transición de Travel Rule puede cambiar el estado de una transacción `APPROVED`. Usa cambios de estado desde la consola para hacer correcciones; quedan anotados en el registro de auditoría. ## Alertas No existe un estado de alerta independiente. Una alerta abierta es una transacción en `IN_REVIEW` o `AWAITING_USER`, así que usa el estado de la transacción descrito arriba. Consulta [Alertas](https://docs.didit.me/es/transaction-monitoring/alerts.md). ## Estado del caso Consulta [Gestión de casos](https://docs.didit.me/es/console/case-management/cases.md) para ver todos los detalles. | Estado | Significado | | - | - | | `OPEN` | En investigación activa. | | `AWAITING_USER` | A la espera de información por parte del usuario. | | `RESOLVED` | Cerrado con una resolución: `FALSE_POSITIVE`, `VALID_THREAT`, `INCONCLUSIVE`, `REQUIREMENTS_NOT_MET` o `REQUIREMENTS_SATISFIED`. | Los casos tienen una **prioridad** independiente (`LOW`, `MEDIUM`, `HIGH`). ## Estado de la comprobación de Travel Rule Las transferencias de activos virtuales sujetas a la Travel Rule del GAFI siguen un **intercambio de 13 estados** propio, independiente del estado de la transacción descrito arriba. Una transferencia saliente comienza en `AWAITING_COUNTERPARTY`, `NOT_APPLICABLE` (por debajo de `threshold_amount`), `UNCONFIRMED_OWNERSHIP` (la wallet de la contraparte se declaró sin custodia), `COMPLETED` o `COUNTERPARTY_MISMATCHED_DATA` (una coincidencia `INTERNAL` con una wallet verificada, según la coincidencia del nombre), `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. Una transferencia entrante también puede comenzar en `ON_HOLD` o `NOT_ENOUGH_COUNTERPARTY_DATA`, y un registro de sunrise que coincide con una wallet verificada, si el nombre del beneficiario coincide o no se proporciona, pasa directamente de `COMPLETED` a `FINISHED`. El intercambio termina en `FINISHED`, `CANCELLED` o `EXPIRED`. | Estado | Significado | | - | - | | `AWAITING_COUNTERPARTY` | Enviada a la contraparte; a la espera de su respuesta. Una transferencia enviada por TRUST permanece aquí hasta que expira, porque TRUST no devuelve nada que Didit pueda leer. En una aplicación de sandbox, la transferencia va al [VASP de prueba de Didit](https://docs.didit.me/es/transaction-monitoring/travel-rule-sandbox.md), que responde dentro de Didit con el escenario que elijas. | | `UNCONFIRMED_OWNERSHIP` | Aún no se ha demostrado la propiedad de la wallet del beneficiario. | | `ON_HOLD` | Didit solo lo asigna en transferencias entrantes: un registro de sunrise o una consulta `TRP` entrante cuya wallet no está en tu libreta de direcciones (o, en una consulta solo con nombre, cuyo nombre no coincide con un único titular verificado), o una consulta `TRP` entrante que requiere tu decisión manual (la aceptación automática está desactivada o no se pudo entregar la respuesta automática). No cambia por sí solo el estado de la transacción; la regla opcional de la biblioteca `travel-rule-pending-action` asigna `AWAITING_USER`. Resuélvelo con `POST /v3/transactions/{id}/travel-rule/ownership/`. | | `COMPLETED` | Los datos del ordenante y del beneficiario coincidieron: se puede transmitir on-chain de forma segura. | | `FINISHED` | Se informó el hash on-chain; intercambio cerrado. | | `CANCELLED` | Cancelada desde un estado no terminal. | | `EXPIRED` | Se agotó el plazo de confirmación. Solo expira una transferencia que sigue en `AWAITING_COUNTERPARTY` al llegar su fecha límite, lo que se comprueba cada 15 minutos; los demás estados nunca expiran. Tu `timeout_outcome` se aplica a la transacción, y ese cambio no envía ningún webhook `transaction.status.updated`. | | `COUNTERPARTY_MISMATCHED_DATA` | El nombre del beneficiario no coincidió. | | `COUNTERPARTY_VASP_NOT_FOUND` | Ningún canal pudo identificar a la contraparte. | | `COUNTERPARTY_VASP_NOT_REACHABLE` | Se identificó a la contraparte, pero Didit no pudo realizar la entrega: su endpoint `TRP` no estaba accesible o informó un LEI distinto o ausente, o un nombre distinto, o un canal de red (GTR, TRUST, VerifyVASP, Sygna Bridge) no pudo entregar el mensaje. | | `COUNTERPARTY_VASP_GENERAL_DECLINE` | La contraparte rechazó el intercambio. | | `NOT_ENOUGH_COUNTERPARTY_DATA` | Una consulta `TRP` entrante no identificó al beneficiario ni por nombre ni por dirección de wallet. No tiene fecha límite y el endpoint de propiedad no puede resolverla, así que cancélala con `action: "cancel"`; no se notifica al remitente. Didit nunca lo asigna en una transferencia saliente; solo aparece ahí cuando tú mismo lo registras, y puedes reintentar esa transferencia con `action: "resend"`. | | `NOT_APPLICABLE` | Está por debajo de `threshold_amount`, por lo que no se intercambió nada, o es un valor que registraste en una transferencia que Didit no gestiona (Travel Rule desactivada, una transacción cuyo tipo no es `travelRule` o un valor heredado). | Las integraciones más antiguas aún pueden enviar los valores heredados `UNKNOWN`, `COMPLIANT`, `PENDING_ACTION`, `PENDING_COUNTERPARTY`, `FAILED` y `EXEMPT`; Didit los asigna automáticamente a los estados anteriores. Consulta [Travel Rule](https://docs.didit.me/es/transaction-monitoring/travel-rule.md#ciclo-de-vida) para ver la referencia oficial. ## Estado de los resultados de proveedores Cada resultado de un proveedor externo (análisis de wallets, monitorización fiat, análisis de sanciones) se almacena con su propio estado. Aparece en `provider_results[]` en la respuesta de la transacción. | Estado | Significado | | - | - | | `PENDING` | Consulta al proveedor en curso. | | `COMPLETED` | El resultado se devolvió correctamente. | | `FAILED` | El proveedor devolvió un error o superó el tiempo de espera. | | `SKIPPED` | El proveedor se omitió deliberadamente (p. ej., la transacción está por debajo del umbral). | ## Resultados de la ejecución de reglas Cada `TransactionRuleRun` tiene: * `matched` (booleano): ¿se activó la regla? * `is_test` (booleano): ¿estaba la regla en modo TEST? * `mode`: `ACTIVE`, `DISABLED` o `TEST` en el momento de la evaluación. * `score_delta`: contribución a la puntuación (si coincidió y está activa). * `status_target`: el estado que solicitó la regla (si es una acción `change_status`). Consulta [Reglas](https://docs.didit.me/es/transaction-monitoring/rules.md) para ver la anatomía de una regla. ## Códigos de motivo de decisión Valores habituales de `reason` en las transiciones de estado: | Motivo | Significado | | - | - | | `rule_score_threshold` | La puntuación superó el umbral de revisión o de rechazo. | | `rule_change_status` | La acción `change_status` de una regla forzó un estado. | | `analyst_approved` / `analyst_declined` / `analyst_cleared` | Acción manual de un analista. | | `user_action_approved` / `user_action_declined` / `user_action_in_review` | Resultado de la sesión de remediación vinculada (la acción del usuario solicitada mientras el estado es `AWAITING_USER`). | | `provider_update` | Un proveedor externo actualizó el resultado. | | `aml_confirmed_sanction` | El análisis AML confirmó una coincidencia con sanciones. | | `blocklist_applicant` / `blocklist_counterparty` | Aplicación de la lista de bloqueo a una de las partes. | ## Próximos pasos > [card] [Puntuación de riesgo](https://docs.didit.me/es/transaction-monitoring/risk-scoring.md) > > Cómo se corresponden las puntuaciones con los estados. > [card] [Alertas](https://docs.didit.me/es/transaction-monitoring/alerts.md) > > Ciclo de vida de las alertas. > [card] [Casos](https://docs.didit.me/es/transaction-monitoring/cases.md) > > Ciclo de vida de los casos. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.