Building software for banks and FinTechs: what is different

A dropped record in a marketplace is an annoyance. In a ledger it is a reconciliation problem, and possibly a regulatory one. That single difference changes almost everything about how financial software has to be built.

The non-negotiables

Double-entry, not a balance column. A balance you can update is a balance you can corrupt. Money moves as paired entries that must sum to zero, and the balance is derived. This is not old-fashioned; it is the only design that survives a partial failure.

Idempotency everywhere. Networks retry. A payment request that arrives twice must charge once. Every write path that touches money needs an idempotency key, and it has to be enforced in the database, not in application logic.

Immutability. You do not update or delete financial records. You append a correcting entry. Auditors need to see what was believed at the time, not the tidied version.

Reconciliation that runs unattended. Your ledger and your provider's will disagree eventually. The question is whether you find out from a scheduled job or from a customer.

Onboarding is a product, not a form

KYC and AML are where most FinTech products lose users. Every additional field costs completions, but you cannot skip what the regulator requires. The work is sequencing — collect the minimum to start, verify progressively, and never make someone re-enter what they already gave you.

Build for the audit you will have

Access control, audit trails, retention policy and data residency are cheap at the start and extremely expensive to retrofit. Assume you will be asked to prove who saw what and when.

Working inside someone else's framework

Most bank and FinTech work happens inside an existing compliance framework. The useful partner is one comfortable being told the rules rather than inventing them.

This is one of the sectors we build for.