> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Reglas y puntuación KYT: velocidad y condiciones

> Configura reglas KYT en Didit con condiciones, ventanas de velocidad y acciones automáticas. 1,000 al mes incluidas, luego $0.001 cada una.

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.

[Crear una regla — Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> Las reglas se pueden gestionar desde la **Consola empresarial**, la **Management API** y el **Didit MCP**. Usa la consola cuando una persona de tu equipo de cumplimiento deba revisar cada cambio; usa la API o el MCP cuando las reglas se creen y ajusten de forma programática, por ejemplo al migrar un conjunto de reglas desde otro proveedor. Consulta la [referencia de la API](https://docs.didit.me/es/management-api/transactions/rules-list.md) y la [guía para gestionar reglas mediante la API y el MCP](https://docs.didit.me/es/transaction-monitoring/rules-api.md). Las reglas se evalúan en cada transacción enviada mediante [`POST /v3/transactions/`](https://docs.didit.me/es/management-api/transactions/create), y el resultado aparece en el array `rule_runs[]` de la transacción (consulta el [esquema de respuesta](https://docs.didit.me/es/transaction-monitoring/response-schema.md)).

## 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](https://docs.didit.me/es/management-api/transactions/rules-install.md) 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](https://docs.didit.me/es/transaction-monitoring/rules-library.md).

| Paquete | Ejemplos |
| - | - |
| **Finanzas** | Detección de fraccionamiento (entrante/saliente), transacciones individuales de gran importe por encima de los umbrales de notificación |
| **AML/CTF** | Límites de volumen acumulado, entradas y salidas rápidas de fondos, coincidencia de contrapartes con listas de sanciones, palabras clave sospechosas en la referencia del pago |
| **Detección de anomalías** | Gran frecuencia de entradas/salidas, reactivación de cuentas inactivas tras 12+ meses sin actividad |
| **FATF** | Exposición a jurisdicciones de alto riesgo asociada a las contrapartes y a las direcciones IP del sujeto |
| **Inteligencia de dispositivos** | Uso repetido de campañas de bonificación desde la misma huella de dispositivo, varias huellas de dispositivo para el mismo sujeto |
| **Prevención del fraude** | Multicuentas mediante huellas de dispositivo compartidas entre sujetos distintos |
| **Monitorización cripto** | Exposición a mezcladores o servicios de ofuscación, direcciones de wallet de alto riesgo (darknet, sancionadas, fondos robados) |
| **Análisis cripto** | Exposición a un origen de los fondos de alto riesgo (>30%), varias contrapartes de riesgo, rechazo automático por financiación del terrorismo o explotación infantil, retención mientras el análisis está pendiente, marcado de wallets con puntuación de riesgo media |
| **Juego responsable** | Ráfagas rápidas de depósitos en ventanas cortas |
| **Comercio electrónico** | Patrones de transacciones propios del comercio electrónico |

## Orígenes de las reglas

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

| Origen | Descripción |
| - | - |
| **Ajuste predefinido** | Reglas instaladas desde la biblioteca integrada de Didit. Tú eliges qué ajustes predefinidos (o paquetes completos) instalar y controlas el modo de cada uno de ellos (`Active`, `Test`, `Disabled`). Sus condiciones y umbrales son fijos (para modificar uno, crea una regla personalizada) y se eliminan desinstalándolos, no borrándolos. |
| **Personalizado** | Reglas creadas por tu equipo desde la Consola empresarial. Tienes control total sobre las reglas personalizadas: créalas, edítalas y elimínalas según lo necesites. |

## Anatomía de una regla

Cada regla consta de:

| Componente | Descripción |
| - | - |
| **Título y descripción** | Nombre legible y explicación de lo que detecta la regla |
| **Categoría** | Agrupación lógica (p. ej., `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **Modo** | `Active` (evaluación en producción), `Disabled` (se omite) o `Test` (se evalúa, pero los resultados no afectan a la transacción) |
| **Modo de evaluación** | `All` (deben cumplirse todas las condiciones) o `Any` (debe cumplirse al menos una condición) |
| **Ámbito** | Limita las transacciones a las que se aplica la regla. Claves: `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types`; si está vacío o no se indica, no hay restricción |
| **Condiciones** | Comprobaciones a nivel de campo: comparan campos de la transacción con valores mediante operadores como `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` |
| **Agregación** | Ventanas de velocidad: agregan transacciones históricas durante un periodo de tiempo (p. ej., recuento, suma o recuento de valores distintos en 1 hora, 7 días o 30 días) |
| **Acciones** | Lo que ocurre cuando la regla se cumple (ver más abajo) |

## 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:

| Acción | `type` | Claves | Descripción |
| - | - | - | - |
| **Añadir puntuación** | `add_score` | `value` (entero, puede ser negativo) | Suma puntos a la puntuación de riesgo de la transacción. La puntuación acumulada de todas las reglas que coinciden determina si la transacción supera el umbral de revisión o el de rechazo. |
| **Cambiar estado** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, alias `status`), `workflow_id` (alias `remediation_workflow_id`) | Establece directamente el estado de la transacción, sin importar la puntuación. `workflow_id` es obligatorio cuando `value` es `AWAITING_USER`; si lo omites, se devuelve `400`. |
| **Añadir etiquetas** | `add_tags` | `tag_uuid` o `tag_name` (uno de los dos), `tag_color` | Etiqueta la transacción para clasificarla y filtrarla. Usa el `tag_uuid` de una etiqueta existente o un `tag_name` que se crea la primera vez que se usa (se guarda en mayúsculas); `tag_color` define el color hexadecimal de una etiqueta recién creada. |
| **Añadir nota** | `add_note` | `note` (alias `value`) | Adjunta a la transacción una nota de texto automática que da contexto al analista. |
| **Añadir a una lista** | `add_to_list` | `list_id` | Añade el `vendor_data` del sujeto a una lista de bloqueo, una lista de permitidos o una lista personalizada. |
| **Abrir caso** | `open_case` | `blueprint` (UUID de la plantilla de caso, opcional), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (booleano) | Abre un caso de investigación (o añade la transacción a uno existente). Solo se aplica la primera acción `open_case` de una regla. |

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](https://docs.didit.me/es/transaction-monitoring/sdk-transaction-submission.md#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](https://docs.didit.me/es/transaction-monitoring/settings.md#flujo-de-remediación).
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](https://docs.didit.me/es/transaction-monitoring/wallet-ownership-widget.md).

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](https://docs.didit.me/es/transaction-monitoring/sdk-transaction-submission.md#ejemplo-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`.

> [!NOTE]
>
> Puedes usar cualquier tipo de flujo, excepto KYB, como acción de remediación.
> Los flujos de Autenticación biométrica (y los flujos en los que la coincidencia facial se ejecuta antes de la verificación de identidad) requieren además una cara de referencia guardada del sujeto: una selfie de prueba de vida aprobada, una foto del chip del pasaporte, un retrato del documento o un rostro registrado manualmente en el perfil.
> Si no existe ninguna, se pide al usuario que complete el flujo predeterminado de tu aplicación, lo que también registra su cara para la próxima vez, y una nota en la transacción deja constancia de la sustitución.
> Solo si tampoco existe un flujo predeterminado adecuado no se crea la sesión, y la nota explica el motivo.

## 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):

| Ajuste | Valor predeterminado | Descripción |
| - | - | - |
| **Umbral de revisión** | 75 | Las puntuaciones iguales o superiores a este valor activan `IN_REVIEW` |
| **Umbral de rechazo** | 500 | Las puntuaciones iguales o superiores a este valor activan `DECLINED`. Con el valor predeterminado (`500`), nunca se rechaza por puntuación |

## 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](https://docs.didit.me/es/integration/mcp/tools.md) y desde cualquier asistente de IA conectado por MCP).

> [tab] Consola
>
> 1. Ve a **Transacciones** > **Reglas** en la consola
> 2. Haz clic en **Crear regla**
> 3. Define el título, la descripción y la categoría de la regla
> 4. Establece el **modo**: `Active` para ejecutarla en producción, o `Test` para evaluarla sin afectar a las transacciones
> 5. Elige el **modo de evaluación**: `All` (deben cumplirse todas las condiciones) o `Any` (al menos una)
> 6. Establece el **alcance**: a qué tipos o sentidos de transacción se aplica la regla
> 7. Añade **condiciones**: comparaciones de campos como umbrales de importe, códigos de país o comprobaciones de propiedades personalizadas
> 8. De forma opcional, añade una **agregación**: comprobaciones de velocidad sobre una ventana de tiempo (recuento, suma, recuento de valores distintos y más)
> 9. Define una o más **acciones**: sumar puntuación, cambiar el estado, añadir etiquetas, añadir notas, añadir a una lista o abrir un caso
> 10. Guarda y activa la regla

> [tab] API
>
> Invoca el endpoint [`POST /v3/transactions/rules/`](https://docs.didit.me/es/management-api/transactions/rules-create) con los mismos campos: `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`. La referencia completa de campos, operadores y acciones está en esta página, y [gestionar reglas mediante la API y MCP](https://docs.didit.me/es/transaction-monitoring/rules-api.md) explica paso a paso el flujo recomendado crear -> backtest -> activar, incluida la migración de un conjunto de reglas desde la exportación CSV de otro proveedor.

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/`](https://docs.didit.me/es/management-api/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:

| Métrica | Descripción |
| - | - |
| `count` | Número de transacciones que cumplen los filtros dentro de la ventana |
| `sum` | Total de un `field` numérico (p. ej., `preferred_currency_amount`) dentro de la ventana |
| `max` / `min` / `avg` | Valor máximo, mínimo o promedio de un `field` numérico dentro de la ventana |
| `distinct_count` | Número de valores únicos de un `field` (p. ej., huellas de dispositivo distintas) dentro de la ventana (`unique_count` se acepta como alias) |

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](#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

| Patrón | Cómo funciona |
| - | - |
| **Fraccionamiento (structuring)** | Recuento de transacciones del mismo sujeto en 30 días >= 20, con un `max` de importe inferior a \$10,000 en la misma ventana |
| **Alta velocidad** | Recuento de transacciones entrantes del mismo sujeto en 7 días >= 20 |
| **Entrada y salida rápida** | La transacción actual es saliente + recuento de transacciones entrantes del mismo sujeto en 6 horas >= 1 |
| **Multicuenta** | Recuento de sujetos distintos que comparten la misma huella de dispositivo en 7 días >= 3 |
| **Reactivación tras inactividad** | Días desde la transacción anterior del sujeto >= 365, combinados con un importe >= \$1,000 |

## Catálogo de campos

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

| Campo | Descripción |
| - | - |
| `amount`, `currency` | El importe de la transacción y su código de moneda |
| `preferred_currency_amount`, `default_currency_code` | Importe convertido a la moneda preferida de tu aplicación (si no está disponible, se usa `amount_in_default_currency`) |
| `direction` | `INBOUND` u `OUTBOUND` |
| `action_type` | Tu tipo de acción, por ejemplo `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` |
| `payment_details` | Referencia de pago en texto libre (el campo sobre el que actúa `contains_any` en las reglas de palabras clave) |
| `score`, `severity` | La puntuación de riesgo y la severidad actuales de la transacción |
| `subject_vendor_data`, `counterparty_vendor_data` | Tus identificadores para las dos partes |
| `subject_country`, `counterparty_country` | Códigos de país de las partes (se aceptan ISO-2 e ISO-3; se normalizan antes de la comparación) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | Huella del dispositivo o identificador persistente del dispositivo |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | Detalles del contexto del dispositivo (también está disponible `counterparty_browser_family`) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | Contexto de red |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | El método de pago del sujeto (existen los mismos cuatro campos para `counterparty_payment_method_*`) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Estado de la comprobación de Travel Rule |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | Lo que sabes del VASP de contraparte al que llegó el intercambio de Travel Rule: tu decisión sobre él (`APPROVED`, `RESTRICTED`, `BLOCKED`), su nivel de riesgo (`LOW`, `MEDIUM`, `HIGH`; `HIGH` mientras tu propio análisis de la contraparte esté marcado), su país y su capacidad de respuesta (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`). Consulta [Diligencia debida de contrapartes en Travel Rule](https://docs.didit.me/es/transaction-monitoring/travel-rule.md#campos-de-regla-y-presets) |
| `subject_days_since_previous_transaction` | Días transcurridos desde la transacción anterior del mismo tipo de este sujeto (reglas de inactividad) |
| `tags` | Los nombres de las etiquetas de la transacción |
| `custom_values.<key>` | Cualquier clave que hayas enviado en `custom_properties` al crear la transacción |

## Operadores de condición

Las reglas admiten los siguientes operadores de comparación para las condiciones:

| Operador | Descripción | Ejemplo |
| - | - | - |
| `eq` / `ne` | Igual / distinto | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | Comparaciones numéricas y de fechas; nunca coinciden si falta alguno de los dos lados | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | Pertenencia a una lista (también se acepta un único valor escalar) | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | Subcadena, sin distinguir mayúsculas de minúsculas, dentro de un valor de texto | `payment_details contains "refund"` |
| `contains_any` | Alguna de las cadenas de una lista es una subcadena del campo, sin distinguir mayúsculas de minúsculas | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | El patrón indicado en el valor coincide con el campo | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | Similitud aproximada de cadenas; requiere un umbral `score` (0-100) en la condición | `counterparty_name fuzzy_match "Acme Corp"` con `score: 85` |
| `exists` / `is_not_empty` / `is_not_null` | El campo está presente (son alias; se ignora `value`) | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | El campo no está presente o está vacío (son alias; se ignora `value`) | `subject_ip_address is_empty` |

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`:

| `value_type` | Significado |
| - | - |
| `list` | `value` es el UUID de una lista: las entradas de la lista de bloqueo, de la lista de permitidos o de la lista personalizada pasan a ser el valor de comparación, de modo que una regla puede coincidir con "contraparte incluida en mi lista de vigilancia personalizada". |
| `field` | `value` es la ruta de otro campo: la condición compara dos campos de la transacción, por ejemplo `subject_payment_method_account_id ne counterparty_payment_method_account_id`. |
| `relative_date` | `value` es una fecha relativa, por ejemplo `{"direction": "past", "unit": "days", "amount": 30}`, para campos de fecha como `txn_date`. |

### 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/`](https://docs.didit.me/es/transaction-monitoring/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:

| Entidad | Tipo de lista de bloqueo | Qué se comprueba |
| - | - | - |
| **Usuario (solicitante)** | Lista de bloqueo de usuarios | El identificador `vendor_data` del solicitante |
| **Empresa** | Lista de bloqueo de empresas | El identificador `vendor_data` de la empresa |
| **Dirección de wallet** | Lista de bloqueo de direcciones de wallet | El `account_id` de los métodos de pago con wallet de criptomonedas |
| **Cuenta bancaria** | Lista de bloqueo de cuentas bancarias | El `account_id` de los métodos de pago por transferencia bancaria |
| **Dirección IP** | Lista de bloqueo de direcciones IP | La dirección IP del contexto de dispositivo de la parte (admite rangos CIDR) |
| **Huella del dispositivo** | Lista de bloqueo de huellas de dispositivo | La huella del dispositivo o el ID persistente del dispositivo |

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

> [!NOTE]
>
> Las comprobaciones de listas de bloqueo se ejecutan antes de evaluar las reglas. Una entidad incluida en una lista de bloqueo siempre se rechazará, independientemente de la configuración de las reglas o de los umbrales de puntuación.

## 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

> [card] [Envío de transacciones](https://docs.didit.me/es/transaction-monitoring/transactions.md)
>
> Cómo se estructuran las transacciones para la evaluación de reglas.

> [card] [Análisis de criptoactivos](https://docs.didit.me/es/transaction-monitoring/aml-screening.md)
>
> Resultados del análisis de criptoactivos y cómo los usan las reglas predefinidas.

> [card] [Configuración](https://docs.didit.me/es/transaction-monitoring/settings.md)
>
> Configura los umbrales de puntuación y los flujos de remediación.

> [card] [Referencia de la API](https://docs.didit.me/es/management-api/transactions/create.md)
>
> Endpoint de la API Create Transaction.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.