Documentación

Cómo construir un flujo de trabajo de monitoreo

Cómo mantener actualizados los resultados de verificación a medida que cambian las listas, usando nuestra API o archivos delta, sin abrumar a los revisores con actualizaciones de rutina.

La verificación comprueba a una parte una sola vez. El monitoreo la comprueba de nuevo cada vez que cambian las listas y genera una alerta solo cuando surge algo nuevo que importa. No operamos un servicio de monitoreo para los clientes: esta guía muestra cómo construir uno sobre nuestra API o nuestros archivos masivos.

Verificación y monitoreo

El monitoreo repite tres pasos: detectar que los datos cambiaron, volver a verificar a las partes que podrían verse afectadas y comparar los nuevos resultados con las decisiones que ya tomó. La parte difícil es el tercer paso: un buen sistema de monitoreo genera una alerta ante una nueva inclusión en una lista, no ante cada actualización rutinaria de los datos.

Cómo construir su estado de alertas

Diseñe primero el modelo de alertas

Parta de sus obligaciones: qué listas, qué programas y qué jurisdicciones le importan. Luego conserve una decisión almacenada por cada par formado por su parte y nuestro registro, identificada por el id de nuestro registro (y el merged_entity cuando exista), de modo que la siguiente ejecución distinga las coincidencias nuevas de las ya conocidas.

Dos decisiones por alerta

• Resolución: ¿este registro corresponde a la misma parte que la suya? Confirmada, no es una coincidencia o abierta. Un cambio de nombre o de fecha de nacimiento de nuestro lado puede reabrirla.
• Relevancia: ¿la inclusión en la lista le importa? Se decide a partir de topics, list_type, programme y el registro. Un programa nuevo o un registro nuevo para una parte conocida puede volver relevante una coincidencia ya descartada.

Qué almacenar para cada coincidencia

La repetición de alertas depende de sus obligaciones

Una institución canadiense sujeta a la Special Economic Measures Act y a la Justice for Victims of Corrupt Foreign Officials Act se interesa primero por las inclusiones canadienses; una con exposición en Estados Unidos también se interesa por OFAC. Registre los registros y programas que aplican a cada línea de negocio y vuelva a alertar solo cuando un cambio los afecte. Los nombres de los registros provienen de datasets; filtre con include_dataset.

Cuándo volver a alertar sobre una parte conocida

• Puede haber cambiado la resolución: cambiaron los nombres, la fecha de nacimiento o la nacionalidad del registro, o la puntuación varió más que su tolerancia.
• Puede haber cambiado la relevancia: un topics nuevo, un programme nuevo o un registro nuevo en datasets o en la entidad fusionada.
• Ambas: la parte fue excluida de la lista (el registro ya no responde) o apareció un nuevo registro para ella.

Comprobar un registro almacenado requiere una sola GET /api/entity/<id>?nested=false.

Fusiones y divisiones

Cuando vinculamos registros de la misma parte, estos adquieren un ID de entidad fusionada común; cuando los desvinculamos, ese ID cambia. Ambas situaciones pueden hacer que una alerta antigua parezca nueva. Para manejarlo:

1. Identifique las decisiones por ID de registro, y no solo por ID fusionado.
2. Cuando un resultado nuevo comparta un ID fusionado con un registro que ya descartó, muestre la decisión anterior al revisor.
3. Cuando un registro almacenado responda 308, sígalo hasta la entidad fusionada y traslade su decisión tras la revisión.
4. Prevea que la puntuación varíe al vincularse registros: una vista fusionada puede incluir más nombres y fechas.
5. Vuelva a comprobar periódicamente los ID de registro almacenados; consulte Cómo mantener actualizados sus ID almacenados.

Cómo cambian los datos

Tres fuentes de cambio

• El publicador: un registro agrega, modifica o elimina entradas.
• Nuestro procesamiento: mejoramos la forma en que se lee un registro (tipos, fechas, países, programas), lo que modifica los registros sin que haya ningún cambio en la fuente.
• Vinculación: los registros se vinculan a una entidad fusionada o se desvinculan de ella.

El problema del ruido

Normalmente solo el primer tipo es noticia. El segundo y el tercero pueden afectar muchos registros a la vez. Antes de generar una alerta, compare los valores que importan para sus decisiones (nombres, fecha de nacimiento, nacionalidad, temas, programa, registro) y no el registro completo.

Cómo elegir un enfoque

Monitoreo con la API

Nueva verificación programada

1. Consulte /api/catalog y anote el version de cada colección.
2. Cuando cambie la versión, vuelva a enviar sus partes a /api/match/<collection> en lotes de 20, con los mismos filtros y el mismo umbral que antes.
3. Compare cada resultado con las decisiones que tiene almacenadas, aplicando las reglas anteriores.
4. Ponga en cola para revisión las coincidencias nuevas o modificadas y almacene el nuevo checked_at y la versión.

curl "https://api.crownintelligence.net/api/catalog"

import requests

BASE = "https://api.crownintelligence.net"
catalog = requests.get(f"{BASE}/api/catalog", timeout=30).json()
versions = {c["name"]: c["version"] for c in catalog["collections"]}
print(versions)  # store these; re-screen when a version changes

Menos ruido mediante el alcance

Envíe los mismos valores de topics, include_dataset y exclude_dataset en cada ejecución, de modo que un cambio en un registro que usted no utiliza nunca llegue a revisión. Para listar los registros recopilados por primera vez recientemente en una colección, use /api/search/<collection>?sort=first_seen con un filtro.

Nueva verificación solo de lo que cambió

Entre una verificación completa y otra, agregue changed_since a la solicitud de coincidencia. Los candidatos se limitan entonces a los registros recopilados por primera vez en esa fecha u hora, o después, o cuyo contenido publicado haya cambiado en una compilación masiva desde entonces. Una parte que no tiene ninguna coincidencia nueva devuelve una respuesta sin resultados, por lo que cada resultado es un registro nuevo o modificado que debe comparar con sus decisiones. Use la hora de su ejecución anterior, con la misma colección, los mismos filtros y el mismo umbral.

curl -X POST "https://api.crownintelligence.net/api/match/sanctions?changed_since=2026-09-20" \
  -H "Content-Type: application/json" \
  -d '{"queries":{"c-1042":{"schema":"Person","properties":{"name":["Vladimir Putin"],"birthDate":["1952-10-07"]}}}}'

• Formato. Una fecha u hora ISO 8601, por ejemplo 2026-10-01 o 2026-10-01T12:00:00Z. Una fecha sin hora se interpreta como medianoche UTC. Cualquier otro valor devuelve HTTP 400 con una explicación. El valor aplicado se devuelve en filters.changed_since.
• También en la búsqueda. /api/search?changed_since= lista los registros nuevos y modificados con los filtros habituales.
• No se informa de las eliminaciones. Un registro que se retira de su registro de origen simplemente deja de coincidir. Para conocer las eliminaciones, lea las líneas DEL de los archivos delta o realice una verificación completa.
• Mantenga las verificaciones completas. Los cambios se cuentan a partir de las compilaciones masivas y se tienen en cuenta hasta 20,000 registros modificados por solicitud (los registros recopilados por primera vez desde la fecha siempre se incluyen). Después de un intervalo largo, o de una compilación que modificó más registros que ese límite, realice una verificación completa.

Monitoreo con archivos delta

Flujo de procesamiento

El índice de compilación de cada colección, /downloads/collections/<collection>/index.json, lista los archivos de la compilación actual con sus sumas de verificación. A partir de la segunda compilación, delta.json lista lo que cambió desde la compilación anterior, con una operación por línea: ADD (registro nuevo), MOD (registro modificado) y DEL (registro eliminado). Aplíquelas en orden a su copia y luego vuelva a verificar las partes que podrían coincidir con los registros agregados y modificados. Consulte Archivos delta.

Menos ruido mediante la comparación

Para cada MOD, compare las versiones anterior y nueva de los valores de los que dependen sus decisiones e ignore el resto.

Realice una verificación completa de vez en cuando

Los deltas siguen nuestros datos, no su cartera: un cambio en los datos de su cliente, o una compilación omitida, no aparece en ellos. Vuelva a verificar todo periódicamente y cada vez que cambie los umbrales o los filtros.

Ayuda

Preguntas sobre cómo crear un flujo de monitoreo: [email protected] o Obtener soporte.

Última actualización 2026-10-03