A Field Guide to Not Losing Money in Code: Patterns for Fintech Engineering

A new open community handbook lays out the engineering patterns that keep money systems trustworthy, organized around three rules: don’t invent data, don’t lose data, and don’t trust anyone — not external providers, not internal components, not the outside world. Those principles map directly to concrete techniques like idempotency, deduplication, reconciliation, event sourcing, immutable audit trails, and verifying every webhook rather than assuming it’s legitimate.

Much of the guide drills into how to represent money correctly, since errors there silently propagate through every layer above. Floating-point types are effectively banned because they leak precision that can never be recovered; the practical alternatives are arbitrary-precision decimals for chained pricing and FX math, integer storage in a currency’s smallest unit (with the reminder that ISO 4217 precision isn’t always two digits, and crypto can need 18 digits plus arbitrary-width integers), or rational numbers when no loss is tolerable. A subtle trap it flags: serializing an amount as a bare JSON number reintroduces IEEE-754 doubles at the system boundary, so money should cross the wire as a string or a smallest-unit integer. Rounding gets similar treatment — it’s a business and sometimes legal decision, should happen as late as possible, and breaks sums in ways that may require an explicit rounding account.

The handbook also codifies currency discipline: bind amount and currency together in a dedicated type, forbid cross-currency arithmetic, validate against a controlled currency set at the boundary, and remember that simple codes only identify fiat — crypto needs richer identifiers like network plus contract address. On FX, it stresses that rates are directional (EUR/USD isn’t just the inverse of USD/EUR thanks to bid/ask spreads), time-sensitive, and never canonical, drawing a clear line between the transactional rate a trade actually executed at and reference rates used only for valuation. It’s pitched as a living document for newcomers, practitioners, and engineers from other domains, with contributions welcomed.