Today we are introducing Formance Studio
Turn a plain-English product description into a complete, validated ledger schema.
Financial modeling is the last part of building a ledger nobody has automated. Not the database, not the API, not the dashboards. The thinking. We just did, and we did it agentically.
Every ledger project starts with the same questions. Where does money sit between the moment a customer pays and the moment a seller gets paid? Is a refund the reverse of a capture, or a different flow with its own failure modes? When the bank statement and the database disagree, which one is right?
Answering them is the modeling work, and it can be the hardest part of building a ledger, harder than the database or the API. A good model turns most downstream questions into balances you can read. A bad one leaves you with years of reconciliation scripts and a finance team that keeps its own spreadsheet because it stopped trusting the system. The people who can do this work well are rare, and most teams hit these problems exactly once, on their own ledger, without anyone in the room who has seen them before.
Today we are introducing Formance Studio, a workspace for designing ledgers. You describe the product you want to model in plain English, and Studio returns a complete model: an account hierarchy in your vocabulary, transaction logic for every flow, the queries your operations and finance teams will need, and a written explanation of why the model is shaped the way it is.
Studio is the product form of experience we already had. For years, Formance engineers have designed ledgers alongside regulated institutions, from banks and card programs to stablecoin issuers. That experience became a doctrine, and the doctrine became a design agent anyone can put to work. The practical meaning is simple: the barrier to launching a new financial product just dropped. You can start building flows today, and ledger expertise stops being the reason a product does not ship.
Studio is three things that share one artifact, the ledger schema.
A template gallery. Complete, working schemas for the shapes we see most: stablecoin issuance, AI usage billing, marketplaces, card programs, wallets. Each one encodes the patterns that take teams the longest to discover on their own, like escrow and settlement timing, fee splits, pending holds, and reconciliation accounts. You can open any template in the editor and read exactly how it works, without an account.
A schema editor. Ledger schemas are plain YAML: a chart of accounts, Numscript transaction templates, query templates. The editor validates as you type, and you can save schemas to a library, share them by link, and test them against a live ledger.
An agentic designer. This is the part we are most excited about. Describe your business, attach a PRD or a flow diagram if you have one, and an agent goes to work: it researches your flows, asks the clarifying questions a solutions engineer would ask, designs the model, generates fixtures, and executes them against a live ledger to prove the money actually moves the way the design claims. You watch each stage as it happens, and the output loads directly into a Formance Ledger. Not one model call returning YAML: a multi-stage agent doing the job end to end, and it is running in production today.
A ledger is the one system where a plausible answer is worse than no answer. If the model is subtly wrong, the books are subtly wrong, and you usually find out months later, during reconciliation.
So the design agent does not write freehand. It works from the doctrine our solutions engineers have refined over years of workshops with everyone from large regulated institutions to seed-stage startups: every posting must balance, every amount is traced from the account it enters to the account it leaves, pending funds live in explicit in-transit accounts rather than metadata, and reconciliation accounts are part of the design from the start. The doctrine came out of executing these patterns against live ledgers, with generated fixtures, until the failure modes were worked out. A run cannot complete without passing structural and double-entry validation, so a schema that fails the checks never reaches you.
Validation has limits worth being plain about. The checks prove the model is internally sound: postings balance, amounts trace, the structure loads. They cannot prove the model matches your business exactly. Studio's job is to take you from a blank page to roughly 85% of a finished design. The last stretch, the edge cases and policies only your team knows, is deliberate human work, and we think that is the right division. You should not hand the design of a financial system entirely to an AI, ours included.
That is still a different thing from asking a general-purpose model to write your ledger. Producing YAML that looks like a ledger model is easy. The value is in the doctrine, the checks, and knowing exactly which 15% still needs your judgment.
Take a two-sentence description: "We sell AI compute. Customers prepay into a credit balance, every API call draws it down, and the model provider takes 20% of each call."
Studio returns a chart of accounts in those terms:
customers:
$customer_id:
balance
providers:
$provider_id:
payable
platform:
revenue:
usageTransaction logic for each flow, as Numscript. Here is a metered API call:
send [USD/2 300] (
source = @customers:c_1042:balance
destination = {
20% to @providers:p_77:payable
remaining to @platform:revenue:usage
}
)
Both legs of that split commit together or not at all, so the provider's share can never be owed without the revenue being recognized.
And the queries your team will actually run. Total unspent customer credit, the number your deferred-revenue line depends on, is one call to the aggregated balances endpoint:
{ "$match": { "address": "customers::balance" } }The same two sentences work for a stablecoin issuer: describe minting against reserves and redemptions back out, and the model arrives with custody accounts, mint and burn flows, and reserve reconciliation built in.
For a team evaluating a ledger, the blank page disappears. Instead of reasoning about Formance in the abstract, you are looking at your own business, with your own account names and flows. The schema becomes the document your engineers and your finance lead argue over, and that argument is the real work of a ledger project. Studio moves it from week six to day one.
For an engineer, it is a strong starting point instead of an empty file in a language you met this morning. You start most of the way there rather than at zero. You will disagree with parts of the generated model, and that is fine. Arguing with a concrete, validated draft is much faster than deriving one from scratch, and the editor re-validates every change you make.
If you have inherited an in-house ledger, you already know the failure modes: holds that leak, fees that round differently on refunds. Those are the patterns the doctrine exists to handle, so they show up in the generated model by default.
Open the template gallery and read a working schema for a business like yours, or describe your own and watch the first draft arrive with its design document. The modeling expertise that used to gate this work is in the tool now. Don't let ledger technology decide what you ship.
How is this different from asking ChatGPT/Claude to design my ledger?
A general-purpose model produces plausible output. Studio produces validated output: the design follows a doctrine built from real ledger implementations, every amount is traced end to end, and a schema that fails structural or double-entry validation never reaches you. That gap matters more here than in most software, because this is the system that holds your money.
Do I need to know Numscript?
No. The generated schema is readable on its own, and the design document explains every flow in plain language. Numscript is easy to pick up from the examples, and the editor validates anything you change.
What if the model gets something wrong about my business?
Then you can correct it. The schema is a draft for your team to argue with, not a finished decision, and reviewing it is part of the design, not a failure of the tool. Edit it in the editor, or describe the correction and run the design again. Validation applies either way.