A fintech product needs an internal ledger even when a bank holds the funds.
When a fintech product is built on a banking partner, the partner bank holds customer funds and the regulated licenses, usually in pooled or for-benefit-of accounts. The bank knows the total in those accounts. It often does not know, in the detail the product needs, how that total divides among customers, pending transactions, fees, and reserves. That breakdown is the job of the product’s ledger.
Designing the ledger starts with double-entry accounting: every movement is recorded as balanced debits and credits across accounts, so money is never created or lost inside the system. Customer balances are derived from entries rather than stored as editable numbers. That makes every balance explainable by the transactions behind it.
Some banking-as-a-service providers and partner banks offer a ledger through their platform, and dedicated ledger products exist. Using one can be sensible, but the product still needs a clear model of accounts and entries that matches its features. The design questions in this guide apply whether the ledger is built, bought, or provided by the partner.
Model accounts, entries, and transaction states before writing code.
Start with a chart of accounts for the product: customer accounts, the pooled account at the bank, settlement accounts for each payment network, fee revenue, reserves, and suspense accounts for money that cannot yet be matched. Every product feature, such as a card purchase, transfer, refund, or fee, becomes a defined pattern of entries between these accounts.
Money movements pass through states. A card authorization holds funds before it settles, and an ACH transfer is initiated, submitted, settled, and sometimes returned. Record pending and posted amounts separately, so the product can show an available balance and a settled balance accurately. Define what happens on every failure, reversal, and return, not just the successful path.
Entries should be immutable. Corrections are new entries that reverse or adjust earlier ones, never edits or deletions. Each entry carries a timestamp, a reference to the originating event, such as a network message or partner webhook, and an idempotency key so the same event processed twice cannot post twice. These properties make audits and investigations possible.
Reconcile the ledger against the partner bank every day.
Reconciliation compares the ledger with what the bank and payment networks report. The sum of customer balances and other liabilities should match the balance in the pooled accounts after accounting for items in transit. Individual transactions should also match the partner’s transaction records. Differences must be investigated, explained, and resolved with an entry, not ignored.
Automate matching using the partner’s reports, files, and APIs, and send unmatched items to a queue with enough context for operations staff to resolve them. Track how long unmatched items stay open. Partner banks and program managers expect evidence that reconciliation happens reliably, and oversight reviews often ask how differences are found and handled.
Design the ledger so reconciliation is straightforward: store the partner’s identifiers on every entry, keep settlement dates separate from event dates, and record fees and network adjustments explicitly. A ledger that cannot be reconciled easily will create operational work and questions from the partner, however well the rest of the product performs.
Controls, access, and audit trails matter as much as the data model.
Limit who can post manual entries, and require review by a second person for adjustments above set limits. Log every manual action with the person, time, and reason. Separate the people who initiate money movements from those who approve them. These controls protect customers and are standard expectations in partner bank and compliance reviews.
Treat the ledger as the system that answers questions from customers, the partner bank, auditors, and regulators working through the partner. It should be possible to reconstruct any customer balance at any past date and show the entries behind it. Reporting should come from the ledger, not from separate spreadsheets that can drift.
Compliance obligations for money movement, consumer protection, and record keeping depend on the product and the partner program. Licensed partners hold the funds and the licenses, and their program requirements shape the ledger. Confirm obligations with the partner bank and your compliance and legal advisers early, since they affect data retention, reporting, and dispute handling.
Build the ledger early and keep its scope narrow.
The ledger is hard to add after launch, because every feature that moves money depends on it and migrating live balances is risky. Design it before building payments, cards, or transfers, even if the first version supports only a few transaction types. A small, correct ledger is far more valuable than a broad one with unclear rules.
Keep the ledger separate from product features. Payment, card, and transfer services should submit events to the ledger through a narrow interface rather than writing balances directly. That separation makes testing clearer and lets new products reuse the same accounting rules. Test with realistic sequences, including returns, disputes, partial refunds, and duplicate webhooks.
Before choosing whether to build, buy, or use the partner’s ledger, write down the account structure, transaction types, states, and reconciliation sources the product needs for its first release. That document lets you compare options on real requirements and gives the partner bank, auditors, and any development partner a shared reference for how money moves through the product.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project