Arquitetura fintech: os pontos inegociáveis

Na maioria do software, um bug é um incidente. Em fintech, um bug é um passivo que pode já ter custado dinheiro que ninguém deu ainda por isso.

A arquitetura fintech tem um pequeno número de decisões genuinamente inegociáveis. Errá-las e nenhuma engenharia posterior recupera por completo — herda-se um sistema onde o dinheiro pode estar silenciosamente errado, o único modo de falha que um produto financeiro não consegue absorver.

1. Os saldos são derivados, nunca guardados como verdade

O erro mais comum e mais danoso é uma coluna de saldo mutável que o código atualiza diretamente. É cómoda, rápida e irrecuperável: quando derrapa, não há forma de determinar qual deveria ter sido.

O modelo correto é um diário de lançamentos append-only. Nada é jamais atualizado ou apagado; as correções são novos lançamentos compensatórios. O saldo é a soma dos lançamentos, em cache por desempenho mas sempre reconstruível a partir do diário.

2. Todo o caminho do dinheiro é idempotente

As redes repetem. Os utilizadores clicam duas vezes. Os prestadores de pagamento entregam webhooks mais do que uma vez — é comportamento documentado, não um caso limite. Qualquer operação que mova dinheiro tem de ser segura de executar repetidamente.

• Cada operação de dinheiro leva uma chave de idempotência fornecida por quem chama, única por intenção lógica
• A chave é guardada com restrição de unicidade antes dos efeitos secundários, não depois
• Uma chave repetida devolve o resultado original em vez de refazer o trabalho
• Os handlers de webhook guardam o payload cru indexado pelo id do evento do prestador e só depois processam — assim uma reentrega é reconhecida mesmo a meio do processamento

3. Dinheiro são inteiros em unidades menores

A vírgula flutuante não representa frações decimais de forma exata, por isso a aritmética sobre dinheiro em float acumula erro. Guarde unidades menores como inteiros (ou um tipo decimal de precisão fixa) e torne a moeda explícita em cada montante — um montante sem moeda é um bug à espera do primeiro cliente internacional.

4. A reconciliação é uma funcionalidade, não uma ideia tardia

Assuma divergência entre o seu livro-razão e o prestador de pagamento — vai acontecer, por timeouts, falhas parciais e correções do lado do prestador. A questão é se a deteta.

• Um job agendado a comparar o estado interno com os dados de liquidação do prestador
• Alerta em caso de discrepância, com responsável definido e runbook
• Um caminho de resolução definido — lançamentos compensatórios, nunca ajuste silencioso
• Varrimentos de estados presos: transações em pendente há mais tempo do que deviam

5. Isolamento, nos dois sentidos

• Isolamento de tenants — imposto na camada de dados, não à espera de que cada consulta inclua o filtro certo
• Isolamento de falhas — um prestador lento não pode esgotar o pool de pedidos e derrubar funcionalidades sem relação
• Isolamento de ambientes — nunca transações de teste em livros-razão de produção

6. Construa para a auditoria que acabará por enfrentar

Não. Produz constatações técnicas no âmbito acordado. Interpretação jurídica e certificação formal exigem os profissionais qualificados correspondentes.

• Trilho de auditoria imutável de quem fez o quê e quando — incluindo ações internas de administração
• Dados de cartão nunca a tocar nos seus servidores, a menos que pretenda mesmo ser PCI-compliant (use campos alojados ou página alojada)
• Retenção e eliminação de dados que possam de facto ser executadas a pedido
• Controlo de acessos revisível — quem pode mover dinheiro, quem aprovou

Em software vulgar otimiza-se a velocidade de mudança. Em fintech otimiza-se a capacidade de provar, mais tarde, exatamente o que aconteceu e porquê.

As cinco perguntas ao seu próprio sistema

1. Se este webhook chegar duas vezes, muda alguma coisa da segunda vez?
2. Consigo reconstruir o saldo de qualquer cliente em qualquer momento passado apenas a partir do livro-razão?
3. Detetaríamos uma discrepância com o prestador, ou seria um cliente a dizer-nos?
4. Um pedido forjado consegue ler ou mover o dinheiro de outro tenant?
5. Se um regulador perguntasse quem aprovou um ajuste manual em março passado, conseguiríamos responder em minutos?

Separar aceitação e liquidação das transações

Os estados devem permitir reconciliar eventos tardios ou repetidos. Verifique registos financeiros e o processo de correção.

1. Usar decimais exatos ou unidades inteiras com regras por moeda.
2. Correlacionar eventos e registos sem contabilizar repetições duas vezes.
3. Preservar originais e documentar correções autorizadas.

• auditoria técnica fintech →