Why Collect Operational Risk Event Data?

The design of an operational risk event database will be driven by the purpose of the program. There are several possible purposes for implementing an operational risk event collection program, and most firms have more than one in mind. When designing operational risk event collection policies, procedures, standards, and guidelines, a firm should consider which of the following reasons apply:

• They are collecting data for capital modeling purposes.
• They wish to use events to help identify control weaknesses.
• They wish to kick off risk mitigation activities when events occur.
• They wish to evaluate risk events and outcomes.
• They wish to use events to help them understand their current operational risk exposure and any areas of excessive risk.
• They wish to use event collection as a way to embed the operational risk discipline.

Each purpose will result in different design elements in the program and will impact the policies and procedures that are developed around loss data. An effective loss data, or operational risk event, program will be designed to reflect the specific purposes and culture of the firm. It will also be accompanied by a strong training program to maximize participation.

The audit department should audit the departments of the firm against the operational risk event data policies, procedures, and standards.

It is pragmatic to expect the initial quality of the database to be somewhat disappointing. It takes some time for culture change to take effect and for a significant number of operational risk events to be captured as intended.

Who Should Collect the Operational Risk Event Data?

Who will be responsible for reporting operational risk-related events in the firm? Responsibility must be clear in order to ensure good participation. The operational risk policy might assign responsibility, or it might be outlined in a separate operational risk event policy or procedure document.

The firm might designate a particular representative in each department to ensure that all events are collected for their department. For example, an operational risk coordinator, specialist, or manager for each department might be tasked with ensuring that all events are entered into the operational risk event database. This empowers them to seek out and report events that might otherwise languish unreported. It also ensures that someone owns the data-reporting responsibility.

Some departments will be in a position to identify events that did not occur in their area but that are captured by their controls. For example, the operations or finance departments may catch events during reconciliation activities.

It may be prudent, therefore, to endow these departments with additional responsibilities to inform the operational risk department of likely events that they come across in their day-to-day activities. Finance may also be involved in reconciling operational risk events to the general ledger if that is one of the goals of the loss data capture program in that firm. However, some firms do not attempt to reconcile loss events to the general ledger.

It can be helpful to adopt an “if you see it, you must report it” policy; or perhaps, more practically, an “if you see it, you must ensure that someone reports it” policy. This is reminiscent of the antiterrorism posters in the subways of New York City after 9/11 (as illustrated in Figure 7.2) and may form the basis of a strong marketing campaign to ensure good participation in operational risk event collection.

This helps to ensure that an event does not remain unreported when several people are aware of it but they all believe it is someone else's responsibility to report it.

Reporting of events should not be associated with fault, but rather should be associated with effective operational risk management. An open access database allows all employees at a firm to enter an event. However, if it is not practical to allow everyone to be able to report an event, then there needs to be a policy or procedure that allows for anyone to pass an event to a designated operational risk event reporter.

If there is an open access database approach, then it may be prudent to allow only very minimal data to be entered, with more being gathered by someone who has been trained in loss data collection. This will help to avoid some of the dangers of poor reporting. These dangers are covered later in this chapter.

What Should Be Collected in the Operational Risk Event Data Program?

Any event that meets a firm's definition of operational risk should be captured in the operational risk event data database, subject to any conditions that are outlined in the loss data or operational risk event policy.

There are several useful pieces of information that should (or must, if under Basel II) be captured for each event. First, it is important to assign an event to one, and only one, appropriate risk category. Risk categories are provided by Basel II, and many firms adopt these at the highest level and then customize lower levels to better match their firm's culture and products.

Internal Fraud

Losses due to acts of a type intended to defraud, misappropriate property, or circumvent regulations, the law, or company policy, excluding diversity/discrimination events, which involves at least one internal party.

Internal Fraud captures any event where there has been intentional wrongful behavior by an employee of the firm. In Annex 9 of the Basel II document, this category is further explained at a lower level, Level 2.

At Level 2, Internal Fraud is broken down into two subcategories: Unauthorized Activity, and Theft and Fraud. Basel II provides Level 3 examples to illustrate these subcategories, as shown in Table 7.2.

From these second and third levels, it becomes clear that insider trading and unauthorized trading are captured under this category. It is also clear that unintentional acts are not captured here. In fact, you will see similar activities fall under Execution, Delivery, and Process Management or under Clients, Products, and Business Practices when they are unintentional mistakes.

Capturing operational risk events that have a fraud element is likely to be very sensitive. This category and the External Fraud category often require legal review before being entered into a database. They might also have only minimal information entered in order to ensure confidentiality.

External Fraud

Losses due to acts of a type intended to defraud, misappropriate property, or circumvent the law, by a third party.

External Fraud captures all events where there has been fraud, with no collusion or participation from an internal employee.

At Level 2, External Fraud is broken down into two subcategories: Theft and Fraud and Systems Security. Basel II provides Level 3 examples to illustrate these subcategories, as shown in Table 7.3.

From these second and third levels, we can see that one of the most high-profile operational risks is captured here: cyber security. In 2004, the Basel Committee was unaware just how dangerous cyber-attacks would become for the financial services industry, but they did have the foresight to include it as a Level 3 example in their risk categories. In the past few years, the volume, sophistication, and effectiveness of cyber-attacks have increased dramatically.

As a result, this risk category is currently enjoying intense scrutiny. The proliferation of politically motivated attacks such as events involving WikiLeaks and Anonymous are of high concern. In addition, the threat of ransom attacks by organized criminal groups and the rise of cyber terrorism are significant concerns that are consistently highlighted by governments and regulators.

Traditional external fraud is also captured here, and theft and forgery are examples of criminal events that are captured in operational risk event databases.

Employment Practices and Workplace Safety

Losses arising from acts inconsistent with employment, health, or safety laws or agreements, from payment of personal injury claims, or from diversity/discrimination events.

The Employment Practices and Workplace Safety category captures losses that result from harm suffered by employees, either due to workplace accident or due to mistreatment by the firm.

At Level 2, Employment Practices and Workplace Safety is broken down into three subcategories: Employee Relations, Safe Environment, and Diversity and Discrimination. Basel II provides Level 3 examples to illustrate these subcategories, as shown in Table 7.4.

Events that are captured in this category might be highly sensitive, and some firms have a policy that allows only the human resources department to enter events in this category.

Workers' compensation items are captured in this category, and it can be helpful to set up an automatic link with any workers' compensation database so that such data can be automatically linked or reconciled.

Discriminatory actions are likely to be kept confidential and will often have only minimal information entered for that reason.

There is sometimes confusion regarding termination payments. If someone is compensated beyond the usual termination notice period due to grievances, should such a payment be considered an operational risk event? Different firms treat these sensitive cases differently. Going back to the definition of operational risk, it should certainly be entered if, but only if, there is a loss resulting from failed or inadequate processes, people, systems, or external events. Consistency is key here. Whatever approach a firm decides to adopt, a clear standard needs to be established and consistently applied.

Clients, Products, and Business Practices

Losses arising from an unintentional or negligent failure to meet a professional obligation to specific clients (including fiduciary and suitability requirements), or from the nature or design of a product.

This category has some of the largest events, as large legal losses are often captured here. A class action lawsuit that alleges client misselling will fall into this category, as will any large litigation concerning a badly flawed financial product.

At Level 2 there are many subcategories for Clients, Products, and Business Practices: Suitability, Disclosure, and Fiduciary; Improper Business or Market Practices; Product Flaws; Selection, Sponsorship, and Exposure; and Advisory Activities. Basel II provides Level 3 examples to illustrate these subcategories, as shown in Table 7.5.

You will notice that the Level 3 examples present a disturbing list of the worst things that can go wrong for a financial institution, from model error to money laundering. Criminal activity by the firm may be captured in this category along with regulatory breaches. Regulatory fines and legal penalties often dominate this category. In fact, some are tempted to rename this category “Legal Events.” However, legal events can certainly arise in other categories, as we have just seen in the Employment Practices and Workplace Safety category.

Clients, Products, and Business Practices events often have a serious reputational impact as well as a financial cost. Items in this category are most likely to get negative press coverage, and the legal department is usually (painfully) aware of these events.

It is important to clearly establish and maintain a process for ensuring that events that are being considered by legal are also being captured in the operational risk database. Regulators are now asking for legal reserves to be captured along with realized losses. For this reason, it can be beneficial to have an automated link between any legal database and the operational risk database, to ensure accurate and timely reporting and to reconcile the two sources.

Damage to Physical Assets

Losses arising from loss or damage to physical assets from natural disaster or other events.

Damage to Physical Assets can occur for a variety of reasons. There is only one Level 2 subcategory provided by Basel II—Disasters and Other Events—and little further explanation in Level 3, as seen in Table 7.6.

Most events in this category will be covered, at least in part, by insurance. However, the original loss should still be captured, and regulators allow only a small amount of insurance recovery to be considered. The reason for this is clear: it might take more than a year to receive an insurance recovery, and during that period the firm needs to be able to demonstrate that is has enough capital to cover the loss. We consider insurance further in Chapter 12.

Business Disruption and System Failures

Losses arising from disruption of business or system failures.

There is only one Level 2 subcategory for Business Disruption and System Failures: Systems. Basel II provides Level 3 examples of the systems to be considered, as shown in Table 7.7.

It is often hard to put a value on losses in this category. While the impact of a major network or telecommunications outage can be serious, it is often best measured in lost opportunities rather than in direct losses. An operational risk event database might be designed to capture both the opportunity costs as well as direct costs, but many firms do not take that extra step.

Losses in this category are also often challenging in that they need to be assigned to a particular business line, but the impact may be firm-wide. If that is the case, then an allocation methodology needs to be established, and this is discussed further later in this chapter.

In the past few years, we have seen many wide-scale power outages as a result of extreme weather as well as examples of simple human error and equipment errors.

Extreme weather may well cause damage to physical assets as well as business disruption. For example, in the United States alone, the past 10 years have seen multiple severe weather-related events. Since Hurricane Sandy hit the eastern states in the autumn of 2012, there have been multiple record-setting hurricanes, including Harvey, Irma, and Maria in 2017 and Dorian in 2019. The United States has also experienced catastrophic tornados, devastating winter blizzards, damaging flooding, and widely destructive forest fires.

These patterns of extreme and disruptive weather have been seen across the globe.

The resulting physical damage in all of these events was severe, and there were major disruptions to telecommunications and utilities. It can be seen from this example that one cause can produce multiple operational risk events that sit in different risk categories.

Execution, Delivery, and Process Management

Losses from failed transaction processing or process management, from relations with trade counterparties and vendors.

The majority of operational risk events occur in the Execution, Delivery, and Process Management category. The frequency of events is usually relatively high compared to other categories. However, many of the events may be small, and so the severity might be relatively low compared to other categories.

There are many Level 2 subcategories: Transaction Capture, Execution, and Maintenance; Monitoring and Reporting; Customer Intake and Documentation; Customer/Client Account Management; Trade Counterparties; and Vendors and Suppliers. Basel II provides Level 3 examples, as shown in Table 7.8.

As can be seen, the list of examples is comprehensive. Anything that goes wrong somewhere in the process of executing a trade, onboarding a client, creating regulatory reports, or dealing with third parties will be captured in this category. Many support functions are designed to manage controls to prevent these types of errors, so you may find that your operations, controllers, and technology departments already capture information on events that occur in the category.

Comprehensive

The operational risk event data program must be comprehensive and capture all material activities and exposures from all appropriate subsystems and geographic locations.³

Practically speaking, it can be extremely difficult to ensure that every nook and cranny of the organization is participating effectively in the operational risk event data collection program. As a result, it is important that the operational risk department regularly reviews the business structure of the firm to ensure that new acquisitions, mergers, or business changes are reflected in the coverage of the operational risk data program.

Threshold

The operational risk data program must include all material losses that are above a de minimis gross loss threshold, for example, €20,000.

There should be a threshold over which events must be entered. Setting a threshold will depend on the risk appetite of the firm and any regulatory requirements that it needs to meet. Recent Basel guidance suggests that a threshold of €20,000 would be appropriate, but even Basel II firms have selected different thresholds: from zero to $100,000. In recent years, regulatory pressure has been downward, and most firms are now requiring mandatory reporting of all events over €10,000 or $10,000. However, the most recent guidance suggests that a national regulator might allow larger banks to set a threshold of €100,000 for the purposes of including their losses in the new Standardized Approach capital calculation.⁴

Fintechs do not have a regulatory mandated threshold and so should select one that meets their own risk appetite.

A zero threshold will set a high reporting burden on the firm. Every error that is a result of inadequate or failed processes, people, and systems or from external events will have to be captured. Taken literally, this would mean that a pencil stolen from the supply cabinet would be an event that needs to be entered in the operational risk event database.

In practice, firms that have a zero threshold apply it only to areas of the firm where it is practical to collect that data. For example, if they have a data feed for all trading errors, then it might not be burdensome to capture them all, however small.

Some departments may want to capture all losses, regardless of the threshold. For example, an operations department may want to track every error, or a finance department might want to track every time there is a wire transfer error, whatever the size.

However, there will be other requirements around each event in addition to the amount, and these may be unnecessary details for smaller losses and might be excluded from the reporting requirements. A firm that has a zero threshold for operational risk event reporting is therefore likely to have a higher threshold for full details to be mandatory.

Many firms do indeed have varying reporting thresholds for different departments, but there must also be a minimum corporate threshold, over which an operational risk event must be reported and will be included in the firm's program and in any operational risk capital calculation.

Amount

Each operational risk event data entry must include the loss amount.

This can be the source of some contention and may need intervention from the operational risk department, or a dedicated controller, as there may be some confusion over the exact amount lost. Some firms reconcile their operational risk events to their general ledger; others do not. The actual gross loss amount will often be different from the net loss amount or the loss after all recoveries. Both the gross and net amounts should be captured.

There may be conflicting views as to how much was actually lost. For example, a trade error that results in a loss can give rise to disagreements regarding the time and price at which the resulting loss should be calculated. A hedging error might produce a loss, but it may be unclear exactly what loss was realized.

In addition to ensuring that the correct amount of loss is entered, there are considerations as to which losses should be included in the loss data system. In June 2011, the BCBS issued “Operational Risk—Supervisory Guidelines for the Advanced Measurement Approaches” in which they offered further guidance on how to determine the correct gross amount.

Measures of the gross loss amount

There are different ways to measure the gross loss amount:

1. Mark-to-market: the economic impact of an operational risk loss is usually the same as the accounting impact when an operational risk loss affects assets or accounts treated on a mark-to-market basis. In such cases, the gross loss amount is the loss or adjustment as recognized in the comprehensive statement of income.
2. Replacement cost: the economic impact of an operational risk loss usually differs from the accounting impact when losses affect assets or accounts that are not maintained on a mark-to-market basis such as property, plant, equipment or intangible assets. The gross loss amount is the replacement cost of the item. Replacement cost means the cost to replace an item or to restore it to its pre-loss condition.⁵

The Committee also provided guidance on what should be included in a gross loss amount:

The following specific items should be included in gross loss computation.

1. Direct charges (including impairments) to the statement on comprehensive income and write-downs due to operational risk events.
2. Costs incurred as a consequence of the event that should include external expenses with a direct link to the operational risk event (e.g., legal expenses directly related to the event and fees paid to advisors, attorneys or suppliers) and costs of repair or replacement, to restore the position that was prevailing before the operational risk event.
3. Provisions (“reserves”); the potential operational loss impact is reflected in the comprehensive income statement and should be taken into account in the gross loss amount.
4. Pending losses stem from operational risk events with a definitive financial impact, which are temporarily booked in transitory and/or suspense accounts and are not yet reflected in the statement of comprehensive income. For instance, in some countries, the impact of some events (e.g., legal events, damage to physical assets) may be known and clearly identifiable before these events are recognized through the establishment of a reserve. Moreover, the way this reserve is established (e.g., the date of recognition) can vary across institutions or countries. “Pending losses,” that are recognized to have a relevant impact, should be included in the scope of operational risk loss within a time period commensurate to the size and age of the pending item; this can be done through the recognition of their actual amount in the loss database or pertinent scenario analysis.⁶

Until the publication of these guidelines there was a wide range of practice regarding the definition of “gross” and “net” loss. The Committee went further and provided clarification of what should not be included in the gross amount:

The following specific items should be excluded from the gross loss computation. It should not be considered to be an exhaustive list:

1. Costs of general maintenance contracts on property, plant or equipment;
2. Internal or external expenditures to enhance the business after the operational risk event: upgrades, improvements, risk assessment initiatives and enhancements;
3. Insurance premiums.⁷

National regulators applied their interpretation of this guidance to all of their AMA banks. As has been noted earlier, even financial institutions that were not technically required to adopt AMA practices were generally advised by their regulators that AMA standards were “best practices” and therefore should be adopted anyway.

For the upcoming new Standardized Approach, further guidance has been provided:

Gross loss is a loss before recoveries of any type. Net loss is defined as the loss after taking into account the impact of recoveries. The recovery is an independent occurrence, related to the original loss event, separate in time, in which funds or inflows of economic benefits are received from a third party.

22. Banks must be able to identify the gross loss amounts, non-insurance recoveries, and insurance recoveries for all operational loss events. Banks should use losses net of recoveries (including insurance recoveries) in the loss dataset. However, recoveries can be used to reduce losses only after the bank receives payment …

23. The following items must be included in the gross loss computation of the loss data set:

1. Direct charges, including impairments and settlements, to the bank's P&L accounts and write-downs due to the operational risk event;
2. Costs incurred as a consequence of the event including external expenses with a direct link to the operational risk event (e.g. legal expenses directly related to the event and fees paid to advisors, attorneys or suppliers) and costs of repair or replacement, incurred to restore the position that was prevailing before the operational risk event;
3. Provisions or reserves accounted for in the P&L against the potential operational loss impact;
4. Losses stemming from operational risk events with a definitive financial impact, which are temporarily booked in transitory and/or suspense accounts and are not yet reflected in the P&L (“pending losses”). Material pending losses should be included in the loss data set within a time period commensurate with the size and age of the pending item; and
5. Negative economic impacts booked in a financial accounting period, due to operational risk events impacting the cash flows or financial statements of previous financial accounting periods (timing losses”). Material “timing losses” should be included in the loss data set when they are due to operational risk events that span more than one financial accounting period and give rise to legal risk.

24. The following items should be excluded from the gross loss computation of the loss data set:

1. Costs of general maintenance contracts on property, plant or equipment;
2. Internal or external expenditures to enhance the business after the operational risk losses: upgrades, improvements, risk assessment initiatives and enhancements; and
3. Insurance premiums.⁸

We consider several of these elements later in this chapter.

Date

Each loss data entry must include the date of the event.

Perhaps surprisingly, this can be a difficult piece of data to nail down. For example, if the loss is the result of several consecutive control failings, then is the date of the event the date that the first control failing occurred, or the date that the last control failing occurred? Or is the correct date the date the loss hit the accounts? Or is it the date that it was detected? The date requirements must therefore be clearly defined in the operational risk event data policy or standards.

The recent guidance for the new Standardized Approach provides the following requirements for the collection of date information:

Aside from information on gross loss amounts, the bank must collect information about the reference dates of operational risk events, including

• the date when the event happened or first began (“date of occurrence”), where available;
• the date on which the bank became aware of the event (“date of discovery”); and
• the date (or dates) when a loss event results in a loss, reserve or provision against a loss being recognised in the bank's profit and loss (P&L) accounts (“date of accounting”).¹⁵

So, for the future calculation of operational risk capital, it will be necessary to collect at least the date of occurrence, date of discovery, and date of accounting for each event.

Description and Causes

For effective operational risk management, each operational risk data entry should include descriptive information about the drivers or causes of the loss event.

The most sensitive information about the event will often be in the description of the drivers and causes.

A firm's operational risk data standards may include a list of possible causes to select from—often related to the firm's operational risk definition. For example, the cause might be selected from people, process, systems, or external event. Alternatively, there may be a more sophisticated list of causes to select from that are specific to the firm, or to a department in the firm.

It is always politically challenging to memorialize fault or blame, and so care must be taken in providing clear guidelines on what should (and should not) be included in a description. Good training must be provided on these guidelines. Some firms are concerned enough about this information to engage their legal departments in reviewing and editing the entries where necessary, so as to avoid inadvertently exposing the firm to legal risk through inappropriate wording.

The Operational Riskdata eXchange Association (ORX) is a not-for-profit industry association dedicated to advancing the measurement and management of operational risk in the global financial services industry. The ORX database collects operational risk event data from a consortium of banks, and it is discussed more fully in Chapter 8. For events over $10 million the member banks are required to select a cause for the event. ORX provides a helpful taxonomy of causes as shown in Table 7.9.

As there may well be more than one cause, ORX allows its members to select up to three causes. In the same way, many firms' operational risk event data standards allow for several causes to be selected for a single event. They also provide lower-level descriptions and examples that can be found in their standards document and are easily accessible online.

Criteria for Allocation to Business Line

There must be documented, objective criteria for allocating losses to specified business lines. The purpose for this allocation is twofold. First, if a firm is currently applying the Advanced Measurement Approach (or the future-state Standardized Approach) for capital calculation, then the location of the event may directly impact the capital calculation. Second, it is helpful to be able to demonstrate which business areas are generating operational risk events, so that the firm can understand the relative operational risk profiles of each business area.

Every event needs an owner, or in other words, it must be determined which front office area suffered the loss. This can cause some tension in cases where, for example, the cause of the loss occurs in a department outside the front office, but the impact is placed on the profit-and-loss account of the business area. For this reason, it is helpful to have clear, objective criteria, including a limited list of business areas to select from when identifying where the loss hit the firm's accounts.

The latest Basel guidance describes business line categorization, as shown in Table 7.10.

The organizational structure of a firm might well not fit neatly into this categorization structure, and most firms have developed a mapping behind the scenes. This mapping allows them to collect data in a way that makes sense to their firm, but also allows them to group data appropriately for regulatory reporting as needed.

Criteria for Allocation to Central and Supporting Functions

If an event occurs in a central function and impacts the whole firm or several business lines, such as a network outage, then the operational risk event data policy should clearly outline how any resulting loss is allocated to each business line. Basel II originally outlined this requirement for operational risk event collection as follows:

A bank must develop specific criteria for assigning loss data arising from an event in a centralized function (e.g. an information technology department) or an activity that spans more than one business line, as well as from related events over time.¹⁹

The most recent Bank for International Settlements (BIS) guidance on operational risk capital also provides guidance on how to relate a supporting function to the Basel categories of business lines for the purpose of assigning revenue.

Any banking or non-banking activity which cannot be readily mapped into the business line framework, but which represents an ancillary function to an activity included in the framework, must be allocated to the business line it supports. If more than one business line is supported through the ancillary activity, an objective mapping criteria must be used.²⁰

All Impacted Departments

It is often helpful to specify in the operational risk event data criteria that all departments that are involved in the event must be identified as the event is entered. This helps to ensure good communication around the event. Many events impact several areas, and the operational risk event data system often needs strong workflow components to facilitate entries and discussions by multiple parties.

Boundary Events Identified

Credit risk–related operational risk events and market risk–related operational risk events should be collected and flagged as boundary events. When using operational risk event data as an input into a capital calculation, credit risk boundary events can be excluded from the calculation, but market risk events must be included. An example of a boundary credit risk/operational risk event is where a counterparty fails and the collateral that was supposed to have been collected has failed to be requested, leading to an avoidable financial loss.

An example of a boundary market risk/operational risk event is where a trade error occurs and the market moves dramatically in a direction that increases the loss.

It is generally accepted that credit risk/operational risk boundary events are captured in credit risk capital calculations, and so can be excluded from any operational risk capital calculations. In contrast, market risk/operational risk boundary events are not captured in market risk capital calculations, and so should be included in operational risk capital calculations.

If an operational risk event database is being used to calculate operational risk capital, then these boundary events need to be carefully tagged to ensure that they are appropriately included or excluded from the operational risk calculation.

Action Items

As losses are gathered, there should also be identified mitigating actions, either to ensure the recovery of the funds or to support the prevention of future similar events. Actions should include an owner and due date for each task, and should be tracked to completion. From a practical point of view, having good action-tracking processes in place is necessary to ensure that actions do not sit ignored in the event database, but are being actively pursued in order to mitigate the operational risk that has been identified by the event.

Nonfinancial Impacts

In addition to the financial impact of the event, there may be other impacts that can be gathered as part of the operational risk event data collection program. While it may be difficult to put a value on impacts such as reputational damage, a firm's event data standards might include a field for a qualitative or free prose assessment of any reputational impact.

1. Which of the following are Basel II Level 1 operational risk categories?
   1. Clients, Products, and Business Practices
   2. Employment Practice and Workplace Safety
   3. Internal Fraud
   4. Damage to Systems
   5. Unauthorized Trading
   1. I only
   2. I and II only
   3. I, II, and III only
   4. I, II, III, and IV only
   5. All of the above

1. The event should be mapped to which of the following Level 1 Basel II categories?
   1. Trading Error
   2. Execution, Delivery, and Process Management
   3. Business Disruption and System Failure
   4. Transaction Capture, Execution, and Maintenance
   5. Data Entry, Maintenance, or Loading Error
2. Why should the trade support employee enter the event into the database? Select the best answer.
   1. Because the trader should be free to focus on making a profit for the firm
   2. Because it might not have been the trader's fault
   3. Because the trade support employee is in the back office
   4. Because $150,000 is over the threshold
   5. Because every employee is responsible for reporting operational risk events
3. The trade support employee decides not to enter the data into the event database and does not inform anyone of the error. What is the most serious consequence of this action? Select the best answer.
   1. He is risking being fired for breaching company policy.
   2. The trader cannot learn from his mistake.
   3. Audit will issue an audit point if the omission is discovered.
   4. Effective operational risk management in the firm is undermined.
   5. The firm might fail its Basel II examination.