Technology
If you run treasury, group finance, or a supply-chain-heavy operating company, you already live across three worlds that rarely speak the same language. Your ERP posts bookings. Your bank negotiates credit lines. Legal and compliance sign contracts. Risk runs scenarios in spreadsheets. Audit reconciles the damage after quarter-end. Every layer has its own tools, its own consultants, its own "single source of truth." And yet, at the moment that matters, no one can say with confidence whether a new facility, a new subsidiary rule, or a new pooling structure will stay consistent all the way from contract to cash to consolidated accounts.
OiC.OS exists because that fracture is not a software bug. It is a design gap in how we model economies. Monetary Macro Accounting Theory (MoMaT) closes it with a single rigorous account of money, bilateral obligations, and institutions: the same logic governs a liquidity pool in a supply chain and a central bank balance sheet. OiC.OS is the operating system built on that theory. You compose an organisational form, run it on a digital twin, and redesign it when strategy shifts — all without breaking the books along the way.
This page is written for boards, CFOs, and treasurers. The formal monographs and the forthcoming docs.oicos.systems site carry the depth that builders need; here we explain why the engine is worth commissioning.
The pain you already pay for
Most finance organisations discover the same pattern twice a year. Treasury closes a strong deal: pooled facilities, better rates, cleaner covenants. Operations keeps shipping. Then consolidation surfaces mismatches between contract intent, bank reporting, and ERP reality. Controllers build manual bridges, audit adds fees, IT adds interfaces. Nothing was illegal; everything was simply uncomposed.
The same story plays out at larger scale. National accounts fail to align with payment-system flows. Macro models treat "money" as a single aggregate when every treasurer knows it is not. Stress tests ignore how bilateral claims actually net. The cost is not only error, it is delay: you cannot safely approve a structural change until armies of reconcilers have blessed it.
MoMaT begins from a simpler discipline. It asks what must stay true in the books, regardless of why anyone booked. Once that layer is fixed, decisions and governance can move quickly without silent drift.
Three layers, one organisation
Every institution, holding, banking network, or supply chain runs on three coupled layers. OiC.OS names them so that they can be designed together rather than as three separate silos.
Accounting is the unconditional core. Double entry is the minimum form of honesty: every debit has a credit. Quadruple entry is what bilateral business actually requires, because my receivable is your payable, mirrored in real time. When a payment, a drawdown, or an internal transfer posts, the balances close — not because an auditor later agrees, but because the structure cannot post any other way. Stock-flow consistency stops being a slide in a consulting deck and becomes a property of the system, much as a building cannot stand without its load-bearing walls.
Decisions are where strategy lives: investment, pricing, credit utilisation, seasonal draws, capacity, choice of counterparty. Here outcomes feed back. A facility that looked cheap in January can prove wrong once demand shifts in June. OiC.OS treats decisions as first-class objects linked to the accounts — forward choices and backward learning on the same object — so that scenarios and stress paths never live in a parallel universe to the ledger.
Governance is the rulebook: who may sign, which covenants apply, which policy version is in force, and what compliance requires before money moves. The posture is compliant by design — prevent rather than audit. A violation is rejected at the boundary, like a payment that fails because the account does not exist, rather than surfacing six months later in a sample test.
Accounting is unconditional; decisions and governance can be revised whenever the board changes strategy. But neither can override arithmetic. That separation is what lets a CFO sleep: innovation upstairs, iron downstairs.
Money is three things, and your treasury already knows it
Board packs still add up "M0 and M1" as though they measured the same kind of thing. Treasurers know better. Book money is an instruction to your bank — giro, not cash in a vault. Reserves are how banks settle with one another through the central bank. Cash is legal tender, the final discharge of a monetary debt.
Giro does not teleport into cash. It converts through reserves and institutional capacity. Treating the three as one number is how models miss bank-run dynamics, how groups misjudge intraday liquidity, and how policymakers and corporate treasury end up talking past each other. OiC.OS keeps the hierarchy explicit — household and firm, bank, central bank — so that a liquidity pool, a payment system, and a currency area are the same pattern at different scales, not different species of software.
Only the central bank creates cash. Banks create claims on cash: credit and deposits are options on settlement. For a CFO negotiating facilities this is not an academic point. It clarifies who bears settlement risk, where pooling genuinely saves cost, and why ample liquidity on paper can still fail in the wrong kind of stress.
Circulation versus valuation
Here is a distinction your controllers already feel but standard toolchains rarely enforce cleanly. Monetary circulation — payments, clearing, bilateral balances — follows exact rules that do not depend on whether you like this quarter's valuation model. Valuation — mark-to-market, impairment, changes in measurement policy — moves reported equity through choices that should never break monetary consistency.
MoMaT separates financial equity, which lives in the circulation layer, from real equity, which lives in the valuation layer. Circulation must net bilaterally to zero across the system; valuation can shift reported wealth while the monetary spine stays intact. Where the two are conflated, as in much of equilibrium macro and in many improvised ERP customisations, you get elegant stories that fail in a live close.
For a holding CFO the payoff is direct. Treasury and consolidation can share one spine that still respects a different measurement policy per entity, with no hand-built bridges every month.
Compose, run, redesign
OiC.OS is not a template ERP. It is a platform for organisational forms: a language in which contracts, charts of accounts, policy rules, and network topology become one composable design. You compose the institution you actually have — the pool vehicle, the operating companies, the bank relationships, the covenants. You run it as a simulation on a digital twin before any signatures, then as a live operation once you are ready. You redesign when units, currencies, or governance change, lifting the old form into the new one instead of replacing history with a migration project.
The workflow is the same whether the object is a three-firm liquidity pool or a national accounting architecture. That is not marketing symmetry; it is what "operating system for economies" means in practice.
What is under the hood
A short word on the engineering, because it explains why the promises above can actually hold.
We build on category theory and on the everyday tools of programming-language design: type systems, compilers, and formal semantics. These are the same techniques that let a modern compiler reject a broken program before it ever runs. We point them at economies instead of at ordinary software.
The simple idea underneath is this: money is a language. It is the language in which economies express debt relations — who owes whom, in what unit, settled along which path. Once you treat money as a language with a grammar, you can give it a compiler: state the rules once, and let the machine keep every sentence — every booking, every contract, every consolidation — grammatical by construction.
To make that work in practice we need a particular piece of mathematics called topos theory. Its key gift is internal mathematics: the ability to do mathematics inside the system's own world, in its own context, rather than only describing it from the outside. That sounds abstract, and it is — but it buys something extremely practical. It lets the system carry internal triggers and perform internal restructuring: the organisation can reorganise itself from within, consistently, while the books stay closed. A new subsidiary, a changed covenant, a merged pool — the model lifts itself into the new shape instead of being torn down and rebuilt.
This is exactly the functionality that hurts most in real life. Without it you are left with change management: migration projects, endless PowerPoint orgies, reconciliation spreadsheets, and the quiet hope that nothing drifted. With internal restructuring, a structural change is a typed operation the system performs on itself.
The mathematics behind this is genuinely advanced. OiC.OS's job is to hide that complexity away so that the people who need it — treasurers, CFOs, controllers — get the practical benefit without ever touching a topos. You compose, run, and redesign in plain organisational terms; the hard maths works silently underneath, the way you drive a car without solving the thermodynamics of the engine.
LiquiPool
The flagship teaching case — and the one that turns CFO conversations from polite interest into "we want that for our group" — is LiquiPool.
Picture a supply chain of supplier, manufacturer, and distributor. Each firm holds its own revolving credit facility with its house bank, complete with commitment fees, usage fees, flexibility premia, and seasonal draws. Finance has seen this a hundred times. Add the three annual costs together and you get a number everyone accepts as the price of liquidity.
Now compose a single pool vehicle that negotiates the same total capacity as one package with the bank. The bank's risk and operational picture improves, and so does the rate. In the reference model, total cost falls from roughly 177 thousand euros per year to roughly 124 thousand — on the order of thirty percent — for the same underlying liquidity need. Not because someone sharpened a spreadsheet, but because three separate contracts are simply not the same object as one composed contract. Group purchasing saves money for the same reason; here the saving is measured precisely and allocated fairly.
Fair allocation matters as much as the headline number. If one subsidiary free-rides, the pool dies in internal politics. OiC.OS uses a Shapley-style fair split of the coalition gain, so each participant can see what it contributes and what it receives. Treasury can then take the proposal to three CEOs without a zero-sum fight.
On the same object you watch all three layers work together. Governance: three standalone facility agreements versus one pool agreement with participation rules. Accounting: parallel T-account flows for draws and fees, mirrored bilaterally with the bank. Decisions: seasonal draw policies optimised jointly instead of as three myopic local optima. Simulate before signing, stress the draw paths, then run.
That is the commission a CFO actually writes: implement our LiquiPool — or our holding cash pool, treasury company, or supply-chain finance vehicle — on an engine where the contract, the accounts, and the decision model cannot diverge.
What else composes on the same stack
LiquiPool is the door. The same engine carries much more.
Structured finance and banking networks, with tranches, intermediaries, and polycentric governance in which no single centre owns every rule, yet global consistency still closes.
Supply-chain ERP and logistics, modelled not as generic inventory rows but as a topology of payments and obligations: who owes whom, in which currency, along which settlement path.
Holdings and operating groups, with entities as compositional agents and consolidation as the lifting of smaller closed books into larger ones, rather than re-keying charts of accounts with every acquisition.
Currency areas and cross-border settlement, with two or more currency zones and a corrected balance-of-payments logic; the international extension of MoMaT treats external accounts with the same bilateral discipline as internal ones.
Central banks and national accounts, where the invariants your group wants in a pool are the same ones a sovereign architecture must respect at scale.
Each of these is a fragment of one operating system, not a separate product line. A group that masters pooling on the engine does not discard that work when it adds a treasury company in another jurisdiction; it embeds it.
Why this is not another fintech integration
Integration projects connect silos. OiC.OS removes the need for heroic reconciliation by giving governance, decisions, and accounts one shared semantic core. Policy type-checking and ERP reporting are not two implementations of a vague policy PDF; they are the same typed object. Digital twins are not demos; they are the mandatory rehearsal before covenants bind real cash.
The research stands behind the claims. MoMaT-A develops axiomatic money and macro accounting: double and quadruple entry, stability, central banking, and the three types of money. MoMaT-I extends the framework to currency areas and to the staged Ouroboros ladder, from a single posting to a closed-world settlement architecture. Formal proof and a reference implementation sit beneath the prose so that builders cannot hand-wave, and boards do not need to read them to benefit from what they enforce.
What a commission looks like
A typical engagement starts where you already hurt: duplicated facility costs, opaque intragroup liquidity, consolidation bridges, covenant surprises, or a supply chain in which finance and operations hold different pictures of the same obligations. We model your actual contracts and account structure on OiC.OS, run the digital twin against your own draw and seasonality history, quantify the coalition gain, and implement the pool — or the holding structure, or the treasury vehicle — so that governance rules, decision policies, and posted balances stay aligned by construction.
You gain fewer audit surprises, faster board decisions, and a path on which the next structural change is a redesign, not a rescue.
If you want the theoretical frame behind the engine, see Platform and MoMaT. For the people behind the research: