Gestión de casos: casos y ciclo de vida

La gestión de casos es el centro de investigación de la Didit Console. Cualquier coincidencia AML, verificación marcada o transacción sospechosa puede convertirse en un caso que tu equipo de cumplimiento gestiona desde su apertura hasta su resolución, con un registro de auditoría completo.

---

​

Ciclo de vida

Un caso pasa exactamente por tres estados: Para resolver un caso es obligatorio indicar una resolución: Cada caso tiene además una prioridad (Low, Medium, High; por defecto Medium) y una fecha límite opcional que determina la ordenación por SLA y los indicadores de casos vencidos.

​

Un sujeto por caso

Cada caso está vinculado a exactamente un usuario o una empresa. No puedes mezclar sujetos en un mismo caso ni adjuntar una sesión, una sesión de empresa o una transacción que pertenezca a un sujeto distinto del caso: si lo intentas, se devuelve un error explícito. Así cada página de caso se mantiene centrada: la tarjeta del sujeto, el resumen de riesgo, los documentos y los datos financieros describen la misma persona o empresa que se investiga en el caso. Para revisar una segunda entidad, abre (o crea) un caso independiente.

​

Contexto de origen de Fraud Check

Al crear un caso a partir de una sesión de Fraud Check se conservan su ID de comprobación, su ID de solicitud y la sección que abrió el revisor. La tarjeta de origen también registra el estado del analista de la sesión en el momento de crear el caso. La decisión del caso y la decisión de origen se mantienen separadas. Los clientes de la API pueden enviar source_context con check_id, request_id y source_section al crear un caso. Incluye esa solicitud como una entrada session en links. La comprobación y la sesión vinculada deben pertenecer a la aplicación seleccionada y estar relacionadas entre sí. La API lee por sí misma el estado del analista y rechaza en este contexto los campos de estado, recomendación o tipo de origen enviados por el cliente.

​

Listas

En la navegación superior de Gestión de casos están disponibles Casos, Resumen y Asignación. El espacio de trabajo de Casos ofrece las vistas de estado Abierto, En espera del usuario, Resueltos y Todos. En escritorio, al abrir un caso la cola de casos se mantiene junto a sus detalles. En el móvil, usa la ruta de navegación para volver a la cola. La búsqueda encuentra coincidencias por nombre o ID del sujeto, etiqueta, número de caso, título del caso, ID de sesión vinculada e ID de transacción vinculada, de modo que puedes pegar el UUID de una sesión o de una transacción e ir directamente a su caso. Chips de filtro: Plantilla, Creada, Origen, Asignado, Etiqueta, además de Agregar filtro para Prioridad y Vencimiento. Columnas: Creada (fecha y creador), Detalles del caso (título), Estado, Plantilla, Sujeto (nombre e ID), Etiquetas del sujeto, Asignado, Prioridad y Fecha de vencimiento, con más columnas disponibles mediante el desplazamiento horizontal y la configuración de columnas.

​

Ordenación y SLA

Ordena por Fecha de creación (por defecto) o por Fecha de vencimiento. Al ordenar por fecha de vencimiento, los casos vencidos aparecen primero; un caso está vencido cuando su fecha de vencimiento ha pasado y sigue en estado Abierto o En espera del usuario, y se muestra con una etiqueta de vencimiento en rojo.

​

Vistas guardadas

Guarda la combinación actual de filtros y columnas como una vista con nombre mediante Guardar vista, cambia de una vista a otra con Seleccionar una vista y restablece los filtros con Borrar filtros. Las vistas son personales y se conservan del mismo modo que las demás preferencias de tablas de la consola.

​

Acciones masivas

Selecciona varios casos para:

• Asignar a un responsable. Todos los casos seleccionados deben compartir la misma plantilla; si no es así, la consola te avisa antes de enviar.
• Establecer estado en el estado de En espera del usuario, Reabrir o Resolver (con una resolución y una nota opcional). Cada caso se evalúa de forma independiente, de modo que un caso bloqueado por una lista de comprobación incompleta o por falta de una nota obligatoria se notifica individualmente sin que falle el resto del lote.

​

Exportaciones

El menú de la lista ofrece dos exportaciones CSV, que se entregan a través de la página Informes:

• All cases report, una fila por caso con estado, resolución, prioridad, etiquetas, transacciones vinculadas y el último informe presentado ante la FIU.
• SLA report, métricas de tiempos por caso: horas hasta la asignación, horas hasta la resolución, y marcas de vencido y de SLA cumplido.

​

Acciones sobre el sujeto y reintentos

La tarjeta del sujeto permite a los revisores autorizados cambiar el estado del sujeto, añadir etiquetas, añadir una nota interna o añadir el sujeto a la lista de bloqueo. Estas acciones son independientes de la resolución del caso. La sección Subject actions registra cada acción solicitada como Applied o Failed e identifica a su revisor y la hora. Usa Retry action para reintentar una acción fallida después de revisar el sujeto actual. Una acción aplicada no se vuelve a ejecutar cuando se reintenta su solicitud. Los clientes de la API deben enviar un client_reference único con cada solicitud al endpoint entity-actions/ del caso. Mantén la misma referencia y los mismos datos de entrada al reintentar una solicitud tras un error de conexión. Unos datos de entrada distintos con la misma referencia devuelven 409. Cuando se envía una referencia, revisa receipt.status: una respuesta 200 puede contener un comprobante fallido, lo que significa que la acción no se aplicó. Para reintentar una solicitud fallida es necesario retry: true o una llamada a su endpoint action-receipts/{receipt_uuid}/retry/. El endpoint de historial devuelve como máximo 20 comprobantes por página y proporciona next_offset para obtener más resultados. Los clientes de la API existentes que omiten client_reference mantienen su comportamiento de respuesta anterior.

​

Etiquetas

Añade etiquetas a un caso desde su encabezado (Añadir etiqueta) para agrupar investigaciones relacionadas, o filtra y busca por etiqueta desde la lista. Los cambios en las etiquetas quedan registrados en la cronología del caso.

​

Páginas relacionadas

​

Mensajes al cliente

Usa Enviar mensaje para previsualizar una solicitud predeterminada o una actualización de revisión dirigida a un contacto verificado. Consulta Mensajes al cliente para conocer los estados de entrega, las respuestas seguras y el flujo de la API.

​

Discusión y notas fijadas

Selecciona el botón de discusión junto al estado del caso para revisar las notas sin salir de la investigación. Usa el menú de una nota para responderla o fijarla. Las notas fijadas aparecen primero, y las respuestas muestran un breve extracto de la nota a la que responden. Los cambios de fijación quedan registrados en la actividad del caso y no modifican las decisiones de origen. Al confirmar la eliminación, la nota se elimina de forma permanente y su extracto citado desaparece de las respuestas. Las respuestas en sí siguen disponibles. Los archivos adjuntos se eliminan, salvo que otra nota los siga usando. Los clientes de la API pueden indicar un UUID en client_reference al añadir una nota. Un reintento sin cambios devuelve la nota existente sin duplicar las notificaciones. Reutilizar esa referencia con contenido modificado o para una nota eliminada devuelve 409. Indica reply_to para hacer referencia a una nota activa del mismo caso, y actualiza is_pinned mediante el endpoint PATCH de la nota.

​

Comprobar si existe una investigación

El diálogo compartido Crear caso comprueba si existen investigaciones para el usuario, la empresa o la fuente vinculada seleccionados. Abre un caso existente para seguir revisándolo. Los casos cerrados siguen visibles para que puedas abrirlos y decidir si reabrirlos. Para crear una investigación independiente, introduce un motivo para tratarla como un incidente distinto. El motivo se guarda con el nuevo caso y se muestra en su vista general. La consola vuelve a comprobar si hay duplicados al enviar, incluidos los casos que otro revisor haya creado mientras el diálogo estaba abierto. Las integraciones de API pueden consultar POST .../cases/duplicates/ y establecer review_duplicates=true al crear el caso. Cuando se encuentra una investigación existente, la creación devuelve 409, salvo que se indique separate_incident_reason. El endpoint de revisión de duplicados devuelve hasta 20 casos por página, con next_offset para obtener más resultados. Las integraciones de API existentes que omiten esta opción mantienen su comportamiento de creación actual.