Formance vs. TigerBeetle vs. Fragment: Choosing a Core Ledger

The lending launch is scheduled for Q3. The core ledger underneath it is a transactions table with a balance column built two years ago, and it cannot model an origination fee without new application code. Month-end reconciliation now consumes engineering time budgeted for the product, and every new payment rail adds another reconciliation script that breaks when the provider changes formats. This situation traces back to a single architectural decision that every fintech team asks: which core ledger sits underneath the product?

A core ledger is a real-time system of record for money in motion: it answers who holds what, right now, under concurrency. Selecting a core ledger determines where financial correctness lives and how reconciliation and transaction traceability hold up as the business scales.

Formance, TigerBeetle, and Fragment are all core ledger options, but each makes a different bet on where financial correctness should live. Formance encodes intent in a programmable open-source ledger, Fragment packages a schema-driven ledger as a managed cloud service, and TigerBeetle exposes a high-throughput OLTP accounting engine that leaves everything above it to you.

Choosing between Formance, Fragment, and TigerBeetle requires weighing where double-entry is enforced, how multi-asset activity is modeled, what reconciliation surfaces, and which deployment model your compliance posture will accept.

Formance vs. Fragment vs. TigerBeetle at a glance

For fintech teams, these three core ledger products differ most in deployment model, programmability, multi-asset handling, and the location where double-entry is enforced.

Formance is a programmable, self-hostable core ledger

Formance is an open-source, programmable core ledger that unifies fiat and digital assets with regulatory-grade traceability.

Double-entry and atomic posting are enforced within the ledger itself, while transaction intent is expressed in DSL, and the ledger runs on infrastructure your team controls. A single instance can also host multiple fully isolated ledgers, so multi-entity or multi-region topologies do not require multiple deployments.

Formance's position is that financial logic encoded above the ledger layer compounds into technical debt, so the ledger must encode transaction intent alongside its database primitives. It is used across fintech workloads (lending, neobanks, BaaS, PSPs, and crypto) where multiple payment rails or asset types are in play.

Numscript expresses complete flows as one atomic unit

Formance expresses complete fund flows as a single atomic unit through the Numscript transaction language, a purpose-built language for money that describes transaction intent in terms readable by both engineers and finance teams.

Here is a $250,000 lending disbursement with a 2% origination fee, using the platform loan principal at @platform:loans:8412:principal, the borrower wallet at @customers:8412:wallet, and platform origination revenue at @platform:revenue:origination:

Four postings executed within a single atomic transaction show that the loan principal account is debited, the customer wallet is credited, the $5,000 fee debits the wallet, and revenue is credited. There is no intermediate state in which the borrower received funds, but the fee was never captured.

Any asset type, any mix, in one ledger instance

A single Formance Ledger instance tracks fiat, stablecoins, digital assets, custom tokens, and reward points side by side, with every asset defined by the customer.

A wallet holding USD, EUR, USDC, and loyalty points runs on a single deployment, and Assets Coloring adds semi-fungible tracking so that restricted balances (promotional credit and program-specific USD pools) remain individually addressable without spawning a new asset type.

Multi-rail ingestion, reconciliation, and orchestration in one platform

Formance Connectivity handles multi-rail ingestion through a generic connector framework that normalizes data from banks and PSPs into a single model. Pre-built connectors include Stripe, Adyen, Mangopay, Wise, Banking Circle, Modulr, JP Morgan, Cross River Bank, Tink, Powens, Fireblocks, and Kraken, among others. Connected providers handle payment initiation, and Formance does not hold or move funds itself.

Formance Flows orchestrates multi-step fund movements on top of Connectivity and the Ledger, so multi-leg payouts, fee splits, and conditional transfers are expressed as a single workflow rather than stitched together in application code.

Formance Reconciliation reconciles internal postings with external provider data using policy-based rules, automated drift detection and balance verification. The Web Console then surfaces account, transaction, connectivity, and reconciliation monitoring in one place.

All three modules run inside one platform.

Auditable code and bi-temporal history for regulated entities

The MIT-licensed core ledger and Numscript interpreter provide full source transparency, and Formance Ledger records every posting in an immutable, append-only log with bi-temporal history, so compliance teams, auditors, and regulators can reconstruct any point-in-time balance without rewriting records.

Each transaction cryptographically links to the previous one for tamper evidence. Bi-temporality tracks both when an event was recorded and when it was effective, and backdated corrections do not require rewriting history.

Enterprise Self-Hosted deployment with data residency support reduces both black-box and vendor lock-in concerns for compliance teams facing regulators. Formance meets security compliance as it is SOC 2 Type II certified, ISO 27001 certified, and supports DORA, MiCA, and GENIUS compliance.

Fragment takes a different bet compared to Formance. Instead of a DSL and self-hosting, it packages the ledger as a managed cloud service with a declarative schema.

Fragment is a managed-cloud ledger built on a declarative schema

Fragment is a managed-cloud ledger with a declarative, schema-driven programming model. The schema shapes ledger entries (accounts, entry types, and the debit/credit lines each entry expands into), and then posts transactions against that schema via the API. Double-entry is enforced at write time by conditions declared in the schema, so unbalanced postings are rejected before they land.

Fragment tends to show up in earlier-stage fintech products like expense management and single-currency SaaS billing, where a small team wants to skip the infrastructure work.

Interactive evaluation through the visual ledger simulator

Fragment's most distinctive advantage is a visual ledger simulator that lets teams model a chart of accounts and run interactive transaction simulations in under 30 minutes. For an early-stage team prototyping a chart of accounts with finance in the room, the simulator shortens the evaluation cycle from days to minutes.

No cluster, no consensus, and no upgrade path to manage

The managed cloud model removes ledger deployment entirely from your infrastructure decisions. There is no cluster to run, no consensus to operate, and no self-hosted upgrade path to manage. For a Series A team optimizing for engineer-months, the reduction in operations work is often the deciding factor.

Write-time double-entry and native multi-currency support

Enforcing double-entry at write time through the schema reduces the class of application bugs that cause unbalanced postings, and multi-currency support (including stablecoins) is native to the account model.

Fragment's opinions live in the schema layer rather than the engine layer, so teams should assess how much financial logic ends up in calling code versus the schema itself.

Best-fit workloads: expense management, travel, and single-rail products

Fragment's packaging suits smaller workloads, expense-management products, and travel-product scenarios where the ledger shape is stable, and the compliance surface is limited.

Reconciliation, idempotency semantics, and audit inspection are accessed through the managed API rather than through direct storage access, and self-hosted data residency is not on the table.

Fragment's public compliance posture centers on SOC 2. However, teams with a hard ISO 27001 or DORA requirement should confirm current certification status directly with Fragment before ruling it in or out.

TigerBeetle sits at the opposite end of Fragment's spectrum.

TigerBeetle is a high-throughput OLTP accounting engine

TigerBeetle is a purpose-built OLTP accounting database with an intentionally small data model. All accounts, transfers, and typed identifiers, with double-entry enforced, are on the engine level on every transfer.

Transactions are constructed as typed transfer objects by client code and submitted through the API in batches. Reconciliation, orchestration, connectors to payment providers, and audit reporting all live above the engine as application concerns.

TigerBeetle is used for fintech workloads where transfers-per-second is the binding constraint, typically card processors, crypto exchanges, and real-time settlement networks.

One million transfers per second on batched workloads

TigerBeetle's log-structured merge storage engine can exceed 1 million transfers per second for batched workloads, per vendor benchmarks. For a card processor, high-frequency exchange, or real-time settlement network where the ceiling is genuinely transfers per second, the headroom directly determines whether the ledger becomes your bottleneck.

The issue with TigerBeetle is whether the workload is near that limitation now or within the next two years. If it is not, throughput is not the deciding factor.

Three-replica Viewstamped Replication for engine-level durability

A three-replica Viewstamped Replication consensus provides engine-level disaster recovery with zero data loss in the event of a single-node failure by default.

Teams comfortable operating a consensus deployment get strong storage-layer guarantees, but the end-to-end recovery story still depends on clients, connectors, and the systems that persist idempotency identifiers.

Narrow correctness primitives: accounts, transfers, and typed identifiers

TigerBeetle’s primitives are transfers, accounts, and typed identifiers, with no opinions on assets, orchestration, or reconciliation. Idempotency is anchored on client-generated transfer identifiers, so the client picks the identifier, and the engine treats a resubmitted identifier as a retry.

Multi-asset activity is handled by using separate accounts or ledgers per asset, with any cross-asset logic implemented in the application layer. Teams that want a small, fast primitive to build a bespoke financial platform on top of, and that have the engineering capacity to build that platform (including per-rail reconciliation scripts and regulatory-grade traceability tooling), will find TigerBeetle a good fit.

Which core ledger is right for your fintech?

Different fintech verticals hit different constraints first. Lending platforms and BaaS providers usually hit reconciliation and multi-rail sprawl before throughput. Neobanks, wallets, and PSPs juggling fiat, stablecoins, and points are bottlenecked by multi-asset modeling and regulatory traceability. Match the architecture to the constraint that decides your roadmap.

When Formance is the right call

Pick Formance when you are running, or planning to run, more than one payment rail, and when you hold more than one asset (fiat plus stablecoins, multiple currencies, or points and credits alongside cash).

Formance fits especially well when reconciliation has become a recurring engineering cost you want to move off the roadmap, and when regulators, auditors, or a compliance team need immutability, hash-chained history, and bi-temporal traceability inside the ledger layer itself, including MiCA or GENIUS obligations for stablecoin activity.

Formance is the right call when self-hosting is required today or plausible within the next two years, and MIT-licensed source transparency matters to your diligence process.

When Fragment fits your workload

Go with Fragment when infrastructure work is the blocker, and eliminating it is worth it; accept a managed, proprietary service.

It fits when the use case is genuinely low-complexity today (a single asset or a small currency set, a single rail, and a stable chart of accounts), and when interactive scenario design with finance in the room, via the visual simulator, matters at your stage.

Fragment also assumes that self-hosted data residency and ISO 27001 or DORA posture are not hard requirements for your regulator.

When TigerBeetle is the better bet

Reach for TigerBeetle when raw transfer throughput is your single binding constraint, and you can name the specific workload where you approach its ceiling.

It assumes an engineering team willing and resourced to own reconciliation, multi-asset handling, orchestration, and audit reporting above the storage engine, and that wants a narrow, opinionated primitive to build a bespoke financial platform on top of.

Operating a three-replica consensus deployment should be inside your comfort zone before you commit to this path.

Try it against your actual workload

The fastest way to decide is to stop reading comparison tables and post transactions. Pull the Formance Ledger from GitHub, run it locally, and model one real flow from your product (a disbursement, a payout with a fee split, or a multi-currency wallet transfer) in Numscript.

If it holds up under the constraints of your production workload, you have your answer. If it doesn't, you have a much sharper question to take into your TigerBeetle or Fragment evaluation.