The product principle I care about most is simple: a scenario result should be easy to challenge.
Treasury can calculate a stressed portfolio value in many ways. The harder requirement is explaining how that number was produced when the CFO, controller or auditor asks what sits behind it.
That is why I do not want Scenario Analysis to produce a number users are simply expected to trust. The evidence should already be there so the user can verify it.
One valuation engine was the first design decision
Scenario Analysis runs through the same valuation engine as the standard market valuation.
The deals and valuation methodology remain the same. The scenario changes the relevant market-rate inputs.
I consider that important because a second model creates a second maintenance and reconciliation problem. The standard valuation already supports the market values and, for relevant transactions, realised and unrealised accounting entries finance uses. The scenario should build on that calculation basis rather than create a parallel one.
A useful scenario has an assumption professionals can understand
A scenario should be clear before anybody looks at the result.
A +100 basis point rate movement is clear. A defined FX shift is clear. Users can name and describe the scenario, apply it across the relevant exposures or target selected rate sets and currencies, and then reuse the same definition when the question returns.
That clarity matters in risk discussions. It is much easier to challenge a sensitivity result when everybody understands exactly what market movement was tested.
Parallel interest-rate shifts are the current starting point
Release 2026.11 starts with parallel shifts for interest-rate curves. A selected curve moves by the defined amount across its periods, while different selected rate sets can use different shifts.
This covers the type of stress test that is commonly used for IFRS 7 reporting and in many treasury risk discussions.
More granular per-period shocks and scenarios based on separate market data sets are planned. I prefer that sequence because the first version should make the core analysis reliable and repeatable before adding more modelling options.
The valuation log should expose the deal-level calculation
The portfolio result is useful for the first conversation. The valuation log matters when the discussion goes deeper.
For an individual deal, users can review when the valuation ran, who ran it, the market data used and the calculation detail behind the result, including the relevant cash flows. Standard valuation and scenario results are available in the same context.
Most professionals won't review that level of detail every day. The value is knowing it already exists when somebody asks where the number came from.
Scenario Analysis should cover the portfolio treasury actually manages
I also want scenario analysis to reflect the instruments that create the organisation's real exposure.
That includes FX forwards, swaps and spot transactions, interest-rate and cross-currency swaps, loans, deposits, bonds and discount instruments. For floating-rate positions, the future cash flows are reforecast using the scenario rates.
The risk that deserves attention is not always sitting in the instrument everyone is already watching. Wider coverage helps treasury see where the sensitivity actually comes from.
Stored results make the analysis verifiable later as well
A scenario result should still be available months after the calculation.
Nomentia stores results per deal and valuation date, including values in the original deal currency, accounting currency and group base currency. Treasury can reopen the calculation later instead of trying to reproduce what was presented at an earlier reporting date.
That is part of the audit trail for me. A team should be able to revisit what it knew at a particular point in time and see the evidence behind it.
Control belongs where the scenario definition changes
Creating and editing scenarios has a dedicated user right, and changes to scenario definitions are logged.
The wider team can still use approved scenario results in Deal Management and Transactions reports without needing that configuration permission.
That separation is deliberate. Professionals authorised to define it should control the assumption, while the resulting information should remain practical for everyday treasury work.
IFRS 7 is one reason to run the scenario, not the only one
IFRS 7 gives companies a formal reason to perform market risk sensitivity analysis. Treasury has plenty of reasons to keep those scenarios available during the year.
A saved rate scenario can support a refinancing discussion. Treasury can rerun an FX scenario after a sharp currency move. The same analysis can support a hedging review or answer a question during a board meeting.
The objective is for treasury to produce the answer while it is still useful and show how it was calculated.
That is the standard I want from treasury scenario analysis: fast enough to support the decision and transparent enough to verify.
Marc Vietor
Chief Product Officer, Nomentia