Core banking ledger

A core banking ledger is the system of record for balances and movements of money: which account holds what, what moved where, when, and why. Everything else in a financial product — payments, cards, statements, interest, fees — is an instruction to the ledger or a report from it.

Why it is the decision that outlives the others

Providers get changed. Card processors get swapped. The ledger is where your history lives, and history is not portable in the way an API integration is. If the ledger belongs to your banking partner, then changing partner means migrating every balance and every historical transaction, usually while the product is live.

This is why "who owns the ledger?" is the question that separates an arrangement you can leave from one you cannot.

Owned, rented or hybrid

• Provider's ledger. Fastest to launch, nothing to build, and the least portable. Your data model is theirs.
• Your own ledger. You run a ledger and treat the provider as a payment and licence rail, reconciling against them. More engineering, far more control, and migration becomes a reconciliation exercise rather than a rebuild.
• Hybrid. A shadow ledger mirroring the provider's, built primarily for reconciliation and reporting, that can later become the primary record.

What to evaluate

Double-entry discipline and immutability — can a balance ever be edited rather than corrected by an entry? Multi-currency handling. Support for holds, pending authorisations and reversals, which card products require. Idempotency on writes. Reconciliation tooling against external statements. Export: can you get a complete, usable history out, and in what format? And throughput at your projected peak, tested rather than quoted.

Related terms

A sub-ledger tracks balances beneath a single real account — the mechanism behind most pooled-account products. A virtual IBAN is the addressing layer that routes incoming payments to those sub-ledger positions.