Why Fintech Systems Don't Use Floating-Point Numbers for Money
Floats feel natural in code, but money in production uses integers, fixed decimals, ledgers, and idempotency — not IEEE-754 — so precision and trust scale.
If you have ever worked with numbers in code, using a float or double feels natural. But in financial systems, that instinct can quietly introduce errors that scale into real money loss.
This is not theoretical. It is one of the first problems engineers run into when building payment systems, wallets, or ledgers.
Let us break down how real systems handle money, and why.
The Problem with Floating-Point Numbers
The Core Rule
Integers representing the smallest unit (paise, cents)
Fixed-precision decimal types
For example:
₹100.50 → 10050 (paise)
This eliminates rounding issues completely.
How Real Systems Handle Money
Double-Entry Bookkeeping
A debit from one account
A credit to another account
If you transfer ₹100:
- Your account:
-100 - Receiver's account:
+100
This ensures that the system always remains balanced.
Append-Only Ledger
Every entry is recorded once
Corrections are made by adding new entries, not editing old ones
This provides auditability, traceability, and safety against corruption.
Balance Is Not the Source of Truth
Idempotency: Handling Retries Safely
Where Strings Come In
A Simple Mental Model
API receives amount as a string
Backend converts it into an integer (smallest unit)
Two ledger entries are created (debit and credit)
Entries are appended to the ledger
Idempotency is checked to avoid duplicates
Balance is computed from the ledger
This design prioritizes correctness over convenience.