Fintech Engineering Handbook

Original Article ↗ Hacker News Discussion ↗

Engineering money-moving systems turns out to be less about clever algorithms and more about getting details like idempotency, audit trails, rounding, and data lineage exactly right. Commenters largely praise a new “Fintech Engineering Handbook” for capturing hard‑won lessons on ledgers, retries, and safe APIs, while arguing over thorny issues such as how to represent monetary values (integers vs decimals vs strings), where to use event sourcing, and when doubles are acceptable. Many stress that domain knowledge, regulation, and use case (consumer banking, payments, HFT, capital markets) heavily shape the “right” design, and that compliance and reconciliation matter at least as much as technical elegance.

Overall reception of the handbook

  • Many readers with fintech experience say the advice matches real-world practice and is useful for newcomers.
  • Others find it shallow in places or missing important caveats (FX, ledgers, compliance).
  • Some skepticism about AI authorship; author clarifies most is from experience with some AI help on editing.
  • Several stress that no generic handbook can replace company-specific guidance shaped by lawyers and compliance.

Idempotency, retries, audit trails, and webhooks

  • Strong agreement that idempotency keys, careful retry semantics, and ordered events are critical, especially with payments and webhooks.
  • Good audit trails are described as both a debugging tool and a core compliance backstop; some engineers build “only audit trails” as their primary data source.
  • Webhooks are widely used in payments (e.g., confirming transaction status) but not universal across all sectors.

Representing money: integers, decimals, floats, strings

  • Int-based “minor unit” representation (e.g., cents) is defended as an industry standard in many areas (HFT, payments, consumer banking).
  • Critics argue minor-units-as-ints become brittle with:
    • currencies with varying decimal places,
    • stablecoins/crypto with different precisions,
    • partner systems that silently assume different exponents.
  • Alternatives discussed:
    • Arbitrary-precision decimal or language-native decimal types.
    • String-based JSON representation to avoid float parsing issues.
    • Integer mantissa + integer exponent (decimal floating point).
    • Fixed-point schemes (e.g., scale by 10^n).
  • Strong minority view: doubles are acceptable and common if you:
    • respect precision limits,
    • round consistently after each operation,
    • use specialized accounting math.
  • Others insist floats should never be used for custodial/accounting balances; approximations are acceptable only in modeling/quant contexts.
  • Consensus that explicit rounding rules and reconciliation are essential, regardless of representation.

Ledgers, immutability, event sourcing, and data modeling

  • Agreement that core monetary state should be immutable and derived from movements, but:
    • Some prefer full event sourcing;
    • Others favor simpler append-only audit logs to avoid complex state replay.
  • Dispute over whether “balance is never stored” is practical; some consider it borderline bad advice.
  • Callouts that FX and complex instruments need much more nuance than the handbook gives (rates, rounding policies, legal precision rules).
  • Data lineage and versioning of external/vendor data are highlighted as missing but important topics.

Compliance, PII, and organizational constraints

  • One camp endorses separating PII from financial records to support erasure while preserving required financial history.
  • Another warns this can conflict with KYC/AML and investigative requirements; stresses adherence to internal, jurisdiction-specific policies over generic advice.
  • Some argue engineers in regulated firms should mostly follow established internal standards rather than “shopping” for patterns online; others counter that outside ideas are needed to modernize legacy practices.

Scope of “fintech” and domain-specific tradeoffs

  • Multiple commenters note that “fintech” spans very different subdomains:
    • HFT and low-latency trading,
    • consumer payments and banking,
    • crypto wallets and blockchains,
    • risk/quant modeling.
  • What’s “correct” (ints vs decimals, event sourcing depth, precision levels) varies heavily by subdomain and performance/compliance constraints.
  • Several stress learning accounting and ledger principles, plus database fundamentals, as more important than any specific technology choice.

Miscellaneous practical notes and resources

  • ACH/Plaid balance checks are not guarantees; funds can disappear before settlement.
  • Overdraft handling and “submit to know for sure” semantics are acknowledged realities.
  • Resources mentioned for further study include accounting-for-developers guides, ledger-scaling articles, data-intensive systems books, and standard reading for capital markets and fixed income.