# 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.

<!--
Guidance: How to use this template
- One report per loss event. When several losses share one root cause
  (for example, one faulty system change that produced 40 duplicate
  payments), record them as one grouped event with a list of the
  individual impacts in section 8.
- The first line of defence (the business unit where the event
  happened) drafts sections 1 to 7. The operational risk function
  (second line) challenges the classification, amounts and root cause,
  then completes sections 11 and 12 before the record enters the loss
  database.
- Do not wait for final amounts. Open the report as soon as a loss or a
  provision is booked, record a provisional gross loss, and update it
  as recoveries and adjustments arrive. Each update is a new row in the
  amount history (section 5.3).
- Keep the narrative factual. The report is evidence for supervisors,
  internal audit and, for capital purposes, the loss data set. Opinions
  on blame belong in HR processes, not here.
- Related documents: Operational Risk RCSA
  (`finance/operational-risk-rcsa`), KRI Framework Specification
  (`finance/kri-framework-spec`), Risk Appetite Statement
  (`finance/risk-appetite-statement`), ICAAP Report
  (`finance/icaap-report`), Incident Response Plan
  (`compliance/incident-response-plan`), DORA ICT Third-Party Register
  (`compliance/dora-ict-third-party-register`), Risk and Control Matrix
  (`compliance/risk-control-matrix`), Risk Register
  (`compliance/risk-register`), Fraud Risk Assessment
  (`compliance/fraud-risk-assessment`).
-->

## Document control

<!-- Guidance: The loss event ID is the key that links this report to the loss database, the general ledger entries and any incident record. Never reuse an ID, even when an event is withdrawn. -->

| Field | Value |
|---|---|
| Document ID | [OLE-RPT-YYYY-NNN] |
| Loss event ID | [OLE-YYYY-NNN] |
| Linked incident IDs | [INC-YYYY-NNN, DORA incident reference if any] |
| Legal entity | [Entity name and LEI] |
| Business unit where the event occurred | [Unit] |
| Version | [1.0] |
| Status | [Provisional / Under second-line review / Final / Closed / Withdrawn] |
| Owner (first line) | [@business-unit-risk-officer] |
| Approvers/reviewers | [@head-of-business-unit], [@head-of-operational-risk], [@finance-controller], [@cro for events above the escalation threshold] |
| Reporting currency | [EUR] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential, operational risk and audit use] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Head of business unit (first line) | [@name] | [Confirm facts and amounts] | YYYY-MM-DD |
| Head of operational risk (second line) | [@name] | [Accept / Return for changes] | YYYY-MM-DD |
| Finance controller (amount reconciliation) | [@name] | [Reconciled to general ledger] | YYYY-MM-DD |
| Chief risk officer (escalated events only) | [@name] | [Noted / Further action required] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | Provisional report opened after first booking |
| 1.0 | YYYY-MM-DD | [@author] | Root cause and recoveries completed, second-line review passed |
| [1.1] | YYYY-MM-DD | [@author] | [Late recovery booked, net loss updated] |

## Contents

- [1. Event summary](#1-event-summary)
- [2. Classification](#2-classification)
- [3. Key dates](#3-key-dates)
- [4. Event narrative](#4-event-narrative)
- [5. Loss amounts](#5-loss-amounts)
- [6. Root cause analysis](#6-root-cause-analysis)
- [7. Control failures](#7-control-failures)
- [8. Related and grouped events](#8-related-and-grouped-events)
- [9. Boundary events with credit and market risk](#9-boundary-events-with-credit-and-market-risk)
- [10. Remediation actions](#10-remediation-actions)
- [11. Regulatory notifications and reporting](#11-regulatory-notifications-and-reporting)
- [12. Second-line review and data-entry checklist](#12-second-line-review-and-data-entry-checklist)
- [13. Glossary](#13-glossary)
- [14. References](#14-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Event summary

<!-- Guidance: Write this last, in five sentences or fewer, for a reader who sees only this section: the risk committee. State what happened, the net loss, whether customers were harmed, whether the cause is fixed and whether a regulator was notified. Pitfall: summaries that describe the fix but not the loss. -->

[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.

| Field | Value |
|---|---|
| Event title | [Short title] |
| Event status | [Open / Recoveries pending / Closed] |
| Gross loss (current) | [EUR amount] |
| Recoveries (current) | [EUR amount] |
| Net loss (current) | [EUR amount] |
| Customers affected | [Number, segments] |
| Escalation level | [Business unit / Operational risk committee / Executive committee / Board risk committee] |
| Regulatory notification made | [Yes, reference / No, with reason] |

## 2. Classification

<!-- Guidance: Classify by the event (what happened), not by the cause (why it happened) or the effect (what it cost). The cause goes in section 6. Use the bank's taxonomy, mapped to the Basel Level 1 event types for regulatory reporting. Pitfall: classifying every IT-related event as "Business disruption and system failures" even when the system worked and a person keyed the wrong amount. -->

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.

| Level 1 event type (Basel name) | Selected for this event | Bank Level 2 category | Rationale |
|---|---|---|---|
| Internal fraud | [ ] | [Category] | [Why it does or does not apply] |
| External fraud | [ ] | [Category] | [Rationale] |
| Employment practices and workplace safety | [ ] | [Category] | [Rationale] |
| Clients, products and business practices | [ ] | [Category] | [Rationale] |
| Damage to physical assets | [ ] | [Category] | [Rationale] |
| Business disruption and system failures | [x] *(Example)* | Systems, software change failure *(Example)* | The duplicate execution was produced by a software defect, not by a manual input error *(Example)* |
| Execution, delivery and process management | [ ] *(Example)* | Transaction execution *(Example)* | Considered and rejected: no person processed the payments twice; the second-line reviewer recorded the debate *(Example)* |

### 2.2 Business line and other attributes

| Attribute | Value |
|---|---|
| Business line (Basel name) | [Corporate finance / Trading and sales / Retail banking / Commercial banking / Payment and settlement / Agency services / Asset management / Retail brokerage] |
| Business line *(Example)* | Payment and settlement |
| Process (bank process taxonomy) | [Process ID and name], *Example:* PRC-PAY-04 Clearing and settlement (scheme submission of bulk salary files); the faulty release came through PRC-PAY-06 Platform operations (release management) |
| Product | [Product], *Example:* Corporate payroll service |
| Cause category | [People / Process / Systems / External events], *Example:* Process (change management) with a Systems trigger |
| Legal entity and country | [Entity, country], *Example:* Fernhollow Bank, head office |
| ICT-related | [Yes / No], *Example:* Yes |
| Third party involved | [Name, register ID in the DORA register], *Example:* none, in-house software |
| Conduct or customer harm | [Yes / No, describe], *Example:* Yes, late salary credits for some recipients after the bank reversed duplicates |
| Linked risk in the RCSA | [Risk ID], *Example:* RSK-PAY-001 Misdirected or duplicate payments, in the payments operations RCSA (`finance/operational-risk-rcsa`) |

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

<!-- Guidance: Three dates matter for loss data: when the event happened, when the bank found out, and when the loss first hit the profit and loss account. Capital and reporting rules usually use the accounting date to place a loss in a year. Pitfall: using the report date as the occurrence date. -->

| Date type | Date | Source of evidence |
|---|---|---|
| Date of occurrence (event start) | YYYY-MM-DD | [Log, transaction record] |
| Date of occurrence *(Example)* | 2026-06-12 | Payment engine log, batch run 06:05 CET |
| Date of discovery | YYYY-MM-DD | [Complaint, reconciliation, alert] |
| Date of discovery *(Example)* | 2026-06-12 | Nostro reconciliation break at 14:40 CET |
| Date of first accounting (first loss, provision or reserve booked) | YYYY-MM-DD | [Journal entry ID] |
| Date of first accounting *(Example)* | 2026-06-15 | JE-2026-06-0881 |
| Date event ended (cause removed) | YYYY-MM-DD | [Change record] |
| Date event ended *(Example)* | 2026-06-12 | Release rolled back at 15:25 CET |
| Date of last accounting movement | YYYY-MM-DD | [Journal entry ID] |
| Date of last accounting movement *(Example)* | 2026-08-28 | JE-2026-08-1204, final beneficiary recovery |

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

<!-- Guidance: Describe the sequence of facts in time order. Name systems, processes and roles, not individuals. Separate facts from assumptions and mark the assumptions. Pitfall: narratives that jump to the root cause before the facts are established. -->

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.

| Time (local) | Fact | Evidence |
|---|---|---|
| 2026-06-11 18:30 *(Example)* | Release PAY-REL-2026-23 deployed to production after approval on the change advisory board | Change record CHG-2026-1147 |
| 2026-06-12 06:05 *(Example)* | Bulk salary batch processed; the new retry logic resubmitted 412 payments after a timeout response from the clearing gateway | Engine log |
| 2026-06-12 14:40 *(Example)* | Reconciliation shows outgoing volume EUR 1,240,000 above client instructions | Reconciliation report REC-0612 |
| 2026-06-12 15:25 *(Example)* | Release rolled back; incident INC-2026-0412 declared, severity 1 | Incident record |
| 2026-06-12 17:10 *(Example)* | Incident classified as major ICT-related incident under DORA | Classification record |
| 2026-06-13 to 2026-08-28 *(Example)* | Recall requests to beneficiary banks; recoveries received in tranches | Recovery ledger |

[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

<!-- Guidance: Record each component separately so that finance can reconcile to the general ledger and the operational risk function can apply the regulatory inclusion and exclusion rules. Pitfall: netting recoveries against the gross loss before recording it, which hides the true severity. -->

### 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.

| Component ID | Description | Amount (EUR) | GL account and journal | Basis for inclusion |
|---|---|---|---|---|
| GL-01 *(Example)* | Duplicate payments credited to beneficiaries | 1,240,000 | 590-110, JE-2026-06-0881 | Direct charge to profit and loss |
| GL-02 *(Example)* | Compensation to clients for late fees and interest after reversals | 18,500 | 590-120, JE-2026-07-0310 | Direct charge, settlement with customers |
| GL-03 *(Example)* | External legal and forensic costs | 46,000 | 590-130, JE-2026-07-0455 | External expense directly linked to the event |
| Excluded *(Example)* | Overtime of payment operations staff (internal cost, EUR 9,200) | 0 | Not booked to the event | Internal cost, excluded by bank policy |
| **Total gross loss** *(Example)* | | **1,304,500** | | |

### 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.

| Recovery ID | Type | Counterparty | Date received | Amount (EUR) |
|---|---|---|---|---|
| REC-01 *(Example)* | Direct recovery, returned funds | 29 beneficiary banks (first tranche) | 2026-06-30 | 864,000 |
| REC-02 *(Example)* | Direct recovery, returned funds | 6 beneficiary banks (second tranche) | 2026-07-24 | 171,000 |
| REC-03 *(Example)* | Direct recovery, returned funds | 2 beneficiary banks (final) | 2026-08-28 | 57,000 |
| REC-04 *(Example)* | Insurance | Cyber and crime policy | Not applicable | 0 (net loss after beneficiary recoveries, EUR 212,500, is below the EUR 250,000 retention) |
| **Total recoveries** *(Example)* | | | | **1,092,000** |

Net loss equals gross loss minus total recoveries:

$$
\text{Net loss} = \text{Gross loss} - \text{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.

| Date | Movement | Gross loss after movement | Recoveries after movement | Net loss after movement | Entered by |
|---|---|---|---|---|---|
| 2026-06-15 *(Example)* | Initial booking of duplicate payments | 1,240,000 | 0 | 1,240,000 | [@ops-risk-analyst] |
| 2026-06-30 *(Example)* | First recovery tranche | 1,240,000 | 864,000 | 376,000 | [@ops-risk-analyst] |
| 2026-07-15 *(Example)* | Client compensation booked | 1,258,500 | 864,000 | 394,500 | [@ops-risk-analyst] |
| 2026-07-22 *(Example)* | Legal and forensic costs booked | 1,304,500 | 864,000 | 440,500 | [@ops-risk-analyst] |
| 2026-07-24 *(Example)* | Second recovery tranche | 1,304,500 | 1,035,000 | 269,500 | [@ops-risk-analyst] |
| 2026-08-28 *(Example)* | Final recovery tranche | 1,304,500 | 1,092,000 | 212,500 | [@ops-risk-analyst] |

### 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.

| Impact | Description |
|---|---|
| Customers affected *(Example)* | 61 corporate clients, 412 payees |
| Service disruption *(Example)* | Bulk payment service suspended for 9 hours |
| Potential exposure if undetected for a full batch cycle *(Example)* | Scenario input, not a loss: a month-end batch carries about three times the volume |
| Media or social media coverage *(Example)* | None identified |

## 6. Root cause analysis

<!-- Guidance: Ask "why" until you reach a cause the bank can control and change. Stop at the level where a control could have prevented or detected the event. Pitfall: stopping at "human error"; people make errors, controls are meant to catch them. -->

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.

```mermaid
flowchart TD
  A[412 payments executed twice] --> B[Engine retried after gateway timeout]
  B --> C[Release changed timeout handling to automatic retry]
  C --> D[Retry path not tested]
  D --> E[Gateway simulator cannot produce timeouts]
  D --> F[Test plan did not require negative-path cases for payment changes]
  B --> G[No idempotency check on payment reference]
  G --> H[Design standard for payment interfaces silent on duplicate protection]
```

| Cause ID | Cause statement | Level | Evidence | Addressed by action |
|---|---|---|---|---|
| RC-01 *(Example)* | The payment engine lacked a duplicate check on the end-to-end payment reference before submission | Root cause, design | Code review, interface specification v4.2 | ACT-PAY-05 |
| RC-02 *(Example)* | The test plan for payment changes did not require negative-path cases such as timeouts | Root cause, process | Test plan TP-PAY-23 | ACT-PAY-06 |
| RC-03 *(Example)* | The gateway simulator in the test environment could not produce timeouts | Contributing cause, tooling | Test environment inventory | ACT-PAY-07 |
| RC-04 *(Example)* | Reconciliation ran only twice a day, so detection took over eight hours | Contributing cause, detection | Reconciliation schedule | ACT-PAY-08 |

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

<!-- Guidance: Link each failed or missing control to the control library so that the RCSA rating can be updated. A control can fail in design (it would not have worked even if performed) or in operation (it was designed well but not performed). Pitfall: concluding that controls were effective because no one broke a rule. -->

| Control ID | Control description | Type | Failure mode | RCSA rating before | Rating after review |
|---|---|---|---|---|---|
| CTL-CHG-007 *(Example)* | Change advisory board approves production releases after test evidence review | Preventive, manual | Operating effectiveness: approval given on incomplete test evidence | Effective | Partially effective |
| CTL-PAY-002 *(Example)* | Automated duplicate payment check on amount, beneficiary and reference within 5 days | Preventive, automated | Design: did not cover bulk salary files resubmitted by the engine after a timeout, nor SEPA instant payments | Partially effective | Ineffective |
| CTL-REC-002 *(Example)* | Intraday nostro reconciliation | Detective, automated | Design: frequency too low for the volume | Effective | Partially effective |
| CTL-INC-001 *(Example)* | Incident declaration and escalation | Corrective | Worked as designed: severity 1 declared within 45 minutes of detection | Effective | Effective |

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

<!-- Guidance: Group losses that share one root cause into one event, and link events that are related but separate. Grouping affects the severity distribution and therefore capital and scenario analysis. Pitfall: splitting one event into many small ones that each fall below the collection threshold. -->

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.

| Item | Linked event ID | Relationship | Amount (EUR) | Comment |
|---|---|---|---|---|
| Grouped impact *(Example)* | OLE-2026-014-A to OLE-2026-014-C | Same release, same batch, three accounting entries | 1,304,500 gross | Recorded as one event OLE-2026-014 |
| Related prior event *(Example)* | OLE-2026-018 | Duplicate SEPA instant payments after a repair batch (2026-05-20), net loss EUR 65,000 | 65,000 net | Same duplicate-check gap in CTL-PAY-002; issue ISS-PAY-02 was scoped to SEPA instant only and is still open |
| Related near miss *(Example)* | NM-2026-007 | Duplicate file blocked manually by an operator in April 2026 | 0 | Weak signal that was not escalated |

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

<!-- Guidance: Some losses have operational causes but surface as credit or market losses. Flag them so the loss is counted once, in the right capital requirement. Pitfall: leaving a fraud-related loan default only in credit risk data, so the operational risk profile never shows the fraud. -->

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.

| Boundary type | Typical examples | Flag in loss database | Treatment applied (check the applicable rules) |
|---|---|---|---|
| Credit risk boundary | Loan obtained with forged documents, collateral that was never perfected because of a process failure, a limit breach caused by a system error | [Yes / No] | [Kept in credit risk capital and excluded from the regulatory loss data set (CRR Art. 317(5)); flagged in the internal database / other] |
| Market risk boundary | Trade entered with the wrong quantity, unauthorised position, model input error in a pricing system | [Yes / No] | [Included in the loss data set as operational risk (CRR Art. 317(6)) / other] |
| Not a boundary event *(Example)* | Duplicate payment (this event): no credit exposure or trading position involved | No | Pure operational loss |

*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

<!-- Guidance: Each root cause needs at least one action with an owner, a due date and a test of effectiveness. Close an action only after evidence shows the fix works, not when the change is deployed. Pitfall: actions such as "remind staff" that do not change any control. -->

| Action ID | Addresses | Action | Owner | Due date | Status | Effectiveness test |
|---|---|---|---|---|---|---|
| ACT-PAY-05 *(Example)* | RC-01 | Add a duplicate check on end-to-end payment reference to CTL-PAY-002 for bulk and single SEPA credit transfer files (SEPA instant follows under ACT-PAY-02 in the RCSA) | [@head-of-payments-it] | 2026-09-30 | Done | Replayed the June batch in test with forced timeouts: zero duplicates |
| ACT-PAY-06 *(Example)* | RC-02 | Make negative-path test cases mandatory for any change touching payment submission | [@head-of-change-management] | 2026-08-31 | Done | Second-line sample of five later payment changes: all had negative-path evidence |
| ACT-PAY-07 *(Example)* | RC-03 | Upgrade the gateway simulator to produce timeouts, rejects and partial acknowledgements | [@test-environment-lead] | 2026-10-31 | In progress | Simulator capability demonstrated to second line |
| ACT-PAY-08 *(Example)* | RC-04 | Move nostro reconciliation for bulk payment accounts to hourly | [@head-of-treasury-operations] | 2026-09-15 | Done | Detection time in the next live test below one hour |
| ACT-PAY-09 *(Example)* | Section 8 | Widen issue ISS-PAY-02 (from OLE-2026-018) to all payment channels and confirm closure criteria | [@head-of-operational-risk] | 2026-07-31 | Done | Closure criteria rewritten to require effectiveness evidence |

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

<!-- Guidance: One event can trigger several regimes at once, each with its own clock: DORA incident reporting, payment services incident reporting, data protection breach notification, conduct notifications and supervisory loss reporting. Record each decision, even a decision not to notify, with the reason. Pitfall: treating the loss report as the trigger; notification clocks start from classification or awareness, usually long before amounts are final. -->

### 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.

| Item | Value |
|---|---|
| Linked incident ID | [INC-YYYY-NNN], *Example:* INC-2026-0412 |
| Classified as major ICT-related incident | [Yes / No], *Example:* Yes, criteria met for clients affected, critical service and economic impact |
| Classification date and time | [YYYY-MM-DD hh:mm], *Example:* 2026-06-12 17:10 |
| Initial notification sent | [YYYY-MM-DD hh:mm], *Example:* 2026-06-12 20:45 |
| Intermediate report sent | [YYYY-MM-DD], *Example:* 2026-06-15 |
| Final report sent | [YYYY-MM-DD], *Example:* 2026-07-14 |
| Loss amount in final report matches loss database | [Yes / No, explain], *Example:* Yes at the date of the final report (gross 1,240,000; recoveries 864,000); later costs and recoveries recorded here only |
| ICT third-party provider involved (register reference) | [Register ID or none], see DORA ICT Third-Party Register (`compliance/dora-ict-third-party-register`) |

### 11.2 Other regimes

| Regime | Trigger met | Decision and reference | Owner |
|---|---|---|---|
| Personal data breach notification (GDPR Article 33) | [Yes / No] | [Decision, DPO reference], *Example:* No personal data disclosed to unauthorised parties | [@dpo] |
| Conduct or customer remediation notification to the conduct authority | [Yes / No] | [Decision] | [@head-of-compliance] |
| Supervisory loss data reporting (common reporting templates where applicable) | [Period] | [Included in the reporting for period YYYY-QN] | [@regulatory-reporting] |
| Insurance notification | [Yes / No] | [Claim reference], *Example:* Notified 2026-06-14 for completeness; loss within retention | [@insurance-manager] |
| Internal escalation to board risk committee | [Yes / No] | [Meeting date] | [@cro] |

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

<!-- Guidance: The second line uses this checklist before the record is accepted into the loss database. Every "No" needs a comment and an owner. Pitfall: accepting records with missing dates or unreconciled amounts because the quarter-end deadline is close. -->

| Check | Result | Comment |
|---|---|---|
| Event ID unique and linked to incident and journal entries | [Yes / No] | |
| Event type, business line and cause category mapped to the taxonomy | [Yes / No] | |
| Occurrence, discovery and accounting dates present and evidenced | [Yes / No] | |
| Gross loss components reconciled to the general ledger by finance | [Yes / No] | |
| Recoveries recorded separately by type, only when received | [Yes / No] | |
| Exclusions (internal costs, improvements) documented | [Yes / No] | |
| Grouping rule applied and related events linked | [Yes / No] | |
| Boundary flags set where applicable | [Yes / No] | |
| Root cause goes beyond "human error" and is evidenced | [Yes / No] | |
| Each root cause has an action with owner, date and effectiveness test | [Yes / No] | |
| RCSA, KRI and scenario owners informed | [Yes / No] | |
| Regulatory notification decisions recorded with reasons | [Yes / No] | |
| Collection threshold applied: internal threshold [EUR x] or collected voluntarily; regulatory threshold EUR 20,000 net (CRR Art. 319(1)) for the annual operational risk loss, EUR 100,000 net for Art. 446 disclosure (Art. 319(2)) | [Yes / No] | |

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

<!-- Guidance: Keep definitions consistent with the bank's operational risk taxonomy. -->

| Term | Meaning in this report |
|---|---|
| Operational risk | Risk of loss from inadequate or failed internal processes, people and systems, or from external events, including legal risk |
| Loss event | An occurrence that produces an operational loss, or would have done so without a recovery |
| Gross loss | Loss before any recovery |
| Recovery | An amount received from a third party that reduces the loss, such as returned funds or insurance |
| Net loss | Gross loss minus recoveries |
| Near miss | An event that could have caused a loss but did not |
| Grouped event | Several losses that share one root cause and are recorded as one event |
| Boundary event | An operational loss related to credit or market risk |
| Major ICT-related incident | DORA term for an ICT-related incident that meets the classification criteria in the delegated regulation |
| RCSA | Risk and control self-assessment |
| Collection threshold | Minimum amount above which the bank must record a loss event in its database |

## 14. References

<!-- Guidance: Cite the version you used and check for amendments before each reporting cycle. -->

- 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.