ERIR en España: funciones y requisitos para valores tokenizados

Una emisión de valores tokenizados necesita un sistema capaz de identificar a sus titulares, registrar las transmisiones y atender los derechos asociados a cada valor. En España, la entidad responsable de la administración de la inscripción y registro, conocida como ERIR, asume funciones legales sobre ese registro cuando los valores se representan mediante tecnología de registros distribuidos o DLT.

Para diseñar una emisión, importa entender qué controla esa entidad y cómo se conecta su trabajo con los contratos inteligentes. La elección de la red, los permisos de administración y la recuperación de posiciones deben responder al modelo jurídico del valor. Esta guía distingue las obligaciones previstas en la normativa de las decisiones de implementación que el proyecto debe concretar con sus participantes. Las responsabilidades deben quedar definidas también para una clave perdida, una transmisión discutida o una solicitud del titular para ejercer sus derechos.

Qué es una ERIR y cuándo interviene

El artículo 8.4 de la Ley 6/2023 regula la entidad o entidades responsables de administrar la inscripción y el registro de valores negociables representados mediante DLT. La figura pertenece al régimen del mercado de valores. No es un sello de calidad aplicable a cualquier token ni una denominación que pueda adoptar un proveedor de software por desarrollar contratos inteligentes.

El punto de partida es clasificar el instrumento y determinar la ley aplicable. El artículo 5 contempla, entre otros supuestos, la elección válida de la ley española para el registro, transmisión y representación de los valores. Por tanto, ni la ubicación de los nodos ni el nombre comercial del token bastan para decidir el régimen de una emisión.

Una vez definido ese encaje, el artículo 6 permite la representación mediante DLT y exige que el sistema identifique a los titulares, determine los valores que les corresponden y preserve la integridad de la emisión. El proyecto debe resolver esas funciones antes de tratar el despliegue del token como una emisión terminada.

Quién puede ejercer la función

El emisor designa a una o varias entidades responsables en el documento de emisión. La ley admite que el propio emisor asuma la función, pero exige en todo caso la habilitación correspondiente para la actividad del artículo 126.a). Ser emisor no concede esa habilitación automáticamente.

La CNMV aclara en sus preguntas 12 y 13 la relación entre la autorización para custodiar valores, los trámites de habilitación y el registro de ERIR por emisiones. Conviene comprobar tanto la entidad y su actividad autorizada como su designación para la emisión concreta. Una marca comercial o una referencia genérica a estar regulado no documenta por sí sola ese alcance.

Para valores admitidos a negociación en infraestructuras DLT, el artículo 8.5 atribuye la responsabilidad a las infraestructuras de mercado autorizadas conforme a la normativa europea aplicable. Ese supuesto debe analizarse por separado del de una emisión no admitida a negociación. Contratar una ERIR para el registro no autoriza al promotor a operar un centro de negociación.

El documento de emisión define el valor y el sistema

El artículo 7 exige identificar los valores y la entidad responsable. En DLT, el documento debe incluir información suficiente sobre el funcionamiento y el gobierno del sistema. El emisor deposita una copia ante la entidad responsable; ambos deben mantenerlo disponible para titulares y público interesado, en los términos de la ley.

Esto tiene una consecuencia técnica: la documentación debe describir el sistema que realmente se va a operar. Si un contrato permite bloquear una posición, cambiar una implementación o reasignar facultades, esas capacidades deben evaluarse dentro del modelo de gobierno. No basta con documentar la transferencia ordinaria y dejar los poderes de administración fuera del diseño.

Como criterio de implementación, resulta útil mantener una matriz que relacione cada operación con su responsable, permiso, evidencia y procedimiento de excepción. Por ejemplo: quién solicita una rectificación, quién comprueba su fundamento, quién autoriza la ejecución y cómo se conserva la trazabilidad. La matriz no sustituye el documento legal; ayuda a comprobar que el software puede cumplirlo.

Titulares, posiciones y transmisiones

El artículo 8.4 atribuye a la ERIR la gestión de identificación de titulares, eventos corporativos, inscripciones y gravámenes. El artículo 10 sitúa la constitución de los valores representados mediante DLT en su primer registro en el sistema, a favor del emisor o de los suscriptores. El artículo 11 regula los efectos de la transferencia registrada.

Una dirección blockchain sirve como identificador técnico, pero no describe por sí sola quién está legitimado para ejercer los derechos. El artículo 13 contempla tanto al beneficiario último como a una entidad autorizada que actúe por cuenta de su clientela y deje constancia de ello. La arquitectura debe permitir interpretar correctamente el modelo de tenencia elegido.

En la práctica, hay que relacionar identidades, direcciones y posiciones sin asumir que cada persona utiliza una única wallet. También hay que distinguir una transferencia del valor a otro titular de un cambio de dirección del mismo titular. Ambas operaciones pueden mover tokens, pero responden a situaciones jurídicas y procedimientos diferentes.

Gravámenes, herencias y certificados

El artículo 12 exige mecanismos para registrar actos como embargos, ejecuciones judiciales, transmisiones por fallecimiento y otros gravámenes. Una implementación limitada a emitir y transferir tokens entre direcciones deja estas operaciones sin resolver.

Cada supuesto necesita una conexión entre la instrucción jurídicamente válida y su ejecución técnica. El sistema no decide si una orden judicial es auténtica o quién tiene derecho a heredar: necesita procedimientos y responsables que comprueben la documentación antes de actuar sobre el registro.

El artículo 14 regula los certificados de legitimación y las condiciones asociadas a su expedición. Para diseñar esta función hay que comprobar qué derechos acredita el certificado, cómo se evita que pierda correspondencia con el registro y cómo se atienden las restricciones aplicables mientras esté vigente. Una captura del explorador o un PDF generado por la interfaz no equivalen automáticamente a ese certificado.

Registro y custodia de claves

La administración del registro y la custodia de las claves privadas son cuestiones relacionadas, pero distintas. Hay que identificar quién conserva las claves con las que se ordenan operaciones y quién dispone de las facultades necesarias para mantener correctamente el registro. La CNMV trata esta distinción y la recuperación de posiciones en su pregunta 27.

Desde el diseño técnico, deben separarse las claves del inversor de las claves administrativas. También deben definirse revocación, sustitución y control de acceso de operadores. Una clave con capacidad para cambiar restricciones o ejecutar recuperaciones requiere controles acordes a esa facultad, aunque no se use para las transferencias ordinarias.

Una wallet perdida plantea además un problema de identificación: antes de actuar hay que comprobar a quién corresponde la posición y qué dirección está autorizada para recibirla. La solución no debería depender de una intervención improvisada del desarrollador. El flujo debe estar acordado, documentado y probado antes de incorporar titulares.

Qué corresponde al proveedor tecnológico

El equipo de desarrollo implementa las funciones acordadas, integra los sistemas y aporta evidencia sobre su comportamiento. La ERIR conserva sus responsabilidades legales aunque utilice software de un tercero. Conviene reflejar esa separación en los contratos de servicio, los accesos y los procedimientos operativos.

Los criterios de aceptación deberían cubrir emisión, transferencias permitidas y rechazadas, restricciones sobre posiciones, cambios de permisos y recuperación. Deben incluir errores: instrucciones duplicadas, información incompleta, caída de un proveedor de acceso a la red o discrepancias entre lo mostrado por la interfaz y el registro.

Un estándar de token puede proporcionar componentes para determinados controles. Su elección no acredita por sí sola que una emisión cumpla la normativa. Tampoco una auditoría de código valida el documento de emisión o autoriza una actividad financiera. Para profundizar en esa distinción, puede consultarse la guía sobre qué demuestra una auditoría de smart contracts.

Continuidad del registro y responsabilidad

El artículo 5.2 del Real Decreto 814/2023 exige un plan de contingencia para gestionar incidentes y mantener la continuidad del registro si la red falla o deja de ser viable. El requisito no se satisface únicamente con una copia de la base de datos de la interfaz.

Como desarrollo operativo de ese objetivo, el proyecto debería probar qué información necesita para reconstruir posiciones, quién declara una contingencia y cómo se conserva el historial de actuaciones. Si se contempla cambiar de red, debe especificarse cómo se determina el estado válido y cómo se evita que existan dos representaciones operativas incompatibles de la misma emisión.

La responsabilidad también tiene una base expresa: el artículo 8.6 prevé que estas entidades respondan frente a perjudicados por omisiones, inexactitudes o retrasos registrales y por incumplimientos dolosos o negligentes de sus obligaciones. Esto no convierte a la ERIR en garante de la solvencia del emisor ni del precio de los valores; delimita responsabilidades sobre su función.

Ejemplo hipotético de una emisión de deuda

Supongamos que una sociedad prepara una emisión de deuda representada mediante DLT y sujeta al régimen español. El ejemplo sirve para conectar funciones; no describe una operación real ni resuelve las condiciones legales de una oferta concreta.

Primero se definen los derechos del valor, sus condiciones económicas y las reglas de transmisión. El emisor designa a la entidad habilitada y prepara el documento de emisión. El proveedor tecnológico traduce los requisitos acordados a permisos y operaciones verificables, con criterios de aceptación para cada flujo.

Durante la suscripción, el sistema relaciona al titular con su posición y registra los valores. Si más adelante solicita transferirlos, se comprueban las condiciones previstas. Si comunica la pérdida de acceso a su wallet, se activa un procedimiento de recuperación con verificación de identidad y autorización documentada, en lugar de tratar la petición como una transferencia ordinaria.

Cuando corresponde gestionar un evento económico, deben reconciliarse titulares, posiciones y derechos según la documentación de la emisión. Si aparece una incidencia, la ERIR y los demás participantes actúan conforme a sus responsabilidades y al plan acordado. El resultado debe poder reconstruirse desde las evidencias, no solo desde lo que muestra una pantalla.

Cómo evaluar una ERIR y preparar la integración

La evaluación empieza por su identidad jurídica, habilitación y alcance para la emisión prevista. Después conviene revisar cómo se distribuyen las tareas entre emisor, ERIR, custodio de claves y proveedor tecnológico. Si una misma entidad presta varios servicios, cada función debe seguir siendo identificable.

La propuesta económica debería separar puesta en marcha, mantenimiento del registro, eventos corporativos, soporte, integraciones y posibles actuaciones extraordinarias. No existe un precio único que pueda deducirse de la norma; comparar ofertas exige conocer volumen, complejidad, responsabilidades y condiciones de salida.

Antes de desplegar, el equipo debería poder mostrar el recorrido completo de una inscripción, una transferencia, una restricción y una recuperación, con responsables y evidencia. Las decisiones de oferta, comercialización y negociación requieren su propio análisis, desarrollado en el artículo sobre security tokens en España. El trabajo de tokenización debe conectar estas decisiones con una arquitectura que pueda operarse durante toda la vida del valor.