Risk Management puzzles, solved step by step

Expected annual loss is about Rs 2 crore, and the rare event is half of it. Twenty small losses at Rs 5 lakh cost Rs 1 crore a year. A Rs 5 crore loss every five years averages Rs 1 crore a year. So an event that is about 1% of the count is about 50% of the expected loss, and in the year it strikes the total is about Rs 6 crore.

Why does counting events mislead you?

Think of a household budget. Daily tea and snacks happen hundreds of times a year and feel like the big drain, but one hospital bill every few years can cost as much as all of them together. Expected loss is frequency times severity, and a rare event with a large severity can match or exceed a flood of small ones. Here twenty small losses a year produce Rs 1 crore, and one-fifth of a Rs 5 crore event a year also produces Rs 1 crore.

Why is the expected loss not the number a risk manager plans capital around?

Because no single year looks like the average. In four years out of five the bank loses about Rs 1 crore, and in the fifth it loses about Rs 6 crore; capital has to cover the bad year, not the average one. This is the gap between expected and unexpected lossThe loss above the average that a bank must be able to absorb in a bad year, usually covered by capital rather than by pricing or provisions.. Small, frequent losses are usually budgeted in the cost base; the rare, severe loss is what operational risk capital exists for.

Say the estimation problem too. The small-loss average rests on hundreds of data points; the rare-loss figure rests on very few, perhaps one event in the bank's own history. That is why operational risk teams add external loss data and scenario workshops: the half of expected loss that matters most is also the half measured least precisely.

You can rule out error rates above about 4.9%, and nothing below. If the true error rate were p, the chance of 60 clean trades would be one minus p, to the power 60. That falls to 5% at p of about 4.87%. The rule of three gives the same answer quickly: 3 divided by 60 is 5%. With a real error rate of 1%, a clean sample happens 55% of the time.

Why does a clean sample not prove a clean book?

Think of tasting one spoonful from a large pot to check the salt. A good spoonful tells you the pot is not badly over-salted, but a few salty patches could easily be missed. Zero errors in a sample puts an upper bound on the error rate; it never proves the rate is zero. At a true error rate of 1%, one trade in a hundred is wrong, yet 60 random trades would all be clean 55% of the time. The sample simply is not large enough to see errors that rare.

Where does the rule of three come from, and does the 3,000 matter?

The chance of zero errors is roughly e to the power of minus n times p, and e to the minus 3 is about 5%. So n times p equal to 3 marks the 95% bound, which gives the rule of three: divide 3 by the sample size. The population of 3,000 barely matters here because the sample is only 2% of it. Sampling without replacement tightens the bound slightly: counting exactly, the book could hold at most 144 errors, about 4.80%, instead of the 4.87% the simple formula gives.

Then give the practical point. If the firm's tolerance for booking errors is 1%, a sample of 60 cannot confirm it; you need about 300 clean trades, 3 divided by 1%, to rule out 1%. The limit is that the sample must be random; a sample of the easiest trades to check says little about the ones that go wrong.

About 81.9% for one year and 36.8% for five years. Random arrivals at a steady average rate follow a Poisson process, where the chance of none in t years is e to the minus rate times t. One year gives e to the minus 0.2; five years gives e to the minus 1. So a loss is more likely than not over five years, 63.2%, yet most single years are quiet.

Why is one every five years not a schedule?

Buses that arrive at random, on average every twenty minutes, do not arrive every twenty minutes. Sometimes two come together, sometimes you wait an hour. A rate of 0.2 a year says how often losses happen on average, not when; each year is an independent draw, and most draws come up empty. Losses that arrive independently at a steady average rate follow a Poisson processA model for events arriving at random and independently at a constant average rate, such as large fraud losses or defaults in a big pool., and the chance of seeing none falls away exponentially with time.

What should an operational risk manager take from a quiet year?

Very little. A quiet year happens 82% of the time even when the risk is fully present, and three quiet years in a row still happen 55% of the time. A business that points to a clean record and asks for lighter controls is reading noise as evidence. The flip side is equally useful: when a loss arrives after a long gap, it is not proof that controls suddenly failed; the average gap here is 5 years, and gaps of ten years happen 13.5% of the time.

The limit to say out loud: the Poisson model assumes losses arrive independently at a constant rate. Fraud often clusters, one weak control exploited several times, and rates change as the business changes. The model is a baseline for reading the record, not a forecast.

Recorded losses average Rs 30 lakh, 50% above the true Rs 20 lakh. Because the exponential is memoryless, losses above Rs 10 lakh exceed it by an average of Rs 20 lakh, so they average Rs 30 lakh. Fitting the records as if complete overstates the size of a typical loss by half, pushes the 99th percentile from Rs 92 to 138 lakh, and misses the 39% of losses below the threshold.

Why does a threshold raise the recorded average?

A school that only records exam scores above 60 will report a class average far above the real one, because the weak scores never enter the register. A reporting threshold removes the small losses from the data, so any average taken from what is left overstates the typical loss. For an exponential, the shift is exact: it is memorylessFor an exponential distribution, knowing a value already exceeds some level tells you nothing new about how much further it goes; the excess has the same distribution as the original., so the excess above Rs 10 lakh again averages Rs 20 lakh, and recorded losses average Rs 30 lakh.

What exactly goes wrong in the fitted model?

Two errors that pull in opposite directions. Severity is overstated: fit an exponential to the records and you get a mean of 30, so every quantile is 50% too high, with the 99th percentile of a single loss at Rs 138 lakh instead of Rs 92 lakh. Frequency is understated: only 60.7% of events are recorded, so the true count is 1.65 times the recorded one. A model that fits both naively gets the size of losses and the number of losses wrong at once, and the errors do not cancel in the tail.

The fix is to fit a truncated distribution: treat the records as losses known to exceed Rs 10 lakh and estimate the parameters of the whole curve from that conditional shape. For an exponential that means fitting the excesses over 10, which recovers the mean of 20. The limit is that heavier-tailed distributions are not memoryless, the truncated fit becomes unstable when the threshold is high relative to the data, and the missing small losses still matter for frequency.

About 6 false ambers a year. The threshold of 18 is two standard deviations above the mean of 12. If daily fails are roughly normal, about 2.3% of days land above two standard deviations on the high side, and 2.28% of 250 days is 5.7. Roughly one quiet day in every 44 will trip the alert with nothing wrong.

Why does a sensible threshold still fire when nothing is wrong?

A smoke alarm set sensitive enough to catch every real fire also goes off when someone burns toast. Set it deaf enough never to react to toast, and it may miss a real fire. Operational alerts face the same trade. Any threshold drawn on a noisy count carries a false alarm rate you can compute in advance, and the only way to cut it is to accept missing more real problems.

How precise is the answer of about six?

It rests on two assumptions worth saying. First, fails are whole numbers: if a count of exactly 18 triggers the alert, a continuity correction moves the tail to about 3.3% and the count to about 8. Second, real operational counts often have fatter tails than a bell curve, with bad days clustering around month ends and system changes. Both push the true false alarm count up, so six is a floor, not a ceiling.

In the room, close with what you would do: tell the operations team to expect about one amber every two months from noise alone, so that a cluster of ambers in one week, not a single one, is what triggers an investigation.

About 0.8% get through if the checkers are truly independent. Each misses 20% of what reaches them, so 100 errors become 20, then 4, then 0.8. The real figure is likely higher because the checkers are not independent: later checkers relax because someone already looked. If checkers two and three catch only 40%, 7.2% get through, nine times as many.

Why do independent checks multiply?

Think of three sieves stacked on top of each other. If each lets one grain in five through, the first passes 20 of 100 grains, the second 4 of those 20, and the third 0.8 of the 4. When checks are independent, the chance of an error getting past all of them is the product of each one's miss rate. That is why a three-check process looks almost watertight on paper: 0.2 cubed is 0.008.

Why is the real leakage higher than 0.8%?

Because people who know others are checking check less carefully. The second checker assumes the first caught the obvious problems, and the third signs off because two colleagues already did. Checks that rely on each other are not independent, and once they are correlated the multiplication rule overstates how much they catch. There is also a common cause: an error that looks like a normal payment, a correct-looking amount to a familiar name, fools all three checkers for the same reason.

What would an operational risk team do about it?

Measure each check on its own, not the chain. Seed known errors into the flow and count what each checker catches; rotate who checks first; give each checker a different thing to look for rather than the same whole payment. The goal is to make the checks genuinely independent, because three checks that behave like one are more dangerous than one check everyone knows is the only one.

Rs 63 crore. The monthly losses double: 1, 2, 4, 8, 16 and 32 crore, and they add to 2 to the power 6, less 1, which is 63. Each month's loss is one more than everything before it combined, so the hole grows as fast as the bets. For a control function, the pattern is the signal: position size growing geometrically with no matching approved limit.

Why does doubling down grow the hole so fast?

A gambler at a roulette table who doubles his bet after every loss plans to recover everything with one win. After six losses in a row he has lost 63 times his first stake and must bet 64 times it to break even, if the table allows it. Doubling means each new bet equals all past losses plus one, so the cumulative loss is always just under the next bet, and a short losing run produces an enormous number. The strategy fails when the losing run is longer than the capital or the limit.

What should a control function see before month six?

Several things, and none needs the trader's honesty. A position growing geometrically, a P&L that is flat or smooth while the gross position explodes, and large trades that are cancelled, amended or booked to unusual accounts are the classic signs of concealed losses. Gross notional limits catch the growth even when net risk looks small. Reconciling traded volumes with confirmations from counterparties catches fictitious offsetting trades. A mandatory two-week leave rule catches positions that need the trader to keep rolling them.

The operational risk lesson is that the fraud is the smaller part of the loss. A Rs 1 crore trading loss, reported on day one, is a normal cost of business; the controls failed on the other Rs 62 crore. That is why control reviews measure time to detection, not only whether a loss was eventually found.