Explore the ledger behind proof of funds
Clone the Formance Ledger repository on GitHub to see how double-entry enforcement, immutable hash-chained postings, idempotent connectors, and bi-temporal history are implemented in production code.
When an FCA examiner or your sponsor bank asks, at any time in the past, whether customer money equaled what your banks held for them (per customer, to the cent), you have hours to answer. That answer is proof of funds.
The Financial Conduct Authority (FCA) estimates that payment firms which went insolvent were missing 65% of client funds on average when they went under. Proof of funds is the daily discipline that keeps customer money accounted for, protects insolvency exposure, and gives regulators and sponsor banks the evidence they need to keep you operating.
Fintechs, payment providers, and stablecoin issuers need to know what each party requires and how the ledger produces it. This includes what regulators need, what sponsor banks and banking partners require beyond the regulatory baseline, which ledger properties make proof of funds possible on demand, and how omnibus account attribution produces the per-customer side.
All these obligations start with the payments ledger.
Proof of funds means you can show, for any past date, that the money in your bank and custodian accounts covered what your ledger says you owed customers at that moment.
One side of the equation is the ledger, which includes the per-customer balances plus any holding balance not yet attributed. The other side is what the bank and custodian statements (or connector data) show at the same moment. It is not what your ledger expected them to show. The reconciliation record captures the comparison, the time it ran, and any variance.
Proof of reserves for a stablecoin issuer works the same way: circulating token supply is what you owe holders, and reserve assets at custodians back it.
Formance produces this proof on demand. The open-source Formance Ledger keeps per-customer postings, Connectivity pulls in bank and custodian data, and Reconciliation compares the two and records any variance. All three modules work in one platform that compliance, auditors, and sponsor banks can review.
Regulators want daily reconciliation records under UK CASS 15, segregated customer funds under EU PSD2 Article 10 and MiCA Article 36, and one-to-one stablecoin reserves with monthly reporting under the US GENIUS Act. In every case, you have to own the data model that produces the record.
UK CASS 15 requires fintechs, payment providers, and e-money institutions safeguarding customer funds to run internal and external reconciliations each reconciliation day, keep records for five years, and file a monthly safeguarding return to the FCA. The rules take effect on 7 May 2026.
Each record must include the date and time, the actions taken, and the outcome of the safeguarding calculation. For fintechs and payment providers with D+1 obligations, the record must also include the D+1 requirement compared against the D+1 resource.
The monthly safeguarding return goes to the FCA within 15 business days of month-end, split between e-money funds and unrelated payment services funds. The resolution pack has to be pullable within 48 hours of a request.
EU PSD2 Article 10 requires payment institutions to keep customer funds separate from their own money. MiCA Article 36 requires asset-referenced token issuers to keep each token's reserve separate from every other token's reserve, without setting a daily reconciliation deadline.
Article 10 lets you meet the safeguarding rule by holding funds in a separate account at a credit institution, investing them in secure, liquid, low-risk assets, or covering them with an insurance policy or comparable guarantee.
Under MiCA, Article 36 says the reserve backing an asset-referenced token has to be separated from the issuer's own assets and from every other token's reserve, both legally and operationally.
Our MiCA implementation guide covers the wider reconciliation and reserve-visibility requirements.
The GENIUS Act, signed 18 July 2025 as Public Law 119-27, will require permitted payment stablecoin issuers to back every outstanding token with at least one dollar of identifiable reserve assets and publish what those reserves are made of every month.
A registered public accounting firm must check each month-end report, and the issuer's CEO and CFO must certify that it's accurate.
The Act takes effect 18 months after signing (roughly 18 January 2027), or 120 days after regulators finalize its implementing rules, whichever comes first.
Sponsor banks and banking partners require more than the regulatory baseline. They need additional proof-of-funds evidence tied to each role in your money movement stack.
Sponsor banks hold your customers' money in omnibus accounts on their books, so they need to see the per-customer split behind that omnibus balance. Banking partners move settlements to and from your ledger, so they need reconciliation evidence at the settlement boundary.
Sponsor banks hold customer money in a for-benefit-of (FBO) or omnibus account on your behalf, so they need to see the per-customer split behind the single balance on their books.
Sponsor banks need daily reconciliation of omnibus bank balances against per-customer records in your subledger, plus direct read access to that subledger without an engineer running a query.
They also require documented beneficial ownership records for every underlying customer and independent periodic validation of the reconciliation.
Banking partners (PSPs, custodians, open-banking providers, and BaaS platforms) sit between you and the money movement rails, which means they see every settlement before you do.
Banking partners need a reliable settlement feed with per-transaction attribution, a documented resolution path when a settlement doesn't match your ledger, and beneficial ownership records available on request.
Four properties have to hold at the same time: programmatic double-entry enforcement for balanced customer postings, immutable ledger evidence for reconciliation audits, connector idempotency to prevent duplicate deposit postings, and bi-temporality for point-in-time ledger reconstruction.
When the ledger enforces double-entry, every internal transaction is a matched set of postings that balances by construction so that no customer credit can be posted without an offsetting source.
Internal balances still have to be checked against the actual bank and custodian balances, using the external data brought in through Formance's Connectivity and Reconciliation modules.
Without ledger-enforced double-entry, orphan values appear, such as a customer credit with no matching source, which the spreadsheet shows as an unexplained shortfall.
Immutable ledger records cannot be changed after the fact, so a regulator, sponsor, or partner sees the same postings and history that were used for the original comparison.
Postings are never edited or deleted, so a correction is a new transaction that offsets the original one, and both stay visible. Hash-chaining each transaction to the previous one makes any tampering show up.
If the underlying records can be edited, a comparison re-run does not prove anything about the reconciliation day.
Connector idempotency, a safe-retry guarantee, means a retried deposit does not credit the same customer twice, so per-customer balances stay accurate when bank or custodian integrations retry an event.
Every inbound event needs a unique ID that the integration checks against before posting. Without it, duplicate postings inflate customer liabilities, and the difference looks like money that was never actually missing.
Bi-temporality, a built-in Formance Ledger feature, records both when an event was posted and when it was effective, so the internal ledger can be rebuilt as of any past cut-off and matched against the dated external position from reconciliation.
The D+1 segregation check and the GENIUS month-end report all use the same method, but only the timestamp changes.
A bank statement line that arrives Wednesday but settled Tuesday belongs to Tuesday's proof of funds record.
You produce per-customer proof of funds by recording who owns every dollar in the omnibus account the moment funds land, so the "who owes what" side of the equation is real ledger data.
Every reported inflow gets split into per-customer postings (or into a holding account if the sender is not yet known) in one atomic transaction at posting time.
The bank sees one omnibus balance in the omnibus account, while the per-customer split lives only in your customer subledger.
The proof-of-funds calculation adds customer balances and holdings in the subledger, then compares that total to the external omnibus balance the bank reports.
Take a PSP settlement of $1,250,000 landing in a USD omnibus account. The connector delivers the credit with a settlement report that assigns $780,000 to customer 4471 and $462,500 to customer 9082. The remaining $7,500 has no reference.
Written in Numscript, the language Formance Ledger uses for atomic multi-destination postings, the same pattern works in any double-entry ledger that supports atomic multi-party transactions.
// OMNIBUS_ATTRIBUTION
// Event: attribute a $1,250,000 PSP settlement to customers and holding
send [USD/2 125000000] (
source = @platform:banks:omnibus:usd allowing unbounded overdraft
destination = {
[USD/2 78000000] to @customers:4471:available
[USD/2 46250000] to @customers:9082:available
remaining to @platform:holding:unattributed
}
)
set_tx_meta("event_type", "omnibus_attribution")
set_tx_meta("bank_reference", "PSP-SETTLE-2026-09-16-0417")
set_tx_meta("omnibus_account", "platform:banks:omnibus:usd")
set_tx_meta("value_date", "2026-09-16")The omnibus_account tag is just a label showing which external bank account the money came into. It doesn't create a new ledger account. The $7,500 sits in a holding account as money not yet assigned to anyone.
CASS 15 still counts this money as part of what you need to safeguard, so proof of funds covers it while you figure out who it belongs to.
Once you know who sent the money, a second transaction moves it to that customer's account. The original posting stays exactly as it was, so the audit trail stays clean.
Add up every customer account and the holding account at a specific point in time, then compare that total to what the bank reports in the external banks:omnibus:usd account at the same moment. The two numbers should match exactly.
Address these 12 questions to meet your obligations to regulators, sponsor banks, and banking partners, and to satisfy the underlying ledger requirements.
Every question maps to something a ledger has to do by design.