AWAITING_USER: Autorremediación para Transacciones Marcadas (ES)

La parte más difícil del monitoreo de transacciones no es detectar el pago sospechoso, sino lo que se hace después. Rechazarlo de plano bloquea a un cliente que paga y que puede ser completamente legítimo. Dejarlo pasar significa que ha aceptado el riesgo que acaba de señalar. La mayoría de los equipos resuelven esto con una cola manual: un analista envía un correo electrónico al usuario, espera días por un documento y la transacción permanece congelada todo el tiempo.

La API de Monitoreo de Transacciones de Didit tiene un cuarto estado diseñado precisamente para esta brecha: AWAITING_USER. En lugar de una aprobación o rechazo binario, una transacción marcada puede pausarse, solicitar una acción específica del usuario —volver a verificar la identidad, proporcionar prueba de fondos— y reanudarse automáticamente en el momento en que se resuelve. La fricción solo ocurre donde hay riesgo, y cuesta lo mismo: $0.02 por transacción, como todo lo demás.

Esta guía explica cómo funciona la ruta AWAITING_USER y cómo integrarla en su flujo.

Puntos clave

• AWAITING_USER es uno de los cuatro estados de transacción —junto con APPROVED, IN_REVIEW y DECLINED—, por lo que la remediación es un resultado de primera clase, no una solución provisional.
• Una transacción marcada se pausa en lugar de fallar, solicita una acción adicional del usuario y se reanuda automáticamente una vez que la acción se completa.
• La acción adicional puede ser un re-KYC, una carga de prueba de fondos o cualquier paso de verificación generado en la API unificada /v3/.
• Los webhooks impulsan el ciclo — transaction.status.updated se activa cuando la transacción entra y sale de AWAITING_USER.
• El mismo estado existe en la gestión de casos, por lo que un analista puede mover una alerta a AWAITING_USER y permitir que el usuario la resuelva.
• $0.02 por transacción, sin mínimos. Un re-KYC o una verificación AML generada durante la remediación se factura a su tarifa publicada.

Qué hace AWAITING_USER

Cuando una regla se activa, el motor asigna un estado. Tres de los cuatro son familiares: APPROVED permite que la transacción pase, IN_REVIEW abre una alerta para un analista y DECLINED la bloquea. El cuarto, AWAITING_USER, hace algo diferente: suspende la transacción y señala que el usuario debe hacer algo antes de que pueda resolverse.

Concretamente: una transferencia activa una regla de alto valor o alta velocidad, el motor devuelve AWAITING_USER, su aplicación solicita al usuario que complete el paso requerido (una nueva verificación de vida, una carga de documento, una declaración de origen de fondos) y la sesión de verificación retroalimenta la plataforma. Una vez que el paso se completa, la transacción se reevalúa y pasa a APPROVED (o se escala si la nueva evidencia empeora las cosas). Ningún analista tiene que supervisarla.

Por qué es importante

Los rechazos totales son costosos. Cada bloqueo por falso positivo es un cliente legítimo frustrado, un ticket de soporte y, a menudo, una cuenta perdida. Pero dejar pasar pagos marcados es como las empresas terminan en acciones de cumplimiento. La solución convencional —una cola de remediación manual— intercambia un costo por otro: tiempo del analista, lentitud en la respuesta y una transacción congelada durante días.

AWAITING_USER elimina esa compensación. El usuario hace el trabajo, en el momento, en el punto de fricción, exactamente cuando está motivado para resolverlo porque su propia transacción está esperando. Usted detecta el riesgo, mantiene al cliente y no paga a un analista para que persiga un documento. Es la diferencia entre un control de cumplimiento que le cuesta clientes y uno que simplemente hace su trabajo.

Detalles técnicos

Una transacción que el motor enruta a remediación regresa con el estado AWAITING_USER y las reglas que la activaron:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "Transferencia de alto valor — primeros 30 días", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

Usted reacciona solicitando al usuario y generando el paso de verificación en la API unificada /v3/. Cuando el paso se completa, un webhook le indica que la transacción ha avanzado:

# carga del webhook: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Webhooks. Suscríbase a transaction.created y transaction.status.updated. El evento de actualización de estado se dispara tanto cuando la transacción entra en AWAITING_USER como cuando sale, para que su libro mayor y su interfaz de usuario se mantengan sincronizados sin necesidad de sondeo.

Precio. $0.02 por transacción. El paso de remediación se factura a su tarifa publicada: un re-KYC a las tarifas de Verificación de Usuario, una verificación AML en una parte marcada a $0.20.

El ciclo de remediación, paso a paso

1. Activar una regla. Una transacción cruza un umbral que su política establece que debe remediarse en lugar de rechazarse, por ejemplo, una primera transferencia de alto valor desde una cuenta nueva.
2. Pausar, no fallar. El motor devuelve AWAITING_USER en lugar de DECLINED, con la acción requerida adjunta.
3. Solicitar al usuario. Su aplicación muestra el paso adicional —una nueva verificación de vida, una carga de documento, una declaración de origen de fondos— y genera la sesión de verificación.
4. El usuario lo resuelve. El usuario completa el paso dentro del mismo flujo en el que ya estaba.
5. Reanudar automáticamente. La transacción se reevalúa con la nueva evidencia y pasa a APPROVED —o se escala a IN_REVIEW/DECLINED si la evidencia aumenta el riesgo. Un webhook transaction.status.updated notifica a su backend en cualquier caso.

Debido a que el mismo estado AWAITING_USER existe en la gestión de casos, un analista que trabaja en una alerta IN_REVIEW también puede enviarla de vuelta al usuario en lugar de resolverla ellos mismos; la alerta se mueve a través de OPEN → INVESTIGATING → AWAITING_USER y se resuelve una vez que el usuario responde.

Casos de uso

• Fintech — una primera transferencia de alto valor desde una cuenta recientemente incorporada se pausa para solicitar prueba de fondos en lugar de bloquear al cliente.
• Cripto — una transferencia saliente a una billetera con exposición elevada se pausa para una declaración de origen de fondos antes de liquidarse.
• Préstamos — un desembolso que activa una señal de identidad sintética se pausa para una verificación de vida re-KYC.
• Mercados — un pago a un vendedor que activa una regla de velocidad se pausa para una reverificación antes de liberar los fondos.
• iGaming — un pico de velocidad de depósito se pausa para una verificación adicional, que también sirve como punto de contacto de juego responsable.

Cómo integrar con Didit

1. Decida su política de remediación. En la Consola de Negocios, establezca qué reglas se enrutan a AWAITING_USER en lugar de DECLINED, y qué acción adicional solicita cada una.
2. Envíe transacciones. POST /v3/transactions/ a medida que se mueve el dinero, con un transaction_id estable y vendor_data vinculando cada una a su usuario.
3. Maneje la pausa. Cuando una transacción devuelve AWAITING_USER, solicite al usuario y genere el paso de verificación en la API /v3/.
4. Escuche la reanudación. Reaccione a transaction.status.updated para liberar o retener la transacción una vez que el usuario complete el paso.

Debido a que todo está en la API unificada /v3/, el KYC de remediación que genera una transacción marcada es el mismo KYC que utiliza para incorporar usuarios: una plataforma de identidad y fraude, de principio a fin.

Preguntas frecuentes

¿Qué es AWAITING_USER?

Es uno de los cuatro estados de transacción. En lugar de un rechazo total, una transacción marcada se pausa y solicita una acción del usuario —reverificación o prueba de fondos—, luego se reanuda automáticamente una vez que el usuario la completa.

¿La transacción se reanuda por sí misma?

Sí. Una vez que se completa el paso solicitado, la transacción se reevalúa y pasa a APPROVED automáticamente —o se escala si la nueva evidencia aumenta el riesgo. Un webhook transaction.status.updated se activa con el cambio.

¿Cuál puede ser el paso adicional?

Cualquier paso de verificación en la API unificada /v3/ —una verificación de vida re-KYC, una reverificación de documentos, una verificación AML o una carga de prueba de fondos.

¿Tiene que participar un analista?

No. El ciclo de autorremediación se ejecuta sin un analista. Pero el mismo estado AWAITING_USER existe en la gestión de casos, por lo que un analista también puede enviar una alerta de vuelta al usuario cuando lo desee.

¿Cuánto cuesta?

$0.02 por transacción. El paso de remediación se factura a su propia tarifa: un re-KYC a las tarifas de Verificación de Usuario, una verificación AML a $0.20.

¿Listo para empezar?

Lea la descripción general de Monitoreo de Transacciones en la documentación, vea cómo encaja con el resto de la plataforma en la página de producto de Monitoreo 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 y monitoreo de transacciones a $0.02 por llamada.