Porque é que cada saldo deve sair de um ledger de dupla entrada

Todos os sistemas bancários têm uma tabela que responde à pergunta mais importante do produto: quanto dinheiro tem este cliente? A decisão de design que separa os cores fiáveis dos frágeis é se esse número é armazenado — uma coluna que alguém atualiza — ou derivado — a soma de um ledger append-only. Parece um detalhe de implementação. É a diferença entre um sistema que consegue provar os seus saldos e um sistema que apenas consegue afirmá-los.

Esta é a decisão de arquitetura com mais consequências num core fintech, e é quase invisível numa demo. Dois produtos podem parecer idênticos no ecrã enquanto um atualiza uma coluna de saldo no próprio registo e o outro deriva cada saldo de um ledger de dupla entrada. A diferença aparece mais tarde — em quebras de reconciliação, em tickets de suporte que ninguém consegue explicar e nas auditorias.

O que significa dupla entrada em termos de engenharia

A contabilidade de dupla entrada tem cinco séculos, mas num backend bancário não é uma formalidade contabilística — é um invariante que a base de dados faz cumprir. Cada movimento de dinheiro é uma transação com pelo menos dois lançamentos: uma conta é debitada, outra é creditada, e os lançamentos somam zero. O dinheiro nunca é criado nem destruído por um UPDATE; apenas se move entre contas, e o próprio movimento é o registo.

O saldo de um cliente é então uma projeção: a soma de todos os lançamentos do ledger que tocam essa conta. Guardado em cache por desempenho, sim — mas sempre recalculável, e o recálculo é a verdade. Se a cache e o ledger alguma vez discordarem, o ledger ganha, e a própria discordância é um sinal de que algo precisa de ser investigado.

O invariante de soma zero dá-lhe uma propriedade que nenhum design de saldo armazenado pode oferecer: o sistema inteiro pode ser verificado. Some todos os lançamentos de todas as contas — carteiras de clientes, receita de comissões, contas de liquidação de provedores, contas transitórias — e o total é zero. Qualquer bug, condição de corrida ou falha parcial que perca dinheiro quebra essa equação e torna-se detetável, normalmente no próprio dia.

Como os saldos armazenados se desviam

O modo de falha do design de coluna de saldo não é dramático. É um desvio lento produzido pelo tráfego normal de produção:

• Concorrência: dois levantamentos leem o mesmo saldo no mesmo instante, ambos passam a verificação, ambos escrevem. Sem o ledger, não há registo de qual deveria ter sido o saldo.
• Repetições e falhas parciais: um provedor de pagamentos dá timeout, o cliente repete o pedido e o crédito entra duas vezes — ou uma falha entre "atualizar saldo" e "registar transação" deixa os dois permanentemente inconsistentes.
• Operações manuais: um engenheiro de suporte resolve uma reclamação com um UPDATE direto. O cliente fica satisfeito; o dinheiro que apareceu não tem origem, e nenhum relatório o explicará jamais.
• Comissões e arredondamentos: uma comissão calculada num sítio e aplicada noutro, uma conversão cambial arredondada de forma diferente em cada lado — frações de cêntimo que se acumulam até serem discrepâncias reais.

As regras que um ledger lhe impõe — todas boas

Comprometer-se com saldos derivados impõe disciplina ao resto do core. Estas restrições parecem rígidas no primeiro dia e revelam-se a razão pela qual o sistema continua correto no terceiro ano:

• Montantes inteiros em unidades mínimas — cêntimos, satoshis, wei — nunca vírgula flutuante. Os floats binários não conseguem representar 0,10 com exatidão; um ledger que tem de somar zero não pode ser construído sobre números que quase batem certo.
• Lançamentos imutáveis: um lançamento registado nunca é editado nem apagado. Os erros corrigem-se como os bancos sempre os corrigiram — com um lançamento de estorno que deixa no registo tanto o erro como a correção.
• Idempotência: cada operação transporta uma chave, para que um pedido repetido seja lançado uma única vez. O ledger torna os duplicados visíveis; a idempotência evita-os.
• Atomicidade: o débito, o crédito e a mudança de estado de negócio são confirmados juntos ou não são confirmados de todo. Nenhum caminho do código atualiza um saldo fora de uma transação do ledger — incluindo os ajustes administrativos, que passam a ser lançamentos normais e atribuíveis em vez de sobreposições silenciosas.

Reconciliação: prová-lo contra o mundo exterior

O invariante interno prova que o sistema é consistente consigo próprio. A reconciliação prova que é consistente com a realidade. Um core fintech mantém posições com terceiros — trilhos bancários, processadores de cartões, redes blockchain — e cada um guarda a sua própria versão da verdade. A reconciliação diária compara cada extrato de provedor e cada posição on-chain com as contas correspondentes do ledger e obriga a explicar cada diferença: uma liquidação em trânsito, uma comissão de provedor ainda não lançada, ou uma quebra genuína que recebe um lançamento transitório e um responsável no próprio dia.

A reconciliação é onde a arquitetura se paga a si própria. Com um ledger de dupla entrada, uma quebra é uma busca delimitada: o dia em que apareceu, as contas que tocou, os lançamentos envolvidos. Com saldos armazenados, a mesma investigação parte de um número sem história — e é por isso que as diferenças por reconciliar em sistemas de coluna de saldo tendem a ser dadas como perdidas em vez de resolvidas.

Os criptoativos sobem a parada. Um saldo on-chain é público: qualquer pessoa pode comparar as carteiras que controla com os saldos que mostra aos clientes. Autocustódia sem um ledger que reconcilie diariamente contra a chain é uma discrepância à espera de ser descoberta por alguém de fora da empresa.

O que auditores e reguladores realmente perguntam

Mais cedo ou mais tarde, uma fintech regulada enfrenta alguma versão da mesma pergunta: prove que os saldos dos clientes estão certos. A resposta prática é uma cadeia de evidência — cada saldo deriva de um ledger append-only; o ledger soma zero; reconcilia diariamente contra cada posição externa; e uma trilha de auditoria imutável, encadeada por hash, regista quem iniciou cada movimento, a partir de que dispositivo e sob que aprovação.

As equipas que constroem sobre um design de saldo armazenado respondem a estas perguntas com trabalho forense — reconstruindo a história a partir de logs da aplicação e exportações dos provedores, no pior momento possível e contra um prazo. As equipas com um ledger respondem com uma consulta. A auditoria não cria o requisito; apenas revela se a arquitetura o cumpria desde o início.

O teste a fazer a qualquer plataforma de core banking

Se está a avaliar uma plataforma — ou a rever a que construiu — as perguntas fazem-se em cinco minutos e as respostas são difíceis de fingir:

• De onde vem o número no ecrã do cliente? Se a resposta é uma coluna de saldo e não uma projeção do ledger, tudo o resto é decoração.
• É possível alterar um saldo sem criar lançamentos no ledger? Pergunte especificamente pelas ferramentas de administração e pelos fluxos de suporte — é aí que se escondem os UPDATE silenciosos.
• Os montantes são inteiros em unidades mínimas de ponta a ponta, incluindo o lado cripto?
• Mostre-me a reconciliação de ontem: cada provedor, cada chain, cada diferença explicada. Uma plataforma que não a consegue mostrar é porque não a faz.
• Como se corrige um lançamento errado? A única boa resposta é um lançamento de estorno, atribuído a uma pessoa, atrás de um fluxo de aprovação.

Onde está a Coreza

A Coreza está construída sobre a versão estrita deste design: cada saldo — fiat e cripto — deriva de um ledger de dupla entrada; os montantes são inteiros em unidades mínimas em todo o sistema; os lançamentos registados são imutáveis, com correções por lançamentos de estorno atrás de aprovação maker-checker; e cada instância reconcilia diariamente contra cada provedor ligado e cada chain em que opera. A trilha de auditoria é append-only e encadeada por hash, registando o quem, o quando e o de onde de cada movimento.

Nada disto é visível numa demo de produto, e é precisamente esse o sentido deste artigo: o ledger é a parte de uma plataforma de core banking que não se pode avaliar olhando para ecrãs. Uma versão deste core processa clientes e dinheiro reais numa fintech europeia regulada desde 2024 — e as cinco perguntas acima são as que sugerimos que faça a qualquer plataforma, incluindo a nossa.