Requisitos de Relatório CARF e Diferenças na Implementação Local Explicadas

Artigo por: FinTax

Nos artigos anteriores da série CARF, discutimos e analisamos os temas “quem precisa relatar” e “onde relatar” dentro do quadro CARF. O primeiro aborda a identificação dos provedores de serviços de ativos criptográficos que devem relatar (Reporting Crypto-Asset Service Provider, RCASP), enquanto o segundo utiliza as regras do Reporting Nexus para determinar em quais jurisdições o RCASP tem obrigações de due diligence e relato. Após identificar o sujeito do relato e as jurisdições de relato, a implementação das obrigações CARF levanta uma questão mais específica: quais informações o RCASP deve declarar às autoridades competentes?

O relatório CARF exige que o RCASP identifique, com base no processo de due diligence, os usuários e respectivos controladores que devem ser relatados, e classifique e resuma as transações dos ativos criptográficos associados conforme os métodos estabelecidos. O relatório final inclui três seções: informações do RCASP, informações do usuário e informações da transação.

A OCDE fornece padrões internacionais unificados, mas cada jurisdição ainda precisa implementá-los por meio de leis e normas técnicas locais. Portanto, para entender o que o CARF "relata", é necessário retornar às regras da OCDE e também prestar atenção adicional às regras de implementação locais e como elas alteram o conteúdo final a ser declarado.

Este artigo apresenta o quadro básico das informações a serem relatadas pelo CARF, as principais diferenças na implementação local e as preparações que os RCASP podem realizar nos níveis de dados e sistemas, visando fornecer uma referência prática.

(1) O que são "ativos criptográficos relevantes" dentro do escopo do CARF

A classificação de ativos é a base do relatório de negociação. De acordo com os termos definidos pelo CARF, o termo "ativo criptográfico" refere-se a valor digital que depende de ledger distribuído ou tecnologia semelhante para validação e proteção. "Ativo criptográfico relevante (Relevant Crypto-Asset)" abrange, em princípio, todos os ativos que se enquadram na definição de ativo criptográfico, mas exclui:

• Moeda digital do banco central (CBDC);
• Produto de moeda digital específico (SEMP);
• Relatou que o provedor de serviços de ativos criptográficos determinou plenamente que os ativos criptográficos não podem ser usados para pagamento ou fins de investimento.

A análise de ativos principais como BTC e ETH geralmente é mais direta, enquanto stablecoins, NFTs, títulos tokenizados e alguns tokens utilitários exigem análise adicional.

Figura 1: Ilustração do intervalo de ajuste CARF e CRS

(2) Quais informações específicas a CARF relata? Três categorias: RCASP, usuários e transações

As informações a serem relatadas dividem-se em três categorias: informações sobre provedores de serviços de ativos criptográficos relatáveis (informações RCASP), usuários relatáveis ou pessoas relatáveis (informações do usuário) e informações sobre transações de ativos criptográficos relacionadas (informações de transação), que constituem o conteúdo completo do relatório CARF.

Informações RCASP

Informe o nome, endereço e número de identificação do prestador de serviços de ativos criptográficos *.

O número de identificação é o Número de Identificação do Contribuinte (TIN); se não houver TIN, use o código de registro da empresa ou o LEI (Global Legal Entity Identifier). Se o RCASP não tiver atribuído um número de identificação, informe apenas seu nome e endereço.

Informações do usuário

• Nome, endereço, local de residência, número de identificação do contribuinte (TIN) *, data de nascimento, local de nascimento * do usuário individual;
• Nome, endereço, residência e número de identificação fiscal (TIN) do usuário da entidade; para os controladores da entidade relatável determinados pelos procedimentos de due diligence *, inclui também o nome, endereço, residência, número de identificação fiscal (TIN), data e local de nascimento do controlador, bem como o papel como controlador.

As informações de local de nascimento do usuário individual não precisam ser relatadas, salvo disposição em contrário da lei do país onde se encontra o RCASP.

O Número de Identificação do Contribuinte (TIN) é o número de identificação atribuído pelo território de residência fiscal do usuário ou do controlador da entidade, e não pelo território da plataforma, local da transação ou origem da renda.

Se um usuário for considerado residente fiscal em múltiplas jurisdições, o relatório deve refletir cada jurisdição fiscal em que o usuário reside, bem como o respectivo TIN para cada uma, sem seleção.

A due diligence e a declaração de informações dos usuários jurídicos podem ser aprofundadas até os controladores; o CARF exige que o RCASP identifique primeiro o controlador da entidade e, em seguida, determine se esse controlador relevante é uma Pessoa Relatável (Reportable Person). O controlador da entidade incluído no escopo de relato deve atender a dois critérios simultâneos: residência fiscal e controle. Ou seja, deve ser residente fiscal em uma jurisdição relatável e exercer controle sobre a entidade — o critério central é o “direito de propriedade controladora”, que pode ser atingido por meio da detenção de uma proporção superior a determinado percentual de ações, ocupação de cargo executivo ou atuação como constituinte, fiduciário ou beneficiário de um trust, entre outros.

Informações de negociação

Para cada tipo de ativo criptográfico relevante definido pelo CARF *, deve-se relatar:

1. Nome completo do tipo de ativo criptográfico relacionado;
2. Aquisição e disposição de ativos criptográficos em moeda fiduciária: valor total pago/recebido *, número total de unidades e número de transações relacionadas;
3. Aquisição e disposição de ativos criptográficos relacionados em troca por outros ativos criptográficos relacionados: valor de mercado justo total *, número total de unidades, número de transações relacionadas;
4. Transações de pagamento no varejo a serem relatadas *: valor total de mercado justo, número total de unidades, número de transações;
5. Transferências de ativos criptográficos relevantes realizadas pelo usuário relator ou por ele realizadas: transferências não classificadas acima, detalhadas por tipo de transferência (como airdrops, rendimentos de staking, pagamentos de empréstimos, troca por bens ou serviços), indicando o valor de mercado justo total, o número total de unidades e o número de transações relacionadas;
6. Transferência para carteira externa desconhecida: valor de mercado justo total, número total de unidades.

O valor total pago/recebido refere-se ao valor líquido após a dedução das taxas de transação e é relatado na moeda fiduciária utilizada na transação. Quando envolver múltiplas moedas fiduciárias, será relatado em uma única moeda fiduciária, com conversão realizada de forma consistente a cada transação relevante. Por exemplo, utiliza-se consistentemente a taxa de câmbio à vista no momento da transação para conversão monetária.

O ponto de avaliação do valor justo de mercado total é no momento da transação e deve descontar as taxas de transação; deve ser determinado e relatado em uma única moeda fiduciária e avaliado de forma consistente a cada transação. Em relação aos métodos de avaliação, o RCASP deve priorizar os pares de negociação mantidos por si próprio; quando não houver preço interno aplicável, podem ser utilizados, por ordem de preferência, valores contábeis internos, valores fornecidos por terceiros ou sites, a última avaliação do RCASP para esse ativo ou estimativas razoáveis.

O valor de referência para constituir uma transação de pagamento a varejo que deve ser relatada é de 50.000 dólares americanos; no entanto, transferências abaixo desse valor não estão isentas de relato e devem ser consideradas na soma sob os itens “Transferências de outros ativos criptográficos relacionados para ou por usuários sujeitos a relato” e “Transferências para carteiras externas desconhecidas”.

* Se o usuário transferir ativos criptográficos para sua carteira privada ou para uma conta operada por outra plataforma, impedindo que o RCASP tenha conhecimento de sua situação de transação completa, o RCASP também deve relatar isso como uma transferência para uma carteira externa desconhecida.

* As regras exigem a agregação de todas as transações por categoria. Se o ativo criptográfico relevante for não fungível e as diferentes variantes desse ativo relevante tiverem valores distintos por unidade fixa, cada unidade deve ser considerada um tipo separado de ativo criptográfico relevante.

As regras CARF e seus comentários publicados pela OCDE fornecem um padrão internacional unificado, mas são finalmente transformadas em leis locais por cada jurisdição. As regras centrais, como a definição de ativos criptográficos relevantes, a classificação de transações e os campos de relatório, são altamente próximas dos padrões da OCDE, mas podem haver diferenças significativas em certos detalhes de implementação conforme as políticas locais.

(1) O público do relatório inclui usuários domésticos?

O quadro original do CARF da OCDE foi principalmente desenvolvido para a troca automática de informações fiscais transfronteiriças. "Jurisdição reportável" refere-se a uma jurisdição que já possui acordos de troca de informações sob o CARF e que consta da lista pública emitida pela jurisdição implementadora. Os relatórios concentram-se nos residentes fiscais de outras jurisdições reportáveis. Algumas jurisdições acrescentaram requisitos locais de relato, ou seja, os RCASP devem também relatar às autoridades fiscais locais as informações dos usuários que são residentes fiscais do país.

Por exemplo, o Reino Unido estabeleceu as obrigações de relato dos RCASP britânicos para usuários residentes fiscais britânicos e seus respectivos controladores por meio do Finance Act 2026, e as diretrizes atuais da HMRC exigem explicitamente que os RCASP coletem todas as informações dos usuários e relatem dados de residentes fiscais britânicos e de residentes fiscais de outras jurisdições participantes do CARF. A lista de jurisdições sujeitas a relato sob o CARF publicada pela Autoridade Tributária da Nova Zelândia inclui seu próprio país, portanto, residentes fiscais da Nova Zelândia também estão abrangidos pelo relato local. As diretrizes oficiais esclarecem ainda que, quando um RCASP possui simultaneamente usuários residentes e não residentes na Nova Zelândia, as informações de identidade e os dados das transações de ambos devem ser submetidos à autoridade tributária, sendo os dados dos residentes utilizados para gestão tributária interna e os dados dos não residentes trocados com as autoridades tributárias dos países de residência conforme os acordos do CARF.

Ao mesmo tempo, jurisdições como Japão e Cingapura não incluem seus residentes fiscais no âmbito do relatório CARF, adotando uma abordagem semelhante ao quadro original da OCDE. Mesmo assim, o RCASP ainda precisa realizar procedimentos de due diligence em todos os usuários, incluindo usuários locais, para identificar quais usuários estão dentro do escopo de relato; a ausência de exigências de relato local não isenta essa obrigação.

Portanto, o escopo da due diligence não é igual ao escopo do relatório final, e o escopo da troca internacional não necessariamente corresponde ao escopo exigido pela autoridade tributária local.

(2) Conversão e forma de avaliação de uma única moeda fiduciária

O valor da transação e o valor de mercado justo devem ser convertidos, conforme as regras CARF, em moeda fiduciária para relato. A determinação, por cada jurisdição, da moeda de relato adicional afetará diretamente a conversão de dados e o sistema de declaração do RCASP.

Por exemplo, o regulamento CARF emitido pela Autoridade Tributária da África do Sul (Notice 6887) especifica claramente que os valores das transações e o valor de mercado justo devem ser determinados e relatados em rand sul-africano (South African Rand). A autoridade tributária, em suas respostas às Perguntas Frequentes, abordou as cargas de conformidade e desafios práticos que plataformas de alto volume de negociação podem enfrentar, esclarecendo detalhadamente os requisitos para conversões e avaliações consistentes e contínuas. Ela destaca que o CARF não exige que o RCASP realize conversões monetárias em tempo real, não restringe fontes específicas de taxas de câmbio nem métodos de precificação para cada transação, mas permite o uso de métodos razoáveis, como processamento em lote, aplicação da taxa de câmbio ao final do dia ou médias apropriadas. A grande volume de transações, a volatilidade dos preços dos ativos e as diferenças nas fontes de dados de mercado podem ser equilibradas pela flexibilidade operacional do RCASP.

(III) O limite de valor é convertido para o padrão da moeda local?

De acordo com as regras da OCDE, as transações de pagamento ao consumidor são agregadas como categoria de transações de pagamento ao consumidor a relatar apenas quando atingirem o limiar de 50.000 dólares americanos; caso contrário, são classificadas como outros tipos de transações.

Cada jurisdição pode converter os limiares em padrões monetários locais durante a implementação da legislação local. Por exemplo, o Japão estabeleceu o limiar para transações de pagamento no varejo a serem relatadas em 5 milhões de ienes (aproximadamente 31.273 dólares americanos), o Brasil adotou o valor equivalente em reais de 50.000 dólares americanos, a UE DAC8 utiliza 50.000 dólares americanos ou seu equivalente em outra moeda, e algumas outras jurisdições mantêm o padrão original em dólares americanos.

Existem várias formas de localização dos limiares de valor para transações de pagamento no varejo, incluindo a definição de um valor fixo na moeda local ou a conversão do padrão em dólares americanos para um valor equivalente na moeda local; essa distinção afetará a classificação e a agregação de dados das transações de ativos criptográficos relevantes pelo RCASP na prática. A mesma transação pode ser classificada em categorias diferentes de transações CARF dependendo da jurisdição aplicável: em uma jurisdição A, constitui uma transação de pagamento no varejo, enquanto em uma jurisdição B é classificada como outro tipo de transferência.

(4) Diferenças detalhadas nos campos do relatório

As regras da OCDE estabelecem uniformemente os campos principais de relatório para usuários individuais, usuários entitativos e seus controladores, mas mantêm espaço para legislação local.

A nacionalidade do usuário individual não precisa ser relatada, exceto se a legislação da jurisdição onde o RCASP está localizado exigir de outra forma. Em relação ao número de identificação fiscal (TIN), se a jurisdição de residência fiscal do usuário a ser relatado ou do controlador relevante não emitir TIN, ou se a legislação local não exigir sua coleta, o TIN não precisa ser relatado. Nesse sentido, a IRAS de Cingapura permite explicitamente que, nessas circunstâncias, sejam fornecidos os códigos de motivo correspondentes conforme as regras CARF XML.

Além disso, mesmo quando exigidos, os formatos dos números de TIN variam entre as jurisdições. No Reino Unido, o número de seguro nacional (NINO) do usuário individual ou do controlador relevante, o número de registro (CRN) da empresa britânica, e o UTR da parceria ou confiança são os respectivos números de identificação fiscal.

(5) Ainda é necessário apresentar declaração se não houver informações a relatar

Se não houver nenhuma informação sobre usuários ou transações relacionadas a relatar durante um ano de relatório, o RCASP ainda precisa apresentar declaração à autoridade tributária, o que também depende das regulamentações da jurisdição onde se encontra.

O Reino Unido adota claramente o modelo sem dados, sem declaração; Cingapura exige, em princípio, a apresentação de declaração nula (nil return), ou seja, apenas as informações RCASP devem ser preenchidas, sem necessidade de incluir dados de usuários e transações. Além disso, as Perguntas Frequentes do CARF da Agência Tributária do Japão esclarecem a relação entre o valor da transação e as informações a serem relatadas: mesmo que, em determinado ano, não tenha ocorrido nenhuma transação relacionada a um contrato de transação ainda em vigor, o RCASP ainda deve apresentar um relatório anual.

(1) CARF due diligence tributária integrada ao processo KYC do usuário

Os dados AML/KYC do cliente desempenham a função de validação da justificativa da autodeclaração fiscal no CARF, constituindo assim a base fundamental para a diligência devida realizada pelo RCASP. Ao cumprir as obrigações AML/KYC, o RCASP geralmente já possui informações como nome, endereço e comprovante de identidade de indivíduos, bem como dados de registro, estrutura de propriedade e beneficiários finais de entidades — esses dados não precisam ser coletados novamente. Para fins de relatório, o CARF também se concentra em aspectos como jurisdição de residência fiscal, TIN, se os controladores de entidades relacionadas são considerados pessoas reportáveis e a validade da autodeclaração fiscal. Com base nas informações de estrutura de propriedade e beneficiários já coletadas no KYC, o RCASP deve ainda avaliar se essas pessoas atendem às definições de “controlador de entidade” e “pessoa reportável”. Dado o parcial sobreposição entre os dados KYC e os dados CARF, ambos devem ser tratados como dados compartilhados com julgamentos distintos; na prática, as empresas devem adicionar um nível adicional de requisitos de dados CARF ao framework KYC existente, em vez de criar um sistema totalmente separado de clientes.

(2) Estabelecer um mecanismo unificado de conversão e avaliação em moeda fiduciária

Na integração e relatórios de informações de negociação, a unidade monetária utilizada afeta processos como a conversão do volume de negociação, a avaliação do valor de mercado justo e a classificação dos tipos de transação; os requisitos de localização relacionados têm um grande impacto no design do sistema de RCASP global. O RCASP deve, pelo menos, armazenar a moeda original da transação, o valor da transação, a taxa de câmbio no momento da transação, bem como o valor convertido para relatório, a moeda e o tempo e método de avaliação, e não apenas o resultado convertido. Mesmo que uma jurisdição atualize suas políticas exigindo relatórios em moeda local, o RCASP deve ser capaz de gerar relatórios compatíveis a partir dos dados subjacentes da transação.

(III) Aperfeiçoar o sistema de regras de localização da CARF

Embora o OECD CARF possa servir como padrão unificado de dados básicos, as diferenças de implementação local mencionadas neste artigo demonstram que a lógica final de declaração ainda se baseia em jurisdições específicas. O RCASP precisa identificar em qual jurisdição gera e cumpre suas obrigações de conformidade com o CARF e confirmar se o escopo de relatório inclui residentes fiscais locais, quais jurisdições relatáveis estão incluídas na publicação local, se campos opcionais como local de nascimento do usuário individual precisam ser submetidos e se é necessário apresentar declaração nula quando não houver informações relatáveis. As diferenças nas políticas locais também se manifestam na forma dos números de identificação fiscal. Os campos de relatório finais devem ser determinados com base na legislação e nas normas técnicas locais do RCASP e da jurisdição onde o usuário está localizado; tais diferenças não podem ser tratadas apenas por meio de um conjunto único de regras.

O conteúdo de um relatório anual CARF baseia-se em uma série de pressupostos anteriores, o que significa que o RCASP não pode começar a se preparar apenas na véspera do prazo de apresentação, mas sim integrar a conformidade CARF nas cadeias operacionais, como gestão de clientes, processos de KYC e sistemas de negociação. O CARF global já está entrando progressivamente na fase de legislação e execução locais, e o padrão unificado construído pela OCDE inevitavelmente continuará a se diversificar. Para provedores de serviços de criptomoeda com operações transfronteiriças, os mesmos dados de usuários e transações precisam ser configurados separadamente de acordo com as regras nacionais de cada jurisdição envolvida na declaração. A capacidade de concluir antecipadamente o mapeamento das regras locais e dos dados do sistema terá um impacto direto na precisão e estabilidade da declaração CARF subsequente.