Young hacker smiling

Zero false positives

Expert intelligence + effective automation

Choices. Photo by Nathan Dumlao on Unsplash: https://unsplash.com/photos/pMW4jzELQCw

Risk indicator roundup

A matter of taste
A comparison of risk indicators used in quantitative finance. Most of them have been discussed earlier in the blog, such as VaR, tVaR and LEC. We also introduce the ALE, and compare them all giving their respective pros and cons. In the end, it is a matter of choice or we can just use them all.

What is the best risk indicator? Bottom line: there is no "best", only different approaches to the same thing. Ultimately, it’s up to you. Here we will show the pros and cons of each so you can make an informed decision (about that which will guide your informed decisions, if you allow the inception reference).

VaR

Recall that Value at Risk (VaR) measures the worst-case scenario in an uncertain return by telling us beyond how much our losses will most likely not go, up to a certain degree of confidence, in a definite period of time. Thus a daily 1% VaR of $10 million means that the probability that you will lose more than ten million is 1%, which is the same as saying that you are 99% confident that the losses will not exceed $10 million.

Pros:

  • Gives a good idea of how much to save in order to avoid bankruptcy in most (95%) cases.

  • It is a well established standard, used by most banks and a requirement as per international banking regulations.

Cons:

  • Says nothing about what might happen beyond the threshold.

  • In fact, being a single number, its expressiveness is rather narrow. It says nothing about what happens elsewhere with the distribution of returns.

tVaR

While the VaR gives a worst case with a certain confidence, what if that confidence is broken, i.e., the VaR is breached? What can we expect? That’s precisely the answer the tail value at risk tries to answer. By using the expected value of a conditional probability, it gives us, in a single number, what would be expected in case that the dreaded worst case scenario occurs.

No better way to summarize both VaR and tVaR than does this plot by Nematrian:

(t)VaR illustration
Figure 1. (t)VaR illustration

Pros:

  • Prepares you for the worst of the worst

  • Single number, easy to compare or monitor over time

Cons:

  • Not too easy to compute (involves an integral).

  • Can be overly pessimistic, thus impeding you from seeing the other side of the coin.

ALE

OK, this is a new one. Not all that new, though. Remember we discussed Return on Control (ROC) to decide whether investing in a given defense is worth the hassle?

Return on control
Figure 2. Return on control

The change in loss was obtained from two simulated scenarios: one with the control and another without it. Both were obtained by "averaging out", i.e. finding the expected value of a simulated distribution for the loss.

The Annualized Loss Expectancy (ALE) is related to such a computation, in that it is also obtained from a couple of expected, estimated values, namely, the expected number of ocurrences of an event in a year (the Annualized Rate of Occurrence, ARO), and the expected loss for a single ocurrence (Single Loss Expectancy, SLE). Thus, total = reps x single. Too many acronyms for not too much content:

Acronyms joke
Figure 3. You don’t want to ask Chandler about his Annual Net Usage Statitics!

The ARO can be estimated by experts. Suppose that it is known that a data breach will most likely occur at least once in 10 years, the ARO for such an event is 1/10 = 0.1 events per year. The SLE is to be estimated by your own experts. How much would such a breach cost you? Say, $100 million. Then the loss expected in every one of those years is 0.1x100 = 10 million. However this rate will be fixed for each of the next ten years. It is static and unlikely to be true, since risks and threats change daily.

Pros:

  • Simple computation.

  • Single number, thus easy to compare.

Cons:

  • You’re stuck with the one year period.

  • Not very "realistic".

LEC

This is a decidedly different one, and one of our favorites at that. The loss exceedance curve. We have already discussed it at length in our introduction to quantitative risk, our general Monte Carlo simulation article, and gave an implementation in Quantitative Python. In a nutshell, it is a graph that tells you the probability of losing a given amount or more, for any amount in a range. It’s like having all possible values-at-risk for all confidence levels. We believe the graph speaks for itself:

Loss Exceedance Curve
Figure 4. Loss Exceedance Curve from Hubbard et al.

Pros:

  • All the information you could want about losses, in a single plot.

  • Since it is a visual tool, that aids in considering a range of risk to take, especially when combined with residual risk and risk tolerance curves.

Cons:

  • Harder to compare since it’s not a single number.

  • Harder to obtain, since it involves simulations.


Overall, single number risk indicators (ALE, VaR and tVaR) are good for making quick comparisons and monitoring them over time. In contrast, the LEC might allow you to make a more fine-grained decision regarding how much risk you are willing to take vs. how much you would have to lose in many different scenarios, all in a single chart.

For ease of use, we’d say ALE is the winner. However, we wouldn’t expect its predictions to be the most accurate of the lot. Also, its time period (year) might be too much for the fast-paced market we currently live in. If you have to choose one single-number indicator, we would recommend to go for the VaR, as do international banking regulations (Basel II), since the tVaR might be a tad too extreme.

In the end, it’s your choice. Or there might not be any choice to make at all: who says you cannot use them all at once? If well done, they should not be contradictory, but complimentary. Find out all you can about your investment, use all the tools at hand, and you might well be making the best decision in terms of risk vs gain.


Author picture

Rafael Ballestas

Mathematician

with an itch for CS



Related




Service status - Terms of Use