For the London Stock Exchange Group (LSEG), identifying Severe but Plausible Scenarios (SbPS) for CBS-1 Exchange Trading Services is a key activity within Stage 4 of the Operational Resilience implementation methodology.
Severe but plausible scenarios are not routine operational incidents; they are extreme but credible events that could materially disrupt the delivery of critical business services.
In accordance with operational resilience principles described in the BCM Institute guidance, scenario identification enables organisations to assess vulnerabilities across people, processes, technology, facilities, data, and third-party dependencies.
For an exchange operator such as LSEG, where uninterrupted market operations are critical to market integrity and financial stability, these scenarios must evaluate the resilience of trading operations under highly disruptive conditions, including cyber incidents, infrastructure failures, market volatility events, and third-party disruptions.
The scenarios below are designed to support dependency mapping, impact tolerance validation, and future scenario testing activities.
Each scenario incorporates a cyber and ICT risk perspective and identifies evidence of proactive risk management actions demonstrating LSEG's preparedness and resilience capabilities.
Table P5: Identify Severe but Plausible Scenarios for CBS-1
|
Sub-CBS Code |
Sub-CBS |
Severe but Plausible Scenario |
Impact/Effect |
Proactive Risk Management Action |
Link to Integration of Cyber and ICT Risks |
|
1.1 |
Market Participant Onboarding and Membership Management |
The identity and access management platform is unavailable during a major onboarding cycle |
Delay in participant activation and inability for new members to access trading services |
Automated onboarding workflows, alternate approval procedures, and resilience testing of IAM systems |
Identity platform compromise, privileged account attack, directory service outage |
|
1.2 |
Customer Identification and Regulatory Validation |
External KYC/AML verification provider outage |
Delayed regulatory validation and onboarding backlog |
Secondary validation provider, manual fallback process, third-party resilience assessment |
Third-party API disruption or cyber compromise |
|
1.3 |
Trading Account Setup and Access Provisioning |
Privileged access system corruption resulting from malware infection |
Trading accounts cannot be created or modified |
Segregated administration, privileged access management, and immutable backups |
Cyber attack on identity and access infrastructure |
|
1.4 |
Trading Platform Connectivity and Session Establishment |
Network gateway failure at the primary exchange access point |
Participants unable to establish sessions with the exchange |
Diverse telecom providers, automatic failover, and network stress testing |
DDoS attack against exchange connectivity gateways |
|
1.5 |
Instrument and Product Configuration Management |
Incorrect deployment of trading instrument parameters |
Trading errors and market disruption |
Change approval governance, release validation, and rollback procedures |
Configuration manipulation through compromised admin access |
|
1.6 |
Market Data Feed Distribution and Synchronization |
Market data multicast infrastructure failure |
Participants receive delayed or inconsistent market information |
Dual feed architecture, latency monitoring, synchronization testing |
Network intrusion affecting feed dissemination platforms |
|
1.7 |
Order Entry and Capture Processing |
Order gateway software failure during high-volume trading |
Orders cannot be submitted or captured |
Capacity testing, active-active processing, performance monitoring |
Exploitation of trading APIs is causing service degradation |
|
1.8 |
Pre-Trade Risk and Control Validation |
Risk validation engine unavailable |
Orders bypass controls or experience delays |
Redundant risk engines and threshold monitoring |
Malware affecting risk processing servers |
|
1.9 |
Order Routing and Matching Engine Processing |
Core matching engine failure during volatile market conditions |
Trading interruption and inability to execute orders |
Active-active architecture, high availability design, resilience exercises |
Cyber compromise of the matching engine infrastructure |
|
1.10 |
Trade Execution Processing |
Database corruption affecting trade execution records |
Trade failures and integrity concerns |
Real-time replication and transaction recovery procedures |
Ransomware attack affecting transaction systems |
|
1.11 |
Trading Session and Market State Management |
Session controller failure is causing incorrect market status |
Market opens/closes incorrectly |
Segregated controllers and operational validation procedures |
Unauthorized access to altering session states |
|
1.12 |
Market Surveillance and Trade Monitoring |
Surveillance analytics platform unavailable during market abuse event |
Delayed fraud detection and regulatory exposure |
Alternate monitoring tools and incident escalation procedures |
SIEM compromise or cyber attack on monitoring systems |
|
1.13 |
Exception Handling and Trade Intervention Management |
Manual intervention platform unavailable during trading incident |
Delayed issue resolution and operational escalation |
Backup intervention procedures and crisis playbooks |
Administrative console cyber compromise |
|
1.14 |
Circuit Breaker and Volatility Control Administration |
Volatility control logic failure during flash market movement |
Market instability and excessive price movement |
Validation testing and simulated market exercises |
Manipulation of control algorithms through cyber intrusion |
|
1.15 |
Clearing and Settlement Integration Processing |
Clearing the network interface is unavailable |
Settlement delays and post-trade backlog |
Secondary communication links and recovery procedures |
API disruption from a cyber attack on external integration |
|
1.16 |
Regulatory Reporting and Compliance Monitoring |
Regulatory reporting application unavailable |
Reporting breaches and potential sanctions |
Alternative reporting procedures and resilience testing |
Data exfiltration or attack on reporting systems |
|
1.17 |
Reference Data and Master Data Administration |
Corrupted master instrument data was introduced into production |
Trade processing errors across multiple services |
Data validation controls and dual approval process |
Unauthorized modification of master data repositories |
|
1.18 |
Cybersecurity Monitoring and Trading Infrastructure Protection |
Security operations monitoring platform disabled during active intrusion |
Threats remain undetected, and attacks escalate |
SOC redundancy, SIEM failover, continuous monitoring |
Advanced persistent threat targeting SOC infrastructure |
|
1.19 |
Business Continuity and Exchange Recovery Operations |
Regional data centre outage affecting the primary exchange site |
Exchange service disruption and market outage |
Alternate recovery site, crisis management exercises, recovery testing |
Combined cyber-physical disruption and infrastructure attack |
|
1.20 |
Trading Analytics and Operational Performance Reporting |
Analytics platform unavailable during operational incident |
Reduced visibility into exchange performance |
Replicated reporting environments and operational dashboards |
Data pipeline compromise affecting analytics integrity |
The Severe but Plausible Scenarios identified for CBS-1 Exchange Trading Services provide LSEG with a structured basis for understanding how significant disruptions may affect the resilience of its exchange operations.
These scenarios extend beyond isolated technology failures and evaluate interconnected dependencies involving cyber threats, infrastructure disruptions, operational process failures, and third-party service interruptions.
By incorporating explicit links to cyber and ICT risks, LSEG can align operational resilience objectives with broader enterprise risk, technology resilience, and cybersecurity initiatives.
Furthermore, the inclusion of proactive risk management actions demonstrates evidence of preventive and detective controls rather than relying solely on recovery capabilities.
These scenarios should subsequently be used to design scenario testing exercises, validate impact tolerances, identify capability gaps, and drive continuous improvements to LSEG’s operational resilience framework.
Through regular review and testing, LSEG can strengthen confidence that Exchange Trading Services remain resilient under severe yet credible disruption conditions.
| eBook 3: Starting Your OR Implementation |
|||||
| CBS-1 Exchange Trading Services | |||||
| CBS-1 DP | CBS-1 MD | CBS-1 MPR | CBS-1 ITo | CBS-1 SbPS | CBS-1 ST |
To learn more about the course and schedule, click the buttons below for the OR-300 Operational Resilience Implementer course and the OR-5000 Operational Resilience Expert Implementer course.
|
If you have any questions, click to contact us. |
||
|
|