Building fintech products properly.

Never store money as a floating point number

This sounds like pedantry and is the single most common expensive mistake in the category.

Floating point cannot represent many decimal values exactly. Accumulate enough arithmetic and balances drift by amounts that are small individually and impossible to explain to an auditor collectively.

Store currency as an integer in minor units, or as a decimal type with explicit precision. Decide rounding behaviour deliberately and document it, because rounding rules differ by jurisdiction and by product, and getting them wrong is a compliance issue rather than a bug.

Design the ledger before the features

A double-entry ledger with immutable entries is the correct foundation for anything holding balances. Corrections are made with compensating entries rather than by updating history.

This matters because it makes the system provable. You can demonstrate that balances derive from a complete, ordered sequence of events, which is what reconciliation and audit both require.

Retrofitting this is among the hardest migrations in software, because you must reconstruct history that was never recorded. It is worth the time at the start.

Make every payment path idempotent

Networks fail mid-request, clients retry, and users press buttons twice. Any endpoint that moves money must be safe to call repeatedly.

Use client-supplied idempotency keys stored with the result. A repeated request returns the original outcome rather than performing the operation again. Without this, duplicate charges are a matter of time, and they damage trust disproportionately.

Build reconciliation from the start

• Daily automated comparison between your ledger and each provider's records
• An exception queue for discrepancies, with ownership and resolution tracking
• Immutable audit trail covering who initiated each movement and when
• Alerting on balance drift beyond a defined threshold
• The ability to reproduce any balance at any historical point in time

Treat compliance as a design input

KYC, AML screening, data retention and the right to erasure all change your data model. They are not features to be added to a finished system.

Retention is the one most often missed. If you must delete personal data on request while retaining transaction records for regulatory periods, that tension has to be designed for - typically by separating identity from transaction data from the beginning.

Your compliance counsel owns the regulatory interpretation. Your engineers own building a system where the required answer is achievable without a migration under deadline.