Estar preparado para MiCA describe un exchange cuya arquitectura puede evidenciar los requisitos aplicables a un proveedor de servicios de criptoactivos autorizado, y no una plataforma que ha adquirido una etiqueta. El marco de los mercados de criptoactivos se aplica plenamente desde el 30 de diciembre de 2024, y las disposiciones transitorias que permitían operar bajo los regímenes nacionales han finalizado. La cuestión que afronta un nuevo proyecto no es, por tanto, si el marco se aplica, sino si sus sistemas pueden demostrar los controles que el marco presupone ya establecidos.
El período transitorio de MiCA ha finalizado. Los nuevos proyectos cripto de la UE deben diseñarse desde el principio para un modelo operativo de CASP autorizado. Una plataforma que se ensambla primero y se concilia con los requisitos después hereda un programa de subsanación antes de haber recibido su primera orden; una plataforma diseñada en torno al modelo operativo genera la mayor parte de las pruebas que exige una solicitud como subproducto de su funcionamiento normal.
Este artículo expone qué significa la preparación para MiCA en el plano de la arquitectura: cómo se estructuran la custodia, la negociación, los controles contra el delito financiero y la resiliencia para que una autoridad nacional competente, un auditor externo o la propia función de cumplimiento pueda ver cómo se comporta la plataforma y quién la ha modificado. La perspectiva es de diseño y adquisición, no una receta de implementación.
Qué significa estar preparado para MiCA en la arquitectura
La preparación se confunde a menudo con un certificado. No existe una plataforma certificada por MiCA, y la autorización no la concede directamente la ESMA; la concede la autoridad nacional competente del Estado miembro en el que el proveedor se establece, mientras la ESMA mantiene el registro público de las empresas autorizadas. Estar preparado para MiCA designa, por tanto, una arquitectura estructurada en torno a los requisitos pertinentes, de modo que la autorización sea alcanzable y, una vez concedida, siga siendo demostrable bajo supervisión.
La consecuencia práctica es que la preparación es una propiedad de la prueba más que de las funcionalidades. Dos plataformas pueden ofrecer las mismas funciones de negociación, mientras que solo una puede mostrar, cuando se le solicita, cómo se segregan los activos de los clientes, cómo se tramitó una orden o quién aprobó un cambio de configuración. La arquitectura capaz de aportar esas respuestas sin reconstruirlas a posteriori es la que sostiene una afirmación defendible de preparación para MiCA.
El modelo operativo de CASP como base de diseño
Un proveedor de servicios de criptoactivos se autoriza para servicios concretos, y cada servicio que ofrece conlleva sus propias obligaciones. Operar una plataforma de negociación, prestar custodia, cambiar criptoactivos por fondos y ejecutar órdenes por cuenta de clientes son actividades distintas con controles distintos, y la combinación que un exchange pretenda ofrecer define el modelo operativo que su arquitectura debe sostener. Elegir esa combinación tarde, después de haber construido la plataforma en torno a una hipótesis más estrecha, figura entre las correcciones más costosas de un proyecto.
Como la ventana transitoria está cerrada, no existe un derecho adquirido que permita a un exchange iniciar su actividad y alinearse más tarde. La gobernanza que el marco espera —una asignación clara de responsabilidades, la separación de tareas incompatibles y una responsabilidad nominada para las funciones de control— debe expresarse en la propia plataforma: mediante el diseño de roles y permisos, los flujos de aprobación y la separación entre quienes negocian, quienes mueven activos y quienes modifican el sistema. Son decisiones de arquitectura antes de ser enunciados de política.
Custodia y segregación de los activos de los clientes
Cuando un exchange mantiene criptoactivos o fondos por cuenta de clientes, el marco exige que esas tenencias se protejan y se mantengan separadas de los recursos propios de la empresa. En el plano de la arquitectura, esto se traduce en un diseño de wallets y ledger que mantiene segregadas las posiciones de los clientes, las concilia de forma continua con los saldos on-chain y los registros internos, y restringe quién puede autorizar el movimiento de activos. La distribución de las tenencias entre esquemas hot, cold y multisig es una decisión de control, y no meramente operativa, porque determina cómo se limita la exposición y cómo se aprueban los retiros.
Las pruebas que ese diseño debe generar son concretas. Debe poder demostrarse, en cualquier momento, que los saldos de clientes registrados coinciden con los activos realmente mantenidos, que el acceso a las claves está restringido y es atribuible, y que cada movimiento lleva un aprobador y un motivo. El detalle de los procedimientos de gestión de claves y de los umbrales de firma corresponde a la función de seguridad y no a una descripción pública, pero el requisito arquitectónico permanece constante: la segregación y la conciliación deben ser continuas y demostrables, no periódicas y afirmadas.
Nota: La segregación es antes un problema de conciliación que un problema de almacenamiento. Un exchange que no pueda conciliar las tenencias de los clientes con su ledger casi en tiempo real no puede evidenciar la protección de los activos, con independencia de cómo custodie sus claves, y la brecha suele aflorar durante un incidente y no durante el diseño.
Negociación ordenada e integridad del mercado
Operar una plataforma de negociación conlleva obligaciones que alcanzan el núcleo del exchange. La negociación debe desarrollarse con reglas transparentes y aplicadas de manera coherente, las órdenes y su tramitación deben registrarse, y la plataforma debe permitir la detección y la comunicación de conductas que puedan constituir abuso de mercado. En el plano arquitectónico, esto conecta la capa de matching, la capa de datos de mercado y la capa de vigilancia: el exchange debe poder reconstruir cómo se recibió, priorizó y ejecutó una orden, y hacer visibles los patrones que justifican una investigación.
La integridad del mercado depende también de la gestión de los conflictos de interés, que adquiere una dimensión arquitectónica cuando un exchange negocia por cuenta propia, opera una función de liquidez vinculada o lista activos en los que tiene un interés. Los controles que separan esas actividades, y los registros que acreditan esa separación, pertenecen a la misma base de pruebas que examina una evaluación de autorización. Una plataforma cuyo ciclo de vida de las órdenes y cuyas salidas de vigilancia no puedan exportarse ni explicarse resulta difícil de defender bajo supervisión, sean cuales sean sus características de rendimiento.
Controles contra el delito financiero y Travel Rule
Un exchange autorizado opera dentro del régimen contra el blanqueo de capitales además del marco de mercado, y ambos se supervisan cada vez más de forma conjunta. La diligencia debida en la incorporación de clientes, la monitorización continua, el filtrado de sanciones y PEP, y la obligación de acompañar las transferencias de criptoactivos con información del ordenante y del beneficiario en virtud de la Travel Rule forman parte del modelo operativo. La autoridad europea contra el blanqueo de capitales ya está en funcionamiento y la supervisión se consolida a escala de la UE, con un código normativo único que surtirá efecto en el período próximo; por ello, una arquitectura diseñada para la base actual debería anticipar expectativas más estrictas y uniformes en lugar del régimen fragmentado al que sustituye.
Para la arquitectura, el requisito es la integración y no la yuxtaposición. La verificación de identidad y el filtrado no pueden residir en una herramienta separada cuyos resultados se transcriban a mano; pertenecen a los flujos de incorporación y de transacción, con los resultados registrados junto al cliente y a la transacción para que un revisor pueda ver por qué se aceptó una cuenta o se retuvo una transferencia. Las consideraciones de diseño que sustentan estos controles se exponen en software de control AML y software de verificación KYC.
Resiliencia operativa y riesgo de terceros
Un exchange preparado para MiCA también debe satisfacer las expectativas de resiliencia operativa que ahora se aplican a las entidades financieras de la UE. DORA se aplica desde el 17 de enero de 2025 y trata la resiliencia como algo que debe probarse y evidenciarse: la gestión de los riesgos de las tecnologías de la información y la comunicación, el tratamiento y la comunicación de incidentes, las pruebas de resiliencia y la vigilancia de los terceros críticos entran todos en su ámbito. Para un exchange, esto convierte la disponibilidad de una aspiración operativa en un control que debe ejercerse, medirse y demostrarse eficaz.
La dependencia de terceros es el punto en el que la resiliencia y la arquitectura se encuentran de forma más directa. Cuando la custodia, el alojamiento, el matching o el filtrado los prestan terceros, esos proveedores pasan a formar parte del entorno de control del exchange, y el marco espera evaluación, pruebas y un plan de salida viable en lugar de una mera garantía contractual. Un exchange que no pueda recuperar un objetivo definido sin la intervención de un proveedor, o que no pueda abandonar a un proveedor sin reconstruirlo todo, presenta una brecha de resiliencia que ningún documento cierra. Consideraciones técnicas relacionadas se exponen en preparación regulatoria para la Unión Europea.
Alcance: 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.
Pruebas y expediente de autorización
Una evaluación de autorización, y la supervisión que la sigue, comprueban si el exchange puede mostrar lo que afirma hacer. Cada dominio de arquitectura tiene, por tanto, una pregunta correspondiente sobre la prueba, y una plataforma está preparada cuando esas preguntas pueden responderse desde el sistema y no desde la intención. La tabla siguiente relaciona los dominios examinados más arriba con la demostración que cada uno debe sostener.
| Dominio de arquitectura | Qué debe poder demostrar la plataforma |
|---|---|
| Custodia y segregación | Las tenencias de los clientes coinciden con los activos mantenidos; los movimientos de activos están aprobados y son atribuibles |
| Negociación e integridad | El ciclo de vida de las órdenes es reconstruible; las salidas de vigilancia pueden exportarse y explicarse |
| Delito financiero | Los resultados de verificación y filtrado se registran junto al cliente y a la transacción |
| Resiliencia operativa | Los objetivos de recuperación se ejercitan; la salida de terceros está planificada y probada |
| Control de cambios y accesos | Los cambios de configuración llevan aprobadores nominados y versiones fechadas |
Reunir estas pruebas después de construir la plataforma es posible pero costoso, porque los registros que no se capturaron en su momento no pueden recrearse con fidelidad. La vía eficiente consiste en tratar el expediente de autorización como un resultado de la operación ordinaria, generado de forma continua por una plataforma cuya arquitectura se diseñó con el modelo CASP a la vista. La perspectiva de planificación más amplia se describe en software de exchange de criptomonedas.
Resumen y próximos pasos
La preparación para MiCA no es un distintivo que se aplica a una plataforma terminada; es una propiedad de una arquitectura capaz de segregar los activos de los clientes, operar un mercado ordenado, integrar los controles contra el delito financiero, resistir las interrupciones y evidenciar cada uno de estos elementos cuando se le solicita. Con el período transitorio cerrado, esa arquitectura es la condición de partida de un nuevo exchange de la UE y no un refinamiento posterior, y el coste de incorporarla a posteriori es sistemáticamente mayor que el coste de diseñarla desde el inicio.
El próximo paso práctico consiste en precisar, para cada uno de los dominios anteriores, qué deberá demostrar la plataforma y de dónde procederá esa prueba. Un exchange capaz de responder a esas preguntas antes de seleccionar una plataforma está en condiciones de evaluar a los proveedores frente al modelo operativo que realmente debe satisfacer, y no frente a una lista de funcionalidades.
La preparación para MiCA es una decisión de arquitectura, no un certificado. Grumpio diseña y entrega tecnología de exchange en torno al modelo operativo de CASP, con los controles de custodia, vigilancia, prevención del delito financiero y resiliencia que un expediente de autorización debe evidenciar.