Feedback concerning some preliminary design ideas of a cashflow package

I need to develop a stochastic discounted cash flow package for a project, where the analysis should include both private cost/benefit and public good values.
The specific domain is the valuation of forestry investments, but I am more akin to do something much more general.
Unfortunately, generality doesn’t always go well with simplicity, especially simplicity for the end user.

I have sketched below some ideas of the package I would like to implement, and would like to get some feedback from you, especially on design choices and possible alternatives.
This would be an open source project, so if you are interested in co-developing it, I would be super happy about it!

StochasticCashFlow

A stochastic multi-stakeholder discounted cash flow for cash flow analysis and project evaluation

Main ideas at this point:

Objective of the package:

To enable a cash-flow based analysis of a hypothetical investment, considering simultaneously several “points of view” (called “subjects” in the package: e.g. the investment owner, the local neighbourhood, society as a whole…), where some cost (or benefit) entries are stochastic and depend on complex interrelationships between different random variables. The user of the package must be able to specify these complex relationships between random variables and the effect on the cash flow entries.

The package must be able to adapt to different specific investment typologies where the metric of interest may be different (NPV, IRR, but also more specific ones such as Soil Expected Values for land based investments).

Overview of the package

The package separates the concept of state variables from that of cf entries (see later). The user either defines his own state variables and cf entries and their logic, or uses predefined ones provided by the library for specific investment typologies. The same applies to the metric to be observed from the cash flow, which can be user-defined or available in a library of metrics.

The package uses a Monte Carlo approach, where it returns a distribution (or possibly some statistic) of the specific metric desired, for each specific subject specified in the model.

Higher level functions can then be used to search for the parameters of the state variable definitions or cf entries that maximise (or minimise) the desired statistic, transforming these parameters into control variables.

Overview of the implementation

Each cash flow model is defined by some cf-specific parameters (number of MC iterations, number of time periods,…) and two sets of state definitions and cf items definitions, respectively.

State definitions are structs that are subtypes of StateV, while cfitems are subtypes of CFRecord.

StateVs are state variables that can be deterministic or stochastic, and whose concrete state at time t can depend on their own and previously defined states at times [1,t]. However, they do not directly carry a CF entry.

CF entries are the final CF values (costs of benefits). They depend on specific states of the state variables, and they may have a random component themselves, but CF entries can’t depend on other CF entries. Conversely, they have the attribute “subject” to indicate to whom they belong (investment owner, local users, society as a whole…).

Example of state variables for forest investments (plantations): “Storm”, with the parameters “Damage” and “Relative average times of return”, and “Timber quantity”, with the parameters of a logistic function and depending on the variable “Storm”.

Example of CF entries for forestry investments: “Timber sale” with parameters the means and standard deviations of prices for different quality of timber and associated agent the forest owner, or “Ecosystem services” with different entries associated to the agent “Society”.

Once specific instances of state variables and CF entries are created, they are added to the CF object together with a registry of their realisation over time.

The logic that defines the realisation of the state is in realise!(cf,t,s::StateV). Similarly, the registry of cf entries is populated with realize!(cf,t,cfe::CFEntry).

These two functions are executed in a loop, first for the state variables in a loop for each state variable (in the order defined in the CF object) and time period, and then for the CF entries.

Once specific realisations of state variables and CF entries have been created, they are added to the CF object. This is done for each Monte Carlo iteration so that we end up with a set of stochastic cash flows.

Finally, these multi-realised CFs can be processed with some metric functions to return a distribution of the desired metric or a particular statistic of it.

Finally, the CF realisation/metric can be used in a higher level function to provide an “optimisation” function, where the user specifies the statistic to maximise and the parameters of the state definitions to change (e.g. the final harvesting period, the minimum share of damage to a forest to lead to replanting instead of continuing the rotation,…). In this way, any “parameter” of the CF model can be turned on as an endogenous variable.

I’ve built quite a few DCFs in my life so interested to see what comes out of it, but in my opinion they’re a classic case for which Excel excels (no pun intended) - often dependent on a variety of assumptions that the user wants to vary through some form of control sheet, and with the main outputs just tables of monthly/quarterly/annual cost and benefit streams which are quite useful to visually inspect to sense check the model.

MC is maybe not an ideal use case for Excel, although it’s doable and becomes pretty useable with plugins like RiskAMP

1 Like

Sounds like a super interesting project you have there, and a good fit for Julia imo if you want to do e.g. strategy optimization on top of your MC model.

In my day job, I do something almost identical, just for running a life insurance/pension company. But not, alas, in Julia :slightly_smiling_face:. If it becomes an open source project, I will be happy to offer thoughts and suggestions, and maybe a little pr now and then. As it goes for almost everyone, I can’t commit firmly to anything (due to time + IP considerations vs my employer).

Your outline of the structure sounds pretty healthy in my view, but it’s hard to say something concrete without seeing more code. I think it would be good to separate the ‘pure’ stochastic cashflow model from domain specific issues such as stakeholders and trees.

Some parts of stochastic cash flows may already exist (for inspiration or reuse) in the JuliaActuary ecosystem. @Alec_Loudenback will know that off his head.

1 Like