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 consistent account of money, bilateral obligations, and institutions: the same logic carries a liquidity pool in a supply chain and a central bank balance sheet. OiC.OS is the operating system — the model of that theory. You compose an organisational form, run it on a digital twin, and redesign it when strategy shifts — without the books, contracts, and decisions ever drifting apart.
This page is written for boards, CFOs, and treasurers. Here we explain why we should work together.
The pain you already pay for
Most finance departments discover the same pattern twice a year. Treasury closes a deal: pooled facilities, better terms, cleaner covenants. Operations keeps shipping. Then consolidation surfaces mismatches between contract intent, bank reporting, and ERP reality. Controllers build manual bridges, audit adds work, IT adds interfaces. None of it was impermissible as a single operation; everything was simply uncomposed and not aligned with one another.
The same situations play out at larger scale. National accounts fail to align with payment-system flows. Macro models treat "money" as a single aggregate — book money, reserves, cash — when every treasurer knows these are different things. Stress tests ignore how bilateral claims actually net. The cost is not only error, it is also delay: you cannot safely approve a structural change until armies of reconcilers have blessed it.
OiC.OS 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 faster, without silent drift.
Three layers, one organisation
Every institution, holding, banking network, or supply chain runs, under the concepts of OiC.OS, 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. The agents in the decision layer can represent the decisions of humans or be programmed agents themselves. The digital twins are then simply shaped accordingly.
Governance is the rulebook: who may sign, which covenants apply, which policy version is in force, and what compliance requires before money moves. OiC.OS's principle 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.
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.
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 at the wrong moment.
Circulation versus valuation
Here is a distinction your controllers have long known 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 must never break monetary consistency.
OiC.OS 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 latest 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 and their software, the way these technologies are built into software in the first place.
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 execute every sentence — every booking, every contract, every consolidation — correctly and grammatically 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 provide internal triggers in order to perform internal restructuring: the organisation can rebuild itself from within, consistently and with defined operations — as software that processes software, compiler technology in fact, here for the software of economic organisations. A new subsidiary, a changed covenant, a merged pool — the model lifts itself into the new shape instead of being torn down and rebuilt, or ground down by change management and endless specification and ad-hoc reprogramming.
This is exactly the functionality that hurts most in live operation. 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, in the topos, a structural change is a typed operation the system performs on itself.
The mathematics behind this is 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 the organisational terms familiar to you; the hard maths works underneath, the way you drive a car without solving the thermodynamics of the engine, or compute with a computer without understanding the relativistic effects of Einstein inside it.
LiquiPool
The flagship teaching case — the one that, hopefully, 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, with OiC.OS, compose a pool vehicle that manages the same total capacity as one package with the banks. 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 between the contracts. Group purchasing saves money for the same reason; here the saving is measured precisely and allocated fairly.
The fair allocation follows from the efficiency gain. 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 (that is, nostro/loro accounts). Decisions: draw policies optimised jointly instead of as three local optima of the pool members. Before signing you can simulate, the draw paths can be stress-tested, and then the processes run provably correctly, fully automated and with an audit trail that is, in the end, what AI has promised for decades: transparent, self-explaining, and reacting intelligently when inconsistencies arise.
That is the commission that makes a CFO happy: implement our LiquiPool — holding cash pool, treasury company, or any other supply-chain finance vehicle — on an engine where the contract, the accounts, and the decision models 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 (after Elinor Ostrom) in which no single centre determines every rule, yet global consistency is preserved.
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 OiC.OS treats external accounts with the same bilateral discipline as internal ones. Units are checked by the compiler, the way physicists have done for hundreds of years — without it no remotely complicated machine would run.
Central banks and national accounts: the same invariants that hold in a holding and its treasury department must also hold in a sovereign architecture at scale.
Each of these is a fragment of one operating system, not a separate product line. A holding that masters pooling on the engine can transfer its experience to a further treasury company in another jurisdiction; it embeds the experience — OiC.OS makes it possible, through formal operations, to embed software into other software.
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 policy PDF; they are typed objects whose consistency the compiler checks and the theorem prover proves beforehand. Digital twins are not demos; they are the mandatory rehearsals before covenants bind real cash. Just as engineers prove the statics of bridges, we now prove the statics of monetary systems.
The research behind these claims: MoMaT-A develops an axiomatic theory of 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, from a single posting to a closed architecture of international clearing and settlement. We provide formal, machine-checked proofs and a reference implementation. With that, economists and developers can no longer get lost in the non-binding.
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: