Todo sistema financeiro tem um ledger. É ele que registra cada crédito, cada débito, cada saldo. Se o ledger erra, o dinheiro some. Ou aparece onde não deveria.
A pergunta incômoda: quantas fintechs no Brasil sabem como o ledger delas computa um saldo? Não o resultado. O processo. A lógica que decide se um estorno parcial debita de um saldo bloqueado ou disponível. A regra que determina o que acontece quando duas transações concorrentes disputam o mesmo centavo.
Na maioria dos casos, a resposta é ninguém. O código é do vendor. A fintech opera no escuro e confia que está tudo certo.
O que significa "código aberto" em infraestrutura financeira
Código aberto (ou source-available) significa que qualquer pessoa pode ler, inspecionar e auditar o código-fonte do sistema. Não é a mesma coisa que gratuito. Não é a mesma coisa que sem suporte. É uma decisão de transparência: o código que governa o dinheiro é visível para quem depende dele.
No Brasil, esse conceito ainda é novo em fintech. A maioria das plataformas de core banking, ledger e pagamentos opera com código 100% fechado. O cliente contrata o resultado e torce para que a implementação esteja correta.
Essa é a norma. Não significa que seja inteligente.
O problema real: você audita o que não pode ver?
Reguladores brasileiros (Bacen, CVM, auditores de participantes Pix) pedem evidências de controle. Como saldos são computados. Como estornos são tratados. Como a integridade contábil é mantida sob carga.
Com código fechado, a evidência é um PDF. Um documento que o vendor preparou explicando o que o sistema supostamente faz. O auditor lê. O time de compliance valida. Todo mundo assina embaixo de uma narrativa que ninguém verificou contra o código real.
Isso funciona. Até não funcionar. Até o momento em que o regulador pede detalhes que o PDF não cobre. Ou até o momento em que um bug silencioso acumula diferenças de centavos por meses e ninguém percebe porque ninguém pode olhar dentro da caixa.
Um estudo da Juniper Research (2023) estimou que fraudes em pagamentos digitais custariam US$ 362 bilhões globalmente entre 2023 e 2028. Boa parte desses custos não vem de ataques sofisticados. Vem de falhas de controle que passam despercebidas em sistemas opacos.
Quando o código é aberto, a dinâmica muda. O engenheiro aponta a função exata. O time de segurança examina a superfície de ataque real. O auditor não depende de interpretações. Depende do código. A implementação é a evidência.
Vendor lock-in: o risco que ninguém precifica até ser tarde
Vendors mudam de estratégia. São adquiridos. Pivotam. Descontinuam features. Mudam pricing.
Segundo o Gartner (2023), 83% das migrações de sistemas core em instituições financeiras excedem o orçamento planejado. 60% excedem o prazo. Migrar de um vendor com código fechado não é trocar de fornecedor. É reconstruir.
A pergunta que importa não é "e se o vendor sumir?", porque isso é raro. A pergunta é "e se o vendor mudar de ideia?". Mudar o preço. Descontinuar a API que sustenta sua integração de Pix. Ser adquirido por um concorrente que não tem interesse em manter seu contrato.
Com código aberto, a resposta é diferente. O código permanece acessível independente do que aconteça com a empresa que o criou. Times internos ou parceiros podem continuar operando o sistema. A continuidade não depende da boa vontade de ninguém.
Isso não elimina vendor risk. Nenhuma decisão de arquitetura elimina. Mas muda radicalmente o poder de negociação.
Código aberto não é sinônimo de gratuito (nem de inseguro)
Essa confusão é comum e vale esclarecer.
"Se o código é aberto, qualquer um vê as vulnerabilidades." Sim. Inclusive os engenheiros de segurança da empresa que usa o sistema. E os pesquisadores independentes. E a comunidade. É contra-intuitivo, mas código aberto tende a ser mais seguro ao longo do tempo porque mais olhos encontram mais bugs. O Linux roda 96% dos servidores web do mundo e toda a infraestrutura da AWS. Não apesar de ser código aberto. Porque é.
"Se o código é aberto, não preciso pagar." Depende da licença. Source-available significa que você pode ler e inspecionar. Não necessariamente que pode usar comercialmente sem licença. Empresas como HashiCorp, MongoDB e Elastic operam com modelos híbridos: código visível, uso comercial licenciado.
"Se posso rodar sozinho, não preciso do vendor." Pode, mas provavelmente não deveria. Self-hosting de infraestrutura financeira exige equipe dedicada, compliance, monitoramento 24/7. A maioria das empresas prefere (com razão) um ambiente gerenciado. A diferença é que com código aberto, essa escolha é sua. Não uma imposição.
O que avaliar antes de contratar infraestrutura financeira
Independente de escolher código aberto ou fechado, essas perguntas valem pra qualquer decisão:
• Você pode inspecionar a lógica contábil? Se não pode, como valida que o sistema está correto?
• O que acontece se o vendor for adquirido ou descontinuar o produto? Tem plano de contingência real ou só esperança?
• Onde seus dados residem? LGPD e normas do Bacen têm exigências específicas sobre residência de dados financeiros.
• Você pode rodar o sistema na sua infraestrutura se precisar? Não porque vá fazer isso amanhã. Mas porque a opção precisa existir.
• Como o vendor trata auditoria? Te entrega código ou te entrega PDFs?
• Qual o custo real de migração? Se for proibitivo, você não tem um fornecedor. Tem uma dependência.
Quem já está nessa direção
Esse movimento não é exclusivo de uma empresa. É uma tendência de mercado:
• Midaz (Lerian): Ledger de partidas dobradas com código-fonte publicado. Modelo source-available com opção de cloud gerenciada ou self-hosting.
• Apache Fineract: Plataforma de core banking open source mantida pela Apache Foundation. Adotada por instituições de microfinanças em mercados emergentes.
• Moov Financial: Infraestrutura de pagamentos open source nos EUA. Foco em APIs financeiras com código publicado no GitHub.
• Hyperledger (Linux Foundation): Frameworks de ledger distribuído com adoção em bancos globais.
São abordagens diferentes para o mesmo princípio: infraestrutura que move dinheiro deveria resistir à inspeção.
Perguntas frequentes
O que é source-available?
Modelo de licenciamento onde o código-fonte é publicado e pode ser inspecionado por qualquer pessoa. Diferente de open source puro, pode ter restrições de uso comercial. O ponto relevante pra infraestrutura financeira é a transparência: o código é visível.
Código aberto é seguro pra sistemas financeiros?
Sim. A maioria da infraestrutura financeira global roda sobre componentes de código aberto (Linux, PostgreSQL, Kubernetes). Visibilidade do código permite auditorias independentes e identificação mais rápida de vulnerabilidades.
Preciso de equipe técnica pra usar infraestrutura com código aberto?
Não necessariamente. A maioria dos vendors que publicam código também oferece versões gerenciadas (cloud). O código aberto dá a opção de self-hosting, não a obrigação.
Reguladores brasileiros exigem código aberto?
Não diretamente. Mas exigem evidências de controle, auditabilidade e governança sobre a infraestrutura de liquidação. Código inspecionável facilita significativamente o compliance.