Double-entry, always balanced
Every movement posts equal debits and credits. Balances are derived from entries, never edited in place — so the books cannot silently drift.
The ledger is the product.
Every wallet, transfer, and payout in a Mozaca product resolves to one place: an event-sourced, double-entry ledger that reconciles continuously against partner records and leaves signed evidence for every movement. This is the part a regulated buyer diligences first — so we lead with it.
Built for what comes next.
The question every fintech buyer now asks first.
In 2024 a major banking-as-a-service middleware collapsed and froze roughly a quarter of a billion dollars of end-customer money — not because a rail failed, but because its internal ledger never reconciled with the partner bank's records, and no one could prove who was owed what. Regulators now expect daily, per-beneficiary reconciliation. So the first question a serious buyer asks an infrastructure vendor is no longer “how fast is your API?” — it is “does your ledger reconcile with the bank's, and can you prove it?” Mozaca is built to answer yes.
What the ledger actually is.
Not a report that runs at night — a live, append-only system of record that every product surface reads and writes through.
Event-sourced & immutable
The ledger is an append-only log of events. Nothing is overwritten; corrections are new, signed entries — giving you a replayable history of exactly what happened and when.
Real-time balances, no batch
Available, held, and pending balances update as events arrive. There is no overnight batch window where the truth is unknown.
Holds, reversals & provisioning
Authorizations, holds, reversals, and account provisioning are first-class ledger operations with duplicate protection built in.
Per-beneficiary sub-ledger
Pooled and settlement balances are sub-ledgered down to the individual customer, so every shilling is attributable to a named owner.
Multi-rail, multi-currency
Fiat, mobile money, and approved digital-asset balances share one balance model — one source of truth across every rail a product touches.
One transfer, five provable steps.
The ledger sits at the center of Mozaca's lifecycle — the point where an intention becomes a balanced, reconciled, provable fact.
- 01
Initiate
A funded balance and the intended movement are captured on the wallet.
- 02
Policy
Role, limit, counterparty, KYC, and sanctions checks clear before money moves.
- 03
Route
The transfer is routed across the selected rail with settlement state surfaced.
- 04
Ledger
Double-entry journals post and reconcile — the balance source of truth updates.
- 05
Proof
Receipt, webhook, export, and hash-chained audit record close the loop.
The controls that make it provable.
Six controls that turn “we have a ledger” into “we can prove, per customer and per partner, that the books are right.”
Continuous reconciliation
Ledger, bank, mobile-money, and provider events are matched continuously against partner and settlement records, with exception queues surfacing drift as it happens — not at month-end.
Reconciles to the partner, not just to itself
The failure that froze customer funds elsewhere was an internal ledger that never reconciled to the bank's. Mozaca treats reconciliation against external partner records as the load-bearing control, not an afterthought.
Per-client isolation
Brand, data, policy, and rail configuration are scoped per deployment. One client's balances, keys, and evidence never share a boundary with another's.
Signed, correlated evidence
Every meaningful state change leaves a hash-chained, correlation-ID'd record linking ledger journal, rail callback, webhook, and receipt — the same event, provable from any side.
Audit-ready exports
Statements, journals, chart-of-account mapping, and audit packs are generated from the reconciled ledger, so what an auditor receives is what the system actually did.
Recoverability by design
Because state is an event log, position at any historical moment can be reconstructed — the basis for contingency, dispute resolution, and regulatory reconstruction.
Reconciliation, isolation, and evidence behaviour are configured per client, market, and partner path during implementation. Exact control coverage for a given deployment is confirmed in scoping and diligence.
Evaluating Mozaca as your ledger of record? Ask for the reconciliation and isolation walkthrough — how continuous matching, per-beneficiary sub-ledgering, and signed evidence work end to end.
See the ledger in the wider platform → Ledger Engine · Trust & security
FOLLOW THE FINANCIAL RECORDTHE DETAILS THAT MATTER
From movement to a balanced journal.
A transaction should remain explainable after the screen changes, after the provider responds, and after the reporting period closes.
PRODUCT EXPERIENCEIllustrative data
Built around the workflow.Designed for the operator. ↗
Record the financial effect
Distinguish instruction state from the financial entries that affect balances, fees, holds, and settlement.
A clear accounting interpretationMatch the external evidence
Connect the internal payment reference with provider records, bank or rail events, and reconciliation results.
A traceable matching processKeep exceptions actionable
A difference needs an owner, context, supporting records, and a resolution path—not an unexplained balance adjustment.
Reviewable financial operationsIs a payment marked submitted the same as settled?
No. Submission is an instruction state. Settlement confirmation depends on the configured rail and provider behavior. Reconciliation then connects the financial record to the external evidence.
What should finance teams inspect in a walkthrough?
Ask to follow a payment reference across the account balance, journal, fee, provider confirmation, reconciliation state, receipt, and reporting export.
KEEP EXPLORING