Post your first ledger transaction
Clone the Formance Ledger on GitHub, run it locally, and test the ledger layer behind your cloud-based core banking stack.
The ledger is the one component of a cloud-based core banking stack you cannot outsource.
The stack bundles account opening, card issuing, payment rails, and a ledger into one hosted stack, and when the other components fail, the ledger still records who owns what.
Choosing that cloud-based core banking system means choosing the ledger underneath it, and that is a build-vs-buy decision with three options: build in-house, buy proprietary, or buy open-source.
This article covers the four mechanisms the ledger must enforce, the signals that point to build or buy, a side-by-side comparison of the three options, and six questions to run against your current ledger before you commit.
Cloud-based core banking is delivering a bank's core operational stack (accounts, ledger, payments, card issuing, and customer data) as a hosted service running on cloud infrastructure.
The vendor runs the platform, ships upgrades continuously, and exposes the stack through APIs. The bank consumes the platform under a subscription or usage-based contract instead of a perpetual license and a data center.
Three properties separate a cloud-native core banking system from a legacy model:
Opening an account, posting a transaction, checking a balance, and sending a payment all run through documented APIs, so product teams can build against the core banking system without waiting on the vendor's release schedule.
The vendor sizes the infrastructure to match transaction load, so the bank does not plan capacity for peak days or provision servers in advance.
New features, security fixes, and regulatory updates reach every customer on the vendor's release schedule, without a migration project on the bank's side.
Underneath the API-first access, elastic infrastructure, and continuous delivery sits the ledger, which records every posting, enforces double-entry, and holds the authoritative balance for every account the platform serves.
A cloud-based core banking system needs a ledger with four mechanisms, including idempotency, bi-temporality, omnibus attribution, and reconciliation. Underneath all four mechanisms is double-entry accounting, the constraint that every posting has equal debits and credits so total balances across the ledger always sum to zero.
Without double-entry enforced at write time, a "missing" credit or a duplicated debit lands in the balances and only surfaces during reconciliation or an audit. Double-entry enforced at write time underpins the four mechanisms.
Idempotency means one payout maps to one posting, no matter how many times the request retries. Without it, two identical retries can arrive at the same moment, both pass the "have I seen this key" check, and the payout posts twice.
Duplicated payouts cost real money, and they happen exactly when the system is degraded and retrying most aggressively.
A cloud-based core banking system needs a ledger with idempotency enforced at the storage layer because the ledger records the payout event while a connected payment provider (PSP, bank, or custodian) executes the transfer.
The ledger is the only place that can catch a duplicate record before it turns into a duplicate real-world payout.
Bi-temporality lets your ledger answer what it knew at any point in time by tracking both when an event was recorded and when it was effective.
Without it, a backdated correction lands against a balance that has transferred funds and has already been consumed for interest accrual or fee assessment, and the ledger can't reconstruct the balance.
A ledger needs bi-temporality from the first release because retrofitting it later means rewriting live history tables to separate recorded time from effective time.
Omnibus fund attribution maps your sponsor bank's single omnibus balance to per-customer ownership in your subledger. The omnibus balance at your sponsor bank is a single number, while per-customer ownership exists only in your subledger.
Internal settlement and per-customer attribution postings must therefore commit as one atomic ledger transaction. When your subledger and your sponsor bank balance diverge, you hold funds you can no longer allocate to a named customer.
A ledger needs correct subledger attribution enforced as one atomic transaction so per-customer balances always sum to the omnibus balance at the sponsor bank.
Reconciliation is the enforced comparison between your ledger and each payment rail's settlement file.
Drift starts the moment a settlement file schema changes without notice. A parser written against the old schema produces mismatches that only surface at close, and a formatting change gets misclassified as a balance break.
Because settlement files change without warning and rails fail partially, the ledger layer needs reconciliation modeled as state-machine verification of payment lifecycles.
Row-by-row matching cannot distinguish a missing state transition from an ingestion or normalization error. Reconciliation keeps the idempotency, bi-temporality, and omnibus fund attribution optimal after the ledger goes live.
Build a ledger in-house only when it is a competitive differentiator, you have a dedicated infrastructure team, you face regulatory custody or data-residency demands, and you can sustain permanent maintenance costs
Build the ledger only if how money moves is part of what customers are paying for.
A marketplace that splits every payout across sellers, platform fees, and referrers on custom rules is selling the ledger schema itself, so the fund-attribution model is a competitive differentiator.
A B2B SaaS collecting subscription payments through Stripe is not. It is a standard ledger that records the money, but the customer never sees it.
A standing infrastructure team must be hired and accountable for the ledger before the first customer transaction posts. The four mechanisms (idempotency, bi-temporality, omnibus fund attribution, and reconciliation) need dedicated ownership from the infrastructure team, because product engineering under load will not deliver it.
If the team gets assembled reactively once drift shows up in production, the build option is already compromised.
The regulatory regime demands custody of the underlying storage in a way no third party can satisfy, or the compliance posture requires certifications a vendor cannot provide.
Regulators expect direct answers, and pointing them at a vendor will not satisfy the question. Data-residency and jurisdictional constraints are also important. When a specific region must hold the storage and no vendor can satisfy the constraint, build becomes the defensible choice.
Most fintech regulatory postures are satisfiable by a vendor holding SOC 2 Type II, ISO 27001, and DORA compliance with region-flexible deployment.
Sustain permanent maintenance costs
Transaction volume and unit economics must carry the permanent cost of maintaining the four mechanisms internally over years, well after launch.
A built ledger creates a permanent line in the operational budget, alongside every other piece of infrastructure the team already owns.
Margin that cannot absorb that line without slowing the product roadmap disqualifies the build option.
Buy a cloud-based core banking ledger when the team lacks the time or headcount to build safely, the ledger's invariants are not the differentiator, and the migration/exit risk is contained. The right call is to build if none of these situations apply to you and your team.
The team may not have time to build it before the roadmap needs it, or may not have the headcount to spare, and either one points to buy.
Shipping this quarter matters more than owning every ledger detail, and pulling product engineers onto ledger work after launch is how homegrown ledgers get built by accident and fail under scale. A bought ledger removes both problems at once.
Fund attribution, double-entry, and bi-temporality are baseline requirements for your category. Customers assume these work and pay you for the product built on top of them.
If the customer never notices the ledger, owning it end-to-end adds nothing to the P&L. Buying puts that engineering effort into the product surface instead.
Postings are portable, so reversing the buy decision doesn't mean rebuilding the source of truth from scratch. A botched exit and migration from a closed proprietary system can force a full rebuild of the ledger and its history, at a cost far higher than buying a ledger.
Buying a core banking ledger has two options: buy proprietary or buy open source.
Proprietary ledgers are the fastest option to first posting but lock you in, because your exit or migration plan depends on the vendor's contracts and interfaces.
Open-source ledgers are nearly as fast, but they let you keep the source of truth inspectable. Inspectability means you can read every attribution rule as source code before deployment. Teams can audit the source code and then run the ledger locally before signing anything.
Formance is one such open-source ledger, and it expresses those rules in Numscript, a purpose-built language for describing financial transactions. Here's what running one of those rules locally actually looks like.
Below is a Numscript transaction that attributes a PSP settlement of $2,400,000.00, with 98% going to the customer's available balance and the remainder to a platform fee account.
// Attribute a PSP settlement across a customer balance and a platform fee account
send [USD/2 240000000] (
source = @psp:provider:settlement
destination = {
98% to @customers:88410:available
remaining to @platform:fees
}
)
set_tx_meta("event_type", "psp_settlement")
set_tx_meta("settlement_id", "settlement88410")
The customer credit and the platform fee posting commit or fail as one unit, and the sum of per-customer balances stays equal to the omnibus balance at the sponsor bank. You can read, run, and audit this logic locally before signing anything, which turns exit risk into an architectural question instead of a contractual one.
Build in-house for full control and highest cost, buy proprietary for fastest launch and highest lock-in, or buy open-source for near-launch speed with an inspectable, portable source of truth. Seven dimensions decide the call, and the table below puts each dimension across the three options.
| Dimension | Build in-house | Buy proprietary | Buy open-source |
| Time to first production posting | Longest, gated by staffing the four mechanisms before launch | Fastest, vendor stack ships production-ready | Fast, self-hosted or hosted deployment with no invariants to re-derive |
| Ongoing engineering cost | Permanent infra headcount for the four mechanisms | Integration, upgrade cycles, and vendor-managed change | Operator effort on deployment and upgrades, invariants maintained upstream |
| Vendor licensing/TCO | No license fee, TCO dominated by internal headcount and infrastructure | Per-transaction or per-account licensing, plus integration and support fees | No license fee for the core, TCO is hosting plus internal operator time |
| Control over source of truth | Full because the team owns storage and semantics end-to-end | Delegated to vendor, contract-mediated access | Preserved, source code and postings inspectable at all times |
| Exit risk/migration cost | Contained within the org, but migration reproduces the original build cost | High as the exit depends on vendor contracts and undocumented interfaces | Low because portable postings and inspectable schema migration are an architectural exercise |
| Regulatory defensibility of the ledger layer | Strongest when the regime requires custody of the underlying storage | Depends on vendor's regulatory posture and audit access | Strong, storage is inspectable and can be self-hosted for custody |
| Where the four mechanisms live | Storage layer, owned and enforced by the internal team | Vendor, opaque to the buyer beyond contract | Storage layer, enforced at write time |
Run these yes-or-no questions to determine whether you need to build a ledger in-house, buy a proprietary ledger, or buy an open-source ledger for your cloud-based core banking stack. Each question maps back to a mechanism or signal covered above, so your team can trace the answer to the underlying source.
Answering these six questions tells you which option fits your cloud-based core banking stack. Any "no" is a gap in your current ledger, and the shape of that gap points to whether you should build, buy-proprietary, or buy-open-source.
Formance is the open-source ledger put into practice. It is an open-source, programmable core ledger that unifies fiat and digital assets with a regulatory-grade audit trail, so teams can enforce the four invariants at the storage layer without giving up control of the system of record.