Los 6 estados de la Travel Rule y el problema del amanecer (ES)

Cuando un VASP envía una transferencia de criptomonedas por encima del umbral, la obligación de la Travel Rule del GAFI asociada a ella no se resuelve instantáneamente. Pasa por diferentes estados: quizás la contraparte aún no ha respondido, quizás faltan datos requeridos de su lado, quizás el destino es una jurisdicción que ni siquiera ha adoptado la norma. Para ejecutar esto a escala, necesita un modelo de estado claro y finito, no una nota de texto libre que un analista tenga que interpretar.

Didit le ofrece exactamente seis. Debido a que el soporte de la Travel Rule está integrado en la monitorización de transacciones, cada obligación en cada transferencia de criptomonedas se resuelve en uno de UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED o EXEMPT. Esta guía explica qué significa cada uno, cómo actuar al respecto y cómo los estados le brindan una forma limpia de manejar la parte más complicada del cumplimiento de la Travel Rule: el problema del amanecer, donde la norma está vigente en su jurisdicción pero no en la de la contraparte.

Puntos clave

• Seis estados, sin ambigüedad. Cada obligación de la Travel Rule es exactamente una de UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED o EXEMPT.
• El estado le indica quién tiene la responsabilidad — usted (PENDING_ACTION), la contraparte (PENDING_COUNTERPARTY), o nadie porque ya está hecho (COMPLIANT) o fuera de alcance (EXEMPT).
• El problema del amanecer es la adopción global desigual de la Travel Rule — algunas jurisdicciones la aplican, otras aún no — lo que le lleva a intercambiar datos con contrapartes que pueden no tener la obligación de corresponder.
• Los estados dan al problema del amanecer un modelo de manejo limpio: PENDING_COUNTERPARTY, FAILED y EXEMPT se asignan directamente a los casos que produce una contraparte no adoptante.
• Se ejecuta dentro de la monitorización de transacciones en POST https://verification.didit.me/v3/transactions/ con currency_kind: "crypto", con el cribado de monederos al mismo tiempo desde $0.02 (traiga su propia clave).

Qué significan los seis estados

Cada transferencia de criptomonedas que conlleva una obligación de la Travel Rule obtiene un travel_rule_status. Aquí está el conjunto completo y cómo actuar en cada uno.

Estado	Significado	Qué hacer
UNKNOWN	La obligación aún no ha sido evaluada, o el VASP de la contraparte no puede resolverse.	Espere la resolución; investigue si persiste.
COMPLIANT	Los datos del originador y del beneficiario fueron intercambiados y confirmados.	Nada — la obligación está cumplida.
PENDING_ACTION	Se requiere algo de su parte — datos del originador faltantes o un paso de confirmación.	Suministre los datos; considere una remediación AWAITING_USER si es proporcionado por el cliente.
PENDING_COUNTERPARTY	Está esperando que el VASP de la contraparte responda al intercambio.	Mantenga según la política; el motor rastrea la espera.
FAILED	El intercambio no pudo completarse — contraparte inalcanzable, datos rechazados o falta de coincidencia de protocolo.	Investigue; decida si proceder, bloquear o tratar según su política de amanecer.
EXEMPT	La transferencia está fuera de alcance — por debajo del umbral, manejo de monederos autoalojados o de otro modo no obligatoria.	Procesar; la exención se registra para la pista de auditoría.

El valor de un conjunto cerrado es que la política se vuelve expresable. Puede decir "retener cualquier transferencia de criptomonedas OUTBOUND en PENDING_COUNTERPARTY por hasta N horas, luego escalar" o "auto-proceder en EXEMPT" — reglas, no juicios.

Por qué es importante

Los exámenes de la Travel Rule no solo preguntan si intercambió los datos, sino que preguntan si puede mostrar, por transferencia, cuál era la obligación y por qué procedió o no. Un modelo de seis estados es la pista de auditoría: cada transferencia lleva su estado, la razón y el protocolo que realizó (o no pudo realizar) el intercambio. Esa es la diferencia entre un registro listo para el examinador y un ejercicio de reconstrucción.

También es importante operativamente, porque la mayoría de las transferencias no son COMPLIANT en la primera pasada. Se quedan en PENDING_COUNTERPARTY mientras el otro VASP responde, o terminan en FAILED porque la contraparte no es accesible. Un equipo que no puede ver esos estados claramente termina bloqueando buenas transferencias o dejando pasar las obligadas.

El problema del amanecer

El estado más difícil de razonar es FAILED o PENDING_COUNTERPARTY contra una contraparte que simplemente no tiene una obligación de la Travel Rule, porque su jurisdicción no la ha adoptado. El GAFI estableció la norma; las jurisdicciones la implementan según sus propios plazos. El resultado es una cobertura global desigual: usted puede estar totalmente obligado mientras su contraparte, en una jurisdicción que no la ha adoptado, no tiene ningún requisito para enviar o confirmar nada. Esa brecha es el problema del amanecer: el sol ha salido en la norma en algunos lugares pero no en otros.

El problema del amanecer no puede ser resuelto unilateralmente por un VASP; es una función de la regulación, no de la ingeniería. Pero se puede manejar, y los seis estados son la clave:

• Una contraparte no adoptante que no responde aparece como PENDING_COUNTERPARTY y luego FAILED, no como una brecha silenciosa.
• Su política decide qué significa FAILED-debido-a-no-adopción: proceder con una justificación documentada, retener o bloquear. El estado hace que esa decisión sea explícita y registrada.
• Las transferencias genuinamente fuera de alcance se resuelven en EXEMPT, para que no pierda tiempo del analista en ellas.

El objetivo es que el problema del amanecer se convierta en un estado documentado y basado en políticas en lugar de un caso límite indefinido. Cuando la jurisdicción de la contraparte adopte la norma, las mismas transferencias comenzarán a resolverse en COMPLIANT sin ningún cambio en su integración.

Detalles técnicos

Los estados se devuelven en la transacción que publica en la API unificada /v3/.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_a17d63",
    "category": "travel_rule",
    "amount": 3100,
    "currency": "ETH",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T13:40:00Z",
    "subject": { "vendor_data": "user_5567", "role": "ORIGINATOR", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "BENEFICIARY", "entity_type": "INDIVIDUAL", "wallet_address": "0x4c1a...77fe" }
  }'

{
  "transaction_id": "txn_a17d63",
  "status": "IN_REVIEW",
  "travel_rule_status": "PENDING_COUNTERPARTY",
  "protocol": "OpenVASP",
  "wallet_screening": { "risk_score": 22, "risk_level": "LOW" }
}

Precio. El soporte de la Travel Rule está incluido en la monitorización de transacciones. El cribado de monederos en cadena en la dirección de la contraparte se ejecuta simultáneamente desde $0.02 por cribado con su propia clave (Crystal o Merkle Science).

Cómo los estados impulsan el bucle de remediación

Un estado PENDING_ACTION a menudo significa que el cliente tiene que proporcionar algo, confirmar un beneficiario, suministrar detalles del originador. Ahí es donde el bucle de remediación AWAITING_USER que utiliza el resto de la monitorización de transacciones se aplica directamente: en lugar de un bloqueo total, la transferencia se detiene, se le pide al usuario lo que falta y se reanuda automáticamente una vez que lo resuelve. La fricción solo se aplica a las transferencias que realmente la necesitan, y la línea de tiempo del estado registra cada paso para la pista de auditoría.

Casos de uso

• VASPs e intercambios — expresan políticas de retención y escalada directamente contra PENDING_COUNTERPARTY y FAILED, con EXEMPT procediendo automáticamente.
• Rampas de entrada/salida — manejan un alto volumen de contrapartes de jurisdicciones mixtas donde el problema del amanecer es una realidad diaria.
• Custodios — mantienen un registro de estado por transferencia, listo para el examinador, a través de muchas contrapartes y protocolos.
• Front-ends DeFi — se apoyan en EXEMPT para transferencias genuinamente fuera de alcance y documentan la justificación para el resto.

Cómo integrarse con Didit

1. Active las reglas de la Travel Rule en la Consola de Negocios junto con la monitorización y el cribado de criptomonedas, y escriba su política de amanecer como reglas contra los estados.
2. Envíe transferencias de criptomonedas con POST /v3/transactions/, currency_kind: "crypto" y las partes originadora/beneficiaria.
3. Ramifique en travel_rule_status — proceda en COMPLIANT/EXEMPT, remedie en PENDING_ACTION, retenga en PENDING_COUNTERPARTY, investigue FAILED.
4. Trabaje las excepciones en la Consola, donde la línea de tiempo del estado y el flujo de trabajo del caso viven con el resto de su monitorización.

Todo funciona en la API unificada /v3/, por lo que el estado de una transferencia se vincula a la misma identidad que incorporó con KYC y cribó con AML.

Preguntas frecuentes

¿Cuáles son los seis estados de la Travel Rule?

UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED y EXEMPT. El travel_rule_status de cada transferencia es exactamente uno de ellos.

¿Qué es el problema del amanecer?

La adopción global desigual de la Travel Rule: algunas jurisdicciones la aplican, otras aún no la han adoptado. Eso le lleva a intercambiar datos con contrapartes que pueden no tener la obligación de corresponder.

¿Cómo maneja Didit a las contrapartes que no la adoptan?

Aparecen como PENDING_COUNTERPARTY y luego FAILED en lugar de como brechas silenciosas. Su política decide si proceder, retener o bloquear, y la decisión se registra para la pista de auditoría.

¿Cuál es la diferencia entre PENDING_ACTION y PENDING_COUNTERPARTY?

PENDING_ACTION significa que la responsabilidad está de su lado (datos faltantes o una confirmación). PENDING_COUNTERPARTY significa que está esperando al otro VASP.

¿Es la Travel Rule un producto separado?

No. Está integrada en la monitorización de transacciones, en la misma transferencia de criptomonedas que ya envía para monitorización y cribado de monederos.

¿Listo para empezar?

Lea la documentación de la Travel Rule, vea cómo encaja en la página de soluciones de la Travel Rule para criptomonedas y la página del producto de monitorización de transacciones, y consulte los precios transparentes por llamada en la página de precios. Cuando esté listo, comience gratis: 500 verificaciones KYC gratuitas cada mes, con seguimiento del estado de la Travel Rule integrado en la monitorización.