Operational resilience testing

What operational resilience testing includes

We test what happens to money in flight when infrastructure or a provider fails: card authorisations, transfers, payouts, withdrawals, and orders. The requirements behind the tests are on the DORA testing requirements and RPAA testing requirements pages; this page sets out test scope. Legal sources were checked on 2026-09-16.

Resilience scenarios for critical services

• Function to component map. Each critical service from your business impact analysis maps to its API gateway, database, message queue, ledger, scheduler, and provider connections. One scenario covers one failed component and states the pass condition as money state: each acknowledged request ends in one final state, and no ledger entry is missing or duplicated.
• Scenario set. Commission Delegated Regulation (EU) 2024/1774 Article 26(2) lists scenarios that response and recovery plans take into account, including (a) cyber-attacks and switchovers to redundant capacity, backups, and redundant facilities, and (b) failure of any relevant ICT third-party service provider. Our executable set adds software failure modes: loss of a cloud region, promotion of a database replica, loss of the queue broker, an expired TLS certificate on a provider connection, and a DNS failure.
• Degraded modes. When the ledger is unavailable, card authorisation declines, approves against a cached balance within a stand-in limit, or queues. The test checks that the service uses the mode in your continuity plan, and that queued items post exactly once when the ledger returns.

Failover and recovery time

• Switchover under load. Region and database switchovers run while synthetic traffic sends authorisations, transfers, and withdrawals. The checks look for acknowledged requests that disappear, client retries that create a second charge (the payment idempotency guide shows the retry cases), and a payout scheduler that starts in both regions and sends each payout twice.
• Recovery measured per function. Recovery time runs from the injected fault to the first successful end-to-end transaction and to a drained backlog. Recovery point is the gap between the last acknowledged ledger entry and the last entry present after recovery. A database that is back within its target while the transfer API still rejects requests fails the function.
• Backup restore. A ledger backup restores into a segregated environment. Balances then reconcile against processor and bank settlement files for the same period, and transactions a counterparty confirmed after the backup point are listed as breaks (ledger reconciliation testing guide).
• Failback. Traffic returns to the primary site. The checks cover replication direction, ID sequence collisions, and jobs that ran on the secondary site and run again on the primary.

Third-party provider outage simulations

Each provider connection gets five fault shapes: connection refused, timeout after the provider accepted the request, slow responses, an error burst, and late webhooks or files after recovery. Provider connections by segment:

• Acquiring, neobank, business banking, BaaS. Card processor and scheme connections, the 3-D Secure server, the partner bank core, and settlement files over SFTP. A timeout after acceptance leaves the outcome unknown; the test checks that the product queries the status before a retry and shows "pending", never "failed".
• Remittance. Payout partners per corridor. A payout rerouted to a second partner after a timeout pays the recipient twice when the first partner also completes it.
• Crypto exchange. Node and RPC providers and custody services. A withdrawal service that re-signs an already broadcast withdrawal after recovery sends the funds twice.
• Trading. Market data feeds and broker or exchange connectivity. The test checks that the order service stops accepting market orders priced against stale quotes.
• Open banking. Bank APIs. A payment initiation that times out may still execute at the bank, so the test checks that the product reads the payment status before it offers a new attempt.

The tests also check that circuit breakers open and close, and that retries after recovery stay inside provider rate limits. Delegated Regulation 2024/1774 Article 25(2) requires continuity tests to contain testing of services from ICT third-party service providers where applicable, and to duly consider provider insolvency or failure scenarios where relevant. Where your exit strategy names a secondary provider, the simulation routes test traffic to it and back.

Evidence records

Each run records the scenario, the injected fault, fault and recovery timestamps, measured recovery time and point, the reconciliation result, and defects with retest status. The mapping names DORA and Delegated Regulation 2024/1774 articles. The same records support recovery plan tests under SOC 2 criterion A1.3 and backup and redundancy controls 8.13 and 8.14 of ISO/IEC 27001:2022. Threat-led penetration testing and peak load testing are outside this service.