Liquidity saving and settlement compression are two fundamentally different problems that can be solved by graph-based netting mathematics — but the infrastructure each one produces is architecturally distinct, legally distinct, and operationally distinct, because the participants, the economics, and the regulatory surface area are different.
One asks: how do we clear the most debt with the least money?
The other asks: how do we reduce the capital locked in settlement to the minimum net positions?
Both involve obligation graphs. Both use algorithms to find offsets among participants. Both reduce the gross value of what must be settled. And both are legitimate — each solves a real problem for a real market. But they are not the same problem, and the infrastructure designed to solve one cannot serve the other without being rebuilt from the legal framework up.
This distinction matters because a growing number of projects apply graph-based netting mathematics to obligation networks and describe the output in terms that blur the line between these two categories. For an institution evaluating netting infrastructure — whether a bank, a payment service provider, a treasury operation, or a central bank — the first question is not "what is the compression rate?" It is: which problem does this infrastructure solve? The answer determines whether the infrastructure is relevant to the institution's settlement operations or whether it serves an entirely different market.
Liquidity saving: the trade credit problem
The liquidity saving problem starts with cash flow. A firm has outstanding invoices — 30, 60, 90-day trade credit — and does not have enough cash to pay them all. Its suppliers have the same problem. Their suppliers have the same problem. Across the network, there is more debt than available money to discharge it.
The mathematical insight is that some of this debt is circular. Firm A owes Firm B, Firm B owes Firm C, and Firm C owes Firm A. If all three agree, the circular obligations can be discharged simultaneously — set off against each other — without anyone moving a dollar. The algorithm that finds these cycles in the obligation graph is well understood. The academic literature, including formalisation by researchers in the Journal of Risk and Financial Management, has established the mathematics rigorously.
The constraint is structural: without external liquidity injection, only pure cycles in the obligation graph can be cleared. If A owes B, B owes C, and C owes D — but D does not owe A — the chain is not a cycle, and it cannot be discharged without someone paying. The published academic data on this constraint is consistent: in a typical commercial obligation network with zero external liquidity, approximately 10 per cent of total debt sits in pure cycles that can be cleared through set-off alone.
Ten per cent is not trivial for an SME struggling with cash flow. But it is a ceiling, not a floor — and the ceiling is determined by the topology of the obligation graph, not by the sophistication of the algorithm.
The mechanism for increasing clearance beyond the cycle baseline is liquidity injection. An external party — a bank, a government programme, a liquidity facility — injects cash into the network. Each dollar of injected liquidity clears more than a dollar of debt, because it unlocks chains that were one participant short of being cycles. The multiplier effect is real and well documented: modest liquidity injection can push clearance rates from 10 per cent to 30 or 40 per cent of total outstanding debt.
This is a useful and legitimate mechanism. The Slovenian national clearing system has operated a form of multilateral obligation clearing for SMEs since 1991. The problem it solves — invoice gridlock among commercial counterparties with constrained cash flow — is a genuine economic problem. The mathematics are sound. The outcomes are measurable.
But the problem it solves is: how do firms that cannot pay their debts discharge the maximum amount of mutual obligation with the minimum external liquidity?
That is not the settlement compression problem.
Settlement compression: the institutional capital efficiency problem
The settlement compression problem starts from a fundamentally different position. The participants — banks, payment service providers, institutional counterparties — have the capital to settle their obligations. They are not insolvent. They are not in invoice gridlock. They settle billions of dollars every day, reliably and on time.
The problem is how much capital they must lock up to do so.
Every gross settlement obligation requires prefunded capital. A bank running a cross-border corridor must maintain nostro account balances, intraday credit lines, and liquidity buffers sized to the gross flow — not to the net economic exposure. Under Basel III and the BCBS 248 monitoring tools for intraday liquidity management, those exposures are visible to supervisors and to bank treasury teams. The capital locked in prefunding earns nothing. At an institutional cost of capital of 8 to 12 per cent, gross prefunding is a direct drag on return on equity.
Settlement compression addresses this by computing the net position of every participant across all counterparties in a corridor — the sum of what each participant owes minus the sum of what each participant is owed — and producing settlement instructions for the residuals only. The gross obligations are mathematically compressed into a minimum set of net positions that, when settled, leave every participant in the same economic position as if every gross obligation had been settled individually.
No external liquidity injection is required. The volume itself provides the offsets. The more participants and the more obligations in the netting window, the more offsets the algorithm finds. This is not a liquidity multiplier — it is a mathematical reduction of the settlement value to the true net economic exposure.
The scaling dynamic is the opposite of liquidity saving. In a liquidity saving system, clearance starts low and increases only when external capital is injected. In a settlement compression system, compression starts high and increases with participation. Each new participant in a netting corridor adds potential offsets against every existing participant. Each new obligation adds to the population that the algorithm compresses. The result is that well-designed settlement compression systems routinely achieve 85 to 96 per cent compression in production — not because the algorithm is better, but because the problem structure is different. The participants are not short of money. They have offsetting flows. The algorithm merely computes what the net economic reality already is.
The empirical evidence from production systems is unambiguous. CLS Bank processes over $8 trillion in daily gross FX obligations and reduces participants' funding requirements by more than 96 per cent. CHIPS — the largest US dollar clearing system — achieves a liquidity efficiency ratio of approximately 26:1, meaning $26 of gross obligations are settled for every $1 of liquidity in the system. The European Central Bank's TARGET2 maintains both real-time gross settlement and liquidity-saving mechanisms precisely because institutions need both modes depending on the urgency and size of the obligation.
The output of settlement compression is not a set-off notice sent to a firm's accounting system. It is an ISO 20022 settlement instruction — a pacs.008, a pacs.009, or a camt reporting message — dispatched to institutional back-office systems that process it through existing correspondent banking, RTGS, or payment rails. The residual net positions settle through the same infrastructure the institution already uses. The compression layer sits above the settlement rail, not beside it.
Why the distinction matters architecturally
These two problems produce fundamentally different infrastructure because they require different outputs, different legal frameworks, different regulatory postures, and different participant models.
Different outputs. Liquidity saving produces set-off notices — records that mutual obligations have been discharged by agreement under private contract. Settlement compression produces settlement instructions — messages that direct the movement of funds through banking infrastructure to discharge net positions with legal finality. The downstream systems that consume these outputs are entirely different. A set-off notice updates a ledger. A settlement instruction triggers a funds transfer.
Different legal frameworks. Liquidity saving operates under obligation law — private contract, mutual agreement, and in some jurisdictions statutory set-off provisions such as those codified in the UNIDROIT Principles. Settlement compression operates under financial regulation — CPMI-IOSCO PFMI Principle 8 on settlement finality, the EU Settlement Finality Directive 98/26/EC, Dodd-Frank Title VIII in the United States. The legal protections are different. The insolvency treatment is different. The enforceability of netted positions when a participant defaults — the scenario that matters most — is governed by entirely different legal architectures.
Different regulatory requirements. Infrastructure designed for liquidity saving among commercial counterparties typically operates outside the financial regulatory perimeter. No sandbox engagement is required. No supervisory observability framework is expected. No settlement finality opinion is sought. Settlement compression infrastructure, by contrast, operates within the financial regulatory perimeter or at its edge — and every institution that uses it expects the operator to have engaged regulators, to have prepared or be preparing settlement finality opinions, and to provide tiered supervisory access consistent with PFMI Principle 17 on operational risk and Principle 18 on access and participation requirements.
Different participants. Liquidity saving serves firms with constrained cash flow — typically SMEs, trade credit counterparties, and commercial businesses in economies where invoice payment terms create systemic cash flow delays. Settlement compression serves institutions with abundant capital but suboptimal capital deployment — banks, payment service providers, treasury operations, and central bank-adjacent infrastructure. The onboarding requirements, the compliance expectations, the credit assessment frameworks, and the operational integration points are categorically different.
Different economics. Liquidity saving clears debt. Its value proposition is measured in obligations discharged — invoices that no longer need to be paid because they have been set off against reciprocal obligations. Settlement compression frees capital. Its value proposition is measured in prefunding reduction — the capital that was locked in nostro accounts and intraday buffers and is now available for deployment. One reduces a firm's liabilities. The other reduces an institution's cost of doing business.
What institutions should understand
When an institution evaluates netting infrastructure, the first analytical step is to determine which of these two problems the infrastructure was designed to solve. The design intent is not always stated explicitly, but it is always visible in the architecture.
Infrastructure designed for liquidity saving will emphasise cycle detection — finding circular chains in obligation graphs that can be discharged without external funds. It will measure success in terms of debt cleared as a percentage of total outstanding obligations. It will describe the challenge in terms of firms that cannot pay, and the solution in terms of enabling payment without requiring full liquidity. Its data will show clearance rates that start low without liquidity injection and scale with external capital. These are the correct metrics for the problem it solves.
Infrastructure designed for settlement compression will emphasise net position calculation — computing each participant's aggregate position across all counterparties and producing the minimum set of settlement instructions. It will measure success in terms of compression rate — the percentage reduction from gross obligations to net settlement value. It will describe the challenge in terms of capital efficiency, not cash flow constraint. Its data will show compression rates that scale with participant count and obligation volume, without requiring external liquidity injection. The output will be settlement instructions in institutional message formats, not set-off notices to accounting systems.
The distinction is not a matter of quality or sophistication. Both problems admit elegant mathematical solutions. Both produce measurable value for their respective participants. But infrastructure designed for one cannot serve the other without a fundamental rebuild.
A cycle detection engine optimised for finding mutual offsets among cash-constrained SMEs does not produce ISO 20022 settlement instructions. It does not operate under a settlement finality framework. It does not provide supervisory observability to central banks and prudential regulators. It does not integrate with the SWIFT network, the RTGS systems, or the back-office reconciliation platforms of a regulated financial institution. And it does not carry the legal opinions — jurisdiction by jurisdiction — that confirm netted positions are enforceable in insolvency.
Adding these capabilities is not a feature request. It is a different product built on different legal, regulatory, and operational foundations. The legal framework alone — settlement finality opinions for each participating jurisdiction, engagement with the relevant prudential authority, alignment with CPMI-IOSCO PFMI principles, preparation for designation under frameworks like the EU Settlement Finality Directive or Dodd-Frank Title VIII — represents years of specialised legal and regulatory work that must be built into the architecture from inception, not layered on after the algorithm is running.
This is why the problem you solve defines the infrastructure you build. The problem constrains the architecture. The architecture constrains the market. And no amount of algorithmic elegance in solving one problem creates readiness to solve the other.
The mathematics is commodity. Netting algorithms are well published, peer-reviewed, and available to anyone with a graduate-level understanding of graph theory and linear programming. What distinguishes settlement infrastructure from obligation-clearing infrastructure is everything around the mathematics: the legal framework, the regulatory engagement, the message standards, the supervisory architecture, and the institutional integration model. These cannot be bolted on after the fact. They must be designed in from the first line of architecture.
Where FiatRails sits
FiatRails solves the settlement compression problem. The infrastructure is designed for banks, payment service providers, and institutional counterparties that settle cross-border obligations and need to reduce the capital locked in that settlement process. The output is ISO 20022 CBPR+ settlement instructions dispatched to institutional back-office systems. The regulatory posture includes active central bank engagement, sandbox participation, and a supervisory observability framework designed for tiered access by home regulators. The legal architecture is built for settlement finality, not private set-off.
The corridors, the participants, the message standards, the regulatory engagement, and the legal framework are all designed for the institutional settlement compression problem from the ground up — not adapted from infrastructure originally designed for a different problem serving a different market.
For institutions evaluating netting infrastructure: identify which problem the infrastructure was built to solve. If it was designed for liquidity saving among commercial counterparties, it may be excellent at that. But it is not settlement compression infrastructure, and the gap between the two is not a feature to be added — it is a foundation to be built.
The algorithm is the easy part. The framework is the product.
This article is part of the FiatRails Insights series on institutional settlement infrastructure. Other articles in the series examine what multilateral netting is and how it works, the empirical case against universal atomic settlement, why set-off is not settlement netting, MiCA's gap for digital asset settlement, and the current state of the Settlement Computer.