Saltar al contenido principal
Todas las funciones relacionadas con las reglas de la Business Console también están disponibles de forma programática: a través de la Management API con la clave de API de tu aplicación y a través del Didit MCP para agentes de IA que actúan como un usuario de la consola con sesión iniciada. Úsalas para gestionar reglas desde código, mantener los conjuntos de reglas bajo control de versiones o dejar que un asistente de IA cree y migre reglas por ti.

​
Qué interfaz usar en cada caso

​
Los endpoints

Las herramientas MCP correspondientes son didit_transaction_rule_list, didit_transaction_rule_get, didit_transaction_rule_create, didit_transaction_rule_update, didit_transaction_rule_delete, didit_transaction_rule_backtest, didit_transaction_rule_library_list, didit_transaction_rule_install y didit_transaction_rule_uninstall; consulta la referencia de herramientas MCP. El esquema completo (el catálogo de campos, los 19 operadores de condición, las ventanas de velocidad, las condiciones agrupadas y los seis tipos de acción) está documentado en la página Reglas y puntuación e integrado en la referencia de la API.

​
Crear, hacer backtest y activar

El patrón de despliegue seguro para cualquier regla nueva:
1

Crea la regla en modo TEST

Lee el payload en dos mitades. scope y conditions describen la transacción que se evalúa: una transacción financiera entrante en EUR con un amount sin convertir inferior a 10,000. Las entradas de aggregation describen la ventana de 30 días para el mismo sujeto: al menos 20 transacciones financieras entrantes en EUR, y ninguna de ellas de 10,000 EUR o más. Ambas entradas de agregación deben cumplirse, diga lo que diga evaluation_mode: ese ajuste solo rige las condiciones.Este ejemplo usa el amount sin convertir y fija currency en EUR en ambas mitades, por lo que no depende de la normalización de divisas. Para hacer el backtest con datos de prueba en sandbox, envía al menos 20 transacciones financieras entrantes en EUR para el mismo sujeto en un plazo de 30 días, cada una con un amount inferior a 10,000. No se requiere ni preferred_currency_amount ni amount_in_default_currency. La ingesta en sandbox almacena estas transacciones; ejecuta el backtest de forma explícita.Una regla en TEST se evalúa en cada transacción nueva y registra las coincidencias que habría encontrado, pero nunca modifica la puntuación ni el estado de la transacción.
Un filtro de agregación no es una condición. Una condición solo lee la transacción que se evalúa; un filtro de agregación solo acota la ventana histórica y compara por igualdad o pertenencia a una lista. No existe un filtro lt, así que no puedes contar solo las transferencias inferiores a 10,000.La entrada max ... lt 10000 es la forma admitida de poner un tope a la ventana: exige que todas las transacciones de la ventana sean inferiores a 10,000, lo cual es más estricto que contar solo las pequeñas. Una sola transferencia de 12,000 entre las veinte impide que la regla se dispare. Elimina esa entrada si prefieres que el recuento funcione por sí solo, y entonces indícalo en el título: sin ella, la regla cuenta transferencias entrantes de cualquier importe, y diecinueve transferencias de 50,000 seguidas de una pequeña la cumplen.
2

Haz el backtest contra tu historial

Un recuento de matched inesperado significa que hay que ajustar los umbrales antes de que la regla pueda actuar sobre nada.
Haz el backtest con las opciones exactas que vas a activar: los mismos conditions, aggregation, evaluation_mode y scope. Si omites conditions, aggregation y scope, no añaden restricciones propias; prescindir del scope puede incluir sentidos o tipos de transacción que la regla guardada omite. Si omites evaluation_mode, toma ALL por defecto, así que omitirlo en una regla ANY puede reducir las coincidencias. Si omites period_days, toma 90 días por defecto; no selecciona un historial ilimitado.
3

Activa la regla

La regla se aplica de inmediato a todas las transacciones nuevas de una aplicación en producción.
Las aplicaciones de sandbox nunca evalúan reglas. Una transacción de sandbox se almacena y nada más, por lo que activar una regla en una aplicación de sandbox no cambia nada que puedas observar. El backtest es la forma admitida de probar una regla antes de pasarla a producción; consulta Monitorización de transacciones en sandbox.

​
Migrar reglas desde otro proveedor

Como la creación de reglas es una simple llamada a la API con un esquema totalmente documentado, un asistente de IA puede convertir por ti la exportación de reglas de otro proveedor en reglas de Didit.
  1. Exporta tus reglas desde el proveedor actual: la mayoría de las herramientas exportan a CSV o Excel.
  2. Suelta el archivo en el asistente de la consola de Didit (o en cualquier agente conectado por MCP, como Claude con el MCP de Didit añadido). Las hojas de cálculo se convierten a texto automáticamente.
  3. El asistente asigna cada fila al esquema de Didit (condiciones, ventanas de velocidad, acciones) y te muestra esa correspondencia, señalando todo lo que no tiene equivalente en Didit, antes de crear nada.
  4. Cuando le das el visto bueno, crea las reglas en modo TEST, hace un backtest con tu propio historial de transacciones e informa de las filas creadas, fallidas y sin correspondencia.
  5. Revisa las cifras y activa las reglas que te parezcan correctas, desde la consola o con un PATCH {"mode": "ACTIVE"}.
Una exportación de un proveedor como esta:
se convierte en reglas como estas:
La fila del CSV indica una dirección y una divisa, así que ambas mitades de la regla las incluyen: scope y conditions limitan la transacción evaluada a una transferencia saliente en EUR inferior a 10,000, y los filtros de agregación limitan la ventana de 30 días a las transferencias salientes en EUR de ese mismo sujeto. El amount sin normalizar solo es comparable dentro de una misma divisa: mantén la divisa fijada como se muestra arriba. Un límite entre divisas requiere un importe normalizado para cada transacción de la ventana. Cambiar solo a preferred_currency_amount no garantiza su disponibilidad: las agregaciones numéricas pueden tratar como cero los importes normalizados históricos que falten. La entrada max es lo que mantiene la ventana por debajo de 10,000 EUR, porque un filtro de agregación no puede expresar inferior a 10,000; consulta la nota del paso de creación más arriba para ver la contrapartida que implica. Conviene dejar explícito en la description de la regla todo lo que el esquema no pueda expresar con exactitud, en lugar de aproximarlo en silencio.
Antes de recrear como personalizada una regla de un proveedor, consulta la biblioteca de reglas: Didit incluye 150+ ajustes predefinidos que cubren las tipologías habituales (fraccionamiento, velocidad, exposición a sanciones, reutilización de dispositivos, riesgo cripto), e instalar uno requiere una sola llamada a la API.

​
Los errores de validación son precisos a propósito

Los endpoints de creación y actualización validan los valores de condiciones, agregación y alcance exactamente según lo que acepta el motor de reglas: operadores o métricas desconocidos, ventanas mal formadas ("30days" en lugar de "30d"), direcciones no válidas en el alcance, contains_any sin una lista, fuzzy_match sin un score y change_status con AWAITING_USER sin un workflow_id devuelven un 400 que indica el índice y el problema, en lugar de guardar una regla que nunca coincide sin avisar. Los agentes y scripts deben leer el cuerpo del error y corregir el payload. Las claves de alcance adicionales a transaction_types, directions y action_types se guardan, pero el motor las ignora, igual que la Business Console siempre las ha guardado.

​
Próximos pasos

Reglas y puntuación

El esquema completo de reglas: campos, operadores, ventanas de velocidad y acciones.

API para crear reglas

Referencia del endpoint con los esquemas de solicitud y respuesta.

Biblioteca de reglas

El catálogo de 150+ ajustes predefinidos y sus paquetes.

Visión general de MCP

Conecta un agente de IA a tu espacio de trabajo de Didit.
Última modificación el 1 de noviembre de 2026