## wpiea2025085-print-pdf

## Source details

**Canonical URL:** [wpiea2025085-print-pdf](https://www.imf.org/-/media/files/publications/wp/2025/english/wpiea2025085-print-pdf.pdf)

## Other formats

- [Markdown version](/-/media/files/publications/wp/2025/english/wpiea2025085-print-pdf.pdf.md)
- [Structured JSON version](/-/media/files/publications/wp/2025/english/wpiea2025085-print-pdf.pdf.json)

---

### Introduction
- Cybersecurity risk is a growing concern for macro-financial stability.
- Objective:
  - (i) to assess the quantitative impact on settlement and liquidity according to a range of risk metrics;
  - (ii) to strengthen cyber incident response and recovery, ecosystem resilience, and situational awareness with policy considerations;
  - (iii) to complement tabletop cyber exercise programs with quantitative assessments to support decision-making.
- Methodology:
  - Uses computer-based simulations (a payment and settlement systems simulator) to replicate key features of a payment system and simulate movement of actual payment transactions data (Annex 2).
  - Builds on earlier simulation analyses and stress testing studies of operational risks in payment networks (Annex 1).
- Scope:
  - Simulations model participant default, cyber-attacks, terrorist attacks, operational incidents, bank runs, collateral devaluation, supply chain attacks, and system or policy changes.
  - Quantifiable outcomes include settlement delays, settlement failures, queues, account liquidity positions at end-of-day, liquidity usage, and liquidity deterioration.
- Illustrative case: Finland; relevance extends to emerging market and developing economies and authorities with oversight or operational responsibilities for systemically important FMIs.

### Framework for Simulating Stress in Cyber Exercises
- Three main steps (Figure 1):
  - Step 1: Designing Scenarios
  - Step 2: Simulating Stress
  - Step 3: Assessing Preparedness
- Design principles:
  - Scenarios should address an appropriately broad scope, including extreme but plausible cyber-attacks, and challenge assumptions of response, resumption, and recovery practices, governance arrangements and communication plans (CPMI-IOSCO Cyber Guidance).
  - Use cyber threat intelligence and cyber threat modelling to imitate unique characteristics of cyber threats and test unfamiliar scenarios.

### Cyber Stress Scenarios (summary of five scenarios)
- Scenario 1. Baseline
  - LVPS operates under normal conditions; banks have access to an unaltered amount of liquidity provided by the central bank.
- Scenario 2. Bank
  - A major bank stops submission of outgoing payments for four hours in the afternoon; affected bank is largest participant by market share of transaction values.
  - Other banks stop outgoing payments to the affected bank two hours before closing time. Notification delayed to end-of-day.
  - Contingency measures lack manual paper-based procedures for processing time-critical transactions.
  - Assumptions include compromised security controls, deficient defense-in-depth, unusual network traffic and high authentication failures.
- Scenario 3. CSP
  - A CSP serving the five largest banks is attacked; five largest banks unable to submit payment instructions for four hours in the afternoon before closing time.
  - Notification delayed to end-of-day. Contingency measures lack manual paper-based procedures.
  - Assumptions include server-side application/database breach, ransomware used to steal credentials and manipulate data, lack of regular audits of the CSP.
- Scenario 4. LVPS
  - Central bank owned and operated LVPS experiences an outage for 10-hours, including at primary and secondary sites; all banks unable to submit payment instructions 10-hours after opening time.
  - Contingency measures include manual paper-based processing for high priority and time-critical transactions between opening and closing time.
  - Notification delayed to end-of-day. Affected system resumes after closing time and operational hours extended until midnight to continue settlements.
  - Assumptions include an insider threat and deficient termination of system access.
- Scenario 5. FX
  - Privately-operated FX settlement system suffers a data breach affecting confidentiality and integrity; outage for five hours (7:00 am to 12:00 pm Central European Time).
  - All banks unable to submit or receive payment instructions during the window for settlement and funding.
  - Notification delayed to end-of-day. Contingency measures lack manual paper-based procedures.
  - Assumption: Ransomware used to steal credentials and manipulate data.

### Data used and simulation setup
- Data source: TARGET Services data for February 2024.
- Data components: all payments and transfers, account balances, credit line changes, bilateral limits and reservations related to the Central Liquidity Management (CLM) and Real-Time Gross Settlement (RTGS) components.
- Volumes:
  - For a typical business day, there could be over 400,000 transactions.
  - One month can amount to more than 8.4 million transactions.
  - In February 2024, there were 8.76 million transactions.
- Simulator: Bank of Finland’s Payment and Settlement System Simulator (BOF-PSS).
- Replication: Tailored algorithms for the Eurosystem replicate TARGET Services (CLM and RTGS).
- Performance optimizations:
  - Scenario 1 (Baseline) run time with stress tester improved from around six hours to under two hours.
  - One-month benchmark simulation time improved from around three and a half hours to one hour.
- Scenario-specific data adjustments implemented via SQL-filters and automated stress tester (exact timing and removal/postponement rules per scenario):
  - 1. Baseline: Not applicable.
  - 2. Bank: All payments introduced by Bank after 2:00 p.m. and all payments sent towards Bank introduced after 4:00 pm are removed. Automated payments remain.
  - 3. CSP: Outgoing payments of the five biggest banks introduced after 2:00 p.m. are removed. Incoming payments remain.
  - 4. LVPS: Introduction times of payments and transfers between 2:30 a.m. and 12:30 p.m. postponed until 12:30 p.m.; earliest debit times during that period postponed to 12:30 p.m.; latest debit times between 2:30 a.m. and 12:30 p.m. postponed until 1:30 p.m.
  - 5. FX: Introduction times between 7:00 a.m. and 12:00 p.m. involving the FX system postponed until 12:00 p.m.; earliest debit times postponed until 12:30 p.m.; latest debit times between 7:00 a.m. and 12:00 p.m. postponed until 1 p.m.

### Risk metrics (definitions preserved verbatim)
- Total value of unsettled payments: The sum of the values of the unsettled transactions in a simulation or scenario (direct scenario effect + systemic or second-round effects).
- Total volume of unsettled payments: The count of the unsettled transactions in the simulation or scenario (systemic or second-round effects).
- Average queue value: The average time weighted value of queue balance.
- Delay indicator: A relative indicator ranging from 0 to 1. If no transactions are queued the value is 0; if all transactions are queued the maximum time (from entry time till the end of the day) the value is 1. Calculated as the time weighted queue value for each transaction divided by the maximum theoretical time the payment could have delayed in queue.
- Maximum liquidity deterioration 1/: The needed extra liquidity to keep end of day (EOD) balance in the scenario unchanged when other participants are not able to compensate and cannot send all of their payments. Maximum Liquidity Deterioration = End of day balance in benchmark simulation - End of day balance in scenario + unsettled in scenario (systemic) - Unsettled in benchmark (systemic). If the value is negative, it is an improvement and it is rounded to 0.
- Minimum liquidity deterioration: The needed extra liquidity to keep end of day (EOD) balance in the scenario unchanged when other participants are able to compensate and still send their unsettled payments. Minimum Liquidity Deterioration = End of day balance in benchmark simulation - End of day balance in scenario + unsettled in scenario (systemic) - Unsettled in benchmark - incoming unsettled (systemic, not direct) in scenario. If the value is negative, it is an improvement and it is rounded to 0.
- Note: Intraday throughput is an additional risk metric that could be used but is not within the scope of this study.

### Simulation results — key statistics (averaged daily figures)
- Scenario 1. Baseline
  - Value of unsettled payments (€ million): 0.20
  - Volume of unsettled payments (number of transactions): 0.05
  - Queue value (€ million): 0.49
  - Delay indicator: 0.0039
  - Liquidity deterioration (Min) (€ million): 0.00
  - Liquidity deterioration (Max) (€ million): 0.00
- Scenario 2. Bank
  - Value of unsettled payments (€ million): 190.61
  - Volume of unsettled payments (number of transactions): 51.70
  - Queue value (€ million): 0.48
  - Delay indicator: 0.0039
  - Liquidity deterioration (Min) (€ million): 1.80
  - Liquidity deterioration (Max) (€ million): 23.12
- Scenario 3. CSP
  - Value of unsettled payments (€ million): 2,676.54
  - Volume of unsettled payments (number of transactions): 295.95
  - Queue value (€ million): 0.47
  - Delay indicator: 0.0048
  - Liquidity deterioration (Min) (€ million): 0.00
  - Liquidity deterioration (Max) (€ million): 23.09
- Scenario 4. LVPS
  - Value of unsettled payments (€ million): 0.20
  - Volume of unsettled payments (number of transactions): 0.05
  - Queue value (€ million): 0.48
  - Delay indicator: 0.0039
  - Liquidity deterioration (Min) (€ million): 0.00
  - Liquidity deterioration (Max) (€ million): 0.00
- Scenario 5. FX (aggregate observations)
  - Reported numeric values from the source: 0.42, 0.10, 0.68, 0.0039, 0.20, 0.20
  - Second-round contagion in Scenario 5 (FX) on one day: around 4 million euros.
  - Average unsettled-payment value reported higher (0.42 instead of 0.2) due to the one-day FX exception.

### Key observations and analytic findings
- Confidentiality constraints limit disclosure of participant-level detail in publication.
- Scenarios removing outgoing payments (Scenarios 2 and 3) produce substantial increases in unsettled value and volume relative to Baseline; Scenario 3 (CSP) shows the largest unsettled value and volume.
- Queue values and delay indicators remain of similar order across Baseline, Bank, CSP, and LVPS scenarios; unsettled values and liquidity deterioration metrics reveal the scale of liquidity impact.
- Liquidity deterioration measures provide a plausible interval for needed extra liquidity at participant level:
  - Scenario 2 (Bank): Min 1.80, Max 23.12.
  - Scenario 3 (CSP): Max 23.09, Min 0.00 (sensitivity to assumptions about other participants bringing in liquidity).
- The reported unsettled-payment indicators show practically no second-round effects; almost all observed effects are direct effects related to the scenarios.
- Variance of daily aggregated liquidity deteriorations is larger for Scenario 2 (Bank) than for Scenario 3 (CSP); liquidity deteriorations are slightly larger but more consistent for Scenario 2 (Bank).
- Combining lack of second-round effects with observed end-of-day liquidity deteriorations suggests account liquidity was sufficient to absorb liquidity risk while settling other due payments.

### Queueing, liquidity-saving mechanisms, and recovery dynamics
- Queue and delay indicators show fast recovery in Scenarios 4 (LVPS) and 5 (FX) because initially delayed payments were introduced to the settlement process at the end of the event in the simulations.
- The simulator follows production-system algorithmic routines without manual intervention; results indicate theoretical possibility of near complete and fast recovery.
- TARGET’s RTGS hybrid module (queueing and liquidity saving mechanisms) enables frequent queue releasing and offsets, contributing to positive simulation outcomes.
- Assumption: ancillary system cycles can be postponed freely until the end of anomalies and run after without delays.
- Queue release mechanisms allow liquidity provision transfers related to ancillary system settlements and subsequent batch processes and queue releases to occur, enabling efficient resumption when automation is at a high level.

### Operational resilience, limitations, and scenario severity
- Simulations assumed outages of 4 hours (and scenarios up to 4 to 10 hours); real incidents could involve longer outages, including multiple days or weeks, complicating restoration and end-of-day settlement.
- Scenarios 2 (Bank) and 3 (CSP) did not significantly pressurize liquidity-saving mechanisms because direct effects removed payments close to end of day and indicators did not show second-round pileups.
- Low and quasi-immutable delay and queue indicators make a shift from entry settlement to reliance on liquidity-saving mechanisms unlikely under the simulated incidents.

### Practical policy questions raised
- What conditions would necessitate extension of operational hours of a payment system, and for how long?
- What alternative arrangements (for example, manual paper-based procedures) exist to process time-critical transactions in extreme circumstances?
- How many staff would be required to manually process such transactions?
- What should be done if settlement cycles of ancillary systems linked to the payment system fail to operate normally after a cyber-attack?
- When should a temporary suspension from the payment system be invoked for a bank that experienced a cyber-attack?
- What if end-of-day settlement cannot be achieved and unsettled payments remain until the next business day or week?
- Should central banks consider queuing and liquidity-saving mechanisms as part of RTGS modernization?
- How would outcomes differ if a “pure” RTGS operated with prefunding and without access to central bank intraday liquidity facilities?
- How would collateral deterioration, intraday liquidity shortages, foreign exchange settlement risk from inter-day exposures, and the value of unsettled FX transactions relative to available liquid capital affect outcomes?

### Preparedness and recommended frameworks
- Financial entities should ensure they have a comprehensive Cyber Incident Response and Recovery (CIRR) framework to:
  - execute appropriate activities in reaction to detected or reported cyber incidents;
  - restore systems, capabilities, and services impaired by a cyber incident.
- Effective CIRR components (Box 1):
  - Governance: clear allocation of responsibilities, decision-making framework, coordination team.
  - Planning and preparation: policies, plans and playbooks, communication strategies, inclusion of severe but plausible scenarios, regular testing.
  - Analysis: forensic and incident analysis capabilities.
  - Mitigation: containment, business continuity, isolation, eradication.
  - Restoration and recovery: prioritize by criticality, use metrics like RTO and RPO.
  - Coordination and communication: escalation protocols, stakeholder updates, pre-defined update frequencies.
  - Improvement: lessons learnt from exercises and incidents.
- For Scenarios 4 (LVPS) and 5 (FX), a key consideration is resumption of services within two hours following a cyber incident (CPMI-IOSCO Cyber Guidance resumption objective quoted in source).

### Steps for authorities — resilience of the ecosystem
- FMI cyber resilience should consider risks from and to participants, other FMIs, vendors, vendor products and service providers.
- Key principles for authorities:
  - (i) collective strategic planning and collaboration;
  - (ii) identification and mapping;
  - (iii) situational awareness;
  - (iv) cyber threat intelligence;
  - (v) information sharing;
  - (vi) incident reporting;
  - (vii) authorities’ response framework.
- Collective strategic planning and collaboration: ex-ante governance structures, MOUs, data sharing agreements, crisis management protocols and inclusion of regulated and unregulated critical service providers.
- Identification and mapping: develop a cyber mapping of interconnections to identify critical nodes and transmission channels; mapping requires consistent data submissions and collaboration.
- Situational awareness: robust threat intelligence, participation in information-sharing arrangements, effective incident reporting.
- Cyber threat intelligence and information sharing: require processes to gather, analyze and exchange indicators of compromise (IOCs), TTPs and other threat information; authorities should catalyze participation in information-sharing groups.
- Incident reporting: standardized templates, safe channels, clear thresholds and taxonomies; timely notification and updates to authorities are critical.
- Authorities’ Response Framework (ARF):
  - Jointly owned by senior representation from all authorities.
  - ARF levels: “Monitor”, “Engage”, “Escalate”.
  - ARF playbook components: thresholds, invocation processes, assessment and escalation model, response plan and decision-making process.
  - Regular market-wide exercises recommended.

### Extensions and future scenario considerations
- Forward-looking scenarios to simulate:
  - more extreme cyber-attack scenarios;
  - lengthier outages (multiple days or weeks);
  - liquidity constraints (collateral deterioration);
  - net settlements instead of RTGS;
  - unauthorized modification of transactions;
  - non-substitutability of settlement services;
  - inter-day exposures due to time zone differences in FX settlements;
  - cross-sectoral impacts (telecommunications, energy suppliers).
- Internal analyses could focus on participant-level impacts to identify vulnerabilities, critical participants and counterparty exposures; confidentiality may limit public presentation.

### Annex II — Bank of Finland Payment and Settlement System Simulator (BoF-PSS3) overview
- Purpose: studying liquidity needs and risks in payment and settlement systems; simulating special situations difficult or impossible to test in a real environment.
- Architecture:
  - GUI web-application (html and javascript);
  - Back-end server installable on a regular windows PC;
  - Database storage (development uses MariaDB).
- Input data (minimum required: transaction data):
  - Account balances (PART)
  - Transactions (TRAN)
  - Intraday credit limits (ICCL)
  - Bilateral and multilateral limits (BLIM)
  - Events information (EVNT)
  - Reservations (RSRV) — tailored systems only
- Data handling:
  - All input data must be in CSV format; tools provided to import and validate data.
  - Older Excel versions handle about 65,000 rows; Excel 2010 can handle ~1 000 000 rows.
- Execution and outputs:
  - Records all events and bookings; premade reports and statistics; logs for simulation runs.
  - Output database tables contain booking order and balances; users often export CSV for further analysis.
- Supported system structures and features:
  - RTGS, DNS, CNS, Hybrid, LVPS and Retail, DvP, PvP, bilateral/multilateral limits, multicurrency, multisystem, securities settlement systems, central counterparty.
- Focal output factors: counterparty risk, liquidity consumption, settlement volumes, gridlock situations, queuing time.
- Use cases: identify and quantify risks, scenario analysis, stress testing, feature prototyping, system design, academic research.
- Simulator described as deterministic model with stochastic input; scenarios generated by affecting input data and system setups.

*Source: Authors and Bank of Finland.*

### References .............................................................................................................

### Using Simulations for Cyber Stress Testing Exercises

### Introduction
- Cybersecurity risk is a growing concern for macro-financial stability.
- Objective of the paper:
  - (i) to assess the quantitative impact on settlement and liquidity according to a range of risk metrics;
  - (ii) to strengthen cyber incident response and recovery, ecosystem resilience, and situational awareness with policy considerations;
  - (iii) to complement tabletop cyber exercise programs with quantitative assessments to support decision-making.
- Methodology:
  - Uses computer-based simulations (a payment and settlement systems simulator) to replicate key features of a payment system and simulate movement of actual payment transactions data (Annex 2).
  - Builds on earlier simulation analyses and stress testing studies of operational risks in payment networks (Annex 1).
- Scope and relevance:
  - Simulations can model participant default, cyber-attacks, terrorist attacks, operational incidents, bank runs, collateral devaluation, supply chain attacks, and system or policy changes.
  - Quantifiable outcomes include settlement delays, settlement failures, queues, account liquidity positions at end-of-day, liquidity usage, and liquidity deterioration.
  - Lessons are presented with Finland as an illustrative case but are relevant for emerging market and developing economies and authorities with oversight or operational responsibilities for systemically important FMIs.

### Framework for Simulating Stress in Cyber Exercises
- Framework organized into three main steps (Figure 1):
  - Step 1: Designing Scenarios
  - Step 2: Simulating Stress
  - Step 3: Assessing Preparedness
- Design principles:
  - Scenarios should address an appropriately broad scope, including simulation of extreme but plausible cyber-attacks, and be designed to challenge assumptions of response, resumption, and recovery practices, including governance arrangements and communication plans (CPMI-IOSCO Cyber Guidance).
  - Use cyber threat intelligence and cyber threat modelling to imitate unique characteristics of cyber threats and test unfamiliar scenarios to achieve stronger operational resilience.

### Cyber Stress Scenarios (five scenarios)
- Scenario 1. Ecosystem operates in normal conditions without incidents (baseline).
  - Overview: LVPS operates under normal conditions; banks have access to an unaltered amount of liquidity provided by the central bank.
- Scenario 2. Systemically important financial institution is targeted by cyber criminals.
  - Overview: A major bank stops submission of outgoing payments for four hours in the afternoon; affected bank is largest participant by market share of transaction values in the LVPS.
  - Additional details: Other banks stop outgoing payments to the affected bank two hours before the closing time. Notification delayed to end-of-day. Contingency measures lack manual paper-based procedures for processing time-critical transactions.
  - Assumptions: Security controls compromised; defense-in-depth deficient; anomalies include unusual network traffic and high authentication failures.
- Scenario 3. Critical service provider (CSP) to financial sector is hit and experiences an outage.
  - Overview: A CSP serving the five largest banks is attacked; five largest banks unable to submit payment instructions for four hours in the afternoon before closing time.
  - Additional details: Notification delayed to end-of-day. Contingency measures lack manual paper-based procedures.
  - Assumptions: Server-side application/database breach; ransomware used to steal credentials and manipulate data; lack of regular audits of the CSP.
- Scenario 4. Central bank compromised by an insider threat.
  - Overview: Central bank owned and operated LVPS experiences an outage for 10-hours, including at primary and secondary sites; all banks unable to submit payment instructions 10-hours after opening time.
  - Additional details: Notification delayed to end-of-day. Contingency measures include manual paper-based processing for high priority and time-critical transactions between opening and closing time. Affected system resumes after closing time and operational hours are extended until midnight to continue settlements.
  - Assumptions: Insider threat due to a former system administrator with grudges; deficient termination of system access.
- Scenario 5. Systemically important financial infrastructure faces an advanced persistent threat.
  - Overview: A privately-operated FX settlement system suffers a data breach affecting confidentiality and integrity of payment instructions; outage for five hours (7:00 am to 12:00 pm Central European Time) affecting interbank payments in the LVPS; all banks unable to submit or receive payment instructions during the window for settlement and funding of the system.
  - Additional details: Notification delayed to end-of-day. Contingency measures lack manual paper-based procedures.
  - Assumption: Ransomware used to steal credentials and manipulate data; FX settlement system critical due to common reliance by all banks.

### Key findings and lessons from simulation exercises
- Timely systems recovery and effective queuing and liquidity risk management generally serve as preemptive actions to reinforce cyber resilience.
- Financial sector entities with a mature CIRR (Cyber Incident Response and Recovery) framework are better placed to respond and recover, reducing systemic risk.
- An adequately wide range of stress scenarios is useful to industry risk management and to authorities’ surveillance of safety, soundness, and financial stability.
- The simulation approach remains at an early stage but has potential to complement existing testing arrangements.

### Methodological notes and references within text
- The simulation methodology was pioneered at the Bank of Finland; the Bank of Finland’s payment and settlement systems simulator is a key component and has been made publicly available to the central banking and academic community (subject to licensing from the Bank of Finland).
- The paper distinguishes scenario-based cyber stress testing from penetration testing and red team testing, and from other stress testing methods used to assess credit, liquidity, and operational risks.
- The Cyber Guidance (CPMI-IOSCO) recommends using cyber threat intelligence and modelling, and testing governance, communication, and recovery arrangements.
- Real-world incidents referenced include operational outages and cyber-attacks affecting payment systems, banks, central securities depositories, and stock exchanges.

*IMF Working Papers — Using Simulations for Cyber Stress Testing Exercises*

### 1. Baseline  Payment system operates under normal conditions.

### wpiea2025085-print-pdf - 1. Baseline  Payment system operates under normal conditions.

### Scenario descriptions
- Baseline
  - Payment system operates under normal conditions.
  - Banks have access to unaltered amount of liquidity.
- Bank
  - External denial of service attack affects payment controls.
  - Bank system outage of 4-hours.
  - Bank is unable to submit outgoing payments 4-hours in the afternoon before closing time.
  - All banks stop outgoing payments to affected bank 2-hours before closing time.
  - Bank is the largest participant in terms of market share of transaction values.
  - Notification of cybersecurity incident is delayed to end-of-day.
  - Contingency measures lack manual paper-based procedures for processing time-critical transactions in extreme circumstances.
  - The settlement cycles of ancillary systems that are linked to the large-value payment operate normally after anomalies.
- CSP
  - Attack exploits application server and affects confidentiality and integrity of payments.
  - CSP outage of 4-hours.
  - 5 largest banks are unable to submit payment instructions 4-hours in the afternoon before closing time.
  - CSP provides ICT services to the 5 largest banks in terms of market share of transaction values.
  - Notification of cybersecurity incident is delayed to end-of-day.
  - Contingency measures lack manual paper-based procedures for processing time-critical transactions in extreme circumstances.
  - The settlement cycles of ancillary systems that are linked to the large-value payment operate normally after anomalies.
- LVPS
  - Internal denial of service attack through insider threat affects access and data.
  - LVPS outage of 10-hours, including at the primary and secondary sites.
  - All banks are unable to submit payment instructions 10-hours after opening time.
  - Contingency measures include manual paper-based procedures for processing high priority and time-critical transactions in extreme circumstances between opening and closing time.
  - Notification of cybersecurity incident is delayed to end-of-day.
  - LVPS resumes after closing time and operational hours extended until midnight to continue settlements.
  - The settlement cycles of ancillary systems that are linked to the large-value payment operate normally after anomalies.
- FX
  - Attack exploits application server and affects confidentiality and integrity of payments.
  - FX settlement system outage of 5-hours (7:00 a.m. to12:00 p.m. Central European Time).
  - All banks are unable to submit to or receive payment instructions from the FX system during the window for settlement and funding.
  - Contingency measures lack manual paper-based procedures for processing time-critical transactions in extreme circumstances.
  - Notification of cybersecurity incident is delayed to end-of-day.
  - FX settlement system resumes after outage.
  - The settlement cycles of ancillary systems that are linked to the large-value payment operate normally after anomalies.

### Data used for simulations
- Data source: TARGET Services data for February 2024.
- Data components: all payments and transfers, account balances, credit line changes, bilateral limits and reservations related to the Central Liquidity Management (CLM) and Real-Time Gross Settlement (RTGS) components.
- Volume notes:
  - For a typical business day, there could be over 400,000 transactions.
  - One month can amount to more than 8.4 million transactions.
  - In February 2024, there were 8.76 million transactions.
- Reported results include only metrics related to the participants of TARGET Services that are accessing through the Bank of Finland.

### Methodology and simulation setup
- Simulator: Bank of Finland’s Payment and Settlement System Simulator (BOF-PSS).
- Replication: Tailored algorithms for the Eurosystem replicate TARGET Services (CLM and RTGS).
- Automated stress testing tool used to dynamically generate scenarios without recreating copies of input data.
- Performance optimizations achieved:
  - Scenario 1 (Baseline) run time with stress tester improved from around six hours to under two hours.
  - One-month benchmark simulation time improved from around three and a half hours to one hour.
- Scenario implementation: SQL-filters define modifications to input data; automated stress tester allows definition of affected participants and accounts; parallelization of simulations used to speed up runs.
- Data adjustments by scenario (as implemented in simulations):
  - 1. Baseline: Not applicable.
  - 2. Bank: All payments introduced by Bank after 2:00 p.m. and all payments sent towards Bank introduced after 4:00 pm are removed. Automated payments remain in the simulations.
  - 3. CSP: Outgoing payments of the five biggest banks introduced after 2:00 p.m. are removed from the simulations. Incoming payments remain in the simulations.
  - 4. LVPS: All introduction times of payments and transfers between 2:30 a.m. and 12:30 p.m. are postponed until 12:30 p.m. Earliest debit times during that period are also postponed until 12:30 p.m. Latest debit times occurring between 2:30 a.m. and 12:30 p.m. are postponed until 1:30 p.m. to give more time for settlement.
  - 5. FX: All introduction times of payments and transfers between 7:00 a.m. and 12:00 p.m., involving the FX settlement system, are postponed until 12:00 p.m. Earliest debit times during that period are postponed until 12:30 p.m. to allow the possibility for single transfers to be executed before batches. Latest debit times occurring between 7:00 a.m. and 12:00 p.m. are postponed until 1 p.m. to give 30 minutes time for settlement.

### Risk metrics (definitions used in analysis)
- Total value of unsettled payments:
  - The sum of the values of the unsettled transactions in a simulation or scenario (direct scenario effect + systemic or second-round effects).
- Total volume of unsettled payments:
  - The count of the unsettled transactions in the simulation or scenario (systemic or second-round effects).
- Average queue value:
  - The average time weighted value of queue balance.
- Delay indicator:
  - A relative indicator ranging from 0 to 1. If no transactions are queued the value is 0; if all transactions are queued the maximum time (from entry time till the end of the day) the value is 1. Calculated as the time weighted queue value for each transaction divided by the maximum theoretical time the payment could have delayed in queue.
- Maximum liquidity deterioration 1/:
  - The needed extra liquidity to keep end of day (EOD) balance in the scenario unchanged when other participants are not able to compensate and cannot send all of their payments.
  - Maximum Liquidity Deterioration = End of day balance in benchmark simulation - End of day balance in scenario + unsettled in scenario (systemic) - Unsettled in benchmark (systemic).
  - If the value is negative, it is an improvement and it is rounded to 0.
- Minimum liquidity deterioration:
  - The needed extra liquidity to keep end of day (EOD) balance in the scenario unchanged when other participants are able to compensate and still send their unsettled payments.
  - Minimum Liquidity Deterioration = End of day balance in benchmark simulation - End of day balance in scenario + unsettled in scenario (systemic) - Unsettled in benchmark - incoming unsettled (systemic, not direct) in scenario.
  - If the value is negative, it is an improvement and it is rounded to 0.
- Note: Intraday throughput is an additional risk metric that could be used but is not within the scope of this study.

### Simulation results — key statistics (averaged daily figures)
- Scenario 1. Baseline
  - Value of unsettled payments (€ million): 0.20
  - Volume of unsettled payments (number of transactions): 0.05
  - Queue value (€ million): 0.49
  - Delay indicator: 0.0039
  - Liquidity deterioration (Min) (€ million): 0.00
  - Liquidity deterioration (Max) (€ million): 0.00
- Scenario 2. Bank
  - Value of unsettled payments (€ million): 190.61
  - Volume of unsettled payments (number of transactions): 51.70
  - Queue value (€ million): 0.48
  - Delay indicator: 0.0039
  - Liquidity deterioration (Min) (€ million): 1.80
  - Liquidity deterioration (Max) (€ million): 23.12
- Scenario 3. CSP
  - Value of unsettled payments (€ million): 2,676.54
  - Volume of unsettled payments (number of transactions): 295.95
  - Queue value (€ million): 0.47
  - Delay indicator: 0.0048
  - Liquidity deterioration (Min) (€ million): 0.00
  - Liquidity deterioration (Max) (€ million): 23.09
- Scenario 4. LVPS
  - Value of unsettled payments (€ million): 0.20
  - Volume of unsettled payments (number of transactions): 0.05
  - Queue value (€ million): 0.48
  - Delay indicator: 0.0039
  - Liquidity deterioration (Min) (€ million): 0.00
  - Liquidity deterioration (Max) (€ million): 0.00

### Key observations and analytic findings
- Confidentiality constraints limit disclosure of participant-level detail in publication, though internal analyses can provide participant-level counterparty exposures.
- Scenarios that remove outgoing payments (Scenarios 2 and 3) produce substantial increases in unsettled value and volume relative to the Baseline, with Scenario 3 (CSP) showing the largest unsettled value and volume.
- Queue values and delay indicators remain of similar order across Baseline, Bank, CSP, and LVPS scenarios, but unsettled values and liquidity deterioration metrics reveal the scale of liquidity impact.
- Liquidity deterioration measures provide a plausible interval for needed extra liquidity at participant level:
  - Scenario 2 (Bank) shows a non-zero minimum and elevated maximum liquidity deterioration (Min 1.80, Max 23.12).
  - Scenario 3 (CSP) shows a very large unsettled value with Liquidity deterioration (Max) 23.09 and Liquidity deterioration (Min) 0.00, indicating sensitivity to assumptions about other participants bringing in liquidity.

*Source: Authors.*

### 5. FX 0.42 0.10

### 5. FX 0.42 0.10

### Key findings from the simulations
- The reported unsettled-payment indicators show practically no second-round effects; almost all observed effects are direct effects related to the scenarios.
- The baseline value of 0.2 comes from one observation on one day present in all scenarios.
- Only Scenario 5 (FX) exhibits a second-round contagion effect, limited to one day, amounting to around 4 million euros and explaining the higher average unsettled-payment value of 0.42 instead of 0.2.
- Scenarios 4 (LVPS) and 5 (FX) do not materialize liquidity risks except for the one-day exceptional observation for Scenario 5 (FX).
- The variance of daily aggregated liquidity deteriorations is larger for Scenario 2 (Bank) than for Scenario 3 (CSP); liquidity deteriorations are slightly larger but more consistent for Scenario 2 (Bank).
- Combining lack of second-round effects with observed end-of-day liquidity deteriorations suggests account liquidity was sufficient to absorb liquidity risk while settling other due payments.

### Liquidity and unsettled payments: quantitative observations
- Reported numeric values from the source:
  - 0.42
  - 0.10
  - 0.68
  - 0.0039
  - 0.20
  - 0.20
- Second-round contagion in Scenario 5 (FX) on one day: around 4 million euros.
- Average number of unsettled payments:
  - Scenario 2 (Bank): 52 per day
  - Scenario 3 (CSP): 296 per day
- Scenarios 4 (LVPS) and 5 (FX): number of affected payments not deducible from Table 4 because payments were mainly delayed.

### Systemic transmission channels and scenario contrasts
- Three transmission channels through which a hit on a systemically important institution or third-party service provider could impact financial stability:
  - loss of confidence
  - lack of substitutability
  - interconnectedness
- Scenario contrasts:
  - Scenarios 2 (Bank) and 3 (CSP): most severe impact on settlement and liquidity risks due to definitive removal of affected payments, resulting in unsettled payments and liquidity deteriorations.
  - Scenarios 4 (LVPS) and 5 (FX): payments are delayed rather than removed, leaving possibility for settlements to resume; recovery close to 100 percent in unsettled payments and queue indicators (except the one-day FX exception).

### Queueing, liquidity-saving mechanisms, and recovery dynamics
- Queue and delay indicators show fast recovery in Scenarios 4 (LVPS) and 5 (FX); initially delayed payments were introduced to the settlement process at the end of the event in the simulations.
- The simulator follows production-system algorithmic routines without manual intervention; results indicate theoretical possibility of near complete and fast recovery.
- TARGET’s RTGS hybrid module (queueing and liquidity saving mechanisms) enables frequent queue releasing and offsets, contributing to positive simulation outcomes.
- Assumption in simulations: ancillary system cycles can be postponed freely until the end of anomalies and run after without delays; ancillary batches and payments remain in queues or are postponed to the end of the anomaly.
- Queue release mechanisms allow liquidity provision transfers related to ancillary system settlements and subsequent batch processes and queue releases to occur, enabling efficient resumption when automation is at a high level.

### Operational resilience, limitations, and scenario severity
- The simulations assumed outages of 4 hours (and scenarios up to 4 to 10 hours); cybersecurity incidents could involve longer outages, including multiple days or weeks, which would complicate restoration, resumption, and end-of-day settlement.
- Scenarios 2 (Bank) and 3 (CSP) did not significantly pressurize liquidity-saving mechanisms because direct effects removed payments close to end of day and indicators did not show second-round pileups.
- Low and quasi-immutable delay and queue indicators make a shift from entry settlement to reliance on liquidity-saving mechanisms unlikely under the simulated incidents.

### Practical questions and policy-relevant issues raised by the simulations
- What conditions would necessitate extension of operational hours of a payment system, and for how long?
- What alternative arrangements (for example, manual paper-based procedures) exist to process time-critical transactions in extreme circumstances?
- How many staff would be required to manually process such transactions?
- What should be done if settlement cycles of ancillary systems linked to the payment system fail to operate normally after a cyber-attack?
- When should a temporary suspension from the payment system be invoked for a bank that experienced a cyber-attack?
- What if end-of-day settlement cannot be achieved and unsettled payments remain until the next business day or week?
- Should central banks consider queuing and liquidity-saving mechanisms as part of RTGS modernization?
- How would risks differ if a “pure” RTGS operated with prefunding and without access to central bank intraday liquidity facilities?
- How would collateral deterioration, intraday liquidity shortages, foreign exchange settlement risk from inter-day exposures, and the value of unsettled FX transactions relative to available liquid capital affect outcomes?

### Preparedness and recommended frameworks
- Financial entities should ensure they have a comprehensive Cyber Incident Response and Recovery (CIRR) framework to:
  - execute appropriate activities in reaction to detected or reported cyber incidents
  - restore systems, capabilities, and services impaired by a cyber incident
- An effective CIRR framework should combine multiple components to prepare a financial entity to respond and recover before, during, and after an incident.

*iSource: Authors.*

### Box 1. Cyber Incident Response and Recovery Framework

### Box 1. Cyber Incident Response and Recovery Framework

### Governance
- The CIRR framework should be predicated on effective governance arrangements.
- An effective governance structure should:
  - define the decision-making framework with clear allocation of responsibilities and accountabilities;
  - ensure that the right internal and external stakeholders are engaged when a cyber incident occurs.
- It is useful to identify an individual or a team to coordinate actions and communications for a cyber incident, with clear reporting and escalation paths to management, in the event of an incident.

### Planning and preparation
- The CIRR framework should adequately set out planning and preparation activities so that the entity is prepared to respond before an incident occurs.
- Entities should establish policies, ex-ante, to prepare and plan for responding and recovering from a cyber incident.
  - Policies should include relevant high-level statements that drive development of more detailed plans and playbooks (e.g., classification and assessment of cyber incidents; a clear communication strategy and plan describing whom to inform within a given timeframe).
- Entities should establish and maintain plans and playbooks that provide well-defined, organized approaches for CIRR activities, including criteria for activating measures to expedite response time.
  - Develop an adequate number of plans and playbooks for specific purposes (e.g. response, recovery, contingency, communication) aligned with the overall cyber resilience strategy.
  - Plans and playbooks should cover the initial hours and days of a cyber incident.
  - Establish communication strategies for internal and external stakeholders, including a communications plan and pre-defined statements for different incident types.
  - Include severe but plausible cyber scenarios and stress tests based on high-impact, low-probability events (examples given: ransomware, Distributed Denial of Service (DDoS), system intrusion, data exfiltration, and system disruption).
  - Regularly assess scenarios and stress tests in business continuity tests and CIRR exercises.
- Annex 3 provides example questions for tabletop or crisis simulation exercises (listed in source).

### Analysis
- During an incident, entities should have capabilities to conduct analysis, including forensic analysis, to determine severity, impact, and root cause.
- Capacity to conduct such analysis during an incident improves ability to determine impact and drive appropriate CIRR activities.

### Mitigation
- Entities should be prepared to activate mitigation measures to prevent aggravation and eradicate cyber incidents in a timely manner.
- Mitigation can take four forms:
  1. containment — activate containment measures and technologies suited to each type of cyber incident to prevent further damage, including to connected entities;
  2. business continuity measures — invoke business continuity plans to maintain critical operations based on a pre-defined prioritization process;
  3. isolation — decide whether to shut down or isolate all or substantial parts of systems and networks versus maintaining business services operations;
  4. eradication — remove all materials and artefacts (i.e. malicious code and data) introduced by the attacker.
- The specific mitigation measure depends on the nature of the incident and requires timely judgement.

### Restoration and recovery
- The CIRR Framework should direct entities on how to restore and recover systems and services.
- Entities should give due consideration to recovering and restoring systems in a safe and timely manner, ensuring no risk is brought to the system as a whole.
- Prioritize recovery activities based on criticality of business operations, systems and supported services that drive security and restoration requirements.
  - Use metrics like RTO and Recovery Point Objective (RPO) or tiered criticality levels, decided in advance of an incident.
- Validate that restored assets are free of compromise, fully functional and meet security requirements before returning systems to normal business operations.

### Coordination and communication
- Across the life cycle of a cyber incident, entities need to coordinate with trusted stakeholders to ensure effective management and protect the wider ecosystem.
- Entities must escalate cyber incidents to relevant stakeholders (internal and outside) to avoid delays in addressing the incident.
- Timely escalation to decision-makers is essential for accelerating CIRR actions, including seeking approval to implement response and recovery plans.
- Inform relevant stakeholders about potential business disruptions, response and recovery activities taken, and plans to restore services.
  - Set frequency and intervals of updates in advance to manage expectations; this highlights the importance of playbooks and ex-ante testing.

### Improvement
- Incidents are inevitable; establish processes to improve CIRR activities and capabilities through lessons learnt from:
  - proactive tools (CIRR exercises, tests and drills); and
  - past cyber incidents.

### Financial entities: overall guidance
- Financial entities should have an agile and evolving CIRR framework that encompasses the components cited above.
- Each aspect interconnects to allow holistic preparedness.
- Scenarios in the paper demonstrate potential for cyber incidents to become systemic; entities with a mature CIRR framework are best placed to respond and recover, reducing system risk.
  - CIRR framework is particularly relevant in Scenarios 2 (Bank) and 3 (CSP).
- Prudential authorities should work closely with supervised entities to ensure an effective, comprehensive and mature CIRR framework is in place.
- For Scenarios 4 (LVPS) and 5 (FX), a key consideration is resumption of services within two hours following a cyber incident.
  - Cyber Guidance quote on resumption objective:
    - “An FMI should design and test its systems and processes to enable the safe resumption of critical operations within two hours of a disruption and to enable itself to complete settlement by the end of the day of the disruption, even in the case of extreme but plausible scenarios. Notwithstanding this capability to resume critical operations within two hours, when dealing with a disruption FMIs should exercise judgment in effecting resumption so that risks to itself or its ecosystem do not thereby escalate, whilst taking into account that completion of settlement by the end of day is crucial. FMIs should also plan for scenarios in which the resumption objective is not achieved. Although authorities recognize the challenges that FMIs face in achieving cyber resilience objectives, it is also recognized that current and emerging practices and technologies may serve as viable options to attain those objectives. Furthermore, the rationale for establishing this resumption objective stands irrespective of the challenge to achieve it.”

### Steps for authorities — resilience of the ecosystem
- An FMI’s cyber resilience framework should consider risks the FMI bears from and poses to its participants, other FMIs, vendors, vendor products and service providers — collectively referred to as an FMI’s ecosystem.
- A cyber incident can have material impact on the broader financial ecosystem due to interconnectedness; steps are required to strengthen overall ecosystem resilience.
- Authorities should consider these key principles when strengthening resilience:
  - (i) collective strategic planning and collaboration;
  - (ii) identification and mapping;
  - (iii) situational awareness;
  - (iv) cyber threat intelligence;
  - (v) information sharing;
  - (vi) incident reporting;
  - (vii) authorities’ response framework.

### Collective strategic planning and collaboration
- During a significant cyber incident that spreads throughout the system, clearly defined arrangements between relevant stakeholders (public and private) are essential.
- Develop ex-ante collective governance structures, a strategy for managing a systemic cyber incident, clear allocation of roles and responsibilities, and strong public-private partnerships.
- Operational measures may include memoranda of understanding (MOUs) and data sharing agreements.
- Strategy should cover crisis management protocols, incident response arrangements, public communication strategies to handle the crisis and minimize panic, and business continuity arrangements.
- Scenarios highlight:
  - the two most significant impacts arose from cyber incidents implicating a systemically important financial institution in Scenario 2 (Bank) and a CSP in Scenario 3.
  - the CSP in Scenario 3 is likely to sit outside the regulatory perimeter in most jurisdictions, underscoring need to include both regulated and unregulated entities in strategic planning.
- Authorities should develop robust ex-ante engagement processes with financial institutions and their service providers, with clearly defined roles and responsibilities.

### Identification and mapping
- FMIs have a broad range of participants and external stakeholders; the weakest link can trigger propagation and cause financial instability.
- Developing a cyber mapping of interconnections allows identification of critical nodes and transmission channels.
- Analyze financial, operational and technological interconnections to identify potential systemic risks from interconnectedness and concentrations.
- Mapping steps for authorities:
  - identify stakeholders in the ecosystem;
  - determine operational connections;
  - develop a mapping of the system;
  - analyze the map to identify critical nodes and transmission channels;
  - consider steps to reduce concentration risk or build processes to manage potential systemic risk (e.g., crisis communication protocols, recovery arrangements).
- The mapping process requires consistent data submissions and strong collaboration with other authorities, regulators and market participants.
- In Scenarios 2 (Bank) and 3 (CSP), mapping would:
  - highlight them as critical nodes;
  - enable authorities to identify threats and impacts on the sector;
  - develop scenarios and mitigation strategies;
  - conduct scenario-based tests or stress testing; and
  - improve incident response capabilities, including including critical service providers in exercising incident response protocols and information sharing.

### Situational awareness
- “Situational awareness refers to an entity’s understanding of the cyber threat environment within which it operates, and the implications of being in that environment for its business and the adequacy of its cyber risk mitigation measures.”
- Strong situational awareness helps pre-empt cyber events or respond rapidly and effectively.
- Key means to achieve situational awareness:
  - robust threat intelligence processes;
  - active participation in information-sharing arrangements and collaboration with trusted stakeholders within and outside the industry;
  - an effective cyber incident reporting framework.
- Authorities can catalyze initiatives to improve sector-wide situational awareness.

### Cyber threat intelligence
- Authorities should require financial entities to establish a process to gather and analyze relevant cyber threat information.
- Analysis should be combined with internal and external business and system information to provide business-specific context and turn information into usable cyber threat intelligence.
- Usable intelligence should enable anticipation of attacker capabilities, intentions and modus operandi.
- Entities should gather and interpret information about threats from participants, service and utility providers and other FMIs to implement appropriate safeguards.
- In Scenarios 2 (Bank) and 3 (CSP), stronger threat intelligence regarding attackers’ modus operandi may have improved chances of preventing the denial of service and ransomware attacks, respectively.

### Information sharing
- Cyber information and intelligence includes indicators of compromise (IOCs), motives of threat actors, tactics, techniques and procedures (TTPs), security alerts, threat intelligence reports, and recommended security tool configurations.
- Exchanging cyber information within a sharing community lets entities leverage collective knowledge to gain a more complete understanding of threats.
  - Members can make threat-informed decisions regarding defensive capabilities, threat detection techniques and mitigation strategies.
  - Correlating and analyzing information from multiple sources enriches and makes intelligence more actionable (e.g., sharing effective practical mitigations).
- Authorities should encourage active participation in information-sharing groups, including cross-industry, cross-government and cross-border groups.
- Multilateral information-sharing arrangements should be designed to facilitate sector-wide response to large-scale incidents.
- Authorities can catalyze information sharing through public-private partnerships, designing frameworks, rules, platforms and media of exchange.
- In Scenarios 2 (Bank) and 3 (CSP), participation in information sharing networks could have provided ex-ante actionable intelligence or enabled sharing of vital intelligence during an attack to reduce ecosystem impact.

### Incident reporting
- Efficient and effective response and recovery is essential to limit related financial stability risks.
- Incident reporting is a primary mechanism for financial authorities to maintain visibility of disruptions with regulated entities.
- A robust cyber incident reporting framework facilitates authorities' ability to intervene and manage incidents with potential systemic impact.
- A sound cyber incident reporting framework should include:
  - standardized templates;
  - safe communication channels between authorities and entities;
  - clear thresholds for reporting;
  - clearly articulated definitions and taxonomies.
- Figure 4 in the source illustrates the components of the framework.

*Source: Financial Stability Board (2020).*

### 1.1 Reporting Details 1.2 Incident Details 1.3                     Impact

### 1.1 Reporting Details 1.2 Incident Details 1.3 Impact Assessment

### Incident reporting and information sharing
- A robust incident reporting framework, designed by financial authorities and clearly communicated to financial entities, enables stakeholders to manage an incident (including a potentially systemic one) throughout its lifecycle.
- The incident response phase is the most critical stage when system impact could be highest; restoring services and ensuring system safety can also occur during the resolved phase.
- Timely notification to financial authorities and ongoing updates are critical to ensure incidents are managed and do not escalate to systemic levels.
- Authorities should ensure:
  - strong awareness among all entities about incident reporting;
  - clear protocols for notification;
  - a robust response framework dictating crisis management at a sector level.
- While incident reporting is essential, relevant authorities must be able to share incident information with each other where legally feasible.
- Scenario-specific observations:
  - Scenario 2 (Bank): the financial institution should notify its banking supervisor; the banking supervisor must have protocols to inform the FMI operator, FMI overseer and other relevant authorities to enable timely ecosystem-wide incident management.
  - Scenario 3 (CSP): CSPs are unlikely to be bound to report to financial sector authorities; information may reach authorities indirectly with a time-lag. Authorities should enable free-flowing incident information sharing and invite CSPs to notify them in a timely manner.
  - In some jurisdictions, critical infrastructure agencies or Computer Emergency Response Teams (CERTs) may be notified and manage cross-sectoral incident response; financial authorities should liaise with such agencies and CERTs through ex-ante arrangements and protocols.

### Authorities’ Response Framework (ARF)
- Financial ecosystems are complex and interconnected, typically comprising RTGS systems, other FMIs, banks, CSPs, overseers, supervisors, and central banks.
- The ARF is a formal mechanism for financial authorities to coordinate when an incident or threat could cause major disruption to financial services.
- ARF governance and operation:
  - Jointly owned, governed and supported by senior representation from all authorities.
  - Enables authorities to respond to incidents while considering impacts to their statutory objectives.
  - Can be used for incidents affecting the finance sector or other sectors whose incidents may indirectly affect finance.
- ARF invocation should occur for any operational incident that affects, or has the potential to affect, the finance sector.
- ARF should operate at three levels:
  1. “Monitor” – cross-authority coordination and monitoring required.
  2. “Engage” – situation has worsened; active engagement with firms, data gathering, relief actions, and wider communications may be needed.
  3. “Escalate” – authorities’ Seniors needed to coordinate strategic action.
- ARF playbook components (four key components):
  - (i) defining clear thresholds for an incident that requires invocation of the ARF;
  - (ii) processes to invoke the ARF;
  - (iii) an incident assessment and escalation model;
  - (iv) a response plan and decision-making process.
- The playbook should define the ARF role, clarify systemic-level operational incidents and systemic risk, describe ARF fit within financial sector crisis management and coordination frameworks, outline activation procedures, and provide guidelines for information sharing.
- The ARF should bring together all relevant stakeholders (public and private) with clarity on roles and responsibilities for incidents that could become systemic.
- The ARF should be regularly tested through market-wide exercises to ensure effectiveness and fitness against a rapidly evolving threat landscape.
- Scenarios 2 (Bank) and 3 (CSP) illustrate that ARF invocation is necessary to:
  - assess ecosystem impact;
  - make crucial decisions;
  - disseminate consistent information to market participants timely to avoid market panic.

### CIRR (Crisis Incident Response and Recovery) framework and sector preparedness
- Financial entities should have a robust CIRR framework enabling ex-ante and ex-post management of cyber incidents.
- Authorities should provide strong leadership to drive:
  - collective strategic planning and collaboration;
  - identification and mapping of the sector to identify transmission channels;
  - situational awareness for timely actionable intelligence;
  - an authorities response framework to galvanize decisive and effective responses to systemic incidents.
- CIRR framework components to encompass:
  - governance;
  - planning and preparation;
  - analysis;
  - mitigation;
  - restoration and recovery;
  - coordination and communication;
  - improvement.
- Prudential authorities should work closely with supervised entities to ensure effective, comprehensive and mature CIRR frameworks, given problems at critical institutions could affect the system.

### Key findings and policy implications from scenarios and simulations
- Two key takeaways:
  1. Timely systems recovery and effective queuing and liquidity risk management serve as preemptive actions to reinforce cyber resilience.
     - Scenarios produced limited impact with practically no second round effects due to scenario design.
     - Liquidity and settlement risks were most severe in Scenarios 2 (Bank) and 3 (CSP) when a cyber-attack hits a major bank, or several banks simultaneously through dependence on a common CSP.
     - In those scenarios, incidents are assumed to last till end of day leaving no intraday recovery potential; effects limited to direct initial incident effects without second round contagion.
     - In Scenarios 4 (LVPS) and 5 (FX), payments affected by the incident are assumed postponed till noon (not removed), allowing time for system recovery; results indicate fast and full recovery due to queuing and liquidity saving mechanisms of TARGET Services enabling prompt and automated recovery.
  2. Financial sector entities with a mature CIRR framework are best placed to respond and recover, reducing systemic risk.
     - Identification of institutions requiring supervisory attention regarding CIRR is important.
     - Multi-authority involvement strengthens ecosystem resilience through improved collective planning, identification and mapping, situational awareness, and response frameworks.

### Extensions and future scenario considerations
- Forward-looking scenarios to simulate for cyber stress testing could include:
  - more extreme cyber-attack scenarios;
  - lengthier outages (multiple days or weeks);
  - liquidity constraints (liquidity shortages due to collateral deterioration);
  - net settlements instead of real-time gross settlements;
  - unauthorized modification of transactions;
  - non-substitutability of settlement services;
  - inter-day exposures due to time zone differences in foreign exchange settlements;
  - cross-sectoral impacts (e.g., disruptions in capital market FMIs, or cyber-attack on critical infrastructure such as telecommunication networks or an energy supplier);
- Such assumptions enable testing of more severe scenario impacts.
- Internal operative analysis could focus on participant-level impacts in addition to system-level analysis to identify vulnerabilities, critical participants and counterparty exposures, and to observe first-round and second-round contagion effects; confidentiality constraints may limit public presentation of participant-level results.

*Source: IMF Working Papers — Using Simulations for Cyber Stress Testing Exercises*

### Annex II.  Overview of the Bank of Finland

### Annex II.  Overview of the Bank of Finland

### Payment and Settlement System Simulator (BoF-PSS3)
- The Bank of Finland Payment and Settlement System Simulator (BoF-PSS3) is an analysis software designed for payment and settlement system simulations.
- Purpose: studying liquidity needs and risks in payment and settlement systems; simulating special situations difficult or impossible to test in a real environment.

### General architectural overview
- The BoF-PSS3 simulator consists of 3 main parts:
  - A graphical user interface implemented as a web-application using mainly techniques like html and javascript.
  - A back-end server than can be installed on a regular windows PC.
  - Database storage. Currently MariaDB is used in development.
- The simulator architecture relies on project-specific databases to store all data and simulation results.

### Input data
- Minimum required input: transaction data.
- List of datasets that can be given to the simulator:
  - Account balances (PART)
  - Transactions (TRAN)
  - Intraday credit limits (ICCL)
  - Bilateral and multilateral limits (BLIM) Credit caps are also supported.
  - Events information (EVNT)
  - Reservations (RSRV). Tailored systems only.
- Data handling and validation:
  - Production data is usually favored; artificial data may be used depending on the study.
  - The simulator includes tools to import and validate these data.
  - All input data must be formally valid and account ids in all files must correspond to the account ids in a participant dataset.
  - All input data must be presented in CSV (comma separated values) format, but it can be entered in a user-defined order.
  - Input data can be exported as CSV to Excel for editing and re-imported after changes.
  - Older Excel versions can handle about 65,000 rows. Excel 2010 is already able to handle ~1 000 000 rows.
  - For larger files, other tools (e.g. Python, Matlab, R, Access or SAS) or programming is usually needed.
  - One option is to edit the data directly in the simulator’s databases with SQL-queries; this requires moderate technical skills.
  - In rare situations, splitting tables in sub-tables may be suitable; the simulator does not include a proprietary editor for this purpose.

### Simulation execution
- The simulator includes tools for configuring payment and settlement system setups and running simulations.
- Functionalities:
  - Records all events and bookings.
  - Provides premade reports and statistics on simulation runs.
  - Allows setup and management of settlement structures and settlement rules.
  - Enables users to launch, monitor and control simulation runs.
  - Keeps a log file for the user of all simulations made.

### Analysis functionalities and simulation results
- Reporting:
  - Basic statistics for common result parameters are available.
  - Output database tables contain data for booking order of transactions and balances of settlement accounts.
  - Input database tables contain the transactions posted to the production system.
  - Output tables contain the settlement flow, i.e. settlement order and timing of submitted transactions.
- Post-processing:
  - Users often export CSV files for use with Excel or other statistical software for complex or tailored analyses.
  - Recommendation: create a structure beforehand for simulation runs and determine which results are to be stored in databases for further analysis.
  - Databases can become overly massive when transaction volumes are high and all transaction-level events are retained—this is specifically the case when the automated stress tester is not used.

### Example of supported system structures and simulation
- BoF-PSS3 supports a large variety of general system structures and can model most payment and securities settlement system structures and processes.
- Supported settlement system types and features:
  - RTGS, DNS, CNS
  - Hybrid (combinations of the above)
  - LVPS and Retail
  - Delivery versus payment, payment versus payment
  - Bilateral and multilateral limits (credit and debit caps)
  - Multicurrency
  - Multisystem
  - Securities settlement systems
  - Central Counterparty
- Processing options are defined by selecting appropriate algorithms (e.g., QUE algorithms for releasing transactions from queues; PNS algorithms for partial net settlement invocation).
- Focal output factors in simulations typically include:
  - Counterparty risk and overall risk
  - Liquidity consumption
  - Settlement volumes
  - Gridlock situations
  - Queuing time

### Examples of purposes for using the simulator
- Identify and quantify risks
  - Counterparty risk
  - Critical participants
  - Warning indicators
- Scenario analysis
- Stress testing
- Feature prototyping
- System design
- Academic research

### Examples of possible scenario types
- Participant default
- Cyber attacks
- Terror attack
- Earthquake
- Operational incidents
- Bank run
- Devaluation of collateral
- System change
- Policy change
- Mergers

### Commonly affected factors in scenarios
- Transactions (canceled, delayed, introduction order)
- Beginning of day balances
- Credit limits
- Bilateral and multilateral limits (credit and debit caps)
- System setups
- Algorithms
- Account structure
- Note: Scenarios are usually generated by affecting input data and system setups in various ways. The simulator can be described as a deterministic model with stochastic input.

*Source: Bank of Finland*

---


_Source: https://www.imf.org/-/media/files/publications/wp/2025/english/wpiea2025085-print-pdf.pdf_