Relatórios regulatórios: como estruturar os dados

O problema não é gerar o relatório, é provar de onde veio cada número#

Quem trabalha no setor financeiro sabe que produzir relatórios regulatórios não é a parte difícil. A parte difícil vem depois, quando o regulador, a auditoria interna ou o próprio comitê pergunta de onde saiu aquele valor, e a equipe precisa reconstruir o caminho que o número percorreu do sistema de origem até a célula final. Se essa reconstrução depende de memória, de uma planilha guardada por uma pessoa específica ou de um passo manual que ninguém documentou, o problema não é o relatório. É a estrutura de dados por trás dele.

Relatórios regulatórios são, no fim, uma promessa de fidelidade: o que você reporta ao Banco Central, à CVM ou à auditoria tem que ser exatamente o que aconteceu na operação, com o mesmo valor, na mesma data-base, reproduzível meses depois. Essa promessa exige rastreabilidade, linhagem, governança, versionamento e um fechamento controlado. Este artigo é sobre como estruturar os dados para torná-la verdadeira, e sobre onde a engenharia de dados no Azure e no Microsoft Fabric entra, junto com o Power BI, para que ela pare de depender de heroísmo individual.

Relatórios regulatórios no setor financeiro seguem uma régua diferente#

Instituições financeiras no Brasil operam sob supervisão do Banco Central, e o mercado de capitais é regulado pela CVM. Quando você lida com dados de crédito, contábeis ou de clientes, ainda entra a LGPD, a Lei nº 13.709/2018, que impõe controle sobre dado pessoal em cima de tudo o que já é exigido pela regulação prudencial. Na prática, isso significa que uma estrutura de dados desenhada só para "responder perguntas de negócio" não serve. Ela precisa responder também a perguntas de conformidade.

A diferença é concreta. Um dashboard gerencial pode arredondar e ser recalculado com a base mais recente sem que ninguém reclame. Um relatório regulatório, não. Ele tem data-base fixa, precisa bater com a contabilidade oficial da instituição e tem que sobreviver a uma pergunta feita dois anos depois. O plano contábil das instituições do sistema financeiro, o COSIF, e os envios de informações de crédito ao SCR mostram que o mesmo dado precisa ser consistente entre o que você reporta e o que exibe internamente. Se o número do relatório regulatório e o do painel de gestão divergem, alguém vai ter que explicar por quê, e "são fontes diferentes" costuma ser o começo de um problema maior.

Estruture em camadas: bronze, prata e ouro#

A forma mais honesta de organizar dados para reporte regulatório é a arquitetura em camadas, o padrão medalhão de bronze, prata e ouro. Não é moda, é separação de responsabilidades, e cada camada resolve um tipo de pergunta que o regulador ou o auditor vão fazer.

Camada	O que guarda	Papel no reporte regulatório
Bronze	Cópia fiel do dado de origem, sem transformação, com data e hora de carga	Prova de que o dado bruto existiu daquela forma; base para reprocessar
Prata	Dado limpo, padronizado, com chaves conciliadas e regras de qualidade aplicadas	Camada onde a linhagem das transformações fica explícita e testável
Ouro	Dado agregado e modelado no formato exigido pelo relatório e pelos painéis	O que alimenta o Power BI e o arquivo entregue ao regulador

A camada bronze é a que a maioria das equipes pula, e é a mais importante para auditoria. Guardar o dado exatamente como chegou do core bancário ou do ERP, com carimbo de data e hora, permite responder "o dado de origem mudou depois?" sem depender do fornecedor. Sem bronze, você não tem um ponto de verdade imutável, e qualquer divergência vira discussão de opinião.

A camada prata é onde a mágica suja acontece de forma controlada: deduplicação, conciliação de cadastro, aplicação de regras de negócio, tratamento de nulo. Cada uma dessas transformações precisa estar em código versionado, não em cliques manuais. É aqui que a diferença entre um processo auditável e um frágil fica visível. Se você precisa de engenharia de dados para nada, é para garantir que essa camada seja determinística: dado igual na entrada, resultado igual na saída, sempre.

A camada ouro é a que o negócio enxerga. É dela que sai tanto o arquivo regulatório quanto o modelo que o Power BI consome, e o ponto crítico é que as duas saídas venham da mesma fonte. Reporte e painel gerencial precisam nascer do mesmo número, ou você vai gastar reunião explicando divergência que nunca deveria ter existido.

Linhagem e rastreabilidade não são o mesmo item#

Muita gente usa os dois termos como sinônimo, e não são. Vale separar, porque cada um responde a uma pergunta diferente do auditor.

Rastreabilidade é a capacidade de pegar um número final e voltar até o registro de origem que o gerou. É a resposta para "este saldo de R$ 12,4 milhões, quais contratos o compõem?". Linhagem é o mapa das transformações: quais tabelas, quais regras e quais colunas participaram do caminho entre a origem e o resultado. É a resposta para "que lógica foi aplicada entre o dado bruto e este saldo?".

No ecossistema Microsoft, a linhagem e a governança se apoiam no Microsoft Purview, que cataloga os ativos de dados e mapeia as dependências entre eles. Isso não substitui a disciplina de engenharia, mas dá uma visão navegável de onde cada dado vive e por onde ele passa. Combinado com o versionamento do código de transformação, você mostra não só o caminho atual, mas o que existia na data-base de um reporte antigo. Essa é a diferença entre dizer "hoje funciona assim" e provar "em março funcionava assim". A segunda é a que salva a instituição em uma fiscalização.

Versionamento: o dado de ontem tem que continuar sendo o dado de ontem#

Aqui está o erro mais comum e mais caro. A equipe entrega o relatório da data-base de setembro, o mês vira, o cadastro de um cliente é corrigido, e quando alguém tenta reproduzir o número de setembro, ele mudou. Não porque estava errado, mas porque a base é viva e ninguém congelou o estado dela.

Estruturar dado para reporte regulatório exige versionamento em duas dimensões. A primeira é o versionamento do dado: manter o histórico do que cada registro valia em cada data-base, tipicamente com dimensões que registram vigência, o que na modelagem dimensional se chama de dimensão de mudança lenta. A segunda é o versionamento da lógica: o código que transformou o dado precisa estar em controle de versão, com a mesma disciplina de qualquer software sério, para que você saiba qual regra rodou em qual fechamento.

Sem versionamento	Com versionamento
Reprocessar setembro dá um número diferente	Reprocessar setembro dá o mesmo número, sempre
"Foi a Ana que fez, mas ela saiu"	Qualquer pessoa reproduz o resultado a partir do código
Correção no cadastro reescreve o passado	Correção entra com nova vigência, o passado fica intacto
Divergência vira investigação de dias	Divergência é explicada pela linhagem em minutos

O versionamento transforma o fechamento de um evento tenso em um processo repetível, e processo repetível reduz custo de auditoria, porque o auditor confia em controle, não em pessoas.

O fechamento precisa ser um estado, não uma correria#

Fechamento regulatório costuma ser vivido como maratona de fim de mês. Deveria ser um estado formal do dado. A ideia é simples: há um momento em que a data-base é declarada fechada, e a partir dali aquele conjunto vira imutável para efeito de reporte. Qualquer ajuste posterior não apaga o que foi fechado, entra como um novo evento com sua própria data.

Na prática, um bom desenho de fechamento tem alguns componentes que não podem faltar:

• Um marco explícito de corte, com data-base e horário definidos, registrado no próprio pipeline.
• Validações automáticas que rodam antes de liberar o fechamento, comparando totais contra a contabilidade e checando regras de completude.
• Um registro de aprovação, com quem revisou e quando, para que o fechamento tenha responsável.
• Uma trava que impede reescrita silenciosa do período já fechado.

Sem esses componentes, o fechamento depende de alguém lembrar de conferir. Com eles, vira um portão que só abre quando os testes passam. É aqui que a governança de dados deixa de ser documento de prateleira e vira controle operacional de verdade.

Onde o Fabric e o Azure entram, e onde o Power BI entra#

O Microsoft Fabric, anunciado em 2023, junta em uma plataforma só a engenharia de dados, o armazenamento e o Power BI, o que reduz o número de pontos de integração onde a linhagem costuma se perder. O consumo no Fabric é medido em Capacity Units, as CUs, o que importa para o planejamento de custo do fechamento, já que os picos de processamento de fim de mês concentram uso. Vale entender essa dinâmica antes de dimensionar a capacidade, e o tema está detalhado no nosso guia sobre o Microsoft Fabric.

A divisão de trabalho saudável é a seguinte. A engenharia de dados, seja em Azure com Data Factory e Synapse, seja dentro do Fabric, constrói e mantém as camadas bronze, prata e ouro, com linhagem e versionamento embutidos no código. O Power BI fica na ponta, consumindo a camada ouro e servindo tanto o painel de gestão quanto a base do arquivo regulatório. O que ele não deve fazer é virar a camada de transformação pesada: cálculo regulatório enterrado em medida DAX, sem versionamento e sem teste, é dívida técnica esperando a hora de aparecer numa fiscalização. Se a lógica é regulatória, ela vive na engenharia, não no relatório.

Isso não diminui o papel do Power BI. Ao contrário, libera a ferramenta para o que ela faz bem: apresentar, conciliar e dar transparência. Um modelo semântico bem desenhado, com medidas limpas, ajuda a conciliar o reporte com a gestão, porque as duas visões partem do mesmo modelo.

LGPD e reporte convivem no mesmo pipeline#

Não dá para falar de estrutura de dados no financeiro sem falar de dado pessoal. O mesmo pipeline que gera o reporte carrega CPF, dados de renda e comportamento de crédito, e a LGPD exige controle sobre esse dado. A boa notícia é que uma estrutura bem feita para reporte já resolve boa parte do que a LGPD pede: você sabe onde o dado está, por onde ele passa e quem acessou. Linhagem serve para conformidade regulatória e para privacidade ao mesmo tempo.

O que muda é a necessidade de controle de acesso por camada e de mascaramento onde o dado pessoal não é necessário. O detalhamento contratual pode precisar do CPF, o painel gerencial agregado, não. Tratamos essa interseção entre governança e privacidade no artigo sobre governança de dados e LGPD no Power BI, que vale a leitura para quem está estruturando o ambiente do zero.

Perguntas frequentes#

Preciso da camada bronze mesmo se meu sistema de origem já guarda histórico?

Sim. Confiar no histórico do sistema de origem significa terceirizar a sua prova de auditoria para um fornecedor que pode mudar a base, corrigir dados retroativamente ou ser desligado. A camada bronze é a sua cópia imutável, sob seu controle, com carimbo de data de carga. Ela é o que garante que você consegue reprocessar um fechamento antigo mesmo que o sistema de origem tenha mudado.

Posso fazer os cálculos regulatórios direto no Power BI com DAX?

Não é recomendado para a lógica regulatória pesada. Cálculo que precisa ser versionado, testado e reproduzido meses depois deve viver na camada de engenharia, com controle de versão e testes automatizados. Medida DAX sem versionamento vira uma caixa-preta difícil de auditar. Use o Power BI na ponta, sobre a camada ouro.

Fabric ou Azure tradicional para relatórios regulatórios?

Depende da maturidade e do volume. O Fabric concentra engenharia, armazenamento e Power BI em uma plataforma só, o que reduz pontos de integração e simplifica a linhagem, com custo medido em Capacity Units. O Azure com Data Factory e Synapse dá mais controle granular e faz sentido em ambientes que já têm esse investimento. As duas entregam rastreabilidade e versionamento se a disciplina de engenharia estiver presente. A ferramenta não substitui o processo.

Como provo a linhagem em uma fiscalização?

Com a combinação de três coisas: o catálogo de dados, que no ecossistema Microsoft se apoia no Microsoft Purview; o código de transformação versionado, que mostra a regra aplicada em cada data-base; e a camada bronze, que preserva o dado de origem. Juntas, elas permitem reconstruir o caminho de qualquer número final até o registro que o gerou, na versão que existia na época.

Qual é o erro mais comum ao estruturar esses dados?

Tratar o fechamento como um evento manual em vez de um estado controlado do dado. Quando ele depende de alguém lembrar de rodar uma conferência ou de não mexer em uma planilha, o processo é frágil por construção. O fechamento precisa ser um portão automático que só libera quando as validações passam e que trava a reescrita do período já fechado.

Estrutura primeiro, relatório depois#

O relatório regulatório é a saída visível de algo que acontece muito antes: a decisão de estruturar o dado com rastreabilidade, linhagem, versionamento e um fechamento controlado. Instituições que investem nessa estrutura param de tratar cada fechamento como corrida contra o relógio e passam a tratar auditoria como consulta, não como investigação. A régua do setor financeiro, com a supervisão do Banco Central e a exigência da LGPD, não deixa espaço para improviso, e a mesma estrutura que satisfaz o regulador é a que dá confiança ao negócio.

Se a sua instituição ainda reconstrói número na mão toda vez que alguém pergunta de onde ele veio, esse é o sinal de que a estrutura precisa de atenção. Se esse é o seu caso, fale com a gente e vamos desenhar juntos o caminho do dado de origem até o relatório, com a rastreabilidade que uma fiscalização exige.