Stablecoin settlement business continuity: what to do when the chain, the node or the issuer fails

Stablecoin settlement business continuity is the plan for the hour the settlement layer itself stops working. Most payment institutions plan for a failed payment. Far fewer plan for a failed rail. When the settlement leg runs on a public blockchain, that rail is not yours. A network can halt. A node provider can go dark. Fees can spike past the value of a small payment. An issuer can freeze an address without asking you. None of that is exotic and all of it has happened. This is the failure map, the first hour, and the evidence a supervisor will ask for afterwards.

What does business continuity mean when settlement runs on a public blockchain?

It means what it always meant. Keep the service running, stay inside policy, and be able to prove what you did.

The supervisory frame is not new. The FFIEC IT Examination Handbook booklet on Business Continuity Management, published in November 2019, expects an institution to identify its critical business functions, set a recovery objective for each, and test them. The Basel Committee on Banking Supervision asks for the same discipline across third parties in its March 2021 Principles for Operational Resilience.

What changes is the shape of the dependency. A correspondent bank is a counterparty you hold a contract with. A public blockchain is not. There is nobody to escalate to and no service level agreement. Your node provider has one. Your custodian has one. Your stablecoin issuer has terms. The chain itself has none.

So the plan cannot be a call list. It has to be a set of decisions taken in advance, with named owners and stated limits, because the team on shift will not have time to invent them.

Which parts of a stablecoin settlement path can actually fail?

Map the path before you plan for it. One cross border payment touches at least seven components, each failing in its own way.

The chain can stop. Solana's mainnet beta halted block production for roughly five hours on 6 February 2024, according to Solana's published network status history. A halted chain does not lose funds. It does freeze every payment in flight on that chain until block production resumes.

The chain can also stay up and become unusable. Congestion delays inclusion and raises the fee. On a fee market a small payment can cost more to send than it is worth. That needs a threshold written down before the day it bites.

Your view of the chain can fail while the chain is healthy. Most institutions read the ledger through a node or an RPC provider. If that provider degrades, your platform sees stale balances and missing deposits. The worst version is silent. The connection answers, the data is behind, and reconciliation looks wrong.

Finality can move under you. A transfer that looked settled can be reorganised out if your confirmation depth was too shallow. Depth is a policy choice, not a default. Under proof of stake the Ethereum Foundation's documentation describes a block as finalised after two epochs, roughly thirteen minutes.

The issuer can act. The USDC token contract carries a blacklist function the issuer can call, as Circle documents for the contract, and a blacklisted address can neither send nor receive. That is a compliance feature working as designed, and it can still strand a payment you were in the middle of.

Then come the parts you already plan for. Custody and key access, the payout partner on the fiat leg, and your own platform.

What should a settlement continuity runbook do in the first hour?

The first hour decides whether this becomes an incident or a mess. Work in a fixed order.

• Confirm the failure and name it. Check the chain's own status page, a second independent node and a public explorer before touching anything. Many incidents are a node problem rather than a network problem, and the fix is different.
• Stop new settlement on the affected chain. One switch, one owner. Payments already instructed are a separate queue from payments not yet sent.
• Classify what is in flight. Not sent, sent and unconfirmed, confirmed but not credited, credited but not paid out. Each state has a different action and a different client message.
• Hold, do not retry. A retry against a degraded chain is how one instruction becomes two. Queue it and record the decision instead.
• Tell the affected clients, with a time for the next update. Say what is held and what is not. Silence is what turns an outage into a complaint.
• Decide on the fallback against the limit you set in advance. A second chain, a second stablecoin, or waiting. Waiting is a legitimate choice when you say so and record it.
• Keep the compliance controls on. Screening, Travel Rule data and approvals apply to the fallback exactly as they applied to the original path.
• Log every step with a timestamp, the decision, the owner and the reason. Write it while it happens, not afterwards.
• Check the reporting clock. Regulation (EU) 2022/2554, the Digital Operational Resilience Act, applicable from 17 January 2025, requires financial entities in scope to report a major incident affecting information and communication technology to their competent authority.

Keep it to one page. A stablecoin settlement business continuity plan is tested by use, not by review.

A retry is the most expensive reflex in payments. On a degraded chain it is how one instruction becomes two, and the second one is nobody's to reverse.

How do you keep payments moving without breaking policy?

A fallback only counts as a fallback if it was approved before the incident.

That means naming the alternative in advance. A second chain for the same stablecoin is the simplest option, because neither the asset nor the issuer changes. A second stablecoin is a bigger step, since it moves the issuer, the reserve and the redemption path. Either one has to sit in the policy, the custody configuration, the screening rules and the client agreement before the day you reach for it.

It also means knowing what you will not do. Sending on a chain the client never approved, or one your custodian cannot support, converts an availability problem into a compliance problem. The fiat leg follows the same rule. A manual workaround that skips an approval is not continuity.

And it means being able to say no. Some payments should wait. A low value payment during a fee spike is better held with a clear message than forced through.

What evidence does a supervisor expect after a settlement outage?

Assume the incident will be read by someone who was not there.

They will want the timeline, the decisions and the authority behind each one. Who declared the incident. Who stopped settlement. Who approved the fallback, and under which policy. They will want the affected payments with the final state of each, and the client messages with timestamps.

They will also want proof that the controls held. That screening ran on the fallback path. That Travel Rule data travelled with the payment. That nothing settled outside an approved route.

Keep the file for as long as the record keeping rules demand. In the United States, section 1010.430 of title 31 of the Code of Federal Regulations requires records under the Bank Secrecy Act to be retained for five years.

Then close the loop. A post incident review that changes a threshold, a fallback or an owner is worth more than one that produces a narrative.

What usually goes wrong with settlement continuity planning?

The failures repeat, and most are planning gaps rather than technical ones.

A plan written for the platform and not the rail. It covers your own outage in detail and says nothing about the chain, the node provider or the issuer.

One node provider and no second opinion. Without an independent source you cannot tell a network halt from your own connectivity.

No confirmation depth policy, so finality is whatever the integration defaulted to on the day it was built.

A fallback chain that lives in a slide rather than in the custody configuration, the screening rules and the client agreement.

No fee threshold, so operations improvises during congestion.

No rehearsal. Point the platform at a dead node on a quiet day, run the classification, use the switch and time it. That one exercise tells you your real recovery time.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. It settles in regulated stablecoins on public blockchains, in minutes, with on chain auditability, and it is chain agnostic by design, so a fallback route is a configuration rather than a project. It is ISO 20022 native, producing pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns under a head.001 envelope, tracked end to end by UETR. That matters during an incident, because every payment carries its own status message and its own transaction hash. Compliance is built in: KYB and KYC onboarding, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101, a compliance workbench and a tamper evident audit trail, so the controls follow a payment onto a fallback path. Universal Compliance Control, the SpendTheBits submission named a finalist in the Swift Hackathon 2026 Technical Challenge, applies the same idea to settlement itself: an off chain compliance oracle issues one signed attestation and on chain gates enforce it identically across chains, so no valid attestation means no settlement. SpendTheBits is a Bank of Canada registered payment service provider.