Como integrar o core bancário e sistemas de crédito ao Power BI

O core bancário não foi construído para ser consultado por um dashboard#

A pergunta técnica que mais chega para nós no setor financeiro é como integrar o core bancário ao Power BI sem derrubar a produção nem estourar o compliance. Ela parece uma questão de conector, mas não é. O core bancário, o sistema de crédito e o de cobrança foram desenhados para processar transação com integridade, não para responder consulta analítica sobre milhões de linhas. Quando alguém aponta um relatório direto na base de produção do core e roda uma agregação de carteira, a consulta compete com a operação, a latência sobe e, em banco, cooperativa, financeira ou fintech, isso é risco operacional, não só lentidão de BI.

Este artigo é para quem toca dados, TI ou risco em instituição financeira e precisa levar a carteira de crédito, o histórico de cobrança e o movimento do core para dentro do Power BI de forma técnica, auditável e que aguente volume. Vou ser direto sobre conectores, gateway on-premises, onde a camada de dados deve viver no Azure ou no Fabric e por que o dado sensível entra na arquitetura no primeiro dia.

A regra que resolve metade dos problemas: nunca leia da base de produção#

Antes de qualquer conector, uma decisão de arquitetura resolve boa parte dos problemas: o Power BI não deve tocar a base transacional do core. O caminho correto é extrair o dado para uma camada intermediária, uma réplica de leitura ou um data warehouse, e conectar o BI ali. Isso protege a operação, dá liberdade para historizar e reprocessar, e permite aplicar regras de negócio e de privacidade antes de o dado chegar ao relatório.

Instituições financeiras são supervisionadas pelo Banco Central do Brasil, e isso não é detalhe jurídico, é premissa de projeto. O número que aparece no dashboard de inadimplência ou de provisão precisa reconciliar com o contábil e com o que vai para o regulador. Uma camada de dados própria é onde essa reconciliação passa a ser possível, porque você controla a data-base, a regra de corte e a historização. Ler direto da produção arrisca a operação e entrega um número que ninguém consegue auditar depois.

Os conectores certos dependem de onde o dado mora#

O Power BI tem conector nativo para quase tudo que importa no financeiro, e a escolha depende menos da marca do sistema e mais de onde o dado está exposto. Poucos cores modernos deixam você consultar o banco transacional diretamente, e ainda bem. O padrão saudável é o core expor uma réplica, um staging ou uma API, e o Power BI consumir essa camada. A tabela abaixo mostra o mapa típico.

Origem no financeiro	Onde o dado costuma estar exposto	Conector típico no Power BI
Core bancário (contas, lançamentos)	Réplica de leitura em SQL Server, Oracle ou DB2	Conector do banco relacional
Sistema de crédito (carteira, safras)	Data warehouse ou staging do core de crédito	SQL Server, Azure SQL, ODBC
Cobrança e recuperação	Base do sistema de cobrança ou export	Banco relacional, arquivo, API
Cadastro e CRM	Banco do CRM ou API REST	Conector Web / OData / SQL
Contabilidade e PDD	ERP contábil	Conector do ERP ou do banco
Dados externos (bureau, Bacen)	API ou arquivo posicional	Web, pasta, ODBC

O erro comum é escolher o conector pela facilidade e não pela sustentação. Conectar via ODBC genérico num sistema legado funciona no piloto e vira dívida técnica quando o volume cresce. Desenhe a extração pensando em quem vai mantê-la rodando todo dia, o que é trabalho de engenharia de dados, não de quem monta a tela.

O gateway on-premises é a ponte entre o legado e a nuvem#

A maior parte do core bancário no Brasil ainda roda on-premises, dentro do data center da instituição, por exigência de segurança e por peso de legado. O Power BI, quando publicado no serviço, mora na nuvem. Quem faz essa ponte é o On-premises data gateway, o componente que conecta fontes de dados locais ao serviço na nuvem sem expor o banco para a internet. Ele fica dentro da rede da instituição, recebe a solicitação de atualização vinda do serviço e devolve só o resultado, por um canal cifrado.

Entender o gateway muda a forma de projetar a atualização. Alguns pontos que definem se ele vira gargalo ou ponte confiável:

• Dimensionamento importa. O gateway consome CPU e memória para comprimir e transferir dados. Em carteira grande, uma máquina subdimensionada transforma a janela de atualização num funil. Gateway em cluster dá alta disponibilidade e distribui carga.
• Rede é metade da conta. A banda entre o gateway e o serviço define quanto dado você consegue mover na janela. Extração incremental, que traz só o que mudou, alivia isso mais do que qualquer upgrade de máquina.
• Ele conecta, não transforma. O gateway não é lugar de regra de negócio. Transformação pesada fica na camada de dados, antes, senão você joga processamento para um componente que não foi feito para isso.
• Auditoria passa por ele. Como todo tráfego do on-premises para a nuvem cruza o gateway, ele é um ponto natural de controle e de log, útil no requisito regulatório de rastrear o que saiu de onde.

Volume alto de transações exige camada de dados, não consulta direta#

O financeiro é, por natureza, alto volume. Lançamento, parcela, evento de cobrança, movimentação de conta: são milhões de linhas por mês que só crescem. Aqui a decisão entre os modos de conexão do Power BI define se o projeto escala ou trava. A tabela resume o trade-off.

Modo de conexão	Como funciona	Onde faz sentido no financeiro	Cuidado
Import	Copia o dado para o modelo em memória	Carteira e safras que atualizam por janela	Volume exige atualização incremental
DirectQuery	Consulta a fonte a cada interação	Saldo ou posição que precisa ser ao vivo	Joga carga na fonte, exige base preparada
Direct Lake	Lê direto do OneLake no Fabric	Volume grande com atualidade recente	Depende de estar no Fabric e bem modelado

Para a maioria dos casos de crédito e cobrança, Import com atualização incremental é o caminho, porque a análise de carteira raramente precisa do dado do último segundo. A atualização incremental faz o Power BI reprocessar apenas as partições recentes em vez de recarregar anos de histórico todo dia, o que encurta a janela e desafoga o gateway.

Do lado da modelagem, o motor VertiPaq, que comprime os dados em memória, funciona melhor quanto menor a cardinalidade das colunas, ou seja, quanto menos valores distintos elas têm. Guardar CPF ou número de contrato em texto livre numa tabela fato de milhões de linhas destrói a compressão e a velocidade. Modelagem em estrela, chaves inteiras e medidas DAX bem escritas resolvem a maior parte da lentidão que se atribui, injustamente, ao Power BI. Se o time vai escrever muita medida de risco e de safra, seguir as boas práticas de modelagem DAX desde o início evita a conta cara do remendo em base grande.

Como integrar o core bancário ao Power BI passo a passo#

Juntando as peças, a arquitetura que sustenta um projeto de integrar core bancário Power BI em produção tem uma ordem clara. Não é a única possível, mas é a que erra menos:

1. Exponha uma réplica ou staging do core, para que a extração nunca toque a base transacional que roda a operação.
2. Construa a camada de dados, um data warehouse ou lakehouse, onde core, crédito, cobrança e cadastro são integrados, padronizados e historizados. É aqui que safra, faixa de atraso e cliente ativo passam a ter uma definição única.
3. Aplique privacidade e regra de negócio nessa camada, mascarando ou removendo dado sensível e reconciliando os números com o contábil antes de o BI encostar neles.
4. Instale e dimensione o gateway on-premises se a camada ainda estiver dentro do data center, garantindo alta disponibilidade para a janela de atualização.
5. Conecte o Power BI por Import com atualização incremental na maioria dos casos, reservando DirectQuery ou Direct Lake para o que realmente precisa de atualidade.
6. Modele em estrela e escreva as medidas de inadimplência, PDD, spread e recuperação sobre esse modelo limpo.

O que separa esse desenho do improviso é que cada camada tem uma responsabilidade só, e nenhuma delas é a base de produção do core. É o tipo de fundação que a sustentação de BI mantém no ar sem virar plantão de madrugada toda vez que a carteira cresce.

Azure e Fabric são onde a camada de dados costuma viver#

A pergunta seguinte é onde essa camada intermediária mora. No ecossistema Microsoft, os caminhos mais comuns são o Azure, com serviços como Azure SQL e Synapse, e o Microsoft Fabric, a plataforma de dados que a Microsoft anunciou em 2023 e que unifica engenharia de dados, armazenamento e Power BI num mesmo ambiente.

O ponto do Fabric que interessa ao financeiro de alto volume é o Direct Lake, um modo de conexão que lê os dados direto do OneLake, o armazenamento único do Fabric, sem importar nem consultar a origem em tempo real. Na prática, ele aproxima o desempenho do Import da atualidade do dado, o que ajuda quando a carteira é grande e precisa refletir movimentação recente. O consumo no Fabric é medido em Capacity Units, e as capacidades vão dos SKUs F2 até F2048, o que permite começar pequeno e escalar conforme o volume e o número de domínios integrados cresce.

Não há obrigação de saltar para o Fabric no dia um. Muita instituição atende bem com Power BI Pro ou PPU sobre um data warehouse no Azure. A escolha depende de volume, de atualidade e de quantos domínios serão integrados. Se você avalia esse caminho, o guia sobre Microsoft Fabric ajuda a decidir com critério, sem trocar de plataforma por moda.

Dado sensível entra na arquitetura, não é etapa final#

No financeiro, dado sensível não é um capítulo de compliance no fim do projeto, é uma restrição que molda a arquitetura desde o primeiro diagrama. A carteira de crédito, o histórico de cobrança e o cadastro são dados pessoais sob a LGPD, a Lei nº 13.709/2018, e ficam ainda mais sensíveis quando cruzados com comportamento financeiro. A regra de minimização casa direto com a decisão técnica: se o dashboard não precisa do CPF para responder à pergunta, o CPF não deve trafegar até ele. O lugar certo de mascarar ou remover essa coluna é a camada de dados, antes do gateway e do Power BI.

Do lado da visualização, o Power BI resolve boa parte do controle de acesso com a segurança em nível de linha, que filtra o que cada usuário enxerga conforme o papel dele. Um analista de cobrança de uma regional não precisa ver a carteira nacional inteira, e um gestor de produto não precisa do CPF para analisar churn. Além do acesso, instituição supervisionada precisa de rastreabilidade: quem viu, quando e o quê. Isso é trabalho contínuo de governança de dados, não um item de checklist assinado no encerramento. Um projeto de BI em Power BI que ignora esse ponto entrega velocidade hoje e passivo regulatório amanhã. Se o tema é novo para o time, vale ler antes o guia de governança de dados no Power BI e LGPD, porque no financeiro ele deixa de ser recomendação e vira requisito de arquitetura.

Perguntas frequentes#

Posso conectar o Power BI direto na base do core bancário? Tecnicamente dá, mas não deve. A base do core é transacional e roda a operação. Uma consulta analítica sobre milhões de linhas compete com a operação, sobe a latência e vira risco operacional. O caminho correto é o core expor uma réplica de leitura ou um staging, e o Power BI consumir uma camada de dados intermediária, onde você ainda ganha historização, reconciliação com o contábil e controle de privacidade.

Para que serve o gateway on-premises nesse cenário? O On-premises data gateway conecta fontes de dados locais, como o core que roda no seu data center, ao serviço do Power BI na nuvem, sem expor o banco para a internet. Ele recebe a solicitação de atualização, executa a extração dentro da rede e devolve o resultado por canal cifrado. Em carteira grande, dimensionar o gateway e usar cluster para alta disponibilidade é o que evita que a janela de atualização vire gargalo.

Como o Power BI aguenta o volume alto de transações do financeiro? Com a arquitetura certa, não com força bruta. Na maioria dos casos de crédito e cobrança, o modo Import com atualização incremental resolve, porque reprocessa só as partições recentes em vez de recarregar todo o histórico por dia. Some a isso modelagem em estrela e chaves inteiras, porque o motor VertiPaq comprime melhor colunas de baixa cardinalidade. Boa parte da lentidão atribuída ao Power BI é, na verdade, modelo mal construído.

Preciso de Azure ou de Fabric para integrar o core ao Power BI? Precisa de uma camada de dados intermediária, e ela pode viver em Azure SQL, em Synapse ou no Fabric. O Fabric interessa quando o volume é alto e a atualidade importa, porque o Direct Lake lê direto do OneLake e aproxima o desempenho do Import da atualidade do dado. O consumo é medido em Capacity Units, dos SKUs F2 ao F2048. Muita instituição, porém, atende bem com Power BI Pro ou PPU sobre um data warehouse no Azure.

Como a LGPD afeta a integração do core e dos sistemas de crédito? A LGPD, Lei nº 13.709/2018, trata carteira, cobrança e cadastro como dados pessoais, e isso entra na arquitetura, não no fim do projeto. Na prática, significa mascarar ou remover dado sensível já na camada de dados, aplicar segurança em nível de linha no Power BI e manter trilha de auditoria de quem acessou o quê. A regra de minimização é direta: dado que o dashboard não precisa não deve trafegar até ele.

Os números do BI precisam bater com o contábil e com o Banco Central? Sim, quando se trata de inadimplência, PDD e resultado. Instituição financeira é supervisionada pelo Banco Central, e o BI não substitui a contabilidade nem o reporte regulatório, ele dá visibilidade e antecipação. Divergência quase sempre vem de data-base ou de regra de corte diferente, e reconciliar isso na camada de dados faz parte do projeto. Um dashboard que produz um número diferente do oficial vira passivo, não ativo.

Para fechar#

Integrar o core bancário, o sistema de crédito e o de cobrança ao Power BI é menos sobre achar o conector certo e mais sobre desenhar as camadas certas: uma réplica que protege a produção, uma camada de dados que integra e reconcilia, um gateway bem dimensionado e um modelo que respeita o volume e a LGPD. A ferramenta é a parte fácil. O que separa o dashboard confiável do improviso que trava é a disciplina de nunca ler da produção e de tratar o dado sensível como restrição de arquitetura. Se a sua instituição precisa levar a carteira para o Power BI sem arriscar a operação nem o compliance, fale com a gente e desenhamos a arquitetura pela camada que mais dói.