What happens when a bank has to keep trading without its normal systems after a ransomware attack?

When normal systems are unavailable, a bank may revert to manual processing, courier-based document handling, and tightly sequenced approvals to keep trades moving. That preserves continuity, but it also slows execution, increases operational overhead, and raises the chance of errors. The recovery process must balance speed, control, and evidence preservation.

How a bank keeps trading moving after ransomware takes down core systems

Once core platforms are unavailable, the business does not stop, but it does change shape. Front office, operations, and control teams move to fallback processes that preserve execution and recordkeeping while they work around the outage. The practical question becomes which trades can still be processed safely, which approvals are mandatory, and how much manual handling the institution can absorb before delay becomes a market, client, or compliance problem.

That shift is not just an IT recovery issue. Trading continuity depends on control over data, instructions, confirmations, and settlement steps, so the fallback model has to be designed for operating risk as much as technical recovery. In a bank, the real objective is to keep the book moving without losing traceability or creating unreconciled exposure.

What manual trading continuity usually looks like in practice

Fallback trading is typically a controlled degradation rather than a free-for-all. Teams may capture orders in spreadsheets or ticketing tools, route documents by courier or secure email, and require sequential sign-off before a trade is released. The 52 NHI Breaches Report is a useful reminder that once normal automation is disrupted, exposed credentials and access paths can quickly widen the blast radius if recovery steps are not tightly governed.

The most important operational change is that the bank replaces automated straight-through processing with human checkpoints. That reduces speed, but it also forces explicit verification of trade instructions, counterparty details, and exception handling. For higher-risk products, firms often narrow the set of permissible activity so only pre-approved, well-understood trades can proceed while systems are impaired.

Manual continuity also changes evidence. Instead of relying on system logs alone, the bank needs a defensible chain of who approved what, when the instruction was received, how it was transmitted, and how the execution was confirmed. That audit trail matters because the organisation must later reconcile the manual period back into the normal books and records environment.

Why the recovery trade-off is speed versus control

The main trade-off is simple: every extra control step slows execution, but every shortcut increases the chance of a bad trade, a missed limit, or a settlement break. Banks that move too quickly can create downstream errors that are harder to unwind than the original outage. Banks that slow down too much can fail clients, miss market windows, or breach internal service commitments.

External guidance on ransomware and critical infrastructure consistently treats this as a resilience problem, not only an incident response problem. CISA cyber threat advisories emphasise that ransomware events can disrupt operations well beyond the initial encryption event, which is why fallback workflows and recovery sequencing need to be planned before the attack. For sector context, the CISA cyber threat advisories page is a relevant reference point.

For banks, the failure mode is usually not one dramatic mistake. It is accumulated friction: delayed confirmations, duplicated work, manual transcription errors, and inconsistent exception handling across desks or regions. When that happens, the outage stops being just a technology event and becomes an operational integrity issue that can persist after systems come back.

What good recovery looks like for a trading bank

Good recovery keeps the fallback period bounded. That means the bank knows which processes can run manually, which ones must be paused, and which approvals must remain in force even under pressure. It also means the institution can prove that trades processed during the outage were segregated from normal processing, reviewed, and reconciled before full resumption.

Industry control guidance reinforces this separation of duties and evidence discipline. NIST SP 800-53 Rev. 5 makes this explicit through controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control, audit, and contingency-related controls that support controlled fallback operations. The point is not to automate everything at any cost, but to ensure the manual process is still governed, reviewable, and recoverable.

Well-run recovery also uses the outage as a signal. If manual handling is repeatedly required, the bank should treat that as a resilience gap in the trading stack, not as an acceptable normal mode. The more frequently the organisation falls back to paper, courier, or voice-based handling, the more it should reassess recovery time, control coverage, and operational capacity.

Risk and Threat Considerations

When trading continues manually after ransomware, the main risks are operational error, evidence loss, and control bypass. The longer the fallback period lasts, the more likely it becomes that one-off exceptions turn into unmanaged process drift, especially if teams are under pressure to restore client service quickly.

Failure mechanism: Manual re-entry, unsecured document movement, and rushed approvals can break the integrity of trade data and weaken the chain of custody for instructions and confirmations.

Impact: The bank can suffer settlement failures, inaccurate records, disputed trades, delayed closeout, or compliance findings, even if the ransomware itself is contained.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	CP-2 — Contingency Plan	Trading fallback after ransomware depends on preplanned continuity procedures.
	AU-2 — Audit Events	Manual trading needs traceable evidence of approvals, handoffs, and execution steps.
	AC-6 — Least Privilege	Fallback processing should keep manual access tightly limited during degraded operations.
Recommendation — Document and test fallback trading procedures before an outage occurs. Define and retain audit evidence for every manual trade action during recovery. Restrict manual recovery access to the minimum roles needed for trading continuity.
NIST CSF 2.0	RC.RP-01 — Recovery Plan Execution	The scenario is about restoring and operating services during recovery after ransomware.
	RS.MA-01 — Response Planning and Resources	Banks need defined response resources and sequencing to keep operations running under attack.
Recommendation — Execute and rehearse recovery procedures that preserve critical trading operations. Assign response resources for manual trading and outage coordination before incidents occur.

Practitioner Guidance

What to prioritise: Keep the fallback process narrow. Allow only the trades, products, and counterparties that can be processed with the lowest reconciliation risk, and pause anything that depends on brittle downstream integration or ambiguous approval paths.

What to verify: Before trusting the manual process, verify that every trade captured during the outage has a clear instruction source, an accountable approver, a timestamped handoff, and a defined reconciliation owner. If any of those elements are missing, treat the trade as unresolved, not merely delayed.

Practitioner takeaway: The best recovery posture is not “operate as usual without systems”, it is “continue only where the bank can still prove control, traceability, and later reconciliation.”