Why Fintech Systems Don't Use Floating-Point Numbers for Money

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.

Floating-point numbers store values in binary. That works well for many computations, but it cannot represent most decimal fractions exactly.

A simple example:

0.1 + 0.2 is not exactly 0.3.

Instead, you get something like:

0.30000000000000004

In isolation, this looks harmless. But now imagine a system processing millions or billions of transactions.

Even a tiny error like ₹0.01, repeated enough times, becomes a serious discrepancy. In financial systems, this is unacceptable.

Financial systems follow a strict rule:

Never use floating-point numbers for money.

Instead, they use representations that guarantee exact precision.

There are two common approaches:

For example:

₹100.50 → 10050 (paise)

This eliminates rounding issues completely.

To understand how fintech systems work internally, it helps to look at how transactions are recorded.

Every transaction creates two entries:

If you transfer ₹100:

• Your account: -100
• Receiver's account: +100

This ensures that the system always remains balanced.

Transactions are never modified or deleted.

Instead, systems use an append-only ledger:

This provides auditability, traceability, and safety against corruption.

In many systems, the balance you see is not the primary data.

The real source of truth is the ledger.

Balance is derived by summing all entries for an account. Some systems cache this for performance, but the ledger remains authoritative.

Network requests can fail and retry. Without protection, this could lead to duplicate transactions.

To prevent this, systems use idempotency keys.

Each request includes a unique key. If the same request is received again:

• The system does not process it twice
• It returns the original result

This is critical in payment systems where retries are common.

You might notice that many APIs represent amounts as strings:

jsonCopy
1{
2  "amount": "100.50"
3}

This often leads to confusion.

Strings are used at system boundaries, not internally.

Why?

• Avoid precision loss during serialization
• Ensure consistency across languages (especially JavaScript)
• Prevent accidental float parsing

Once the request reaches the backend, the value is converted into an integer or decimal type for actual computation.

A typical flow in a payment system looks like this:

This design prioritizes correctness over convenience.

If you simulate adding ₹0.01 one million times:

• Using float → you will see drift
• Using integer → exact result
• Using precise decimal → exact result

This is why financial systems are designed the way they are.

At small scale, these details seem unnecessary. At large scale, they become critical.

A system handling money must guarantee precision, consistency, and auditability.

Using floats breaks that guarantee.

Financial systems are not just about moving money. They are about maintaining trust.

That is why they rely on exact numeric representations, double-entry bookkeeping, immutable ledgers, and idempotent operations.

These are not optimizations. They are requirements.

Once you understand this, a lot of design decisions in fintech start to make sense.