Operational Loss Event Report Template (Basel, CRR3, DORA)

Operational Loss Event Report: [Event ID] [Short event title]

Report for one operational risk loss event (or one group of related events) at a bank or investment firm: what happened, how it is classified, when it occurred, was discovered and was accounted for, the gross loss, recoveries and net loss, the root cause and failed controls, boundary flags with credit and market risk, remediation, and the regulatory notifications it triggered. It is structured around the loss data concepts in the Capital Requirements Regulation as amended by Regulation (EU) 2024/1623 (CRR3, Part Three, Title III, operational risk, loss data provisions in Articles 317 to 323; check the consolidated text), the Basel Framework chapter OPE25 (cited by name; Level 1 event types and business lines by name only), and the major ICT-related incident regime of Regulation (EU) 2022/2554 (DORA, Article 19). Replace every [bracketed] value and every row marked Example. The worked example uses the fictional Fernhollow Bank, a mid-sized EU credit institution reporting in EUR. This is a document format, not legal, regulatory, accounting or risk advice. Obtain the regulation or standard for the normative text.

Document control

Approvals

Revision history

Contents

• 1. Event summary
• 2. Classification
• 3. Key dates
• 4. Event narrative
• 5. Loss amounts
• 6. Root cause analysis
• 7. Control failures
• 8. Related and grouped events
• 9. Boundary events with credit and market risk
• 10. Remediation actions
• 11. Regulatory notifications and reporting
• 12. Second-line review and data-entry checklist
• 13. Glossary
• 14. References
• Standard and licence note

1. Event summary

[Two to five sentences: what happened, where, the gross and net loss, the customer and regulatory impact, and the status of remediation.]

Example: On 2026-06-12 a faulty release of Fernhollow Bank's payment batch software caused 412 salary payments for corporate clients to be executed twice. The bank paid out EUR 1,240,000 in duplicate credits, compensated affected clients for late fees and paid external legal and forensic costs. After recoveries from beneficiaries the net loss is EUR 212,500. The event was classified as a major ICT-related incident under DORA and notified to the competent authority; the release process control that failed has been redesigned and tested.

2. Classification

Classify the event in three dimensions: the event type (what kind of event occurred), the business line (where in the bank it happened), and the cause category (what made it possible). Each dimension answers a different question for the risk profile. Event type tells the board which kinds of failure are recurring. Business line supports capital allocation and comparison between units. Cause category directs remediation investment.

2.1 Event type

The seven Basel Level 1 event types are listed below by name. Map the bank's own Level 2 and Level 3 categories to them in the operational risk taxonomy, and keep the mapping stable across years so that trends remain comparable. EU institutions should also check the operational risk taxonomy that the CRR mandates in its loss data provisions, as specified in the relevant EBA technical standards once in force.

2.2 Business line and other attributes

Record the event type that best describes the event as a whole. When two event types seem equally plausible, apply the taxonomy's tie-break rule (for example, the event type of the first failure in the chain) and record the rejected option with the reason, as in the example. This makes later reclassification traceable and protects the comparability of the loss history.

3. Key dates

Explain any gap of more than [30] days between occurrence and discovery. A long gap is itself a finding: it shows that a detective control did not work or did not exist. For events that span several months, such as a mis-selling practice, record the first and last dates of the conduct and state the basis for the dates chosen.

4. Event narrative

Write a chronological account of the event from the first relevant action to the point where the cause was removed and customers were made whole. Use a timeline table for events with many steps, and keep the narrative paragraphs for the explanation that a table cannot carry.

[Narrative paragraphs.]

Example narrative: The release changed how the payment engine handled a timeout from the clearing gateway. Before the release, a timeout placed the batch in a manual queue. After the release, the engine retried automatically. The gateway had in fact accepted the first submission, so the retry produced a second credit for 412 payments. The test environment used a gateway simulator that never timed out, so the retry path was not exercised before go-live. Treasury noticed an unexplained outflow in the afternoon reconciliation and raised the alarm. Rolling back the release removed the cause the same day, but the duplicate credits had already reached beneficiary accounts at 37 other banks.

5. Loss amounts

5.1 Gross loss components

Gross loss is the loss before any recovery. It includes direct charges to the profit and loss account, write-downs, provisions or reserves booked for the event, external expenses directly caused by it (legal fees, consultants, settlements, compensation) and, where the bank's rules require it, pending losses held temporarily in suspense accounts. It normally excludes internal costs such as staff time, the cost of general improvements made afterwards, and insurance premiums. Check the inclusion and exclusion rules that apply to the bank's capital approach in the consolidated CRR text and the related technical standards, and record the rule you applied in the "Basis" column.

5.2 Recoveries and net loss

Recoveries are amounts received from third parties that reduce the loss: funds returned by beneficiaries, insurance payouts, indemnities from vendors, or legal awards. Record direct recoveries (the lost asset comes back) separately from insurance and other risk-transfer recoveries, because capital rules and internal reporting may treat them differently. Record a recovery only when it has been received or is certain and booked, never when it is merely expected.

Net loss equals gross loss minus total recoveries:

Example: 1,304,500 minus 1,092,000 equals EUR 212,500. The direct recoveries add up as 864,000 plus 171,000 plus 57,000, which is 1,092,000. Of the 412 duplicate credits, the amounts not returned (EUR 148,000) relate to beneficiaries who had already withdrawn the funds; collection continues through the legal team and any later recovery will be booked as an update in section 5.3.

5.3 Amount history

Each change in a booked amount is a new row. This history shows the development of the loss over time, which supervisors and auditors use to test whether provisional amounts were reasonable and whether late adjustments were captured in the right period.

5.4 Non-financial impacts and near-miss value

Some effects do not appear in the ledger but matter for the risk profile: customer detriment, service downtime, regulatory attention and reputational coverage. Record them in plain terms. If the event could easily have been larger (for example, if the batch had been a month-end batch three times the size), record the potential exposure as a scenario input for the RCSA and stress testing, but never add it to the booked loss.

6. Root cause analysis

Use a structured method such as the five whys or a fishbone (cause and effect) analysis. Involve the people who operate the process, the technology owner, and an operational risk analyst who did not take part in the original change. Record the chain of causes and the evidence for each step, then identify the root cause or causes that remediation must address.

Distinguish the root cause from the trigger. In the example, the gateway timeout is the trigger, an event outside the bank's control that will happen again. The root causes are the missing duplicate check and the missing test requirement, both of which the bank can fix. A remediation plan that tries to prevent timeouts would miss the point.

7. Control failures

Record controls that worked as well as those that failed. The example shows that incident management performed well, which is useful evidence for the RCSA and for the supervisor. In the example, CTL-PAY-002 is the same control that the payments operations RCSA rates; after ACT-PAY-05 the RCSA records the bulk-file gap as fixed and keeps the SEPA instant gap open under ISS-PAY-02. Send each change in control rating to the RCSA owner so that the risk and control self-assessment (finance/operational-risk-rcsa) reflects the new evidence before the next reporting cycle.

8. Related and grouped events

Apply the bank's grouping rule consistently. A common rule is that losses arising from the same root cause, in the same process, within a defined period, form one event. Record the individual impacts below so that the grouped event can be audited. Link, but do not merge, earlier events that point to the same control weakness; they show a pattern that the operational risk committee should see.

When an event shows that an earlier remediation action did not work, as in the example, report that fact explicitly to the operational risk committee and reopen the earlier action. Repeat events with the same root cause are among the clearest signals of weak risk culture and should influence the risk appetite discussion in the Risk Appetite Statement (finance/risk-appetite-statement).

9. Boundary events with credit and market risk

A boundary event is a loss with an operational cause that also relates to another risk type. Record every boundary event in the operational loss database with a flag, even when the applicable capital rules require the amount to stay in another risk type's calculation. Check the treatment in the bank's capital rules (CRR loss data provisions for EU institutions and the Basel loss data chapter by name) and record it in the table.

Example of a separate credit boundary event: In 2026 Fernhollow Bank's SME lending unit discovered that a borrower had obtained a EUR 380,000 loan with forged financial statements. The loss surfaced as a credit default and an impairment. The operational risk function recorded event OLE-2026-022 with the external fraud event type and a credit boundary flag, so that fraud trends are visible even though the amount stays in credit risk data under the bank's applicable rules.

10. Remediation actions

Track actions in the bank's issue management system and reference the issue IDs here. Overdue actions on events above the escalation threshold should be reported to the operational risk committee every month until closed, with the reason for the delay and a revised date approved by the committee.

11. Regulatory notifications and reporting

11.1 DORA major ICT-related incident

When the event is ICT-related, check whether the linked incident was classified as major under DORA (Regulation (EU) 2022/2554, Article 18 on classification and Article 19 on reporting, with Delegated Regulation (EU) 2024/1772 for the classification criteria, Delegated Regulation (EU) 2025/301 for the content and time limits and Implementing Regulation (EU) 2025/302 for the forms). The incident response process owns the notification; this report records the link and makes sure the loss amounts given to the authority in the intermediate and final reports match the loss database. DORA also expects financial entities to be able to estimate the aggregated annual costs and losses caused by major ICT-related incidents when the competent authority asks for them; check Article 11 in the consolidated text. The loss database should therefore tag every loss linked to a major ICT-related incident.

11.2 Other regimes

Follow the Incident Response Plan (compliance/incident-response-plan) for the clocks and forms. This report does not replace it.

12. Second-line review and data-entry checklist

Second-line challenge summary: [What the operational risk function questioned, what changed as a result, and any remaining disagreement with the first line.]

Example: The second line challenged the initial classification as "Execution, delivery and process management" and agreed with the first line on "Business disruption and system failures" after reviewing the engine logs. It also asked finance to move the legal costs from a general expense account to the event-coded account so that they reach the loss database automatically.

13. Glossary

14. References

• Regulation (EU) No 575/2013 (CRR) as amended by Regulation (EU) 2024/1623 (CRR3), Part Three, Title III (operational risk), loss data provisions in Articles 317 to 323, applicable from 2025-01-01. EUR-Lex; check the consolidated text and the related EBA technical standards.
• Basel Committee on Banking Supervision, Basel Framework, chapter OPE25 (operational risk, loss data), cited by name only.
• Basel Committee on Banking Supervision, Revisions to the Principles for the Sound Management of Operational Risk (2021), cited by name only.
• Regulation (EU) 2022/2554 (DORA), Articles 11, 18 and 19; Delegated Regulation (EU) 2024/1772; Delegated Regulation (EU) 2025/301; Implementing Regulation (EU) 2025/302. EUR-Lex.
• Regulation (EU) 2016/679 (GDPR), Article 33. EUR-Lex.
• US Government Accountability Office, Standards for Internal Control in the Federal Government (Green Book, 2025), for control design and operating effectiveness concepts (public domain).

Standard and licence note

Based on public law: Regulation (EU) No 575/2013 as amended by Regulation (EU) 2024/1623, Regulation (EU) 2022/2554 and its delegated and implementing acts, and Regulation (EU) 2016/679 (EUR-Lex, reuse with acknowledgement of the source). Structure aligned with the Basel Framework operational risk chapters, which are cited by chapter and name only; no Basel Committee text is reproduced or paraphrased. The seven event types and eight business lines are listed by name only. All text, tables and the worked example are original. Fernhollow Bank, its systems and every amount are fictional. Check the current official version of each regulation and the bank's own taxonomy before use. Template licence: MIT.