Financial Cyber and Operational Resilience
The Global Risks Alliance (GRA)
Finance runs on records: account balances, positions, policies and transactions. An attack or error that corrupts or destroys them is harder to recover from than an outage, because the firm must restore a correct state. This page sets out how data integrity and availability are threatened and protected, how recovery is measured, and who decides.
GRA · In development · service level R0
Data integrity and recovery is the protection of financial records such as balances, positions and transactions against corruption or loss, and their restoration to a correct state. It depends on isolated backups, recovery points and reconciliation. Technology and data leaders, boards, supervisors and industry bodies hold the decisions.
How a failure at one financial centre can spread through settlement links. Design links, not real dependencies.
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Data integrity and availability · Bank B services · Self-assessment 3
| Make a payment | 3 | 2 | Cloud region loss | Within |
| Access cash | 13 | 18 | Cyber attack | Within |
| Mortgage servicing | 62 | 42 | Data centre loss | Within |
| Claims payment | 25 | 50 | Third-party failure | Outside |
people · process · technology · third parties
Confidentiality, integrity and continuity. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Replication copies corrupted data to secondary sites. Without immutable, isolated backups, there may be no clean copy to restore.
The time between the last clean copy and the incident sets how much data must be reconstructed from other sources.
After recovery, balances and transactions must be reconciled with counterparties and infrastructures to confirm the restored state.
Incorrect data sent to payment systems, clearing houses or customers spreads the problem beyond the firm.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Recovery point objective | The maximum acceptable amount of data loss, measured as time since the last good copy. |
| Immutable backup | A backup that cannot be changed or deleted for a set period. |
| Reconciliation | Comparing records with counterparties or other sources to confirm they agree. |
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 |
|---|---|---|---|---|
| Critical data with immutable backups | share of critical datasets | periodic | Firm records | DECLARED |
| Recovery point objective for critical data | minutes or hours | on review | Firm standards | DECLARED |
| Restore tests from isolated backups | count and success rate | annual | Test records | DECLARED |
| Time to reconcile after restore | hours | per test or incident | Test records | OBSERVED |
| Data corruption incidents | count | annual | Incident records | REPORTED |
| Participation in data vaulting arrangements | yes or no | on change | Firm and industry records | DECLARED |
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 |
|---|---|---|
| Sheltered Harbor standard and participant information | United States industry standard for data vaulting and restoration | Free to read, terms to check |
| CPMI-IOSCO cyber guidance on data integrity | Expectations for recovering correct data | Free, BIS terms |
| NIST special publications on data integrity | Guidance on detecting and recovering from data corruption | Public domain |
| DORA requirements on backup and restoration | EU backup and recovery expectations | Free, EU reuse terms |
| Post-incident reports involving data corruption | Lessons from integrity incidents | Public records, terms per publisher |
Financial Cyber and Operational Resilience 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 |
|---|---|---|
| Chief technology and data officers | How to protect and recover critical data | Backup architecture and test results |
| Boards | What recovery points are acceptable for critical services | Impact analysis and cost evidence |
| Supervisors | Whether data recovery capabilities meet expectations | Test evidence and incident reviews |
| Industry bodies | Whether to establish shared vaulting or restoration arrangements | Standards and participation |
Confidentiality breaches dominate headlines, but integrity and availability failures can stop the financial system working. A bank that cannot trust its own ledger cannot safely open for business.
Breaches harm customers and enable fraud, and carry legal and reputational consequences.
If records cannot be trusted, transactions cannot be settled with confidence.
Encryption by ransomware or outages can make data unavailable just when it is needed.
Backups that attackers cannot alter or delete. Limits: restoring large systems takes time.
Cryptographic checks and reconciliation to detect alteration, grounded in cybersecurity and cryptography. Limits: subtle manipulation can go undetected.
Testing that restoration works within tolerances. Limits: full-scale tests are disruptive.
Industry initiatives to preserve critical account data for recovery. Limits: coverage and governance vary.
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.