Nearly everyone in corporate finance builds models, but how many of us actually learned financial modeling in a formal manner, are taking advantage of collaborative environs with open-ended architectures, and following best practices? And how can the CFO manage these challenges?
This is the second article in the series by Rob Trippe about managing financial models. Click here to view all articles in this series.
After the Great Recession of 2008, U.S. federal regulators asked why so many sophisticated financial service companies failed to see the risks and mitigate the impacts that contributed to a financial panic and shuttered respected firms that had been considered secure. One step regulators took was to amplify model governance for the financial services industry, and with that came the need for a definition of what a financial model really is. In the U.S., this came in 2011 in the form of SR 11-7, Guidance on Model Risk Management, issued by the Federal Reserve and the Office of the Comptroller of the Currency.
Financial Models, Defined
So, what is a model? Are Excel workbooks considered to be models? Or are models confined only to large, complex data driven statistical models?
Financial models come in a variety of shapes and sizes, but all share common traits. SR 11-7 defines a model as a: “quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates.”
SR 11-7 goes on to tell us that to qualify as a model our quantitative estimates, or the analysis, must do the following:
- Employ academic theory
- Consist of three components—inputs, calculation processes and outputs
- Transform data into useful business information
- Be used on a recurring basis
- Have output quantitative in nature
- Require subject matter expertise
- Possibly contain qualitative model inputs or output.
As a practitioner, I think of a model as a simplified representation of a larger system that I am trying to study. Models will almost always convert a set of simplified assumptions and a series of conditions and rules in the form of limits or bounds, to numerically expressed output.
Models are not limited to one programming language, environment or application. I suggest the term “model” should be viewed “wing to wing” from initial data inputs to final model output. Numerous programming environments may be involved in financial modeling, as well as numerous data sources.
Given the above criteria, many “models” in Excel are simply not models at all and are sometimes referred to as “tools”. These tools include Excel workbooks, which store downloaded data or organize financial statements and accounts. Workbooks performing simple math calculations may be tools as well.
The distinction is important because models imply that value is at risk, and therefore require more scrutiny than tools. By reviewing and determining what is and is not a model, we place ourselves in a far better position to implement policies and procedures to address risk exposures (a future article). Those exposures come in the form of materiality and complexity.
Materiality: What is the value being put at risk?
Once models are defined, model governance will often tier a company’s models into risk classes. For modeling, creating risk class groups recognizes that different models have different levels of financial gain or loss (materiality), critical decision-making, and/or reporting/regulatory requirements. Creating model tiers allows for differentiated rigor based on materiality. The figure below shows how models may be placed into Tiers 1, 2 or 3 based on these criteria.
Complexity: What is the potential for model failure?
Complexity of a model should also be a determining factor in model tiering[BL1] [RT2] [RT3] ; the basic idea is that that are more commonly known and transparent ones are considered less risky than things that are newer or more opaque. While complexity may come in the form of design, theory, concept, code, or mathematics, my experience tells me that the two below are the most focused upon.
Code complexity addresses the challenge of building an error-free model in a format that is readable and understandable by a large number of reviewers. Model governance tends to tier language-driven models higher than application-driven models employing software such as Excel.
Mathematical complexity addresses the challenge of understandable calculations within the model. Within finance and statistics, there are two common types of financial modeling processes. The first is a “deterministic modeling” process. Deterministic models are mathematical models in which outcomes are determined through known relationships among data and assumptions, without room for random variation. In a deterministic model, utilizing the same input data and assumptions will always produce the same output. There is no random element. One example is a typical discounted cash flow (DCF) model. These models are often viewed as having a lower risk rating because the inputs are visible and the calculation is well-understood, even though they may be calculating high financial risk exposure due to frequent use and for critical exercises such as valuation, acquisitions, and mark-to-market analysis.
By comparison, “stochastic models” have a distribution of potential outcomes since they allow for random variations in one or more inputs. The random variation is usually based on fluctuations observed in historical data for a chosen period using standard time-series techniques. In other words, assumptions are not precisely known and may vary through time. Monte Carlo simulation is one example of a stochastic model. In my experiences, model governance places stochastic models in higher risk tiers than deterministic models due to statistical technique complexity.
Subjectivity is clearly at play in this classification. For example, a sophisticated language-based statistical model forecasting inflation could serve as only a feeder model (upstream) to a far simpler Excel workbook with little materiality to the overall finance function, yet be considered a high risk. In contrast, a forecast earnings or cash flow model whose output is communicated by a Fortune 500 company to its shareholders could be housed entirely in Excel with no statistical modeling whatsoever and yet be among the most important financial model a firm possesses, but be classified as low risk. My advice to the CFO is this: formalize your modeling processes and EXPECT better, more effective output. This can be achieved by determining which analyses are models, and reviewing financial and risk exposure of each model. And so begins a model risk and governance program, formal or informal. For obvious reasons, corporate level FP&A is the ideal resting place for these responsibilities.
A review of a firm’s financial models will help quantify financial materiality, uncover commonality and dissimilarity in both data input and model output among models, assist in data management, and uncover critical model links and duplicity. Model log jams and key person/department dependence will also become more evident. In the next article, we look at best practices for model development.
Rob Trippe is M&A, corporate finance advisor and analyst for Corporate Finance Consulting & Advisory. Read the first part of this series, Financial Modeling and the Executive Suite.