Search for liquidity risk management software and most of the results describe something else. The pages that rank highest are cash visibility and forecasting guides, and the products that carry the exact phrase in their marketing are usually built for banks. A corporate treasury team that buys from that reading gets a better cash position and still cannot answer the question a board asks first: how long can we fund ourselves if the next facility does not renew.
The gap is not marketing. Corporate liquidity risk is a measurement and limit problem sitting on top of the cash data, and most treasury products document the data layer far better than the limit layer. This guide sets out what the risk layer contains, which product group is likely to own it, and the evidence to demand before approving a purchase.
Quick answer
The funding limit framework is usually the buyer's to specify and test, because most products carrying the liquidity risk label are built either for bank supervisory reporting or for market-risk exposure.
Decision: Decide whether corporate liquidity risk belongs in a dedicated risk tool, a TMS risk module or a configuration of the treasury platform already in place, and what evidence to require before approving it.
Key takeaways
- Products marketed as liquidity risk software split into two populations: bank asset-liability and intraday platforms built around LCR, NSFR and BCBS 248, and corporate treasury risk modules built around FX, interest rate and credit exposure. Neither group leads with corporate funding limits.
- The corporate risk layer is a maturity ladder, a drawable-facility record, concentration and counterparty limits, a stress library, funding capacity and early-warning indicators. Cash visibility is an input to it, not a substitute for it.
- Ask vendors to show a limit breached and escalated on their own demonstration data. Scenario screens are common; limit hierarchies, breach states and approval routes are where documented capability thins out.
- Facility headroom needs its own data model. Commitment, borrowing base, reserves, availability blocks and covenant testing status each move independently, and a single availability figure hides all five.
What liquidity risk management software has to own
Liquidity risk has a settled definition. AASB 7, which incorporates IFRS 7, defines it as the risk that an entity will encounter difficulty in meeting obligations associated with financial liabilities settled by delivering cash or another financial asset. The AFP glossary entry on liquidity risk adds the corporate operating view: the inability to convert assets to cash quickly enough without a substantial loss in value, mitigated through reserves, funding diversification, debt maturity ladders, working capital and forward-looking frameworks such as stress testing and contingency funding plans.
Read those two definitions together and the software requirement follows. The tool has to hold obligations by date, hold the funding available to meet them, apply limits to the relationship between the two, and show when that relationship moves outside appetite. Everything else is supporting infrastructure. The broader policy, appetite, limit and escalation framework is set in treasury risk management; this page owns the software evaluation for the liquidity-risk layer inside it.
Where the bank products stop and the corporate problem starts
The strongest liquidity risk products on the market are bank products, and their metrics do not transfer. MORS documents asset-liability management software for banks covering interest rate, liquidity and credit risk, with LCR, NSFR, Survival Horizon and Additional Liquidity Monitoring Metrics. FIS documents an intraday liquidity monitor supporting calculations required under BCBS 248, and Baton Systems documents governed settlement control aligned to BCBS 248 and 2024 ECB intraday guidance. Those are supervisory obligations for regulated institutions.
A corporate treasury has no LCR to file. Its equivalent discipline is a funding capacity question set by its own board and its lenders, and the evidence trail runs to different places: Item 303 of Regulation S-K requires US registrants to identify known trends, demands, commitments, events or uncertainties reasonably likely to result in liquidity increasing or decreasing in any material way, to separately describe internal and external sources of liquidity, and to discuss material unused sources of liquid assets. That is the disclosure the risk layer has to support.
Three product groups, and what each covers
Product discovery for this category is easier once the groups are separated by what they were designed to measure rather than by what the category page says.
| Group | Typically includes | Use when | Avoid when | Evidence to demand |
|---|---|---|---|---|
| Treasury risk module inside a TMS | Exposure aggregation, counterparty and trader limits, policy compliance, scenario and stress analysis, VaR and Cash Flow at Risk | You already run or intend to run the TMS, and liquidity risk is one of several exposures | The module documents only market risk and you need funding concentration and facility headroom | A breached limit escalated on screen; the limit hierarchy; which risks the module names |
| Dedicated treasury risk tooling | Named risk types including liquidity, custom limits with alerts, collateral and margin call handling, rating-agency monitoring | The risk framework is the purchase and the cash layer already works | You lack a reliable cash position to feed it | How liquidity risk is calculated, not only that it is listed |
| Bank ALM and intraday platforms | LCR, NSFR, Survival Horizon, ALMM, liquidity ladder reporting, BCBS 248 intraday monitoring | You are a regulated institution with supervisory reporting duties | You are a corporate treasury; the metrics answer a different obligation | Out of scope for this decision |
The boundary runs through individual vendors, not only between them. ION sells a corporate treasury risk solution and separately documents Reval TS as a liquidity management system for banks to support their corporate service offering. Same vendor, two products, two different buyers. Confirm which one a demonstration is showing.
Sources and uses: the maturity ladder comes before the tool
The maturity ladder is the base record, and the accounting standard already specifies its shape. Paragraph 39 requires a maturity analysis for non-derivative financial liabilities showing remaining contractual maturities, a maturity analysis for derivative financial liabilities where contractual maturities matter to the timing of cash flows, and a description of how the entity manages the liquidity risk in both. If a product cannot reproduce that analysis from its own data, it is not holding the obligations record properly.
Two distinctions decide whether the ladder is useful. The first is contractual against behavioural maturity: a revolving facility with a stated maturity may be repaid and redrawn continuously, and a receivable with 60-day terms may pay in 74. The second is the difference between the disclosure ladder and the management ladder. The disclosure version uses undiscounted contractual cash flows on the earliest date payment can be required. The management version needs expected dates, and both have to exist without one silently overwriting the other.
Near-term detail belongs in the operating forecast rather than the risk model. The 13-week cash flow forecast controls own the weekly cut-off and expected-receipt logic, and the cash flow automation chain owns getting bank and ERP data there reliably. The risk layer consumes the output and applies limits to it.
Facilities and headroom: commitment is not drawable liquidity
Undrawn facility headroom is usually the largest single source of corporate liquidity, and it is the number most often carried as one figure. It should be at least five. Commitment size, borrowing base, lender reserves, availability blocks and outstanding usage each move on their own schedule.
The gap between them is not theoretical. When Wabash amended its asset-based revolver, the facility was set at $300 million, but drawability depended on the borrowing base, lender reserves, outstanding usage and a temporary $40 million availability block, with a separate $90 million defined-liquidity covenant test that is not a cash floor and not proof of drawability. A treasury system holding only the commitment figure would have overstated available liquidity by an amount it had no field to represent.
Covenant headroom is a separate record from cash
Covenant status changes what liquidity is worth without changing the cash balance. Testing can be suspended, waived or reset, and the relief is time rather than money. Dolce & Gabbana’s lending pool suspended covenant testing until March 2028 while the group carried an operating loss and rising net financial debt. The cash position that day was unchanged; the liquidity risk position was not.
Vendor documentation is noticeably thinner here than on forecasting. Ripple Treasury, the platform now carrying the GTreasury product, published guidance on 25 August 2026 describing covenant forecasting around net-debt-to-EBITDA and interest cover ratios as a difficult data-gathering exercise, and framed it as practice guidance rather than a documented feature set. Treat automated covenant headroom as a capability to be demonstrated, not assumed.
The same discipline applies to incoming funding. A closed financing round is not treasury cash until settlement, restrictions and deductions are known, which is why a completed $5 billion round can sit outside usable liquidity for a period the risk model has to represent honestly.
Concentration and counterparty limits
Concentration is where corporate liquidity risk most resembles the bank discipline, and where corporate tooling is most often thin. Four concentrations matter: funding by lender, funding by instrument, funding by maturity date, and cash by bank counterparty. A group can hold comfortable aggregate headroom and still have two thirds of it maturing in the same quarter with the same three lenders.
ION documents capturing liquidity, credit and market risks across global subsidiaries with counterparty limits, trader limits and multi-eye approval, and notes that Cash Flow at Risk is more applicable to corporates than Value at Risk. 3V Finance documents titanTreasury handling five risk types including liquidity, with custom limits, alerts, collateral and margin call handling and monitoring against three rating agencies. Both statements are company-stated capability, and both describe limits as a configured object rather than a fixed report.
Risk appetite, limits and escalation
A limit framework is worth more than a metric library, and it is the part buyers most often forget to script. Specify the hierarchy before the demonstration: board-level appetite statements, treasury policy limits underneath them, and operating thresholds underneath those. Each level needs an owner, a measurement basis, a review date and a defined breach state.
Breach handling is the real test. Ask what happens between the limit being exceeded and someone approving it. A product should record the breach, hold the value that triggered it, route an approval to a named authority, keep the exception open with an expiry, and retain the whole chain after the position returns inside the limit. Products that only send an alert have moved the problem to email.
Scenarios, stress tests and funding capacity
Scenario capability sells well and proves little on its own. A scenario changes assumptions; a stress test applies a specified adverse condition and asks whether the entity remains funded. The corporate output is a funding capacity statement: how long the group can meet obligations under the stress, and what management actions are available inside that window.
A stress library worth paying for contains conditions that are specific to the funding structure, not percentage haircuts applied to every inflow. Useful members include a facility that does not renew at maturity, a borrowing base that falls with receivables quality, a covenant test failed at the next measurement date, a rating action that raises pricing and triggers a review, a single large customer paying 30 days late, and cash trapped in an entity that cannot lend upward.
Management actions belong in the model as separate, dated and constrained items. Drawing a facility, delaying capital expenditure, releasing working capital and selling an asset have different lead times and different approval requirements. A stress result that assumes instant access to all four is not a funding capacity statement.
Early-warning indicators that fire before the breach
Early-warning indicators exist to buy time, so they have to move earlier than the limits they protect. Corporate indicators worth configuring include facility utilisation trending up across consecutive weeks, forecast-to-actual variance widening on receipts, days sales outstanding drifting against terms, covenant headroom narrowing on the forecast rather than the actual, funding cost rising against the reference rate, and concentration rising as smaller facilities mature.
Each indicator needs a threshold, an owner, a stated response and a review cadence. An indicator with no defined response is a chart. The design test is simple: if the indicator had been live last year, would it have fired before the event it was meant to anticipate.
Reporting, data and integrations
Liquidity risk reporting has one requirement above presentation quality, which is reproducibility. A board pack figure should be traceable to the positions, rates, facility terms and limit settings that produced it, on the date it was produced. Products that recalculate historic reports against current reference data cannot support a governance discussion about what was known at the time.
The data dependencies are specific. The risk layer needs bank balances and transactions, ERP payables and receivables, the debt and facility register with covenant terms, market data for rates and ratings, and entity-level restrictions on moving cash. Bank data is usually the constraint, and the choice between API, SWIFT and host-to-host affects freshness more than any risk feature does, which is why bank connectivity options should be settled before the risk module is configured.
Where the debt and facility register lives is the decision that most often gets deferred. It is the only record that carries commitment, borrowing base rules, covenants and maturity together, and if it stays in a spreadsheet the risk module inherits a manual dependency that no amount of connectivity fixes.
Approvals, controls and governance
Ownership needs to be settled before configuration. Treasury owns exposures, limits and the funding plan. The controller owns the accounting records the ladder draws on. Finance systems owns interfaces and access. Internal audit reviews the control design rather than operating it. Where hedging sits alongside liquidity risk, the hedge accounting software requirements bring their own designation and effectiveness evidence that should not be merged into liquidity limits.
Model governance applies even without complex analytics. Any calculated risk output needs a documented method, a version, a named owner and a change record. When a product offers Monte Carlo simulation or Cash Flow at Risk, ask for the assumption set and who approves changes to it.
In the UK the governance requirement is explicit in code. The FRC’s UK Corporate Governance Code 2024, published in January 2024 and applying to accounting periods beginning on or after 1 January 2025, requires the board to assess the company’s emerging and principal risks under Provision 28, with a footnote stating that principal risks include those that might threaten the company’s solvency or liquidity. Provision 30 requires a going concern statement covering at least twelve months from approval, and Provision 31 requires the board to explain how it assessed the company’s prospects, over what period, and whether it has a reasonable expectation the company can meet its liabilities as they fall due. A US registrant faces the Item 303 disclosure instead. The underlying evidence is the same; the reporting artefacts differ, and a global group needs both from one data set.
Product map as of 26 August 2026
Inclusion rules for this map: products are listed by what their official documentation states, checked on 26 August 2026. This is a scope classification, not a ranking, shortlist, quality score or market inventory. No pricing is included because comparable published pricing does not exist for this category. Company-stated capability is recorded as company-stated.
Treasury risk modules inside a wider platform. ION names liquidity, credit and market risk with counterparty limits, policy compliance, scenario analysis, stress testing, VaR and Cash Flow at Risk. Kyriba lists Risk Management as one module of its platform alongside Treasury, Payments, Connectivity and Working Capital, and scopes that module to FX, debt, investments and interest rates. Ripple Treasury describes FX, interest rate and credit risk with Monte Carlo and Cash Flow at Risk modelling, policy breach detection and maturity alerts. FIS documents Treasury and Risk Manager, Integrity Edition covering cash positioning and forecasting, bank account administration, debt and investment management, compliance and reporting.
The pattern in that group is worth stating plainly. Where these products scope their risk module explicitly, they scope it to market risk categories. Liquidity risk appears named in ION’s solution documentation; in the others it is present as cash and liquidity capability rather than as a limit framework. That is the specific thing to test rather than assume.
Dedicated treasury risk tooling. 3V Finance names liquidity risk as one of five risk types in titanTreasury with custom limits, alerts and counterparty monitoring, serving corporates and financial institutions from the same product family.
Bank liquidity platforms, and why they sit outside this decision
MORS, FIS Intraday Liquidity Monitor, Baton Systems and ION Reval TS are named here only to mark the boundary. They are built for banks and regulated institutions, and their governing metrics are LCR, NSFR, Survival Horizon, ALMM and BCBS 248 intraday monitoring. A corporate treasury evaluating them is buying a supervisory reporting engine for obligations it does not carry.
What to demand in a demonstration
Script the session on your own structure rather than accepting a standard tour. Six requests separate documented capability from a screen.
- Load a facility with a borrowing base, a reserve, an availability block and a covenant test, then show available liquidity and every component behind it.
- Produce the paragraph 39 maturity analysis from the same data, then produce the management view with expected dates alongside it.
- Set a concentration limit, breach it, and walk the escalation to approval and expiry without leaving the product.
- Run a stress in which a facility does not renew, and show the funding capacity result with management actions dated and constrained.
- Reproduce a board report from six months ago exactly as it was produced, using the reference data of that date.
- Show the audit record for a limit change: who requested it, who approved it, what it was before.
Score what the product held and calculated itself, separately from what it displayed after a manual load. The gap between those two columns is the implementation work you are actually buying. Where the answer is that the platform holds the data but the limits live elsewhere, the honest conclusion may be that this is a configuration project on the treasury management system selection you have already made, supported by treasury automation controls, rather than a separate purchase. If the shortfall turns out to be cash visibility rather than limits, the decision belongs on the cash-availability side of the same problem instead.
Frequently asked questions
Is liquidity risk management software different from liquidity management software?
Yes. Liquidity management software answers what cash and funding are available and moves them. Liquidity risk software applies limits, concentration tests, stress scenarios and early-warning indicators to that position and reports breaches. Many products do the first well and treat the second as reporting. Test the limit and escalation layer separately from the cash layer.
Do corporate treasury teams need bank liquidity risk software for LCR and NSFR?
No. LCR, NSFR and BCBS 248 intraday monitoring are supervisory requirements for regulated institutions, and products such as MORS, FIS Intraday Liquidity Monitor and Baton Systems document them for banks. A corporate treasury reports liquidity through going concern, viability and Item 303 disclosures, which need funding capacity and headroom evidence instead.
Can a treasury management system handle liquidity risk without a separate tool?
Often yes, if its risk module names liquidity risk rather than only market risk. Several vendors scope their risk module to FX, interest rate, debt and investment exposure. Ask whether limits, concentration and stress results are calculated in the product or assembled outside it, then price the configuration work that answer implies.
What should a liquidity risk report show the board?
Funding capacity under a defined stress, available liquidity split into its components, maturity concentration over the next four quarters, covenant headroom on forecast rather than actual, open limit breaches with owners, and early-warning indicator status. Every figure should be reproducible from the positions and reference data of the reporting date.
