Causal Capital is hosting an advanced ERM masterclass in Dubai and we will demonstrate more of these models during that program [LINK].
In the previous article on Systemic Risk and Fragility Part I [LINK], we explored the reasons why enterprise risk management teams should develop a solution for assessing systemic risk. We also discussed how risk management can improve their 'resilience likelihood' from the effects of different systemic shocks, if management teams are able to decode their Directed Network Activity Layer (DNAL) and treat risk within it.
Our first article seems straightforward enough, quite obvious overall and we know that this type of network modelling is used in a lot of different risk management and scientific domains. For an enterprise risk manager, modelling a DNAL structure for say, a basket of twenty risks across ten departments could actually end up being quite a challenging task.
Firstly, there is a lot of potential network node data that needs to be summarised in the model. This data is relatively easy to capture and I recommend risk managers simply extend their existing risk registries and 'add-on' source~target mapping but even still, the modelling of this network data also needs consideration.
Fig 1 : Adding the DNAL to an existing Risk Register | Martin Davies
In the risk register shown in figure 1, you can see the selected risk "System Outage" has various source~target outcomes throughout its departmental 'Supply Chain Effect Network'.
There is a lot of assessment data we could record for each event in the risk registry but at the moment; all we are trying to do is map which nodes are driving the highest amount of dependency or fragility in the organisation. This is Just what the IMF has done with their Deutsche Bank case study (see part I of this article set).
Emerging Practices for Enterprise Risk Management
We also need to keep this process relatively simple in some respects and as far as I know, this is relatively uncharted territory for enterprise risk managers. When it comes squarely to Enterprise Risk Management, I am not sure I have seen this type of network modelling being entertained at a macro level except in utility companies and banks.
Fig 2 : Modelling Control of Complex Interactive Systems | Massoud Amin [LINK]
In power distribution, the concept of fragility modelling is attracting a lot interest and goes under the term Self-Healing Networks. I have read a few papers on the subject and I am more than happy to share the research with risk practitioners if the interest is there. Just send me a catch up email and I will respond accordingly.
In the link above, brought to you by the New York Federal Reserve as it is here, Massoud Amin presents a fantastic research presentation on Self-Healing National Infrastructures and his focus is on power distribution. It is curious might I add, to see the New York Fed hosting such a paper and one does ponder on whether they have designs for introducing this Self-Healing Resilience concept into the banking sector.
Fig 3 : Network Schematic of Business Unit Dependency and Fragility | Martin Davies
Anyway, back to our IMF style Systemic Risk Map. We have captured source and target 'department mapping details' for different risks in a risk register and we can model this data in R-Project using several libraries such as the network package. This time round, I have chosen to use igraph for the modelling effort.
Fig 4 : Focal point or node fragility for systemic risk | Martin Davies
The resulting schematic shows the different departments in our combined DNAL enabled risk register and for all risks in one aggregated map. This is a very useful report for risk managers because they can see fragility or dependency as it is at an firm wide level. The departments that feature most for different types of catastrophes will have the most connections, as one would expect. These are the departments that need the highest level of control or crisis recovery response planning and the map assists with highlighting the fragility path for different types of catastrophes.