Un exchange de criptomonedas no mueve valor de forma aislada. Cada retirada hacia otra plataforma y cada depósito procedente de otra es una transferencia entre instituciones, y los supervisores esperan ahora que la información sobre las personas que hay detrás de esas transferencias viaje con los activos. La travel rule — la norma internacional según la cual la institución emisora y la receptora intercambian información de identificación sobre el ordenante y el beneficiario — se aplica a las transferencias de criptoactivos en el Reino Unido desde septiembre de 2023 y en la Unión Europea desde finales de 2024. Para un exchange no es ni opcional ni nueva.
La norma es sencilla de enunciar y exigente de operar. Un exchange que envía los activos de un cliente a otro proveedor debe adjuntar información determinada sobre su propio cliente y sobre el destinatario previsto; el que recibe activos debe obtener la información equivalente y comprobarla antes de liberar los fondos. Hacerlo de forma fiable, a la velocidad que esperan los clientes y para miles de contrapartes con grados de madurez distintos, es un problema de ingeniería y de operación tanto como de cumplimiento.
Este artículo expone qué pide la regla a un exchange, cómo se estructura un flujo en torno a las transferencias salientes y entrantes, cómo lo complican la madurez de la contraparte y los wallets self-hosted, y cómo las expectativas del Reino Unido y la UE moldean el diseño — en el nivel de concepto, proceso y arquitectura de alto nivel, no una receta para un protocolo de mensajería.
Qué exige la travel rule a un exchange
La travel rule obliga al proveedor que inicia una transferencia de criptoactivos y al que la recibe a intercambiar información de identificación sobre las partes, de modo que ningún extremo sea anónimo para las instituciones que la tramitan. El exchange emisor transmite la información que identifica a su propio cliente, el remitente, junto con lo que mantiene sobre el beneficiario; el exchange receptor la obtiene, comprueba su integridad y coherencia y la incorpora a sus controles contra el delito financiero. Como la obligación se apoya en la identificación de clientes que un exchange ya realiza, la capacidad se diseña mejor junto con la verificación KYC y el control AML que añadida a posteriori.
Qué debe enviarse exactamente, y cuándo debe verificarse, varía según la jurisdicción y la naturaleza de la transferencia, y este artículo no reproduce ningún cuerpo de reglas. El punto de diseño se mantiene constante: el exchange debe poder producir información exacta sobre el ordenante y el beneficiario para una transferencia saliente, y recibirla, validarla y actuar en consecuencia para una entrante — para cada transferencia incluida, sin esfuerzo manual en el momento en que un cliente pulsa retirar.
El flujo travel rule fundamental
Un flujo travel rule tiene dos recorridos reflejados, y un buen diseño los trata como partes de pleno derecho de los flujos de retirada y depósito. En el recorrido saliente, cuando un cliente solicita una retirada hacia otro proveedor, el exchange determina si está incluida, identifica a la institución receptora, reúne la información requerida y la transmite por un canal que ambas partes puedan usar. En el recorrido entrante, recibe la información que acompaña a la transferencia, comprueba que está presente y es coherente, la filtra frente a sanciones y criterios de riesgo y decide si abonar, retener o consultar la transferencia.
Ambos recorridos comparten una dependencia que moldea todo el diseño: para una dirección blockchain dada, el exchange debe poder discernir si la contraparte es otra institución regulada o un wallet self-hosted, porque el tratamiento difiere de forma marcada. La tabla siguiente resume las responsabilidades reflejadas; las expectativas precisas de datos y verificación varían según la jurisdicción.
| Etapa del flujo | Transferencia saliente (exchange emisor) | Transferencia entrante (exchange beneficiario) |
|---|---|---|
| Ámbito y contraparte | Determinar el ámbito e identificar a la institución receptora. | Confirmar la institución emisora y que la información esperada ha llegado. |
| Tratamiento de la información | Reunir datos exactos del ordenante y del beneficiario y transmitirlos de forma segura. | Recibir los datos y comprobar su integridad y coherencia. |
| Controles contra el delito financiero | Filtrar el destino y al beneficiario antes de la liberación. | Filtrar al ordenante y ejecutar controles de sanciones antes del abono. |
| Decisión y registro | Liberar, retener o rechazar; conservar la evidencia de lo enviado. | Abonar, retener o consultar; conservar la evidencia de lo recibido. |
VASP contraparte y el problema del sunrise
Un exchange no puede intercambiar información con una contraparte que no puede identificar ni alcanzar, y de ello se derivan dos problemas prácticos. El primero es la identificación: a partir únicamente de una dirección blockchain, el exchange debe averiguar si pertenece a otro proveedor regulado — un proveedor de servicios de activos virtuales, o VASP — y, en su caso, cuál y en qué jurisdicción, lo que determina las reglas aplicables. El segundo es la accesibilidad: incluso cuando la contraparte es conocida, ambas partes necesitan un medio común y seguro de transmisión, de ahí que la interoperabilidad entre las soluciones de mensajería del sector importe tanto como cualquier herramienta aislada.
El ritmo desigual de adopción en el mundo crea el problema del sunrise: la norma ha entrado en vigor en lugares distintos en momentos distintos, de modo que un exchange se topa a menudo con contrapartes que aún no están sujetas a ella o que aún no pueden recibir datos de travel rule. Un diseño viable no da por hecho que toda contraparte está preparada. Define cómo se comporta el exchange cuando la información no puede intercambiarse — recabar y conservar lo posible, aplicar una decisión basada en el riesgo de continuar, retener o rechazar, y dejar constancia de la justificación — para que las lagunas de la red no se conviertan en lagunas de sus propios controles.
Transferencias con wallets self-hosted
No toda transferencia se produce entre dos instituciones. Los clientes depositan desde wallets que ellos mismos controlan, y retiran hacia ellos — wallets self-hosted, o « no custodiados » —, y estos quedan fuera del modelo de institución a institución que presupone la travel rule. No hay un proveedor contraparte con quien intercambiar información, así que la obligación cambia de forma: en lugar de transmitir datos a otra institución, el exchange recaba de su propio cliente la información pertinente sobre el wallet y, según la jurisdicción y el valor en juego, adopta medidas para cerciorarse de que el cliente lo controla.
Esto convierte el tratamiento de los wallets self-hosted en una rama distinta del flujo, no en una excepción que se resuelve a mano. El exchange debe reconocer cuándo una dirección de contraparte es probablemente self-hosted y no institucional, captar la información adicional exigida y acreditar el control del wallet cuando así se espera — todo ello dentro de los mismos flujos que los clientes ya usan. Diseñar este recorrido de forma deliberada evita que una categoría amplia y legítima de transferencias se convierta en una laguna de cumplimiento o en una fuente de fricción constante.
Nota: El tratamiento de las transferencias hacia y desde wallets self-hosted es un conjunto de controles adicional, no una prohibición. El objetivo es recabar la información que exige cada jurisdicción y acreditar el control del wallet cuando se espera, manteniendo practicables las transferencias legítimas para los clientes.
Protección de datos y registro
La travel rule mueve datos personales entre instituciones, y hacerlo de forma lícita es inseparable de hacerlo. Cada mensaje contiene información que identifica a personas reales, por lo que un exchange debe transmitirla y almacenarla de forma segura, limitarla a lo necesario y mantenerla bajo la misma disciplina de protección de datos que el resto de su plataforma. Construir el flujo sin una visión clara de adónde van esos datos, quién puede verlos y cuánto tiempo se conservan convierte un control contra el delito financiero en un riesgo para la protección de datos.
El registro es la otra mitad. Un exchange debe poder mostrar, a posteriori, qué información se envió o se recibió para una transferencia dada, qué controles se ejecutaron y por qué se liberó, retuvo o rechazó. Esa evidencia respalda el control de sanciones y el control AML, se sitúa junto a los registros de auditoría del exchange y es lo que un supervisor o un auditor pedirá ver. Tratar los registros de travel rule como evidencia de auditoría de pleno derecho — conservada y recuperable — permite demostrar que el control funciona y no solo que existe.
Expectativas en el Reino Unido y la UE
Para un exchange que atiende a clientes del Reino Unido y la UE, la travel rule es derecho vigente y no un proyecto futuro. En el Reino Unido se aplica a las transferencias de criptoactivos desde septiembre de 2023, implementada a través de las normas contra el blanqueo y supervisada por la FCA, que ha expuesto cómo espera que las empresas recaben, verifiquen y compartan la información requerida. El registro bajo el régimen contra el blanqueo no equivale, por sí solo, a una autorización para las actividades más amplias que un exchange pueda emprender, y se espera que el próximo régimen británico de criptoactivos se apoye en estas obligaciones en lugar de sustituirlas — donde el diseño se encuentra con la preparación regulatoria para el Reino Unido.
En la Unión Europea, las obligaciones de información se aplican a las transferencias de criptoactivos desde finales de 2024, sin la exención de bajo importe conocida en algunas transferencias tradicionales, y dentro del entorno de CASP autorizado que establece el marco más amplio. El período transitorio de MiCA ha finalizado. Los nuevos proyectos de criptoactivos en la UE deben diseñarse desde el principio para un modelo operativo de CASP autorizado. El límite de lo que aporta un socio tecnológico debe enunciarse con claridad. No emitimos dictámenes jurídicos ni garantizamos autorizaciones. Implementamos los requisitos regulatorios y de auditoría en la tecnología, la infraestructura y las operaciones. Qué transferencias entran en el ámbito, y qué debe enviarse y verificarse, son cuestiones para asesores cualificados; la tarea de ingeniería es hacer que el exchange pueda cumplirlas de forma constante, como parte de la preparación regulatoria para la UE.
Construir, comprar e integrar
Pocos exchanges construyen la mensajería de travel rule desde cero: el valor está en alcanzar el mayor conjunto posible de contrapartes, y el alcance depende de soluciones compartidas y de la interoperabilidad más que de un canal a medida. La elección realista es qué capacidad adoptar y cómo integrarla, según criterios prácticos — cuántas contrapartes alcanza, cómo maneja la identificación y el problema del sunrise, con qué limpieza encaja en los flujos existentes de retirada, depósito, KYC y filtrado, y dónde se procesan los datos personales que transporta. La integración decide el resultado: el tratamiento de travel rule ha de volverse una parte nativa del ciclo de vida de la transferencia y no un añadido, lo que es una cuestión de arquitectura tanto como de elección de proveedor. Un exchange puede sopesarlo al planificar su propia plataforma de exchange de criptomonedas.
Resumen y próximos pasos
La travel rule hace a un exchange responsable de la información de identificación que acompaña a las transferencias en ambos sentidos: reunirla y transmitirla cuando un cliente envía activos, y obtenerla, comprobarla y actuar en consecuencia cuando un cliente los recibe. Las realidades más difíciles que la rodean — identificar contrapartes a partir de direcciones, operar con una red desigualmente preparada, tratar wallets self-hosted y mover datos personales de forma lícita — la convierten en un asunto de ingeniería y de operación, y para el Reino Unido y la UE es derecho establecido.
Las empresas que planifican u operan un exchange pueden empezar por proyectar el tratamiento de travel rule sobre sus flujos existentes de retirada, depósito, identidad y filtrado, y por diseñar la identificación de contrapartes, el tratamiento de wallets self-hosted y el registro como partes de ese conjunto. Nuestro trabajo en software de exchange de criptomonedas y control AML expone cómo estos controles se integran por diseño en el ciclo de vida de la transferencia en lugar de añadirse en su borde.
Diseñar la travel rule dentro del flujo de transferencia, no a su alrededor. Grumpio construye plataformas de exchange de criptomonedas en las que el tratamiento de travel rule, la identidad y el filtrado forman parte del funcionamiento de retiradas y depósitos.