Compliance10 min de leitura

MiCAR, Stablecoins e a Camada de Compliance: O Que a Infraestrutura Bancária Central Deve Lidar até H2 2026

MiCAR impõe requisitos de reserva, obrigações de resgate e deveres de monitoramento de transações sobre emissores de stablecoins e prestadores de serviços de criptoativos. Essas não são regras de mesa de negociação. São requisitos de arquitetura de compliance que recaem diretamente sobre a infraestrutura bancária central, e a maioria dos módulos de compliance construídos para depósitos fiat não está estruturalmente equipada para satisfazê-los.

O consórcio Qivalis (37 bancos europeus em 15 países, presidido por Sir Howard Davies) visa H2 2026 para um euro stablecoin em conformidade com MiCAR. Apenas 0,2% das stablecoins globais estão denominadas em euros hoje. Quando isso mudar, a carga de compliance recairá sobre as instituições que emitem e custodiam o token. A decisão de infraestrutura não é se cumprir MiCAR. É se a arquitetura de compliance pode satisfazer os requisitos de MiCAR sem uma reconstrução completa.

O Que MiCAR Realmente Exige

MiCAR (Regulamento UE 2023/1114, plenamente exigível desde junho de 2024) introduz duas categorias regulatórias distintas relevantes para a banca central:

E-Money Tokens (EMTs) são tokens que mantêm um valor estável por referência a uma única moeda oficial. Um stablecoin denominado em euros emitido por um banco é um EMT. O emissor deve manter uma cobertura de reserva de 100% em ativos líquidos de alta qualidade, mantê-los em uma conta segregada separada dos fundos operacionais, e resgatar qualquer token a valor nominal sob demanda dentro de um dia útil.

Asset-Referenced Tokens (ARTs) referenciam uma cesta de ativos: moedas, commodities ou outros tokens. O requisito de reserva é de pelo menos 2% da média de emissão circulante, também segregado.

Para ambos os tipos de token, MiCAR exige monitoramento contínuo de transações sob as mesmas obrigações AML dos instrumentos fiat. O Artigo 83 estende explicitamente as obrigações AMLD5/6 a prestadores de serviços de criptoativos e emissores. Um emissor de euro stablecoin deve rastrear transações de token contra listas de sanções, aplicar CDD a titulares de tokens, e manter trilhas de auditoria para movimentações de tokens, usando os mesmos padrões legais que se aplicam a SEPA Credit Transfers.

A carga de compliance não é aditiva. É estruturalmente nova.

Onde os Módulos de Compliance Existentes Falham

A maioria das arquiteturas de compliance de banca central opera com uma separação clara: CDD fiat é tratada por um pipeline (verificação de identidade, triagem AML, avaliação de políticas CDD), e qualquer exposição cripto passa por um processo separado, muitas vezes operado manualmente. Essa separação fazia sentido quando a atividade cripto era marginal e os instrumentos token não eram legalmente equivalentes a depósitos.

Sob MiCAR, a separação cria três modos de falha concretos.

Registros CDD fragmentados. Se um cliente mantém tanto uma conta de demanda em euros quanto um euro stablecoin na mesma instituição, ele é um cliente com um único perfil de risco. Um registro CDD unificado deve cobrir ambas as exposições. Pipelines de compliance separados para fiat e instrumentos token produzem avaliações de risco separadas, armazenamento de documentos separado, e trilhas de auditoria separadas para a mesma pessoa jurídica, criando a aparência de dois sujeitos de compliance distintos quando os reguladores examinam os registros.

Monitoramento de transações inconsistente. Uma regra AML que sinaliza transações em espécie de EUR 10.000 deve aplicar o mesmo limiar a transferências de token de EUR 10.000. Se o sistema de monitoramento fiat e o sistema de monitoramento token não compartilham configuração de limites e assinaturas de watchlist, uma transação que dispararia um sinal em um sistema passará pelo outro. Durante exame regulatório, essa inconsistência é uma constatação material, não uma nota técnica.

Segregação de reservas sem aplicação de ledger. MiCAR exige que os ativos de reserva que respaldam EMTs sejam mantidos em contas legal e operacionalmente separadas dos fundos próprios do emissor. Esta é a mesma obrigação que o safeguarding EMD2 para e-money, mas aplicada a passivos tokenizados. Um módulo de compliance que rastreia o saldo de reserva como um campo de relatório, em vez de impor segregação como restrição de ledger, não pode prevenir a mistura. A mistura detectada no final do mês já é uma violação regulatória.

A Arquitetura de Compliance Unificada

Satisfazer MiCAR sem reconstruir a pilha de compliance requer um modelo em que instrumentos tokenizados e fiat fluam através das mesmas primitivas de compliance, com parâmetros token-específicos aplicados na camada de política, não codificados em caminhos de código separados.

Registros CDD unificados. O registro CDD de um cliente é uma entidade, não uma transação. Ele cobre todos os instrumentos que o cliente mantém na instituição, independentemente de esses instrumentos serem saldos fiat, posições token ou posições de custódia. Quando um novo tipo de instrumento é adicionado, como um novo produto stablecoin ou um novo ART, os requisitos CDD são resolvidos consultando a política aplicável para o tipo de instrumento e o nível de risco do cliente. Nenhum caminho de código novo. Um novo registro de política.

Pipeline AML compartilhado. O monitoramento de transações aplica-se independentemente do tipo de instrumento. O motor de triagem AML recebe um evento de transação normalizado (montante, moeda ou identificador de token, contraparte, direção, timestamp) e o avalia contra a mesma lista de sanções, base de dados PEP e configuração de limites que se aplica a transações fiat. O identificador de token é um parâmetro, não um ramo na lógica de monitoramento.

Segregação de reservas aplicada por ledger. A conta de reserva que respalda uma emissão de stablecoin deve ser um tipo de conta de primeira classe no ledger, com a mesma isolamento estrutural que recebem as contas de safeguarding EMD2. As transferências da conta de reserva para contas operacionais são bloqueadas a menos que passem por um workflow autorizado: o mesmo workflow durável, registrado em journal, que governa a extração de taxas de contas de safeguarding de e-money. O compliance é imposto pela arquitetura do ledger, não por uma consulta de relatório que verifica o saldo após o fato.

O Direito de Resgate como Restrição de Ledger

O Artigo 48 de MiCAR concede aos titulares de tokens o direito de resgatar qualquer EMT a valor nominal a qualquer momento. O emissor deve executar o resgate dentro de um dia útil. Isso não é uma opção contratual. É uma obrigação regulatória com um prazo de settlement de 24 horas.

Para infraestrutura bancária central, o resgate sob demanda significa que o ledger deve poder executar um swap token-para-fiat (diminuir o saldo token do cliente, aumentar seu depósito à vista ou iniciar uma transferência fiat) dentro de um dia útil para qualquer volume de token a qualquer momento. A conta de reserva deve manter ativos líquidos suficientes para cobrir o resgate sem atraso.

Isso cria um requisito de gestão de liquidez que retroalimenta a arquitetura de reservas. A reserva não apenas deve existir e estar segregada. Deve ser imediatamente acessível para resgate. Uma instituição que investe reservas EMT em instrumentos de 30 dias satisfaz o requisito de "ativos de baixo risco" de MiCAR Art. 36(1)(b), mas não pode cumprir o prazo de resgate de 24 horas. A restrição de liquidez é tão estrita quanto o requisito de reserva.

Da perspectiva da arquitetura de workflow, o resgate EMT é uma operação de múltiplas etapas: validar saldo token, verificar cobertura de reserva, executar o débito da conta token e o crédito da conta fiat, atualizar o saldo de reserva, confirmar ao cliente, e produzir um registro de auditoria. Todas as etapas devem completar-se dentro de um dia útil. Se alguma etapa falhar, o workflow deve compensar de forma limpa: o saldo token não é debitado se o crédito fiat não puder executar. Um motor de execução durável com garantias de exactly-once provê essa propriedade estruturalmente.

Alemanha, Itália e a Proposta de Kill-Switch

A Alemanha e a Itália propuseram conjuntamente um mecanismo de "kill switch" da UE para stablecoins globais não conformes: a capacidade dos reguladores europeus de bloquear ou restringir tipos de token específicos que apresentem risco sistêmico ou violem obrigações de MiCAR. Essa proposta, em revisão em meados de 2026, tem implicações arquitetônicas diretas.

Um kill-switch exige que a camada de compliance possa agir sobre uma decisão de política em tempo real: bloquear nova emissão de token, bloquear resgates de endereços específicos, ou bloquear transferências acima de limites definidos, sem intervenção manual em cada transação. O motor de compliance deve poder receber uma atualização de política (uma nova restrição sobre um token específico ou categoria de tokens) e aplicá-la imediatamente a todas as transações subsequentes.

Este é exatamente o requisito que a lógica de compliance codificada não pode satisfazer. Se a lógica de restrição está embutida em código de aplicação, aplicar uma nova restrição requer um deployment. Em um ambiente regulatório onde um kill-switch pode precisar ativar-se em horas, um ciclo de deployment não é um tempo de resposta viável. Uma política de compliance orientada por configuração, onde uma nova restrição é um novo registro de política aplicado na camada de avaliação, lida com isso sem uma mudança de código.

Compromissos

Unificar fiat e token compliance através de uma arquitetura compartilhada tem custos.

Complexidade do modelo de dados. Um registro CDD que cobre múltiplos tipos de instrumento requer um modelo de dados mais abstrato do que um que cobre apenas contas fiat. O parâmetro de tipo de instrumento deve ser explícito ao longo de todo o pipeline de compliance: consultas de triagem, regras de pontuação de risco, formato de registro de auditoria, e modelos de relatório todos precisam ser parametrizados por tipo de instrumento em vez de assumir fiat.

Incerteza regulatória. Os padrões técnicos de MiCAR ainda não estão completamente estabelecidos. O EBA e ESMA continuam emitindo normas técnicas regulatórias (RTS) que clarificam composição de reservas, procedimentos de resgate, e obrigações AML para categorias específicas de tokens. Uma arquitetura de compliance construída para o texto atual de MiCAR deve ser projetada para mudança de política: as regras serão refinadas, e a implementação deve absorver esses refinamentos através de configuração, não reescritas de código.

Overhead de gestão de reservas. As contas de reserva segregadas exigem sua própria reconciliação, seu próprio monitoramento de liquidez, e seu próprio relatório regulatório. Para instituições que nunca gerenciaram reservas EMT, este é um escopo operacional novo.

Fernel Context

O motor de compliance da Fernel modela políticas CDD como registros versionados com quatro dimensões: jurisdição, nível de risco, tipo de verificação e profundidade. O mesmo modelo de política aplica-se independentemente do tipo de instrumento: os requisitos CDD de um titular de euro stablecoin são resolvidos pela mesma lógica de avaliação de políticas que a de um titular de conta fiat. A triagem AML aceita um evento de transação normalizado e aplica configuração de limites compartilhada. O ledger impõe segregação de reservas através de restrições explícitas de tipo de conta: as transferências de contas de reserva para contas operacionais são bloqueadas a menos que passem por workflows duráveis autorizados. As mudanças de política entram em vigor através de atualizações de registros, não deployments.

Fontes:

MiCAR, Regulamento (UE) 2023/1114, Art. 36 (Requisitos de reserva para EMTs), Art. 48 (Direitos de resgate), Art. 83 (Obrigações AML para CASPs)
Anúncio público do consórcio Qivalis: 37 bancos europeus, 15 países, Sir Howard Davies como Chairman, objetivo de lançamento H2 2026
Cambridge Centre for Alternative Finance, Tokenized RWA Data Q1 2026: 27,5 bilhões USD on-chain, apenas 0,2% do valor global de stablecoins denominado em euros
EBA, Guia de Implementação de MiCAR e Rascunho de Normas Técnicas Regulatórias (2024-2025)
EMD2, Diretiva 2009/110/CE, Art. 7-10 (Safeguarding), para comparação com obrigações de reserva de MiCAR
AMLD5, Diretiva 2018/843, como estendida a CASPs por MiCAR Art. 83