Software for managing investment risk: keep the VaR engine

Software for managing investment risk covers several layers: the order management system that holds positions, the accounting and administration systems that strike net assets, the market and index data that price them, and the risk engine that turns all of it into VaR, stress results and attribution. For a fund's derivatives risk management program under SEC Rule 18f-4, the engine is rarely the gap. The rule lets a fund use any VaR model that meets its parameters and even take the number from a vendor, and the SEC noted that many advisers already had platforms with VaR capability. The gap is the program between the engine and the board: checking each night's inputs, recomputing each ratio, explaining breaches and backtest exceptions, counting the five-business-day clock, and drafting the board reports and Form N-RN from the same figures. Botminds' Derivatives Risk Management Program is that layer. It reads from the systems a firm already runs, has the firm's engine do the calculations, and leaves every decision with the derivatives risk manager.

Rule text is from 17 CFR 270.18f-4 and the SEC's views from its adopting release. Systems are named by type, not by vendor. The figures shown are fictional sample data.

What software for managing investment risk covers at a fund firm

At a firm that manages registered funds, risk software usually means a risk engine plus the data it depends on. The engine computes value at risk, stress losses, factor exposures and attribution; the order management system supplies positions and trades; portfolio accounting and the fund administrator supply net assets; market data vendors supply prices, curves and history; index providers supply benchmark weights. Liquidity, valuation and counterparty programs draw on the same sources for different rules.

Rule 18f-4 adds a specific job to that stack. Every full-program fund must run a VaR test "at least once each business day", backtest and stress test weekly, escalate, report to the board in writing, file Form N-RN when a breach lasts five business days, and keep each day's fund VaR, reference VaR and VaR ratio for five years. The engine supplies the numbers for each of those steps; the steps themselves happen elsewhere, usually in workbooks and email.

Do you need a new risk engine for Rule 18f-4?

Usually not. The rule fixes the VaR model's parameters, 99% confidence, 20 trading days and at least three years of data, and the risk factors it must capture, but not the method or the software. The SEC left the choice of model to each fund, allowed a fund to buy its VaR figures from a vendor rather than compute them itself, and did not require the fund and its reference portfolio to use the same model.

There are three reasons to change an engine, and none is Rule 18f-4 itself. The engine cannot meet the parameters, for example a short history for a new asset class. It cannot capture what the fund holds, typically options priced on delta alone, which the SEC warned can give misleading results for portfolios with significant options. Or it cannot produce what the program needs from it: a one-day VaR for the backtest, component VaR to explain a breach, and what-if re-pricing of proposed trades. If it does all three, keep it.

Which systems feed a derivatives risk program?

Six sources, each with a cut-off that decides whether a night's test is complete. The table lists what each provides and the failure that most often reaches the test unnoticed; the sample timings are from the fictional firm's run of Thursday, October 15, 2026, which tested 45 funds and 118 limited derivatives users between 5:45 and 6:44 pm Eastern, as of the 4:00 pm close.

A seventh source matters for explanations rather than numbers: central bank and market notices. In the sample firm's data, a backtest exception in an emerging markets debt fund was explained by a central bank's notice, published in Spanish, suspending onshore currency settlement for non-residents for one day. The notice is kept in its original language beside the English reading.

What connects the risk engine to the board report?

A chain of custody for each figure. A ratio in the board report is only as good as the path that carried it there: the run that produced it, the check that confirmed it, the person who reviewed it and the version of the settings in force. Rule 18f-4 requires the derivatives risk manager's regular reports to cover exceedances, stress testing and backtesting "since the last report", and the annual report to include the basis for the reference portfolio; every figure in them must agree with five years of daily records.

In Derivatives Risk Management Program the chain is the run log. Each agent's work is recorded with its inputs and outputs, and the Reporting agent drafts the board report, the Form N-PORT VaR items and any Form N-RN from that log, citing each figure. An analyst checks the draft and the derivatives risk manager releases it; the chief compliance officer submits filings. Nothing is retyped, so the four documents that carry a ratio, the limit report, the board report, N-PORT and N-RN, cannot disagree.

Can derivatives risk management software work with an existing risk engine?

It should, and that is the main thing to test before buying. The program layer needs four things from an engine: a way to request a run for a set of funds as of a stated time, the results with identifiers it can cite, component VaR by position, and on-demand re-pricing of a proposed trade. It needs nothing from the engine's internals, and it should never change the engine's settings.

The firm's own choices then sit in one place, versioned. In the sample firm's settings, the limits Rule 18f-4 sets, 200% and 250%, 20% and 25%, 10% for limited users, 99%, 20 trading days and three years, are locked. The firm's choices, such as a near-limit warning at 90% of the limit, a 6:00 pm test time, historical simulation over 756 days, Thursday backtests and stress tests, the NYSE calendar for the cure clock and twice-daily tests during a cure window, are settings an administrator proposes and the derivatives risk manager approves.

The rule's limits locked; the firm's engine choices versioned

Rolling it out on top of the engine: a parallel run, then the switch

Because nothing is replaced, the rollout is a comparison. Connect the program layer to the sources and the engine read-only; run it beside the current process for a period that includes at least one weekly backtest and stress run; compare every fund's ratio, every backtest count and every draft report with what the current process produced; and investigate each difference until it is explained. Only then do the board reports and the filing drafts switch over, with the board told in the next regular report.

The parallel run is also the first measurement of the old process. Every difference is either an error in the new layer, to be fixed before the switch, or an error the old process had been making, to be fixed regardless. Examiners have found policies that were not followed in practice: the SEC's November 2024 risk alert lists derivatives and liquidity risk programs among the areas where fund policies were missing, not reasonably designed or not effectively implemented (SEC risk alert).

What to ask a vendor of derivatives risk management software

Ask about integration and authority before features. A program layer that cannot read the firm's sources without copies, or that can change what it should only read, adds risk rather than removing it.

Where Derivatives Risk Management Program fits, and what it leaves to other systems

It is the program layer for Rule 18f-4, and only that. It does not replace the risk engine, the order management system, portfolio accounting or the data vendors; it does not trade, file with the SEC or contact the board. Counterparty limits and reviews belong to Counterparty Risk Management (what a counterparty risk system needs), ISDA and CSA terms to ISDA and CSA data extraction, and collateral calls to margin call management. Each is a separate program with its own rules and its own people.

The board sees the result as one report written from the run log, released by the derivatives risk manager. For the cost of the errors this layer is designed to prevent, see value at risk software and the cost of a wrong VaR day; for the controls inside a single test, see value at risk in Excel and the check a workbook lacks. The whole program is on the Derivatives Risk Management Program page.

The board report the program layer writes from the run log

Questions people ask

What is a risk engine?

A system that revalues a portfolio under market scenarios to compute value at risk, stress losses, sensitivities and attribution. For Rule 18f-4 it must support a 99%, 20-trading-day VaR on at least three years of data, a one-day VaR for backtesting, and the risk factors the rule names, including options' nonlinearity and volatility.

What is the difference between a risk engine and derivatives risk management software?

The engine computes; the program decides, records and reports. Derivatives risk management software in the sense used here sits on top of the engine and handles the rule's workflow: input checks, verification, escalation, the five-day count, board reports, Form N-RN and five years of records.

Do we need to replace our risk engine to comply with Rule 18f-4?

Not if it meets the rule's parameters, captures the fund's risk factors, and can provide one-day VaR, component VaR and what-if re-pricing. The SEC allowed funds to choose their model and to take VaR from a vendor.

What is the best risk management software for asset managers?

No regulator or independent study ranks it, and the answer depends on what a firm already runs. For Rule 18f-4, judge software on whether it uses your engine, reads your sources without changing them, holds on missing data, verifies independently, and ties every report figure to the run that produced it.

How long does it take to put a program layer on an existing engine?

It depends mostly on access to the sources and the length of the parallel run. A sensible plan includes at least one full weekly cycle of backtests and stress tests run side by side with the current process, and a quarter-end report drafted both ways before the switch.