Payments and Market Infrastructure
The Global Risks Alliance (GRA)
Infrastructures and participants test their resilience through scenario tests, failover and recovery tests, threat-led penetration tests and market-wide exercises. Testing shows whether plans work under severe but plausible disruption. This page sets out the main test methods, what each can and cannot show, the records they produce, and who decides what is tested.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 2
Activity and exposure, for this page
Keyboard, with the map focused
Hold Ctrl or ⌘ and scroll to zoom
Latest available
NASA GIBS / EOSDIS · ASTER GDEM (METI, NASA) · Blue Marble (NASA) · © OpenStreetMap contributors (ODbL) · Natural Earth
Loading the latest NASA imagery.
Drag to move. Ctrl or ⌘ and scroll, pinch or the buttons to zoom; hover for the values under the pointer; reset returns to the region.
For operational test methods, in GRA's spatial-finance reading, the map opens on night lights and population density with built-up and settlement extent from NASA GIBS, framed on the United Kingdom and Ireland; every other NASA layer, live feed and forecast waits in the layer list.Satellite and model products as NASA publishes them, each with its own date; indicators, not assessments of any place; claim ceiling INTEGRATED.
Layers and dates
Operational resilience test methods are the ways infrastructures and participants check that critical services survive disruption: scenario tests against impact tolerances, failover and recovery tests, threat-led penetration tests and market-wide exercises. Authorities, boards, testing teams and exercise coordinators decide what is tested.
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Operational test methods · RTGS system · Business day 193
Failure exercises and recovery assumptions. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Severe but plausible scenarios test whether important services stay within impact tolerances. Scenarios that are too mild give false comfort.
Threat-led penetration tests use realistic attacker techniques against live systems, under controlled conditions, to find weaknesses.
Exercises across many institutions and authorities test communication, decisions and shared dependencies that single-firm tests miss.
Testing produces findings. Without remediation tracked to closure, the same weaknesses appear in the next test.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Severe but plausible scenario | A disruption scenario extreme enough to test resilience yet realistic enough to occur. |
| Failover test | A test that switches operations to a backup system or site to confirm it works. |
| Red team | A group that simulates attackers to test an organization's defences. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Threat-led penetration tests completed | count | annual | Authority records | OFFICIAL |
| Failover tests to secondary sites | count and success rate | annual | Operator records | DECLARED |
| Market-wide exercises held | count | annual | Authority publications | OFFICIAL |
| Findings remediated within deadline | share of findings | periodic | Remediation tracking | DECLARED |
| Services tested against impact tolerance | share of important services | annual | Self-assessments | DECLARED |
| Recovery time achieved in tests | hours | per test | Test reports | OBSERVED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| ECB TIBER-EU framework and annual reports | Red-team testing framework and summary findings | Free, ECB terms |
| Bank of England CBEST and SIMEX reports | Threat-led testing and market-wide exercises | Free, Bank of England terms |
| DORA regulatory technical standards on threat-led penetration testing | EU testing requirements | Free, EU reuse terms |
| G7 Cyber Expert Group fundamental elements | Principles for threat-led testing and third-party risk | Free to read, terms to check |
| Hamilton series exercise reports and similar public summaries | Cross-sector exercise findings | Free to read, terms to check |
Payments and Market Infrastructure prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Authorities | Which institutions must run threat-led tests and exercises | Test frameworks and sector risk evidence |
| Boards | Which services and scenarios to test and how to fix findings | Test results and remediation status |
| Testing teams and providers | How to design and conduct tests safely | Framework requirements and methods |
| Exercise coordinators | Which scenarios to run across the market | Threat evidence and previous findings |
Plans and recovery targets are only as reliable as the tests that verify them. Many infrastructures meet their recovery objectives in planned tests but have never faced a realistic, destructive scenario involving several institutions at once. Credible testing exposes assumptions, such as that backups are clean, that providers will be available or that staff can work from alternate sites, before a real crisis tests them.
Testing ranges from single-system checks to sector-wide simulations.
Switching to backup sites and systems to check recovery times. Planned tests may not reflect real conditions.
Testing by teams that simulate real attackers' techniques, under frameworks established by authorities in several jurisdictions.
Exercises that simulate disruption across infrastructures, participants and authorities, revealing interdependencies.
A common weakness revealed by exercises is the gap between technical recovery and business recovery. Systems may be restored within target, but reconciling positions, communicating with participants and resuming normal operations can take much longer. Tests that measure the full return to service, including data reconciliation across institutions, give a more honest picture of resilience.
Scenario selection, scope and success criteria. Test results depend heavily on design.
Measurement of recovery time and data loss against objectives, applying reliability and resilience engineering.
Structured review of what worked and what failed, with tracked follow-up.
Models of payment flows under disruption, applying network science and contagion, to complement live tests.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.