Você já viu uma fintech perder meses de engenharia tentando descobrir onde, exatamente, seus dados podem estar? Não é um problema teórico. É o tipo de coisa que trava roadmap, atrasa Go-To-Market e, em casos piores, gera multas que aparecem quando a empresa menos espera.
À medida que o setor financeiro se torna cada vez mais interconectado, a soberania de dados deixou de ser um conceito jurídico abstrato para virar uma variável real de arquitetura. No Brasil, fintechs que operam com API Open Finance, processam dados financeiros em infraestrutura de terceiros ou trabalham com análise de crédito com dados bancários precisam lidar com esse tema antes de escalar.
O que significa soberania de dados para fintechs no Brasil
Soberania de dados é o princípio de que os dados de pessoas físicas e jurídicas devem estar sujeitos às leis do país onde foram coletados. Parece simples, mas quando uma fintech opera com API Open Finance Brasil, processa dados financeiros em infraestrutura de terceiros e se conecta a sistemas regulados por múltiplos órgãos, a complexidade sobe rápido.
No Brasil, as principais referências regulatórias que definem onde e como dados financeiros podem circular são:
LGPD (Lei Geral de Proteção de Dados): estabelece as bases legais para coleta, uso e armazenamento de dados pessoais. Para dados financeiros, isso significa ter uma base legal clara para cada tratamento, respeitar os direitos de titulares e documentar todo o ciclo de vida do dado. O consentimento do titular é uma dessas bases legais, e a forma como ele é coletado e gerenciado tem implicações regulatórias próprias que merecem atenção separada. Falamos sobre como funciona o consentimento do titular no Open Finance em detalhes.
Resolução Conjunta n.º 1/2020 (Open Finance): além de definir as regras de compartilhamento no ecossistema de Open Finance, ela impõe obrigações sobre como os dados podem ser tratados pelos participantes e por quem atua como proxy de licença.
CMN e Banco Central do Brasil: para dados sensíveis do sistema financeiro, como saldos, transações e histórico de crédito, há diretrizes específicas sobre armazenamento em território nacional e transferência internacional. Essas diretrizes se aplicam diretamente a qualquer fintech que use dados de crédito BACEN dentro de modelos de análise ou concessão.
A transferência internacional de dados é o ponto que mais gera dúvida. A LGPD permite isso, mas com condições: o país de destino precisa ter nível de proteção adequado, ou a operação precisa de salvaguardas contratuais específicas. Para dados financeiros, a camada regulatória do Banco Central adiciona restrições adicionais que vão além da LGPD.
Como LGPD, Open Finance e BACEN afetam a arquitetura de dados da sua fintech
Se você é data engineer ou CTO de uma fintech de crédito no Brasil, a soberania de dados afeta decisões técnicas concretas. Onde o banco de dados fica hospedado, qual região da cloud você usa, como os logs são estruturados, quem tem acesso a quê.
Uma arquitetura que ignora compliance de dados financeiros desde o início costuma ter quatro problemas:
Dados em regiões incorretas. Usar a região padrão de um provedor cloud sem verificar se ela é compatível com as obrigações regulatórias brasileiras é um erro comum. Para dados do Open Finance, a hospedagem fora de determinadas configurações pode violar as exigências do Banco Central.
Falta de rastreabilidade. Compliance requer auditoria. Se você não consegue dizer, com precisão, quem acessou quais dados, quando e por quê, você tem um problema que vai aparecer na próxima auditoria ou incidente de segurança.
Acoplamento com sistemas de terceiros não homologados. Quando uma fintech integra com um parceiro de dados ou infraestrutura sem verificar se esse parceiro está adequado às regulações brasileiras, a responsabilidade pelo dado ainda recai sobre quem coletou.
Ausência de controles por design. Controles de acesso implementados como camada adicional, e não como parte da arquitetura, são difíceis de manter e fáceis de contornar conforme o sistema cresce.
Licenciamento proxy no Open Finance: quem é responsável pelo dado depois que ele chega na sua infraestrutura
Em artigos anteriores, falamos sobre como funciona o licenciamento proxy no Open Finance e sobre o papel da infraestrutura como serviço no mercado de fintechs reguladas. A soberania de dados conecta os dois.
Quando uma empresa não regulada acessa dados do Open Finance via licenciamento proxy, ela delega parte do risco regulatório ao participante licenciado que faz a intermediação. Mas "delega" não é o mesmo que "elimina". A responsabilidade pelo dado, depois que ele chega na sua infraestrutura, é sua.
O que isso significa na prática:
- O participante licenciado (como a Belvo) garante que a coleta e o transporte do dado seguem as normas do Open Finance e da LGPD.
- A empresa que recebe o dado é responsável por como o armazena, processa e usa dali em diante.
- Qualquer integração downstream, como enviar dados para um modelo análise de crédito com dados bancários hospedado em cloud fora do Brasil, precisa ser avaliada à luz das obrigações regulatórias.
Esse modelo funciona bem quando há clareza sobre onde começa e onde termina a responsabilidade de cada parte. Contratos de uso de dados e DPAs (Data Processing Agreements) não são burocracia: são a documentação da divisão de responsabilidade.
Compliance de dados financeiros sem travar o time de engenharia
Compliance não precisa ser um bloqueio para velocidade de desenvolvimento. Mas exige que as decisões de arquitetura sejam tomadas com as obrigações regulatórias em mente desde o início.
Alguns princípios que fazem diferença:
Data minimization por padrão. Colete e armazene apenas o que você realmente usa. Além de ser uma obrigação da LGPD, dados que você não tem não podem vazar. Isso também simplifica auditorias.
Regionalização explícita na infraestrutura. Documente, de forma explícita, qual dado está em qual região e por quê. Quando o Banco Central ou a ANPD precisarem de informações, essa documentação precisa existir e ser precisa.
Controle de acesso baseado em necessidade real. O engenheiro que trabalha com modelos de risco não precisa acessar dados brutos de transação. O time de produto não precisa acessar dados de emprego não anonimizados. Acesso mínimo necessário não é uma restrição de confiança, é uma proteção para todos.
Trilha de auditoria como requisito, não como feature. Toda operação sobre dado sensível precisa gerar um log imutável com quem fez, o quê, quando e de onde. Isso é requisito regulatório e requisito de segurança ao mesmo tempo.
Revisão de terceiros antes de integrar. Antes de se conectar com um novo parceiro de dados ou infraestrutura, verifique qual é o status regulatório dele, onde os dados ficam hospedados e se o DPA que ele oferece cobre as obrigações que você tem com seus próprios clientes.
O que acontece quando a arquitetura ignora compliance desde o início
Multas da ANPD chegam a 2% do faturamento do grupo no Brasil, limitadas a R$50 milhões por infração, mas o custo financeiro direto raramente é o mais caro.
O custo real costuma aparecer como perda de confiança de parceiros institucionais, impossibilidade de fechar contratos com bancos que exigem DPAs auditados, e tempo de engenharia gasto redesenhando uma arquitetura que deveria ter sido feita corretamente na primeira vez.
Uma fintech que quer crescer no mercado financeiro brasileiro vai, em algum momento, precisar demonstrar maturidade de compliance de dados financeiros para parceiros, investidores ou reguladores. Esse momento é mais fácil de passar quando a arquitetura foi construída pensando nisso desde o início.
A Blipay, por exemplo, construiu todo o seu processo de análise de crédito com dados bancários sobre a infraestrutura do Open Finance via Belvo, aproveitando exatamente essa divisão de responsabilidade regulatória para focar no que importa para o negócio. Veja o case completo da Blipay.
Como a Belvo resolve a camada regulatória de coleta e transporte de dados
A Belvo é uma participante regulada pelo Banco Central, dentro do ecossistema de Open Finance no Brasil. Isso significa que a infraestrutura de coleta e transporte de dados financeiros que disponibilizamos já está construída para atender às exigências do Banco Central, da LGPD e das resoluções do Open Finance.
Para as empresas que usam a plataforma da Belvo, isso reduz parte do trabalho de compliance de dados financeiros: a camada de conexão com o dado já passou pelo crivo regulatório. O que resta é garantir que o uso do dado, dentro da infraestrutura de cada empresa, também esteja em ordem.
Essa divisão clara de responsabilidade é o que permite que fintechs se movam mais rápido sem comprometer o compliance. Não porque ignoraram os requisitos, mas porque parte deles já está resolvida na infraestrutura que usam.
Se você quer entender como a infraestrutura regulada da Belvo pode ajudar sua fintech a navegar LGPD, Open Finance e as exigências do BACEN, fale com nosso time de especialistas.
Perguntas frequentes sobre soberania de dados e compliance no Open Finance
O que é soberania de dados para fintechs no Brasil?
Soberania de dados é o princípio de que dados coletados no Brasil devem estar sujeitos às leis brasileiras, independentemente de onde a infraestrutura está hospedada. Para fintechs, isso significa que decisões sobre região de cloud, acesso de terceiros e transferência internacional de dados têm implicações regulatórias diretas sob a LGPD e as diretrizes do Banco Central.
Como a LGPD se aplica a dados do Open Finance?
A LGPD define as bases legais para coleta e uso de dados pessoais, incluindo dados financeiros acessados via API Open Finance Brasil. Toda fintech que recebe dados do Open Finance precisa ter uma base legal clara para cada tratamento, documentar o ciclo de vida do dado e garantir os direitos dos titulares. O consentimento é uma das bases legais possíveis, mas não a única.
Quem é responsável pelo dado quando uma fintech usa licenciamento proxy no Open Finance?
A responsabilidade é compartilhada, mas dividida por etapas. O participante licenciado, como a Belvo, é responsável pela coleta e transporte do dado dentro das normas do Open Finance e da LGPD. A fintech que recebe o dado é responsável por como o armazena, processa e usa dentro da própria infraestrutura. Essa divisão precisa estar documentada em contratos e DPAs.
O que o Banco Central exige sobre armazenamento de dados financeiros?
Para dados sensíveis do sistema financeiro, como saldos, transações e histórico de crédito, o Banco Central tem diretrizes específicas sobre armazenamento em território nacional e sobre transferência internacional. Essas exigências vão além da LGPD e se aplicam a qualquer fintech que opere com dados de crédito BACEN, independentemente de usar infraestrutura própria ou de terceiros.
