FCA Crypto Operational Resilience: Mapping Critical Services, Dependencies and Recovery Plans

By CRYPTOVERSE Legal Consultancy

The backup works, but customers still cannot withdraw

A crypto custody company is preparing its FCA authorisation application.

Its technology team has reassuring answers: encrypted backups, a second cloud environment and a disaster recovery plan. During a test, the company successfully restores its customer portal.

Then someone asks a different question:

“Can a customer actually withdraw their cryptoassets?”

The answer is no.

The wallet signing provider remains unavailable. The alternative environment depends on the same identity service that caused the original outage. Customer support can access account details but cannot confirm which withdrawal instructions have already been processed.

The company has restored a system. It has not restored the customer’s service.

That distinction should shape how crypto firms prepare their operational resilience framework.

What does operational resilience mean for FCA crypto authorisation?

Operational resilience means understanding which services matter most to customers and markets, how disruption could cause intolerable harm, and whether the firm can keep delivering those services within justified limits.

The FCA’s final policy in PS26/13 extends the SYSC 15A operational resilience framework to qualifying cryptoasset firms. Its accompanying guidance, FG26/6, explains how the framework applies to crypto business models, including custody, trading platforms, stablecoin issuance, staking and intermediaries arranging deals. These are final policy materials for the expanded regime, rather than merely consultation proposals.

For an applicant needing a UK Crypto Licence, the practical task is to connect regulatory requirements with the actual operating model. A policy should explain how the business works under stress, supported by evidence that management understands its dependencies and recovery limitations.

Start with the service customers receive

Technology inventories are useful, but the first question is what the customer needs the firm to deliver.

For example, “wallet infrastructure” describes a resource. “Enabling customers to withdraw their safeguarded cryptoassets” describes a service.

Under SYSC 15A.2.1R, firms must identify their important business services. The assessment considers the harm disruption could cause, including customer vulnerability, time sensitivity, access to alternatives and effects on financial markets. Each distinct relevant service should be assessed separately.

A practical assessment might begin with:

These are starting points for analysis. A firm should justify which services qualify in its own circumstances for UK Crypto staking FCA Authorisation.

Set impact tolerances around harm

An impact tolerance expresses the maximum tolerable disruption to an important business service.

It differs from a recovery target. A technology team might aim to restore a server within an hour, while customers could suffer intolerable harm sooner—or remain affected long after the server returns.

SYSC 15A.2.5R requires an impact tolerance for each important business service. SYSC 15A.2.9R requires firms to ensure they can remain within those tolerances during severe but plausible disruption.

When developing a tolerance, management should ask:

• When would customers begin experiencing serious harm?
• Does the answer change during volatile markets or peak demand?
• Could inaccurate data be more damaging than temporary unavailability?
• How many customers or transactions could be affected?
• Could disruption spread across services?

The FCA’s crypto guidance includes illustrative timeframes. Those examples are not universal regulatory deadlines. A firm needs its own reasoned assessment, using time and other relevant measures appropriate to the service.

Choosing a longer tolerance simply because recovery is difficult leaves the underlying harm unresolved.

Map the full delivery chain

A service map should reveal what must work for the customer to receive the service.

Under SYSC 15A.4.1R, firms must document the people, processes, technology, facilities and information needed to deliver each important business service. Mapping must be detailed enough to identify vulnerabilities and support remediation. Third-party dependencies also require sufficient understanding. 

For overseas UK FCA Authorisation Crypto Company withdrawal service, a useful map could cover:

The most valuable findings often concern shared dependencies.

Two cloud regions may still rely on one identity platform. Two wallet providers may use the same underlying infrastructure. A backup approver may be unable to act without the unavailable primary approver.

The map should expose these connections before an incident does.

Address blockchain dependencies explicitly

Crypto firms often depend on infrastructure they cannot directly control.

The FCA’s final policy treats the use of permissionless distributed ledger technology as outside the outsourcing arrangement requirements of SYSC 8. That treatment does not remove the dependency from operational resilience analysis.

FG26/6 distinguishes between dependencies under contractual control and external network risks. Where infrastructure lies beyond the firm’s control, the focus includes appropriate monitoring, internal controls and contingency arrangements.

For example, a firm could examine:

• How it detects stalled transactions or inconsistent network information.
• When it pauses deposits, withdrawals or affected trading.
• How it prevents duplicate processing when service resumes.
• What customers are told about pending transactions.
• Whether alternative connectivity provides genuine independence.

A node provider, validator operator or wallet vendor may also involve a separate contractual service. Analyse that relationship on its own facts.

Test the difficult scenarios

A successful backup restoration provides useful evidence about one capability. It does not establish that the complete service can withstand disruption.

SYSC 15A.5 requires an up-to-date testing plan and scenario testing against severe but plausible disruptions. Firms must consider adverse circumstances relevant to their business and learn from tests and actual incidents.

Useful crypto scenarios might include:

• A wallet signing outage during a sudden increase in withdrawals.
• Loss of access to a group technology team over a weekend.
• A cloud failure combined with unavailable identity services.
• Corrupted customer entitlement records.
• An execution venue outage leaving order status uncertain.
• A compromised communications channel during an incident.

For each test, record the assumptions, decisions, elapsed time and customer consequences.

If the test fails, identify the cause, assign an owner, fund the improvement and test again. A remediation plan becomes more credible when it explains what will change and how the firm will verify the result.

Write recovery plans that people can execute

A practical recovery plan should answer concrete questions:

Who can declare an incident?
Specify authority and deputy arrangements.

What happens to pending instructions?
Explain how the firm identifies, preserves and resolves them.

What must be checked before restarting?
Consider data integrity, customer entitlements, security and transaction status.

Can a reduced service operate safely?
Define its limitations and the controls needed.

Who communicates with customers, providers and regulators?
Prepare responsibilities, escalation routes and usable communication templates.

The FCA’s guidance recognises that resuming a degraded service requires judgment about customer and market consequences. Recovery should not increase harm or undermine other regulatory obligations.

Build a reviewable evidence pack

For application preparation, we recommend organising the evidence into:

1. A justified important business services assessment.
2. An impact tolerance assessment for each service.
3. Service maps and dependency analysis.
4. Testing plans, results and identified weaknesses.
5. Recovery procedures and communications arrangements.
6. A funded remediation register with accountable owners.
7. Management review records and a written self-assessment.

This is a practical organising structure, rather than a claim that every application requires seven separately named attachments.

SYSC 15A.6 requires a current written assessment covering matters such as services, tolerances, mapping, testing, vulnerabilities and communications. Each version must be retained for at least six years and supplied to the FCA on request.

Returning to the custody company

The company in our opening scenario revises its withdrawal service map for regulatory compliance advisory services.

It discovers that its recovery environment shares an identity dependency with the primary environment. It also identifies uncertainty about pending withdrawal instructions and inadequate weekend approval cover.

Its next exercise tests the complete withdrawal journey. Management can now see where recovery succeeds, where customers remain affected and which improvements require investment.

That gives the firm a much stronger basis for explaining its readiness.

How CRYPTOVERSE can support your preparation

CRYPTOVERSE is a specialist legal and regulatory firm for UK FCA cryptoasset authorisation support.

We can help connect operational resilience requirements with your proposed permissions, customer services, outsourcing arrangements and application evidence, working alongside your technology and operational teams.

Contact CRYPTOVERSE to assess whether your resilience documentation demonstrates how your business will protect customers during disruption.

FAQs