# Operational Risk RCSA: [Business unit or process]

> Risk and control self-assessment (RCSA) record for one business unit or
> end-to-end process in a bank or other financial institution: scope,
> scoring method, process inventory, inherent risks classified by the
> Basel operational risk event types, controls with design and operating
> effectiveness, residual risk compared with risk appetite, action
> plans, key risk indicator (KRI) mapping, links to loss events and
> incidents, operational resilience and ICT third-party dependencies, and
> second-line challenge. It follows the Basel Committee Revised
> Principles for the Sound Management of Operational Risk (March 2021)
> and Principles for Operational Resilience (March 2021), both cited by
> name, and supports the ICT risk management duties of the Digital
> Operational Resilience Act (Regulation (EU) 2022/2554, applicable from
> 17 January 2025). Replace every `[bracketed]` value and every row
> marked *Example*. The worked example uses the payments operations unit
> of the fictional Fernhollow Bank. This is a document format, not legal,
> regulatory or financial advice. Obtain the principles and laws for the
> normative text.

<!--
Guidance: How to use this template
- An RCSA is run by the first line (the unit that owns the process),
  facilitated and challenged by the operational risk function. One file
  per unit or end-to-end process per cycle.
- Fill section 1 (scope) and section 3 (scales) first. Scales are set
  centrally and must not be changed by the unit, otherwise results
  cannot be aggregated.
- Work in this order: processes (section 4), inherent risks (section 5),
  controls (section 6), residual risk (section 7), then actions and KRIs.
  Rating controls before the risks are clear is the most common error.
- The general risk scoring logic is in the Risk Assessment Methodology
  (`compliance/risk-methodology`) and enterprise risks are held in the
  Risk Register (`compliance/risk-register`). This template adds the
  operational risk specifics: event types, control testing, loss data,
  KRIs and resilience.
- Third-party ICT arrangements referenced in section 11 must match the
  DORA Register of Information (`compliance/dora-ict-third-party-register`).
- Related documents: Risk Appetite Statement
  (`finance/risk-appetite-statement`), KRI Framework Specification
  (`finance/kri-framework-spec`), Operational Loss Event Report
  (`finance/operational-loss-event-report`), Risk and Control Matrix
  (`compliance/risk-control-matrix`), Control Testing Workpaper
  (`compliance/control-testing-workpaper`), Business Continuity
  (`compliance/business-continuity`).
-->

## Document control

<!-- Guidance: The unit head owns the RCSA and signs it; the operational risk function signs the challenge. Record the assessment period and the cut-off date for loss and incident data. -->

| Field | Value |
|---|---|
| Document ID | [RCSA-PAY-2026] |
| Institution and entity | [Bank name], [legal entity] |
| Business unit or process | [Payments operations] |
| Assessment period | [YYYY-MM-DD to YYYY-MM-DD] |
| Data cut-off for losses, incidents and KRIs | YYYY-MM-DD |
| Version | [1.0] |
| Status | [Draft / Workshop complete / Challenged / Signed off] |
| Owner | [@unit-head] |
| Facilitator (second line) | [@operational-risk-partner] |
| Approvers/reviewers | [@unit-head], [@head-of-operational-risk], [@chief-information-officer], [@head-of-third-party-risk] |
| Linked RAS | [RAS-2027] |
| Previous RCSA | [RCSA-PAY-2025] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal, confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Unit head (first line, owner) | [@name] | [Sign off] | YYYY-MM-DD |
| Operational risk partner (second line, challenge) | [@name] | [Challenge complete / Challenge with open points] | YYYY-MM-DD |
| Head of Operational Risk | [@name] | [Accept / Return] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@operational-risk-partner] | Pre-populated with prior RCSA, losses, incidents and KRIs |
| 0.2 | YYYY-MM-DD | [@unit-head] | Workshop results |
| 1.0 | YYYY-MM-DD | [@unit-head] | Signed off after second-line challenge |
| 1.1 | 2026-10-25 | [@operational-risk-partner] | Updated to align KRI-OPR-002 (red after the 5-hour outage), loss event OLE-2026-014 and control CTL-PAY-002 with the loss event report |

## Contents

- [1. Scope and unit profile](#1-scope-and-unit-profile)
- [2. Participants and roles](#2-participants-and-roles)
- [3. Methodology and scales](#3-methodology-and-scales)
- [4. Process inventory](#4-process-inventory)
- [5. Inherent risk assessment](#5-inherent-risk-assessment)
- [6. Control inventory and effectiveness](#6-control-inventory-and-effectiveness)
- [7. Residual risk and appetite comparison](#7-residual-risk-and-appetite-comparison)
- [8. Issues and action plans](#8-issues-and-action-plans)
- [9. KRI mapping](#9-kri-mapping)
- [10. Loss events, incidents and external events](#10-loss-events-incidents-and-external-events)
- [11. Operational resilience and third-party dependencies](#11-operational-resilience-and-third-party-dependencies)
- [12. Second-line challenge and sign-off](#12-second-line-challenge-and-sign-off)
- [13. Glossary and references](#13-glossary-and-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Scope and unit profile

<!-- Guidance: Define what is assessed and what is not. Questions to answer: Which processes, systems, locations, legal entities and outsourced activities are in scope? What changed since the last RCSA? Pitfall: scoping by organisation chart and missing steps run by another team or a provider. -->

This RCSA covers the [Payments operations] unit, which runs the end-to-end processing of outgoing and incoming customer payments for the group. The assessment covers all activities performed by the unit and by providers acting on its behalf, from the receipt of a payment instruction to final settlement and reconciliation. It excludes card issuing and acquiring, which are assessed in a separate RCSA, and the payment product design, which belongs to the product owner.

The unit profile gives reviewers the context needed to judge whether ratings are plausible. Volumes and values show exposure; recent changes show where new risks may have appeared; the loss and incident history shows where risks have already materialised.

| Item | Value (*Example* for Fernhollow Bank) |
|---|---|
| Legal entities | Fernhollow Bank (parent) and Fernhollow Payments (payment institution subsidiary) |
| Headcount | 84 full-time equivalents in two locations |
| Volumes | About 3.0 million outgoing payments a year; September 2026: 250,000 |
| Schemes | SEPA credit transfer, SEPA instant credit transfer, cross-border via correspondent, card push payments |
| Key systems | Payments hub, sanctions screening engine, fraud detection engine, core banking ledger |
| Material ICT third parties | Cloud hosting of the payments hub; scheme connectivity provider |
| Important business services supported | Make a domestic payment; receive a payment; make an instant payment |
| Changes since last RCSA | Payments hub moved to cloud hosting (2026-Q2); new repair queue tool; SEPA instant volumes up 40% |
| Operational loss allocation from the RAS cascade | EUR 2.0 million a year (payments allocation under RAS-OPR-01, parent payments operations and Fernhollow Payments combined) |

## 2. Participants and roles

<!-- Guidance: List who took part. A credible RCSA includes people who run the process daily, not only managers. Pitfall: an RCSA completed by one manager in a spreadsheet without a workshop. -->

| Participant | Role in the RCSA | Line of defence |
|---|---|---|
| [@unit-head] | Owner; accountable for ratings and actions | First |
| [@payments-team-leads] | Process experts; describe how work is really done | First |
| [@payments-it-lead] | Systems and change view | First |
| [@operational-risk-partner] | Facilitator and challenger; ensures method is applied | Second |
| [@compliance-partner] | Sanctions and financial crime controls | Second |
| [@information-security-partner] | ICT and security controls | Second |
| [@internal-audit-observer] | Observer only; no rating role | Third |

The workshop is prepared by the operational risk partner, who pre-populates the record with the previous RCSA, loss events, incidents, audit findings, KRI history and control test results. Participants then confirm or change each rating with reasons. The workshop agenda follows the section order of this template.

## 3. Methodology and scales

<!-- Guidance: Use the bank-wide scales without local changes. Questions to answer: What time horizon applies to likelihood? Is impact the reasonably worst case or the most likely case? Pitfall: mixing inherent and residual thinking, so inherent ratings already assume controls. -->

### 3.1 Approach

Inherent risk is the exposure before the controls in this RCSA are considered, assuming the process and its volumes as they are. Residual risk is the exposure after taking account of the controls as they actually operate, not as they are designed on paper. Both are rated on impact and likelihood for a reasonably severe but plausible event over a one-year horizon. Ratings follow the general methodology in the Risk Assessment Methodology (`compliance/risk-methodology`) with the operational risk scales below.

### 3.2 Impact scale

The impact rating is the highest of the dimensions. Financial thresholds are calibrated to the operational loss appetite (RAS-OPR-01, EUR 12.0 million a year group-wide) so that a single level 5 event would consume a large share of the annual appetite.

| Rating | Financial (net loss, EUR) | Customer | Regulatory | Service disruption |
|---|---|---|---|---|
| 1 Minimal | Under 50,000 | Few customers, no lasting harm | None | Within normal service levels |
| 2 Minor | 50,000 to under 250,000 | Limited group, quickly remedied | Routine supervisory query | Disruption well within impact tolerance |
| 3 Moderate | 250,000 to under 1,000,000 | Many customers affected, remediation needed | Notification or formal finding | Disruption approaching impact tolerance |
| 4 Major | 1,000,000 to under 5,000,000 | Large-scale harm, media attention | Enforcement action possible | Impact tolerance exceeded once |
| 5 Severe | 5,000,000 or more | Widespread harm, loss of trust | Sanctions, licence conditions | Impact tolerance exceeded repeatedly or for long periods |

### 3.3 Likelihood scale

| Rating | Description | Indicative frequency |
|---|---|---|
| 1 Rare | Not expected in normal conditions | Less than once in 10 years |
| 2 Unlikely | Could happen | Once in 5 to 10 years |
| 3 Possible | Has happened in the industry or occasionally here | Once in 1 to 5 years |
| 4 Likely | Expected to happen | 1 to 4 times a year |
| 5 Almost certain | Happens regularly | More than 4 times a year |

### 3.4 Score and rating

$$
\text{Score} = \text{Impact} \times \text{Likelihood}
$$

| Score | Rating |
|---|---|
| 1 to 4 | Low |
| 5 to 9 | Medium |
| 10 to 14 | High |
| 15 to 25 | Very high |

A multiplied score treats a 5 by 1 risk (severe but rare) like a 1 by 5 risk (minor but frequent). Review every risk with impact 5 separately, whatever its score, because tail events drive capital and resilience decisions.

### 3.5 Control effectiveness

| Rating | Design | Operating evidence |
|---|---|---|
| Effective | Addresses the risk cause or consequence fully | Tested in the period with no or trivial exceptions |
| Partially effective | Addresses the risk in part, or relies on manual steps with known gaps | Tested with exceptions, or not tested but supported by monitoring evidence |
| Ineffective | Does not address the risk, or is not performed | Failed testing, or a loss or incident showed it did not work |
| Not assessed | New control or no evidence | Treated as ineffective for residual rating until evidence exists |

Control effectiveness informs the residual rating; it is not applied as a fixed percentage reduction. Participants re-estimate residual impact and likelihood with the controls in mind and explain the change in the rationale column.

### 3.6 Running the assessment well

Prepare before the workshop, not during it. Send participants the pre-populated record at least five business days in advance, with the previous ratings, the loss events and incidents of the period, the KRI trends, open audit and regulatory findings, and the control test results. Ask each participant to mark the ratings they disagree with. The workshop then spends its time on disagreements rather than reading tables aloud.

Anchor every rating in evidence. For likelihood, ask how often the event, or a near miss, happened here and at peers. For impact, describe a concrete scenario (for example, "a 5-hour outage of domestic payments on the last business day of the month") and estimate its cost with the finance partner. For controls, ask for the latest test result, not for the control description.

Watch for four recurring errors. Optimism bias: units rate their own controls as effective because they designed them; insist on operating evidence. Anchoring: participants copy last year's ratings; ask what changed and why the rating did not. Granularity drift: one risk is split into ten narrow risks while another covers a whole process; keep risks at a level where one owner can act. Missing change risk: new systems, providers and products create risks that historical losses do not show yet; ask explicitly about every change listed in section 1.

Record the reasoning in the rationale column in plain sentences. An auditor reading the file a year later should be able to see why each rating was chosen without attending the workshop.

## 4. Process inventory

<!-- Guidance: List the processes and sub-processes in scope with owners and key systems. Questions to answer: Does the inventory match the process map used by operations? Which steps are outsourced? Pitfall: process names that differ from the bank's process taxonomy, which breaks aggregation. -->

| Process ID | Process | Sub-processes | Owner | Key systems | Outsourced steps | Important business service |
|---|---|---|---|---|---|---|
| PRC-PAY-01 *(Example)* | Payment initiation and validation | Instruction receipt, format validation, limit checks | [@team-lead-initiation] | Payments hub | None | Make a domestic payment; make an instant payment |
| PRC-PAY-02 *(Example)* | Screening | Sanctions screening, fraud scoring, alert handling | [@team-lead-screening] | Screening engine, fraud engine | None | Make a domestic payment; make an instant payment |
| PRC-PAY-03 *(Example)* | Exception repair | Repair queue handling, beneficiary data correction, release | [@team-lead-repair] | Repair queue tool | None | Make a domestic payment |
| PRC-PAY-04 *(Example)* | Clearing and settlement | Scheme submission, settlement monitoring, liquidity coordination | [@team-lead-settlement] | Payments hub, scheme gateway | Scheme connectivity provider | All three |
| PRC-PAY-05 *(Example)* | Reconciliation and investigations | Nostro reconciliation, customer investigations, recalls | [@team-lead-recon] | Reconciliation tool, core ledger | None | Receive a payment |
| PRC-PAY-06 *(Example)* | Platform operations | Hosting, failover, release management | [@payments-it-lead] | Cloud hosting | Cloud hosting provider | All three |

## 5. Inherent risk assessment

<!-- Guidance: Describe each risk as cause, event and consequence, and classify it by Basel event type. Questions to answer: Is every Level 1 event type considered, even if the conclusion is "not material"? Are risks specific enough to be controlled? Pitfall: risks written as control failures ("lack of four-eyes check") instead of events. -->

Classify each risk using the seven Level 1 Basel operational risk event types: internal fraud; external fraud; employment practices and workplace safety; clients, products and business practices; damage to physical assets; business disruption and system failures; and execution, delivery and process management. Using the same taxonomy as the loss database lets the bank compare RCSA results with actual losses. The same Level 1 categories are used for regulatory loss data collection in the EU; check the current CRR3 provisions and EBA technical standards for the applicable taxonomy.

| Risk ID | Risk description (cause, event, consequence) | Basel event type (Level 1) | Process | Inherent impact | Inherent likelihood | Inherent score | Inherent rating |
|---|---|---|---|---|---|---|---|
| RSK-PAY-001 *(Example)* | High repair volumes and manual data entry lead to misdirected or duplicate payments, causing unrecoverable losses and customer harm | Execution, delivery and process management | PRC-PAY-03, PRC-PAY-04 | 3 | 5 | 15 | Very high |
| RSK-PAY-002 *(Example)* | Failure of the payments hub or its failover causes an outage of payment services beyond the impact tolerance | Business disruption and system failures | PRC-PAY-06 | 5 | 3 | 15 | Very high |
| RSK-PAY-003 *(Example)* | A payment to a sanctioned party is released because screening misses a match or an alert is wrongly cleared | Clients, products and business practices | PRC-PAY-02 | 4 | 3 | 12 | High |
| RSK-PAY-004 *(Example)* | Fraudsters take over customer accounts or manipulate customers into authorising payments, causing reimbursable losses | External fraud | PRC-PAY-02 | 3 | 5 | 15 | Very high |
| RSK-PAY-005 *(Example)* | An employee changes beneficiary details in the repair queue to divert funds | Internal fraud | PRC-PAY-03 | 4 | 2 | 8 | Medium |
| RSK-PAY-006 *(Example)* | The cloud hosting provider fails or exits, and the bank cannot move the payments hub in time | Business disruption and system failures | PRC-PAY-06 | 5 | 2 | 10 | High |
| RSK-PAY-007 *(Example)* | Fire or flood damages the main operations site and its equipment | Damage to physical assets | All | 5 | 1 | 5 | Medium |
| RSK-PAY-008 *(Example)* | Shift patterns breach working-time rules, leading to claims and fatigue-related errors | Employment practices and workplace safety | All | 2 | 3 | 6 | Medium |

All seven Level 1 event types are represented. If a unit concludes that an event type is not material, record the reason in one line rather than omitting it, so reviewers can see it was considered.

## 6. Control inventory and effectiveness

<!-- Guidance: List the key controls for each risk with their type, frequency and evidence. Questions to answer: Is each control preventive or detective, manual or automated? When was it last tested and by whom? Pitfall: listing policies and training as controls; they support controls but rarely prevent an event on their own. -->

Key controls are those the residual rating relies on. Record design and operating effectiveness separately; the evidence column must point to a test, monitoring report or event, not to an opinion. Detailed test steps and results belong in the Control Testing Workpaper (`compliance/control-testing-workpaper`) and the full control catalogue in the Risk and Control Matrix (`compliance/risk-control-matrix`).

| Control ID | Control description | Risks mitigated | Type | Nature | Frequency | Design | Operating | Overall | Evidence |
|---|---|---|---|---|---|---|---|---|---|
| CTL-PAY-001 *(Example)* | Second person approves every repaired payment above EUR 10,000 before release | RSK-PAY-001, RSK-PAY-005 | Preventive | Manual, system-enforced | Each payment | Effective | Effective | Effective | Q3 2026 test, 0 exceptions in 60 samples |
| CTL-PAY-002 *(Example)* | Automated duplicate payment check on amount, beneficiary and reference within 5 days | RSK-PAY-001 | Preventive | Automated | Each payment | Partially effective | Effective | Partially effective | Bulk-file resubmission gap found in OLE-2026-014 and closed by ACT-PAY-05 on 2026-09-30; rule still does not cover SEPA instant, gap logged as ISS-PAY-02 |
| CTL-PAY-003 *(Example)* | Active-passive failover of the payments hub, tested twice a year | RSK-PAY-002, RSK-PAY-006 | Corrective | Automated with manual decision | Semi-annual test | Partially effective | Ineffective | Ineffective | Failover took 5 hours on 2026-09-12 against a 4-hour impact tolerance |
| CTL-PAY-004 *(Example)* | Real-time sanctions screening of all payments against current lists | RSK-PAY-003 | Preventive | Automated | Each payment | Effective | Effective | Effective | Annual screening model validation; list update monitoring |
| CTL-PAY-005 *(Example)* | Repair queue access limited to repair roles, all changes logged and reviewed weekly | RSK-PAY-005, RSK-PAY-001 | Detective | Manual review of system log | Weekly | Effective | Partially effective | Partially effective | 2 of 13 weekly reviews late in Q3 |
| CTL-PAY-006 *(Example)* | Quality assurance of a sample of cleared sanctions alerts by a second analyst | RSK-PAY-003 | Detective | Manual | Daily sample | Effective | Effective | Effective | Compliance monitoring report Q3 |
| CTL-PAY-007 *(Example)* | Behavioural fraud scoring with holds on high-risk payments | RSK-PAY-004 | Preventive | Automated | Each payment | Effective | Effective | Effective | Model performance report; false negative review |
| CTL-PAY-008 *(Example)* | Payee name verification before customer confirms a new beneficiary | RSK-PAY-004 | Preventive | Automated | Each new beneficiary | Effective | Effective | Effective | Scheme rule compliance report |
| CTL-PAY-009 *(Example)* | Documented and tested exit plan and contractual exit rights for the cloud hosting provider | RSK-PAY-006 | Corrective | Manual | Annual test | Effective | Effective | Effective | Exit plan test 2026-06; DORA register entry |
| CTL-PAY-010 *(Example)* | Secondary operations site with tested relocation of critical staff | RSK-PAY-007 | Corrective | Manual | Annual test | Effective | Effective | Effective | Business continuity test 2026-05 |
| CTL-PAY-011 *(Example)* | Rostering system blocks shifts that breach working-time rules | RSK-PAY-008 | Preventive | Automated | Each roster | Effective | Effective | Effective | HR compliance check Q3 |

## 7. Residual risk and appetite comparison

<!-- Guidance: Re-rate each risk with controls as they operate, compare with the appetite for the risk type, and decide treatment. Questions to answer: Is every residual rating justified by control evidence? Which risks are outside appetite? Pitfall: residual ratings that drop to Low because many controls exist, even though key controls are ineffective. -->

Operational appetite at unit level is derived from the Risk Appetite Statement (`finance/risk-appetite-statement`): the qualitative statements QS-06 and QS-07, the loss allocation under RAS-OPR-01, and the impact tolerance metric RAS-OPR-02. For the payments unit the operational risk function has translated these into the following residual rating appetite: risks linked to important business services or impact tolerances, Medium or lower; financial crime risks, Low; all other operational risks, Medium or lower.

| Risk ID | Key controls | Residual impact | Residual likelihood | Residual score | Residual rating | Appetite | Within appetite? | Treatment | Rationale |
|---|---|---|---|---|---|---|---|---|---|
| RSK-PAY-001 *(Example)* | CTL-PAY-001, CTL-PAY-002, CTL-PAY-005 | 3 | 3 | 9 | Medium | Medium | Yes | Reduce further (ISS-PAY-02) | Four-eyes check effective; duplicate check gap for instant payments keeps likelihood at 3 |
| RSK-PAY-002 *(Example)* | CTL-PAY-003 | 4 | 3 | 12 | High | Medium | No | Reduce (ACT-PAY-01) | Failover failed to meet impact tolerance in September 2026 |
| RSK-PAY-003 *(Example)* | CTL-PAY-004, CTL-PAY-006 | 4 | 1 | 4 | Low | Low | Yes | Accept and monitor | Both controls effective; no missed matches in period |
| RSK-PAY-004 *(Example)* | CTL-PAY-007, CTL-PAY-008 | 2 | 4 | 8 | Medium | Medium | Yes | Accept and monitor | Losses per event reduced by holds; frequency remains high |
| RSK-PAY-005 *(Example)* | CTL-PAY-001, CTL-PAY-005 | 4 | 1 | 4 | Medium (impact 4 floor) | Low | No | Reduce (ACT-PAY-03) | Late log reviews weaken detection; see note below |
| RSK-PAY-006 *(Example)* | CTL-PAY-009, CTL-PAY-003 | 4 | 2 | 8 | Medium | Medium | Yes | Accept and monitor | Exit plan tested; failover weakness tracked under RSK-PAY-002 |
| RSK-PAY-007 *(Example)* | CTL-PAY-010 | 3 | 1 | 3 | Low | Medium | Yes | Accept | Secondary site tested |
| RSK-PAY-008 *(Example)* | CTL-PAY-011 | 2 | 2 | 4 | Low | Medium | Yes | Accept | Automated rostering control |

Note on RSK-PAY-005: the score of 4 would normally map to Low, but the bank applies a floor of Medium to internal fraud risks with residual impact 4 or more while a detective control is only partially effective. Record any such override explicitly, with the rule that justifies it, so aggregation reports do not silently differ from the matrix.

```mermaid
flowchart LR
  I["Inherent rating"] --> C["Control effectiveness evidence"]
  C --> R["Residual rating"]
  R --> A{"Within unit appetite?"}
  A -- "Yes" --> M["Accept and monitor through KRIs"]
  A -- "No" --> T["Treatment: reduce, transfer or avoid"]
  T --> P["Action plan with owner and date"]
  P --> E{"Risk acceptance needed meanwhile?"}
  E -- "Yes" --> X["Formal risk acceptance by authorised approver"]
  E -- "No" --> F["Track to closure"]
```

Two risks are outside appetite (RSK-PAY-002 and RSK-PAY-005). Both require an action plan and a temporary risk acceptance signed by the authority defined in the operational risk policy until the action is complete.

## 8. Issues and action plans

<!-- Guidance: Record each control gap as an issue and each remediation as an action with owner, date and success measure. Questions to answer: Will the action move the residual rating back within appetite? How will closure be evidenced? Pitfall: actions such as "raise awareness" with no measurable outcome. -->

| Issue ID | Issue | Linked risk and control | Action ID | Action | Owner | Due date | Success measure | Status |
|---|---|---|---|---|---|---|---|---|
| ISS-PAY-01 *(Example)* | Failover does not meet the 4-hour impact tolerance of the domestic payment service (including card push payments) | RSK-PAY-002, CTL-PAY-003 | ACT-PAY-01 | Move to active-active hosting across two regions and repeat the failover test | [@payments-it-lead] | 2027-03-31 | Failover test completes in under 2 hours; RAS-OPR-02 back to zero events in a rolling 12 months | In progress |
| ISS-PAY-02 *(Example)* | Duplicate payment rule does not cover SEPA instant | RSK-PAY-001, CTL-PAY-002 | ACT-PAY-02 | Extend rule to instant payments | [@payments-product-owner] | 2026-12-15 | Rule live for SEPA instant (bulk files already covered by ACT-PAY-05); zero duplicate payments in any channel in the following quarter | Planned |
| ISS-PAY-03 *(Example)* | Weekly repair queue log reviews performed late | RSK-PAY-005, CTL-PAY-005 | ACT-PAY-03 | Automate the log review with exception alerts and add a deputy reviewer | [@team-lead-repair] | 2026-12-31 | 13 of 13 reviews on time in Q1 2027 | Planned |
| ISS-PAY-04 *(Example)* | Repair rate KRI amber for two months | RSK-PAY-001 | ACT-PAY-04 | Fix the top three validation causes of repairs found in the root-cause sample | [@team-lead-initiation] | 2027-01-31 | KRI-OPR-001 at or below 1.5% for two consecutive months | In progress |

Track actions in the bank's issue management system together with audit and KRI actions. When an action is closed, the second line checks the evidence and, where relevant, the control is retested before the residual rating is lowered.

## 9. KRI mapping

<!-- Guidance: Map each material risk to the KRIs that warn of it, and propose new KRIs where none exists. Questions to answer: Which risks rated High or Very high inherent have no KRI? Pitfall: mapping a KRI to a risk because it is available, not because it predicts that risk. -->

KRIs are defined in the KRI Framework Specification (`finance/kri-framework-spec`). The mapping below shows which indicators warn of each risk and their status at the data cut-off of 2026-09-30.

| Risk ID | KRI ID | KRI | Status at cut-off | Comment |
|---|---|---|---|---|
| RSK-PAY-001 | KRI-OPR-001 | Payment repair rate | Amber (1.9%) | Drives ACT-PAY-04 |
| RSK-PAY-001 | KRI-OPR-005 | Overdue high-rated actions | Amber (6.3%) | Group-level KRI; unit share tracked locally |
| RSK-PAY-002 | KRI-OPR-002 | Unplanned downtime of critical systems | Red (340 minutes) | 300-minute outage on 2026-09-12 plus 40 minutes of other downtime; linked to ISS-PAY-01 |
| RSK-PAY-002 | KRI-ICT-003 | Overdue critical security patches | Green (0) | Supports platform stability |
| RSK-PAY-003 | Proposed KCI | Share of sanctions alert QA samples with errors | Not yet measured | Propose to compliance as a new KCI |
| RSK-PAY-004 | KRI-OPR-010 | External fraud losses on payments | Green (EUR 180 thousand) | Monitor trend after scheme changes |
| RSK-PAY-005 | KRI-OPR-001 | Payment repair rate | Amber (1.9%) | Higher repair volumes increase opportunity for diversion |
| RSK-PAY-006 | KRI-ICT-004 | Overdue exit plan tests for critical ICT providers | Green (0) | Exit plan tested 2026-06 |
| RSK-PAY-007 | None | No KRI proposed | Not applicable | Low residual; covered by continuity testing |
| RSK-PAY-008 | KRI-PPL-009 | Turnover in critical roles | Amber (9.5%) | Fatigue and turnover reinforce each other |

Every risk with an inherent rating of High or Very high has at least one KRI, except RSK-PAY-003, for which a new key control indicator is proposed above.

## 10. Loss events, incidents and external events

<!-- Guidance: Test the ratings against what actually happened, here and elsewhere. Questions to answer: Do internal losses in the period fit the residual ratings? Have peer or industry events revealed a risk the unit has not rated? Pitfall: a Low residual rating for a risk that caused a loss in the same period, with no explanation. -->

Loss and incident data challenge the self-assessment. If a risk rated Low produced a material loss, either the rating or the loss classification is wrong. Losses are recorded and classified in the Operational Loss Event Report (`finance/operational-loss-event-report`); ICT incidents classified as major under DORA are also reported under the bank's incident management process.

| Event ID | Date | Description | Basel event type | Gross loss (EUR) | Recoveries (EUR) | Net loss (EUR) | Linked risk | Consistent with rating? |
|---|---|---|---|---|---|---|---|---|
| OLE-2026-031 *(Example)* | 2026-09-12 | Payments hub failover exceeded impact tolerance; compensation and scheme penalties | Business disruption and system failures | 520,000 | 70,000 | 450,000 | RSK-PAY-002 | Yes: residual High |
| OLE-2026-018 *(Example)* | 2026-05-20 | Duplicate SEPA instant payments after a repair batch | Execution, delivery and process management | 310,000 | 245,000 | 65,000 | RSK-PAY-001 | Yes: confirms ISS-PAY-02 |
| OLE-2026-014 *(Example)* | 2026-06-12 | Bulk salary batch executed twice after a faulty release (412 payments) | Business disruption and system failures | 1,304,500 | 1,092,000 | 212,500 | RSK-PAY-001 | Partly: duplicate-check gap for bulk files confirmed (CTL-PAY-002, fixed by ACT-PAY-05); gross severity shows residual impact 3 relies on recoveries |
| OLE-2026-0xx series *(Example)* | 2026 year to date | Authorised push payment fraud reimbursements, 41 events | External fraud | 1,020,000 | 135,000 | 885,000 | RSK-PAY-004 | Yes: frequent, low severity per event |

Net losses in the table total 450,000 + 65,000 + 212,500 + 885,000 = EUR 1,612,500, within the EUR 2.0 million allocation to the payments unit under RAS-OPR-01 (81% used by 2026-09-30, so the allocation would be exceeded at the same loss rate before year end: 1,612,500 / 9 x 12 = EUR 2,150,000). Each net figure equals gross less recoveries: 520,000 minus 70,000, 310,000 minus 245,000, 1,304,500 minus 1,092,000, and 1,020,000 minus 135,000. The operational risk function reported this run rate to the Executive Risk Committee with the September KRI pack. The full record of OLE-2026-014 is the worked example in the Operational Loss Event Report (`finance/operational-loss-event-report`).

External events reviewed: record relevant public loss events or supervisory publications from peers and state whether they reveal a gap. *Example:* a peer bank's outage caused by a failed cloud region migration led the unit to confirm that RSK-PAY-006 covers region-level failure as well as provider exit.

## 11. Operational resilience and third-party dependencies

<!-- Guidance: Connect the RCSA to important business services, impact tolerances and third parties. Questions to answer: Which important business services depend on this unit? Which ICT third parties support them, and are they in the DORA register? Pitfall: an RCSA that treats an outage only as a financial loss and ignores impact tolerance. -->

The Basel Committee Principles for Operational Resilience (March 2021) group expectations under seven headings: governance; operational risk management; business continuity planning and testing; mapping of interconnections and interdependencies; third-party dependency management; incident management; and resilient ICT including cyber security. This section records the RCSA evidence for the headings that apply at unit level. Under DORA, the ICT risk management framework (Articles 5 to 16), ICT-related incident management and reporting (Articles 17 to 23) and the management of ICT third-party risk (Articles 28 to 30) set the legal requirements for EU financial entities; check the consolidated text and the related technical standards.

| Important business service | Impact tolerance (*Example*) | Supporting processes | Critical ICT third parties | DORA register reference | Last scenario test | Result |
|---|---|---|---|---|---|---|
| Make a domestic payment | 4 hours maximum disruption | PRC-PAY-01 to PRC-PAY-04, PRC-PAY-06 | Cloud hosting provider; scheme connectivity provider | [Contractual arrangement reference from B_02.01] | 2026-09-12 (live event) | Exceeded by 1 hour |
| Make an instant payment | 30 minutes maximum disruption | PRC-PAY-01, PRC-PAY-02, PRC-PAY-04, PRC-PAY-06 | Cloud hosting provider; scheme connectivity provider | [Reference] | 2026-04 (planned test) | Within tolerance |
| Receive a payment | 8 hours maximum disruption | PRC-PAY-04, PRC-PAY-05 | Scheme connectivity provider | [Reference] | 2026-04 (planned test) | Within tolerance |

Keep the provider names, contract references and criticality assessments identical to the DORA Register of Information (`compliance/dora-ict-third-party-register`). Differences between the two are a reportable data issue. Where a third party supports a function the bank has assessed as critical or important, check that the contract includes the provisions the bank's ICT third-party policy requires, that the exit plan has been tested (CTL-PAY-009) and that concentration on a single provider has been assessed.

## 12. Second-line challenge and sign-off

<!-- Guidance: Record the challenge the operational risk function made and how it was resolved. Questions to answer: Which ratings changed after challenge? Which disagreements remain, and who decides? Pitfall: a challenge section that says "no comments", which supervisors and auditors read as no challenge. -->

The second line challenges the RCSA for completeness (all event types and processes considered), consistency (ratings in line with similar units and with loss and KRI data) and evidence (control ratings supported by tests). Unresolved disagreements are escalated to the Head of Operational Risk, who decides and records the decision.

| Challenge ID | Topic | Challenge | First-line response | Outcome |
|---|---|---|---|---|
| CHL-PAY-01 *(Example)* | RSK-PAY-002 residual | First line proposed Medium because a migration is planned | Agreed that planned actions do not reduce current residual risk | Rating raised to High |
| CHL-PAY-02 *(Example)* | RSK-PAY-005 residual | Score 4 maps to Low, but the detective control is partially effective | Accepted floor rule | Rating Medium with override recorded |
| CHL-PAY-03 *(Example)* | RSK-PAY-003 KRI coverage | No leading indicator for screening quality | Agreed to propose a KCI | New KCI proposal sent to compliance |
| CHL-PAY-04 *(Example)* | Completeness | Card push payments not mapped to an important business service | Added to "Make a domestic payment" service scope | Section 11 updated |

Sign-off confirms that the unit head accepts the ratings and actions, that the second line has completed its challenge, and that the results have been loaded into the risk register and aggregated in the operational risk profile reported against the Risk Appetite Statement. The next RCSA is due in [12] months, or earlier after a trigger: a material loss or incident, a major change in systems or processes, a new product, a reorganisation, or a red KRI that remains red for two periods.

## 13. Glossary and references

<!-- Guidance: Define the terms used in this RCSA, in the bank's own words. -->

### 13.1 Glossary

| Term | Definition used in this document |
|---|---|
| RCSA | Risk and control self-assessment: a structured review by the first line of its risks and controls, challenged by the second line |
| Inherent risk | Exposure before the controls assessed in this RCSA |
| Residual risk | Exposure after the controls as they actually operate |
| Basel event type | One of the seven Level 1 categories used to classify operational risk events |
| Key control | A control on which the residual rating relies |
| Important business service | A service provided to external users whose disruption could harm customers, the bank or the market |
| Impact tolerance | The maximum disruption to an important business service the bank will tolerate |
| Risk acceptance | A formal, time-limited decision by an authorised approver to operate outside appetite while actions are completed |
| KRI, KCI | Key risk indicator, key control indicator |

### 13.2 References

- Basel Committee on Banking Supervision, Revisions to the Principles for the Sound Management of Operational Risk (March 2021) and Principles for Operational Resilience (March 2021), cited by name only.
- Basel operational risk event type taxonomy (Level 1 categories), cited by name only.
- Regulation (EU) 2022/2554 (DORA), Articles 5 to 16, 17 to 23 and 28 to 30, applicable from 17 January 2025, EUR-Lex.
- Regulation (EU) No 575/2013 (CRR) as amended by Regulation (EU) 2024/1623 (CRR3), operational risk own funds and loss data provisions, EUR-Lex.
- European Banking Authority, Guidelines on internal governance under Directive 2013/36/EU, EBA/GL/2021/05.
- Risk Assessment Methodology (`compliance/risk-methodology`) for the general scoring method.

## Standard and licence note

Structure aligned with the Basel Committee Revisions to the Principles for the Sound Management of Operational Risk (2021), the Basel Committee Principles for Operational Resilience (2021) and the Basel event type taxonomy, all cited by name only with no text reproduced. Based on public law where cited: Regulation (EU) 2022/2554 and Regulation (EU) No 575/2013 as amended (EUR-Lex). EBA guidelines are referenced with acknowledgement and no text is reproduced. All text, scales, risks, controls and figures are original and illustrative; they are not regulatory requirements. Fernhollow Bank and all figures are fictional. Check the current official version of each principle, guideline and regulation before use. Template licence: MIT.