Tokenização de ativos e garantias entra na infraestrutura de crédito — o que muda na auditoria e nos controles

A nova fase do projeto de moeda digital do Banco Central foca em tokenizar ativos e garantias para crédito. O que isso exige de controles e auditoria.

Resumo

• A tokenização de ativos não cria uma classe contábil nova por si só: um recebível, um título público ou uma cota continuam sendo o que são sob as normas vigentes (CPC 48 / IFRS 9, CPC 11, CPC 04). O que muda é a camada de registro, transferência e oneração desse ativo, e é justamente essa camada que passa a concentrar o risco de auditoria.

• O ganho prometido — verificar garantias de forma instantânea e evitar a dupla oneração de um mesmo ativo em operações de crédito distintas — depende inteiramente da confiabilidade do registro tokenizado e da sua conciliação com o ativo subjacente. Sem essa conciliação, o token é apenas mais um espelho que pode divergir da realidade.

• Para a auditoria, o foco se desloca para controles de tecnologia (acesso, integridade, segregação de funções), para a prova de existência e titularidade do ativo on-chain e off-chain, e para a verificação de que ônus e garantias estão corretamente refletidos — um terreno em que relatórios de asseguração sobre controles de prestadores de serviço (ISAE 3402) ganham peso.

• A entrada de uma infraestrutura pública de tokenização de garantias é também um teste de governança: políticas de custódia, gestão de chaves criptográficas, plano de contingência e trilha de auditoria precisam existir antes de o ativo ser tokenizado, não depois de um incidente.

O que está realmente em jogo do ponto de vista técnico

É tentador tratar tokenização como assunto de tecnologia, mas o cerne é de auditoria e contabilidade. Uma garantia só reduz risco de crédito — e só justifica menor provisão ou melhor classificação de estágio sob o modelo de perdas esperadas — se ela for, de fato, existente, válida, exequível e livre de oneração concorrente. A promessa da tokenização é tornar essas quatro condições verificáveis em tempo quase real. O risco é que a representação digital crie uma falsa sensação de certeza: um token bem-formado, com aparência impecável, referenciado a um ativo que não existe, está duplamente onerado ou cuja titularidade é contestável.

Por isso, o ponto de partida da asseguração não é a tecnologia, e sim a âncora entre o token e o ativo subjacente. Quando o ativo já nasce digital e nativo na infraestrutura — um título público escritural, por exemplo —, a distância entre o token e o ativo é curta, e o registro pode ser, ele próprio, a fonte de existência. Quando o ativo é "espelhado" — um recebível, um imóvel, um bem físico tokenizado por referência —, surge uma camada de custódia e de conciliação que precisa ser auditada com o mesmo rigor de qualquer ativo sob guarda de terceiros. A norma contábil não desaparece: a baixa de um ativo financeiro continua subordinada à transferência substancial de riscos e benefícios (CPC 48 / IFRS 9), e o mero registro de um token não decide, sozinho, se houve desreconhecimento.

A segunda frente é a dos controles de tecnologia da informação. Em um ambiente tokenizado, a segregação de funções migra de perfis de sistema para a gestão de chaves criptográficas e para o permissionamento de quem pode emitir, transferir, travar ou resgatar tokens. A integridade deixa de depender só de um banco de dados central e passa a depender também da lógica de contratos inteligentes — código que executa regras automaticamente e que, se contiver erro ou porta dos fundos, propaga a falha em escala. Revisar essa lógica, testar cenários de exceção e avaliar o plano de contingência (o que acontece se uma chave for perdida ou comprometida) passa a integrar o escopo de qualquer trabalho sério de asseguração.

Implicações práticas para instituições e companhias

Para instituições financeiras que pretendem aceitar garantias tokenizadas, a primeira implicação é de política de crédito: o normativo interno precisa definir quais tokens são elegíveis, sob quais infraestruturas, com qual padrão de conciliação e com qual tratamento em caso de divergência. Aceitar uma garantia tokenizada sem essa moldura é transferir para o ambiente operacional uma decisão que deveria ser de governança. A segunda implicação é de mensuração: o efeito de uma garantia sobre a perda esperada depende de poder executá-la; uma garantia cuja exequibilidade jurídica em ambiente tokenizado ainda não foi testada não deveria ser tratada, no modelo, como se fosse líquida e certa.

Para companhias que tokenizam seus próprios ativos como funding, o cuidado é simétrico. A tokenização de recebíveis, por exemplo, levanta de imediato a questão do desreconhecimento: a operação transferiu de fato os riscos e benefícios, ou a companhia reteve exposição relevante — e, portanto, o ativo (e o passivo correspondente) deve permanecer no balanço? A resposta não está no token, está na substância econômica do arranjo. Divulgar adequadamente a natureza dessas operações, os riscos retidos e os critérios de baixa é parte essencial das demonstrações, e tende a atrair atenção do auditor justamente por ser área de julgamento.

Há ainda a dimensão da prestação de serviço por terceiros. Boa parte da infraestrutura de tokenização e custódia digital é operada por prestadores especializados. Quando controles relevantes para as demonstrações de uma entidade rodam em sistemas de um terceiro, o caminho técnico consagrado é o relatório de asseguração sobre controles de organizações prestadoras de serviço (no padrão ISAE 3402 / SOC). Esse relatório permite que o auditor da entidade usuária se apoie em uma avaliação independente do desenho e da eficácia operacional dos controles do prestador, em vez de auditar do zero uma caixa-preta tecnológica. Exigir esse tipo de asseguração do provedor deixa de ser um luxo e passa a ser pré-condição de governança.

Um caso anonimizado

Considere uma instituição de crédito de médio porte que decide aceitar cotas de um fundo tokenizadas como garantia em uma linha para clientes corporativos. No piloto, tudo funciona: a trava da garantia é registrada no momento da concessão e a verificação parece instantânea. Meses depois, na revisão de provisões, a auditoria pede a conciliação entre os tokens travados e os ativos efetivamente bloqueados na custódia do fundo. Descobre-se que, para uma parcela das operações, a trava on-chain havia sido registrada, mas o bloqueio correspondente na custódia tradicional do ativo não fora efetivado por uma falha de integração — os dois mundos não conversavam. A garantia existia no token e não existia no ativo. O efeito prático foi a necessidade de reclassificar exposições, reforçar provisão e, sobretudo, reescrever o controle de conciliação como rotina diária automatizada, não como verificação pontual. Nenhum dos sistemas estava "errado" isoladamente; faltava a ponte auditável entre eles. É exatamente nessa ponte que mora o risco — e o valor — da tokenização.

Como a MERC pode ajudar

A MERC Audit & Advisory atua na interseção entre norma contábil, controles e tecnologia que esse tema exige. Na frente de auditoria, avaliamos a existência, titularidade e oneração de ativos tokenizados, a adequação do tratamento de desreconhecimento sob o CPC 48 / IFRS 9 e a suficiência das divulgações sobre operações de tokenização e garantias. Na frente de advisory, ajudamos instituições e companhias a desenhar o controle de conciliação on-chain × off-chain, a política de elegibilidade de garantias tokenizadas e o modelo de governança de chaves e contratos inteligentes antes de a operação escalar. E, quando a infraestrutura é operada por terceiros, estruturamos a exigência e a leitura crítica de relatórios de asseguração sobre controles de prestadores de serviço, de modo que a confiança na infraestrutura seja baseada em evidência independente — não em promessa de fornecedor. Como auditoria especializada no mercado financeiro, conectamos essas peças à realidade regulatória e contábil brasileira, e não a um modelo importado que ignora as particularidades do nosso arcabouço.

Perguntas frequentes

A tokenização de um ativo muda a forma de contabilizá-lo?

Não automaticamente. A natureza contábil do ativo subjacente permanece regida pelas normas aplicáveis (CPC 48 / IFRS 9 para instrumentos financeiros, CPC 04 para intangíveis, CPC 11 para determinados arranjos, entre outras). A tokenização altera a camada de registro, transferência e oneração — e é essa camada que muda o perfil de risco e a abordagem de auditoria, não necessariamente a classificação contábil em si.

Uma garantia tokenizada reduz a provisão para perda esperada?

Só na medida em que seja existente, válida, exequível e livre de oneração concorrente — as mesmas condições de qualquer garantia. A vantagem da tokenização é tornar essas condições verificáveis com mais frequência; o risco é confundir a aparência impecável do token com a certeza jurídica e econômica do ativo. Garantia cuja exequibilidade em ambiente tokenizado ainda não foi testada não deve ser tratada no modelo como líquida e certa.

Como o auditor obtém conforto sobre uma infraestrutura de tokenização operada por terceiros?

O caminho técnico consagrado é o relatório de asseguração sobre controles de organizações prestadoras de serviço, no padrão ISAE 3402 / SOC. Ele permite avaliar, de forma independente, o desenho e a eficácia operacional dos controles do prestador, evitando que cada entidade usuária tenha de auditar do zero a infraestrutura. Exigir esse relatório do provedor é pré-condição de governança.

Qual é o erro mais comum nesse tema?

Tratar tokenização como assunto exclusivamente de tecnologia. O cerne é de auditoria, contabilidade e controles: a âncora entre o token e o ativo subjacente, a conciliação entre as camadas on-chain e off-chain, a gestão de chaves e a verificação de que ônus e garantias refletem a realidade. A falha quase nunca está no token isolado; está na ausência de uma ponte auditável entre o registro digital e o ativo real.

Baixar PDF gratuito →