AML y KYT: cumplimiento sobre la cadena

Un cliente con la verificación de identidad completa deposita 12 000 USDT. La transacción es válida y la red ya la confirmó. Pero la dirección de origen recibió fondos, dos saltos antes, de un servicio que una lista de sanciones identifica como ilícito. ¿Acreditamos el saldo? ¿Lo retenemos? ¿Quién decide y en cuánto tiempo?

La cadena no responde a esas preguntas: una transacción válida para el protocolo puede ser inaceptable para la organización. Este capítulo construye el flujo que sí las responde, sobre las bases de Web3 para el equipo y el gobierno de aprobaciones de custodia.

KYC y KYT: identificar al cliente no basta

AML (anti-money laundering, prevención del lavado de dinero) es el conjunto de obligaciones y controles para no facilitar el movimiento de fondos ilícitos. En activos digitales se apoya en dos controles distintos que se confunden a menudo.

KYC (know your customer, conoce a tu cliente) verifica la identidad de la persona o empresa antes de darle servicio. Responde a la pregunta "¿quién es?". BitGo, por ejemplo, ofrece una API de KYC para que las plataformas que usan su servicio verifiquen a sus usuarios finales antes de que operen. [1] Tether, como emisor, exige verificación y debida diligencia a quienes emiten o rescatan directamente con él. [2]

KYT (know your transaction, conoce tu transacción) vigila los movimientos y las direcciones con las que interactúa ese cliente. Responde a "¿de dónde viene y a dónde va este dinero?". Fireblocks describe su AML/KYT como un screening de transacciones contra los datos de riesgo de un proveedor, que incluyen sanciones, mercados de la darknet, fondos robados y ransomware; el proveedor devuelve una evaluación y la política de la organización decide qué hacer. [3]

El escenario del depósito de 12 000 USDT muestra por qué hacen falta los dos. El KYC dice que el cliente es legítimo. El KYT dice que esos fondos concretos tienen exposición a una actividad sancionada. Ninguno de los dos, por separado, permite decidir.

Screening antes y después: retiros y depósitos no se tratan igual

El screening es la consulta que compara una dirección o una transacción con datos de riesgo. La diferencia clave es el momento. En un retiro todavía no se ha firmado nada, así que el screening puede impedir la salida. En un depósito los fondos ya llegaron a nuestra dirección, así que el screening solo puede decidir si los acreditamos o los retenemos.

Figura 1

Screening de retiros y depósitos con cola de alertas

Fuentes:

[4]

Cómo leer esta figura

Dos franjas. Franja superior, retiro: Solicitud de un cliente con KYC y destino; Screening de la dirección de destino y del monto; Decisión por puntuación de riesgo. Desde la decisión, una flecha verde aceptar lleva a Aprobación y firma, que remite al módulo 5, y de ahí a la Red. Una flecha roja hacia arriba indica rechazar: no se firma. Franja inferior, depósito: Llega a la dirección, primera confirmación; Screening de la dirección de origen y su exposición; Decisión por puntuación de riesgo. Una flecha verde aceptar lleva a Acreditar saldo disponible tras finalidad. Una flecha roja hacia abajo indica congelar: fondos retenidos. A la derecha, una caja alta Cola de alertas con analista asignado, plazo por severidad y decisión registrada; recibe una flecha ocre desde la decisión del retiro, alertar: sigue con revisión, y otra desde la decisión del depósito, alertar: se acredita y se revisa.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Fireblocks documenta exactamente este orden. En una transacción de salida, el screening empieza justo después de enviarla y antes de la aprobación por políticas y la firma; un rechazo hace que nunca se envíe. En una de entrada, el screening empieza en la primera confirmación en la cadena, y el resultado puede congelar los fondos. [4]

Que el depósito se evalúe en la primera confirmación no significa que deba acreditarse entonces. La acreditación sigue esperando la finalidad que fijamos por red en el módulo 1, y los datos del depósito deben sobrevivir a una reorganización, como explica indexadores, eventos y reorgs. El screening y la finalidad son dos compuertas distintas en el mismo camino.

Rutas que no se evalúan. Fireblocks indica que su AML/KYT no evalúa ciertas rutas internas, como de cuenta de bóveda a cuenta de bóveda o hacia y desde Gas Station, y que solo cubre transacciones dentro del workspace. [4] Para la política de temperaturas del módulo 4, eso significa que los barridos entre hot, warm y cold no pasan por el screening; el control relevante es el screening del depósito original.

Qué pasa si el proveedor no responde. Es la decisión que más se olvida. En Fireblocks, el valor por defecto de bypassScreeningDuringServiceOutages es verdadero: si falta el resultado, la transacción de salida se envía y la de entrada se libera. Con falso, la de salida no se envía y la de entrada queda congelada. [5] Es una decisión de riesgo, no de configuración, y debe tomarla cumplimiento por escrito.

Puntuación de riesgo y umbrales: de un número a una acción

Una puntuación de riesgo es el resultado que devuelve el proveedor de análisis de cadena: una categoría (bajo, medio, alto, severo) o un número. Por sí sola no decide nada. La política convierte ese resultado en una de pocas acciones posibles.

Los proveedores no devuelven lo mismo. Fireblocks lista proveedores que devuelven un nivel categórico más la categoría de riesgo detectada, y otros que devuelven una puntuación numérica, con un solo proveedor por workspace. [3] Si el equipo cambia de proveedor, la tabla de umbrales hay que reescribirla.

En Fireblocks, cada política tiene dos partes formadas por reglas si-entonces que se evalúan de arriba abajo. El disparador decide qué transacciones se evalúan; el resultado decide qué hacer con lo que devuelve el proveedor: aceptar, rechazar o alertar, y en algunos casos esperar o congelar. El ejemplo de la propia documentación es una regla que evalúa retiros en ETH por encima de 10 000 USD y otra que rechaza los de riesgo alto. [5]

Con varios destinos en una misma transacción, gana el resultado más restrictivo: congelar antes que rechazar, rechazar antes que alertar, alertar antes que aceptar. [5] Es un buen principio general para la política propia, aunque el proveedor no lo aplique.

Circle ofrece el mismo patrón en su Compliance Engine: reglas propias, listas de bloqueo y de permitidos, y alertas que pueden bloquear una transacción, congelar una wallet o enviarla a revisión manual. El screening puede ir embebido en el flujo de sus wallets o invocarse de forma independiente sobre una dirección. [6]

Los emisores de stablecoins añaden una capa que no controlamos. Circle deniega las transacciones de sus wallets que involucran direcciones de la lista de sanciones de OFAC y restringe temporalmente la salida de la wallet afectada. [7] Tether declara que puede inmovilizar y destruir tokens a distancia ante requerimientos de autoridades. [2] Recibir fondos de una dirección señalada puede dejar nuestro saldo atrapado, y por eso el screening de depósitos importa aunque nuestra jurisdicción no lo exija.

Flujo de alertas: quién atiende, en qué plazo y con qué evidencia

Una alerta es una transacción que la política no aceptó ni rechazó: la dejó pasar con aviso o la retuvo para revisión. La decisión del módulo es quién la atiende y en qué plazo, porque una alerta sin dueño es un depósito congelado sin fecha o un retiro aprobado sin que nadie lo mire.

La documentación de los proveedores fija qué acciones existen y quién puede ejecutarlas. En Fireblocks, el bypass de un retiro rechazado solo lo pueden pedir Owner o Admin y crea una transacción nueva; la original queda rechazada. Un depósito rechazado puede volver a evaluarse, y uno congelado se descongela tras revisión. [8] Además, el bypass y el descongelado pueden bloquearse para todo el workspace, de modo que solo se hagan con un ticket al soporte. [5]

Circle ofrece una página de alertas donde se revisa cada alerta histórica con información de riesgo de la wallet asociada. [9] La cola, el plazo y la asignación de analistas los define la organización. Si la cola vive en el sistema del proveedor, hay que decidir cómo se exporta su historial a nuestro registro de cumplimiento.

Aquí se cruza el módulo 5. Liberar fondos congelados o saltar un rechazo es un movimiento sensible y debe seguir la separación de funciones: quien investiga la alerta propone, y una segunda persona de cumplimiento aprueba. Lo mismo vale para cambiar umbrales de riesgo: es un cambio de política y pasa por el plano de gobierno.

Los plazos dependen de la severidad. Un esquema posible, a modo de ejemplo, distingue alertas críticas, como exposición directa a una dirección sancionada, que se atienden en horas; altas, en un día hábil; y medias, en pocos días. Las cifras exactas las fija cumplimiento según la regulación aplicable y el contrato con los clientes.

Atribución por cliente: de quién es cada transacción

Escenario: el proveedor de análisis de cadena devuelve una alerta alta sobre un depósito de 40 000 USDC. Para decidir, el analista necesita saber de qué cliente es. Si el depósito llegó a una wallet compartida, la cadena no lo dice; la atribución tiene que viajar con la transacción desde el principio. Esta sección aplica sobre todo al Middleware Blockchain; la última parte, a Circle, aplica al proyecto que usa stablecoins.

Fireblocks: identificador de cliente y entidad legal. Al crear las cuentas de bóveda de una estructura ómnibus, Fireblocks ofrece el parámetro customerRefId, el identificador con el que los proveedores de AML asocian al dueño de los fondos con las transacciones; el nombre de la cuenta de bóveda y ese customerRefId se propagan a cada transacción. [13] La consecuencia de diseño es que el customerRefId debe ser un identificador opaco de nuestro sistema, no un dato personal: Fireblocks pide expresamente no guardar información de identificación personal en esos campos. [14]

Fireblocks permite además registrar el LEI (Legal Entity Identifier, el código de 20 caracteres de GLEIF que identifica a una persona jurídica) para que las contrapartes vean datos verificados de nuestras direcciones, y asignar cuentas de bóveda a entidades legales por API. [15] Si el grupo opera con varias entidades, el mapa bóveda-entidad decide qué entidad reporta cada alerta.

Circle: screening por entidad externa. Con la Institutional API de Circle Mint, cada cliente institucional se registra como entidad externa, y cada llamada a POST /v1/externalEntities dispara un screening de sanciones síncrono sobre nombre, identificador fiscal, país y dirección. La wallet de la entidad existe desde la creación, pero no se puede usar mientras su complianceState sea PENDING o REJECTED; hay que esperar el webhook externalEntities con ACCEPTED. [16] Ese estado es una compuerta más en nuestro flujo: ningún mint ni pago por cuenta del cliente antes de ACCEPTED.

BitGo: regla de viaje en la lista blanca. Como se ve en la sección siguiente, BitGo ejecuta los controles de regla de viaje cuando se registra un destino, no en cada retiro. Para la atribución, el dato del cliente debe existir en el momento del alta del destino. Cómo se mantiene el saldo de cada cliente sobre fondos agrupados es el tema del módulo 8, ómnibus y libro interno.

La regla de viaje como contexto

La regla de viaje (Travel Rule) es la aplicación a los proveedores de servicios de activos virtuales (VASP) de la Recomendación 16 del GAFI, pensada originalmente para transferencias bancarias. Pide que, en ciertas transferencias, el proveedor de origen envíe al de destino información del ordenante y del beneficiario. Los umbrales y el alcance cambian según la jurisdicción, así que este capítulo solo la presenta como contexto: su aplicación concreta la define el área legal.

Para el diseño, lo importante es que añade un dato y un paso al flujo de retiro: identificar si el destino es otro VASP e intercambiar la información antes o junto con la transacción. Fireblocks integra varios proveedores de regla de viaje y aclara que los datos personales se cifran del lado del cliente, sin que Fireblocks tenga las llaves para descifrarlos. [10] BitGo, en su servicio Crypto-as-a-Service, ejecuta los controles de la regla de viaje al registrar una dirección de destino en la lista blanca, y aplica el umbral según la configuración de la empresa. [11]

Cómo lo resuelven Fireblocks, BitGo, Kaleido y los emisores

Fuentes. Fireblocks: ciclo de screening, [4] proveedores [3] y regla de viaje. [10] BitGo: KYC [1] y regla de viaje. [11] Kaleido: su página de producto indica que una política puede comprobar resultados de screening y que las políticas se ejecutan antes de firmar. [12] En la documentación pública de BitGo que consultamos no encontramos un servicio de screening KYT de transacciones fuera de los controles de regla de viaje; por eso esas celdas quedan a validar. Circle: screening [6] y sanciones. [7] Tether: verificación de clientes. [2]

Un criterio para decidir dónde vive el screening: si el proveedor de wallets lo aplica dentro de su propio camino de firma, no hay forma de firmar saltándolo, y eso vale más que una integración propia que podría desactivarse por error. Si las wallets están repartidas entre proveedores, conviene un único proveedor de análisis de cadena y una única tabla de umbrales, para no tener dos criterios de riesgo distintos para el mismo cliente.

Decisiones que el equipo debe cerrar

Entregable: flujo de cumplimiento por tipo de transacción

El entregable es una tabla que cumplimiento firma y que el equipo implementa. Las puntuaciones usan niveles categóricos y las cifras son ilustrativas; si el proveedor devuelve números, cada fila se traduce a rangos.

El siguiente capítulo, ómnibus y libro interno, el módulo 8, toma la atribución por cliente de este flujo y la convierte en un libro que concilia con la cadena. La última fila queda abierta a propósito: el flujo con el emisor de USDC se desarrolla en el módulo 9, Stablecoins I: USDC y Circle Mint, que aplica estos controles en cada salto del dinero.