FCA FG26/6 Crypto Operational Resilience Checklist

Video transcript

From October 25, 2027, the FCA's operational resilience rules reach qualifying crypto firms. Its guidance, F G 26 slash 6, shows how they apply to code, keys and validators.

It names four crypto-specific risks: code vulnerabilities, private key security, validator risk and service disruption. The FCA says the list is not complete.

For keys, the guidance lists emerging practices like multi-party computation, multisig and hardware security modules. They should avoid centralizing risk: key shares in one cloud account are still one point of failure.

Every important service needs an impact tolerance, like four hours for the example custodian. The guidance also suggests metrics such as error rates for critical smart contracts. These are illustrations, not FCA limits.

Firms must test against severe but plausible disruption, like smart contract failure, validator outages, oracle manipulation and insider threats. Scans and pentests should be proven to identify and address risks.

Map each expectation to a record a supervisor can read: services and tolerances, dependency maps, test results with fixes, a provider register, and a self-assessment approved by your governing body.

Guardian's resilience assessment maps onchain dependencies and runs scenarios like key compromise and a chain halt. Guardian audits and pentests produce the testing evidence, and Managed Security monitors contracts on every block.

Read the full checklist below, and talk to Guardian about turning F G 26 slash 6 into evidence.

FG26/6 is the FCA's finalized guidance on operational resilience for cryptoasset firms. It was published on June 30, 2026, with the final crypto rules.

It explains how SYSC 15A applies to them. That chapter reaches qualifying cryptoasset firms on October 25, 2027, when the FCA's crypto instruments come into force.

Our UK crypto deadlines post has the dates. This post covers the controls, and the evidence for each.

This article explains the technical and security side of the FCA's FG26/6 Guidance on Cryptoasset Operational Resilience. It is not legal advice; confirm how it applies to you with counsel.

What FG26/6 Covers

FG26/6 is non-Handbook guidance. PS26/13 applies SYSC 15A to crypto firms without change, and FG26/6 shows how it works through five fictional firms.

It draws on SYSC 4 (risk management), SYSC 7 (risk control), SYSC 8 (outsourcing) and SYSC 15A. SYSC 15A does not apply to firms with a registered office outside the UK.

The four crypto-specific risks

FG26/6 names four risks that may happen more often in crypto than in traditional finance. It says the list is not complete.

It adds cyber risk. Firms should review the cyber response and recovery practices set out by the FCA, PRA and Bank of England, and the latest CBEST thematics.

Key, Cyber and Continuity Controls

Paragraph 3.2 sets out three focus areas for every stage of the framework.

Cyber and technology resilience

Firms should keep “robust and proportionate” cyber and IT controls over availability, data integrity and third-party dependencies, using recognized international standards.

Safeguarding keys and infrastructure

This covers firms that hold the means of access, such as private keys, and the infrastructure behind it, such as smart contracts or validator nodes. The FCA lists emerging practices:

• multi-party computation (MPC)
• multisignature and threshold key management
• hardware security modules (HSMs)
• zero-trust defense architecture
• distributed storage
• cold and warm wallet segregation
• cryptographic audit logs

It adds a condition: these tools “should be used in a way that avoids centralising risks”. For example, MPC shares that all sit in one cloud account are still one point of failure.

Continuity and disruption planning

Plans should be tested and regularly updated. Scenarios should reflect the firm's activities, such as smart contract failure, failed stablecoin reconciliation technology and validator outages.

Targeted vulnerability scans and pentests “should be carried out and proven to identify and address risks”. Firms should also be able to evidence monitoring and logging.

Services and Impact Tolerances

SYSC 15A.2.1R requires firms to identify important business services. A firm running several activities, such as custody and staking, should name each separately.

SYSC 15A.2.5R then requires an impact tolerance for each. FG26/6's example firms set these:

These are illustrations, not FCA limits. Tolerances are measured in time “and any other relevant metrics”, and FG26/6 suggests three:

• transaction throughput or confirmation latency thresholds
• error rates for critical smart contracts
• transaction success rates

Markets run 24/7 and spike suddenly. FG26/6 suggests shorter maximum downtimes for trading engines, and for hot wallet access, during high volatility.

Its custody example loses access to part of its key management system. It pauses withdrawals for forensic checks but restores read-only access to wallets.

Set your degraded modes, and when to use them, in advance.

Mapping and Scenario Tests

SYSC 15A.4.1R requires firms to document the people, processes, technology, facilities and information behind each important business service.

Where there is no contract, as with some permissionless DLTs, firms must strengthen internal controls and monitoring (paragraph 8.5).

That may involve onchain and offchain transaction monitoring, stress-testing node connectivity and “regular independent audits of smart contracts”.

Scenarios to test

SYSC 15A.5 requires a testing plan and tests against severe but plausible disruption. FG26/6 gives crypto examples (paragraph 9.6):

Firm D, the custodian, tests hot wallet compromise, cold storage access failure, internal access breaches and its MPC protocols. The tests check it can restore access from secure off-site recovery systems.

Its lessons learned found a gap in its visibility over outsourced key management hardware. It formalized assurance with the vendor and added its own health checks.

Every test and real disruption needs a lessons learned exercise with a written record (SYSC 15A.5.8R and 15A.6.1R).

Critical Providers and Outsourcing

Under SYSC 8.1.12G, a firm should notify the FCA when it intends to rely on a third party for critical or important operational functions. In crypto, FG26/6 says these could include:

• custody infrastructure, such as MPC and HSM providers
• validator services, such as third-party node operators
• cloud providers hosting trading, custody or settlement systems
• security-critical services, such as transaction signing infrastructure

Using a permissionless DLT should not be treated as outsourcing under SYSC 8.1.1R. Firms remain responsible for their own resilience.

For DeFi protocols, oracles and bridges, see our GC26/7 mapping checklist. For keys, see our CASS 17.4 checklist.

Evidence Checklist

Map each expectation to a record a supervisor can read. Rule numbers are SYSC; “FG” numbers are FG26/6 paragraphs.

What Guardian Does

Guardian's operational resilience assessment covers important services, impact tolerances and dependency mapping, onchain included: chains, RPC endpoints, oracles, bridges and custodians.

It runs scenarios such as key compromise, an unreachable signer quorum, a custodian outage and a chain halt, as tabletops and as technical tests.

Guardian's audits and pentests produce the code and security testing evidence. Managed Security monitors your contracts on every block, and its Shield service pentests your internet-facing systems around the clock.

Frequently Asked Questions

Is FG26/6 binding on crypto firms?

FG26/6 is non-Handbook guidance, not a rule. It explains how SYSC 15A, read with SYSC 8 on outsourcing, applies to crypto firms. SYSC 15A reaches qualifying cryptoasset firms on October 25, 2027. Ask counsel how the guidance bears on you.

Does FG26/6 require smart contract audits?

Not outright. It names code vulnerabilities as a crypto-specific risk. Where a firm has no contract with a dependency, it says stronger controls may include “regular independent audits of smart contracts”.

Which providers should a crypto firm tell the FCA about?

Those it intends to rely on for critical or important operational functions. FG26/6 lists MPC and HSM custody providers, third-party node operators, cloud hosts for trading, custody or settlement, and transaction signing infrastructure.

Sources

• FCA: FG26/6 Guidance on Cryptoasset Operational Resilience (PDF, June 30, 2026)
• FCA: PS26/13 Application of FCA Handbook for Regulated Cryptoasset Activities (PDF, June 2026)
• FCA: Overview of our cryptoassets regime policy statements (June 30, 2026)
• FCA: PS21/3 Building operational resilience, final rules for SYSC 15A (PDF, March 2021)