|
Incident Data Collection
137
and the value of the information collected. At the very least, firms should limit the
reclassification of events, and the investigation of causes, to major events (according
to their respective definitions of “major”).
R E V I E W A N D V A L I D A T I O N
D a t a Q u a l i t y R e v i e w s
Data quality is naturally of prime importance and risk data are no exception. Regulators
pay attention to the completeness and accuracy of key fields such as dates, classification
of losses, consolidation of group losses and the amounts of expected losses versus
settled losses. Comprehensiveness of data collection is, arguably, the main point of
quality assessment by the regulator. How comprehensive is the loss collection exercise
and how many incidents have not been reported and with what impact? These questions
are almost impossible to answer, but some regulators will ask them nonetheless. More
reasonably, they will check whether the data collection process has been reviewed and
validated by reconciling it with the general ledger, internal audit or a third party.
F e e d i n g f r o m E x i s t i n g S o u r c e s : A C a s e A g a i n s t
S t a n d a l o n e D a t a b a s e s
Most organizations possess – sometimes without realizing it – several databases that
can directly feed the operational incident data collection process and improve data
quality, comprehensiveness and reconciliation, as well as simplify the overall exercise.
Figure 13.2 presents an example of such databases.
The general ledger (GL) is the first information source that comes to mind as a
loss data feed; every amount lost by a firm should be entered in the GL. In a perfect
world, all direct operational losses would be identified directly and fully in accounting.
Regrettably, in practice, the usability of the GL for operational risk strongly depends on
whether the ledger rubric allows you to identify operational risk events. I was fortunate
to start my career in operational risk in a group where the GL had a rubric labeled
“miscellaneous inflows and outflows.” It comprised all the money flows in and out
of the bank that were not justified by an accounting document, from cash imbalances
in retail banking to goodwill gestures in private banking. This acted as a wonderful
proxy for operational incidents. After spending three days with the accounting team,
I had sufficient records to make my case to the risk committee and, as the new head of
operational risk for the region, I received the green light to recruit my first collaborator
for the ORM team, much to the amazement of several of my older colleagues. However,
some GLs are not as easy to exploit and this strategy does not always work. Some tier 1
banks have profoundly reorganized their GL so they can isolate operational risk losses
and reconcile them with the operational incident database. GL data can provide direct,
138
RISK MONITORING
BO issue logs
General
ledger
Legal
provisions
OpRisk
incidents
Customer
complaints &
compensations
Press and
media review
IT logs (P1,
P2)
F I G U R E 1 3 . 2
Data-feeding sources in an operational incident database
settled, financial losses from incidents and will often need to be complemented by
other management information about indirect losses and other so-called non-financial
impacts.
IT logs are probably the most common form of incident collection used in recent
years to feed operational risk incident databases, either automatically or by manual
transfer. IT issues rated Priority 1 (P1) and Priority 2 (P2) are generally considered as
operational risk incidents. Other types of data, such as the list of provisions made for
pending lawsuits, are excellent sources of information about large past incidents that
are yet to be settled. Customer complaints and customer compensations are obvious
data sources for operational events. Many firms use them and those that don’t, should.
Many firms also use information feeds from the marketing and media department,
which provide alerts about bad press and other types of reputational risk incidents.
Sometimes, back offices and other departments maintain their own log of issues and
incidents. Using these logs to build operational incident data is efficient and much more
acceptable to the business than asking it to log the same type of information again on
a different system.
Good practice does not include standalone incident databases in operational risk:
incidents emerge from all parts of the organization and in many forms; they are present
in operations, processes and communications, and are captured by various systems in
different logs and departments. Most of the information needed by the ORM team
already exists in the organization, so it is a question of capturing it in the most
efficient way and then filtering into the ORM database whatever is needed for the
Do'stlaringiz bilan baham: |
