Registro de referencia para valores tokenizados

El registro de referencia (registry of record) es la relación con eficacia jurídica de quién es titular de qué: el registro que un tribunal, un regulador o un liquidador considera determinante cuando se discute la titularidad. En una estructura tokenizada, ese registro es o bien el propio registro en cadena, cuando la ley reconoce los registros basados en DLT, o bien un registro fuera de cadena o híbrido del que los tokens en cadena son un simple reflejo. Cuál de ellos prevalece es una cuestión de jurisdicción y de documentación, no una preferencia tecnológica. Equivocarse no empeora la experiencia del usuario: pone en duda la exigibilidad de la posición de cada inversor.

Por qué la cuestión del registro es estructural

La mayoría de las conversaciones sobre tokenización empiezan por el token. Los responsables de cumplimiento y los asesores jurídicos deberían empezar una capa más abajo: cuando se discute la titularidad, ¿qué registro reconoce la ley?

En un litigio —una transferencia impugnada, una sucesión, la reclamación de un acreedor, una insolvencia— el tribunal no pide un enlace a un explorador de blockchain. Pide el libro registro de socios, el libro de accionistas, los registros del agente de transferencias o el instrumento que la ley aplicable designe como de referencia. Si la estructura tokenizada nunca definió ese instrumento, o lo definió de forma incoherente entre los términos del token, los documentos de suscripción y los documentos constitutivos del emisor, el litigio pasa a ser una disputa sobre qué registro cuenta antes de poder ser una disputa sobre quién es titular del activo.

Por la misma razón, la jurisdicción es la primera decisión de estructuración en los fondos tokenizados: el ordenamiento en el que se emite determina qué son jurídicamente sus registros en cadena. Un token puede ser el valor, una prueba del valor o un comprobante que remite a un valor registrado en otro lugar; el mismo smart contract puede ser cualquiera de los tres según dónde y cómo se haya emitido el instrumento.

Por tanto, el registro de referencia es una decisión sobre el sistema de registro que debe tomarse de forma deliberada, documentarse en los términos de la emisión y aplicarse en la operativa, en coordinación con asesores jurídicos cualificados de la jurisdicción de emisión.

Los tres modelos de registro

Las estructuras tokenizadas que hoy están en producción resuelven la cuestión del registro de una de tres maneras.

De ahí se derivan dos conclusiones. Primero, el debate «en cadena frente a fuera de cadena» es en gran medida ruido. Los tres modelos son legítimos; responden a jurisdicciones y tipos de instrumento distintos. Lo que no es legítimo es la ambigüedad: documentos de oferta que dan a entender que el token es el valor mientras el libro registro de socios de la SPV dice otra cosa, sin ninguna regla escrita sobre qué registro prevalece.

Segundo, la gestión de las discrepancias es la prueba de un registro real. Las claves se pierden, hay transferencias realizadas bajo coacción y los tribunales dictan órdenes. Un registro de referencia que no puede expresar «esta transferencia queda revertida» o «este titular es sustituido por su sucesión» no es un registro: es una caché. Es uno de los ámbitos en los que la configuración jurídica y la arquitectura de la plataforma deben diseñarse juntas, porque los mecanismos de corrección tienen que existir tanto en los documentos jurídicos como en el software.

Qué exige operativamente un registro defendible

Tanto si el registro de referencia está en cadena, fuera de cadena o en un modelo híbrido, los requisitos operativos convergen. Un registro capaz de resistir el escrutinio en un litigio o en una inspección regulatoria necesita:

• Asientos vinculados a una identidad. Cada asiento del registro remite a una persona verificada, física o jurídica, no a una dirección de wallet. Las direcciones rotan, se ven comprometidas y se heredan; la titularidad jurídica corresponde a personas. La correspondencia entre identidad y dirección forma parte del propio registro.
• Gestión de operaciones societarias. Distribuciones, desdoblamientos, llamadas de capital, reembolsos, conversiones y derechos de voto deben poder calcularse a partir del registro en una fecha de registro definida, lo que obliga a conservar el estado histórico y no solo los saldos actuales.
• Una pista de auditoría inmutable. Cada cambio en el registro —quién lo hizo, con qué autoridad y en virtud de qué documento— queda registrado de forma que cualquier alteración sea detectable. En una inspección, el historial del registro importa tanto como su estado actual.
• Capacidad para ejecutar órdenes judiciales y transferencias forzosas. Un registro que no puede ejecutar una transferencia ordenada por un tribunal, congelar una posición sujeta a sanciones o sustituir el asiento de un titular fallecido no puede servir como registro jurídico. Esa capacidad debe estar sujeta a permisos, quedar registrada y estar gobernada, pero debe existir.
• Copias de seguridad y recuperación. El registro de referencia debe sobrevivir a fallos de infraestructura con objetivos de recuperación definidos, y el procedimiento de recuperación debe estar documentado y probado. Un registro irrecuperable es un incumplimiento estructural a la espera de un detonante.

Nada de esto es exótico: los agentes de transferencias y los administradores de fondos lo hacen desde hace décadas. La tokenización no elimina estos requisitos; cambia el lugar donde se implementan y elimina la excusa de los ciclos de conciliación lentos, porque ahora el registro puede actualizarse y verificarse de forma continua.

La elegibilidad es un dato del registro, no una hoja de cálculo aparte

KYC, el control AML, la condición de inversor acreditado y la residencia suelen tratarse como un control de entrada en la incorporación: se verifica una vez, se admite al inversor y se pasa a otra cosa. En una estructura tokenizada transfronteriza eso no basta: la elegibilidad es una propiedad de cada asiento del registro que se mantiene de forma continua.

La razón es mecánica. Las restricciones de transferencia se aplican en el momento de la transferencia: ¿es elegible el comprador en su jurisdicción?, ¿se cumple el periodo mínimo de tenencia?, ¿la transferencia supera un límite de número de inversores o de concentración? Esas comprobaciones solo pueden automatizarse si los datos de elegibilidad están junto al registro —vinculados a los asientos que la transferencia modificaría— y no en una hoja de cálculo de cumplimiento que se concilia cada trimestre.

Operar en varias jurisdicciones eleva el listón: un inversor elegible en la suscripción puede dejar de serlo tras una actualización de sanciones o un cambio de residencia, y el registro debería ponerlo de manifiesto antes de la siguiente operación societaria o transferencia, no después. Automatizar la actualización de KYC/AML y el control de sanciones como flujos de datos hacia el registro es lo que hace viable el control de transferencias en varias jurisdicciones, y lo que los reguladores esperan cada vez más ver acreditado con evidencia, no simplemente afirmado. Cómo se extienden esos controles a las transferencias secundarias se explica en nuestro enfoque de flujos de transferencia controlada y estrategia de liquidez.

Por qué las entidades reguladas quieren controlar la capa de registro

Si el registro es el registro de referencia de la titularidad, sus modos de fallo son modos de fallo del activo, no del software. Ese cambio de enfoque está impulsando dos requisitos de contratación que ya son habituales en las evaluaciones de entidades reguladas.

Titularidad del código fuente. Si el registro funciona sobre el SaaS de un proveedor y ese proveedor quiebra, es adquirido o sale del mercado, ¿qué ocurre con el registro de referencia? La exportación de datos no es una respuesta: un CSV exportado sin el software que aplica las restricciones de transferencia, calcula las operaciones societarias y mantiene la pista de auditoría no es un registro operativo.

Las entidades reguladas exigen cada vez más acceso al código fuente, o su titularidad, específicamente para la capa de registro, de modo que el fallo de un proveedor no pueda dejar el registro huérfano. La planificación de la salida en la externalización de funciones críticas es una expectativa supervisora permanente en la mayoría de las grandes jurisdicciones, y pocas funciones son tan críticas como el registro.

Control del despliegue y residencia de datos. Los datos del registro son datos personales de inversores más datos de titularidad: las categorías con mayor probabilidad de estar sujetas a normas de protección y localización de datos en las jurisdicciones donde operan las entidades reguladas. Ejecutar el registro on-premise o en el perímetro de nube propio del operador mantiene los datos del registro en la región, deja el gobierno de los accesos dentro de la entidad regulada y ofrece a los inspectores un sistema que la entidad puede realmente acreditar y controlar. Los argumentos generales a favor del despliegue controlado por el cliente —incluido lo que «on-premise» significa y lo que no— se exponen en nuestra presentación de la plataforma de tokenización on-premise.

Ninguno de los dos requisitos responde a desconfianza hacia los proveedores. Responde al carácter específico del registro: cualquier otro sistema de la arquitectura puede sustituirse, aunque sea con disrupción; el registro de titularidad de referencia no puede permitirse un único punto de fallo externo.

Un único sistema de registro, o cinco proveedores y un problema de conciliación

La última cuestión es si registro, cumplimiento y liquidación funcionan como un único sistema o como una cadena de proveedores —proveedor de incorporación de inversores, proveedor de registro, plataforma de tokens, infraestructura de pagos, herramienta de reporting— unidos mediante API y conciliaciones nocturnas.

La cadena de varios proveedores puede funcionar. Pero cada costura es un punto donde los registros pueden discrepar: el sistema de KYC marca a un inversor como no elegible mientras el registro sigue mostrándolo como titular; la infraestructura de liquidación muestra un pago que el registro no ha recogido; el saldo de tokens y el asiento del registro divergen y ningún sistema está autorizado para corregir al otro. En una arquitectura de software normal, eso son errores. En una arquitectura de registro de referencia, los huecos de conciliación son huecos jurídicos: periodos en los que el registro de referencia es, como mínimo, discutible y, de forma demostrable, no está verificado.

Un sistema de registro unificado —en el que los datos de elegibilidad, los asientos del registro, los controles de transferencia y el estado de liquidación son estados de un mismo sistema y no mensajes entre sistemas— elimina las costuras en lugar de vigilarlas. La custodia sigue siendo una frontera externa real en la mayoría de las estructuras (se trata por separado en la guía de infraestructura de custodia de activos digitales), pero el registro, sus datos de cumplimiento y su lógica de transferencia no tienen buenos motivos para residir en tres lugares distintos.

Es la arquitectura que Asset Haus despliega como infraestructura de tokenización para mercados de capital privado: registro, datos de cumplimiento y control de transferencias en un único sistema controlado por el cliente, con la configuración jurídica coordinada con asesores cualificados de la jurisdicción de emisión. En 32 operaciones estructuradas y $200M+ facilitados en 9+ jurisdicciones, la decisión sobre el registro de referencia ha formado parte del trabajo de estructuración desde el primer día, no de una corrección posterior al lanzamiento. En nuestros casos hay ejemplos de cómo se resuelve esa decisión según la clase de activo y la jurisdicción.

Preguntas frecuentes

¿Qué es el registro de referencia en la tokenización?

Es el registro con eficacia jurídica de quién es titular de los valores tokenizados: el registro que un tribunal o un regulador considera determinante. Según la jurisdicción y la estructura, es el propio registro en cadena (cuando la ley reconoce los registros DLT), un registro tradicional fuera de cadena que los tokens reflejan, o un modelo híbrido con reglas de prelación documentadas.

¿Es la blockchain el registro jurídico de la titularidad?

Solo cuando la ley lo establece y la emisión se estructura en consecuencia; por ejemplo, los valores registrados en un libro distribuido conforme al art. 973d y ss. del Código de Obligaciones suizo, o la emisión mediante DLT al amparo de las leyes luxemburguesas sobre blockchain. En la mayoría de las demás estructuras, incluido el patrón habitual de agente de transferencias en EE. UU., el registro de referencia está fuera de cadena y los tokens son una representación sincronizada. La respuesta depende de la jurisdicción y debe confirmarse con asesores jurídicos cualificados.

¿Qué ocurre si los saldos de tokens y el registro no coinciden?

Lo que digan los documentos de emisión; por eso deben decirlo. En un modelo de copia maestra fuera de cadena, prevalece el registro y las posiciones en tokens se corrigen para que coincidan. En un modelo nativo en cadena, la corrección se hace en el propio registro mediante mecanismos de transferencia forzosa incorporados. Una estructura sin regla de prelación definida tiene un defecto jurídico latente.

¿Qué ocurre si el proveedor de la plataforma cierra?

Si el registro funciona sobre un SaaS alojado por el proveedor sin derechos sobre el código fuente, el registro de titularidad de referencia corre el riesgo de quedar huérfano: una exportación de datos por sí sola no conserva un registro operativo. Por eso las entidades reguladas exigen cada vez más la titularidad del código fuente y un despliegue on-premise o en la nube del cliente para la capa de registro, con procedimientos documentados de continuidad y de cierre ordenado.

¿Puede un tribunal ordenar una transferencia en un registro tokenizado?

Un registro defendible debe admitir transferencias ordenadas judicialmente, congelaciones por sanciones y sucesiones, con independencia de que el titular coopere o de que sus claves estén disponibles. Esa capacidad debe estar sujeta a permisos, quedar íntegramente registrada y reflejarse tanto en los documentos jurídicos como en el software.

---

¿Está evaluando cuál debe ser su registro de referencia y dónde debe ejecutarse? Empiece por la evaluación de preparación.