Post your first agent-scoped transaction
Your next step is to clone the Formance Ledger on GitHub, run it locally, and post your first transaction from an agent-scoped account.
AI is already running inside payment stacks at banks, payments and capital firms, government institutions, and fintechs.
In 2024, 75% of the 118 UK firms used AI, while 92% of EU banks were deploying it in 2025. In the United States, the U.S. Department of the Treasury used machine learning to help prevent and recover over $4 billion in fraud and improper payments in 2024, up from $652.7 million the year before.
If you're shipping AI in payments, letting the model post directly to the ledger is tempting. Your reconciliation team has an LLM proposing matches that operators approve in batches, and the obvious next step is to cut the human operator out and let the model commit the posting.
Payment systems are deterministic, and a model whose output cannot be reproduced from pinned inputs does not belong on the post side of the line.
The pressure to adopt every new agentic payment capability is real, and most of what gets pitched as "autonomous finance AI" cannot hold up against ledger invariants, idempotency requirements, and audit replay.
Separating what works from what is hype helps you build an architecture that lets you keep the powerful AI components without exposing the ledger to the unreliable ones.
AI commonly runs in production to do four jobs in finance: fraud and compliance scoring, LLM data extraction and matching, LLM drafting for exceptions and disputes, and AI-assisted posting rules.
All four tasks put a person or deterministic rule in front of the output before anything touches a balance.
At Formance, we've built the open-source programmable core ledger that sits underneath this pattern. It produces double-entry and asset-precision invariants that are enforced at write time, so the ledger refuses a bad posting regardless of which of the four jobs produced it.
Fraud and compliance scoring works by ranking transactions by risk and having a human adjudicate the top of the list.
The model learns from past examples of fraud, abuse, or policy breach, and it scores new transactions by how closely they match those patterns.
The ranked list goes to an analyst, and nothing changes in the ledger on the model's say-so.
An LLM pulls structured fields out of unstructured documents, and a rule confirms the match before anything posts to the ledger.
Invoices, bank statements, and remittance notices vary too much in format for template-based extraction, but they share enough language structure for a model to read them.
The AI’s job ends with a candidate posting that includes counterparty, amount, currency, and reference. A rule then checks the candidate against the ledger's open items.
If the candidate matches, the ledger accepts the posting. If it doesn't, the candidate goes to the exception queue. If the model misreads a reference, the mismatch surfaces as an unmatched item, which your reconciliation process already handles.
An LLM writes clear prose from a few structured facts, which is what an exception explanation, a dispute response, or a reconciliation memo requires.
The model reads the transaction record, the counterparty details, and the relevant policy, and writes a paragraph an operator can send without rewriting from scratch.
An operator reviews each draft before it goes out, and edits can feed back as examples for later drafts.
The failure mode is a well-written explanation of the wrong policy, which is why the operator decides what ships, not the model.
Engineers use AI assistants to write posting rules and tests during development, and the reviewed code runs in production, not the model's live output.
The engineer asks a model to generate a posting rule and its unit tests. The rule and tests land in a pull request, and both go through code review and testing like any other change before they run against a ledger.
The failure mode is a plausible-looking rule that violates a double-entry invariant, which the test catches before the merge.
The hype of AI in finance falls into three categories, and all three fail for the same reason: no deterministic gate separates the model’s output from the ledger.
The three failure categories are autonomous execution without gates (at the agent and function level), LLMs computing financial amounts directly, and plug-and-play vendor tools that write to the ledger without invariants.
Fully autonomous AI execution does not work for payments. The pitch is that "autonomous finance agents" that reconcile, approve, and pay without a human in the loop are successful.
But once the model's output goes straight to the ledger, nothing between the two can reject a bad transaction or instruction.
The failure mode shows up at two levels:
Agent-level autonomy: A single agent picks an action and executes it with no rule in between. The problem is that the same request to the same agent can produce different tool calls, different retries, and different postings each time it runs.
A ledger needs the same instruction to produce the same posting every time, and an unconstrained agent cannot promise that.
Full autonomy at this level is still rare in production, and the discrepancy between what the agent intends and what gets posted is the reason.
Function-level autonomy: The pitch escalates to running all of accounts receivable or accounts payable end to end, with no human in the loop.
The failure is the same but scaled to a higher volume. An agent orchestrating a whole function will send too many requests, send malformed data, or send payments it was never meant to make, and no amount of prompt tuning reliably fixes that.
The payment and posting layers have to reject those on sight rather than trust the model to catch them.
LLMs should not do the math that ends up in a posting. The pitch is that an LLM can calculate fees, allocations, or settlement amounts straight from a prompt.
LLMs are trained to sound confident whether the answer is right or wrong, so a correct fee calculation and a wrong one read the same.
A plain calculator must recheck any number a model produces before it posts, and the calculator's number is what posts.
Vendor tools that promise "ledger-ready" output without their own rule-checking push the failure to the ledger itself, and where nothing can stop it.
The pitch is that the tool drops into your stack and starts writing to the ledger with no change to your posting layer.
If the ledger accepts whatever the tool sends, a duplicate retry or an unbalanced posting becomes a valid write. A payout over budget goes the same way: the ledger takes it, and you only find out at reconciliation.
Consider any such tool by what the ledger beneath it refuses, because the tool's own guardrails are the part you cannot see.
Engineers building AI into payment infrastructures need five components in place before an agent goes anywhere near the ledger. These include a control layer around the model, runtime approval gates, a fail-closed deterministic gate, posting-level traceability for spending, and application-level idempotency.
The rule underneath all five is the same: probabilistic components propose, deterministic code posts, and the ledger rejects anything that breaks its rules, no matter what the model decided.
A model or agent sends a candidate posting with accounts, amounts, assets, and metadata. The ledger's deterministic checks (double-entry and asset precision) run at write time, and the application's policy checks (sufficient balance, budget, and spending limit) run before submission. A person or policy approves anything over a threshold before it posts.
The control layer around a model is a set of static rules, written once at design time and unchanged per request. These include input validation, tool schemas the agent cannot step outside, pinned model versions, snapshotted inputs, and replay. The control layer decides which actions the model is even allowed to take.
Ledger immutability with compensating postings means postings are never edited. Corrections are new postings, so a model's mistake stays visible in the history alongside the fix.
Transaction atomicity means a multi-account transaction either commits in full or not at all, so a half-finished agent action cannot leave money stranded in a clearing account.
At runtime, every AI component lands in one of three tiers (signal, propose, or post), and the model itself never reaches post.
An AI component reaches the post tier only when what posts is a deterministic, versioned rule that replays the same way every time.
| Question | Pass/fail | Resulting tier |
| Is the output deterministic and reproducible? | Fail | Propose (staged posting with approval) at most |
| Does the output touch a balance, or only a recommendation? | Recommendation only | Signal (surface to an operator) |
| Can the decision be replayed six months later with model version and inputs pinned, so the evidence behind the compensating controls carries forward? | Fail | Signal |
| Is there a compensating control if the model is wrong? | Fail | Signal |
| All four | Pass | Post (deterministic, versioned rule; a model may have helped author it) |
Split responsibilities by layer. Approval scripts should not re-run the double-entry or asset-precision checks the ledger already runs.
Sufficient-balance and budget checks stay in application policy. The ledger's write-time checks are the final gate, regardless of which tier a component lands in.
Treat the validator and policy layer like any other production code. This includes implementing version-controlled rules, replayable test fixtures, canary deploys against a shadow ledger, and a hard-fail default if any check cannot run.
If the budget service is unreachable or a policy rule throws an error, the posting does not go through. It goes to the exception queue for an operator. A gate that silently fails open is the same as letting the model post directly, which is the exact failure the gate was built to prevent.
Monitor the gate for track evaluation errors, timeout rates, and the rate at which postings are rejected or sent to exceptions.
Posting-level traceability means storing the actor, task, session, delegating principal, and authorizing mandate on the posting itself.
An agent spend audit then becomes a ledger query. When an auditor asks which agent paid a vendor on a given day and under whose authority, the answer sits in the metadata, in the same immutable posting as the amount.
Idempotency means the same intent, replayed on any retry, is submitted only once. It prevents an agent's retries from turning into duplicate payouts.
Assume the application checks the account balance and allocation rules before submission. An agent allocates $1,250,000.00 from a procurement budget funded at $2,000,000.00 for the month to a merchant payable; the transaction does not run an external payout.
The transaction is written in Numscript, Formance's purpose-built language for money, which describes a transaction's intent in a form both engineers and finance teams can read.
The application's budget policy and idempotency key travel with the request.
// VENDOR_PAYABLE_ALLOCATION
// Event: allocate procurement funds to the payable for Acme invoice INV-2026-0447
send [USD/2 125000000] (
source = @platform:procurement:budget
destination = @merchants:acme:payable
)
set_tx_meta("event_type", "vendor_payable_allocation")
set_tx_meta("invoice_id", "INV-2026-0447")
set_tx_meta("agent", "procurement-agent")
set_tx_meta("task", "invoice-INV-2026-0447")
set_tx_meta("mandate", "procurement-monthly-2026-09")
The first submission posts. The budget account drops from $2,000,000.00 to $750,000.00, the merchant payable increases by $1,250,000.00, and the metadata records the actor and links the task to the mandate.
A retry handler using the same idempotency key and a stored request record can return the original transaction and submit nothing new.
It can also flag the response with Idempotency-Hit: true, and reject reuse of the same key with different parameters.
A second $1,250,000.00 allocation under a new key would exceed the remaining $750,000.00, so the application's budget check would reject it before submission and surface the rejection to an operator.
Every AI component ships with a catalog record once the propose/post architecture is in place. Record these four fields before any AI component ships.
If your engineering team cannot populate those four fields for every AI component in the stack, your engineering team doesn't have a propose/post architecture ready to ship.
The starting point for AI in finance is a core ledger that refuses bad postings on its own. The control layer, approval tiers, traceability metadata and idempotency keys rely on the ledger.