Where the 0.65 comes from

A Middle East escalation does not directly affect a Dutch bank's IT continuity. It affects LNG prices, which affect energy costs in India, which affect operating margins of outsourced IT vendors, which affects service quality. That cascades further into core banking systems, SWIFT connectivity, and payment processing. Each link in this chain has a named mechanism, a transmission strength, and a time lag. Modelling the chain rather than the correlation produces insights that are both more accurate and more actionable.

But every link carries a number. The transmission strength from LNG price shock to Indian energy costs might be 0.7. From vendor margin pressure to service quality degradation, 0.4. From core banking disruption to SWIFT outage, 0.85. These numbers determine everything: the Monte Carlo distributions, the threshold breach timelines, the fan charts that reach decision-makers. If those numbers are wrong, or worse, if nobody can explain where they came from, the model is an expensive random number generator.

When a DNB examiner asks why the model predicted a 45-day liquidity threshold breach, the answer must trace to something concrete. A specific historical incident. A specific contractual SLA. A specific expert assessment with documented reasoning. "We estimated it" is insufficient. "We estimated it based on the 2017 NotPetya propagation timeline, cross-referenced with the entity's vendor BCP documentation, confidence Medium" is evidence.

The four source types

Every parameter in Roach carries a source tag from one of four categories. The category determines how much weight the parameter carries, how it should be challenged, and when it needs to be reviewed.

Historical incident data. A transmission path was observed in a real event, and the observed propagation characteristics inform the parameter. The 2017 NotPetya attack provides some of the strongest source material available for cyber-to-operational transmission paths. Maersk's entire IT infrastructure was compromised within hours of initial infection through a Ukrainian tax software update. Port operations across 76 terminals halted. The company estimated losses between $250 million and $300 million, with full system restoration taking approximately two weeks. Research published by the Federal Reserve Bank of New York documented second-round effects on the financial system: banks using services from affected technology providers experienced impaired payment capabilities on Fedwire, which in turn reduced payment flows to uninvolved banks, creating potential third-round liquidity pressure.

This is high-quality source material. The propagation timeline is documented. The transmission mechanism is understood (supply chain software compromise to lateral movement to operational disruption). The financial impact is quantified. A parameter sourced from NotPetya carries real evidential weight.

Expert elicitation. A domain expert estimates the parameter based on professional judgment. This is the most common source type and the most dangerous if undisciplined. The difference between a useful expert estimate and a guess is protocol.

Undisciplined elicitation asks "what do you think the transmission strength is?" and records whatever number the expert offers. Structured elicitation asks the expert to specify a range, name the reasoning that supports the lower and upper bounds, identify the conditions under which the parameter would be higher or lower than expected, and assign a confidence level to the estimate. The output becomes a documented judgment with traceable reasoning, rather than a bare point estimate.

The distinction matters because expert estimates are the hardest parameters to challenge. Historical data can be verified. Contractual terms can be checked. An expert's judgment is opaque unless the reasoning is explicitly recorded at the time of elicitation. Six months later, when the parameter needs review, nobody remembers why 0.65 felt right. The documentation is the parameter's memory.

Document extraction. A contractual SLA, a vendor risk assessment, a regulatory filing, or an architecture document provides a concrete data point. If a vendor contract specifies 99.9% uptime with a 4-hour recovery time objective, you can derive transmission strength from the gap between contractual commitment and observed performance. A vendor that has met its SLA consistently for three years carries different evidence than one that breached it twice last quarter.

Document-sourced parameters have a specific advantage: they are auditable. When a regulator asks why the model assumes a particular transmission strength for a vendor dependency, the answer points to a contract clause, a performance report, or an architecture diagram. The parameter's provenance is verifiable by someone outside the modelling team.

Agent assessment. One of Roach's fourteen specialised agents has assessed the parameter based on its analytical framework. This is a model output used as an input to another model, and it needs to be flagged as such. Agent-assessed parameters carry the uncertainty of the agent's reasoning plus the uncertainty of the underlying evidence the agent relied on. They are useful for dimensions where no direct historical or documentary evidence exists, but they should never be treated with the same confidence as a parameter sourced from a documented incident.

Confidence classification

The source type alone is insufficient. A historical incident from 2008 does not carry the same weight as one from 2024. An expert estimate from someone with 20 years of direct experience in Dutch financial IT outsourcing differs from a generalist's informed guess. The underlying mechanism may have changed. The infrastructure may have evolved. The regulatory environment may have shifted.

Every parameter in Roach carries a three-tier confidence classification alongside its value:

High confidence. Multiple corroborating sources, recent data, directly applicable context. Example: transmission strength from ransomware infection to vendor IT operations halt, sourced from NotPetya (2017), Kaseya (2021), and MOVEit (2023). Three independent incidents, same mechanism, consistent propagation characteristics. The parameter is well-supported.

Medium confidence. Single source or analogical reasoning, where the observed event was not identical to the modelled scenario but the underlying mechanism is similar. Example: transmission strength from Indian energy cost increase to outsourced IT vendor service quality. No directly observed incident of this specific path, but the mechanism (margin pressure reducing investment in infrastructure and staffing) is well-understood in analogous contexts.

Low confidence. Expert judgment without corroboration, or data from a significantly different context. Example: transmission strength from a hypothetical quantum computing breakthrough to cryptographic infrastructure vulnerability. The mechanism is theoretically sound but entirely unobserved.

A 0.65 (High) tells a fundamentally different story than a 0.65 (Low). Both feed into the Monte Carlo simulation, but they feed in differently: the high-confidence parameter generates a tight probability distribution, while the low-confidence parameter generates a wide one. This is where confidence classification connects directly to the model's output uncertainty.

Building a causal subgraph: a worked example

Abstract descriptions of parameter sourcing are less useful than watching it happen. Here is the process of constructing a small causal subgraph from scratch for a specific scenario: a ransomware attack on a Dutch bank's outsourced IT vendor, and its potential propagation to payment processing.

Step 1: Identify the nodes. The causal chain runs through six nodes: external threat event (ransomware deployment), vendor IT operations, data centre availability, core banking system, SWIFT gateway, and payment processing. Each node represents a system or capability that can be in a normal, degraded, or failed state.

Step 2: Map the edges. Which nodes causally influence which others? Direction matters. Not every disruption propagates in every direction, and the mechanisms differ by edge.

Step 3: Source each edge.

Ransomware to vendor IT operations. Source type: historical incident. NotPetya demonstrated that a single infection vector (compromised software update) can propagate across an organisation's entire IT estate within hours. Maersk lost access to 49,000 PCs and 6,500 servers. Kaseya (2021) showed a similar pattern through managed service provider infrastructure. Transmission strength: 0.8. Time lag: 0 to 24 hours. Confidence: High. Three independent incidents confirm the mechanism and approximate magnitude.

Vendor IT operations to data centre availability. Source type: document extraction. The vendor's BCP documentation specifies disaster recovery capabilities, including failover architecture and geographic redundancy. If the vendor operates active-active across two data centres, a ransomware event affecting one site may leave the other operational, giving a lower transmission strength. If the vendor runs active-passive with manual failover, transmission strength is higher. Suppose the documentation shows active-passive with a 4-hour RTO. Transmission strength: 0.5. Time lag: 4 to 48 hours. Confidence: Medium. The documentation describes capability, but the actual DR performance under a real ransomware event may differ from what the documentation claims.

Data centre availability to core banking system. Source type: document extraction (IT architecture). This edge depends on whether the bank's core banking platform is hosted at the vendor's data centre or operates independently. If hosted, this is a hard dependency with high transmission strength. If the bank runs its own core banking but relies on the vendor for ancillary services, the dependency is softer. Assume hosted. Transmission strength: 0.9. Time lag: 0 to 4 hours. Confidence: High (architectural dependency is a fact, not an estimate).

Core banking to SWIFT gateway. Source type: expert elicitation. The relationship between core banking availability and SWIFT connectivity depends on the specific integration architecture. Can SWIFT messages be queued and processed when core banking recovers? Or does SWIFT connectivity require a live core banking connection? An expert with knowledge of the specific institution's architecture estimates that SWIFT can operate in degraded mode for approximately 4 hours before message queuing capacity is exhausted. Transmission strength: 0.7 (degraded rather than failed). Time lag: 4 to 8 hours. Confidence: Medium. The estimate is from a single expert with direct knowledge, but untested under actual stress conditions.

SWIFT gateway to payment processing. Source type: historical incident plus document extraction. SWIFT outages have documented precedent in terms of payment processing impact. Cross-border payments halt immediately. Domestic payments may continue through alternative clearing if the institution has redundant payment rails. The institution's payment architecture documentation shows that 60% of its payment volume is SWIFT-dependent. Transmission strength: 0.6. Time lag: 0 to 2 hours. Confidence: High.

Step 4: Validate end-to-end. The graph now predicts that a ransomware attack on the outsourced vendor could impact payment processing within 8 to 82 hours (sum of time lag ranges across the chain). The end-to-end transmission strength, computed as the product of individual strengths along the critical path, is approximately 0.8 x 0.5 x 0.9 x 0.7 x 0.6, which is approximately 0.15. This means that in about 15% of scenarios where the vendor suffers a ransomware attack, payment processing is materially impacted.

Does this pass a sanity check? NotPetya's impact on Maersk's operations materialised within hours to days, with full recovery taking two weeks. A 15% end-to-end transmission probability with an 8-to-82-hour time window is plausible for a bank with partial architectural independence from its vendor. If the number were 90%, that would suggest the bank has no resilience whatsoever, which contradicts the architectural documentation. If it were 1%, that would suggest the outsourcing relationship carries almost no operational risk, which contradicts the vendor dependency profile.

The parameter carries no claim to absolute precision. It is internally consistent, traceable to specific sources, and produces plausible end-to-end dynamics. That is the standard.

Temporal decay and review cycles

Parameters go stale. A vendor relationship that has experienced zero incidents over ten years carries different evidence than one that suffered a two-day outage last quarter. An expert estimate made in 2022, before the institution migrated to a new cloud provider, no longer reflects the current architecture. A historical incident from 2008 may or may not be relevant depending on whether the underlying mechanism has changed.

Every parameter in Roach carries a review date. When the review date passes, the parameter is flagged for re-assessment. This constitutes a structural requirement, because a model that silently relies on stale parameters will produce confident outputs that are no longer grounded in current evidence.

The review cycle depends on the source type and the rate of change of the underlying system. Architectural dependencies (core banking to SWIFT) change only when the institution re-architects, so they might carry a 12-month review cycle. Vendor performance parameters should be reviewed quarterly against actual SLA data. Expert estimates should be reviewed whenever the expert's underlying assumptions are invalidated by new events.

From parameters to Monte Carlo

Every parameter represents the centre of a probability distribution, and the confidence classification determines how wide that distribution is.

A transmission strength of 0.65 with High confidence becomes a tight Beta distribution: Beta(13, 7), with most of its probability mass concentrated between 0.55 and 0.75. The model is fairly certain about this parameter. When Monte Carlo samples from this distribution, it produces a narrow range of outcomes for this particular edge.

The same 0.65 with Low confidence becomes a wide Beta distribution: Beta(3, 2), with probability mass spread from roughly 0.2 to 0.9. The model is uncertain. When Monte Carlo samples from this distribution, it produces a wide range of outcomes, and this uncertainty propagates through every downstream node in the causal graph.

This is where parameter provenance connects to the model's final output. A fan chart with wide uncertainty bands signals that the model contains low-confidence parameters, and that it is honestly communicating the limits of its knowledge. Narrow bands mean the parameters are well-sourced and the model is confident. Wide bands mean the parameters need better evidence.

The practical consequence follows directly: improving model precision depends primarily on improving parameter provenance. Replace a Low-confidence expert estimate with a High-confidence historical incident, and the fan chart narrows. Replace a document-extracted parameter with a verified post-incident measurement, and the threshold breach timeline becomes more precise. The model's precision is bounded by the quality of its inputs, not the sophistication of its computation.

The register

Every parameter in Roach lives in a register entry. The entry records:

• The parameter value (0.65)
• The source type (historical incident, expert elicitation, document extraction, or agent assessment)
• The specific source (NotPetya propagation timeline, 2017; Maersk operational impact data)
• The confidence classification (High, Medium, or Low)
• The review date (next scheduled re-assessment)
• The last reviewer (who last validated this parameter)

When a DNB examiner asks "why 0.65?", the answer takes the form of a register entry with a traceable evidence chain. The parameter was set to 0.65 based on observed ransomware-to-operations transmission characteristics in three documented incidents, with consistent propagation timelines and magnitude, last reviewed in Q1 2026 by a named analyst.

That is what transforms a model parameter from an inference into evidence.

References

1. Crosignani, M., Macchiavelli, M. & Silva, A.F. (2023). Pirates without Borders: The Propagation of Cyberattacks through Firms' Supply Chains. Journal of Financial Economics, 147(2), 432-448. sciencedirect.com

2. Federal Reserve Bank of New York. (2020). The Propagation of Cyberattacks through Firms' Supply Chains. Staff Report No. 937. newyorkfed.org

3. Li, D.X. (2000). On Default Correlation: A Copula Function Approach. Journal of Fixed Income, 9(4), 43-54. Referenced as an example of parameter provenance failure at systemic scale.