A chain selection policy for corridor settlement: which blockchain settles which corridor, and how to prove it

A chain selection policy is a written and approved document that states which public blockchain settles each payment corridor an institution operates, the criteria used to make that choice, and the process for changing it. It turns the choice of chain from a preference of whoever built the integration into a governed operational decision with an owner, a review date and an audit trail. The policy sits next to the digital asset risk assessment and the ISO 20022 message standards, and it is approved by the same committee that approves new settlement counterparties. This article sets out what the policy decides, the criteria it weighs, how the decision is recorded, and how a corridor moves from one chain to another without changing a single field in the pacs.008.

What does a chain selection policy actually decide?

The unit of decision is the corridor, not the institution. A corridor is a sending jurisdiction, a receiving jurisdiction, a settlement asset and a set of named counterparties, for example USD out of Canada into Mexico settled in USDC with two named exchange houses. For each corridor the policy records a primary chain, a fallback chain, the stablecoin and the token contract address that count as the settlement asset on each, the confirmation rule the operations team applies, and the conditions under which the fallback is used. It does not decide which chains are acceptable in the abstract. That question belongs to the digital asset risk assessment, which produces an approved list. The chain selection policy chooses from that list.

Two things are deliberately kept out of the policy. The first is the ISO 20022 instruction itself, which describes who is paying whom and how much, and which must not change when the settlement layer changes. The second is the wallet operating procedure, which describes how keys are held and how the operating wallet, the till, is funded and swept. The policy references both but owns neither.

Which criteria belong in the policy?

The criteria must be observable and re-measurable, because the policy will be reviewed and the reviewer must be able to reproduce the score. Five criteria cover most corridors.

• Finality time is the elapsed time from broadcast to the point at which the institution treats the transfer as irreversible, expressed as the confirmation rule the operations team applies, for example a validated ledger close on XRP Ledger or Stellar, or a finalised checkpoint rather than a single block on Ethereum.
• Fee volatility is the cost of a standard token transfer in fiat terms over a trailing window, recorded at the peak as well as the median, because a corridor priced on median fees fails on the day of a congestion event.
• Stablecoin liquidity on that chain asks whether the settlement asset is natively issued on the chain by its issuer or is a bridged representation, and whether the counterparty can redeem or convert it at the receiving end without an extra hop.
• Counterparty support asks whether every named counterparty on the corridor can receive, custody and screen the asset on that chain, verified by a test transfer rather than a questionnaire answer.
• Screening coverage asks whether the institution's wallet screening vendor covers the chain, the address format and the specific token contract, so that a hit on that chain is as detectable as a hit on any other.

Each criterion gets a threshold, not just a score. Finality has a maximum in minutes that the treasury team has agreed it can carry as open exposure. Fee volatility has a ceiling in fiat per transfer at the observed peak. Liquidity has a minimum, such as native issuance only. Counterparty support and screening coverage are binary: a chain that a counterparty cannot receive on, or that the screening tool cannot see, is disqualified for that corridor regardless of how well it scores elsewhere. As of mid-2026, ledgers such as XRP Ledger and Stellar close in seconds with deterministic finality while Ethereum proof of stake finality is reached after two epochs and is measured in minutes. The policy does not restate such facts. It states the thresholds and records the measurement taken on the day of the decision.

How should the decision be documented and approved?

The output of the policy is a corridor register, one row per corridor, and a decision record behind each row. The register is the operational view: corridor identifier, primary chain, fallback chain, token contract address on each, confirmation rule, fee ceiling, screening vendor and coverage confirmation, counterparties confirmed, effective date and next review date. The decision record is the evidence: who proposed the assignment, what was measured against each criterion, which alternatives were rejected and why, who approved and when.

Approval should follow the existing new product or new counterparty route rather than a bespoke one. In most institutions that means the head of payments proposes, the compliance officer confirms screening coverage and the sanctions position of the chain's ecosystem, the treasurer confirms that the finality exposure is within limits, and the operational risk committee approves. Information security signs separately on the wallet and key arrangements for the chain, because those are controlled by a different document. The record is versioned and superseded versions are retained, because an examiner reviewing a transfer from last year needs the policy as it stood on that date, not the current one.

A chain is a settlement route, not a product. Treat it the way you treat a correspondent: onboard it, measure it, review it, and be able to leave it.

How do you change chains without changing the ISO 20022 instruction?

The separation that makes this possible is between the payment instruction and the settlement route. The pacs.008 carries the debtor, the creditor, the amount, the currency, the purpose and the UETR. None of those fields names a blockchain, and none should. The settlement route is an attribute held in the platform's routing table, keyed by corridor, and it is the routing table that maps a corridor to a chain, a token contract and an operating wallet. Changing the chain means changing a row in the routing table and the artefacts that hang off it. The message schema, the field mapping and the counterparty's parser are untouched.

In practice the switch runs as a controlled cutover. The new chain is added to the routing table as a fallback first and exercised with low value test transfers to each counterparty, with the resulting transaction hashes recorded against the UETRs. The pacs.002 status reports returned to the sending institution are checked to confirm that they carry the same status codes and comparable timings as before. On the effective date the routing table is updated to make the new chain primary. Payments already in flight on the old chain complete there; their pacs.002 and any pacs.004 return still reference the original UETR and the original chain, because the audit trail records the chain per transaction rather than per corridor. The old operating wallet is then swept to a small residual, kept under the same key controls until the review period has passed, and closed. Tracking by UETR is what lets an analyst reconcile a corridor across two chains during the transition.

What triggers a review of a corridor's chain assignment?

A policy without triggers is reviewed only after something has already gone wrong. The register should carry both a calendar review and a list of event triggers, and each event trigger should be tied to data the institution already collects and to the team that sees it first.

• The screening vendor drops or degrades coverage of the chain or the token contract, which the compliance team learns from the vendor's release notes and must treat as an immediate review.
• Peak transfer fees on the chain exceed the ceiling in the register on more than an agreed number of days in a month, which the treasury team sees in the settlement cost report.
• The issuer of the settlement asset changes its native issuance on the chain, pauses the contract or announces a migration, which the treasury team learns from the issuer's notices.
• A counterparty on the corridor gives notice that it is withdrawing support for the chain, or a scheduled test transfer to that counterparty fails.
• A regulator or sanctions authority takes an action that touches the chain's ecosystem, such as a designation of infrastructure or of a mixing service that carries a large share of the chain's flow.
• A finality incident, such as a chain halt or a reorganisation deeper than the confirmation rule assumed, is logged as an operational incident and forces a review regardless of the calendar.

Each trigger names the team that observes it and the action it starts, which is usually to move the corridor to its fallback chain under the same cutover procedure described above. That is why the fallback chain must be live and tested rather than nominal. A fallback that has never carried a transfer is a line in a document, not a control.

What does an examiner or auditor expect to see?

An examiner will not assess whether the chosen chain was the best one. They will assess whether the institution can show that the choice was made deliberately, against stated criteria, by people with authority, and that it is monitored. The documents that satisfy that are the approved policy with its version history, the corridor register, the decision records, the evidence of test transfers with hashes and UETRs, the trigger log showing reviews that were opened and closed, and the minutes of the approving committee. For a corridor that has changed chains, they will want the cutover plan, confirmation that in flight payments completed, and the sweep and closure record for the old wallet.

Internal audit will additionally test that the routing table in production matches the register. A discrepancy between the two is the most common finding, because engineers change routing to resolve an incident and the register is updated later or not at all. The control is a periodic reconciliation of routing table to register, with exceptions raised to the policy owner. Where the platform records the chain and the transaction hash per UETR in a tamper evident audit trail, that reconciliation can be run from the audit trail itself rather than from screenshots.

Where StableNet fits

StableNet, built by SpendTheBits, settles cross border B2B payments in regulated stablecoins such as USDC and USDT on public blockchains and is multi-chain by design, so the chain is a routing attribute per corridor rather than a property of the integration. Because the platform is ISO 20022 native, the pacs.008 instruction, the pacs.002 status report and any pacs.004 return travel inside head.001 envelopes and are tracked end to end by UETR, and the on chain transaction hash is recorded against that UETR in a tamper evident audit trail. A corridor can therefore move from one chain to another without any change to the message a bank or MSB sends, and the audit trail shows which chain carried each transfer. Wallet screening covers the chains the platform settles on, and customers keep custody of their operating wallets throughout. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.