_FINANCIAL-OPERATIONS/
Treasury Management Systems vs Programmable Money Infrastructure
By Formance Staff
Research
E-Money
Embedded Finance
Loading article content
Loading table of contents
Loading author
A treasury management system (TMS) moves money between bank accounts, while programmable money infrastructure tracks what every dollar is doing once it's inside your product. Regulated fintechs need both because they sit at different layers of the fintech money stack.
A payments fintech holds funds for 40,000 users in one shared bank account. The TMS handles the bank side cleanly until a regulator asks for proof of what each user owned, to the cent, three months ago. The TMS shows one number: the account total, but without a programmable money infrastructure, the financial team spends four weeks digging through event logs and processor exports to rebuild per-user balances, and hands over a best-effort answer.
A TMS answers one question: how do I move money between my bank accounts? Programmable money infrastructure answers a different one: who owns each dollar inside my product, and what rules apply to it? The two get sold as alternatives, but they solve different problems.
This guide covers what a TMS does at the bank boundary, what programmable money infrastructure does inside the product, how the two compare, why regulated fintechs run both, and four questions to test your stack against.
A TMS is the software layer between a finance team and its bank accounts. It handles three jobs: cash visibility and forecasting across every bank account; payment initiation across ACH, wire, RTP, and FedNow; and the approvals, workflows, and bank connectivity that make it an operations system.
The TMS pulls balances from every bank account, across every legal entity and currency, into one dashboard. It also runs short-term cash forecasts (typically 7, 30, and 90 days) built from AR/AP, payroll, taxes, and upcoming treasury moves.
The user is a treasurer who needs to know, before lunch, whether the company has enough cash in the right currencies, in the right places, for the next thirty days.
Bank connectivity is statement-driven, which means the TMS doesn't hold its own record of what's in each account. It re-reads what the bank reports on a schedule and rebuilds the view each time. Feeds come in through one of two channels:
Either way, the bank is the source of truth, with the TMS acting as the summary on top.
Payment initiation is the second job a TMS does after cash visibility. Instead of running programmable payments through each bank's portal, you run them through the TMS. A modern TMS gives you one screen to send payments across every rail: domestic wires, ACH, SEPA, RTP, FedNow, cross-border wires, and transfers between your own entities.
One screen matters because without it, a treasury team logs into six different bank portals with six different UIs, cut-off times, and file formats. The TMS collapses six workflows into one.
Approvals, workflows, and bank connectivity are the three things that turn a TMS from a dashboard into an operations system. Every outgoing payment runs through a maker-checker chain before it hits the rail.
Big payments trigger extra approvers, risky counterparties trigger sanctions screening, and new payees trigger callback verification. The TMS records who approved what and when, and auditors test that log when they ask how your payment controls work.
Deep integrations with the major global banks (JPMorgan, Goldman Sachs, Wells Fargo, Citi, and HSBC) are what make a TMS worth paying for. Without them, a TMS is just a spreadsheet with extra steps.
Programmable money infrastructure is the entire operating system that moves the money, enforces business rules, and talks to the banking system. The ledger is the system of record inside the infrastructure that captures every posting, every balance, and every state change.
Where a TMS tracks balances at the bank-account level, programmable money tracks balances at the customer, asset, and account-state level. It enforces the rules of how money moves between them.
Four properties make programmable money infrastructure work, all built on top of the ledger: a system of record for internal balances, double-entry multi-party postings, orchestration of multi-hop flows with rollback, and an immutable audit trail.
The ledger tracks, in real time, who owns what across every internal account. When $50M sits in one shared bank account on behalf of 40,000 users, the ledger holds 40,000 individual balances, plus a rule that says they must always add up to the bank total.
Every event that moves money (a payment in, a fee, a refund, or a transfer between users) updates the ledger before it updates anything else. The ledger never reads balances back from the app. A store built for money, like Formance Ledger, makes balance integrity a property of the system itself, not something you have to hope every service gets right.
Every posting in a programmable ledger is double-entry, multi-party, and multi-asset by design, and each of those three things kills a whole class of app-layer bugs.
Sources and destinations have to add up, or the ledger rejects the write. Splits, fees, and payouts to multiple parties live inside the posting itself, not spread across half a dozen services.
A single event (a marketplace checkout, a cross-border payout, or a refund with a partial fee reversal) becomes one atomic transaction that touches the shared account, the buyer's balance, the seller's balance, the platform fee account, and a tax account, all in one write.
Multi-asset is built in because a USD bank balance, a USDC stablecoin balance, and a tokenized deposit are all the same kind of thing to the ledger, which is an asset held at an account. Postings treat them the same way, so expect FX legs, stablecoin settlements, and fiat rails all live in one model.
Orchestration turns a multi-step money move into one all-or-nothing transaction. Real payouts are rarely a single hop. A single payout might pull from a customer wallet, convert FX, move through a partner, and land at an outside bank.
Programmable infrastructure treats that whole path as one flow with atomic behavior. If the partner leg fails, the wallet debit and the FX conversion roll back. Either all four steps (wallet debit, FX conversion, partner leg, external bank credit) complete, or the ledger stays where it started.
The transaction log is append-only and chained by hash. Corrections are new entries that point at the original, not UPDATE statements that rewrite history. That kind of log gives you point-in-time views for free. "What was user 88213's balance at 23:59 UTC on 31 March?" is answerable three months later without replaying every event since, and without having to trust that no one edited a row.
Auditors and regulators expect this. Bolting it on afterward is expensive, which is why a programmable ledger ships it as a default property rather than an add-on.
At posting time, the programmable money infrastructure takes the $10,000 the TMS has already moved into a shared account and splits it across three merchants, a platform fee, and metadata, in one atomic write.
The allocation below uses Numscript, Formance's language for multi-party postings. Any programmable money infrastructure models the same split, with only the syntax changing.
// INBOUND_WIRE_ALLOCATION
// $10,000 arrives in the omnibus account and is split across three merchants,
// net of a 2% platform fee.
send [USD/2 1000000] (
source = @platform:banks:bank_b:omnibus
destination = {
2% to @platform:revenue:fees
remaining = {
1/2 to @merchants:88213:available
3/8 to @merchants:88214:available
remaining to @merchants:88215:available
}
}
)
set_tx_meta("event_type", "inbound_wire_allocation")
set_tx_meta("wire_reference", "FED-4471")The send runs all-or-nothing. If the destination fractions didn't add up to 100% of the remaining amount, the programmable money infrastructure would reject the whole posting rather than write a partial split.
Afterward, the TMS still sees $10,000 in the Bank B account. The ledger records $200 in platform fees, $4,900 to merchant 88213, $3,675 to merchant 88214, and $1,225 to merchant 88215, and can prove those splits at any point in time, forever.
TMS and programmable money infrastructure barely overlap. The TMS faces outward (banks, rails, approvals, and cash forecasts) and treats the bank statement as the source of truth. Programmable money infrastructure faces inward (customer sub-balances, splits, fees, and holds) and is itself the source of truth.
| Dimension | Treasury management system | Programmable money infrastructure |
| Primary question answered | How do I move money between my bank accounts? | Who owns which dollar inside my product, and what rules govern it? |
| Primary user | Treasurer, cash manager, FP&A | Engineering, product, financial operations |
| Scope | External: banks, rails, correspondents | Internal: customer sub-balances, fees, holds, splits |
| Source of truth | Bank statement | The ledger itself |
| Unit of ownership | Bank account (one owner per account) | Ledger account (one per customer, per asset and per state) |
| Payment initiation | Native across ACH, wire, RTP, FedNow, and SEPA | Not the primary role. It typically calls out to a TMS or PSP |
| Sub-ledgering | None | First-class |
| Multi-party splits | Not modeled | Native, atomic |
| Multi-asset | Fiat, multi-currency | Fiat, stablecoins, tokenized deposits, custom assets |
| Audit trail | Payment-initiation log and bank statement reconciliation | Append-only, hash-linked, and point-in-time queryable |
| Failure mode | Silent break between statement and book, found at close | Transaction rejected at posting time |
| Category examples | Kyriba, GTreasury, FIS Quantum, ION, SAP TRM and Trovata | Formance, purpose-built internal ledgers |
Regulated fintechs run a TMS and programmable money infrastructure together because neither one alone covers both jobs: day-to-day operations (cash visibility, payment initiation, and approvals) and the per-customer attribution regulators now expect.
Two things drive that: regulation (DORA, MiCA, and safeguarding rules that a TMS can't satisfy on its own) and the fact that adding a ledger underneath an existing TMS is cheaper than replacing either layer.
DORA, MiCA, and safeguarding rules across the UK, EU, and US all require fintechs to prove, per customer, and per timestamp, what is held on their behalf.
DORA in the EU sets operational resilience rules that are hard to meet without an unbroken audit trail. MiCA puts segregation and attribution rules on crypto-asset service providers that a TMS was never built to satisfy.
Safeguarding rules for e-money firms in the UK and EU require you to show that funds in a pooled account are cleanly segregated per customer.
In the US, expectations from the OCC, FDIC, and state regulators point the same way for BaaS relationships.
Teams that already run a TMS are adding programmable infrastructure underneath to address regulatory requirements.
The TMS and a programmable ledger solve different problems and sit at different layers of the stack, so adding one doesn't make the other redundant.
When a new layer is needed, the instinct is to replace what's already there, but that's the wrong move here. Leave the bank-facing layer alone and slot the ledger in underneath, where the per-customer accounting actually needs to live.
Teams that already run a TMS shouldn't rip it out. Bank connectivity, payment initiation, and cash forecasting are hard and expensive to rebuild. Keep the TMS for what it does well. Add a programmable ledger underneath as the source of truth for customer funds. Your bank setup doesn't change. Your internal picture of customer funds becomes correct.
Most regulated fintechs need both a TMS and a programmable ledger, and assuming one covers the other is the common mistake.
A TMS moves money between bank accounts, but it was never built to prove, per customer and per timestamp, what you're holding on their behalf. A programmable money infrastructure with a built-in ledger can prove all funds accurately while meeting DORA, MiCA, and safeguarding requirements.