Test Formance Ledger against your own flow
Clone the Formance Ledger on GitHub, deploy it locally, replicate a posting your production system handles today, and time how long it takes from clone to first successful transaction.
Every fintech or platform team eventually has to answer the same question: what should the ledger, the system of record for who owns what, actually be?
Three options are on the table: build one in-house, buy a closed-SaaS product, or adopt an open-source core ledger.
This guide walks through when each option is the right call and the five checks that settle the decision.
Six factors separate the three ledger options: build in-house, buy closed SaaS, and buy an open-source core. Those six factors are time to first posting, correctness enforcement layer, regulatory reporting effort, code access and self-hosting, ongoing maintenance burden, and exit/migration cost.
| Factors | Build (in-house) | Buy: closed SaaS | Buy: open-source core (self-hosted) |
| Time to first posting | Quarters to years | Days to weeks | Days to weeks |
| Correctness enforcement layer | Application code the team writes and owns | Vendor's storage layer, opaque | Storage layer, source-readable |
| Regulatory reporting effort | Built per mandate, per report | Vendor-shipped, coverage varies | Vendor-shipped, extensible in source |
| Code access and self-hosting | Full access, self-hosted by default | No source access, vendor-hosted | Full source access and self-hostable |
| Ongoing maintenance burden | Full team ownership, compounds with volume | Vendor-absorbed | Shared: upgrades owned and core maintained upstream |
| Exit/migration cost | N/A (you are the system) | High: proprietary schema, contractual exit | Low: portable data, source in hand |
In short: building trades quarters or years of engineering time for full ownership, closed SaaS trades code access and portability for speed, and open source delivers the same speed while keeping the source readable and the data portable.
Build the ledger in-house only when the ledger is the product, no external system meets your throughput or data-model needs, the team has operated financial ledgers in production, and the team is funded permanently.
An in-house build is justified when customers pay for the account tree and the ledger behavior defined by the postings model and transaction language. For lending and marketplace products, the ledger is background infrastructure the product runs on, not something customers notice or pay for. The same is true for payouts, and a team that builds it anyway spends its differentiation budget on infrastructure nobody pays for.
Prove that no existing ledger can handle the required transaction volume or the way the data is structured. A useful test is what happens when many updates hit the same account at once, for example hundreds of transactions per second on a single high-traffic account.
Some existing ledgers batch those updates together instead of processing them one at a time, which keeps balances correct without slowing down. If the in-house build can't clear that same bar using real production numbers, not a rough estimate, this condition isn't met.
Production ledger experience is mandatory. Strong backend generalists aren't the same qualification. Ledgers fail in ways typical services don't (double-posting on retries, running totals that drift under concurrent writes, and corrections rewriting history), and those failure modes tend to surface at month-end close or during a regulator's spot check, when the money is already out the door. A team learning double-entry on live customer funds discovers those failure modes the expensive way.
Two to three engineers at the $133,080 BLS median (May 2024) is roughly $266,000 to $399,000 a year in base wages, before benefits or overhead. It's a permanent headcount line, since a ledger keeps needing engineers for as long as it keeps taking postings. Budget for the team that maintains it, not just the team that ships it.
Opting for a closed SaaS ledger is the right call only when a vendor passes on three requirements: storage-layer correctness, regulatory reporting shipped from the ledger itself, and managed operations that justify giving up code access and exit flexibility. If a vendor falls short on even one requirement, a closed SaaS ledger is not the ideal choice.
The application boundary enforces double-entry invariants and idempotency, so no service has to re-implement them.
Confirm the SaaS vendor can point to the exact line of code where a double-posting gets rejected. A vendor that can't show you that enforcement point is asking you to trust a black box.
CASS 15, FCA safeguarding, and DORA are produced from the source of truth without a downstream reporting pipeline. If a regulator asks for a CASS reconciliation, a safeguarding return, or a DORA incident report, the ledger should answer directly from its own postings. If the answer instead requires pulling data through a separate reporting tool or a finance team's spreadsheet, that extra step is exactly where numbers go out of sync with the ledger.
Closed SaaS ledgers absorb infrastructure operations, upgrades, and regulatory patches, so the buying team runs zero on-call for the ledger. The vendor carries the operational load your team would otherwise own, and compliance patches ship as part of the service rather than as a project your team has to run.
Buying an open-source ledger is the right move for four reasons. It turns payment rails expansion into configuration, collapses time-to-first-posting from quarters to days, drops reconciliation drag to near-zero, and removes the lock-in premise behind buying in the first place.
Adding a payment rail or a new asset type is a configuration change on an open-source core ledger built for multi-rail and fiat-plus-digital-asset support.
Engineering teams should check whether the ledger core separates rail-specific logic from the posting schema itself. If adding a rail still touches ledger core account structures, the "configuration change" claim isn't viable.
First-posting time drops from quarters to days when the ledger is already built, so engineering time shifts from building and maintaining the ledger to the product surface.
Watch for setup steps that still require deep familiarity with the ledger's internals. A genuinely fast time-to-first-posting shouldn't depend on the team that built it being the only ones who can maintain it.
Reconciliation is an add-on module. But because it runs against the ledger's own postings rather than a separate copy or export, adding it later doesn't introduce a second source of truth the way a bolted-on reconciliation tool would.
Confirm any reconciliation module you add reads directly from the ledger's postings. A second source of truth brings back the drift this is supposed to remove.
Open source removes the lock-in premise behind buying by shipping the core ledger under an MIT license, with documented module licensing, readable source, and day-one self-hosting.
An engineering lead can clone the repository, read the enforcement code, and run the ledger against a real account structure before any sales conversation happens.
An open-source ledger like Formance gives a team auditable ledger infrastructure while keeping control, code access, and self-hosted deployment.
Use these five checks to help decide whether you should build or buy a ledger: write-time correctness, regulatory rules, adding new payment rails, senior-engineer capacity, and migration cost.
The first two are must-pass checks that no regulated entity can waive, while the last three compare the two options. Fail any check, and buying, preferably an open-source core, beats building.
Enforce correctness where the posting commits, including double-entry balance, idempotency for retries, and checks that amounts look right. All belong at the posting layer.
Here's what that looks like in practice. The transaction below is written in Numscript, Formance's ledger DSL, and it shows how you can move $2.5 million from @world into an omnibus settlement account, then to a user's available balance, in one atomic transaction.
// PSP_SETTLEMENT
// Event: attribute a $2.5 million PSP settlement through the omnibus account to user 88412
// $amount is injected at execution time via the API's script.vars field
// Idempotency-Key header on the API call prevents this transaction from posting twice
vars {
monetary $amount
}
send $amount (
source = @world
destination = @omnibus:psp_a:settlement
)
send $amount (
source = @omnibus:psp_a:settlement
destination = @users:88412:available
)
set_tx_meta("event_type", "psp_settlement")
set_tx_meta("settlement_id", "stl001")
The vars block declares types only; the caller supplies $amount at execution time by passing {"amount": "USD/2 250000000"} in the request body's script.vars field, per the Numscript variables reference. The transaction balances by construction and fails atomically: no state exists where the omnibus account is debited, and user 88412 is never credited. The Idempotency-Key header stops a retried request from posting twice.
Three mandates make up the regulatory rules for a ledger, and the ledger must serve each mandate from its own postings.
To determine your regulatory rules, ask whether your ledger produces each output on demand today from its own postings.
A ledger scoped to two rails and one currency rarely survives a dozen rails plus fiat and digital assets. Rail-specific assumptions leak into the posting code, each new provider forks the schema, and new asset types force parallel account trees.
Run this test: how many codes must change to add one payment rail, and how many to add one new asset type?
Set a numeric threshold, for example, four senior-engineer weeks per quarter, above which ledger upkeep displaces roadmap work you cannot ship elsewhere.
The engineers qualified to maintain a homegrown ledger are, almost by definition, the engineers you most need on the product surface. Ask your team: how many senior-engineer weeks per quarter went to ledger upkeep in the last two quarters, and how does the number compare to your threshold?
Migration/exit cost is the consideration most build decisions omit, and the bill arrives years later. Migration risk compounds when the target system's schema is proprietary, the source is unreadable, and no shadow-mode path exists to compare balances before cutover. Weigh what migrating away or exiting the vendor relationship would cost you.
Any fail on a pre-check (Checks 1–2) means stop building the ledger. The ledger must enforce write-time invariants and produce reconciliation and regulatory requirements on demand, or it fails the next audit.
Any fail on Checks 3–5 means the homegrown ledger is no longer paying for itself. Schema forks compound with each new rail, and the senior engineers you need on product are consumed by upkeep instead.
Either failure signals whether an open-source ledger closes the gap before you sink more engineering time into the one you have.