The Risk Event: What Counts, and When It Is Recorded

A risk event is something that has actually happened. A risk is something that might. An event counts whether or not it cost money: a failure caught before it caused a loss carries the same information as one that was not. And every event has two dates, the date it occurred and the date it was recorded. The two dates are frequently different and never interchangeable.

Everything else in this part of the subject deals in things that might happen. Sizes are estimated, chances are argued over, and a careful reader learns to hold every number loosely. A record of events deals in things that did happen, and the discipline is completely different. An event record estimates nothing and defines everything. Three choices define it: what counts, when it is written down, and what is left out on purpose. Each choice quietly decides what the institution will later be able to learn from its own history.

The worked case throughout is Vindhya Commercial Bank Limited, an invented mid-sized Indian commercial bank with a balance sheet of Rs 96,000 crore. Over twelve numbered months it collected eighteen events: thirteen incidents numbered I1 to I13 with a loss attached, and five near misses numbered N1 to N5 with none. Every figure below is that invented bank's own. Eighteen rows in one file carry the whole argument, and what any single row is for is worth settling.

What is a risk event, and what makes something one?

The smallest possible distinction comes first. Nothing else in the subject is this simple. A risk eventSomething that has actually happened, as against a risk, which is something that might. is a risk in the past tense. The tense is the whole of it. A risk is something that might happen and therefore carries an estimate: an estimate of how big it would be and an estimate of how likely it is. An event is something that did happen and therefore carries no estimate at all. An event carries a date, an owner, an amount and a consequence. The line between a risk and an event is about tense and nothing else, and it is the only distinction in this part of the subject that is.

Here is the everyday version. A person who cycles to work every day has a risk: they might come off the bicycle. The risk has a size, roughly, and a chance, roughly, and reasonable people can disagree about both. On a wet Tuesday in June they come off the bicycle and break a wrist. The broken wrist is an event. There is nothing left to estimate. There is a date, a cost, a cause and a consequence, and no amount of arguing about how likely it was changes any of them. The risk and the event are the same subject, and they live in two different records because two different questions are being asked of them.

The same is true at Rs 96,000 crore. Inside this bank the collateral valuation control appears in two places at once. On the risk register it is a red entry: a control that might fail, sized and rated by people who are guessing. In the loss record it is incident I10, month 10, a valuation feed that was stale for 11 working days, 340 loans wrongly marked, and a net loss of Rs 1.4 crore. Same subject, same institution, same week. One row is a forecast about the future and the other is a report about the past, and a reader who does not know which one they are holding will misread both.

Why labour a distinction this small? Because institutions get it wrong in one specific direction, and the wrongness is expensive. Institutions treat the event record as a scorecard for the register. Somebody notices that a risk rated as unlikely has now happened twice, and concludes that the rating was bad. Sometimes it was. But an unlikely thing happening is exactly what unlikely means, and a register that never rates anything unlikely is not a better register, it is a more frightened one. The event record is not a mark scheme for the register. The record is a separate body of evidence the register may draw on, and the drawing takes judgement.

Does an event have to cost money to count?

No, and this is where most event records go wrong before they have collected anything. Cost is the field that is easiest to fill in and the only field anybody asks about at the year end, so the instinct is to define an event by its cost. Follow that instinct and the record becomes a list of the failures that happened to be expensive. A list of expensive failures is a different and much less useful object.

Four different kinds of thing belong in the file, and only one of them is defined by money. First, a failure that cost money, the thing everybody already means by a loss eventA risk event that cost the institution money, gross before recoveries and net after them.. Second, a failure that cost nothing because something caught it in time. Third, a failure that cost money without any customer being worse off. The harmlessness is itself the signal: a control failed in a way nobody outside was positioned to complain about, and that is often the clearest signal of all. Fourth, a failure that cost very little and broke a promise the institution had made, where the money is trivial and the promise is not. Four kinds of thing count as an event and only one of them is a loss, so an institution that collects losses is collecting a quarter of the record.

Notice what tile three does to the instinct. Incident I10 wrongly marked 340 loans and no customer lost a rupee, so there was nobody outside the institution with a reason to complain. On a record built around customer harm it would barely register. Incident I10 is in fact the failure sitting behind this bank's single most serious control finding of the year, and the reason is not the Rs 1.4 crore. The reason is that the same feed sets the value of collateral across a secured book, and a control that can be wrong for 11 working days without anybody noticing is a control that can be wrong for longer.

What is a near miss, and why is it worth collecting?

A near missA failure that occurred and did not produce a loss, usually because something caught it. is the same failure with a different ending. Not a smaller failure, not a lucky escape, not a hypothetical. The control broke in exactly the way it would have broken on the expensive day, and then something downstream caught it. Everything the expensive version could have taught is available in the cheap version, and the cheap version costs nothing to collect because somebody has already done the work of noticing.

Take the household version first. A person leaves the gas ring on and walks out of the kitchen. On Monday they come back in two minutes and turn it off. On Friday they come back in forty minutes and there is a fire. Monday and Friday are the same failure. Monday is free. Any household that treats Monday as nothing has decided to buy its information on Fridays.

Vindhya Commercial Bank ran exactly that pair on its collateral valuation feed. Near miss N3 is month 6: the feed was stale for 2 working days and a data quality check caught it. Nobody raised it as an issue. In month 10 the same feed was stale for 11 working days, 5.5 times as long, 340 loans were wrongly marked and it cost Rs 1.4 crore net. N3 and I10 are one control failure with two endings, and the institution had the whole of the second one in its hands four months early, at no cost, and did nothing with it.

There is a second reason a near miss earns its row, and it is subtler. The near miss is the only place where a control that worked is recorded at all. Every other row in the file is a control that did not work. If only the failures are ever written down, no evidence ever accumulates about which checks are actually catching things, and decisions about which controls to keep get made with no data on any of them. Near miss N1 records that the four eyes check on settlement instructions stopped a Rs 68 crore duplicate. Nothing else in this bank's file records that.

Why is a near miss worthless unless it is linked?

Now the uncomfortable part, and it is the part that separates institutions that collect near misses from institutions that use them. Vindhya Commercial Bank collected all five. Two of the five, being 40.0 per cent, were the same failure as an incident that followed, and neither was connected to anything.

LinkingConnecting an event to an earlier one with the same cause, which is the only thing that makes a near miss record valuable. means going back through the record already held and asking whether this failure has a relative. Linking is not a field on a form. Somebody has to perform the act, on a schedule, over a window of time that somebody has to choose. N3 sat in month 6 and its incident arrived in month 10, a gap of four months. Near miss N4 sat in month 7, a trade finance document set carrying a particular forgery pattern that a checker refused and recorded as a routine refusal, and one month later that same pattern surfaced as incident I13, the largest net loss of the year at Rs 15.4 crore. A lookback of a single month would have reached the second link and a lookback of four months would have reached both, and this bank ran neither.

The third line on that timeline points the other way, and it is worth a sentence of its own. Near miss N1 in month 2 was a second duplicate settlement instruction, this one for Rs 68 crore, stopped by the four eyes check before release. Its relative, incident I2, had already gone out ten days earlier and was not stopped. So the pair exists, but the free version came second. The direction matters for how the count is made: counting only near misses that predict, this bank has two. Counting events that share a cause with another event, it has three. How many links a record contains depends on which direction the search is willing to run in, and most institutions only look one way.

There is one thing the linking does not buy, and the discipline of not claiming it matters. Linking N4 to I13 would not have stopped I13. The forgery had been running for fourteen months by month 7 and the loss was already largely incurred. The Rs 16.8 crore of net loss carried by I10 and I13 together, being 38.4 per cent of the year's Rs 43.8 crore, is loss the learning would have been looking at. The Rs 16.8 crore is not loss avoided, and anybody who presents it as loss avoided is selling something.

When is an event recorded: when it happened, or when it was found?

One question separates a tidy event record from a usable one, and almost nobody asks it until a number comes out wrong. Every row carries a date of occurrenceWhen the thing actually happened, which for a long running failure is a period rather than a day. and a date of recordingWhen the institution wrote it down, which is usually when it was discovered., and they are different dates answering different questions. The first says when the institution was harmed. The second says when the institution found out. The gap between the two dates measures how good the detection is. Neither date alone gives that.

For a short failure the gap is small and the question feels academic. Incident I3, the core banking system unavailable for 4 hours and 20 minutes, happened and was known about within the same afternoon. Incident I6, a rate applied 25 basis points above the approved card on 6,200 term deposits for eleven days, occurred over eleven days and was found shortly after. Neither of those puts pressure on the definition. Two events in this record do, and they do it hard.

How does one event become one row when it ran for months?

Two of the thirteen incidents did not happen on a day. Incident I13, the letters of credit, ran for fourteen months ending in month 8, so it began in month minus 5. Only eight of its fourteen months fall inside the twelve month window this record covers, and six of them, being 42.9 per cent of its run, are before the window opens. Incident I5, a branch officer who created 14 fictitious accounts and moved Rs 3.6 crore through them, ran for twenty two months ending in month 5, so it began in month minus 16. Five of its twenty two months fall inside and seventeen, being 77.3 per cent, fall before.

Both long running rows still get one date of recording each, and they sit in this year's file at their full net loss. The recorded loss yearThe set of events attributed to a period, which depends entirely on which of the two dates the attribution uses. is Rs 43.8 crore, and that is this bank's own figure and stays its own figure. Now build the year the other way, on the date each loss occurred, spreading each long running loss evenly across its run. The even spread is an assumption and not the bank's figure: the case says nothing about when within its run either loss actually accrued, and a fraud that accelerates in its final months would move the answer again.

On that assumption I13 puts 15.4 times 6 over 14, being Rs 6.6 crore, outside the window, and I5 puts 2.7 times 17 over 22, being Rs 2.09 crore, outside. Together that is Rs 8.69 crore. The event-dated year is 43.8 less 8.69, being Rs 35.11 crore, or 80.2 per cent of the recorded one. Against this bank's own internal cap on rolling twelve month net operational loss of Rs 60.0 crore, the recorded year runs at 73.0 per cent of the cap and the event-dated year runs at 58.5 per cent. The gap is 14.5 percentage points on one year, produced entirely by which date somebody chose in a template.

Neither number is wrong. Dating by discovery gives what the institution had to deal with this year. A treasurer or an auditor usually wants exactly that. Dating by occurrence gives what the institution's controls actually let through this year. Somebody studying the controls wants that instead. The error is never picking one; the error is picking one silently and then presenting the answer as a fact about the year. Rs 43.8 crore is a figure, and a figure is not a fact about twelve months.

What does a recording cut-off drop, and is the record still complete?

Most institutions do not record everything. A recording cut-offThe size below which an institution does not record an event at all. is the size below which an event never enters the file, and it exists for an entirely reasonable reason: somebody has to write the row, somebody has to review it, and there is no point spending an hour of two people's time on a failure that cost a few thousand rupees. Vindhya Commercial Bank recorded all thirteen and states no cut-off, so the cut-off below is a dial the reader turns rather than a policy the bank has.

Turn the dial and two things move at once, and they move at completely different speeds. Suppose the cut-off is Rs 2.0 crore of net loss. Seven of the thirteen incidents survive and six drop out, so 46.2 per cent of the record has gone. The value that goes with them is Rs 6.9 crore of Rs 43.8 crore, being 15.8 per cent of the money, so the file still holds 84.2 per cent of what the year cost. A cut-off drops events far faster than it drops money, so a record can be nearly complete in rupees and badly incomplete as a record, and those are different claims about the same file.

The reason the two lines separate is arithmetic rather than accident, and it is worth seeing directly. Value concentrates and counts do not. Sort the thirteen net losses and the median is Rs 2.4 crore while the mean is Rs 3.37 crore, so the mean is 1.40 times the median. The largest single net loss, incident I13 at Rs 15.4 crore, is 4.57 times the mean and 6.42 times the median. Take I13 out and the mean of the remaining twelve is Rs 2.37 crore, almost exactly the median of the whole set. One event is doing all the work in the average, and that is what people mean when they say a loss record has a tail.

The table below is the one to put in front of anybody proposing a cut-off. The same arithmetic runs at seven settings, and the two right hand columns are the argument.

Read the bottom row slowly. At a cut-off of Rs 6.0 crore this bank's entire operational event record for the year is one row, and that one row still carries 35.2 per cent of the money. Anybody defending the cut-off on value has a true statement available at every setting on that table. The record is a wreck at most of them.

Why is a cut-off on the net figure not a cut-off on the gross?

The gross and net question arrives again here, and this time it does something worse than confuse a ranking. Gross loss is what left the institution. Net loss is what stayed gone after recoveries. For most rows the two are close, so the distinction feels like bookkeeping. For one row in this record they are not close at all, and that row is the one everything turns on.

The ranking makes the point without any cut-off at all. Rank the thirteen on gross loss and rank them again on net loss, and the two lists disagree at the top. I2 is first on gross and joint twelfth of thirteen on net, tied with I8 at Rs 0.6 crore, a move of eleven places on a list of thirteen. I13's recovery rate was 31.25 per cent against I2's 98.6, so I13 is second on gross and first on net. Across the year the bank recovered Rs 53.9 crore of Rs 97.7 crore gross, being 55.2 per cent. The top two on gross are 65.9 per cent of the gross and the top two on net are 47.0 per cent of the net, and they are not the same two incidents.

What is an event record actually for?

Everything above has been about what goes into the record. Whether any of the definitional work was worth doing depends on what comes out. The honest answer is that the record is not primarily for adding up. An event record exists to make the same failure findable twice, so the cause field, the two dates and the link to any earlier event with the same cause matter more than the amount column ever will.

A total answers exactly one question: what did the year cost. The cost of the year is a real question and somebody has to answer it. But a total cannot answer much beyond it. A total cannot show that a valuation feed failed in month 6 and again in month 10. A total cannot show that a forgery pattern was refused by a checker in month 7 and surfaced as the largest loss of the year in month 8. Three incidents in the year were process failures in execution and delivery, carrying 23.1 per cent of the count and 10.0 per cent of the value. Two were internal fraud, carrying 15.4 per cent of the count and 41.3 per cent of the value. A total shows neither split. Every one of those statements needs a record with rows in it, and none of them survives being summed.

Which is why the definitional choices made earlier are not pedantry. If the four kinds collapse to one, the near misses never enter and the two links can never be found. If the cut-off sits at Rs 2.0 crore on net, incident I2 is not in the file, so nobody can ever notice that near miss N1 in month 2 was its relative. If the template carries one date column, the year is dated by discovery and nobody knows that Rs 8.69 crore of it belongs to months before the record opens. Each of the three choices removes not a number but a question that can no longer be asked.

Who actually picks up an event record, and what do they do with it?

Four different readers open this file for four different reasons, and watching them read it is the fastest way to see which fields carry weight.

The head of operational risk, Purnima Ganeshan in this invented bank, reads it for repetition. She is not looking at the total at all. A cause that recurs is a control that is still broken, and a cause that appears once may be nothing, so she is looking for two rows with the same cause and asking how long the gap was. On this file she would find three pairs, and the gaps are four months, one month and ten days.

The internal auditor reads it for the fields that are empty. A row with a cause of "human error" and no link is a row somebody closed rather than investigated, and in a file of thirteen incidents an auditor can read every cause field in twenty minutes. Reading every cause field is the cheapest test of an event record there is, and it needs no arithmetic at all.

A credit analyst at another institution, looking at Vindhya Commercial Bank Limited as a counterparty rather than as an employer, reads the disclosed operational loss figure and asks one question before anything else: which date is it on. A bank that dates by discovery and has just found a fourteen month fraud reports a bad year that was partly somebody else's. A bank that dates by occurrence reports a smoother series that hides how late its detection is. Comparing a discovery-dated year to an occurrence-dated year across two institutions is comparing nothing to nothing. Neither series is misleading, and the analyst has to know which one is in front of them.

The mechanism is the same at every scale, so a household reader opens the same kind of file. A person who keeps every repair bill for a scooter has a total. A person who writes one line beside each bill saying what actually broke has a record, and after three years the second person knows the chain keeps going and the first person only knows that scooters are expensive. The line beside the bill is the cause field, and it is the only part of either file that ever changes a decision.