MiFID II e tokenização: classificação, serviços e limites

A tokenização permite representar instrumentos financeiros por meio de um registro digital. Ações, títulos de dívida e outros produtos mantêm direitos e obrigações que determinam como podem ser emitidos e comercializados. Na União Europeia, essa natureza jurídica é o ponto de partida para entender qual regulamentação se aplica a cada token.

A MiFID II faz parte do marco que regula os instrumentos financeiros e os serviços relacionados a eles. O MiCA, por sua vez, exclui de seu âmbito os criptoativos que têm essa qualificação. Compreender a relação entre os dois marcos permite definir a emissão e os serviços da plataforma antes de levar seus requisitos ao desenvolvimento técnico.

O que determina a classificação jurídica de um token

Tokenizar um direito muda sua representação técnica, mas não elimina sua natureza jurídica. Oartigo 2 da Lei 6/2023inclui instrumentos financeiros emitidos, registrados, transferidos ou armazenados por meio de DLT. Ações, dívida, cotas de veículos de investimento e derivativos exigem a análise dos direitos concretos.

Chamar um ativo de utility token não determina sua classificação. Tampouco toda expectativa de valorização converte automaticamente um token em valor mobiliário. A análise deve documentar características, negociabilidade, direitos e estrutura da oferta conforme o marco aplicável.

Como a MiFID II e o MiCA se relacionam

Oartigo 2 do MiCAexclui os criptoativos que sejam instrumentos financeiros. Isso evita tratar o mesmo instrumento como se fosse possível escolher livremente entre MiCA e MiFID II. A exclusão do MiCA não significa isenção de outras normas.

A MiFID II regula serviços e atividades de investimento e aspectos dos mercados. O regime de prospectos, a legislação societária e outras obrigações têm seus próprios âmbitos. Por isso, dizer que uma emissão cumpre a MiFID II não basta para descrever todos os seus requisitos.

Separar instrumento, serviços e canal

• Instrumento: que direito o titular recebe e perante quem pode exigi-lo.
• Serviços: quem distribui, assessora, executa ordens, custodia ou administra.
• Oferta: a quem se dirige, em quais países e com qual documentação.
• Negociação: onde as posições podem ser transferidas e com quais permissões.

Essa separação permite atribuir responsáveis e detectar atividades que podem exigir autorização. A análise muda se um aplicativo apenas exibe informações ou se recebe ordens, recomenda produtos ou controla ativos de clientes.

Dos requisitos ao software

As restrições de transferência, as verificações de identidade e os registros de operações devem derivar do modelo jurídico. Não basta escolher uma biblioteca que se descreva como compliant. Defina o que acontece quando a elegibilidade de um investidor muda, uma verificação vence ou uma recuperação é solicitada.

Teste tanto as operações permitidas quanto as rejeitadas. Conserve evidências de configuração, versão e permissões, além de procedimentos para corrigir erros. A auditoria do código revisa seu alcance técnico; não autoriza o serviço nem valida a oferta.

Como documentar a classificação

A análise começa com documentos que permitam reconstruir a relação entre emissor e titular: condições de emissão, estatuto social quando cabível, direitos de recebimento ou de voto, vencimento, regras de transmissão e compromissos comerciais. O código ajuda a entender a operação, mas a descrição do contrato não esgota o conteúdo jurídico do produto.

Oanexo I da MiFID IIdistingue categorias de instrumentos e serviços. Uma revisão deve identificar a categoria concreta que está sendo avaliada, em vez de usar “security” como resposta suficiente. Se a conclusão for que o ativo não é um instrumento financeiro, ainda é preciso examinar se ele se enquadra no MiCA, em alguma exclusão ou em um regime diferente.

Como método de trabalho, convém registrar qual característica sustenta cada conclusão e qual mudança obrigaria a revisá-la. Acrescentar direitos econômicos, alterar o regime de resgate ou permitir novas formas de transmissão pode modificar a análise. Essa revisão não deveria ficar oculta dentro de uma atualização de software.

Exemplo de uma plataforma com funções diferentes

Imagine um projeto que exibe informações sobre uma emissão, permite enviar um pedido de subscrição e oferece um espaço onde os titulares publicam seu interesse em vender. É um exemplo de análise de escopo, não uma classificação jurídica fechada.

A ficha informativa, o recebimento de pedidos e o encontro entre compradores e vendedores devem ser examinados separadamente. É preciso determinar o que cada componente realmente faz, quem toma as decisões, como as operações são executadas e qual entidade presta o serviço. O rótulo “plataforma tecnológica” não resolve essas perguntas.

Para a equipe de desenvolvimento, o resultado deve se converter em uma especificação: quais ações a interface permite, quais exigem a intervenção de uma entidade habilitada e quais ficam fora do escopo. É mais verificável estabelecer que o sistema transmite uma instrução a um participante identificado do que prometer que um aplicativo é “MiFID compliant” sem explicar sua operação.

Evidências que o projeto deveria conservar

A documentação útil conecta requisitos a comportamento: versão das condições aceitas, data de uma verificação, entidade que autorizou uma operação e resultado registrado. Se uma transferência for rejeitada por uma restrição, o sistema deve permitir investigar qual regra estava vigente sem expor dados pessoais desnecessariamente.

Também convém definir como são tratadas reclamações, retificações e mudanças relevantes. A evidência de um teste demonstra o que ocorreu sob uma configuração específica; não garante que toda configuração futura mantenha o mesmo enquadramento. Por isso, a revisão jurídica, a gestão de mudanças e os testes de regressão precisam de pontos de contato explícitos.

O que o regime-piloto DLT oferece

Oregime pilotohabilita um marco específico para determinadas infraestruturas de negociação e liquidação, com permissões e condições. Não transforma qualquer dApp em um centro autorizado nem deve ser confundido com a simples emissão de um token.

Antes do desenvolvimento, reúna um mapa de atividades, a documentação de direitos e os responsáveis. Confronte o enquadramento com asorientações publicadas pela CNMV(o regulador espanhol do mercado de valores mobiliários) e com assessoria adequada à operação. Assim, a tecnologia implementa requisitos definidos e verificáveis.

Para concretizar o design, consulteERIR na Espanha: funções e requisitos para valores mobiliários tokenizadose como se implementa umprojeto de tokenização.