Unsurprisingly in this day and age, risk management and risk modeling are booming fields. With that boom, however, comes a whole host of modeling software options that are ever-so-slightly different, along with a large group of vendors trying to convince you that their product is the best fit for your organization. As you might have guessed, though, every single program is not the best program for you, nor is it an easy/simplistic process to determine exactly which one fits.

An important caveat as you read this is that I won’t be recommending a particular software for your purposes in this blog. What I’ll be discussing is less akin to a concrete recommendation and more a general methodology you can use to make a reasoned decision.

What Does “The Right Software” Mean?

You might’ve already guessed what the answer was, but if you haven’t: “it depends.” Finding the right software for any institution is far more than picking one from a lineup; in fact, it’s more of a full process that involves multiple steps and decision-making across different areas of an institution.

The first step to getting the “right software” is to determine what the purpose of the model is and what the priorities are for your models. Do you want a model that might take less overall maintenance time at the cost of a significantly more rigid set of rules, or do you want something more customizable that can be tailored to your particular needs? The latter really boils down to a different question entirely: can you afford the time and money to train and establish a knowledge base for a smaller group of full-time employees (known as “power users”) at your organization who will take in-house ownership of developing and maintaining the ruleset for the models? It would, of course, be generally preferable to have complete control over your modeling rules, but it’s not always viable.

So then it becomes more of a question of which modeling software contains the set of rules that work at a serviceable level for an institution’s risk modeling needs. That’s where another step comes in. To understand what’s best at an institutional level, examining the kind of rules that exist in the risk modeling space and knowing what your needs are for those rules is crucial. When you purchase a risk modeling software from a vendor, these rules are typically present in some capacity for a more direct out-of-the-box approach in setting up the models. Some common examples of preset rules are:

• Access rules, which dictate how (and which) data is accessed from different places in your system.
• Parameter rules, which dictate the particular pieces of data that are used as factors defining the calculated aspects of the model. In financial risk modeling, this could be anything from loan age to particular internal/external risk variables.
• Assumption rules, which dictate the conditions we assume to be true. In risk modeling, this could be anything from presuming future market conditions to simplifying particular market behaviors.
• Modeling equations, which dictate (somewhat predictably) the mathematical formulas used to determine risk.

There are more types of rules, certainly, but this is at least a place to start. Taking into account what type of conditions you need in place for this subset of rules will give you an initial comprehension of the dealmakers and deal breakers in your modeling software. This doesn’t necessarily mean you can’t get something which mostly fits and can be somewhat customized, but that comes with its own caveats.

Common Pitfalls

Customizable software that can be rolled out without having to bear the overhead of model development seems like the dream, right? Well, think again. In that scenario, you essentially have one of two options:  train a power user, as mentioned earlier, or put in a custom order with the vendor for a particular feature to be added to or manipulated in your institution’s version of the software. This issue can be exacerbated by the difference between the actual functionality and the presentation functionality. If you’re familiar with the classic terminology of “brochureware,” it is similar to this. It is possible that the presentation level of the software has been built for show (no underlying dataset) that doesn’t reflect an automatic or functionally extensible version of the software. In fact, the version of the software you see in a vendor’s presentation when browsing risk modeling options could require manual manipulation or coding custom features not available in some levels of the software. Typically, you can mitigate some of the risk in that purchase by taking a structured approach to acquisition and asking specific, pointed questions during the presentations. Understanding what is provided out of the box, what must be built by you and what is “in the next release” (or what will be provided once enough clients want that feature or that you will pay for) is information that should be asked for.

The limited and untested software that can be behind “brochureware” then gets muddled in a host of other problems (which can also exist without that brochureware risk). As software in general gets more and more complicated, simply running it can require intimate knowledge of the software itself—not to mention the mathematical formulas behind it. Most of this time it does require that someone at your organization becomes a power user regardless, but the amount of effort it takes for a power user to become proficient in a particular software is worth considering in your initial cost-benefit analysis of risk modeling software. After all, you don’t want to have a software where you spend most of your time inputting information and running the software just to “fix” potential deficiencies in the models caused by a lack of features or incorrectly input rules because of a lack of training. On top of that are errors you find within the software itself that could need a future release fix on the vendor’s side or require custom code from the vendor, all of which can cause additional financial (and time-base) stress as you wait for a fix.

A Hopeful Note to End On

Late last year we assisted a financial institution with an RFP process for a risk modeling software solution to replace the one they had built in Excel. Of the three vendors, only one directly addressed the need of the financial institution. As far as the other two, one presented a solution that would give them a modeling “sandbox” to play in so that they could build whatever they wanted (assuming they had the time and expertise) and the other kept showcasing their consulting services, which didn’t bode well for out of the box feature functionality. Without the structured RFP process, the financial institution might have made their decision off of “what ifs” as opposed to what was needed.

Purchasing risk modeling software like with any risk based decision, it’s all about taking what you know, such as what your particular needs are, what you’re willing to compromise on, and how much you’re willing to spend, and using that to make the most educated decision when progressing. Make certain that at the end of the acquisition process, you understand, in a non-complex way, how the software will address the purpose you have defined. There is no such thing as “rock star software”. Richie Norton once said “success is a process, not an event.” Mitigation of risk continues to be the goal of the process game, and using your expertise in the risk management space to avoid risk in software acquisition continues to be a method-based path to success. Who would’ve thought?