Saltar al contenido principal

Descripción general

El análisis AML coteja la identidad verificada de la persona con conjuntos de datos globales de sanciones, PEP, listas de vigilancia y medios adversos. Cada coincidencia devuelve la entidad coincidente, los conjuntos de datos que produjeron la coincidencia y dos puntuaciones: match_score (confianza en la identidad) y risk_score (riesgo de la entidad). También incluye un desglose estructurado por fuente (pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[]). La puntuación agregada score es el risk_score más alto entre las coincidencias que no están marcadas como False Positive. El análisis AML devuelve la misma estructura en las sesiones de usuario (KYC), en las sesiones de empresas (KYB) y en la API de AML independiente.
Captura de pantalla del informe de análisis AML de Didit con coincidencias de sanciones, PEP y medios adversos

Dónde aparece en las respuestas de la API

En el endpoint de decisión de la sesión, el análisis AML se devuelve como el array en plural aml_screenings[]. Cada entrada corresponde a una ejecución de AML en el flujo (una comprobación AML que se ejecuta dos veces produce dos entradas con valores de node_id distintos).
Las sesiones de AML independientes y las sesiones de empresas devuelven la misma estructura por registro. Los campos que aparecen a continuación reflejan el esquema canónico de la página Modelos de datos.

Tres puntuaciones, no un único veredicto

El status es un veredicto, y los números de los que se derivó están en el mismo payload. Consúltalos cuando construyas tus propios niveles de riesgo en lugar de ramificar solo según Approved / In Review / Declined. Por ejemplo, puedes combinar el riesgo AML con respuestas de cuestionarios como el origen del patrimonio o la autodeclaración de PEP: Las tres están presentes en todos los lugares donde se entrega el informe AML: GET /v3/session/{sessionId}/decision/, el objeto decision de los webhooks status.updated y data.updated en todas las versiones de webhook (V3 aml_screenings[] y el aml en singular de las versiones heredadas V2 / V1) y la API de AML independiente. Un consumidor que solo ve una etiqueta de alerta / sin alertas está leyendo el status (o el review_status de una coincidencia) y omite las puntuaciones que lo acompañan. La consola muestra los mismos números: el encabezado de la sección AML incluye la Puntuación de riesgo agregada, y cada fila de la tabla de coincidencias incluye la Puntuación de coincidencia y la Puntuación de riesgo, con un desglose al pasar el cursor.

Esquema

Consulta Análisis AML en la referencia de modelos de datos para ver el esquema canónico. Campos de nivel superior:

Campos por hit

Cada entrada de hits[] tiene los siguientes campos (se muestra un subconjunto). Los arrays de origen de la coincidencia (pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[]) solo se rellenan para los conjuntos de datos a los que pertenece el hit.
Los hits clasificados como False Positive (porque match_score quedó por debajo del umbral de puntuación de coincidencia o porque un revisor los marcó así) permanecen en hits[] para que se puedan auditar. Solo se excluyen del cálculo del score agregado.

Monitorización continua

Cuando is_ongoing_monitoring_enabled es true, Didit vuelve a analizar al sujeto de forma continua y emite de nuevo el informe AML cada vez que se añade, se elimina o cambia una coincidencia. Los nuevos análisis que cambian el estado AML disparan un webhook status.updated; los que solo cambian los datos de las coincidencias disparan data.updated. El periodo de monitorización abarca 365 días a partir de last_aml_bill_date; next_ongoing_monitoring_bill_date indica cuándo se produce la siguiente renovación anual. Todas esas señales dependen de cambios, así que un sujeto analizado de nuevo durante meses sin coincidencias nuevas no genera ninguna. last_ongoing_screening_at es el único campo que se actualiza en cada ejecución completada, y el endpoint del historial de análisis enumera cada ejecución por separado, incluidas las que no cambiaron nada. Consulta Monitorización AML continua para ver el ciclo de vida completo.
Tres fechas de este informe significan tres cosas distintas. next_ongoing_monitoring_bill_date es cuándo se te factura la próxima vez. last_ongoing_screening_at es cuándo se analizó realmente al sujeto por última vez. last_ongoing_screening_datasets_updated_at es cuándo el proveedor actualizó por última vez las listas en las que se basa ese análisis. Solo la segunda demuestra que el control se ejecutó.

Valores de estado

Los umbrales se pueden configurar por nodo del flujo; consulta Puntuación de riesgo AML. Las reglas de estado personalizadas se combinan con el estado derivado según la precedencia Declined > In Review > Approved; los revisores también pueden anular el estado AML desde la consola o mediante el endpoint de estado AML.

Ejemplos

Aprobado — sin coincidencias

En revisión — coincidencia con PEP y medios adversos

Todos los nombres, URL y artículos que aparecen a continuación son ficticios.

Contenido relacionado

Última modificación el 1 de noviembre de 2026