Introduction
Cross-border payments have always had two hard problems: speed and cost. A payment from Riyadh to Frankfurt can take two to three business days, pass through three or more correspondent banks, and lose value at every foreign exchange conversion along the way. Most of that friction is structural — baked into the correspondent banking model that has underpinned global payments for decades.
Now a new architecture is emerging. One where value settles in seconds on a blockchain, and ISO 20022 messages carry the instruction into that new world. Banks, fintechs, and payment service providers are actively exploring stablecoin rails — not to replace the payment instruction layer, but to replace the settlement layer.
This is not theory. SWIFT is piloting it. Fnality International is building it. The Stellar Development Foundation has published ISO 20022 mapping guidance for it. The architecture is being assembled right now, by institutions that move trillions of dollars every day.
This article walks through the entire picture — end to end, clearly, and without hype. We cover what stablecoin settlement actually is, where FX happens in a stablecoin payment flow, how ISO 20022 messages like PAIN.001 and PACS.008 evolve to carry blockchain data, and how a payment engine processes on-chain settlement — including Debit and Credit Party Derivation and reconciliation against an on-chain transaction hash.
Section 1: What Is Stablecoin Settlement?
The Problem with Traditional Cross-Border Settlement
In a traditional cross-border payment, settlement moves through a chain of correspondent banks. Bank A debits its Nostro account at an intermediary bank. The intermediary credits Bank B’s account. Value arrives at the Creditor — eventually. Each hop adds time, adds cost, and adds a potential FX conversion point, often with limited transparency on the rate applied.
The result is a system that is slow by design, expensive by structure, and opaque by default. For high-value corporate payments, this is manageable. For time-sensitive or high-volume cross-border flows, it is a genuine operational burden.
What Is a Stablecoin?
A stablecoin is a digital token pegged to a real-world asset — most commonly a fiat currency. USDC is pegged 1:1 to the US Dollar. EURC (issued by Circle) is pegged to the Euro. USDT is another widely used dollar-pegged stablecoin. Unlike Bitcoin or Ethereum, a stablecoin does not fluctuate in value. One USDC is always worth one USD. That stability is precisely what makes it suitable for payments — the recipient knows what they will receive.
What Is Stablecoin Settlement?
Stablecoin Settlement means replacing the correspondent banking settlement leg with a blockchain transfer. Instead of debiting a Nostro account and routing value through a chain of intermediaries, the bank converts fiat currency into stablecoin tokens and sends them directly across a blockchain — to the receiving end. Settlement is final in seconds. Fees are near-zero. The transaction is recorded immutably on the blockchain.
The payment instruction layer — ISO 20022 messages, SWIFT, PAIN.001, PACS.008 — does not go away. It adapts. The instruction still needs to say who is paying, who is receiving, how much, and for what purpose. But what happens after that instruction is sent is fundamentally different. The correspondent bank is no longer in the middle. A blockchain is.
Key Insight
Stablecoin Settlement does not replace payment messaging standards like ISO 20022. It replaces the correspondent banking settlement leg. The instruction layer remains — but what it instructs changes.
Section 2: Where Does FX Happen in a Stablecoin Payment?
The Most Important Insight — FX Moves to the Edges
This is the concept that every payments professional must internalise before anything else. Stablecoins do not eliminate FX. They move it to the edges of the payment flow.
In a traditional cross-border payment, FX is embedded inside the correspondent banking chain — often invisibly, often at a rate the Debtor never sees clearly. In a stablecoin payment, the blockchain carries tokens from one point to another. The blockchain has no concept of FX. USDC in is USDC out.
But the Debtor starts with local fiat currency. And the Creditor wants to receive local fiat currency. So FX must happen — it just happens at defined, explicit, and potentially more transparent points.
The Three Points in the Flow
1. The On-Ramp — FX Point One
The Debtor’s bank or PSP converts the Debtor’s local fiat currency into stablecoin before it enters the blockchain. Saudi Riyals (SAR) become USDC. This is the on-ramp. FX happens here — priced by the on-ramp provider. The rate applied at this point determines how many stablecoin tokens are generated from the Debtor’s fiat.
2. The Blockchain Leg — No FX
USDC travels across the blockchain — whether Stellar, Ethereum, or Solana — from the on-ramp wallet to the off-ramp wallet. This leg is fast, cheap, and carries no FX conversion. It is a pure token transfer. The value that enters the blockchain is the value that exits.
3. The Off-Ramp — FX Point Two
The Creditor’s bank or PSP receives the stablecoin and converts it into the Creditor’s local currency. USDC becomes EUR. This is the off-ramp. FX happens here — priced by the off-ramp provider. The Creditor receives local fiat in their bank account, with no need to hold or manage stablecoins themselves.
Who Sets the FX Rate?
In stablecoin flows, the FX rate is not set by a correspondent bank buried in the chain. It is set at specific, identifiable points:
- On-ramp/off-ramp providers — They quote a FX rate for fiat-to-stablecoin or stablecoin-to-fiat conversion. This is where their margin is embedded.
- DEX liquidity pools — For stablecoin-to-stablecoin swaps (e.g. USDC to EURC), the rate is determined algorithmically by an Automated Market Maker (AMM) based on pool depth and liquidity.
- Market makers — Institutional players who provide two-sided quotes and hold FX risk between on-ramp receipt and off-ramp delivery, hedging as needed.
Section 3: The Three FX Models
Not every stablecoin payment flow looks the same. The FX model depends on which parties hold stablecoins, which blockchain networks are involved, and which providers are available at each end. There are three primary models.
Model 1: Fiat → Stablecoin → Fiat
Full conversion at both ends. The most common real-world model.
The Debtor’s bank converts local fiat to stablecoin at the on-ramp. The stablecoin travels on-chain. The off-ramp converts stablecoin back to the Creditor’s local fiat. Two FX conversions — one at each edge. Maximum accessibility: works for any Debtor or Creditor regardless of whether they hold stablecoins or have blockchain infrastructure. This is the model that most banks and PSPs will implement first.
Model 2: Fiat → Stablecoin → Stablecoin → Fiat
Stablecoin swap mid-chain. Used when two different stablecoin ecosystems need to be bridged.
Example: The Debtor’s on-ramp produces USDC. But the Creditor’s off-ramp prefers EURC. A stablecoin swap — USDC to EURC — happens mid-chain via a decentralised exchange (DEX) or institutional liquidity provider. FX is embedded in that swap rate. Three FX touch points exist in this model. The mid-chain swap introduces rate and liquidity risk that must be actively managed, particularly for large-value transactions.
Model 3: Stablecoin → Fiat
Single-end conversion. The leanest model. Used when the Debtor already holds stablecoins.
A crypto-native business or treasury that holds USDC sends directly on-chain — no on-ramp conversion needed. FX happens only at the off-ramp when the Creditor converts stablecoin to local fiat. One FX conversion. Lowest cost. But this model only works when the Debtor is already stablecoin-enabled and comfortable holding digital assets in their treasury.
| Model | FX Conversions | Best For | Key Risk |
| Model 1: Fiat → STBL → Fiat | 2 (On-ramp + Off-ramp) | Banks, corporates, standard cross-border flows | Spread at both edges |
| Model 2: Fiat → STBL → STBL → Fiat | 3 (On-ramp + Swap + Off-ramp) | Multi-currency ecosystem bridging | Mid-chain liquidity and rate risk |
| Model 3: STBL → Fiat | 1 (Off-ramp only) | Crypto-native treasuries | Stablecoin holding risk for Debtor |
Section 4: ISO 20022 and Blockchain — The Two-Layer Architecture
The Core Concept
ISO 20022 messages like PAIN.001 (Customer Credit Transfer Initiation) and PACS.008 (Financial Institution Credit Transfer) were designed for a correspondent banking world. Every field reflects that world: BIC codes to identify banks, IBANs to identify accounts, settlement method codes pointing to known interbank systems.
Stablecoin settlement does not require abandoning ISO 20022. It requires understanding where ISO 20022 stops — and where the blockchain begins. The answer is a two-layer architecture that is both elegant and practical.
Layer 1 — The Instruction Layer (ISO 20022)
PAIN.001 or PACS.008 carries the payment instruction. Who is paying. Who is receiving. How much. For what purpose. In what currency. This layer is familiar and flows through existing channels — SWIFT, bank APIs, payment systems. The instruction is still an ISO 20022 message. Nothing fundamentally changes here.
Layer 2 — The Settlement Layer (Blockchain)
The actual movement of value happens on-chain as stablecoin tokens. USDC moves from the on-ramp provider’s wallet to the off-ramp provider’s wallet. Settlement is fast, final, and recorded immutably on the blockchain. A transaction hash is generated — irrefutable proof that settlement occurred. This hash is the blockchain equivalent of a Nostro debit confirmation.
The Bridge Between the Two Layers
The instruction message must carry enough blockchain metadata for the settlement layer to execute correctly. And the on-chain settlement confirmation must map back to the original payment instruction for reconciliation. This bridge is where the architecture gets interesting — and where standards work is most active.
Think of it like the PACS.008 + PACS.009 COV structure in correspondent banking: two linked messages, two layers working together. In the stablecoin world, the PACS.009 COV is replaced by an on-chain transaction. The settlement confirmation is a transaction hash, not a Nostro debit.
The Mental Model : ISO 20022 as the instruction envelope. Blockchain as the settlement engine. Together — they cover the full payment lifecycle.
Section 5: How ISO 20022 Fields Carry Blockchain Data
Here is where theory becomes practice. ISO 20022 is more flexible than most people realise. Several existing fields can be repurposed today — without changing the standard — to carry blockchain-specific information.
Field 1 — Creditor Agent: Carrying Wallet Addresses
In a traditional PACS.008, the Creditor Agent (CdtrAgt) carries a BIC — the receiving bank’s identifier. In a stablecoin flow, there is no BIC. Instead, the Othr (Other Identification) sub-element carries the off-ramp provider’s blockchain wallet address, with a proprietary scheme name indicating the type — for example ETH_WALLET or STELLAR_ADDR.
XML Snippet:
<CdtrAgt>
<FinInstnId>
<Othr>
<Id>GBBD47IF3FSGXZ5F3FSYKHZ7MXTPD7QSNH6FXBETX7FJCN7GKZKHKZL</Id>
<SchmeNm>
<Prtry>STELLAR_ADDR</Prtry>
</SchmeNm>
</Othr>
</FinInstnId>
</CdtrAgt>Field 2 — Local Instrument: Signalling the Blockchain Rail
In both PAIN.001 and PACS.008, PmtTpInf/LclInstrm carries a local instrument code that tells the receiving party which clearing rail to use — for example SEPA or CHAPS. In a stablecoin flow, a proprietary code signals the blockchain rail: USDC_STELLAR, USDC_ETH, or STBL_SOL. This tells every downstream system: route this payment for on-chain settlement, not through a Nostro account.
Field 3 — Settlement Method: Indicating On-Chain Settlement
In PACS.008, SttlmInf/SttlmMtd signals how interbank settlement occurs. Example : INDA/INGA. In a stablecoin flow, proprietary codes (Ex: DLT) or agreed scheme values indicate that settlement will occur on a distributed ledger — not through a traditional Nostro account. This is how the engine knows to dispatch to the on-ramp provider API rather than SWIFT.
Field 4 — Supplementary Data: The Flexible Extension Envelope
ISO 20022 includes a SplmtryData (Supplementary Data) element in most message types. This is the practical approach used widely in implementations today. It carries blockchain-specific fields that have no native ISO 20022 home yet: token contract address, blockchain network identifier, block number, smart contract reference. These are structured in a proprietary namespace agreed between implementation partners.
The Settlement Confirmation: CAMT.054 with Transaction Hash
When on-chain settlement completes, the on-ramp or off-ramp provider sends a CAMT.054 (Bank-to-Customer Debit Credit Notification). The transaction hash is carried in SplmtryData — mapped to the original PACS.008 End-to-End ID. The payment engine processes this exactly as it would a traditional Nostro confirmation. Just with a blockchain hash instead of a Nostro debit reference.
| Information Needed | Traditional Field Usage | Stablecoin Usage | ISO 20022 Field |
| Recipient Institution | BIC of Creditor Agent | Blockchain wallet address | CdtrAgt/FinInstnId/Othr |
| Settlement Rail | SEPA, CHAPS, SWIFT | USDC_STELLAR, USDC_ETH | PmtTpInf/LclInstrm/Prtry |
| Settlement Method | INGA, COVE, INDA | DLT / On-chain code | SttlmInf/SttlmMtd |
| Blockchain Metadata | Not applicable | Token type, Chain ID, Contract address | SplmtryData |
| Settlement Proof | Nostro debit reference | On-chain transaction hash | CAMT.054 / SplmtryData |
Section 6: A Full Practical Example
Scenario: Al-Rashid Trading Co. (Debtor, Riyadh, Saudi Arabia) needs to pay €50,000 to Müller GmbH (Creditor, Frankfurt, Germany) for an import invoice. The payment is instructed via PACS.008 and settles via USDC on the Stellar blockchain.
Step 1 — Payment Instruction (PACS.008)
Al-Rashid’s bank constructs a PACS.008 message. The message carries:
- InstdAmt: EUR 50,000 — the instructed amount in the Creditor’s currency
- LclInstrm/Prtry: USDC_STELLAR — signals on-chain settlement via Stellar blockchain
- CdtrAgt/Othr/Id: The Stellar wallet address of the off-ramp provider
- SplmtryData: Token contract identifier, Stellar network anchor, preferred asset code
Step 2 — On-Ramp FX and Stablecoin Conversion
The payment engine identifies the on-ramp provider from the LclInstrm code via its routing table. It sends a settlement instruction to the on-ramp provider API — not via SWIFT. The on-ramp provider converts SAR to USDC at the prevailing SAR/USD rate. At SAR 3.75 to USD and a USD/EUR rate of 1.08, approximately SAR 202,500 converts to ~53,300 USDC (covering the EUR 50,000 target plus fees).
Step 3 — On-Chain Transfer (Stellar Blockchain)
The on-ramp provider broadcasts a Stellar transaction: 53,300 USDC from the on-ramp wallet to the off-ramp provider’s Stellar wallet address. The transaction includes a memo field carrying the original PACS.008 End-to-End ID for traceability. Stellar consensus finalises the transaction in approximately 5 seconds. Transaction hash generated: a8f3b2c1d4e5f6…
Step 4 — Off-Ramp FX and Fiat Delivery
The off-ramp provider receives 53,300 USDC and converts to EUR at the prevailing USDC/EUR rate. Müller GmbH receives €50,000 in their EUR bank account — net of the off-ramp provider’s spread. Total end-to-end time from instruction to credited funds: under 60 seconds.
Step 5 — Settlement Confirmation and Reconciliation
The on-ramp provider sends a CAMT.054 to Al-Rashid’s bank. The CAMT.054 carries the Stellar transaction hash (a8f3b2c1d4e5f6…) in SplmtryData, mapped to the original PACS.008 End-to-End Identification. The payment engine reads this, matches it against its internal mapping table, and marks the payment as irrevocably settled.
Traditional vs Stablecoin: The Same Payment
- Traditional correspondent banking: 2-3 days, 3 hops, opaque FX at each hop, Nostro debit confirmation.
- Stablecoin settlement: Under 60 seconds, 1 blockchain leg, FX at two defined and explicit points, on-chain transaction hash as immutable proof.
Section 7: Payment Engine — Debit/Credit Party Derivation in an On-Chain Flow
What DPD and CPD Do
In any payment engine, Debit Party Derivation (DPD) determines which account or entity gets debited when a payment is processed. Credit Party Derivation (CPD) determines which account or entity gets credited. These two derivations drive accounting entries, liquidity management, and position tracking. Get them wrong and the payment books incorrectly. Get them right and everything downstream flows cleanly.
In a traditional outgoing PACS.008, the logic is well understood. The Debit Party is the Nostro account at the correspondent bank — the account being funded for the payment. The Credit Party is the Creditor Agent — the receiving bank, credited via the correspondent chain.
How DPD Changes: The On-Ramp Provider as Debit Party
Remove the correspondent bank and replace it with a blockchain. There is no Nostro account to debit. The engine must identify a new Debit Party — and that party is the on-ramp provider.
Think of the on-ramp provider as the new correspondent. Instead of holding a Nostro balance, they hold a stablecoin wallet funded by the bank. The engine identifies the on-ramp provider from the LclInstrm stablecoin rail code in the PACS.008 — mapped via a routing table that links stablecoin rail codes to registered on-ramp providers. The Debit Party derivation logic debits the bank’s position held with that on-ramp provider.
How CPD Changes: The Off-Ramp Provider as Credit Party
Similarly, the Credit Party in an on-chain settlement flow is typically the off-ramp provider at the receiving end — the entity that receives the stablecoin on-chain and converts it to local fiat for the Creditor. The engine credits the off-ramp provider’s position.
In some models — where the Creditor holds a stablecoin wallet directly — CPD skips the off-ramp entirely and credits the Creditor’s wallet position. The derivation logic must handle both cases, driven by the payment type and routing configuration.
| Derivation | Traditional PACS.008 | On-Chain PACS.008 |
| Debit Party | Nostro account at correspondent bank | On-ramp provider account / stablecoin wallet position |
| Credit Party | Creditor Agent (receiving bank) via correspondent | Off-ramp provider wallet / Creditor stablecoin wallet |
| Routing Trigger | BIC of Creditor Agent | LclInstrm stablecoin rail code → routing table lookup |
| Settlement Dispatch | SWIFT PACS.008 or PACS.009 | On-ramp provider API call |
The Core Principle
The DPD/CPD logic has not changed. The derivation principles are identical to traditional flows. What changes is the entity being derived — and the routing trigger used to find it. The on-ramp provider replaces the correspondent bank. The routing table is extended, not replaced.
Section 8: Reconciliation — Bridging the Hash to the Instruction
The Challenge
In traditional payments, reconciliation is straightforward. The MT910 or CAMT.054 confirmation carries the same End-to-End reference as the original PACS.008. The engine matches on that reference. Payment marked as settled. Clean.
In an on-chain flow, the settlement proof is a blockchain transaction hash — a 64-character alphanumeric string that lives on a public ledger. The engine must bridge between the ISO 20022 world and the blockchain world. This is the most underestimated challenge in implementing stablecoin settlement.
Approach 1 — Reference Embedding in the Blockchain Transaction
The on-ramp provider embeds the original PACS.008 End-to-End Identification directly into the blockchain transaction’s memo field. Stellar and XRPL support this natively. When the engine receives the transaction hash, it reads the memo field via blockchain API and matches the embedded reference to the original instruction. Clean, auditable, and fully traceable. This is the preferred approach for Stellar-based implementations.
Approach 2 — Internal Reference Mapping Table
The payment engine maintains an internal mapping table linking the PACS.008 Transaction ID to the on-ramp API request ID and the on-chain transaction hash. When the on-ramp provider sends a callback with the hash, the engine looks up the mapping and updates payment status. This approach works on any blockchain — including Ethereum and Solana, which have more limited native memo functionality.
Approach 3 — CAMT.054 Extended for On-Chain Proof
The most ISO 20022-aligned approach, and likely where the industry converges as DLT extensions mature. The on-ramp or off-ramp provider sends a CAMT.054 carrying the on-chain transaction hash in SplmtryData — mapped to the original PACS.008 End-to-End ID in NtryDtls/TxDtls/Refs/EndToEndId. The engine processes this exactly like a traditional settlement confirmation. The only difference is a blockchain hash where a Nostro reference used to be.
Five New Engine Capabilities Required
Any payment engine extending to support stablecoin settlement needs five new capabilities beyond its current design:
- Stablecoin routing table — Maps LclInstrm stablecoin rail codes to registered on-ramp providers. A new routing dimension: blockchain network + token type.
- API settlement adapter — Instead of dispatching a SWIFT message, the engine calls the on-ramp provider’s API. The adapter must handle authentication, payload formatting, and response handling.
- Hash storage and indexing — On-chain transaction hashes must be stored against payment records and queryable — for reconciliation, investigations, and regulatory reporting.
- On-chain exception handling — Blockchain transactions can fail: insufficient gas, network congestion, invalid wallet address. The engine’s exception and repair queue must handle on-chain failure codes, not just SWIFT NAKs.
- Finality logic — Unlike Nostro debits which are final on booking, blockchain finality varies by network. Stellar: approximately 5 seconds. Ethereum: 12–15 minutes for high confidence. The engine must understand finality thresholds before marking a payment irrevocably settled.
Section 9: What Standards Bodies Are Doing
ISO 20022 Digital Assets Extension
The ISO 20022 Registration Authority has active working groups on digital assets and distributed ledger technology. New elements are being proposed to natively support DLT transaction references, token identifiers, and wallet-based addressing — without relying on the field repurposing workarounds that implementations use today. The goal is to make stablecoin-specific data first-class citizens in the ISO 20022 schema.
SWIFT’s Blockchain Interoperability Experiments
SWIFT has been running experiments connecting its messaging infrastructure to blockchain networks. The core concept: SWIFT carries the payment instruction (PAIN.001 / PACS.008) as normal, but the settlement leg is executed on-chain. The on-chain transaction hash is then returned as settlement confirmation — replacing the MT910/CAMT.054 with an on-chain proof. This model preserves the existing ISO 20022 instruction layer entirely while modernising the settlement leg.
Fnality International
Fnality International — backed by a consortium of major banks including Barclays, Lloyds, and UBS — is building a wholesale payment system using tokenised central bank money. Their architecture uses ISO 20022 messages for the instruction layer and an Ethereum-based blockchain for the settlement layer. This is one of the most advanced live implementations of the two-layer architecture described in this article.
Stellar and ISO 20022 Mapping
The Stellar Development Foundation has published ISO 20022 mapping guidance for payments on the Stellar network — specifically targeting cross-border remittance flows. Their documentation maps PAIN.001 and PACS.008 instruction data to Stellar transaction operations and memo fields, providing a practical blueprint for implementation.
Conclusion
The architecture described in this article is not a distant vision. It is being assembled right now, by institutions that process trillions of dollars in cross-border payments every year. The components are real: ISO 20022 for instruction, blockchain for settlement, and a thin but critical bridge layer connecting the two.
For payments professionals, this shift demands a new mental model — not a replacement of everything learned about ISO 20022, correspondent banking, or payment engine design, but an extension of it. The principles of DPD and CPD remain. The reconciliation logic remains. The ISO 20022 message structure remains. What changes is who the counterparties are, how settlement is dispatched, and what the proof of settlement looks like.
The correspondent bank is not disappearing overnight. But the architecture that will supplement — and in some corridors replace — it is taking shape. Understanding that architecture now, before it becomes standard, is the competitive advantage every payments architect should be building.
Key Takeaways
- Stablecoins replace the correspondent banking settlement leg — not the instruction layer.
- FX moves to the on-ramp and off-ramp edges — it is not eliminated.
- Three FX models exist: full conversion, mid-chain swap, and single-end conversion.
- ISO 20022 is the instruction layer; blockchain is the settlement layer — two complementary layers.
- Existing PACS.008 fields (Othr, LclInstrm, SplmtryData) carry blockchain data today.
- DPD/CPD logic adapts: on-ramp and off-ramp providers replace correspondent banks.
- Reconciliation bridges ISO 20022 references to on-chain transaction hashes — via memo fields, mapping tables, or CAMT.054 extensions.
What to Read Next
If you are new to stablecoins and want the foundational context for the comparisons in this article, the Stablecoins Series (Parts 1–5) covers the complete stablecoin landscape from first principles to solution architecture. The series is available on the PaymentTalks blog.
For deeper technical reading on CBDCs, the BIS publishes comprehensive research papers and project reports at bis.org — the BIS Annual Economic Report chapters on CBDCs are among the most rigorous publicly available analyses.
The conversation between sovereign money and private digital money is one of the defining questions of the coming decade in finance. Understanding both sides — deeply, precisely, and practically — is the foundation of that conversation.
