Fintech Engineering Handbook

Original Article ↗ Hacker News Discussion ↗

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.