MiCAR, Stablecoins y la Capa de Compliance: Lo Que la Infraestructura Bancaria Central Debe Manejar para H2 2026
MiCAR impone requisitos de reserva, obligaciones de redención y deberes de monitoreo de transacciones sobre emisores de stablecoins y proveedores de servicios de criptoactivos. Estas no son reglas de mesa de negociación. Son requisitos de arquitectura de compliance que aterrizan directamente en la infraestructura bancaria central, y la mayoría de los módulos de compliance construidos para depósitos fiat no están equipados estructuralmente para satisfacerlos.
El consorcio Qivalis (37 bancos europeos en 15 países, presidido por Sir Howard Davies) apunta a H2 2026 para un euro stablecoin conforme a MiCAR. Solo el 0,2 % de las stablecoins globales están denominadas en euros hoy. Cuando eso cambie, la carga de compliance recae sobre las instituciones que emiten y custodian el token. La decisión de infraestructura no es si cumplir con MiCAR. Es si la arquitectura de compliance puede satisfacer los requisitos de MiCAR sin una reconstrucción completa.
Qué Requiere MiCAR en Realidad
MiCAR (Reglamento UE 2023/1114, plenamente exigible desde junio de 2024) introduce dos categorías regulatorias distintas relevantes para la banca central:
E-Money Tokens (EMTs) son tokens que mantienen un valor estable por referencia a una sola moneda oficial. Un stablecoin denominado en euros emitido por un banco es un EMT. El emisor debe mantener un respaldo de reserva del 100% en activos líquidos de alta calidad, mantenerlos en una cuenta segregada separada de los fondos operativos, y redimir cualquier token a valor nominal bajo demanda dentro de un día hábil.
Asset-Referenced Tokens (ARTs) hacen referencia a una canasta de activos: monedas, commodities u otros tokens. El requisito de reserva es de al menos el 2% del promedio de emisión circulante, también segregado.
Para ambos tipos de token, MiCAR requiere monitoreo continuo de transacciones bajo las mismas obligaciones AML que los instrumentos fiat. El Artículo 83 extiende explícitamente las obligaciones de AMLD5/6 a proveedores de servicios de criptoactivos y emisores. Un emisor de euro stablecoin debe filtrar transacciones de token contra listas de sanciones, aplicar CDD a titulares de tokens, y mantener trails de auditoría para movimientos de tokens, usando los mismos estándares legales que aplican a SEPA Credit Transfers.
La carga de compliance no es aditiva. Es estructuralmente nueva.
Dónde Fallan los Módulos de Compliance Existentes
La mayoría de las arquitecturas de compliance de banca central operan con una separación limpia: CDD fiat se maneja por una tubería (verificación de identidad, screening AML, evaluación de políticas CDD), y cualquier exposición cripto pasa por un proceso separado, a menudo operado manualmente. Esta separación tenía sentido cuando la actividad cripto era marginal y los instrumentos token no eran legalmente equivalentes a depósitos.
Bajo MiCAR, la separación crea tres modos de fallo concretos.
Registros CDD fragmentados. Si un cliente mantiene tanto una cuenta de demanda en euros como un euro stablecoin en la misma institución, es un cliente con un solo perfil de riesgo. Un registro CDD unificado debe cubrir ambas exposiciones. Tuberías de compliance separadas para fiat e instrumentos token producen evaluaciones de riesgo separadas, almacenamiento de documentos separado, y trails de auditoría separados para la misma persona jurídica, creando la apariencia de dos sujetos de compliance distintos cuando los reguladores examinan los registros.
Monitoreo de transacciones inconsistente. Una regla AML que marca transacciones en efectivo de EUR 10.000 debe aplicar el mismo umbral a transferencias de token de EUR 10.000. Si el sistema de monitoreo fiat y el sistema de monitoreo token no comparten configuración de umbrales y suscripciones de watchlist, una transacción que activaría una marca en un sistema pasará a través del otro. Durante examen regulatorio, esta inconsistencia es un hallazgo material, no una nota técnica al pie.
Segregación de reservas sin aplicación de ledger. MiCAR requiere que los activos de reserva que respaldan EMTs se mantengan en cuentas legal y operativamente separadas de los fondos propios del emisor. Esta es la misma obligación que el safeguarding EMD2 para e-money, pero aplicada a pasivos tokenizados. Un módulo de compliance que rastrea el saldo de reserva como un campo de reporte, en lugar de imponer segregación como restricción de ledger, no puede prevenir la mezcla. La mezcla detectada a fin de mes ya es una violación regulatoria.
La Arquitectura de Compliance Unificada
Satisfacer MiCAR sin reconstruir la pila de compliance requiere un modelo donde instrumentos tokenizados y fiat fluyan a través de las mismas primitivas de compliance, con parámetros token-específicos aplicados en la capa de política, no codificados en caminos de código separados.
Registros CDD unificados. El registro CDD de un cliente es una entidad, no una transacción. Cubre todos los instrumentos que el cliente mantiene en la institución, independientemente de si esos instrumentos son saldos fiat, tenencias token o posiciones de custodia. Cuando se añade un nuevo tipo de instrumento, como un nuevo producto stablecoin o un nuevo ART, los requisitos CDD se resuelven buscando la política aplicable para el tipo de instrumento y el nivel de riesgo del cliente. Ningún camino de código nuevo. Un nuevo registro de política.
Tubería AML compartida. El monitoreo de transacciones aplica independientemente del tipo de instrumento. El motor de screening AML recibe un evento de transacción normalizado (monto, moneda o identificador de token, contraparte, dirección, timestamp) y lo evalúa contra la misma lista de sanciones, base de datos PEP y configuración de umbrales que aplica a transacciones fiat. El identificador de token es un parámetro, no una rama en la lógica de monitoreo.
Segregación de reservas aplicada por ledger. La cuenta de reserva que respalda una emisión de stablecoin debe ser un tipo de cuenta de primera clase en el ledger, con la misma isolación estructural que reciben las cuentas de safeguarding EMD2. Las transferencias desde la cuenta de reserva a cuentas operativas están bloqueadas a menos que pasen por un workflow autorizado: el mismo workflow durable, registrado en journal, que gobierna la extracción de comisiones de cuentas de safeguarding de e-money. El compliance se impone por la arquitectura del ledger, no por una consulta de reporteo que verifica el saldo después del hecho.
El Derecho de Redención como Restricción de Ledger
El Artículo 48 de MiCAR otorga a los titulares de tokens el derecho de redimir cualquier EMT a valor nominal en cualquier momento. El emisor debe ejecutar la redención dentro de un día hábil. Esto no es una opción contractual. Es una obligación regulatoria con un plazo de settlement de 24 horas.
Para infraestructura bancaria central, la redención bajo demanda significa que el ledger debe poder ejecutar un swap token-a-fiat (disminuir el saldo token del cliente, aumentar su depósito a la vista o iniciar una transferencia fiat) dentro de un día hábil para cualquier volumen de token en cualquier momento. La cuenta de reserva debe mantener activos líquidos suficientes para cubrir la redención sin demora.
Esto crea un requisito de gestión de liquidez que retroalimenta la arquitectura de reservas. La reserva no solo debe existir y estar segregada. Debe ser inmediatamente accesible para redención. Una institución que invierte reservas EMT en instrumentos de 30 días satisface el requisito de "activos de bajo riesgo" de MiCAR Art. 36(1)(b) pero no puede cumplir el plazo de redención de 24 horas. La restricción de liquidez es tan estricta como el requisito de reserva.
Desde la perspectiva de arquitectura de workflow, la redención EMT es una operación de múltiples pasos: validar saldo token, verificar cobertura de reserva, ejecutar el débito de la cuenta token y el crédito de la cuenta fiat, actualizar el saldo de reserva, confirmar al cliente, y producir un registro de auditoría. Todos los pasos deben completarse dentro de un día hábil. Si algún paso falla, el workflow debe compensar limpiamente: el saldo token no se debita si el crédito fiat no puede ejecutarse. Un motor de ejecución durable con garantías de exactly-once provee esta propiedad estructuralmente.
Alemania, Italia y la Propuesta de Kill-Switch
Alemania e Italia han propuesto conjuntamente un mecanismo de "kill switch" de la UE para stablecoins globales no conformes: la capacidad de los reguladores europeos de bloquear o restringir tipos de token específicos que presenten riesgo sistémico o violen obligaciones de MiCAR. Esta propuesta, bajo revisión a mediados de 2026, tiene implicaciones arquitectónicas directas.
Un kill-switch requiere que la capa de compliance pueda actuar sobre una decisión de política en tiempo real: bloquear nueva emisión de token, bloquear redenciones de direcciones específicas, o bloquear transferencias por encima de umbrales definidos, sin intervención manual en cada transacción. El motor de compliance debe poder recibir una actualización de política (una nueva restricción sobre un token específico o categoría de tokens) y aplicarla inmediatamente a todas las transacciones subsecuentes.
Esta es exactamente la requisito que la lógica de compliance codificada no puede satisfacer. Si la lógica de restricción está incrustada en código de aplicación, aplicar una nueva restricción requiere un despliegue. En un entorno regulatorio donde un kill-switch puede necesitar activarse en horas, un ciclo de despliegue no es un tiempo de respuesta viable. Una política de compliance impulsada por configuración, donde una nueva restricción es un nuevo registro de política aplicado en la capa de evaluación, maneja esto sin un cambio de código.
Compromisos
Unificar fiat y token compliance a través de una arquitectura compartida tiene costos.
Complejidad del modelo de datos. Un registro CDD que cubre múltiples tipos de instrumento requiere un modelo de datos más abstracto que uno que cubre solo cuentas fiat. El parámetro de tipo de instrumento debe ser explícito a lo largo de toda la tubería de compliance: consultas de screening, reglas de scoring de riesgo, formato de registro de auditoría, y plantillas de reporteo todas necesitan parametrizarse por tipo de instrumento en lugar de asumir fiat.
Incertidumbre regulatoria. Los estándares técnicos de MiCAR no están completamente establecidos. El EBA y ESMA siguen emitiendo estándares técnicos regulatorios (RTS) que clarifican composición de reservas, procedimientos de redención, y obligaciones AML para categorías específicas de tokens. Una arquitectura de compliance construida para el texto actual de MiCAR debe diseñarse para cambio de política: las reglas se refinarán, y la implementación debe absorber esos refinamientos a través de configuración, no reescrituras de código.
Overhead de gestión de reservas. Las cuentas de reserva segregadas requieren su propia reconciliación, su propio monitoreo de liquidez, y su propio reporteo regulatorio. Para instituciones que nunca han gestionado reservas EMT, este es un alcance operativo nuevo.
Fernel Context
El motor de compliance de Fernel modela políticas CDD como registros versionados con cuatro dimensiones: jurisdicción, nivel de riesgo, tipo de verificación y profundidad. El mismo modelo de política aplica independientemente del tipo de instrumento: los requisitos CDD de un titular de euro stablecoin se resuelven por la misma lógica de evaluación de políticas que la de un titular de cuenta fiat. El screening AML acepta un evento de transacción normalizado y aplica configuración de umbrales compartida. El ledger impone segregación de reservas a través de restricciones explícitas de tipo de cuenta: las transferencias desde cuentas de reserva a cuentas operativas están bloqueadas a menos que pasen por workflows durables autorizados. Los cambios de política entran en vigor a través de actualizaciones de registros, no despliegues.
Leer más: Infraestructura de Compliance | Automatización de Debida Diligencia del Cliente | Arquitectura de Safeguarding para Instituciones de E-Money
Fuentes:
- MiCAR, Reglamento (UE) 2023/1114, Art. 36 (Requisitos de reserva para EMTs), Art. 48 (Derechos de redención), Art. 83 (Obligaciones AML para CASPs)
- Anuncio público del consorcio Qivalis: 37 bancos europeos, 15 países, Sir Howard Davies como Presidente, objetivo de lanzamiento H2 2026
- Cambridge Centre for Alternative Finance, Tokenized RWA Data Q1 2026: 27,5 mil millones USD on-chain, solo el 0,2% del valor global de stablecoins denominado en euros
- EBA, Guía de Implementación de MiCAR y Borrador de Estándares Técnicos Regulatorios (2024-2025)
- EMD2, Directiva 2009/110/CE, Art. 7-10 (Safeguarding), para comparación con obligaciones de reserva de MiCAR
- AMLD5, Directiva 2018/843, como extendida a CASPs por MiCAR Art. 83