Una integración de API de KYT llama al endpoint de screening en cada depósito y cada retirada, interpreta la puntuación de riesgo devuelta y enruta la transacción antes de que se muevan los fondos. El screening por lotes y la monitorización continua se superponen encima para cubrir el histórico y la deriva de las direcciones. La API va dentro del flujo de transacciones y no al lado, porque las comprobaciones en tiempo real detectan la actividad de riesgo antes de la liquidación mientras los trabajos por lotes y la monitorización cubren todo lo demás. Esta guía recorre los tres modos para un exchange de cripto. Para el flujo de trabajo completo, consulta Phalcon Compliance. Esta página pertenece al Centro de cumplimiento AML.
Por qué los exchanges necesitan screening en tiempo real a nivel de API
La cadencia de screening que elige un exchange es también la ventana de blanqueo que acepta. Un trabajo por lotes semanal o diario analiza todas las direcciones en el momento en que se ejecuta, pero cada depósito que llega entre lotes entra en el monedero sin cuestionarse. Los fondos pueden aterrizar, moverse y salir a efectivo dentro de ese hueco. El screening en tiempo real a nivel de API cierra el hueco porque cada depósito y cada retirada se comprueban antes de liberar la transacción.
El motivo no es solo operativo. FinCEN exige a las empresas de servicios monetarios, exchanges de cripto incluidos, mantener un programa AML (31 CFR 1022.210) y comunicar las transacciones sospechosas (31 CFR 1022.320), leídos junto con su guía de 2019 sobre moneda virtual (FIN-2019-G001). En la práctica, esa combinación es lo que hace necesaria la monitorización continua, y no un umbral fijo de tiempo real. El enfoque basado en el riesgo del GAFI para proveedores de servicios de activos virtuales converge en la misma exigencia, al obligar a los VASP a vigilar las transacciones de forma continua y no como una comprobación única en el alta. Un exchange satisface ambas manteniendo un control vivo sobre cada depósito y cada retirada, que es exactamente lo que da el modo de API en tiempo real descrito abajo. Una cadencia solo por lotes deja una distancia detectable entre el deber de vigilar y el control que realmente se ejecuta. Los supervisores leen esa distancia como una carencia del programa, no como una preferencia de despliegue.
El lado de desarrollo es una restricción en sí mismo. Ninguna combinación de herramientas de terceros encaja en el caso de uso de un exchange hasta que esas herramientas acceden de verdad a los sistemas internos, así que la batalla infravalorada es la integración y no el número de funcionalidades. Un motor de screening que no puede hablar con el flujo de depósitos, el de retiradas y la ruta de enrutado de alertas no cambia lo que el exchange puede detectar: solo cambia un panel. El trabajo de integración es lo que convierte una capacidad de screening en un programa de screening.
Preparación previa: umbrales de riesgo, enrutado de alertas y acceso a los sistemas
Antes de escribir ninguna llamada a la API hay que fijar tres decisiones. Gobiernan lo que hará de verdad la integración una vez en marcha, y cambiarlas después del despliegue implica rehacer tanto el cliente de la API como la ruta de alertas aguas abajo. Estas tres decisiones viven dentro del programa de cumplimiento AML de un exchange de cripto más amplio, que cubre la evaluación de riesgo, el screening, el triaje y los registros auditables. Esta página se centra en la capa de integración por API de ese programa y no en la estructura del programa en sí.
La primera decisión es el conjunto de reglas de umbral de riesgo. Una API de KYT devuelve una puntuación de riesgo, pero la puntuación no hace nada hasta que el exchange decide qué bandas de puntuación disparan qué acción. Una forma habitual son tres bandas: riesgo bajo libera la transacción automáticamente, riesgo medio la retiene para revisión manual y riesgo alto la bloquea y abre una alerta. Los umbrales hay que definirlos como código, no como política, porque el cliente de la API va a enrutar sobre ellos de forma programática.
La segunda decisión es el enrutado de alertas. Cuando una puntuación de riesgo cruza un umbral, la alerta tiene que llegar a una persona o a una cola. El diseño del enrutado cubre qué canal lleva la alerta, ya sea un webhook hacia un canal de Slack o Telegram, un ticket en una herramienta de gestión de casos o una entrada en una cola interna. La plataforma admite notificaciones multicanal, webhook incluido, y el enrutado hay que mapearlo antes de poner la integración en producción, no añadirlo después de la primera alerta perdida.
La tercera decisión son las restricciones por plan. El acceso a la API solo está disponible en el nivel Scale, desde 699 dólares al mes, y en el nivel Enterprise; los niveles Free, Screening Packages y Essential no incluyen acceso por API. Un equipo que quiera incrustar el screening dentro de su propio flujo de depósitos o retiradas necesita llegar antes al nivel Scale. Confirmarlo antes de empezar la integración evita la situación de escribir el código contra un plan que el equipo no puede usar. La colaboración en equipo con varios asientos, si la función de cumplimiento necesita más de un asiento trabajando dentro de la herramienta, solo está en Enterprise. Cómo encaja esa restricción en el programa más amplio de cumplimiento AML en cripto se expone en la página del centro.
Integrar la API de KYT y KYA de Phalcon Compliance: tres modos
La API de Phalcon Compliance admite comprobaciones en tiempo real, screening por lotes CSV asíncrono y monitorización continua. Las comprobaciones en tiempo real cubren depósitos y retiradas. El screening por lotes cubre direcciones históricas y pendientes. Monitor vigila los cambios de riesgo en direcciones ya analizadas. Un exchange puede combinar los tres modos según dónde y cuándo necesite el screening.
El flujo de depósitos y retiradas de un exchange tiene tres necesidades de screening que no se reducen a una. Una transacción en vivo necesita respuesta antes de liberarse, lo que significa una llamada síncrona y de baja latencia. Un histórico pendiente de direcciones hay que analizarlo en bloque sin bloquear el flujo en vivo, lo que significa un trabajo asíncrono. Y una dirección que estaba limpia en el primer screening puede operar más tarde con una contraparte de riesgo, lo que significa una vigilancia continua sobre direcciones ya analizadas en lugar de un veredicto único.
Phalcon Compliance expone su API de screening en tres modos que se corresponden con esas tres necesidades. Un modo de comprobación única en tiempo real cubre la puerta de depósitos y retiradas. Un modo de lotes CSV asíncrono cubre el histórico pendiente. Un modo Monitor continuo vuelve a analizar las direcciones ya analizadas con una periodicidad dinámica. Los tres modos comparten una única superficie autenticada, así que una sola clave de API gobierna el acceso a todos ellos, y el exchange elige el modo en cada llamada en lugar de mantener integraciones separadas.
| Modo | Disparador | Latencia | Cuota y límite de tasa | Caso de uso |
|---|---|---|---|---|
| Comprobación única en tiempo real | Una dirección o transacción | Del orden de milisegundos | 50 llamadas por minuto y clave de API | Screening en vivo de depósitos y retiradas |
| Lotes CSV asíncronos | Subida de un CSV | Asíncrona | CSV de direcciones hasta 100 por archivo; CSV de transacciones hasta 400 por lote | Histórico y pendientes |
| Monitor | Continuo | Periodicidad dinámica | No consume cuota de screening | Nuevo análisis de direcciones ya analizadas al cambiar su riesgo |
La secuencia de integración es la misma en los tres modos. El cliente se autentica con la clave de API emitida por la plataforma. Llama al endpoint de screening con la dirección o el identificador de la transacción. Interpreta la puntuación de riesgo devuelta, incluidos los indicadores de riesgo y las cifras de exposición que la acompañan. Enruta según las reglas de umbral definidas en la preparación previa. Y emite la alerta por el webhook o el canal de notificación configurado cuando se cruza un umbral. La API de screening está limitada a 50 llamadas por minuto y clave de API, y las llamadas que superan ese límite reciben un HTTP 429, así que el cliente tiene que manejar el 429 con reintentos escalonados en lugar de reintentar como si fuera un error cualquiera.
BlockSec especifica la latencia de la comprobación única en tiempo real como del orden de milisegundos. Trátalo como una cifra a confirmar con el tráfico propio: construye la integración para tolerar latencia en lugar de dar por supuesto un objetivo concreto en milisegundos, y mide cualquier acuerdo de nivel de servicio interno que fije el exchange contra tráfico de producción.
Límites de tasa, cuotas y restricciones por plan: notas de ingeniería
El límite de tasa es la primera restricción de ingeniería con la que se topa la integración. La API de screening está limitada a 50 llamadas por minuto y clave de API, y las llamadas que superan ese límite reciben un HTTP 429. Para un flujo de depósitos en vivo eso rara vez es una restricción efectiva, porque los depósitos llegan de uno en uno y una comprobación en tiempo real termina antes de la llamada siguiente. Para una operación en bloque sí lo es, porque analizar de forma síncrona un histórico de miles de direcciones agotaría el límite en minutos. El modo de lotes CSV existe precisamente para sacar esa carga de la ruta síncrona. El screening de direcciones por CSV acepta hasta 100 direcciones por archivo, y el de transacciones hasta 400 por lote. Un histórico pendiente se procesa así de forma asíncrona, sin competir con la puerta en vivo por el presupuesto del límite de tasa.
El modelo de cuota es la segunda restricción. Los screenings consumen un saldo, y el consumo ocurre en un orden definido: primero se reinicia la cuota de la suscripción en cada ciclo, después se consumen los screenings recargados, luego las recompensas por referidos y por último los Screening Packages. La integración no necesita elegir qué saldo usar. El equipo de cumplimiento que gestiona el presupuesto sí necesita entender el orden, porque determina qué saldo se agota primero y cuándo hace falta una recarga. El modo Monitor es la excepción: se ejecuta con una periodicidad dinámica y vuelve a analizar las direcciones ya analizadas cuando cambia su riesgo, y no consume cuota de screening, así que dejar Monitor encendido no grava el presupuesto por comprobación.
Las restricciones por plan son la tercera y no son negociables. Como se ha visto arriba, el acceso a la API exige el nivel Scale, desde 699 dólares al mes, o el nivel Enterprise; los niveles Free, Screening Packages y Essential no incluyen acceso por API. Más allá de esa puerta, dos capacidades adicionales delimitan el alcance: el acceso a webhook aterriza en Scale o Enterprise, mientras que la configuración de motores de riesgo personalizados está disponible desde el nivel Screening Packages hacia arriba (3 motores en Screening Packages, 10 en Essential, 20 en Scale, ilimitados en Enterprise), y la colaboración con varios asientos dentro de la herramienta es una función de Enterprise. El detalle de precios detrás de esos niveles se trata en el artículo dedicado a precios; esta página solo cubre las restricciones que afectan a cómo se planifica la integración por API.
Consulta la documentación de la API de Phalcon Compliance
Una integración de API de KYT no está terminada cuando la primera llamada devuelve una puntuación. Está terminada cuando la puerta en vivo, la vía del histórico pendiente y la vigilancia de Monitor están las tres cableadas en el flujo de depósitos y retiradas del exchange. Los umbrales se definen como código, las alertas se enrutan a una cola real y las restricciones por plan se confirman antes de la primera llamada. Consulta la documentación de la API de Phalcon Compliance para la referencia de endpoints, el contrato del webhook y la vía de prueba del nivel Scale.