API de KYT en tiempo real para el screening previo a la transacción

Una API de KYT en tiempo real responde a una pregunta en el único momento en que todavía puede cambiar el desenlace: antes de liberar la transacción. Las transferencias on-chain son irreversibles, así que una vez difundido un depósito o una retirada, lo único que queda es investigar y reportar. El screening previo a la transacción adelanta la decisión a la ventana en la que una contraparte de alto riesgo aún se puede bloquear o retener. Esta guía se queda dentro de esa ventana previa: por qué importa, el requisito de latencia, cómo devuelve la API una decisión, la resolución de bloquear/retener/permitir, cuándo usar tiempo real frente a lotes frente a Monitor, y una lista de comprobación de integración. Para la superficie completa de KYT, consulta Phalcon Compliance. Esta página pertenece al Centro de recursos de KYT.

Por qué importa el screening previo a la transacción

La irreversibilidad de las transferencias on-chain es la razón estructural de que exista el screening previo. Una transferencia bancaria se puede revertir, revocar o bloquear a través de la banca corresponsal. Una transferencia blockchain, no. Una vez confirmada, los fondos son del receptor, y el único recurso es la investigación posterior, los requerimientos policiales o la presentación de un STR. Para entonces los fondos se han movido de nuevo a menudo. Un control que solo se ejecuta después de que la transacción se liquide es, de hecho, un control que se ejecuta después del daño.

La monitorización posterior a la transacción no puede sustituir a una comprobación previa. El enfoque basado en el riesgo del GAFI para los proveedores de servicios de activos virtuales obliga a los VASP a vigilar las transacciones de forma continua y sensible al riesgo, no como una comprobación única en el alta. FinCEN plantea las obligaciones de vigilancia AML continuada bajo su norma de programa AML para empresas de servicios monetarios (31 CFR 1022.210) en la misma dirección para los exchanges de cripto y otras empresas de servicios monetarios estadounidenses. Ninguno de los dos marcos fija una cifra dura de latencia, pero los dos esperan que el control se ejecute de verdad sobre la transacción que gobierna. Un programa que detecta el riesgo solo después de que los fondos se hayan movido tiene un hueco que los supervisores leen como una debilidad del programa, no como una preferencia de despliegue.

La economía favorece la decisión temprana. Bloquear un depósito de alto riesgo en la puerta cuesta una llamada de API. Perseguir ese mismo depósito por tres saltos a través de servicios de mezcla cuesta días de análisis, y la recuperación es rara. El screening previo a la transacción es la diferencia entre un control que previene y uno que informa.

Cuán rápido tiene que responder una llamada de screening

El screening previo está acotado por la experiencia de usuario, no por la capacidad del proveedor. Una retirada que se queda parada dos segundos mientras corre un screening parece rota. Un depósito retenido diez segundos mientras alguien lo revisa parece congelado. El presupuesto de latencia para una decisión previa es, por tanto, ajustado: se mide en centenares de milisegundos, no en segundos. Un techo de trabajo habitual son unos 500 milisegundos de extremo a extremo, desde que la transacción llega a la puerta hasta que se devuelve la decisión de permitir, retener o bloquear. Por debajo de ese techo, el screening es invisible para el usuario. Por encima, empieza a parecer fricción, y la fricción empuja a los usuarios a esquivar el control.

El objetivo ideal es más bajo. Una respuesta por debajo de 100 milisegundos, de la API en sí, deja margen para que corra el resto de la puerta. El viaje de ida y vuelta por la red, el enrutado interno, el registro y la decisión de umbral consumen presupuesto por encima de la llamada cruda. Si solo la API se come 300 milisegundos, al resto de la pila no le queda nada. La latencia no es una funcionalidad de una hoja de especificaciones: es la diferencia entre un control que corre al mismo paso que la transacción y uno que compite con ella.

BlockSec especifica una latencia del orden de milisegundos para su API de screening en tiempo real. Trátalo como un objetivo a confirmar contra tráfico de producción antes de construir encima un acuerdo de nivel de servicio interno. Una puerta que presupone 50 milisegundos y en realidad ve 400 se degradará antes de que salte la primera alerta. La puerta tiene que medir la cifra real y degradarse con elegancia cuando no se cumpla.

Cómo funciona una API de screening KYT en tiempo real

Una API de screening KYT en tiempo real se sitúa en la ruta de decisión de la transacción, no al lado. El flujo tiene cuatro pasos que deben completarse dentro del presupuesto de latencia. El cliente se autentica y envía la dirección o el identificador de la transacción. La API resuelve la dirección contra sus datos de riesgo y devuelve una puntuación de riesgo con las evidencias que hay detrás. La puerta del cliente traduce entonces la puntuación a una resolución —bloquear, retener o permitir— usando umbrales definidos como código, y libera o intercepta la transacción. La llamada es síncrona y de una sola dirección, porque la decisión tiene que volver antes de liberar la transacción.

Phalcon Compliance expone su API de screening en tiempo real exactamente con esa forma. Una única clave de API gobierna el acceso. La llamada devuelve una puntuación de riesgo, las cifras de exposición que hay detrás y los indicadores de riesgo que la motivaron. Los datos de riesgo se construyen sobre más de 600 millones de direcciones etiquetadas y más de 17 categorías de indicadores de riesgo, que cubren patrones de comportamiento, exposición a servicios ilícitos conocidos y riesgo de contraparte. La puntuación es sobre lo que enruta la puerta. Los indicadores y las cifras de exposición son lo que lee quien analiza si la transacción se retiene para revisión, y son lo que hace la decisión auditable en lugar de opaca.

Dos restricciones condicionan cómo se usa la API. La primera: el acceso está reservado al nivel Scale, desde 699 dólares al mes, y al nivel Enterprise. Los niveles Free, Screening Packages y Essential son para screening interactivo a través de la interfaz de la plataforma, no para incrustarlo dentro de una puerta de transacciones. Un equipo que monte un screening previo tiene que estar en Scale o Enterprise antes de escribir la primera llamada. La segunda: la cifra de latencia —una respuesta del orden de milisegundos para la API en tiempo real— es lo que determina si la API puede servir a una puerta previa o tiene que replegarse a una monitorización posterior. Confirmar la cifra real bajo la carga propia forma parte de la puesta en producción, no es un trámite posterior.

Bloquear, retener o permitir: decide antes de que se muevan los fondos

Un screening en tiempo real solo es útil si la puerta sabe qué hacer con la respuesta. El marco que encaja con el screening previo es una resolución por capas en tres bandas, no un binario permitir-o-marcar. Las bandas las define la puntuación de riesgo, y cada una lleva una acción concreta que la puerta ejecuta sin esperar a una persona.

La primera banda es permitir. Las direcciones de riesgo bajo pasan automáticamente, sin cola, dentro del presupuesto de latencia, y esta banda tiene que ser la mayor parte del volumen. La segunda banda es retener. Las direcciones de riesgo medio ni pasan ni se bloquean: la transacción se pausa, se enruta una alerta a una cola de revisión y alguien decide la resolución con los indicadores de riesgo y las cifras de exposición delante. Retener recoge los casos en que la puntuación es ambigua y el juicio humano compensa la demora. La tercera banda es bloquear. Las direcciones de riesgo alto se interceptan antes de liberarse, la transacción no se difunde y se abre una alerta con el rastro completo de evidencias. Bloquear es la banda que hace el trabajo de prevención que la monitorización posterior no puede hacer.

La fuerza de este marco está en la cadena de auditoría, no solo en la decisión. Cada resolución tiene que poder reproducirse: qué puntuación se devolvió, en qué banda cayó, qué indicadores la motivaron y qué acción tomó la puerta. Un bloqueo tiene que ser justificable como decisión basada en evidencias, no como una heurística. Una retención tiene que ser auditable como una pausa que de verdad se revisó y se resolvió, no como una transacción descartada sin ruido. Los indicadores de riesgo y las cifras de exposición son lo que completa la cadena. Sin ellos, la resolución es un veredicto. Con ellos, es una decisión documentada que un supervisor o un auditor pueden leer.

Tiempo real, lotes y Monitor: cuándo usar cada uno

El screening previo no es el único modo de screening, y confundir los modos es un patrón de fallo habitual. Una API de KYT en tiempo real funciona en tres modos, cada uno respondiendo a una pregunta distinta. La comprobación única en tiempo real responde «¿se puede liberar esta transacción ahora sin peligro?». El screening por lotes responde «¿cuál es el perfil de riesgo de este histórico pendiente?». Monitor responde «¿ha cambiado el riesgo de una dirección que ya analizamos desde la última vez que miramos?». Los tres modos no se reducen a uno, y usar el equivocado o bien quema cuota o bien se pierde riesgo.

La comprobación única en tiempo real es el modo previo a la transacción: es síncrona, de baja latencia, y se ejecuta una vez por transacción en la puerta. El screening por lotes es asíncrono, se ejecuta sobre subidas de CSV contra históricos pendientes y no corre dentro de la ruta de la transacción. Monitor es continuo: reanaliza las direcciones ya analizadas con una periodicidad dinámica y salta cuando cambia el riesgo de una dirección antes limpia, por ejemplo cuando una contraparte resulta sancionada más adelante.

El reparto práctico: el tiempo real se ocupa de la puerta en vivo, los lotes del histórico pendiente y Monitor de la deriva. Un programa que solo ejecuta tiempo real está ciego ante el riesgo que emerge después del primer screening. Uno que solo ejecuta Monitor no tiene decisión previa a la transacción. Uno que solo ejecuta lotes no tiene ninguna de las dos. El montaje sólido usa los tres, cada uno en su carril. Monitor, notablemente, no consume cuota de screening, así que dejarlo encendido no grava el presupuesto por comprobación del que beben el tiempo real y los lotes. Esta página se queda en el carril del tiempo real; cablear los tres en el flujo de un exchange es un tema de integración aparte.

Lista de comprobación de integración del screening previo

Una puerta de screening previo está terminada cuando puede responder, para cualquier transacción, qué resolución tomó, por qué y cuánto tardó la decisión. La lista de abajo es la vista de tiempo real, centrada en la puerta en sí.

1. Confirma el nivel de la API. El acceso a la API en tiempo real exige el nivel Scale, desde 699 dólares al mes, o Enterprise. Confírmalo antes de escribir la primera llamada.

2. Fija el presupuesto de latencia en código. Define el techo para toda la ruta de screening —habitualmente en torno a 500 milisegundos— y mide el viaje de ida y vuelta real sobre tráfico de producción. Trata la respuesta del orden de milisegundos publicada como un objetivo a confirmar, no como una suposición.

3. Define las bandas de umbral como código. Bloquear, retener y permitir tienen que ser programáticos, enrutando según la puntuación de riesgo devuelta. Una política que vive en un documento pero no en la puerta no se ejecuta sobre la transacción.

4. Cablea la vía de alertas antes de arrancar. Las retenciones y los bloqueos tienen que llegar a una cola real: un webhook, un ticket o un canal interno. Un enrutado añadido después de la primera alerta perdida ya es un fallo.

5. Persiste las evidencias con cada resolución. La puntuación, la banda de umbral, los indicadores de riesgo y las cifras de exposición tienen que guardarse junto al registro de la transacción. La resolución tiene que poder reproducirse meses después.

6. Construye la vía de degradación. Si la API supera el presupuesto de latencia o da error, la puerta tiene que fallar en una dirección definida —retener para revisión, o permitir con una marca para la monitorización posterior—, no descartar la transacción sin ruido.

7. Gestiona los límites de tasa. La API de screening está limitada por clave, y las llamadas que superan el límite devuelven un HTTP 429. El cliente tiene que aplicar reintentos escalonados, no reintentar como si fuera un error cualquiera.

8. Enciende Monitor para la deriva. El screening previo atrapa el riesgo en la puerta. Monitor atrapa el riesgo que emerge después. Monitor no consume cuota de screening, así que puede quedarse encendido sin gravar el presupuesto del tiempo real.

Una puerta que supera esta lista ejecuta la decisión previa dentro de la ruta de la transacción, con umbrales que saltan, alertas que llegan a una persona, evidencias que persisten y una vía de degradación que falla del lado seguro. Eso es lo que significa en la práctica el screening previo a la transacción en tiempo real. Consulta la documentación de la API de KYT de Phalcon Compliance para la referencia de endpoints, la vía de entrada por el nivel Scale y el esquema completo de indicadores de riesgo.