Saltar al contenido principal
Didit ofrece una biblioteca seleccionada de más de 150 reglas predefinidas de monitorización de transacciones que puedes instalar una a una o por paquetes. Cada regla corresponde a una tipología real de AML, fraude o cumplimiento extraída de estándares globales y orientaciones regulatorias: recomendaciones del FATF, avisos de FinCEN, reglas de NACHA, principios de Wolfsberg, tipologías del Egmont Group y patrones de abuso en iGaming. Elige las reglas predefinidas o los paquetes que necesites y después controla el modo de cada regla instalada (ACTIVE, TEST o DISABLED). Las condiciones, los umbrales y las acciones de las reglas predefinidas son fijos; crea una regla personalizada cuando necesites una lógica distinta. Desinstala una regla predefinida para eliminarla de la aplicación y vuelve a instalarla más adelante si la necesitas.
Puedes explorar, instalar y desinstalar las reglas de la biblioteca desde Transactions -> Rules -> Library en la Business Console, mediante la API de la biblioteca de reglas (GET /v3/transactions/rules/library/, POST/DELETE /v3/transactions/rules/install/) o con las herramientas MCP didit_transaction_rule_library_list / didit_transaction_rule_install / didit_transaction_rule_uninstall. Las reglas predefinidas instaladas solo admiten cambios de mode (activar, desactivar, probar); sus umbrales son fijos: para cambiar uno, crea una regla personalizada. Para saber cómo contribuyen las reglas a la puntuación, consulta puntuación de riesgo.
Una regla de la biblioteca cuyas condiciones requieren datos que el motor de reglas todavía no puede evaluar queda no disponible hasta que pueda ejecutarse: la biblioteca no la muestra, una solicitud que la incluya en library_keys responde 400 y no instala nada (en cambio, una clave desconocida se omite), y una instalación por bundle la omite. Una copia que hayas instalado antes se desactiva (DISABLED) y permanece en tu lista de reglas, y si cambias su mode a cualquier otro valor, la solicitud devuelve 400. Una regla que no estaba disponible vuelve a estar disponible por sí sola en cuanto el motor de reglas puede evaluar sus condiciones, de modo que la lista de la biblioteca siempre muestra las reglas que puedes instalar hoy.

Cómo se organizan las reglas predefinidas

Cada regla predefinida pertenece a un paquete (su familia funcional) y a una categoría (su temática de riesgo más amplia). Los paquetes te permiten activar o desactivar juntas reglas relacionadas desde la consola; las categorías determinan la puntuación y los informes.

Cómo leer esta página

Cada regla indica su library_key (identificador estable que puedes usar en la API o en la URL de la consola), las condiciones y la agregación que la activan, y las acciones que aplica por defecto. Los umbrales numéricos que se muestran aquí son los valores predeterminados incluidos: cada valor se puede editar por aplicación sin que la regla pierda su identidad.

Paquete de finanzas

Estas reglas se aplican a toda transacción con transaction_type = FINANCE. Reflejan el marco regulatorio de referencia (umbrales de reporte de la BSA/FinCEN, heurísticas de velocidad del GAFI/FATF), además de patrones de mulas de dinero y pitufeo (smurfing).

Estructuración y montos cercanos al umbral

Volumen y velocidad

Estratificación, mulas y pitufeo

Anomalías de comportamiento


Paquete AML / CTF

Estas reglas modelan tipologías clásicas de AML/CTF que no dependen del enriquecimiento con datos de blockchain, por lo que se aplican de forma universal a transferencias fiat y cripto. La lista predeterminada de jurisdicciones de alto riesgo incluye los territorios incluidos en los llamamientos a la acción del GAFI/FATF y los de regiones en conflicto: IRN, PRK, SYR, AFG, RUS, MMR. Puedes sobrescribir la lista por aplicación.
Actualmente no se ofrece cobertura de contrapartes PEP. Ningún proveedor de análisis conectado informa si una contraparte es una persona expuesta políticamente: hoy el campo pep_counterparty es null en todos los resultados de análisis (consulta análisis de wallets), por lo que la biblioteca no incluye ninguna regla predefinida de contraparte PEP. Una regla instalada antes de que se retirara esa regla predefinida sigue evaluándose, pero no puede coincidir con un análisis real: elimínala o reemplázala por una regla personalizada si necesitas actuar en función de otra señal.

Paquete de análisis cripto

Estas reglas consumen los datos enriquecidos que genera el análisis cripto de Didit; son especialmente útiles para aplicaciones nativas cripto y de VASP.

Paquete de monitorización cripto

Reglas de exposición a nivel de wallet, además de controles de integridad de VASP y relacionados con la Travel Rule.

Paquete de Travel Rule

Las reglas de Travel Rule se aplican solo a transacciones travelRule. Cada régimen regional incluye cuatro reglas (contraparte pendiente, acción pendiente, datos faltantes, intercambio fallido).

Travel Rule global

Regímenes regionales

La misma plantilla de cuatro reglas se aplica a cada régimen. Sustituye <regime> a continuación por cualquiera de estos valores: australia, dubai, eu, hong_kong, india, indonesia, japan, kazakhstan, singapore, south_africa, turkey, uk. El etiquetado del régimen es automático: Didit asigna custom_values.travel_rule_regime a cada transacción de Travel Rule a partir del campo jurisdiction de tu configuración de Travel Rule: SG → singapore, GB → uk, y cualquier código de un Estado miembro de la UE o del EEE, como DE o FR → eu. Los códigos sin un paquete regional se asignan en minúsculas (US → us), para que las reglas personalizadas puedan seguir aplicándose a ellos. Un valor props.travel_rule_regime enviado en la transacción siempre prevalece sobre el régimen derivado. Son 48 reglas específicas por región, además de las tres reglas globales de Travel Rule y las cinco reglas de contraparte que se describen a continuación. El paquete independiente travel_rule_eu_tfr añade cuatro reglas del TFR de la UE, descritas en Paquete de reglas EU TFR.

Diligencia debida de la contraparte

Estas reglas leen lo que tu aplicación sabe sobre el VASP de la contraparte con el que se puso en contacto el exchange: tu propia decisión sobre él, su nivel de riesgo según la diligencia debida, su país y su capacidad de respuesta. Consulta Diligencia debida de la contraparte para saber de dónde procede cada valor.

Inteligencia de dispositivos y prevención del fraude

Estas reglas convierten las señales del SDK de cliente (huella digital del dispositivo, dirección IP, navegador, antigüedad de la sesión) y el enriquecimiento proporcionado por los proveedores en eventos de detección de fraude.

Huella digital del dispositivo y multicuentas

IP, red y VPN

Señales de comportamiento combinadas

Toma de control de cuentas y fraude APP

Abuso de afiliados y bonos


Paquete de juego responsable

Para aplicaciones de iGaming. Estas reglas están diseñadas para detectar tanto señales de protección del jugador como patrones de abuso de bonos.

Paquete de fraude en iGaming

Para operadores que envían eventos de monitorización además de movimientos de dinero. Estas reglas usan scope.record_types = ["event"], así que los clientes que solo envían transacciones no notan ningún cambio de comportamiento. Cuando existe una regla alternativa basada solo en transacciones, instálala junto a la regla de eventos hasta que tu integración envíe esa categoría de eventos.

Señales de eventos que necesita cada regla

Cada una de las reglas anteriores lee campos de eventos concretos. Cuando falta un campo obligatorio, la regla simplemente no coincide: nunca aproxima la señal a partir de otro dato y nunca recurre por sí sola a los datos de transacciones. Envía las claves siguientes en el payload y el device_context del evento (consulta Eventos para ver el contrato de envío completo y Reglas de eventos para ver las rutas de campos de las reglas). Usa el paquete igaming_fraud cuando tu integración emita eventos de inicio de sesión, juego, bonos, afiliados, pagos, disputas, seguridad y juego responsable. Las reglas siguen siendo opcionales: añadirlas a la biblioteca no las instala en las aplicaciones existentes ni cambia los presets actuales de ningún cliente activo.

Paquete de comercio electrónico

Para marketplaces y aplicaciones que actúan como comerciante registrado (merchant of record).

Paquete de fraude con cheques

Para aplicaciones que envían transacciones de depósito de cheques. Cada regla se dispara a partir de los indicadores custom_values.check_* que establece quien realiza la solicitud cuando un cheque presenta una señal de riesgo conocida (lavado de cheques, MICR ausente, número de serie publicado en la dark web, etc.).

Paquete BNPL

Para proveedores de compra ahora, paga después (BNPL). Detecta patrones de fraude de primera parte (impago) y de uso compartido de identificadores propios de los préstamos a plazos.

Referencia: estándares en los que se basa la biblioteca

Cada preset de la biblioteca de Didit corresponde a una tipología AML, de fraude o de cumplimiento ampliamente aceptada. Estos son los estándares en los que nos apoyamos: Didit implementa solo las tipologías que son estándares aceptados del sector y expone todos los umbrales para que los ajustes.

Personalizar los presets

Cada preset puede ser:
  • Ajustado: cambia umbrales, ventanas, valores de puntuación o acciones por aplicación
  • Desactivado: cambia un preset al modo DISABLED y deja de evaluarse sin perder su identidad
  • Probado: cambia un preset al modo TEST para evaluarlo en modo sombra sin afectar al resultado de las transacciones
  • Ampliado: crea reglas personalizadas que complementen o sustituyan a los presets
Consulta Reglas y puntuación para conocer la anatomía de las reglas, los endpoints de la API y ejemplos prácticos de creación de reglas personalizadas.
Última modificación el 1 de noviembre de 2026