Processamento de XML ANBIMA: erros comuns e como validar

O que é o Arquivo de Posição 5.0 e o que aconteceu com o 4.01

O Arquivo de Posição é o layout padronizado pela ANBIMA para a troca de informações sobre posições de fundos e carteiras administradas entre prestadores de serviço. Existem duas gerações. O 4.01, com tags próprias e estrutura simples, foi o padrão dominante por anos. O 5.0, baseado na mensagem ISO 20022 semt.003.001.04, existe há mais de dez anos, é usado pela Previc desde 2016 para receber informações de fundos estruturados e foi reformulado em 2024 para acomodar as classes e subclasses da Resolução CVM 175.

Desde 1º de julho de 2025, gestores e administradores devem usar exclusivamente o 5.0 para posições de fundos; o 4.01 foi descontinuado para fundos e seguiu válido, temporariamente, apenas para carteiras administradas. Dois pontos que confundem: a ANBIMA não recebe o arquivo, ela padroniza o layout e mantém o validador; o arquivo circula diretamente entre administrador, gestora, distribuidores, consultores e investidores institucionais. E o Arquivo de Posição não é o informe diário da CVM: este é enviado pelo administrador à CVM em padrão próprio, cuja versão 4.0 passou a referenciar classes e subclasses para os fundos adaptados à 175.

O arquivo de posição é uma tradução simultânea entre dois sistemas contábeis. Se o intérprete troca uma palavra, os dois lados acham que se entenderam, e a reunião termina com decisões tomadas sobre a frase errada.

Anatomia do arquivo

O 5.0 é organizado em blocos de dados agregados, cada um com campos específicos e regras próprias de obrigatoriedade e repetição.

• Paginação e detalhes gerais: número da página da mensagem, indicador de continuidade (se há continuação ou se é a última página), data, atividade, frequência de envio e base das informações.
• Prestadores: administrador, gestor e custodiante.
• Veículo: detalhes da classe, da subclasse ou da carteira administrada.
• Ativos: um bloco por tipo, com quantidade, preço, valor financeiro, ISIN, tabelas nível e campos específicos. Os tipos já formalizados incluem caixa, títulos públicos, títulos privados, debêntures, compromissadas, termo de renda fixa, ações e ativos negociados na B3, opções de ação, termo e empréstimo de ações, futuros, swaps, opções de derivativos e de moedas, forwards de moedas, imóveis e cotas de fundos, no Brasil e no exterior.
• Patrimônio: PL na moeda base do fundo ou carteira, receitas, despesas, cotas a emitir e a resgatar.

Ativos ainda não formalizados passam pelo comitê técnico do Arquivo de Posição antes de ganhar campos próprios, e o mercado recebe prazo para implementar. Até lá, a forma de preenchimento precisa ser combinada entre as partes e documentada, porque o validador não vai apontar um ativo novo preenchido em bloco errado.

Classes e subclasses: o que muda no arquivo e nas contas

A adaptação à 175 mexeu no cabeçalho e na lógica do PL. O arquivo de uma classe sem subclasses traz a identificação e o cadastro da classe, os ativos e as despesas. O arquivo de uma classe com subclasses traz, além disso, o cadastro e as despesas de cada subclasse. O arquivo da subclasse traz o cadastro da classe (opcional), o cadastro da subclasse, suas despesas e a quantidade de cotas gerenciais. As regras de nome de arquivo também foram revistas para identificar classe e subclasse.

As fórmulas de PL que a ANBIMA publicou no guia de perguntas e respostas são a referência para qualquer conciliação:

As duas fórmulas precisam dar o mesmo número. Quando não dão, a diferença está em cotas a emitir ou resgatar lançadas no nível errado, em despesa de subclasse contabilizada na classe ou em cota gerencial usada como se fosse real. Esse é o cruzamento que o validador faz e que o sistema da gestora deve refazer.

Os erros mais comuns

1. Versão errada. Arquivo 4.01 recebido para um fundo depois de julho de 2025. Além de descontinuado, ele não representa classes e subclasses.
2. CNPJ do fundo no lugar do CNPJ da classe. Na estrutura da 175, a classe é a entidade que tem carteira; os informes e o cadastro referenciam a classe, e o arquivo precisa seguir a mesma chave.
3. Subclasse sem cabeçalho próprio. Despesas e cotas da subclasse lançadas na classe, o que quebra a fórmula de PL e a cota por subclasse.
4. Cota gerencial tratada como cota real. Em classes com subclasses, a cota da classe é apenas gerencial; usá-la para PL ou para conciliar com o administrador gera divergência permanente.
5. PL que não fecha com a composição. O somatório de ativos, receitas e despesas não bate com o PL informado. O validador aponta; muitos sistemas ignoram o aviso.
6. ISIN estruturalmente válido, ativo errado. O validador checa a estrutura do ISIN, não a sua existência nem se ele representa o ativo. Um ISIN de outra série da mesma debênture passa na validação e erra o preço.
7. Tabelas nível incoerentes. Produto, lastro e tipo de negociação que não combinam entre si (um futuro classificado com lastro de renda fixa e negociação de balcão, por exemplo) desviam o ativo para o bloco errado do controle de limites.
8. Precisão numérica. Valores com mais de cinco casas decimais ou mais de treze inteiros são truncados ou rejeitados, e o truncamento silencioso gera diferenças de centavos que se acumulam.
9. Sinais e convenções. Despesas, cotas a resgatar e posições vendidas com sinal invertido em relação ao manual.
10. Datas. Data-base diferente da data de fechamento, ou arquivo de D-1 carregado como D0 em dia de feriado local.
11. Paginação. Arquivo com continuação em que a segunda página não é lida, ou indicador de última página ausente.
12. Ativos novos em blocos improvisados. Criptoativos, créditos de carbono ou estruturas no exterior preenchidos em bloco de outro tipo sem acordo documentado entre as partes.

Pipeline de validação em quatro camadas

Validar o XML é mais do que passar pelo XSD. Um pipeline que protege o controle da gestora tem quatro camadas, e o arquivo só é carregado na base de posições depois da última.

A quarta camada é o batimento propriamente dito, descrito em batimento de carteira: como conciliar ativos, PL e posições. A regra prática: um arquivo que passa nas três primeiras camadas e falha na quarta indica erro de conteúdo no administrador ou na gestora; um arquivo que falha na primeira ou na segunda não deveria nem chegar à quarta.

Para que mais o arquivo serve

Depois de validado, o mesmo arquivo alimenta o controle de enquadramento por classe, o cálculo de risco e liquidez, a cota sombra, os relatórios a investidores institucionais e, para fundos estruturados detidos por planos de previdência, o reporte à Previc. Por isso, o custo de um erro de leitura não fica na controladoria: ele se propaga para o limite apurado errado, o VaR calculado sobre a posição errada e a lâmina com composição errada. A automação dessa cadeia está em como automatizar o controle de enquadramento de carteira.

O acordo operacional com o administrador

Boa parte dos erros não é técnica; é de combinação. Um acordo escrito com cada administrador evita a maior parte deles:

• Horário de envio e canal, com política para reenvio e para arquivos corrigidos (nome, versão, data).
• Um arquivo por classe ou por subclasse, conforme a estrutura de cada fundo, com regra de nome documentada.
• Tratamento combinado para ativos ainda não formalizados no layout.
• Fonte de preço e critério de câmbio usados, para que a gestora saiba o que está comparando na camada de negócio.
• Contato responsável por corrigir o arquivo no mesmo dia, com prazo.

Checklist de processamento do XML ANBIMA

Perguntas frequentes sobre o XML ANBIMA de fundos

Este conteúdo tem finalidade informativa e não substitui a leitura das normas citadas nem a assessoria jurídica da sua instituição. Prazos, números de artigos e entendimentos das áreas técnicas foram verificados em agosto de 2026 e são revisados trimestralmente; alterações posteriores podem não estar refletidas.