Valuation risk management software: live in eight weeks

Valuation risk management is the daily work of checking that a fund's prices are right and proving it, and software for it is a different purchase from the risk systems a fund complex already runs. Those systems measure market risk, liquidity and counterparty exposure, and for US registered funds they map to separate SEC rules: Rule 18f-4 for derivatives, Rule 22e-4 for liquidity, and Rule 2a-5 for fair value. Valuation risk is the odd one out. It is not a number a risk engine calculates from positions; it is a daily workflow of checking prices, chasing second sources, testing methods, overseeing pricing vendors and reporting to the board, run by the valuation designee’s team rather than the risk team. Botminds’ Valuation Risk Management is built for that workflow, and because it works on the files a pricing team already receives, it can go live in about eight weeks on a complex’s own price files, valuation policy and board reports.

This guide is about valuation risk. The sibling programs have their own solutions: Liquidity Risk Management Program, Derivatives Risk Management Program, Counterparty Risk Management and Independent Price Verification. The plan below is our suggested plan, illustrated on a fictional sample complex, Quillfield Capital, with 90 funds; it is not a commitment for every complex.

Does a risk system cover valuation risk management? Usually not

Usually not, because valuation risk is a different question asked by a different rule. A market risk system takes prices as given and asks how much a portfolio could lose; Rule 18f-4 asks a derivatives risk manager to run a value-at-risk test daily and stress tests weekly. A liquidity system asks how quickly holdings could be sold; Rule 22e-4 asks for monthly classification into four buckets. Valuation risk asks whether the prices themselves are right, and Rule 2a-5 answers with four duties: assess and manage valuation risks, establish and apply methods, test them, and oversee pricing services (17 CFR 270.2a-5).

The difference shows in who runs each program. A derivatives risk manager “may not be a portfolio manager of the fund”; a liquidity program administrator may not be solely portfolio managers; and a valuation designee must reasonably segregate fair value determinations from portfolio management. All three are independence rules, but they put different people in charge, and the valuation designee is normally the head of valuation or pricing, not the chief risk officer. A risk platform bought for the first two rarely includes the evidence trail the third needs.

What is an investment risk management framework, and where does valuation sit in it?

An investment risk management framework is the set of policies, limits, people and systems a manager uses to identify, measure and control the risks in its funds, usually organised by risk type with a reporting line to the board. For a US registered fund the framework has several programs the SEC requires by name, each with its own rule, reports and records, and valuation is one of them. The SEC’s fiscal 2027 examination priorities name the area that links them: funds that hold less liquid or illiquid investments, private credit among them, and the valuation, redemption and disclosure questions that come with them (SEC, Fiscal Year 2027 Examination Priorities, October 23, 2026).

Valuation sits at the base of the stack because every other program consumes its output. A VaR model run on stale prices understates risk; a liquidity classification of a holding marked too high understates the fund’s illiquid share; a counterparty exposure on an overvalued derivative is wrong in both directions. The framework works only if the prices feeding it have been checked, which is why the valuation program is worth running on its own evidence rather than as a module of the risk engine.

What data does a valuation risk system need? Mostly files you already receive

A valuation risk system needs the files a pricing team already handles every night, plus the documents that define and evidence its policy. Nothing in the list requires a new data feed; the work is mapping what exists. The sample complex’s night run loaded prices from seven sources, from its pricing system’s file and evaluated-price vendors to fair value factors, exchange closes, independent valuations and broker quotes.

The eight weeks in detail: what happens, who signs, what is measured

Weeks one and two connect the files and load the policy. Each price source is mapped, with its level and asset class, and each threshold in the valuation policy is entered as a setting that cites its section: the sample complex’s five-business-day stale rule, its 30-day single-source limit on Level 3, its tolerances by asset class and its material-matter clock. The checkpoint is simple and strict: every file loads for a full week of past nights, and every setting points at a section the designee recognises.

Valuation Risk Management settings: the policy loaded, section by section

Weeks three and four replay the last quarter. The system runs every night of the quarter on the stored files and drafts the quarterly report from the result; the team compares the exceptions, register movements and report sections with what it actually produced. Differences are the most useful output of the whole project, because each is either a threshold that was not what the team thought, an exception the team missed, or a gap in the system’s mapping. The checkpoint is that every difference is explained and either the setting or the mapping fixed.

Weeks five to seven run the system nightly beside the current process. The pricing team works as before; each morning it compares its exceptions with the system’s, and the analysts begin proposing from the system’s evidence where it is complete. The designee watches three numbers: agreement on exceptions, the number of items below the confidence line handed to a person, and how long proposals wait for approval. Week eight is the designee’s decision to go live, recorded with a reason, and the first live quarter’s report becomes the measure of time saved.

What should you test before going live? Four tests on your own files

Four tests decide whether a valuation risk system is ready, and all four run on the complex’s own files. First, coverage: every price in every nightly file was checked, and the counts reconcile to the files. Second, agreement: on the replayed quarter, the system flags every exception the team flagged, and the extra ones it finds are real. Third, the board report: the drafted quarterly report matches the one the board received, number for number, or the differences are explained. Fourth, control: no price, method, register status or report can change without the person the policy names approving it.

The fourth test matters most and is the easiest to skip. It is the same independence concern regulators keep finding in valuation reviews: MAS’s 2026 paper found a manager whose pricing team had “no established requirement” to escalate a price that warranted a challenge to the approving authority, and managers whose own records could not show how exceptions were resolved (MAS, Valuation Practices for Fund Management Companies). A go-live that proves the approvals work is a go-live that answers that finding in advance.

Can valuation risk software run beside the fund administrator? It has to

Yes, and it should. The administrator usually strikes the NAV, and the valuation program oversees the prices that go into it; the two meet at the approved fair values the designee sends and the price checks the administrator returns. The sample complex’s system reads the administrator’s files, writes approved overrides back to the pricing system, and leaves the NAV calculation where it is. MAS found managers that failed to tell their administrators about approved fair values in time, which is why the plan tests the outbound path in weeks five to seven, not only the inbound one.

The designee’s first live morning: every decision waiting, with its deadline

Why valuation go-lives slip: four causes the plan is built around

Valuation projects rarely slip on technology. They slip on four things the files reveal once someone looks closely, and the eight-week plan is arranged so each shows up early.

The first is a policy that differs from practice. The SEC’s November 2024 risk alert reports fund policies “inconsistent with actual practices” (SEC risk alert, November 4, 2024), and a system that applies the written policy exposes every such gap on the first replay; that is a finding, not a failure, but it needs a decision. The second is definitions that differ between the fund and its administrator: MAS found an administrator treating three days unchanged as stale while reporting only those above seven days, and a manager whose own policy set no number at all. The third is vendor files nobody has documented, which make weeks one and two longer than planned; the sample complex’s night run had one vendor file arrive late, at 7:15 a.m., and the system handed it to the systems administrator rather than guessing. The fourth is an approval chain that exists in practice but not on paper. Rule 2a-5 requires the designee to specify the titles and functions of the people responsible for fair value, and a system that enforces who may approve what cannot go live until that list is written.

None of the four is solved by software. Each is solved by a decision the designee records, which is why the plan ends with the designee’s approval rather than a technical sign-off.

Where Valuation Risk Management fits in your risk stack, and where it does not

Valuation Risk Management fits beside the risk systems a complex already runs, as the program that checks the prices those systems consume. It does not compute VaR, classify liquidity or limit counterparty exposure; the sibling solutions do that, and software for managing investment risk maps the risk engine side. It does not replace the pricing system, the evaluated pricing services or the administrator. It gives the valuation designee one place where the four Rule 2a-5 duties are performed and evidenced, and where the board report is drafted from that evidence.

The cost case and the KPIs that should prove it are set out in the economics of Rule 2a-5 oversight, and the agents’ limits in what each agent may do, and never. To see the sample complex, start at Valuation Risk Management, or ask for a run on a sample of your own price files.

Questions people ask

How long does it take to implement valuation risk software?

Our suggested plan is about eight weeks for a complex of around 90 funds: two to connect files and load the policy, two to replay the last quarter, three to run beside the current process, and one to approve go-live. More price sources or administrators lengthen the first stage.

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

A risk engine measures exposures such as VaR, liquidity and counterparty risk from positions and prices. Valuation oversight software checks whether the prices are right and keeps the evidence Rule 2a-5 requires, including tests of fair value methods and oversight of pricing services.

Does Rule 2a-5 require a particular system?

No. It requires four functions and board reporting, and Rule 31a-4 requires appropriate documentation kept six years; the SEC left methods, thresholds and formats to each fund. A system is useful only if it applies the fund’s own policy and records each decision against it.

Who should own the go-live decision?

The valuation designee, because the system changes how its Rule 2a-5 functions are performed. If the change is a material change to methods or to the oversight of pricing services, it belongs in the next quarterly report to the board.

Can we pilot on our own data before committing?

Yes, and the replay stage is that pilot: run the system on your own last quarter’s price files, policy and board report, and compare. The differences show both what the system adds and what it would need before going live.