Viewing as:

Payments data corruption — restore and replay

Data corruption · Severe but plausible · 3 affected service(s)

Scenario narrative

A defective vendor patch applied to the ACH engine corrupts posting records for four hours of morning traffic before detection. Processing halts; the recovery strategy is point-in-time restore followed by controlled replay and reconciliation of ~180,000 entries. Every hour of replay must be balanced before the next is released. Core posting integrity is protected but end-of-day cannot start until replay completes.

Shock set
ACH Processing Engine
applicationstochastic outage: lognormal (median ≈ 9h)
End-of-Day Batch Orchestrator
applicationfixed outage: 8h
Run simulation

The Examiner persona is read-only — switch to any operating role to launch a live run. The Monte Carlo executes in a Web Worker: the interface stays fully responsive while 10,000 iterations run.

Regulatory basis
PRA-SS1/21Scenario testingSS1/21 §5

Firms must test their ability to remain within impact tolerances under severe but plausible disruption scenarios, increasing sophistication over time.

OSFI-E21Scenario testing of resilienceE-21 §6

Institutions test critical operations against severe but plausible scenarios, using results to assess whether tolerances would be breached and to remediate weaknesses.

EU-DORADigital operational resilience testingDORA Art.24-26

A proportionate testing programme (including advanced threat-led testing for significant entities) validates the entity's ability to withstand ICT disruption.

BCBS-PORBusiness continuity planning & testingPOR P3

Banks maintain and test business continuity plans under severe but plausible scenarios to continue delivering critical operations through disruption.

Expectations are paraphrased for demonstration; consult the source instruments for authoritative text.

Global search

Search services, processes, assets, scenarios, vulnerabilities, and regulatory provisions