Identifying risks · RiskAtoms Academy

By the end you will be able to

1Use workshops, process maps and loss data to find a firm's risks.
2Write a risk as cause, event and consequence.
3Mark where a process can fail, and name the cause: people, processes, systems or external events.
4Read loss data by how often and how much, and say what it cannot show.

Why it matters

Larkfield Bank's loss log has never recorded a cyber attack. That does not make it safe from one. The risks that hurt most are often the ones nobody wrote down, so finding them is the step everything else depends on.

Core explanation

Looking for trouble, on purpose

Identifying risks means finding them and describing them clearly, before anyone scores them. It works from two directions. Top down, the board and executives ask what could stop the firm meeting its goals. Bottom up, the teams that run each process ask what could go wrong in their own work. The map of risk types from L2.2.01: A map of risk types is the checklist that makes sure no whole category is forgotten.

Write it as a sentence. “Cyber” or “IT” is a topic, not a risk. A useful risk statement names three things:

Cause, event, consequence

Because of [cause], [event] may happen, leading to [consequence].

“Because Larkfield runs all its payments through one software platform, a failed change could stop card and app payments for a day, leading to customer compensation, complaints and supervisory attention.”

The cause tells you where to put a control. The event is what you watch for. The consequence tells you how big it could be. Mixing them up is the most common mistake in a risk register.

Sort itCause, event or consequence?

Each phrase comes from one of Larkfield's risk statements.

Staff in payments operations are new and not yet fully trained
A high-value payment is sent to the wrong account
A €1.2m loss and a complaint to the ombudsman
The core banking system is hosted by a single cloud provider in one region
Customer data is stolen in a cyber attack

Three main tools

1. Workshops and interviews. A risk workshop brings together the people who run an activity, someone from the risk function to lead it, and ideally one outsider who will ask naive questions. Good prompts are “What keeps you awake at night?”, “What nearly went wrong last year?” and the pre-mortem: “It is a year from now and this has failed. Why?” Watch for the usual traps: the most senior voice wins, the group copies last year's list, and nobody mentions a risk that would embarrass their own team.

2. Process maps. A process map draws the work step by step. At each step ask the four questions from the Basel definition of operational risk (L2.2.05: Operational risk): what if a person makes a mistake or cheats, a process has a gap, a system fails, or something outside the firm happens? Look hardest at handoffs, where work passes between teams or systems.

3. Loss data. Loss data records what has already gone wrong. Internal data is the firm's own losses, plus near misses. External loss data adds what has happened to others. Banks sort losses into seven Basel event types, so that firms can compare. Read the data two ways: by frequency and by severity.

ExploreLarkfield's loss log, last three years (illustrative)

16 losses of €20,000 or more, €9,385k in all. Switch the measure, then click a bar to see its events.

External fraud happens most often. Click a bar to see the events behind it.

Of Larkfield's 16 logged losses, external fraud is the most frequent (6 events), but execution and process errors cost the most: 46.9% of the total, mostly from one event (“savings interest miscalculated for two years, refunded”, €2,900k). And the log has a blind spot: it only shows what has already happened to Larkfield. That is why firms add external data and scenarios.

Other sources. None of the three is enough alone, so firms use several:

Source	Good at finding
Scenario analysis	Rare, severe events with no history: 'what if our cloud provider is down for a week?'
New product approval	Risks in something the firm has never done before
Audit and supervisory findings	Control gaps others have already spotted
Complaints and incidents	Problems customers see before managers do
Horizon scanning	Emerging risks: new technology, new rules, climate change
Indicators (L2.4.06: Key risk indicators)	Risks that are growing before they cause a loss

Try it

Here is Larkfield's instant app payment as a process map, with seven things that could go wrong. Place each one on the step where it happens. Then read the cause behind each.

Try itWhere does it break?

Pick a failure below, then click the step of the payment where it happens. On a computer you can also drag it.

Worked example

A workshop on moving to the cloud

Larkfield plans to move its core banking system, which holds every account, to a cloud provider. The chief operating officer asks the risk team to run an identification workshop. Try to guess each output before you open it.

Running the workshop

Step 1 of 6

1
Prepare
Scope: the migration and the first year after it. Invite the people who will run it: IT architects, payments operations, the supplier manager, compliance, and a risk facilitator. Send the plan and the risk taxonomy a week ahead.

Regulatory lens

The Basel Committee's Principles for the Sound Management of Operational Risk (revised 2021) expect banks to identify the operational risk in all their products, activities, processes and systems, and list the tools they use: loss and incident data, risk and control self-assessments, business process mapping, scenario analysis, indicators and audit findings among them. New products and major changes, such as Larkfield's cloud move, should be assessed before they go live.

Loss data also matters for capital. Under the Basel III standardised approach for operational risk, a bank's own loss history can raise or lower the capital it must hold, so supervisors expect it to be complete and accurate. The calculation belongs to Level 4: Regulation, Capital & Accounting.

Sparks

SparkFailing in advance

The psychologist Gary Klein described the pre-mortem in the Harvard Business Review in 2007. Asking “why did it fail?” instead of “what might go wrong?” gives people permission to voice doubts they would keep quiet about in a planning meeting, because the failure is treated as a given rather than a criticism.

SparkBanks share their losses

Rare losses are hard to see in one bank's data, so banks pool them. ORX, an industry association founded in 2002, collects anonymised operational loss events from its member banks and insurers, so each can see losses that have happened elsewhere and not yet to them.

Key takeaways

Identifying risks means finding and describing them, top down and bottom up, with the risk taxonomy as a checklist.
Write each risk as cause, event and consequence: the cause shows where to control it, the event what to watch.
Workshops tap the knowledge of the people who do the work; a pre-mortem helps them speak up.
Process maps find failure points step by step: people, processes, systems and external events, especially at handoffs.
Loss data shows frequency and severity, but only for what has already happened; add external data and scenarios for rare events.

Reaction

Check what stuck

Glossary

Risk statement: One sentence that names a risk's cause, the event that could happen, and its consequence.
Risk workshop: A structured meeting where the people who run an activity list what could go wrong with it.
Pre-mortem: A workshop technique: imagine the project has already failed, then list the reasons why. It makes it easier to voice doubts.
Process map: A step-by-step drawing of how a piece of work flows through people and systems.
Handoff: A point where work passes from one team or system to another. Errors gather there.
Loss data: A record of past losses and incidents: what happened, when, why and what it cost.
Near miss: An incident that could have caused a loss but did not, often by luck. Worth recording too.
External loss data: Loss data from other firms, through a data-sharing consortium or public reports.
Event type: One of the seven Basel categories used to classify operational loss events.
Frequency: How often losses happen.
Severity: How large a loss is when it happens.
Horizon scanning: Looking ahead for new risks, such as new technology, new rules or a changing climate.

Deep Dives & Origins

Deep Dives

Chapelle, A., Operational Risk Management: Best Practices in the Financial Services Industry, Wiley, 2019, part on risk identification. Intermediate.
Klein, G., “Performing a Project Premortem”, Harvard Business Review, September 2007. Beginner.

Origins

Basel Committee on Banking Supervision, Revisions to the Principles for the Sound Management of Operational Risk, BIS, March 2021.
Basel Committee on Banking Supervision, International Convergence of Capital Measurement and Capital Standards (Basel II), comprehensive version, June 2006: definition of operational risk and the loss event type classification.
Basel Committee on Banking Supervision, Basel III: Finalising post-crisis reforms, BIS, December 2017 (standardised approach for operational risk).
International Organization for Standardization, ISO 31000:2018 Risk management: Guidelines, clause 6.4.2 (risk identification).

Watch this lesson

Video version

Prefer to watch? The same lesson as a 10-minute video will sit here, made from this page's script.