Your Risk Reserve Is Built on a Number That Cannot Be Right

Most organizations set financial reserves using an average. An expected loss. A most-likely scenario. Then they defend that number in a board meeting with a straight face.

The problem is mathematical, not political. A single number cannot describe a distribution. And risk is always a distribution.

I’ve spent years watching risk managers produce beautiful reports full of red, amber, and green labels while the actual financial exposure sat undescribed in the tail of a curve nobody drew. The tools to draw that curve exist. Most of them cost nothing. And almost nobody uses them.

That changes today. I’m sharing a fully open-source Python model that runs a compound Poisson-lognormal Monte Carlo simulation across 100,000 scenarios in seconds, from a free browser tab, with no software to install. You can find the code on GitHub here: github.com/hwyler/HernanHuwylerRiskManagement/blob/main/PythonMinMaxConvMCS2

Here is why it matters and exactly how to use it.

The Averaging Trap

Picture your team estimating the financial impact of an operational disruption. Someone says losses typically run between $50,000 and $200,000. Someone else says it happens roughly four times a year. A spreadsheet multiplies those numbers. The result goes into a budget line.

That process just threw away all the information about uncertainty.

What happens when three incidents converge in one quarter instead of spreading evenly across the year? What happens when one of those incidents lands at the top of the severity range instead of the middle? What happens when two happen to be catastrophic outliers that your range never captured?

Averages cannot answer those questions. They produce one number that describes the center of an experience you will almost certainly never have. In risk management, the center is not where the damage lives. The damage lives in the tail.

Monte Carlo simulation does not remove that uncertainty. It makes the uncertainty visible. You run the scenario 100,000 times, let frequency and severity vary independently across each trial, and read the shape of what comes out. That shape tells you something a single expected value never can: how bad do things get when they get bad, and how often does that happen?

Why Compound Poisson-Lognormal

The model I’m releasing uses two distributions that actuaries and operational risk practitioners have relied on for decades because they match how loss events actually behave.

Frequency follows a Poisson distribution. This means events occur randomly and independently, at an average rate you specify. If you expect four incidents per year, the Poisson distribution tells you the probability of experiencing zero, one, two, five, or twelve in any given year. It handles clustering. It handles quiet years. It handles the year everything happens at once.

Severity follows a lognormal distribution. Individual losses are non-negative, right-skewed, and occasionally extreme. The lognormal captures that shape honestly. You do not need to estimate the distribution parameters directly from data you probably do not have. The model calibrates them analytically from a range you specify: a lower bound, an upper bound, and your confidence that most individual losses fall inside that interval.

The aggregate loss for any simulated year is the sum of all individual losses that year. Run that calculation 100,000 times and you have an empirical loss distribution that reflects the actual probabilistic structure of your risk.

That is the math. You do not need to derive it. You need to understand what it is telling you when you read the output.

What the Charts Are Actually Saying

The model produces four charts. Two of them drive decisions.

The aggregate loss distribution is a histogram of your 100,000 simulated annual outcomes. Read the shape, not just the average. A narrow, symmetric distribution means outcomes are relatively stable. A long right tail means a small percentage of years can be catastrophic. If your reserve sits at the mean of a heavily right-skewed distribution, you are underfunded by construction. The math guarantees it.

You can see the histogram from the model here: huggingface.co/hewyler/compound-poisson-lognormal-risk-model/blob/main/histogram.png

The loss exceedance curve is the decision tool. It answers one question directly: what is the probability that total annual losses exceed any specific threshold? Read it against your organization’s actual pain points. Where does your liquidity strain begin? Where do loan covenants trigger? Where does your insurance retention sit? Plot those thresholds on the exceedance curve and you know immediately whether your current financial structure can absorb the exposure the model is describing.

The other two charts are sanity checks. The events-versus-loss scatter shows how frequency drives total exposure. The correlation heatmap confirms the simulation logic is behaving as expected. Both take thirty seconds to read and either confirm your inputs or surface a calibration problem before you build a decision on it.

Running It in Five Steps

You do not need to be a programmer. You need a Google account and calibrated estimates of your risk exposure.

Go to colab.research.google.com and open a new notebook. Copy the full Python code from the GitHub repository linked at the top of this article. Paste it into the first code cell and press the play button. The model initializes and asks you for inputs.

Enter your parameters carefully. The lower and upper severity bounds are the financial loss range where most individual incidents fall. Not your absolute worst case. The range where you expect 80 percent of losses to land. The model uses that interval and your confidence level to calibrate the lognormal tail mathematically.

For frequency, enter the expected number of incidents per year. Four means roughly quarterly. Two means twice a year. The Poisson distribution handles the variation around that average.

Leave simulations at 100,000. Fewer trials produce unstable tail estimates. The model runs in seconds regardless.

Set your reserve percentile to whatever confidence level your organization requires for contingency planning. The 75th percentile means your reserve covers three quarters of simulated outcomes. Whether that is enough depends on your risk appetite and what the exceedance curve shows at that threshold.

Submit the inputs. Read the output.

What This Replaces

Commercial GRC platforms treat quantitative simulation as a premium add-on. Consultants charge significant fees to run models that are technically straightforward once you understand the underlying structure. Neither the platform lock-in nor the consulting invoice is necessary.

This model runs on free infrastructure. Google Colab requires no installation and no license. The Python libraries it uses, NumPy, SciPy, pandas, matplotlib, and seaborn, are all open-source. The calibration logic is transparent. You can read exactly what the model does and why.

I’ve seen teams spend months waiting for a vendor to configure a risk quantification module that produces a less complete output than this script generates in twenty seconds. The bottleneck was never the technology.

The bottleneck is the decision to treat quantitative risk assessment as something that requires expensive infrastructure rather than calibrated inputs and honest math.

One Thing to Get Right

The model is only as good as your inputs. This is not a limitation of Monte Carlo. It is a feature of any honest quantitative method.

Do not guess your severity bounds. Use historical loss data, insurance claims, industry benchmarks, or structured expert elicitation to anchor your lower and upper estimates. Do not guess your frequency. Use incident records, audit findings, or control assessment outputs.

The model will tell you the truth about the distribution that follows from your assumptions. If the assumptions are wrong, the distribution will be wrong. The math will be precise and the answer will be misleading.

Calibrate carefully. Then read the shape. Then make the decision with the full distribution in front of you instead of a single number that was always a fiction.

The code is free. The infrastructure is free. The decision quality is not free. It costs the effort of honest calibration and the willingness to look at what the tail is actually saying.

Most organizations skip that step. You don’t have to.

What’s the biggest gap you see between how your organization currently estimates financial exposure and what a full loss distribution would actually show?