How to Build an Operational Loss Database for Financial Firms Inexpensively
An internal operational loss database is a key resource for organizations that actively manage operational risk. While all forms of risk management consider empirical data, tracking information on realized events of loss can be especially critical to operational risk assessment. Tracking realized events permits the risk manager to back-test assumptions about where operational risk lies within an organization.
The challenge in building an internal operational loss database is in obtaining the data. Two factors work against data availability: 1) obfuscation, meaning that loss events are not always neatly identified in a financial ledger, and 2) disincentive to report loss events, meaning those who are aware of an operational loss are often those responsible and are not incentivized to report a perceived failure.
To overcome these obstacles large, well-funded organizations have created Operational Risk departments, often staffed with analysts who are embedded in major business lines or operating units. These analysts create relationships with key staff, attend management meetings, and receive regular reporting so they develop a good sense of what is happening and can pick up on system, process, or people failures. But what do you do if you cannot afford a staff of operational risk analysts to collect your loss event information? You can glean loss event data centrally from a multitude of normal business information sources, and make inferences from that data.
Sources of Data
Since many organizations do not explicitly record loss event data, the risk analyst must locate records that contain inferences of events. The following sources might be useful:
i. Support Logs – Incident logs can be excellent sources of information for system outages and software release issues.
ii. Financial Records – Write-offs and unusual expense items can sometimes be indicative of an unexpected loss event. To pick up on these, review journal entries and general ledger line items.
iii. P&L Adjustments – Financial organizations often produce profit and loss reports for management on a daily basis. Look for special loss items or adjustments to P&L not related to the organizations normal sources of revenue. Errors in trade processing, for example, may reveal themselves this way.
iv. Trade error logs – Trade error logs are also maintained by financial institutions and are direct records of errors. Missed trades, late trades, and incorrect tickers are common sources of operational loss.
v. Departmental business plans (major initiatives) – Major initiatives or special projects frequently carry significant budgets and risk of failure. By understanding departmental business plans, an operational risk analyst can follow-up on major initiative implementation results. Because major initiatives are new and risky, these efforts often result in unintended outcomes, which can be added to the operational loss database.
vi. Project status updates – Project status reports may point to projects going off course or even failing, creating operational loss events.
vii. Governance committees meeting minutes – Committees that perform a governance role, such as supervisory, audit, IT governance, and information security committees, maintain meeting minutes that can be mined for useful information about process failure.
viii. Audits – While audits usually focus on risk assessment and internal controls, the process of conducting an audit often reveals realized losses that come up in discussion with the auditee. Because audits are focused and detail oriented, they can be great sources of loss event data.
ix. Data analytics – Just as in Audit work, data analytics can be a useful tool for uncovering operational losses. Analytics can be created to look at process abnormalities or check for boundary conditions. For example, an analytical dashboard that highlights trending account reconciliation differences can graphically display statistically significant deviations, allowing the analysts to make further inquiries.
x. Inquiry with Legal and Senior management – This type of learning is similar to the work performed by the embedded operational risk analysts we discussed earlier, except we are going directly to the top of the organization for information rather than up through the business units. This is, of course, more efficient in that the analyst can become aware of loss events that reached the ears of management. Undoubtedly, however, smaller events would not be known to senior managers.
xi. Word-of mouth – Sometimes colleagues speak informally with one another about unusual events, some of which can be realized operational loss events. Often the disadvantaged party, such as the recipient of a botched software release, for example, may be more motivated to openly discuss such events than the party responsible for the error, so this form of learning for the risk analyst is through listening to the complaints of co-workers in an informal setting.
Recording Events in the Loss Database
Operational loss events should be logged in a structured uniform format in a “Loss Database”. Ideally, logging these events should be automated through various feeder systems. However, many of these events do not exist in a system and these events should be meticulously logged manually. The database should capture enough information to look for event patterns and make meaningful inferences about the organization’s risk profile.
Some attributes one might consider maintaining include event date, type (such as Basel II category), loss amount, internal risk type, root cause, impacted departments, and related systems.
Calculating the realized loss is, of course, key for the loss log and can also present some challenges. For example, some firms may consider only external costs, “money out the door”, and not the internal cost of dealing with the issue. Similarly, an organization might also look at opportunity cost related to events, or consider that too indirect for management decision-making purposes. Operational risk analysts should use an event costing methodology that is meaningful for the organization and is likely to facilitate the risk management decision-making process.
Looking for Themes / Making Inferences
Making inferences from the data one collects is the next step after amassing enough data. Sometimes an event may be significant enough by itself to warrant action, such as the discovery of a large fraud. Often times, however, insights are more subtle. A risk group may conclude, for example, that a firm has consistent problems with software releases even though the data points to many unrelated systems. Or, there could be a systematic problem with project management even though project failures are seemingly unrelated involving different people and products. This is the reason why root cause is a valuable piece of data to collect when an event is first recorded.
The ultimate payoff from this analysis is being able to alter the risk profile of the organization for the better. After making meaningful inferences from the data, management can then mitigate the risk through process improvement, adoption of controls, or training, share the risk, avoid the risk, or choose to live with these loss events. No matter what path is chosen the organization will be better managed, and ultimately, more profitable.
About the Author
Ethan Quinn is a Senior Audit Executive at a Large Hedge Fund and a long time Risk Advisors Inc. client. Ethan is an industry thought leader and regularly shares his views in industry publications and at conferences.