Why the Event Unit Matters
Operational loss information often arrives as a collection of accounting entries, invoices, customer payments, and recoveries. These entries are not automatically separate loss events. Several payments may arise from one event, while similar payments occurring at different times may have unrelated causes. The event unit determines what counts as one frequency observation and which amounts belong together as one severity observation.
A model boundary is the documented rule set that determines which events and amounts are represented. It identifies, for example, the covered risk types and entities, the observation period, the event-date convention, and whether the modeled amount is gross of recoveries or net of them. Without a stable boundary, apparent changes in frequency or severity may reflect inconsistent recording rather than a change in risk.
From Occurrence to Event-Level Record
A practical event-level record separates the event from its financial components. It should contain enough information to apply the event-unit and boundary rules consistently: a unique event identifier, a concise cause and description, the covered entity or business area, the event date under the chosen convention, the amounts and currencies, and any linked recoveries. The individual entries remain traceable to the event, but they do not each become frequency observations merely because they have separate invoice or ledger identifiers.
The event date is the date assigned to the event for classification and reporting. It need not be the date on which an expense is paid, discovered, or entered in the accounts. A sudden event may have a clear occurrence date. A continuing process failure, repeated fraud, or gradual system issue may require a stated convention, such as using the first occurrence, the date the cause was identified, or another consistently applied date. There is no universally appropriate convention for every operational-loss purpose; the choice must fit the model boundary and be applied consistently.
A useful way to make the mapping explicit is to define the record in stages. First identify the occurrence or linked occurrences. Next apply the event-unit rule. Then assign the event date. Finally determine which financial amounts are in scope and how recoveries are shown. This ordering avoids deciding that two entries are separate events merely because they have different dates or payment references.
Describe what happened and distinguish the event from its control failure, consequences, and accounting entries.
Decide whether related occurrences form one event or several, using stated criteria such as a common initiating cause, continuity, and the relevant organizational scope.
Apply the selected date convention, even if discovery, payment, or accounting dates differ.
Include qualifying losses, keep excluded amounts out, and record recoveries according to the defined gross or net basis.
Check that the event count, component amounts, date, and recovery treatment agree with the source records and the chosen rules.
Aggregation and Recovery Treatment
Suppose event \(j\) has \(m_j\) qualifying loss components, with amounts \(x_{j1},\ldots,x_{jm_j}\). If the model uses gross loss, the event severity is the sum of those qualifying components. If eligible recoveries are recorded separately, net loss can be calculated by subtracting the recovery total from gross loss. This calculation is appropriate only when the components and recoveries are defined consistently and assigned to the same event.
Here, \(R_j\) is the recovery amount assigned to event \(j\). The equation is an accounting identity for the specified record, not a rule that every analysis must use net loss. A model may use gross loss and preserve recoveries as a separate field, or it may use net loss if that is the explicitly chosen basis. The chosen basis must be used consistently; otherwise the same event can be represented with incomparable severities.
The reason the event unit matters can be seen directly from the sum. If three qualifying payments result from one event, summing the payments gives the event's total qualifying loss. Recording them as three separate events leaves the total dollars unchanged but changes the frequency count and creates three smaller severity observations. Conversely, combining unrelated events changes both the event count and the severity distribution.
Worked Example: Several Payments From One System Failure
Hypothetical scenario. A payment platform fails on March 12. Under the organization's documented event rule, all customer reimbursements and external response costs caused by this single failure are one event. The rule uses the occurrence date as the event date. The model records gross loss and tracks recoveries separately. There is no discounting or currency conversion.
The event produces three qualifying amounts: customer reimbursements of $4,500, external technical support of $3,800, and customer notification costs of $6,200. A vendor later reimburses $2,000 of the technical support cost.
Method. Apply the common-cause event rule, sum the three qualifying gross components, and then record the recovery separately.
Step 1: Event count and date. The three amounts arise from one platform failure, so they form one event, not three. The event date is March 12 under the occurrence-date convention.
Step 2: Gross severity. Add the three underlying amounts:
The gross severity is $14,500.
Step 3: Recovery and net amount. The $2,000 vendor payment is a recovery, not a fourth loss component:
Thus the record has one event, $14,500 gross loss, and a separately identified $2,000 recovery; its net amount is $12,500. The check is \(12{,}500+2{,}000=14{,}500\), which reconciles to the gross total. A common mistake is to count each of the three underlying amounts as a separate event or to add the recovery to gross loss. The event rule prevents the first error, and the loss-versus-recovery distinction prevents the second.
Setting the Model Boundary
An event-unit rule alone does not determine which dollars belong in a severity record. An amount boundary should specify the loss basis and the treatment of direct losses, external expenses, internal costs, opportunity costs, recoveries, and other consequential amounts. For instance, a model may include customer refunds and external legal expenses but exclude internal staff time and estimated lost future revenue. Another analysis may choose a different basis. The essential requirement is that the choices be stated, defensible, and consistently applied.
The boundary should also state the organizational and risk scope. A loss may be in scope only for specified entities, activities, or operational-risk categories. A control weakness with no financial consequence may be important for risk assessment and incident reporting, but it is not automatically a loss event for a financial loss model. Similarly, a near miss does not become a positive-severity observation simply because it could have caused a large loss. It can be recorded separately under the relevant incident or control process.
| Item | Boundary question | Example of a documented choice |
|---|---|---|
| Event scope | Which occurrences qualify as operational loss events? | Include realized financial losses from in-scope operational causes. |
| Event unit | When are related occurrences one event? | Treat impacts from one continuous, common-cause failure as one event. |
| Date | Which date assigns the event to a reporting period? | Use the first occurrence date for a continuous event. |
| Amount basis | Which costs enter event severity? | Include direct customer payments and external response expenses. |
| Recoveries | Are recoveries subtracted or tracked separately? | Model gross loss and retain recoveries as a separate linked amount. |
Worked Example: Choosing One Event Date for a Continuing Incident
Hypothetical scenario. A configuration error causes intermittent service failures at three offices on September 8 and 9. The organization’s documented rule treats impacts from the same continuing configuration error as one event and assigns the first occurrence date. Its model includes external restoration invoices and customer compensation, records gross loss, and excludes internal employee time. There is no discounting or currency conversion.
The invoices are $7,200 for external restoration at the first office, $4,100 for restoration at the second office, and $2,700 for restoration at the third office. Customer compensation totals $5,500. A separate network outage on September 9 has an unrelated cause and produces $3,000 of in-scope loss.
Method. Apply the common-cause rule to the configuration-error impacts, then treat the unrelated outage as a separate event. Use the assigned event dates rather than invoice dates.
Step 1: Group the configuration-error impacts. The three office restoration amounts and customer compensation arise from the same continuing error, so they form one event. Their total is:
The event date is September 8, the first occurrence date. The $19,500 is one severity record, not four frequency observations.
Step 2: Classify the unrelated outage. Its separate cause makes it a second event under the stated rule. Its event date is September 9 and its severity is $3,000.
Step 3: Reconcile the period totals. There are two events, with combined gross loss:
The check is that the event-level amounts sum to $22,500, matching the sum of all listed in-scope amounts. A common mistake is to count the three office invoices and customer compensation as four events, or to combine the unrelated outage merely because it occurred on the same day. The documented cause-based rule yields two events and a total of $22,500.
Worked Example: Applying Inclusion Rules and Separating Recoveries
Hypothetical scenario. A claims-processing error causes one event at a fictional insurer. The model boundary includes direct customer payments and external legal expenses, excludes internal employee time and estimated lost business, and records gross losses with recoveries separately. All amounts are in dollars, with no discounting.
The event generates $18,000 of customer refunds, $4,000 of external legal expenses, $3,000 of internal employee time, and an estimated $9,000 of lost future business. The insurer receives an $8,000 recovery from a service provider.
Method. Apply the inclusion rules before calculating event severity; then identify the recovery without treating it as a loss component.
Step 1: Select in-scope loss components. Customer refunds and external legal expenses qualify. Internal employee time and estimated lost business are excluded under the stated boundary. Therefore:
Step 2: Record the recovery. The $8,000 provider payment is linked to the event and recorded separately. If a net view is required, it is:
The event has $22,000 gross severity and an $8,000 recovery, giving $14,000 net. The reconciliation check is \(14{,}000+8{,}000=22{,}000\). The common mistake is to add every amount mentioned in the scenario to gross severity. Applying the boundary first excludes $3,000 of internal time and $9,000 of estimated lost business; the recovery is then handled separately.
Common Mistakes and Practical Checks
These decisions matter because frequency and severity describe different aspects of the loss experience. Frequency is the number of events under the chosen event-unit rule; severity is the amount assigned to each event. A change in how transactions are grouped can alter both measures even when the underlying dollars do not change.
- Counting payments as events. Separate invoices or customer payments can be components of one event. Apply the event-unit rule before counting frequency observations.
- Using discovery or payment date automatically. These dates may differ from the event date. Apply the stated convention and retain other dates as distinct fields when needed.
- Combining events based only on timing. Two losses on the same day may have unrelated causes. Time proximity alone does not establish a common event.
- Mixing gross and net amounts. State whether severity is gross or net and keep recoveries identifiable. Do not silently subtract some recoveries while leaving others embedded.
- Including every consequential amount. Apply the model boundary to internal costs, opportunity costs, and other indirect amounts rather than assuming they qualify.
- Treating a near miss as realized loss. A potential loss with no qualifying financial consequence is not a positive loss severity under a realized-loss boundary.
A final reconciliation should connect each event-level severity to its included source amounts, and each recovery to the event it offsets. It should also confirm that the number of frequency records equals the number of qualifying event units, not the number of ledger lines. These checks make the data representation faithful to the selected model boundary. They do not, by themselves, determine which statistical distribution should later be fitted.
Check Your Understanding
For each hypothetical situation, apply the stated event and amount rules before calculating the answer.
- A single data-transfer failure causes customer reimbursements of $1,250 and $2,750 and an external response invoice of $4,000. The model treats these as gross loss from one occurrence and records a later $1,500 vendor recovery separately. What are the event count, gross amount, recovery, and net amount? (Answer: 1 event; $8,000 gross; $1,500 recovery; $6,500 net.)
- A continuing fraud campaign begins on December 30 and causes qualifying payments of $6,000 that day and $4,000 on January 2. The event rule treats the campaign as one event and assigns the first occurrence date; the reporting year is the calendar year and the event is assigned wholly to that year. What date, event count, and severity are recorded in the year containing December 30? (Answer: December 30; 1 event; $10,000 severity.)
- A single processing error causes $12,000 of customer payments, $2,000 of external legal expense, and $1,000 of internal staff time. The boundary includes customer payments and external legal expenses, excludes internal staff time, and uses gross loss. What severity is recorded? (Answer: $14,000 gross severity.)
- A shared software defect affects two locations, with qualifying loss amounts of $8,500 and $3,500. The event rule groups impacts from this one defect into one event. A separate $2,000 loss on the same date has an unrelated cause. How many events are recorded, and what are their severities and combined amount? (Answer: 2 events; $12,000 and $2,000 severities; $14,000 combined.)
- One event has included gross losses of $9,000 and $5,000. An eligible recovery of $3,000 is recorded separately. The model requires both the gross event severity and the net amount for reconciliation. What values should be reported? (Answer: $14,000 gross severity; $3,000 recovery; $11,000 net amount, with $11,000 + $3,000 = $14,000.)