Guiding principles for a viable open source operational risk model

Guiding principles for a viable open source operational risk model (OSORM)

Such a framework:

  1. Must avoid formulaic inclusion of meaningless risk event types (e.g., legal risk created by the firm’s own management decisions) or any risks where the nature and state of current knowledge does not support any meaningful quantification. Such potential risks would be managed outside the framework
  2. Must employ a bottom-up design that addresses the risk characteristics of simpler business units first and (if needed) creates a combined profile for a more complex business in a building block fashion.
  3. Must avoid formulaic integration between different event risks (that is, positing dependency or correlation) when qualitative and quantitative reasoning does not support it
  4. Must cover a comprehensive event risk taxonomy that is well adapted to the nature of the firm
  5. Incorporates effectively all relevant organizational information (e.g., Key Risk Indicators or other business line characteristics that are demonstrably generating or affecting operational risk)
  6. Involves clear explanatory narratives as to the causes of operational risk (and the drivers of severity). Thus, it links operational risk realizations to concrete attributes of the firm and its environment. This implies preference for fundamental (factor) modeling over agnostic reduced form approaches
  7. Is sufficiently concrete and expressive to enable introducing management control parameters. In other words, answering the question: how can we reduce operational risk
  8. Must use all relevant empirical historical loss data either at the stage of the model building or at the validation stage
  9. The probability distributions employed should reflect the nature of the risk and be valid at the widest possible confidence level range
  10. Must incorporate forward looking elements (e.g. via scenarios) that are consistent with the current and past behavior / response of the firm
  11. Should allow the documentation any difficult or subtle choices with solid expert reasoning
  12. Is the simplest model that is fit for purpose!
  13. Last but not least: It is open source, making its advantages and limitations transparent to all stakeholders

Discussion / contributions are welcome.