Core banking versus ledger versus payment hub

“Core banking”, “ledger” and “payment hub” are frequently used as if they were the same thing. They are not. A core banking system runs banking products and account servicing. A double-entry ledger is the accounting system of record for balances and movements. A payment hub orchestrates payments across rails. Confusing them leads to architectures where accounting logic leaks into payment code, or where a “ledger” cannot actually reconcile. This guide separates the layers and explains the design details — balances, holds, posting, reconciliation and events — that determine whether the whole thing holds together.

System of record

The system of record is the authoritative source for a given fact — the definitive answer to “what is the balance?” or “did this payment happen?”. Clarity about which system owns which fact is the foundation of the architecture. When two systems both claim to own balances, you get reconciliation disputes and data drift. Decide explicitly what is authoritative for each fact before choosing products.

Double-entry ledger

A double-entry ledger records every movement as balanced debits and credits across accounts, so the books always balance. It is the accounting system of record for balances and movements. A ledger is not a core banking system and not a payment hub: it does not run banking products or move money on rails — it records the accounting truth of what happened. Keeping the ledger focused on accounting keeps it trustworthy.

Core banking

A core banking system runs banking products and account servicing: opening accounts, applying product rules, handling interest and fees, and maintaining customer-facing account state. Core banking typically has a ledger inside or beside it, but the terms are not interchangeable — “core banking” describes the product and servicing platform, while “ledger” describes the accounting layer. Treat them as distinct even when one vendor supplies both.

Product engine

A product engine defines and applies the rules of financial products — account types, limits, fees, interest and eligibility. Separating the product engine from the ledger lets you change product behaviour without rewriting accounting logic. The product engine decides what should happen; the ledger records what did.

Account service

An account service manages account identity and state: which accounts exist, their status, and their relationships to customers. It sits alongside the ledger (which holds balances) and the product engine (which holds rules). Keeping account identity separate from balances makes both easier to reason about.

Payment hub

A payment hub orchestrates the movement of money across payment rails — routing, format translation, scheme messaging and status tracking. It is not the accounting system of record; it initiates and tracks payments, then posts the resulting movements to the ledger. Keeping the hub distinct from the ledger prevents payment plumbing from corrupting your accounting truth. See add accounts and IBANs for how account and rail access relate in provider selection.

Orchestration

Orchestration coordinates a payment across its steps and across systems: validating, screening, routing to the right rail, handling responses and exceptions, and updating state. Payment orchestration lives in or beside the payment hub, distinct from accounting. Well-defined orchestration makes failures visible and recoverable rather than silent.

General ledger

The general ledger (GL) is the top-level set of accounts summarising the financial position. In a fintech architecture, the operational ledger often feeds the GL. The GL answers financial-reporting questions; the operational ledger answers transaction-level questions. Define how detail rolls up so the two always agree.

Subledger

A subledger holds detailed accounting for a subset of activity (for example, customer balances) and summarises into the general ledger. Subledgers keep transaction-level detail out of the GL while preserving a reconcilable link. Design the mapping from subledger to GL deliberately so reconciliation is provable.

Available and booked balances

Booked balance reflects settled, posted movements; available balance reflects what a customer can actually use, accounting for holds and pending items. These are different numbers and must be modelled explicitly. Showing a booked balance where an available balance is needed (or vice versa) causes overspend, failed payments and confused customers.

Holds and reservations

A hold (reservation) sets aside funds for a pending transaction — for example, a card authorisation — reducing available balance before the movement posts. Holds must be tracked, aged and released or captured correctly. Orphaned holds silently strand customer funds and are a common operational defect.

Idempotency

Payments and postings must be idempotent: retrying the same request must not create duplicate movements. Network retries, timeouts and client resubmissions are inevitable, so every money-moving operation needs an idempotency key and deduplication. Without it, you get double postings and reconciliation breaks. This is a first-class design requirement, not an optimisation.

Posting rules

Posting rules define how a business event translates into ledger entries — which accounts are debited and credited, in what amounts. Encoding posting rules explicitly (rather than scattering them through application code) keeps accounting consistent and auditable. Changes to posting logic should be governed like any accounting change.

Reversals

Reversals undo or correct a previous movement. In a double-entry system, a reversal is itself a set of balanced entries, not an erasure — the original stays visible for audit. Design reversals, corrections and adjustments explicitly, because ad-hoc fixes to balances destroy auditability.

Reconciliation

Reconciliation confirms that your ledger agrees with external records — bank statements, scheme settlement files, partner reports. It is the routine check that your accounting truth matches reality. Design for reconciliation from the start: consistent identifiers, matchable records and clear handling of breaks. Reconciliation that is bolted on later is painful and error-prone.

Multi-currency accounting

Multi-currency accounting requires holding balances per currency, recording the currency of each movement, and handling conversion explicitly. Mixing currencies in one balance, or converting implicitly, corrupts the books. Model currency as a first-class attribute of accounts and movements.

Interest and fees

Interest and fees are business events that must post to the ledger like any other movement, driven by the product engine and recorded with the same rigour. Calculating them outside the ledger and injecting balances directly breaks the double-entry discipline. Route them through posting rules.

Events and audit trail

An event log records what happened, when and why, and underpins both integration (other systems react to events) and audit (you can reconstruct history). A complete, immutable event trail is essential for operational resilience and investigation — a concern reinforced by the operational-resilience framework in the Digital Operational Resilience Act, which covers ICT risk management, incident handling and resilience of these systems 1. Design events and audit as core features, not add-ons.

Build versus buy

You can build these systems, buy them, or combine. A double-entry ledger looks deceptively simple but is easy to get subtly wrong; core banking and payment hubs are large undertakings. Decide per layer based on how core it is to your differentiation, how fast it must evolve, and your team’s capacity — using a structured process such as fintech provider due diligence and RFP.

Migration

Migrating between core banking systems or ledgers is high-risk: balances must be moved without loss or duplication, history preserved, and cutover managed with reconciliation at every step. Plan migration as a project in its own right, with dual-running and reconciliation, not a single switch. The consequences of a bad migration last for years.

Architecture diagrams

The following text diagram shows how the layers relate:

Layer	Owns	Talks to
Account service	Account identity and state	Product engine, ledger
Product engine	Product rules, fees, interest	Account service, ledger
Double-entry ledger	Balances and movements (system of record)	Subledger, general ledger
Payment hub	Payment orchestration across rails	Ledger, external rails
Event log / audit	History of what happened	All layers

Comparison table

Aspect	Core banking	Double-entry ledger	Payment hub
Primary purpose	Run banking products and servicing	Record accounting truth	Orchestrate payments across rails
System of record for	Account/product state	Balances and movements	Payment status
Moves money on rails	Sometimes (via hub)	No	Yes
Core concern	Products, accounts, servicing	Debits/credits, balances	Routing, formats, scheme messaging
Not the same as	A ledger	Core banking	A ledger

• System of record defined for every key fact
• Ledger kept distinct from core banking and payment hub
• Available vs booked balances modelled explicitly
• Holds tracked, aged and released/captured correctly
• Idempotency keys on every money-moving operation
• Posting rules encoded explicitly and governed
• Reversals designed as balanced entries, not erasures
• Reconciliation designed in with matchable identifiers
• Multi-currency modelled as a first-class attribute
• Event log and audit trail treated as core features

Questions to ask providers

• Which system is the authoritative system of record for balances, and for payment status?
• Is your product a core banking system, a ledger, a payment hub — or a combination?
• How do you model available versus booked balances and holds?
• How is idempotency enforced across money-moving operations?
• How are posting rules defined, and how are reversals handled?
• What reconciliation capabilities and identifiers do you provide?
• How is multi-currency accounting handled?
• What event and audit-trail capabilities exist for resilience and investigation?
• What does a migration onto (and off) your platform involve?

Common failure modes

• Using “ledger” and “core banking” interchangeably and building accordingly.
• Letting payment-hub logic write balances directly, bypassing the ledger.
• Showing booked balance where available balance is required.
• Orphaned holds that strand customer funds.
• Missing idempotency, causing duplicate postings on retries.
• Adjusting balances ad hoc instead of posting balanced reversals.
• Treating reconciliation and audit as afterthoughts.

What this does not cover

This guide explains how these systems differ in general architectural terms. It does not evaluate specific products, does not determine whether an architecture is compliant for your institution, and does not make operational-resilience determinations under any regulation. It complements — but does not replace — architectural, accounting and regulatory advice tailored to your systems.

FAQ

Is a ledger the same as a core banking system?

No. A double-entry ledger is the accounting system of record for balances and movements. A core banking system runs banking products and account servicing. They are distinct layers, even when one vendor supplies both.

What does a payment hub do that a ledger does not?

A payment hub orchestrates money movement across payment rails — routing, format translation and scheme messaging. The ledger records the accounting result of those movements but does not move money on rails itself.

Why do available and booked balances differ?

Booked balance reflects settled, posted movements; available balance subtracts holds and pending items to show what a customer can actually use. Treating them as one number causes overspend and failed payments.

Why is idempotency so important?

Retries, timeouts and resubmissions are inevitable, so money-moving operations need idempotency keys to avoid duplicate postings. Without idempotency you get double movements and reconciliation breaks.

How risky is migrating core banking or ledger systems?

High. Balances must move without loss or duplication, history must be preserved, and cutover needs reconciliation at every step. Plan migration as its own project with dual-running, not a single switch.