What’s the Secret to Automating Risk Management?

In the last few years, my team has been involved in automating risk management for investment decision-making, vendor accreditation, market risk, tender process, treasury management, credit risk, and project management. That’s eight different software packages selected from dozens of possible options. In this article, I wanted to share some important takeaways from our risk management automation.

Ask What the Market Can Offer Before Listing Your Requirements

Time after time, I discovered that software vendors often had interesting ideas and methodologies, something that we hadn’t considered or something that was good enough to do the job, even if it was a slight variation on our own approach.

For example, we were very glad to discover a vendor offering risk management automation for procurement that did a good job at capturing tax, compliance, and performance risks. Or Archer Insight, which has a back-tested Monte Carlo engine built in that allows risk aggregation across the company in a mathematically sound way.

So, my first advice would be to come up with problems and make them as broad as possible because you never know if someone in the market has a better way of solving the same problem than you can ever imagine.

A couple of times, I literally used automation as an excuse to improve on the existing risk methodology. We did that for market risk, credit risk, and investment decision-making. Don’t waste this opportunity to upgrade your risk methodology; automating what you did yesterday is just bad management.

In my experience, RFP is an important contractual obligation between the vendor and the company, but I always made sure that I knew which solution we needed long before we started drafting the RFP.

For me, it was much more important to talk about specific use cases that we needed, read the methodology, or review back-testing results. Temporary trial access or at least video demonstrations allowed me to see and feel the functionality and be real about what expected tasks would be solved and which wouldn’t be.

Don’t Chase Perfect at the Cost of Retaining Risk

This point is huge. In 8 software implementations and 30+ vendors, I found zero software packages that had absolutely everything we wanted. Let me rephrase that, out of the box never had every functionality we wanted, but everyone was offering to develop a tailor-made solution for us; it would just take time and cost extra. That’s because every company is unique, and your risk methodology probably has some nuances compared to the other 100 software implementations.

When thinking of automation, we always separate core important functionality from nice-to-have functionality. Every software decision, in my experience, was a trade-off between selecting the software that automated most of the things important to us or retaining the risk exposure while looking for a perfect match.

Keep in mind that every day, your credit, market, or performance risk is not automated, monitored, and mitigated; the company owns that risk exposure and can lose more money than the cost of software implementation. That’s why we first focused on automating the parts of risk management that had immediate and direct savings.

For example, implementing risk management into vendor accreditation protects the company from tax liability, credit risk, and sanctions, which is a significant saving. The same goes for investment management.

Automating risk analysis as part of investment decisions increases transparency, gives more comfort to the Board, and allows management to identify and prevent significant risks. Another example is risk quantification for setting limits and automating reporting and monitoring of operational risks.

Automation saves money not just by saving man hours on data entry and report generating (that’s easy) but by reducing the risk exposure, reducing expected losses and reducing the required capital requirements.

Just keep in mind, it may be more cost effective to change own risk methodology instead of investing into software modification if both produce the same result.

Backtest the Proposed Methodology

As you can probably tell from the article I am big fan of risk management software that comes with its own methodology. And if the software vendor is offering a methodology I want to see the back tests. Because if the back tests are not available I will need to run them myself.

This is exactly what we did for one of the biggest vendors in vendor accreditation in the country—only to discover their out-of-the-box methodology led to disqualifying more than 70% of good vendors. Another surprise was the fact that out of 155 risk factors advertised, only 30 made a significant difference. This allowed us to update their risk model and continue to use the software effectively.

There were plenty of positive examples, too. Credit risk models showed great accuracy, performance risk models had their own backtests, and Archer Monte Carlo and the risk aggregation engine are world-class.

When implementing software with methodology, it is important to make sure the methodology is solid and that you feel comfortable relying on it for decision-making.

Join RAW2024 to Learn More about Risk Management