The scenario and the evidence chain
This is an invented training exercise, not a real customer outcome, observed resilience test, assurance claim or suggested regulatory tolerance. It demonstrates the structure of evidence a competent practitioner would demand. Any regulated firm must derive its service boundaries, tolerance and harm thresholds from its actual customers, data, regulatory perimeter and governing-body decisions.
Consider North Quay Payments, a fictional UK authorised payment institution. A customer-facing service accepts and processes eligible transfer instructions. It relies on gateway supplier A, authentication platform B, a settlement partner, two reconciliation specialists and a customer-notification channel. Payment instructions arrive at a hypothetical average of 1,200 per hour during the test. A backup gateway could process 200 per hour, but only after an assumed 60-minute activation period; that substitute has not yet been validated for fraud-control capacity.
One dependency map that exposes the important risks
| Client outcome | Dependency | Failure question | Evidence owner |
|---|---|---|---|
| Accept eligible instructions | Primary payment gateway A | Can routing fail over independently of the same identity provider? | Head of payments |
| Authenticate access | Identity platform B | Would failed access prevent customers checking pending instructions? | Identity operations |
| Settle and reconcile | Settlement partner plus reconciliation staff | Can manual processing reconcile all accepted but unsettled instructions? | Treasury / finance |
| Explain disruption | Customer communications provider | Is a non-primary channel available to notify affected customers? | Customer operations |
| Decide on controls | Compliance/fraud controls | Can the fallback be used safely without bypassing required checks? | Compliance and fraud lead |
A credible tabletop must challenge the relationship between these elements—not simply ask how quickly gateway A restarts. A service could be technically available while payments remain unprocessed, duplicate instructions accumulate or customers cannot get reliable information.
Test assumptions and arithmetic
At 09:00, gateway A fails. The hypothetical alternative is not usable for 60 minutes. From 10:00 onward, incoming demand remains 1,200 instructions/hour and backup throughput is 200/hour, so backlog grows by 1,000 instructions per hour once the fallback is operating. We assume a starting backlog of zero, no cancellations, no queue drain from the primary, even arrivals, and no reduction in customer demand. Those are simplifying assumptions, not claims about a real system.
| Elapsed time | Arrived since outage | Processed by fallback | Estimated pending backlog |
|---|---|---|---|
| 0 minutes | 0 | 0 | 0 |
| 60 minutes | 1,200 | 0 | 1,200 |
| 120 minutes | 2,400 | 200 | 2,200 |
| 180 minutes | 3,600 | 400 | 3,200 |
| 240 minutes | 4,800 | 600 | 4,200 |
The calculation at minute 180 is 3,600 arrived minus 400 processed = 3,200 pending instructions. A workbook containing the inputs and calculation steps is available as a downloadable simulated observation log. Changing demand, backlog age, priority mix or fallback throughput would change the outcome.
For the exercise only, imagine a decision threshold of 3,000 pending instructions, set for discussion; it is not a regulatory impact tolerance. The backlog reaches 3,000 at approximately 168 minutes after outage onset under these assumptions. A competent review would still need real harm evidence, affected customer cohorts, value and urgency of transfers, settlement cut-offs and whether any vulnerable customers are disproportionately harmed.
Exercise injects and governance responses
09:20 — supplier dependency challenge. The supplier says authentication platform B is also degraded. Does the backup gateway depend on it? Capture the actual system architecture, not an optimistic assertion.
10:00 — fallback availability. The team proposes routing a subset of payments through the backup. Compliance asks whether fraud and safeguarding controls function at 200/hour. An unvalidated workaround cannot be counted as safe tested capacity merely because it exists on paper.
11:00 — customer harm and backlog visibility. Operations can report transaction counts but not how many customers need urgent access to funds. The incident commander must record this evidence gap; a backlog count alone is not a consumer-harm analysis.
12:00 — escalation. The simulated 3,000-instruction planning threshold has already been exceeded. Who owns the regulator notification analysis under the applicable current rules? Which stakeholders approve customer communications and risk acceptance? This decision cannot be delegated to a generic AI-generated score.
What a board-ready report should contain
- Service and tolerance rationale: exact customer-facing outcome, legal entity, authorised activities, harm metric, sensitivity by customer cohort and source data.
- Observed scenario timeline: planned assumptions versus actual measured tests, failed dependencies, communication routes, decisions and limitations.
- Vulnerability: fallback throughput and fraud-controls not proven; no validated customer-harm distribution; supplier identity dependency potentially shared.
- Remediation: assign the head of payments to commission a safe failover exercise, the fraud lead to approve control parity, and customer operations to measure impacted cohorts and missed commitments.
- Closure criterion: repeated evidence-backed exercise at agreed loads, documented controls, measured restoration and governing-body review of residual exposure.
An exercise result saying “all systems restored” would miss the business-service question. The worthwhile deliverable is an owned chain from a test observation through a material risk decision to verifiable closure.
Suggested deliverables, downloadable without registration
- Simulated payments-outage observations and calculations (CSV)
- Board evidence matrix (CSV)
- Example managed programme RACI
Assumptions and limitations
The firm, counts, timeline and decisions here are fictional teaching inputs. This is not a case study, a penetration-test report, a security assessment or financial-services legal advice. Our worked data contains no client information or confidential supplier material. It does not establish whether any actual firm can remain within its regulator-approved impact tolerances.
Regulatory context
Prepared 12 October 2026; simulated data only. A qualified regulatory and operational resilience reviewer must approve the final training material before it is used as professional guidance.