At Octane we run the wallet on Formance, a ledger you buy rather than build. I promised at the end of the Temporal post to write about the ledger itself — the posting rules and the reconciliation that proves the numbers agree. This is that post, framed as the question every fintech asks eventually: do you buy this, or do you build it?
The honest answer starts with what a ledger actually has to guarantee, because that list is longer than it looks from the outside.
What a ledger actually has to guarantee
Strip the word down and a ledger is four promises. Every movement of money is double-entry: postings that sum to zero, so money is never created or destroyed, only moved. The log is immutable: you don't update history, you append a reversal. Every posting is idempotent: a retried charge is one charge, not two. And every balance is derived: the sum of postings, reproducible from the log at any moment, including moments in the past.
Those four together are what make reconciliation possible — the daily proof that what the wallet says, what the bank says and what the customer sees are the same number.
The build trap
The trap is that each promise looks easy alone. A transactions table with an amount column covers the demo. The guarantees only bite together, under load, on the bad day: two captures racing the same balance, a retry arriving after a timeout that wasn't one, a deploy landing mid-transaction, an auditor asking for the balance as of last Tuesday at 14:00.
Teams discover the gap the same way every time — in reconciliation, as numbers that should agree and don't, weeks after the code that caused them shipped. By then the fix is not a bugfix; it's a migration of every balance the system has ever touched.
What buying gets you — and what it doesn't
Formance gives you the four promises as a service: a posting model with real semantics (Numscript scripts that say, in a few lines, move this from the fleet's wallet to the station, keeping the fee), an immutable log, idempotency keys on every posting, and balances derived from the log rather than stored beside it. Duplicates are rejected at the ledger, which is what makes the retry-heavy workflow from the Temporal post safe at the bottom layer too.
What it does not give you is the part that's actually yours: the invariants of your business. A ledger guarantees the arithmetic; it doesn't know that a fleet wallet must never go negative, that a hold must release within twenty-four hours, that station settlements run net of fees. Those live in your code and your queries — which is where they belong, because they're the rules you change as the product evolves.
How we run it
The split that works for us: Formance owns the log and the arithmetic; we own the invariants and the proof. Concretely, the proof is a set of reconciliation queries that run on a schedule and page someone when they fail — every transaction's postings sum to zero, no wallet is negative that shouldn't be, holds older than their lifetime are flagged, and the ledger's totals agree with what we settled at the network. The day those queries are all green is a day nobody thinks about the ledger. That is the entire point of buying it.
When building wins
Build when the ledger is the product — you're a core-banking provider and the posting model is your differentiation. Build when your assets are genuinely exotic: not money-like, with rules no general ledger expresses. And build when the unit economics break — volumes where the vendor's price per posting outgrows a team's salary. None of those described a fleet-payment wallet that needed to ship.
The rule of thumb I'd give another team: if your customers will never praise your ledger, buy it — and spend the saved year on the invariants and the reconciliation, because those are yours no matter who runs the log.
Muhammad Alnaqeeb is a senior software engineer in Cairo. He works on wallets, ledgers and fraud controls, most recently at Octane. Reach him at [email protected].
← More writing