Spatial financeWhere capital meets hazard, exposure and transition
Reliability and resilience engineering at Financial Cyber and Operational Resilience
Resilience engineering studies how organisations anticipate, absorb, recover from and adapt to disruption. On this platform it frames important services, impact tolerances, dependency mapping, recovery design and learning from incidents.
What reliability and resilience engineering does here.
Reliability and resilience engineering studies how systems fail, how failures can be prevented and how systems absorb, adapt and recover from disruption. It addresses both technical components and the organisations that operate them. In cyber and digital resilience, financial stability and critical infrastructure, resilience engineering identifies critical components and recovery bottlenecks across connected systems. It informs redundancy, spares and restoration priorities. The canonical description is on the STEM Commons.
Service and dependency mapping
Important services are traced to the people, processes, technology, facilities and suppliers they need, to find single points of failure.
Recovery strategy comparison
Recovery options are compared for time, data loss and cost under destructive scenarios, informing investment choices by boards.
Learning reviews
Post-incident reviews separate causes from blame and track lessons to changes in design, process and training.
03Spatial finance
Settlement dependencies, and what fails with a node.
How a failure at one financial centre can spread through settlement links. Design links, not real dependencies.
Sixteen financial centres, and how a failure at one spreads through settlement links.Design links, not the real dependencies of any infrastructure.
04Data
What the method consumes.
Datasets and records used by reliability and resilience engineering on this platform, with the role each plays and the label its values carry. Sources are listed in the source register.
Data
Role
Label
Service maps
Dependencies
DECLARED
Incident reviews
Failure causes
REPORTED
Test results
Recovery performance
OBSERVED
05Monitor
Reliability model.
The screen a team would use to follow this method: its measures, states and decisions. Names are examples and values are illustrative.
Reliability model
Operational resilience · Reliability and resilience · Run R-3432
Single point of failureGRA · Financial Cyber and Operational Resilience
Dependency graph
nodes: assets · edges: dependencies
Failure modes
N3
7992
3
Critical
N4
8104
35
Normal
N5
8877
43
Normal
N6
1638
7
Normal
Cascade size under removal
Reliability model: the screen's structure, terms and states for Operational resilience.Example names and illustrative values; a design, not a record or a live system.
06Validation
How results are checked.
Reliability predictions are compared with field failure data. Exercises and post-event reviews check whether recovery performed as planned.
Check
How it is done
Mapping depth
Maps extend beyond first-layer dependencies
Scenario severity
Tests include destructive and multi-failure scenarios
Closure tracking
Lessons are tracked to verified change
Common-cause failures and rare events are hard to estimate from limited data. Human and organisational factors resist quantification.
07Exposure model
How a local shock becomes a system outage.
How much of the networks an operator, insurer or lender depends on stays working after a local shock, and how much the coupling between them amplifies it. Teaching model with stated illustrative values, not a prediction. The map on this page shows The Low Countries; the model itself is not tied to a place.
Controls
Assets per layer
18
Hazard footprint
8% of area
Assets that depend on another layer
60%
Spare capacity (tolerance)
30%
Readouts
Assets hit by the hazard
7%
Assets still working
20%
Amplification of the initial damage
10.8 times
Steps to settle
4
Numbers, methods and sources
Step
Data centres working (%)
Networks working (%)
Power working (%)
0
89
94
94
1
39
44
94
2
22
17
61
3
22
17
33
4
22
17
22
Methods
Interdependent networks Buldyrev and others (2010), Catastrophic cascade of failures in interdependent networks, Nature 464
Overload cascades Motter and Lai (2002), Physical Review E 66
Betweenness load Brandes (2001), Journal of Mathematical Sociology 25
Multilayer networks Kivela and others (2014), Journal of Complex Networks 2
Infrastructure interdependencies Rinaldi, Peerenboom and Kelly (2001), IEEE Control Systems 21(6)
Uncertainty fan (parameter Monte Carlo) Spiegelhalter, Pearson and Short (2011), Visualising uncertainty about the future, Science 333
One-at-a-time sensitivity (tornado) Saltelli and others (2008), Global Sensitivity Analysis: The Primer, Wiley
Data
The model runs on the teaching values set by the controls. To calibrate it for a place, read it against these admitted layers and series, which this page's map can draw:
Natural events (NASA EONET) NASA EONET · register nasa.eonet.events
How a local shock becomes a system outage. Illustrative teaching model: it runs on the values set by the controls, not on measured data. Methods: Interdependent networks (Buldyrev and others (2010), Catastrophic cascade of failures in interdependent networks, Nature 464); Overload cascades (Motter and Lai (2002), Physical Review E 66); Betweenness load (Brandes (2001), Journal of Mathematical Sociology 25).
Assembled from the Nexus Standards area profile Cyber resilience and digital operational resilience: the shocks it names, the systems and sectors that carry the loss, the controls that dampen it and the data that observe it. Pick an initiating shock and step through the cascade to see which exposures it reaches and where losses could concentrate. The Map view places the run on an example geography with open data. Every weight is a stated assumption. An exercise, not a forecast, a valuation, a rating or investment advice. To model a place of your own choosing, open the full System Builder.
The exposure, loss, scenario and capital views a risk officer, supervisor or ministry of finance would ask for, with the frameworks they report against. Structures follow supervisory and actuarial practice. Values are illustrative: never prices, ratings or advice.
Transmission channels
How a shock in Reliability and resilience engineering at Financial Cyber and Operational Resilience reaches credit, market, underwriting, liquidity and operational risk, and feeds back.
Channel structure after the Basel Committee's work on climate-related risk drivers and transmission channels; links shown are typical paths, not estimated exposures.
NGFS climate scenarios · Network for Greening the Financial SystemIFRS S2 Climate-related Disclosures · ISSBTCFD recommendations · Financial Stability Board TCFDPrinciples for the effective management of climate-related financial risks · Basel Committee on Banking Supervision
What are the limits of reliability and resilience engineering in this field?
Common-cause failures and rare events are hard to estimate from limited data. Human and organisational factors resist quantification.
How are results checked?
Reliability predictions are compared with field failure data. Exercises and post-event reviews check whether recovery performed as planned.
Are the values on this page real?
The data names, roles and checks are real descriptions of practice. The canvas shows a design of the method's use, not a run; no result is reported here.
Reports is the Consortium's quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
Global Risks AllianceFinancial Cyber and Operational ResilienceScenario and Stress-TestStrategic Systems
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Financial Cyber and Operational Resilience
Bring an exposure or capital question to the Alliance.
Information and enquiries are open today. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.
Editors and the expert reviewers named on each article decide what we publish. Funders and partners do not review or approve articles before publication.
Privacy choices · Financial Cyber and Operational Resilience
This site uses only strictly necessary cookies to work and to remember your privacy choices. Nothing loads from other companies, and we never sell or share your personal information.
Details
This site uses only strictly necessary cookies to work and to remember your privacy choices. Nothing loads from other companies, and we never sell or share your personal information. We run no advertising. You can review your choices at any time through Privacy choices at the foot of every page.