Cuando el screening manual deja de funcionar
El screening manual falla por tres motivos, y llegan juntos. El volumen crece hasta que copiar y pegar ya no da abasto. La cola de revisión se atasca y los retiros se ralentizan mientras los usuarios esperan. Y una vez cerrada una comprobación, nadie sigue vigilando esa dirección, así que un cambio de riesgo tres semanas después pasa inadvertido. La automatización resuelve los tres a la vez.
La primera presión es el simple recuento. Los depósitos y las solicitudes de retiro llegan en lotes, y una persona que los revisa uno a uno se convierte en la parte más lenta del proceso. La segunda presión es la propia cola. Cada minuto que una dirección espera revisión es un minuto que un usuario espera su dinero, y el cumplimiento normativo empieza a percibirse como el enemigo del producto. La tercera presión es el tiempo. Una comprobación manual termina cuando termina; nada en ella sigue ejecutándose.
El Grupo de Acción Financiera Internacional espera un seguimiento continuo como parte de un enfoque basado en el riesgo, no solo una comprobación en la puerta. Y las listas de sanciones cambian a su propio ritmo, como muestra claramente la página de acciones recientes de la OFAC: una dirección puede entrar en una lista cualquier mañana, esté alguien mirando o no. Esos dos hechos son el argumento central para integrar el screening en tus sistemas en lugar de dejarlo en una pestaña del navegador.
Lo que cambia la automatización es dónde vive la comprobación. Una comprobación dentro del proceso se ejecuta tanto si alguien se acuerda de ella como si no, aplica el mismo criterio a la dirección número diez mil que a la primera y deja constancia de lo que vio sin que nadie se lo pida. Esa última parte, el registro, es lo que convierte una auditoría de un proyecto en una consulta.
| Aspecto | Screening manual | Proceso automatizado |
|---|---|---|
| Dónde vive la comprobación | Una pestaña del navegador que alguien se acuerda de abrir | Dentro de tu flujo de depósitos y retiros |
| Coherencia con volumen | Depende de la persona y de la hora | El mismo criterio en cada dirección |
| Vigilancia tras la aprobación | Termina cuando se cierra la comprobación | Los webhooks envían los cambios de nivel de riesgo |
| Registros | Se reconstruyen cuando lo pide una auditoría | Los escribe el proceso mientras se ejecuta |
Las señales de que ha llegado el momento de cambiar son sencillas. Comprobaciones diarias que no podrías saltarte ni un día, auditorías que piden registros de cada decisión y una obligación de seguimiento que tu equipo solo cumple en espíritu.
Screening por lotes a través de la API
La API convierte las comprobaciones puntuales en un paso del proceso. Las solicitudes van a la dirección base https://api.blocksec.com con el prefijo de ruta /phalcon/compliance/v2/, autenticadas con una clave de API generada en System, luego API, luego Generate Key. Las solicitudes de screening tienen un límite de 50 por minuto por clave, el resto de llamadas de 10 por segundo, y el éxito se indica con code=0.
Cuatro endpoints de screening soportan la carga: /address/screen para una sola dirección, /addresses/screen para lotes, /transaction/screen para una transacción y /transactions/screen para lotes de transacciones. Las formas individual y por lotes permiten que tu proceso llame a la misma herramienta tanto para el caso manual puntual como para el trabajo nocturno de diez mil elementos.
En torno a los endpoints se aplican las buenas prácticas habituales. Trata el límite de solicitudes como un dato de diseño y no como una sorpresa: pon tus lotes en cola, reduce el ritmo cuando alcances el techo y mantén una vía de reintento para las llamadas que fallen. Haz el screening en el momento de la decisión, depósito o retiro, y guarda el resultado junto con la transacción a la que pertenece, para que ambos nunca se desincronicen.
Las claves se gestionan por proyecto. Los detalles completos de solicitudes y respuestas, campo por campo, están en la documentación oficial de la API, y esta página se mantiene a nivel de flujo de trabajo en lugar de repetirlos.
Un dato de planificación tiene cabida aquí porque afecta a tu calendario: la API está disponible en los planes Scale y Enterprise, no en todos los planes. Si tu despliegue da por hecho el acceso a la API, confirma primero el plan. Es un requisito real, no una formalidad, y es mejor toparse con él en la primera semana que en la sexta.
Deja que los webhooks vigilen los cambios
Los webhooks son la forma en que funciona la mitad de vigilancia. Registras un endpoint y el servicio le envía dos tipos de mensajes: mensajes notification de tipo 1, que contienen alertas del motor de riesgo, y mensajes monitorEvent de tipo 2, que contienen eventos de Monitor. Estos últimos son los que te dicen que un monedero que ya aprobaste ha cambiado.
Los eventos que más importan a un flujo de trabajo de cumplimiento son los cambios de nivel de riesgo: Risk Level Increased y Risk Level Decreased. Cada uno incluye prevLevel y newLevel para que tu sistema vea el salto, además del Risk Timeline de la dirección. Un monedero que pasó el screening limpio en el alta y más tarde toca fondos sancionados produce exactamente este evento, que es la respuesta desde el lado de la máquina a la pregunta que los usuarios no dejan de hacer: ¿puede un monedero limpio volverse de riesgo? Sí, y esto es lo que se ve cuando ocurre.
Hay un nombre de campo que merece una advertencia, porque parece una errata y no lo es: targetIdentifiter aparece en los payloads oficiales exactamente con esa grafía. Cópialo tal como figura en la documentación, con la letra cambiada incluida, o tu integración fallará de una forma que te hará perder una tarde en encontrarla.
La entrega no se detiene en tu servidor. Las mismas alertas se distribuyen por 7 canales de notificación, entre ellos Telegram, correo electrónico y Lark. La persona que tiene que actuar puede recibirlas donde ya está, en lugar de en un panel que nadie mira a las 2 de la madrugada.
Asigna responsables junto con los canales. Una alerta que llega a todos es una alerta de la que nadie es responsable. Cada canal debe corresponder a una persona o a un turno, con una norma escrita sobre la rapidez con la que debe atenderse un cambio de nivel de riesgo y cuál es la primera respuesta.
Lo que aporta la automatización
Una vez que el screening se ejecuta dentro del proceso, tres cosas encajan en su sitio. Cada depósito se comprueba antes de aceptarse, así que las decisiones se basan en evidencias. Cada monedero aprobado sigue vigilado, así que los cambios de riesgo salen a la luz por sí solos. Y cada comprobación deja un registro, así que las auditorías se convierten en una recuperación y no en una reconstrucción.
La capacidad está pensada para este tipo de trabajo: respuestas de screening en menos de 100 milisegundos y más de 200 señales de riesgo que alimentan la puntuación (según BlockSec). Los precios empiezan con un nivel gratuito, y después paquetes de créditos según los necesites o una suscripción mensual a medida que crece el trabajo.
El límite honesto es que la automatización amplía la cobertura y la acelera; no hace desaparecer el riesgo. Una política equivocada, rápida y bien registrada sigue siendo una política equivocada. Los límites de solicitudes y el requisito de plan mencionados antes en esta página son los márgenes prácticos. Trabaja dentro de ellos, escala cuando los alcances y revisa la propia política de forma periódica, no solo cuando algo se rompe.
Para la capa conceptual que hay debajo de todo esto, qué son realmente las etiquetas y las señales y cómo se construye una puntuación, lee ¿Qué es el screening de direcciones en el cumplimiento cripto?. El mapa de todo el tema, desde la primera comprobación hasta el seguimiento y los registros, está en el hub de screening de monederos.