The engineering behind financial systems — ledgers, money movement, KYC/AML, ISO 20022, and the correctness guarantees fintech demands.
The first decision in any financial system, and the one people get wrong most often: never store money in a floating-point number.
Never store money in a float. Use integer minor units or fixed-scale decimals, round half-even, allocate so splits sum exactly, and treat currency and the FX rate you used as first-class, auditable data.
Every movement of money touches at least two accounts, and the entries always sum to zero. That one invariant is the backbone of a correct financial system.
Every transaction is balanced postings that sum to zero — enforce it at write time. The ledger is append-only, and booking, value, and settlement time are three different clocks you must not conflate.
In finance you never update and never delete — you only append. Event sourcing gives you a perfect audit trail; the right to be forgotten is where it fights back.
In finance you append, never update or delete. Event sourcing gives a perfect audit trail; the right to be forgotten is where it fights back — and crypto-shredding is how you reconcile the two.
A transfer is a state machine with money on the line. Model the states explicitly, reserve funds before you commit, and decide up front what an overdraft even means.
A transfer is a state machine with money on the line. Model the states explicitly, reserve funds before you commit, enforce invariants at every transition, and decide up front what an overdraft even means.
The network will time out mid-transfer. The only safe assumption is that every request runs zero, one, or many times — so make "many" behave like "one."
The network times out ambiguously, so every request runs zero, one, or many times. Idempotency keys make many behave like one; full resumability lets a crashed money flow resume from its last committed step.
Talking to a payment rail is the least reliable part of your system. Treat every outbound call as fallible and every inbound webhook as hostile.
Talking to a payment rail is the least reliable part of your system. Treat every outbound call as fallible and reconcile on ambiguity; treat every inbound webhook as hostile — verify, dedupe, ack fast, and go read the truth.
Two systems will drift. The transactional outbox stops you losing events; reconciliation is how you find the truth when they disagree anyway.
You can't atomically update your database and publish a message. The transactional outbox (or CDC) stops you losing events; reconciliation is how you find and classify the breaks when two systems drift anyway.
The last mile of a financial system isn't code — it's who can do what, who approves it, and how you prove the whole thing is correct.
The last mile isn't code — it's who can do what, who approves it, and how you prove it's correct. Segregation of duties, four-eyes, an auditable change trail, and property tests that assert ledger invariants over thousands of scenarios.
This series is part of a larger body of work by Pratik Dhanave, an Agentic AI Architect writing about production AI systems, distributed systems, and cloud-native engineering. Explore all course series, browse every post, or find topics via the tag index.