The Ledger Is Becoming the Control Plane

When your fintech product processes its first payment, the ledger records what happened. Debit this account, credit that one, store the timestamp.

At ten payments per minute, that recording function is the entire job. An engineer can query the ledger to check a balance, and the answer comes back before anyone notices the wait.

At ten thousand payments per minute, the ledger is doing something different. It's no longer just the system of record. It's the system that decides whether the next transaction is allowed to happen at all. Can this account afford this debit? Has this user exceeded their daily limit? Does this multi-party split round correctly before any money moves?

Three companies approached this problem from different directions over the past two years and arrived at the same architectural answer. Fragment built entry conditions into its ledger schema. Formance created Numscript, a domain-specific language for declaring atomic money movement. Modern Treasury added approval rules that gate payments based on amount, account, or metadata. Each one turned the ledger from a passive recorder into an active enforcer.

What changes when the ledger enforces constraints

A traditional payments architecture separates the decision from the record. Your application logic checks whether an account has sufficient funds, then calls a payments API, then writes the result to the ledger. At each step, the state of the world can change between the check and the write.

That gap between "check the balance" and "post the entry" is where most financial bugs live. Two concurrent requests read the same balance, both see sufficient funds, and both post. Or the payment API succeeds but the ledger write fails. Or the split calculation in your application code doesn't match the precision your ledger expects.

A control-plane ledger collapses those steps. The balance check, the constraint evaluation, and the ledger write happen in the same atomic operation. When the constraint fails, nothing posts. When it succeeds, the entry and the proof that the constraint was met are recorded together.

This matters for compliance as much as correctness. When a regulator asks how daily transaction limits are enforced, a ledger-native control plane can point to the rejection rule itself since the limit lives in the ledger, not in application code that runs before an API call. The enforcement and the audit trail are the same system.

Fragment: Conditions in the schema

Fragment approaches control-plane behavior through its schema definition. You declare the rules at the account level, and the ledger evaluates them on every entry.

A precondition checks that a balance matches an expected value before an entry posts. If another transaction modified the balance between your read and your write, the precondition fails and the entry is rejected. This eliminates the race condition at the infrastructure layer rather than forcing every application developer to handle it.

A postcondition guarantees a balance stays within bounds after the entry. The most common case: totalBalance >= 0, meaning the ledger will never allow an overdraw. Any entry that would push the account negative is rejected atomically.

Both require the account's consistencyConfig.totalBalanceUpdates set to strong, which trades some write throughput for the guarantee that the balance is always current. Fragment's architecture, built on DynamoDB with pre-computed balance deltas, is designed to make that tradeoff viable at high transaction volumes. Their Building Balances blog series documents the engineering: delta-based balance computation for low-latency reads and conflict-free replicated writes for throughput, with a forthcoming third installment on fault tolerance.

Ramp uses Fragment as what they call "the control plane for our coding agents." The agent proposes a transaction, and Fragment evaluates whether the ledger state allows it.

Formance: A language for money movement

Formance took a different path. Instead of embedding constraints in a schema, they built a programming language for expressing financial transactions.

Numscript is a declarative DSL where you describe the intent of a transaction rather than the mechanics. A marketplace payout that splits revenue 85% to a driver, 10% to charity, and the remainder to platform fees is a single Numscript declaration. The Formance ledger executes the entire script atomically: every posting succeeds or fails as one unit.

The language handles details that trip up application code in production. Cascading sources let you draw from multiple funding accounts with caps: "take up to $20 from the coupon pool, then pull the rest from the customer's wallet." Numscript uses integer math with built-in rounding rules and Unambiguous Monetary Notation to make fee splits deterministic. No floating-point arithmetic touches the money path.

Because Numscript is open-source with a standalone interpreter, you can embed it outside the Formance stack. The language is the interface. An engineer evaluating Formance can read the Numscript for a complex multi-party payout and understand exactly what will happen, because the language was designed to be readable by accountants and auditable by compliance teams.

The architectural bet is that financial transactions are better expressed as programs than as API calls. An API call says "move $50 from A to B." A Numscript program says "split this payment across four accounts with these percentages, cap the fee at this amount, and fail the entire operation if any account would go negative."

Modern Treasury: Human-in-the-loop at the ledger layer

Modern Treasury's approach reflects its position as payment operations infrastructure for enterprise finance teams. Its approval rules gate transactions based on configurable conditions: amount thresholds, bank account type, metadata filters, or combinations connected by AND/OR logic.

When a payment order matches a rule, the system requires human reviewers from specified groups to approve or deny it. Multiple rules can trigger sequentially, creating approval chains. A $50,000 wire might require a Finance Analyst to review first, then a Finance Manager. The payment doesn't move until every required reviewer approves.

This is the most conservative form of ledger-as-control-plane. The constraint is a human judgment enforced by the infrastructure rather than a balance check or an atomic script. The system routes the decision to the right person, records their response, and maintains an audit trail of every rule change and every review.

Modern Treasury logs rule modifications and notifies administrators when rules change. Only users with explicit administrator permissions can modify rules. The controls apply to external accounts too: a manually created bank account can require approval before any payments flow through it.

With Modern Treasury's application for an OCC national trust bank charter, the company that built the payment approval abstraction layer is becoming the bank underneath. The trust bank charter piece covers what that collapses architecturally.

Why now

Agent-initiated transactions are the primary accelerant. A human operator can review a payment in a dashboard before clicking "approve." An agent generating transactions programmatically cannot pause for human review on every operation. The constraints have to be evaluated at the ledger layer, in real time, at the moment the entry tries to post. Fragment's entry conditions and Formance's Numscript are built for this. Modern Treasury's approval rules still require a human, but the company's roadmap, from the trust bank filing to its API-first architecture, suggests programmatic approvals are coming.

But the shift predates agents. Multi-party payment flows have been demanding atomicity that simple payments APIs can't express for years. A marketplace disbursement that splits revenue across a seller, a platform fee, and a tax withholding involves four or more ledger entries that must succeed or fail together. Orchestrating that across separate API calls creates partial-failure states that are expensive to reconcile. A ledger that executes multi-entry transactions atomically eliminates that class of bug entirely.

Compliance pulls in the same direction. You can't prove you enforced a daily limit if the enforcement logic lives in application code that changes every sprint while the audit trail lives in a separate database. When the ledger enforces the limit and records the enforcement in the same write, the proof is architectural.

The open-source spectrum

The managed infrastructure from Fragment and Modern Treasury sits at one end of a spectrum. At the other end, open-source libraries give engineering teams direct control over ledger logic.

Formance occupies a middle position. Numscript is open-source with a standalone interpreter, and the Formance ledger platform is available as both a self-hosted deployment and a managed cloud service. Teams that want the declarative transaction language without vendor lock-in can embed the interpreter and build their own operational layer around it.

Medici is a Node.js double-entry accounting library that stores entries in MongoDB. It handles the bookkeeping primitives, debits, credits, balance queries, journal entries, but leaves consistency guarantees and constraint enforcement to the application. For teams building a ledger into an existing Node.js stack with moderate transaction volumes, Medici provides the accounting primitives without the overhead of a separate infrastructure service.

Hledger is a plain-text accounting tool in the tradition of Ledger CLI. It uses human-readable text files as the ledger format, which makes it version-controllable and diffable. Hledger is designed for personal and small-business accounting rather than production payment systems, but its balance assertions, a declaration that an account's balance must equal a specific amount at a specific point in time, are a simple form of constraint enforcement at the data level.

The tradeoff across this spectrum is consistent. Managed infrastructure handles consistency and throughput scaling, while open-source tools give you control over the ledger logic but leave you responsible for making that logic survive production traffic and concurrent writes.

What convergence tells us

Fragment, Formance, and Modern Treasury started from different premises. Fragment began as a high-throughput ledger API for fintech engineers. Formance set out to open-source the payment ledger, and Modern Treasury built payment operations tooling for enterprise finance teams.

All three converged on the same insight: the ledger is the only component in a payments architecture that sees every transaction and knows every balance. Putting constraint enforcement anywhere else means the enforcement and the evidence are in different systems, maintained by different teams, drifting apart over time.

The a16z thesis that institutions are selectively adopting "programmable financial infrastructure," cherry-picking atomic settlement and programmable money while discarding permissionless access, maps cleanly onto what these three companies built. The control-plane ledger is programmable financial infrastructure with institutional guardrails baked in at the transaction layer.

Whether the market consolidates around managed platforms, open-source tools, or some combination depends on how fast agent-initiated transactions scale. At low volume, the distinction between checking a constraint in your application code and checking it in the ledger is academic. At the volumes where agents operate, with hundreds of transactions per minute per agent across thousands of agents, the ledger-as-control-plane architecture becomes the only approach where the enforcement is guaranteed to keep up with the throughput.