Ledger11 min de leitura

Ativos Tokenizados no Balanço: Como a Arquitetura do Ledger Muda Quando os Depósitos se Tornam Tokens

Um depósito à vista de EUR 1.000 e um depósito tokenizado de EUR 1.000 são o mesmo passivo no balanço. São instrumentos diferentes para settlement, resgate e fins de compliance. A contabilidade de partida dobrada tradicional assume que os passivos do mesmo tipo são fungíveis e intercambiáveis: dois depósitos de EUR 1.000 podem ser compensados, agregados e reportados como um único saldo de EUR 2.000 sem perda de informação. Os depósitos tokenizados quebram essa suposição. Cada token carrega propriedade rastreável, condições programáveis e um caminho de settlement on-chain que requer tratamento distinto no ledger.

27,5 bilhões de dólares em ativos reais tokenizados estão on-chain no T1 2026, um aumento de 30% em três meses. 37 bancos europeus em 15 países estão construindo um euro stablecoin em conformidade com MiCAR sob o consórcio Qivalis. Os depósitos tokenizados estão se movendo da infraestrutura comercial para a infraestrutura bancária. As decisões de design do ledger tomadas hoje determinarão se as instituições podem satisfazer os requisitos de reserva de MiCAR, produzir relatórios de balanço precisos e processar resgates sem reconciliação manual.

A Suposição de Fungibilidade na Partida Dobrada Tradicional

A contabilidade de partida dobrada tradicional trata os passivos do mesmo tipo como fungíveis. Quando um banco mantém EUR 50 milhões em depósitos à vista, os saldos individuais são agregados: o banco deve EUR 50 milhões aos depositantes coletivamente. A identidade de qual depositante tem qual saldo é rastreada no ledger do cliente, mas para fins de balanço e liquidez, os EUR 50 milhões são um único pool.

Essa fungibilidade funciona porque os depósitos à vista são legalmente homogêneos: todos os depositantes têm os mesmos direitos de resgate, a mesma taxa de juros aplicável e o mesmo tratamento regulatório. Um banco pode satisfazer a solicitação de retirada de qualquer depositante do mesmo pool de ativos de reserva.

Os depósitos tokenizados não são legalmente homogêneos. Cada token pode carregar:

Condições programáveis: um token que só pode ser resgatado após um período de bloqueio, ou apenas por uma categoria específica de destinatário, ou apenas dentro de um intervalo de valor de transação definido. Essas condições estão codificadas no contrato inteligente do token e não podem ser violadas sem que a transação falhe.
Linha de propriedade rastreável: os tokens on-chain carregam um histórico completo de transações desde a emissão até o detentor atual. A linha é pública, imutável e verificável. Para fins AML, isso é valioso. Para fins de balanço, significa que dois tokens do mesmo valor nominal podem ter diferentes perfis de risco com base em seu histórico de transações.
Finalidade de settlement on-chain: uma vez que um token é transferido on-chain, a transferência é irrevogável. Uma transferência de depósito à vista tradicional pode ser devolvida (transação R de SEPA). Uma transferência de token não pode ser revertida por meio de um mecanismo de esquema estruturado. Apenas uma nova transação compensatória iniciada pelo destinatário pode desfazê-la.

Um modelo contábil que agrega depósitos tokenizados e fiat em um único passivo perde a informação necessária para processar resgates corretamente, satisfazer os requisitos de reserva de MiCAR e produzir relatórios regulatórios precisos.

O Que o Ledger Deve Rastrear Explicitamente

Três propriedades requerem representação explícita no ledger, não como campos de metadados em contas fiat, mas como atributos de conta de primeira classe.

Tipo de token e caminho de settlement. Cada conta de depósito tokenizado deve carregar o identificador de tipo de token (MiCAR EMT, ART ou token de utilidade), o endereço on-chain, o identificador de cadeia e o modelo de settlement (atômico on-chain, fiat diferido ou híbrido). O caminho de settlement determina como o resgate é processado: um resgate puro de EMT é um queimada de token mais um crédito fiat. Um caminho híbrido pode exigir tanto operações on-chain quanto SEPA em um workflow coordenado. O ledger não pode executar o settlement correto sem saber qual caminho se aplica.

Vinculação de reserva. MiCAR exige que cada EMT em circulação seja respaldado por um ativo de reserva de valor equivalente. O ledger deve manter uma vinculação explícita entre o passivo total de token circulante e o saldo de ativo de reserva correspondente. Isso não é uma consulta de relatório executada no final do mês. É uma restrição aplicada em cada evento de emissão e resgate de token. Quando um novo token é emitido (o passivo aumenta), a conta de reserva deve receber um depósito equivalente (o ativo aumenta). Se a transferência de reserva falhar, a emissão do token deve ser revertida. Ambas as operações devem ser atômicas.

Condições programáveis como restrições de ledger. Se um token carrega uma condição de bloqueio, essa condição deve ser imposta pelo ledger, não apenas pela camada de aplicação. Uma aplicação que verifica a condição de bloqueio antes de executar uma transferência fornece uma camada de aplicação. Um ledger que rejeita transferências contra contas bloqueadas fornece uma segunda camada independente. A defesa em profundidade aplica-se aqui pela mesma razão que aplica ao isolamento multi-tenant: um bug na camada de aplicação que contorna a verificação de condições não deve corromper o registro financeiro.

O Risco de Fragmentação do Balanço

Se os depósitos tokenizados não forem devidamente segregados no ledger, surgem três problemas de balanço no momento da auditoria.

Sobreestimação de liquidez. Um banco que conta depósitos tokenizados no mesmo pool de liquidez que os depósitos à vista pode reportar uma proporção de ativos líquidos mais alta do que realmente mantém. Se 20% do pool de "depósitos à vista" são na verdade tokens bloqueados que não podem ser resgatados até que uma condição seja satisfeita, a capacidade real da instituição para cumprir com solicitações de retirada é menor do que a cifra reportada sugere. Os requisitos de resiliência operacional de DORA e o cálculo da proporção de cobertura de liquidez (LCR) do BCE sob CRR exigem ambos uma representação de liquidez precisa.

Sub-relatório de reservas. Se a instituição emitiu EUR 10 milhões em EMTs mas a reserva que os respalda é rastreada como uma reserva de liquidez de propósito geral em vez de uma reserva de EMT segregada, o requisito de reserva de MiCAR está tecnicamente satisfeito mas não verificável. A ESMA e EBA esperam que as instituições demonstrem que a reserva é dedicada ao resgate de EMT e não pode ser usada para outros fins. Uma reserva de liquidez geral não pode fornecer essa demonstração.

Tratamento incorreto de capital regulatório. Os requisitos de capital para passivos tokenizados sob CRR III (Capital Requirements Regulation) diferem dos de depósitos tradicionais, particularmente para ARTs onde a cesta subjacente pode incluir ativos voláteis. Se o ledger não distingue passivos token de passivos fiat por tipo, os insumos do cálculo de capital são incorretos.

Emissão e Resgate de Tokens como Workflows Duráveis

A emissão e resgate de tokens são processos de múltiplas etapas com diferentes requisitos de atomicidade que as transferências de um único ativo.

Emissão (cliente deposita fiat, recebe token):

Passo 1: Receber depósito fiat (SEPA Credit Transfer creditado à conta do cliente)
Passo 2: Debitar conta fiat do cliente
Passo 3: Cunhar token on-chain (transmitir transação, aguardar confirmação)
Passo 4: Creditar conta de token do cliente no ledger
Passo 5: Transferir valor equivalente para conta de reserva segregada

Os passos 3 e 4 devem ser atômicos: se a cunhagem on-chain falhar, o débito fiat do passo 2 deve ser revertido. Se o passo 5 falhar (transferência de reserva), a emissão deve ser revertida por completo. Uma execução parcial (fiat debitado, token cunhado, reserva não financiada) cria um token sem respaldo, que é uma violação de MiCAR.

Resgate (cliente devolve token, recebe fiat):

Passo 1: Receber solicitação de resgate
Passo 2: Verificar saldo de token na conta do cliente
Passo 3: Queimar token on-chain (transmitir transação, aguardar confirmação)
Passo 4: Debitar conta de token do cliente no ledger
Passo 5: Liberar valor equivalente da conta de reserva
Passo 6: Creditar conta fiat do cliente
Passo 7: Iniciar transferência de saída fiat (SEPA ou interna)

Se o passo 3 tiver sucesso mas o passo 6 falhar, o cliente queimou seu token e não recebeu nada. O caminho de compensação (re-cunhar o token e reverter a liberação de reserva) requer que a camada de orquestração execute uma compensação composta, não uma simples reversão de passo.

A execução durável provê a garantia de recuperação: cada passo é registrado em um journal antes da execução. Ao reiniciar após um bloqueio entre dois passos quaisquer, o motor reproduz o journal e completa o workflow ou executa a compensação do ponto exato de interrupção. O saldo de token e o saldo de reserva nunca estão dessincronizados por mais de um único ciclo de recuperação.

Requisitos de Reserva de MiCAR como Arquitetura de Ledger

O Artigo 36 de MiCAR exige que os emissores de EMT mantenham uma reserva de pelo menos 100% da emissão circulante em ativos com características específicas de liquidez e qualidade creditícia. A reserva deve estar segregada: mantida em uma conta dedicada em uma instituição de crédito, legalmente separada dos fundos próprios do emissor.

Esta é a mesma exigência arquitetônica que o safeguarding de EMD2, aplicada a passivos tokenizados. A restrição do ledger é idêntica: a soma de todos os passivos de token circulantes nunca deve exceder a soma dos saldos de contas de reserva. Em qualquer momento. Não no final do mês. Não após a reconciliação.

O mecanismo de aplicação é o mesmo: tipos de conta explícitos no ledger, com regras de transferência que impedem que os ativos de reserva fluam para contas operacionais exceto através de workflows de resgate autorizados e registrados em journal. Um relatório de safeguarding em tempo real (consultar as contas de reserva, consultar os saldos de token circulantes, comparar) deve mostrar excedente ou zero em qualquer instante. Um valor negativo é uma violação de MiCAR em tempo real, não uma discrepância de reconciliação que se aborde mais tarde.

Compromissos

Estender o ledger para suportar contas tokenizadas de primeira classe tem custos.

Extensão do modelo de dados. Adicionar tipo de token, endereço on-chain, identificador de cadeia e modelo de settlement como campos a nível de ledger requer mudanças de esquema e migração para sistemas existentes. Para sistemas construídos sobre bancos de dados SQL de propósito geral, a migração é uma mudança de esquema padrão. Para motores de settlement construídos para o propósito, o protocolo deve ser estendido para transportar os novos campos. Nenhuma migração é trivial em escala de produção.

Sobrecarga operacional de monitoramento on-chain. Rastrear a confirmação de settlement de tokens requer executar ou conectar-se a nós blockchain, monitorar a confirmação de transações e lidar com reorganizações de cadeia. Este é um domínio operacional novo para instituições que não operaram infraestrutura blockchain anteriormente. O uptime de nós, o manejo de bifurcações de cadeia e o monitoramento de mempool não são problemas com os quais as equipes de processamento de SEPA têm experiência.

Ambiguidade regulatória sobre composição de reservas. Os padrões técnicos regulatórios em rascunho da EBA para a composição de reservas de MiCAR não estão completamente finalizados em meados de 2026. Uma instituição que constrói infraestrutura de gestão de reservas contra o rascunho atual deve projetar para mudança de política: os tipos de ativos aceitáveis, os requisitos de diversificação e os padrões de custódia podem mudar antes da publicação do RTS final.

Fernel Context

O ledger da Fernel suporta tipos de conta explícitos, incluindo customer_emoney, safeguarding, operating e float, impostos a nível de protocolo. Estender a taxonomia de tipos de conta para incluir token_emoney e token_reserve segue o mesmo padrão: cada conta carrega um indicador de tipo que o motor valida antes de executar transferências. A restrição de vinculação de reserva, saldo total de token circulante não deve exceder saldo de reserva, é aplicada como uma verificação de saldo em tempo real, não como um relatório periódico. Os workflows duráveis acoplam os passos de emissão e resgate de tokens atomicamente, com recuperação baseada em journal para qualquer falha de workflow em curso.

Fontes:

Cambridge Centre for Alternative Finance, Tokenized RWA Data T1 2026: 27,5 bilhões de dólares on-chain, +30% em três meses
Consórcio Qivalis: 37 bancos europeus, 15 países, Sir Howard Davies como Chairman, objetivo H2 2026 de euro stablecoin em conformidade com MiCAR
MiCAR, Regulamento (UE) 2023/1114, Art. 36 (Requisitos de reserva para EMTs), Art. 48 (Direitos de resgate e prazos), Art. 56 (Gestão de reservas para ARTs)
EMD2, Diretiva 2009/110/CE, Art. 7-10 (Requisitos de safeguarding), para comparação estrutural com obrigações de reserva de token de MiCAR
CRR III (Capital Requirements Regulation III), EU 2024/1623, tratamento de capital de exposições de instrumentos tokenizados
BCE, Liquidity Coverage Ratio sob CRR, requisitos para classificação precisa de ativos líquidos
HGB §246, Proibição de compensação, requisito de reportar ativos e passivos separadamente