Creando un Flujo de Trabajo SAR sin Herramientas de Casos Separadas (ES)

Activar una regla es la parte fácil. Lo que sucede después —la alerta, la investigación, la escalada, la decisión de presentar un Informe de Actividad Sospechosa (SAR)— es donde realmente reside la mayoría de las operaciones de cumplimiento y donde se esconde la mayor parte del costo. La configuración típica une tres cosas: un proveedor de monitoreo que produce alertas, una herramienta de gestión de casos separada que contiene la investigación y un proceso manual de SAR que a menudo termina en una hoja de cálculo y un PDF. Los datos se vuelven a introducir entre sistemas, la pista de auditoría se fragmenta y los analistas pasan el día cambiando de pestañas.

El API de Monitoreo de Transacciones de Didit entrega todo el flujo de trabajo en un solo producto. Cuando una regla se activa, se abre una alerta; las alertas se agrupan en casos; se asignan analistas; y el SAR se presenta desde la misma consola donde se generó la alerta. No hay una herramienta de casos separada que licenciar, integrar o conciliar, y las transacciones que la alimentan cuestan $0.02 cada una.

Esta guía describe el flujo de trabajo desde una regla activada hasta un SAR presentado.

Puntos clave

• Las alertas se abren automáticamente cuando una regla se activa y pasan por un ciclo de vida definido: OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED, DISMISSED.
• Los casos agrupan alertas relacionadas, llevan prioridad y gravedad, y rastrean una investigación a través de OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD y RESOLVED.
• Los analistas son asignados a alertas y casos, por lo que la propiedad y el rendimiento son medibles.
• La presentación de SAR reside en la misma consola que la alerta, sin exportar a una herramienta separada ni volver a introducir datos.
• La ruta AWAITING_USER permite a un analista devolver una alerta al usuario para su remediación en lugar de resolverla manualmente.
• $0.02 por transacción, sin mínimos. La revisión AML de una parte marcada se factura por separado a $0.20.

Qué hace el flujo de trabajo de gestión de casos

El monitoreo de transacciones produce señales; la gestión de casos las convierte en decisiones defendibles. Cada alerta en Didit lleva una fuente —activada por regla, activada por proveedor o creada por analista— y un estado que refleja dónde se encuentra en la investigación. Un analista abre la alerta, revisa la transacción y las reglas que se activaron, y decide: descartarla como un falso positivo, resolverla, escalarla a un caso, devolverla al usuario o moverla hacia un SAR.

Los casos son el contenedor para cualquier cosa más grande que una sola alerta. Varias alertas sobre el mismo usuario —un pico de velocidad el lunes, un impacto de contraparte sancionada el miércoles— se agrupan en un solo caso que contiene la imagen completa, con su propia prioridad y gravedad. El caso es lo que un investigador trabaja, y el caso es lo que documenta la decisión de la empresa.

Por qué es importante

Los reguladores no solo esperan que detecte actividad sospechosa, sino que la investigue y la denuncie, y que muestre una pista de auditoría clara de cómo llegó de la alerta a la decisión. Una pila fragmentada trabaja en su contra en todos los aspectos. Volver a introducir datos entre un proveedor de monitoreo y una herramienta de casos introduce errores. Un proceso de SAR en hoja de cálculo es imposible de auditar y lento de defender. Y cada unión de integración es un lugar donde una alerta puede pasar desapercibida.

Colapsar la pila en un solo producto resuelve el problema operativo y regulatorio a la vez. La alerta, la investigación, el analista que la poseía y el SAR viven en el mismo registro. La pista de auditoría es continua porque nada sale del sistema. Y el costo se escala con las transacciones, no con las licencias por asiento para una herramienta de casos que también tiene que mantener.

Detalles técnicos

Cuando una regla se activa en una transacción, la respuesta lleva el estado y un alert_id:

{
  "transaction_id": "txn_3c81f0",
  "status": "IN_REVIEW",
  "risk_score": 64,
  "triggered_rules": [
    { "name": "Sanctioned counterparty", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_77a920"
}

La transacción en sí se crea contra el API unificado /v3/, idempotente en un transaction_id que usted controla:

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_3c81f0",
    "category": "finance",
    "amount": 24000,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T14:50:00Z",
    "subject": { "vendor_data": "user_6610", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" }
  }'

Estados de alerta. OPEN → INVESTIGATING → (AWAITING_USER) → PENDING_SAR → SAR_FILED, o terminar en RESOLVED o DISMISSED.

Estados de caso. OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, RESOLVED.

Webhooks. Suscríbase a transaction.created y transaction.status.updated para que sus sistemas se mantengan sincronizados a medida que un analista mueve una alerta a través del flujo de trabajo.

Precio. $0.02 por transacción. La revisión AML ejecutada en una parte marcada durante una investigación se factura por separado a $0.20.

De la alerta al SAR presentado

1. Se abre la alerta. Una regla se activa, la transacción pasa a IN_REVIEW y se abre una alerta en estado OPEN con las reglas desencadenantes adjuntas.
2. El analista la toma. La alerta pasa a INVESTIGATING y se asigna a un analista, quien revisa el historial de transacciones, el contexto de velocidad y cualquier revisión AML.
3. Escalar o remediar. El analista agrupa las alertas relacionadas en un caso, o envía la alerta a AWAITING_USER para que el cliente pueda aclararla con prueba de fondos o una nueva verificación.
4. Decidir sobre un SAR. Si la actividad justifica un informe, la alerta pasa a PENDING_SAR, el SAR se prepara en la misma consola y, al presentarse, la alerta pasa a SAR_FILED.
5. Cerrar. Las alertas que no justifican una acción se resuelven como DISMISSED (falso positivo) o RESOLVED. Todo el rastro —quién decidió qué, cuándo— permanece en el registro.

Debido a que las alertas pueden pasar a AWAITING_USER, la investigación y el ciclo de remediación automática comparten la misma superficie: un analista puede devolver una alerta dudosa al usuario en lugar de perder tiempo en ella, y la alerta se reanuda automáticamente una vez que el usuario responde.

Casos de uso

• Fintech — agrupar alertas de velocidad, estructuración y sanciones en una sola cuenta en un caso antes de decidir sobre un SAR.
• Cripto — investigar alertas generadas por la exposición de la detección de billeteras junto con la velocidad en cadena en el mismo archivo de caso.
• Préstamos — trabajar alertas de patrones de fraude (mula, identidad sintética) hasta una decisión documentada sin una segunda herramienta.
• Mercados — consolidar alertas de abuso de reembolso y contracargo en un vendedor en un caso, luego presentarlas o descartarlas.
• iGaming — gestionar alertas de juego responsable y AML en un solo flujo de trabajo, con propiedad del analista y una pista de auditoría.

Cómo integrar con Didit

1. Active sus paquetes. En la Consola de Negocios, habilite los paquetes de reglas que se ajusten a su negocio para que las alertas se abran contra las tipologías correctas.
2. Envíe transacciones. POST /v3/transactions/ a medida que se mueve el dinero, con un transaction_id estable y vendor_data que vinculen cada una a su usuario o entidad.
3. Trabaje las alertas en la Consola. Investigue, asigne analistas, agrupe alertas en casos y presente SARs, todo desde la misma interfaz.
4. Sincronice con webhooks. Escuche transaction.status.updated para que sus propios sistemas reflejen los cambios de estado de alertas y casos.

Debido a que todo está en el API unificado /v3/, una sesión KYB puede generar las sesiones KYC para sus UBOs, esos usuarios fluyen al monitoreo de transacciones, y una transacción marcada puede generar un KYC de remediación — una plataforma de identidad y fraude, de principio a fin.

Preguntas frecuentes

¿Necesito una herramienta de gestión de casos separada?

No. Las alertas, casos, asignación de analistas, estados de investigación y presentación de SAR están integrados en el mismo producto y consola.

¿Por qué estados pasa una alerta?

OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED y DISMISSED. Los casos pasan por OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD y RESOLVED.

¿Puedo asignar alertas a analistas específicos?

Sí. Las alertas y los casos se asignan a analistas, por lo que la propiedad es clara y el rendimiento es medible.

¿Dónde se presenta el SAR?

En la misma consola donde se generó la alerta. No hay exportación a una herramienta separada ni datos reintroducidos, lo que mantiene la pista de auditoría continua.

¿Cuánto cuesta?

$0.02 por transacción, facturado por llamada sin mínimos. La revisión AML ejecutada en una parte marcada durante una investigación se factura por separado a $0.20.

¿Listo para empezar?

Lea la descripción general del monitoreo de transacciones en la documentación, vea cómo encaja con el resto de la plataforma en la página del 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.