Propagación de Listas Negras: Cómo un Caso de Abuso Confirmado Puede Aniquilar Toda la Red (ES)

Hay un momento específico en el que la mayoría de los programas de abuso pierden valor: el momento después de ganar.

Su capa de tráfico marca una cuenta. Un analista investiga. La evidencia es sólida, el caso se confirma, la cuenta es prohibida. Y luego, horas más tarde, el mismo operador vuelve con nuevas cuentas, porque lo único que su aplicación tocó fue una fila en una tabla de usuarios.

Anthropic describió exactamente esta dinámica en su informe de febrero de 2026 sobre campañas de destilación, una red proxy que "gestionaba más de 20.000 cuentas fraudulentas simultáneamente", reemplazándolas a medida que eran eliminadas. La eliminación no era el cuello de botella. La regeneración era más barata que la eliminación.

La solución es hacer que la aplicación opere sobre identificadores en lugar de cuentas. La API de Listas de Didit se basa en una mecánica que hace esto en una sola llamada.

Puntos clave

• La inclusión en la lista negra con reference_session_id hace que Didit extraiga automáticamente el valor correcto de la sesión (cara, documento, teléfono, correo electrónico, IP o dispositivo), marque el modelo subyacente como incluido en la lista negra y vincule la entrada a la sesión de origen.
• 12 tipos de entrada: face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key.
• Las listas negras son creadas por el sistema, una por tipo de entrada, e inmutables. No se pueden crear, lo que hace que la aplicación sea uniforme.
• Las entradas entran en vigor inmediatamente en el momento de la verificación. La eliminación de una entrada desbloquea la coincidencia.
• ip_address acepta un rango CIDR, por lo que puede incluir en la lista negra la infraestructura en lugar de una sola dirección.
• Las listas blancas en los mismos 12 tipos mantienen a los desarrolladores de confianza fuera de cada ruta de escalada.

Los dos tipos de listas que importan

La API tiene tres tipos de listas, y la distinción entre ellas es deliberada.

Las listas negras son creadas por el sistema (una por tipo de entrada) e inmutables. No se pueden crear, renombrar ni eliminar. Se añaden y eliminan entradas. Esa restricción es una característica: significa que "en lista negra" tiene exactamente un significado en toda su organización, y no hay forma de terminar con cuatro listas negras de caras en competencia que diferentes servicios verifican de manera inconsistente.

Las listas blancas son suyas para crear. Aquí van los dispositivos conocidos y buenos, los rangos de direcciones, las entidades comerciales y los usuarios.

Las listas personalizadas son para todo lo demás: sus propias taxonomías, grupos de vigilancia, cohortes de revisión.

# Encontrar la lista negra de caras
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

La mecánica que importa

Esta es la forma ordinaria de incluir algo en la lista negra, y es la forma incorrecta en casi todas las situaciones reales:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

Eso incluye una dirección en la lista negra. Mientras tanto, la sesión que estaba investigando también contenía una cara, un número de documento, un teléfono, un correo electrónico y una huella digital del dispositivo, cada uno de ellos un identificador que el operador tiene que reemplazar antes de regresar.

La mejor llamada:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

Pase reference_session_id y Didit extrae automáticamente el valor correcto para el tipo de entrada de esa lista de la sesión, marca el modelo subyacente como incluido en la lista negra y vincula la entrada a la sesión para que la consola pueda mostrarle de dónde proviene.

De eso se derivan tres cosas, y las tres importan operativamente:

Sin extracción manual. Su analista no lee una huella digital del dispositivo de una pantalla y la vuelve a escribir. Los errores de transcripción en los datos de aplicación son fallas silenciosas: la prohibición simplemente no se activa y nadie se entera.

La procedencia se conserva. Cada entrada se vincula a la sesión que la justificó. Cuando alguien pregunta en cuatro meses por qué este dispositivo está bloqueado, la respuesta es un clic, no un proyecto de arqueología.

La aplicación es repetible. La misma llamada contra cada lista negra de tipo de entrada cubre toda la superficie de identificadores de la sesión.

Si una sesión contiene varias instancias del mismo tipo, pase value junto con reference_session_id para desambiguar.

También puede aplicar desde fuera de una sesión de verificación. reference_object_uuid junto con metadata.reference_type (transaction, vendor_user o vendor_business) incluye en la lista negra desde una transacción o desde un usuario o negocio del proveedor, y mantiene el mismo vínculo con la fuente.

Los 12 tipos de entrada

Tipo de entrada	Bloquea	Notas
face	La persona	También se puede cargar directamente mediante carga de cara
document	La credencial
phone	El número	Normalizado automáticamente a E.164
email	La dirección
ip_address	La dirección o rango	Acepta CIDR, ej. 10.0.0.0/8
device_fingerprint	La máquina	Mínimo 8 caracteres alfanuméricos
wallet_address	La dirección en cadena
bank_account	La cuenta
user	El registro de usuario
business	La entidad
country	La jurisdicción
key	Una clave personalizada

Dos merecen ser destacadas para este problema.

ip_address acepta un rango CIDR. La inclusión en la lista negra de 203.0.113.0/24 bloquea la infraestructura, no una dirección. Cuando una operación de fraude se ejecuta en una subred alquilada, esta es la diferencia entre una aplicación que escala y una aplicación que juega al topo. Úselo con cuidado: un rango también cubre a usuarios reales, y los rangos demasiado amplios son la forma de prohibir silenciosamente el operador de telefonía móvil de un país.

face admite la carga directa. Cuando tiene una imagen pero no una sesión, cárguela directamente:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<imagen codificada en base64>" }'

Didit extrae el dato biométrico. A partir de ese momento, esa cara se verifica en cada verificación.

Qué sucede después de que una entrada se registra

Agregar a una lista negra del sistema bloquea las futuras coincidencias inmediatamente en el momento de la verificación. No hay retraso de propagación ni trabajo por lotes.

En la siguiente verificación, la aplicación se manifiesta como advertencias:

• FACE_IN_BLOCKLIST — coincidencia definitiva, verificación denegada. POSSIBLE_FACE_IN_BLOCKLIST es una coincidencia límite por debajo del umbral estricto y debe dirigirse a revisión, no a denegación.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — aciertos de red y dispositivo.

En Face Search, una coincidencia en la lista negra es lo único que establece el status en "Declined". Cada coincidencia en la respuesta también lleva is_blocklisted, por lo que una investigación le muestra inmediatamente qué partes de un clúster ya están bajo aplicación y cuáles aún están activas.

La eliminación es simétrica: eliminar una entrada desbloquea la entidad coincidente. La aplicación es reversible por diseño, lo cual es importante porque la aplicación demasiado amplia es un riesgo real y necesita un camino limpio de regreso.

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

Listas blancas: protegiendo a los desarrolladores que desea

La aplicación que solo escala eventualmente estrangula el producto. Los mismos 12 tipos de entrada admiten listas blancas, y son la válvula de presión.

Incluya en la lista blanca los rangos de IP de la oficina de un socio de diseño. Incluya en la lista blanca los dispositivos del equipo de ingeniería de un cliente empresarial. Incluya en la lista blanca una entidad comercial verificada para que sus usuarios nunca lleguen a una ruta de escalada. IP_ADDRESS_IN_ALLOWLIST y DEVICE_FINGERPRINT_IN_ALLOWLIST se activan cuando ocurre una coincidencia, por lo que puede confirmar que la exención se aplicó en lugar de asumir que lo hizo.

Este es el mecanismo que hace que la aplicación agresiva sea sostenible. Puede permitirse una política estricta sobre infraestructura desconocida precisamente porque su población conocida y buena está explícitamente excluida.

Errores que vale la pena manejar

• 400 — el valor no pasó el validador del tipo de entrada, el list_type es incorrecto para la operación (por ejemplo, una carga de cara contra una lista que no es de cara), o reference_session_id no tiene datos del tipo solicitado. Este último caso es común y benigno: no todas las sesiones capturan todos los identificadores.
• 403 — {"detail": "No tiene permiso para realizar esta acción."}

Tenga en cuenta que se espera un 400 de "la sesión no tiene datos de ese tipo" cuando se recorre una sesión a través de todas las listas negras de tipos de entrada. Manéjelo como un salto, no como un error.

Un flujo de aplicación de ejemplo

Un analista ha confirmado el abuso en la cuenta acct_8842.

1. Resuelva el clúster primero. La búsqueda de caras en la cara de la sesión devuelve doce cuentas; la correlación de dispositivos e IP atrae a una docena más. La aplicación antes de la resolución prohíbe una cuenta y advierte al operador.
2. Incluya en la lista negra desde la sesión confirmada — reference_session_id contra las listas negras de cara, dispositivo, IP, correo electrónico, teléfono y documento. Seis llamadas, sin extracción manual, procedencia completa.
3. Considere el rango. Si la evidencia de la red apunta a infraestructura alquilada, una entrada CIDR cubre la subred. Verifique qué más vive allí primero.
4. Actúe sobre el clúster de acuerdo con su propia política: las cuentas que ya identificó no se desbloquean solas.
5. Verifique la aplicación. Vuelva a ejecutar la búsqueda de caras. Las coincidencias ahora deberían llevar is_blocklisted: true.
6. Espere el intento de regeneración. La siguiente cuenta creada con esa cara, dispositivo o subred se deniega en la verificación en lugar de aparecer en su tráfico tres semanas después.

El paso 6 es el objetivo principal. El costo del operador para regresar ya no es "crear una nueva dirección de correo electrónico". Es "adquirir nuevo hardware, nueva red y una nueva persona".

Casos de uso

Plataformas de API de IA que convierten un caso confirmado de destilación o abuso en aplicación en cada identificador que el operador tocó.

Abuso de pruebas y crédito donde el mismo dispositivo y cara siguen regresando para una nueva asignación gratuita.

Mercados que impiden que los vendedores eliminados se vuelvan a registrar bajo un nuevo negocio.

iGaming que aplica la autoexclusión, donde un jugador excluido que regresa es un fallo regulatorio y la aplicación a nivel de cara es el único control fiable.

Preguntas frecuentes

¿Puedo crear mi propia lista negra?

No. Las listas negras son creadas por el sistema, una por tipo de entrada, e inmutables; usted añade y elimina entradas. Puede crear listas blancas y listas personalizadas libremente. La restricción mantiene el significado de "en lista negra" uniforme en todas partes.

¿Qué tan rápido entra en vigor una entrada?

Inmediatamente, en la siguiente verificación.

¿Qué pasa si incluyo algo en la lista negra por error?

Elimine la entrada y la entidad se desbloquea. Por eso la procedencia es importante: cada entrada creada a partir de una sesión se vincula a ella, por lo que puede auditar para qué era una entrada antes de eliminarla.

¿Afecta la inclusión de un rango de IP en la lista negra a los usuarios legítimos de ese rango?

Sí, y ese es el riesgo. Una entrada CIDR bloquea todo lo que contiene. Use rangos cuando la evidencia apunte a infraestructura dedicada, use direcciones únicas de lo contrario, e incluya en la lista blanca los rangos conocidos y buenos primero.

¿Puedo incluir en la lista negra desde algo que no sea una sesión de verificación?

Sí. reference_object_uuid más metadata.reference_type (transaction, vendor_user o vendor_business) cubre transacciones y usuarios o negocios del proveedor.

¿Esto detiene la extracción de modelos?

No. Detiene a un actor conocido específico de volver a entrar a través de los identificadores que ha aplicado, y aumenta el costo de regeneración. Detectar la extracción en primer lugar es trabajo de su capa de tráfico, y limitar lo que produce la extracción es trabajo de su capa de modelo. Este es el brazo de aplicación de una defensa de tres capas, no un reemplazo de las otras dos.

¿Listo para empezar?

La API de Listas está disponible en todas las cuentas de Didit.

• Lea la documentación — Descripción general de la API de Listas y el catálogo de advertencias de IP y Dispositivos.
• Vea el producto — Verificación de Usuario.
• Consulte los precios — públicamente listados, pago por éxito, sin mínimos.
• Empiece gratis — business.didit.me, 500 verificaciones KYC al mes sin costo.