TL;DR
A ledger is the system of record for money. It is not the application database, and treating it as one is the most common and most expensive architectural mistake in early fintech. A ledger records immutable, double-entry postings where every movement has a matching debit and credit, so that balances are derived from history rather than stored and updated.
The engineering difficulty is not the accounting, which is centuries old and simple. It is maintaining those guarantees under concurrency, retries, partial failures and the volume of a payments business, while remaining explicable to an auditor years later.
Key points
- A balance should be a function of the ledger's history, never a mutable field.
- Idempotency is the central engineering requirement, because every upstream system will retry.
- Most fintechs rebuild their ledger once, usually between Series A and Series C, and the rebuild is a different hire from the original build.
- The scarce engineer is one who has run a ledger in production through an audit, not one who has designed a schema.
What a ledger is, and what it is not
An application database tracks current state: this user has this balance. A ledger tracks what happened: this amount moved from this account to that account, at this time, caused by this event.
The distinction has practical consequences.
Balances are derived. If a balance is a column that gets updated, then a bug, a race or a partial failure corrupts it with no way to detect or reconstruct the truth. If a balance is the sum of postings, it can always be recomputed and any discrepancy is visible.
Entries are immutable. You do not edit a posting. A mistake is corrected by writing a compensating entry, so the history shows both the error and the correction. Auditors require this, and so does any serious investigation of what went wrong.
Every movement balances. Double-entry means each transaction produces postings that sum to zero across accounts. This is not bookkeeping ceremony; it is a continuous invariant that catches a large class of bugs immediately, because an unbalanced transaction is detectable without knowing what the correct answer was.
Teams that skip this early move fast and then discover, usually during a reconciliation exercise or an audit, that they cannot explain their own numbers.
The hard parts
Idempotency. Every upstream system retries. Networks time out, queues redeliver, users press the button twice, and a payment switch will resend. If the same logical event produces two sets of postings, money has been created. The standard answer is an idempotency key derived from the originating event, enforced with a uniqueness constraint at write time, so a duplicate is rejected by the database rather than by application logic that might be racing with itself.
Concurrency on hot accounts. Most accounts are quiet. A few, such as a merchant settlement account or a pool account, receive enormous write volume. Naive row locking on those accounts serialises the entire system. Common approaches include sharding a hot account into sub-accounts that sum to the logical balance, or appending postings without locking and computing balances asynchronously, each with its own trade-offs around how quickly a balance can be trusted.
Consistency boundaries. A transfer involving two accounts in the same ledger is straightforward. A transfer involving an external party, such as a bank, is not: the external leg can succeed while your write fails, or the reverse. This is where ledgers meet reality, and the resolution is reconciliation rather than distributed transactions. See reconciliation and breaks.
Ordering and time. Financial systems care about when something happened, and clocks disagree. A ledger needs a defensible notion of sequence, and the distinction between the time an event occurred, the time it was recorded and the value date it applies to is not pedantry; it determines interest, settlement and what the regulator sees.
Retention and queryability. Ledgers grow without bound and are never deleted. A design that performs well at ten million postings may be unusable at ten billion, and the queries an auditor or a finance team needs are different from the ones the product needs.
Why ledgers get rebuilt
Nearly every fintech that survives rebuilds its ledger once. The pattern is consistent enough to plan for.
The first ledger is built quickly inside the product, usually by the founding engineers, to support one flow. It works. Then the company adds a second product, a second currency, a partner bank, a lending book, or a regulatory requirement to report positions in a particular way. Each addition is accommodated with a special case, until the special cases outnumber the rules and nobody can say with confidence what the system guarantees.
The rebuild usually triggers on one of four events: an audit the team cannot answer, a reconciliation break nobody can explain, a new product the ledger cannot represent, or a funding round that makes the risk unacceptable to the board.
This matters for hiring, and it is the point most briefs miss. Building a first ledger and rebuilding a live one are different jobs. The rebuild requires someone who can run the new system in parallel with the old, migrate history without losing auditability, and cut over without downtime on a system where downtime means payments fail. That is a specific and much rarer skill than designing a schema.
Period close, and the thing nobody designs for
A ledger has to support a close: a point at which a period is declared final, balances are fixed and reported, and subsequent corrections are handled as adjustments to a closed period rather than as edits.
This is almost never designed in up front, and retrofitting it is painful. The requirements are specific. Postings need an accounting date distinct from their system timestamp, because a transaction that occurred on the last day of a period may arrive after the period closed. There needs to be a mechanism to freeze a period. There needs to be a defined treatment for late entries, which usually means posting to the current period with a reference to the original.
Teams discover this the first time finance asks why last month's reported figure changed after it was reported. The answer, that postings were backdated, is not acceptable to an auditor and the fix is architectural.
Multi-currency, when it arrives
Single-currency ledgers are substantially simpler, and most Indian fintechs start that way correctly.
The complexity on adding a second currency is not the conversion arithmetic. It is that a balance now has to be expressed in both its own currency and a reporting currency, at a rate that varies, which means the reporting value of an unchanged balance changes over time. Revaluation becomes a posting of its own. Gains and losses on conversion have to be recognised and attributed.
Retrofitting multi-currency is one of the two most common reasons for a ledger rebuild, the other being the accumulation of product special cases described above. A team planning cross-border within eighteen months should design for it now, even if they do not implement it.
How a ledger is tested
Worth knowing because it is a reliable interview probe.
Unit tests on posting logic are necessary and insufficient. The techniques that distinguish a seriously built ledger are property-based testing, asserting that invariants hold across generated transaction sequences rather than on hand-picked cases; a continuous invariant check in production verifying that debits equal credits and that derived balances match any cached values; and deterministic replay, the ability to rebuild all balances from the posting history and compare against live state.
That last one is the strongest single signal. A team that can rebuild its ledger from history and get the same answer has a ledger. A team that cannot has a database with financial data in it.
Build or buy
The honest position is that this depends on what the ledger is for.
A company whose product is financial infrastructure, where ledger semantics are a differentiator, generally builds. A company where the ledger supports the product but is not the product can often use a ledger service or a core banking provider, and the engineering question becomes integration and reconciliation rather than design.
The decision is frequently made implicitly by whoever is available, which is the worst way to make it. It is a leadership decision with a long shadow, and it belongs with the CTO. See hiring a FinTech CTO in India.
Talent implications
| Role | What they own here | Signal of the real thing |
|---|---|---|
| Principal or staff architect | Ledger design, consistency model, migration strategy | Has rebuilt a live ledger, not only designed one |
| Core platform engineer | Posting engine, idempotency, hot account handling | Can explain their idempotency key and why it is derived that way |
| Head of Platform or VP Engineering | Build versus buy, team structure, the rebuild decision | Has made the call and lived with it |
| FinOps and settlement | Operating the ledger, breaks, period close | Has closed a month on a system they did not design |
| Compliance engineering | Auditability, retention, reporting | Has defended a ledger to an auditor |
Three practical points for a brief.
Ask what they would not do. Strong ledger engineers have strong opinions about mutable balances, soft deletes and storing money as floating point. A candidate who is relaxed about all three has not been burned, which means they have not run one in production.
Separate the design question from the operations question. Many candidates can describe a good ledger. Far fewer have operated one: handled a break at month end, migrated history, explained a discrepancy to a finance team under time pressure. For a rebuild, the operator matters more than the designer.
Do not use generic distributed systems experience as a proxy. The concerns overlap, and an engineer from a high-scale non-financial background will understand consistency and idempotency well. What they will not have is the instinct that correctness beats availability here, which is the opposite of the trade-off most consumer systems teach.
The adjacent guides are how UPI payments work, which generates most of the postings in an Indian consumer fintech, and reconciliation and breaks, which is how a ledger is proved against the outside world. The role this most often maps to is the principal payments architect.
Common questions
Can we just use our application database as a ledger?
For a single flow at low volume, it will appear to work. It fails when you need to explain a historical balance, when a retry creates a duplicate, or when an auditor asks how a number was derived. The cost of the eventual rebuild is substantially higher than building it correctly at the outset, and the rebuild happens while the system is live.
Should balances be stored or computed?
Computed from postings, with caching if performance requires it. A stored balance that can drift from its postings is a defect waiting to surface, and it will surface during reconciliation or an audit rather than in testing. If a cached balance is used, the system needs a continuous check that it still matches the derived value.
What is the most common ledger bug in production?
Duplicate postings from a retried upstream event, caused by an idempotency key that is not actually unique for the logical transaction. It is common because the happy path never exercises it and load testing rarely reproduces the exact partial-failure conditions that trigger it.
How do we assess ledger experience at interview?
Ask the candidate to walk through what happens when a payment is submitted twice with the same reference, then what happens when the second arrives while the first is still in flight. Then ask how they would prove to an auditor that a balance on a date two years ago was correct. Both questions are unanswerable in detail by someone who has not built and run one.
Is a ledger engineer the same as a backend engineer?
In capability, not in instinct. The strongest ledger engineers are backend engineers who have internalised that correctness is non-negotiable and that every system upstream of them is unreliable. That disposition is learned by having been responsible when money moved incorrectly, which is why production experience in a financial system is difficult to substitute for.