Reglas y puntuación KYT: velocidad y condiciones

Cada transacción que se envía a Didit se evalúa con todas las reglas activas de tu aplicación. Las reglas definen condiciones, controles de frecuencia y acciones que determinan el estado y la puntuación finales de la transacción. Este capítulo de la lección de Didit Academy sobre el motor de reglas de fraude continúa con la creación de una regla. La lección de Academy sobre el motor de reglas muestra cómo crear una regla en el minuto 7:54: disparador, condiciones, acciones y puntuación, y después el backtesting antes del despliegue.

​

Paquetes de reglas integrados

Didit ofrece una biblioteca de reglas preconfiguradas que cubre las tipologías regulatorias más habituales. Instala desde la biblioteca los ajustes predefinidos (o paquetes completos) que quieras, ya sea en la consola, mediante la API de instalación o con las herramientas del MCP, y controla el modo de cada ajuste predefinido instalado. Para ver el catálogo completo de todas las reglas predefinidas con sus umbrales y acciones, consulta la biblioteca de reglas.

​

Orígenes de las reglas

Cada regla tiene un source que indica quién la gestiona:

​

Anatomía de una regla

Cada regla consta de:

​

Acciones

Cuando una regla coincide con una transacción, se ejecutan una o varias acciones. Cada regla puede tener varias acciones, y todas se aplican a la vez: La mayoría de las reglas predefinidas combinan Añadir puntuación con Cambiar estado: por ejemplo, una regla de contraparte sancionada suma 90 puntos a la puntuación y rechaza la transacción de inmediato.

​

Exigir la verificación del usuario (AWAITING_USER)

Una acción Cambiar estado → AWAITING_USER hace algo más que establecer un estado: en cuanto se dispara la regla, Didit crea automáticamente una sesión de verificación alojada para el sujeto de la transacción (con el mismo vendor_data). La sesión se devuelve en el bloque action_required de la transacción (y en el objeto remediation) de la respuesta de creación y de cada consulta posterior, así como en ambos webhooks de transacción, de modo que puedes redirigir al usuario de inmediato. Consulta acciones requeridas del usuario. Las reglas personalizadas deben indicar el flujo en la propia acción (workflow_id): tanto el constructor de reglas de la consola como la API de reglas lo exigen. Las reglas de la biblioteca integrada no llevan ningún flujo; en su caso, el flujo de la sesión se determina en este orden:

1. El flujo de remediación configurado en tu configuración de transacciones.
2. El flujo de Autenticación biométrica de tu aplicación, cuando el sujeto ya tiene una cara de referencia guardada de una verificación aprobada.
3. El flujo predeterminado de tu aplicación.

Esto significa que las reglas de la biblioteca con AWAITING_USER siempre generan una sesión accionable sin configuración adicional: una autenticación biométrica reforzada para los usuarios que ya verificaste y una verificación completa en los demás casos. Las transacciones de Travel Rule quedan excluidas de este mecanismo de respaldo automático: en ellas, la espera en AWAITING_USER corresponde a la prueba de propiedad de la wallet, que tiene su propio flujo. La opción más sólida para las transacciones de alto riesgo es un flujo de Autenticación biométrica: como el sujeto es el usuario al que ya verificaste mediante KYC, Didit reutiliza la rostro de referencia verificado de su onboarding (la selfie de prueba de vida aprobada, la foto del chip del pasaporte o el retrato del documento). El usuario solo se toma una selfie en vivo, y Didit ejecuta la prueba de vida y una coincidencia facial 1:1 con la identidad que abrió la cuenta. Las credenciales robadas, los OTP obtenidos mediante phishing y los SIM swaps fallan en este control. Guía completa: biometría reforzada para un retiro de alto valor. Cuando la sesión llega a una decisión, la transacción la sigue automáticamente y se dispara un webhook transaction.status.updated: una sesión aprobada aprueba la transacción (decision_reason_code: user_action_approved), una sesión rechazada la rechaza (user_action_declined) y una sesión que termina en revisión envía la transacción a IN_REVIEW (user_action_in_review). Una sesión expirada o abandonada mantiene la transacción en AWAITING_USER.

​

Puntuación

Cuando una transacción coincide con una o varias reglas, las puntuaciones se combinan:

1. Cada coincidencia de regla contribuye a la puntuación de riesgo global de la transacción mediante la acción add_score
2. La puntuación final determina el estado de la transacción según los umbrales de puntuación de tu aplicación
3. Si alguna regla tiene una acción change_status, ese estado se aplica directamente; DECLINED siempre tiene prioridad

Umbrales de puntuación predeterminados (configurables en la consola):

​

Creación de reglas personalizadas

Puedes crear reglas personalizadas desde la Business Console o mediante la Management API (también accesible desde el MCP de Didit y desde cualquier asistente de IA conectado por MCP). Las reglas en modo Active entran en vigor de inmediato para todas las transacciones nuevas. Los títulos son únicos por aplicación.

​

Backtesting

Antes de activar una regla, puedes validarla con datos históricos:

• Pon una regla en modo Test: la regla se evalúa en cada transacción nueva, pero sus resultados no afectan al estado ni a la puntuación de la transacción. Las estadísticas de ejecución (número de coincidencias, entidades afectadas) se acumulan para que puedas valorar su impacto antes de pasarla a producción.
• Usa la función de backtest (en la consola o mediante POST /v3/transactions/rules/backtest/) para evaluar de forma retroactiva las condiciones y la agregación de una regla sobre las transacciones de un periodo de tiempo determinado. El backtest devuelve el número de transacciones evaluadas y que coincidieron, y de entidades afectadas, sin modificar ningún dato histórico. Envía los mismos conditions, aggregation, evaluation_mode y scope que la regla que quieres activar: omitir el alcance significa que no hay restricción, por lo que el backtest contaría transacciones que la regla guardada omite.

​

Ventanas de velocidad (agregación)

Las reglas de velocidad agregan datos históricos de transacciones durante un periodo de tiempo para detectar patrones que las comprobaciones sobre una sola transacción no detectarían: Cada agregación especifica:

• Una ventana de tiempo: <N>m (minutos), <N>h (horas) o <N>d (días), p. ej. 30m, 6h, 7d, 30d. Atención: m significa minutos, no meses.
• Filtros para acotar qué transacciones históricas se incluyen. Las claves son rutas de campo del catálogo de campos; el valor especial "__current__" se resuelve como el valor del mismo campo en la transacción que se está evaluando (p. ej., "subject_vendor_data": "__current__" limita la ventana al mismo sujeto), y un valor de lista indica pertenencia. Los filtros comparan solo por igualdad o pertenencia: no existe un filtro lt/gte, así que un rango como transacciones por debajo de 10,000 no se puede expresar con un filtro. Aplica el rango a la métrica en su lugar (max por debajo de 10,000, min por encima de 1,000), y recuerda que una condición restringe la transacción que se está evaluando, nunca la ventana.
• Un operador y un umbral (eq, ne, gt, gte, lt, lte frente a value, p. ej., recuento >= 20)

​

Patrones de ejemplo

​

Catálogo de campos

Las condiciones y los filtros de agregación hacen referencia a los campos de la transacción mediante su ruta:

​

Operadores de condición

Las reglas admiten los siguientes operadores de comparación para las condiciones: Todos los demás operadores necesitan un value no vacío y, si falta, la API responde 400. contains, not_contains y regex reciben una sola cadena, no una lista ni un objeto; contains_any recibe una lista de cadenas.

​

Tipos de valor de las condiciones

Un value_type opcional en una condición cambia cómo se interpreta value:

​

Condiciones agrupadas

Una lista plana de condiciones se combina según el evaluation_mode de la regla (ALL/ANY). Para lógica mixta, asigna a las condiciones un group_index: las condiciones que comparten un índice forman un grupo, group_logic (AND/OR, AND por defecto) combina las condiciones dentro de un grupo y groups_logic en la primera condición (AND/OR, OR por defecto) combina los resultados de los grupos. Cuando alguna condición lleva un group_index, la evaluación agrupada sustituye a evaluation_mode.

​

Referenciar propiedades personalizadas

Cada clave enviada en el objeto custom_properties de POST /v3/transactions/ se guarda en la transacción como custom_values y puede usarse en condiciones con la ruta de campo custom_values.<key>. Por ejemplo, una transacción enviada con "custom_properties": {"channel": "mobile_app"} cumple la condición custom_values.channel eq "mobile_app". Todos los operadores anteriores funcionan con propiedades personalizadas, que además pueden compararse con otros campos o usarse en filtros de velocidad. En el creador de reglas de la Console, las claves detectadas en las transacciones ingeridas recientemente aparecen automáticamente en el selector de campos de la condición, en Custom Properties. También puedes referenciar una clave antes de que alguna transacción la incluya: elige Enter custom property en el mismo grupo y escribe la clave exactamente como la envía tu integración (las claves distinguen mayúsculas de minúsculas). La regla simplemente se evalúa como no coincidente hasta que lleguen transacciones con esa clave.

​

Rechazo automático por lista de bloqueo

Antes de evaluar cualquier regla, Didit comprueba las entidades de la transacción frente a las listas de bloqueo de tu aplicación. Si se encuentra cualquier coincidencia, la transacción se rechaza de inmediato y las reglas no se evalúan. Se comprueban las siguientes entidades: Cuando se produce una coincidencia con una lista de bloqueo:

• El estado de la transacción se establece en DECLINED
• El motivo de la decisión se establece en blocklisted
• Se crea un registro de actividad para el seguimiento de auditoría

​

Análisis de transacciones

Didit se integra con proveedores externos de AML y de análisis de blockchain para enriquecer las transacciones con información de riesgo. Cuando se envía una transacción, el sistema puede:

• Analizar las contrapartes frente a bases de datos globales de sanciones y listas de vigilancia
• Evaluar las direcciones de wallet (en transacciones de criptomonedas) frente a datos de inteligencia de blockchain, incluida la exposición a mixers, las conexiones con entidades sancionadas y las interacciones con servicios de alto riesgo
• Comprobar el estado AML del solicitante comparando los datos del usuario vinculado a la transacción con sus resultados de análisis AML más recientes

Los resultados del análisis se adjuntan a la transacción y se tienen en cuenta en la puntuación del motor de reglas. Si una contraparte o una wallet coincide con una lista de sanciones, la regla correspondiente marca o rechaza automáticamente la transacción.

​

Próximos pasos