November 5, 2026
Autor: Joao Lages
Una lista de diligencia debida para plataformas de tokenización dirigida a compradores y socios debe comprobar mucho más que las funcionalidades del software. Debe determinar quién desempeña cada función regulada y operativa, qué derecho jurídico representa el token, cómo circulan el dinero y los registros de los inversores, si los controles funcionan en la práctica y si el comprador puede seguir prestando servicio a sus clientes cuando el proveedor o un subcontratista crítico falla.
La revisión más sólida sigue todo el ciclo de vida del producto: estructuración, aprobación del emisor, incorporación del inversor, suscripción, pago, emisión, custodia o conexión de monederos, registro, transmisión, distribuciones, reembolso, información y salida. Una demostración cuidada puede enseñar el recorrido normal. La diligencia debida también debe poner a prueba las excepciones, las evidencias, las responsabilidades y la recuperación. Esta guía está dirigida a entidades financieras, fintechs, gestoras de activos, emisores y socios estratégicos que evalúan una plataforma europea de tokenización. Distingue los requisitos jurídicos vinculantes de las buenas prácticas de mercado y no constituye asesoramiento jurídico, de inversión ni de ciberseguridad individualizado.
Una revisión completa debe permitir que quien toma la decisión responda con evidencias a cinco preguntas. ¿Es lícito el modelo de negocio propuesto en cada jurisdicción de destino? ¿La plataforma ejecuta correctamente las reglas jurídicas y económicas del producto? ¿Están protegidos los activos, los datos y los registros de los inversores? ¿Pueden las entidades reguladas supervisar el servicio y cumplir sus propias obligaciones? ¿Puede modificarse o finalizarse la relación sin perder datos, control o continuidad?
Estas preguntas exigen que los equipos jurídico, de cumplimiento, tecnología, seguridad, operaciones, finanzas, compras y negocio trabajen sobre el mismo mapa de servicios. Cada conclusión material debe remitir a una licencia, contrato, política, diagrama de arquitectura, resultado de prueba, registro operativo o persona responsable. Un cuestionario de proveedor compuesto únicamente por respuestas afirmativas no es una evidencia.
Empiece por redactar un modelo operativo objetivo de una página. Identifique el activo o producto de inversión, el emisor, los tipos de inversor, los países de oferta, el importe de captación, la actividad primaria y secundaria, el registro jurídico de titularidad, el circuito de pagos y los acontecimientos previstos durante el ciclo de vida. Indique qué capacidades son imprescindibles en el lanzamiento y cuáles son opciones futuras. Sin esta base, los evaluadores suelen puntuar funcionalidades llamativas que el producto propuesto no necesita y omitir funciones que determinan si puede salir al mercado.
Una misma plataforma puede admitir modelos muy diferentes: una colocación privada para inversores profesionales, una oferta pública minorista de bonos tokenizados, la distribución de participaciones de un fondo, un mercado de marca blanca o un registro puramente tecnológico. Sus requisitos de regulación, divulgación, idoneidad, custodia, pagos y resiliencia no son intercambiables. El alcance de la diligencia debida debe seguir el servicio real, no la palabra «tokenización».
La tokenización no determina la clasificación. La determinan los derechos y las actividades. Las directrices de ESMA sobre criptoactivos como instrumentos financieros señalan que los instrumentos financieros tokenizados siguen siendo instrumentos financieros a efectos regulatorios y deben evaluarse con un enfoque tecnológicamente neutro que atienda al fondo y no a la forma. Por tanto, un token que representa una acción, un bono u otro valor negociable permanece dentro del marco de valores cuando se cumplen los criterios jurídicos.
Solicite al proveedor una matriz de responsabilidades por jurisdicción. Debe identificar quién fabrica el producto, aprueba al emisor, prepara la información, distribuye o coloca el instrumento, recibe y transmite órdenes, mantiene fondos de clientes, ejecuta pagos, custodia valores o claves, mantiene el registro de referencia, tramita reclamaciones y facilita transmisiones secundarias. Para cada actividad regulada, registre la entidad jurídica responsable, su autorización, los servicios permitidos, el alcance territorial, la autoridad competente y cualquier estructura de agente vinculado, externalización o pasaporte.
No acepte «cumple la normativa de la UE» como conclusión. El pasaporte de un distribuidor regulado puede cubrir un servicio de inversión, pero no resuelve automáticamente el derecho societario nacional, la documentación de oferta pública, la fiscalidad, la protección del consumidor, el idioma ni los requisitos específicos del producto.
Identifique la entidad contratante, la estructura del grupo, los titulares reales, los administradores, los recursos financieros, los seguros y el historial de litigios o medidas de ejecución. Obtenga cuentas recientes o información financiera fiable y proporcionada a la relevancia de la relación. Una plataforma puede tener una tecnología sólida y seguir siendo una dependencia inaceptable si carece de financiación, personal competente o control contractual sobre los servicios que revende.
Trace todos los subcontratistas materiales: alojamiento en la nube, verificación de identidad, filtrado de sanciones, entidades de pago, bancos, custodios, proveedores de monederos o claves, nodos de blockchain, desarrolladores de contratos inteligentes, registradores, analítica de datos y proveedores de soporte. Registre dónde se prestan los servicios y se alojan los datos, si se permite una nueva subcontratación, cómo se notifican los cambios y si el comprador puede oponerse. Pregunte qué dependencias pueden sustituirse y cuáles crean concentración o un punto único de fallo.
Para compradores regulados, esto no es una simple buena práctica de compras. Conforme al artículo 28 de DORA, las entidades financieras incluidas en su ámbito siguen siendo responsables cuando utilizan servicios TIC y deben realizar diligencia debida sobre posibles proveedores, evaluar la concentración y los conflictos, y mantener información sobre los acuerdos contractuales. Puede que la propia plataforma no sea una entidad financiera, pero a menudo deberá aportar las evidencias y la cooperación contractual que necesita su cliente regulado.
Una plataforma no debe tratar el token como si fuera el producto. Debe poder conectar el emisor, el activo, el instrumento jurídico, la información y los permisos de distribución con reglas ejecutables en la plataforma. Revise los criterios de aceptación, las evidencias exigidas, las autoridades de aprobación, el proceso de conflictos y las condiciones que impiden el lanzamiento. El proveedor debe explicar cómo rechaza o subsana un emisor cuya propiedad, titularidad, hipótesis financieras o publicidad propuesta no puedan justificarse.
Examine un expediente de incorporación completo o anonimizado. Compruebe que las afirmaciones fácticas tienen documentos de respaldo, que las cifras financieras cuadran, que las condiciones del producto coinciden con el recorrido del inversor y que los riesgos materiales tienen responsables. Los desencadenantes de revisión deben abarcar cambios del emisor, incumplimientos de cláusulas, impagos, variaciones de valoración, coincidencias con sanciones, reclamaciones materiales y ventas fuera del mercado objetivo. La lista de incorporación de emisores para plataformas de tokenización de Lympid ofrece una perspectiva complementaria centrada en el producto.
Solicite un diagrama actualizado de arquitectura y flujos de datos que incluya el portal del inversor, el servicio de identidad, el sistema de órdenes, los circuitos de pago, los contratos del token, el acceso a la blockchain o a los nodos, la custodia o los monederos, el registro jurídico, los registros contables, la información y las herramientas administrativas. El diagrama debe distinguir los sistemas propiedad de la plataforma de los operados por clientes o subcontratistas, y mostrar los límites de confianza, los accesos privilegiados y las ubicaciones de los datos.
Formule una pregunta sencilla pero decisiva: ¿qué registro prevalece cuando el saldo de la blockchain, la base de datos de la plataforma, el registro del custodio, el libro de pagos y el registro jurídico del inversor no coinciden? La respuesta debe reflejar la legislación aplicable y la documentación del producto. A continuación, examine la frecuencia de conciliación, las tolerancias, la responsabilidad sobre excepciones, su antigüedad, el escalado y la autoridad para corregirlas. La «transparencia on-chain» no sustituye a un registro de referencia controlado.
La documentación de las API debe cubrir autenticación, permisos, idempotencia, límites de uso, versiones, gestión de errores, webhooks, entornos de prueba y aviso de cambios. Los compradores deben probar si una instrucción repetida puede crear suscripciones o pagos duplicados, si los eventos fallidos son recuperables y si un cliente puede exportar datos completos sin una transformación propietaria.
Obtenga las direcciones de los contratos desplegados o un código representativo, informes de auditoría, registros de incidencias, registros de despliegue y un mapa de permisos administrativos. Una auditoría independiente es una evidencia útil, no una garantía. Confirme su alcance, fecha, versión del código, red, hallazgos sin resolver y si posteriores actualizaciones invalidaron la garantía. Revise también los procesos internos de aprobación del código, pruebas, segregación y cambios de emergencia.
Pruebe casos negativos en un entorno controlado. Un monedero no admisible debe ser rechazado. Una instrucción de emisión duplicada no debe aumentar la oferta. La pérdida de un firmante no debe imposibilitar la recuperación. Una pausa de emergencia debe generar evidencias, alertas y una vía definida para reanudar la actividad. El equipo jurídico debe comparar los permisos ejecutables con la documentación del producto; un código técnicamente correcto puede aplicar una regla jurídica equivocada.
Solicite evidencias de gobernanza de seguridad, inventario de activos, control de acceso, gestión de vulnerabilidades, desarrollo seguro, registros, supervisión, respuesta a incidentes, copias de seguridad, recuperación y continuidad del negocio. Certificaciones como ISO 27001 o informes de aseguramiento pueden evitar pruebas duplicadas cuando su alcance y periodo son relevantes, pero no deben sustituir el análisis de sistemas excluidos, excepciones e interfaces específicas del cliente.
Para servicios críticos o importantes, los compradores regulados deben alinear la revisión con DORA. El proveedor debe facilitar niveles de servicio definidos, notificación de incidentes, medidas de seguridad, pruebas de continuidad, cooperación regulatoria, derechos de acceso y auditoría, y mecanismos de salida probados. El artículo 30 de DORA exige determinadas condiciones contractuales para los servicios TIC y disposiciones adicionales para los servicios que respaldan funciones críticas o importantes. La guía de Lympid sobre auditorías y controles de tokenización para la preparación ante DORA explica cómo se traducen esas obligaciones en evidencias de plataforma.
Pida resultados de pruebas recientes, no solo políticas. Entre los escenarios útiles se encuentran el volumen máximo de suscripciones, la indisponibilidad del proveedor de identidad, la confirmación bancaria retrasada, la congestión de la blockchain, una cuenta de administrador comprometida, la pérdida de una clave de firma, una importación de datos dañada, la caída de un nodo y la restauración desde una copia de seguridad. Registre los objetivos de tiempo y punto de recuperación, los resultados obtenidos, los hallazgos abiertos y las fechas de subsanación.
Trace los datos personales por finalidad, origen, sistema, destinatario, ubicación y plazo de conservación. Determine si cada parte actúa como responsable, corresponsable o encargado del tratamiento. Conforme al artículo 28 del RGPD, un responsable debe utilizar encargados que ofrezcan garantías suficientes y establecer las condiciones de tratamiento exigidas. Por tanto, la revisión debe cubrir medidas de seguridad, confidencialidad, autorización de subencargados, derechos de los interesados, apoyo ante brechas, supresión o devolución, información de auditoría y transferencias internacionales.
Los documentos de identidad, las evidencias de sanciones y la información financiera del inversor no deben escribirse en una blockchain pública. Cuando se utilicen hashes o identificadores on-chain, valore si aún pueden vincularse a una persona identificable y si la inmutabilidad entra en conflicto con la conservación o el ejercicio de derechos. Verifique la segregación entre clientes, el cifrado, los registros de acceso, el uso de datos de producción en pruebas y la capacidad del comprador para obtener y suprimir sus datos al finalizar la relación.
Dibuje el flujo de fondos desde la orden del inversor hasta la liquidación de la suscripción, la liberación al emisor, las distribuciones, los reembolsos y la amortización. Para cada cuenta, indique el titular jurídico, el régimen de salvaguarda, el uso permitido, el proceso de conciliación y el tratamiento de fallos. Confirme quién puede aprobar un cierre, cambiar datos bancarios, liberar fondos o crear un reembolso. La doble aprobación y la conciliación independiente importan más que una pantalla de pagos visualmente fluida.
Utilice un lenguaje preciso sobre custodia. Custodiar claves criptográficas, mantener instrumentos financieros, llevar un registro jurídico y operar un monedero ómnibus son funciones diferentes. Verifique la entidad responsable, su autorización y el tratamiento en caso de insolvencia para cada una. La plataforma debe admitir operaciones societarias, rendimientos, datos fiscales, vencimientos, amortizaciones parciales, transmisiones, herencias, órdenes judiciales, bloqueos por sanciones, comunicaciones de impago y correcciones de registros erróneos.
El contrato debe convertir las conclusiones de la diligencia en derechos exigibles. Revise el alcance, los niveles de servicio, el cálculo de disponibilidad, el horario de soporte, la gravedad de incidentes, los plazos de aviso, la ubicación de datos, la subcontratación, el acceso de auditoría y regulatorio, los compromisos de seguridad, la responsabilidad, los seguros, la propiedad intelectual, el control de cambios, la resolución, la asistencia en la transición y la devolución de datos. Los materiales comerciales no deben prometer capacidades que el contrato excluye.
Un plan de salida solo es creíble si el comprador puede identificar proveedores alternativos o una solución interna, exportar registros utilizables y mantener el servicio crítico. DORA exige a las entidades incluidas en su ámbito planificar la salida de acuerdos TIC que respaldan funciones críticas o importantes sin interrumpir el negocio, el cumplimiento ni el servicio al cliente. Los compradores deben probar una exportación de muestra, documentar dependencias, estimar el tiempo y coste de transición y definir cómo se transferirán o neutralizarán las claves, los dominios, los permisos de contratos inteligentes y las cuentas administrativas.
Compare el coste total, no solo las tarifas de la plataforma. Incluya la estructuración jurídica, las integraciones, las licencias o socios regulados, las comprobaciones de incorporación, las comisiones de pagos y custodia, los costes de blockchain, el soporte, el desarrollo a medida, el aseguramiento, las migraciones y la salida. Confirme las unidades de precio, los compromisos mínimos, los gastos repercutidos, la moneda, los impuestos y la responsabilidad por operaciones fallidas o repetidas.
Solicite un plan de implantación con responsables, dependencias, criterios de aceptación y una ruta crítica realista. Un piloto útil debe probar un producto representativo y las integraciones más complejas, no una demostración simplificada desconectada de producción. Los hitos de liberación deben incluir la aprobación jurídica, los hallazgos de seguridad, la conciliación, la conservación de evidencias, la formación operativa y los escenarios de fallo.
La lista corta debe reflejar el modelo operativo y no una clasificación genérica de proveedores. Hay tres vías habituales.
No adjudique el mandato a una plataforma únicamente porque cubra la lista más larga de funcionalidades. La mejor solución es la que cumple el modelo jurídico y operativo requerido con el menor número de dependencias sin controlar, genera evidencias aceptables para los órganos de gobierno y los reguladores, y puede mantenerse después del lanzamiento.
Una señal de alerta no siempre exige rechazar al proveedor. Sí exige un responsable, evidencias, un plazo de subsanación y aprobación en el nivel de riesgo adecuado. Compras no debe permitir que la urgencia comercial transforme una condición de lanzamiento sin resolver en un riesgo de producción aceptado.
Una lista de diligencia debida para plataformas de tokenización dirigida a compradores y socios es eficaz cuando conecta permisos jurídicos, reglas del producto, controles técnicos, evidencias operativas y derechos contractuales. El objetivo no es demostrar que una plataforma puede emitir un token. Es demostrar que el servicio de inversión completo puede lanzarse, supervisarse, conciliarse, recuperarse y finalizarse sin perjudicar a los inversores ni incumplir las obligaciones del comprador.
Utilice la lista de forma proporcionada, pero no elimine un área de trabajo porque el proveedor sea pequeño o el piloto limitado. Ajuste la profundidad al riesgo, pero conserve las preguntas. Una revisión bien dirigida produce un registro de decisión claro: alcance aprobado, evidencias utilizadas, riesgos residuales, subsanación, responsables y condiciones de lanzamiento.
Si está considerando lanzar un producto de inversión tokenizado, hable con Lympid.
Book a call with us today and get a free assessment.
