Manual de Engenharia Fintech

Artigo original ↗ Discussão no Hacker News ↗

Recepção geral do manual

  • Muitos leitores com experiência em fintech dizem que os conselhos batem com a prática do mundo real e são úteis para quem está começando.
  • Outros acham que em alguns pontos ele é superficial ou deixa de fora ressalvas importantes (FX, livros-razão, compliance).
  • Há algum ceticismo sobre a autoria por IA; o autor esclarece que a maior parte vem da experiência, com alguma ajuda de IA na edição.
  • Vários destacam que nenhum manual genérico pode substituir orientações específicas da empresa moldadas por advogados e compliance.

Idempotência, retries, trilhas de auditoria e webhooks

  • Há forte concordância de que chaves de idempotência, semântica cuidadosa de retries e eventos ordenados são críticos, especialmente com pagamentos e webhooks.
  • Boas trilhas de auditoria são descritas tanto como uma ferramenta de depuração quanto como um suporte essencial de compliance; alguns engenheiros constroem “apenas trilhas de auditoria” como sua principal fonte de dados.
  • Webhooks são amplamente usados em pagamentos (por exemplo, para confirmar o status de uma transação), mas não são universais em todos os setores.

Representando dinheiro: inteiros, decimais, floats, strings

  • A representação baseada em inteiros de “unidade menor” (por exemplo, centavos) é defendida como padrão da indústria em muitas áreas (HFT, pagamentos, bancos de consumo).
  • Os críticos argumentam que inteiros como unidades menores se tornam frágeis com:
    • moedas com diferentes casas decimais,
    • stablecoins/cripto com precisões diferentes,
    • sistemas parceiros que assumem silenciosamente expoentes diferentes.
  • Alternativas discutidas:
    • decimal de precisão arbitrária ou tipos decimais nativos da linguagem.
    • representação JSON baseada em string para evitar problemas de parsing de float.
    • mantissa inteira + expoente inteiro (ponto flutuante decimal).
    • esquemas de ponto fixo (por exemplo, escalar por 10^n).
  • Visão minoritária forte: doubles são aceitáveis e comuns se você:
    • respeitar os limites de precisão,
    • arredondar consistentemente após cada operação,
    • usar matemática contábil especializada.
  • Outros insistem que floats nunca devem ser usados para saldos de custódia/contabilidade; aproximações são aceitáveis apenas em contextos de modelagem/quant.
  • Há consenso de que regras explícitas de arredondamento e reconciliação são essenciais, independentemente da representação.

Livros-razão, imutabilidade, event sourcing e modelagem de dados

  • Concorda-se que o estado monetário central deve ser imutável e derivado de movimentações, mas:
    • alguns preferem event sourcing completo;
    • outros favorecem logs de auditoria append-only mais simples para evitar replay complexo de estado.
  • Há disputa sobre se “saldo nunca é armazenado” é algo prático; alguns consideram isso uma orientação limítrofe ou ruim.
  • Foram apontados FX e instrumentos complexos como temas que precisam de muito mais nuance do que o manual fornece (taxas, políticas de arredondamento, regras legais de precisão).
  • Linhagem de dados e versionamento de dados externos/de fornecedores são destacados como tópicos importantes que ficaram de fora.

Compliance, PII e restrições organizacionais

  • Um grupo defende separar PII dos registros financeiros para permitir eliminação, preservando ao mesmo tempo o histórico financeiro exigido.
  • Outro alerta que isso pode conflitar com KYC/AML e requisitos investigativos; enfatiza aderir a políticas internas específicas da jurisdição, em vez de conselhos genéricos.
  • Alguns argumentam que engenheiros em empresas reguladas devem, em grande parte, seguir padrões internos já estabelecidos em vez de “pescar” padrões online; outros contrapõem que ideias externas são necessárias para modernizar práticas legadas.

Escopo de “fintech” e tradeoffs específicos do domínio

  • Vários comentaristas observam que “fintech” abrange subdomínios muito diferentes:
    • HFT e negociação de baixa latência,
    • pagamentos e bancos para consumo,
    • carteiras cripto e blockchains,
    • modelagem de risco/quant.
  • O que é “correto” (inteiros vs decimais, profundidade do event sourcing, níveis de precisão) varia bastante conforme o subdomínio e as restrições de desempenho/compliance.
  • Vários destacam que aprender princípios de contabilidade e de livros-razão, além de fundamentos de banco de dados, é mais importante do que qualquer escolha tecnológica específica.

Notas práticas diversas e recursos

  • Verificações de saldo via ACH/Plaid não são garantias; os fundos podem desaparecer antes da liquidação.
  • O tratamento de cheque especial e a semântica de “enviar para saber com certeza” são reconhecidos como realidades.
  • Recursos citados para estudo adicional incluem guias de contabilidade para desenvolvedores, artigos sobre escala de livros-razão, livros de sistemas intensivos em dados e leituras padrão sobre mercados de capitais e renda fixa.