PvP settlement with stablecoins: how atomic FX legs remove Herstatt-style exposure

PvP settlement with stablecoins means the two legs of a foreign exchange trade are exchanged so that one currency moves only if the other does, and neither party holds the other's principal for any meaningful interval. When both legs are stablecoins on the same public blockchain, a settlement contract can make the exchange atomic: both transfers succeed in one transaction or neither does. When one leg is fiat, the exchange can be made near-atomic by locking the token leg in escrow and releasing it against proof of the fiat credit. This article explains what atomic and near-atomic mean in operational terms, the controls a treasury needs before running the first trade, how the flow looks step by step, and the cases where stablecoin PvP does not apply.

Why does an FX leg carry principal risk at all?

In a conventional gross FX settlement each party pays its leg through its own currency's clearing system. Those systems close at different hours, so one party's leg usually becomes irrevocable before the other party's leg is even released. The party that has paid holds an exposure equal to the full notional of the trade, not the mark-to-market difference, until the counter-leg is confirmed final. That is principal risk, and it was named Herstatt risk after Bankhaus Herstatt was closed by German regulators on 26 June 1974 having received Deutsche Mark legs while its US dollar legs were still unpaid in New York.

The BIS Principles for Financial Market Infrastructures address this directly. Principle 12 says an exchange-of-value settlement system should eliminate principal risk by conditioning the final settlement of one obligation on the final settlement of the other. CLS applies that principle to the major currency pairs. Below the CLS threshold, and for pairs and counterparties outside it, most institutions still settle gross and simply accept the window. A treasury can measure its live principal exposure with one report: every trade where its own leg is irrevocably paid and the counter-leg is unconfirmed, summed by counterparty. In a cross-time-zone book that number is typically at its highest overnight, when nobody is watching it.

What does atomic settlement mean on a stablecoin rail?

A blockchain transaction either executes completely or reverts completely. A settlement contract that holds both tokens and releases them in one transaction therefore cannot produce a state in which one party has been paid and the other has not. That is what atomic means here: not fast, but indivisible. The release condition is written into the contract, typically signatures from both parties or their custodians plus a check that each deposit matches the agreed amount. If either deposit is short the release reverts and both deposits remain claimable by their owners.

Three operational details matter. First, both legs must be the issuer-native version of the token on that chain. A bridged or wrapped representation carries bridge risk on top of issuer risk, and a treasury should not treat it as the same asset. Second, atomic within a block is not the same as final for accounting. On chains with probabilistic finality the treasury still applies its confirmation-depth policy before posting the ledger entry, so the exposure is not zero, it is the residual reorganisation risk during the confirmation window. Third, the transaction hash of the release is a single reference that proves both legs. The ledger should post two entries, one per currency, against that one hash, and the reconciliation rule is that no entry may exist without it.

What does near-atomic mean when one leg is fiat?

A fiat leg on Fedwire, SEPA, EFT or a local clearing system cannot be made conditional on an on-chain event. The practical answer is to make the token leg conditional on the fiat leg instead, and to bound the window. The party delivering the stablecoin locks it in an escrow contract with a time-lock. The party delivering fiat then pays through the normal rail, quoting the trade's UETR in the end-to-end reference. When the fiat credit is visible on the statement, typically through a camt.053 or camt.054 message or a direct account feed, the escrow is released to the fiat payer. If no credit arrives before the time-lock expires, the token returns to its owner automatically.

Under that design the party locking the token holds no principal risk, only the opportunity cost of the locked balance. The party paying fiat holds an exposure for the interval between its fiat becoming irrevocable and the escrow release, which should be minutes, and which is bounded above by the time-lock and by the counterparty's obligation in the settlement agreement to release promptly. That is what near means: a window measured in minutes, with a defined ceiling and a defined remedy. Instant fiat rails such as FedNow, RTP or SEPA Instant compress the window further because the credit is final on receipt. ACH does not, because an ACH credit can be returned, and a treasury should not release escrow against an ACH credit that is still inside its return window.

Which controls does a treasury need before running PvP on chain?

The controls are unglamorous and mostly contractual. An examiner or an internal auditor will want to see each of the following, and will ask for the evidence that it was tested before the first live trade.

• A written settlement agreement that names the chain, the token contract addresses for each leg, the escrow or settlement contract address, the exact release condition and the time-lock duration.
• An address whitelist under change control, so outbound legs go only to counterparty addresses that were confirmed through an out-of-band test transfer and recorded with the approver's name.
• A confirmation-depth policy per chain that states how many confirmations count as final before the ledger is updated and the pacs.002 completion status is sent.
• Dual control on the manual fallback path, so that no single operator can release a leg outside the contract if the automation fails.
• Wallet screening and sanctions checks on the counterparty address before the trade is agreed, with the screening result attached to the trade record rather than run afterwards.
• An intraday one-leg-moved report that lists every trade where one leg has settled and the other is unconfirmed, with a named owner and a time limit for escalation.

A PvP contract does not remove counterparty risk from the relationship. It removes principal risk from the settlement. Pricing, credit lines and the decision to trade at all stay exactly where they were, with the treasury.

How does the trade flow look step by step?

For a two-stablecoin trade the flow is short. The rate and amounts are agreed and a UETR is generated for the trade. Each party confirms the trade with a pacs.009 or a bilateral confirmation carrying that UETR. Each party funds its leg into the settlement contract from its whitelisted operating wallet. The contract verifies both deposits and executes the release in one transaction. The transaction hash is recorded against the UETR. Each party's confirmation service watches the chain, applies the confirmation-depth policy, and emits a pacs.002 with status ACSC when the depth is reached. The ledger posts both currency entries against the hash and the UETR. If the release reverts, the pacs.002 carries RJCT with a reason code and the deposits are withdrawn under dual control.

For a stablecoin-against-fiat trade the token party locks its leg and shares the escrow transaction hash. The fiat party sends a pacs.008 or an MT103 with the trade UETR in the end-to-end reference. The token party's statement feed matches the incoming credit to the UETR, applies the release, and records the release hash. Two references now exist for one trade, the fiat clearing reference and the release hash, and both should be stored on the same trade record. The reconciliation rule is simple: one UETR, one fiat reference, one hash, and the trade is closed only when all three are present.

Where does stablecoin PvP not apply?

The model has clear edges, and a treasury should write them down before a sales team promises otherwise. It does not apply where the fiat leg runs on a rail that permits returns after credit, such as ACH or card rails, because the release condition would rest on a credit that is not final. It does not apply where the currency pair has no regulated stablecoin on a shared chain, which as of mid-2026 still describes most currencies outside the US dollar and a small number of others. It does not apply where one party cannot hold tokens under its own licence or charter conditions, in which case that party needs a custodian or an agent to hold the leg on its behalf, and the agreement must say who bears the risk in the interval.

Two further cases deserve care. Where the two tokens live on different chains, cross-chain atomic swaps are technically possible but any bridge in the path introduces a third party whose failure would strand one leg. The safer design is escrow on both chains with matched time-locks, which is near-atomic rather than atomic. And where a pair trades in high volume between the same two counterparties, bilateral netting may reduce gross exposure more efficiently than settling every trade PvP. Netting changes the risk from principal to replacement cost, which is a smaller number, and a treasury may reasonably prefer it for intraday flow while keeping PvP for large or one-off trades.

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. Settlement runs in regulated stablecoins such as USDC and USDT on public blockchains, completing in minutes with on chain auditability, and customers keep custody of their own wallets, which is the precondition for a treasury to fund an escrow leg from a whitelisted address it controls. The platform is ISO 20022 native, so a PvP trade can be confirmed with pacs.009, tracked end to end by UETR, and closed with a pacs.002 status report, while fiat legs arrive over SWIFT or local rails such as ACH, SEPA and EFT. Wallet screening, sanctions and PEP screening and a tamper evident audit trail sit in the same workflow, so the counterparty address is screened before the trade rather than after. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.