This Is Where It Gets Real
Over the first four articles in this series, you have built a complete foundation:
- You understand what stablecoins are and why they exist (Part 1)
- You can trace the minting and burning lifecycle and explain the reserve mechanics (Part 2)
- You can compare stablecoin rails against SWIFT and SEPA with precision (Part 3)
- You know the six risks and the three major regulatory frameworks (Part 4)
Now comes the work that separates payments professionals who understand stablecoins from payments architects who can build with them.
This final article covers three concrete architectural patterns for stablecoin-enabled payment systems, the critical challenge of integrating ISO 20022 structured data with blockchain flows, the full compliance architecture required for production deployment, and a decision framework for knowing when to recommend stablecoin rails and when to stand firm with traditional infrastructure.
This is the article you will return to when you are in a design review or advising a client on their next-generation payment infrastructure.
The Architect’s Starting Point: Two Fundamental Design Questions
Before selecting an architectural pattern, every stablecoin payment design must answer two foundational questions:
Question 1: Where does fiat enter and exit the stablecoin world?
Every stablecoin payment that involves a party paying or receiving in traditional fiat currency requires an on-ramp (fiat → stablecoin) and an off-ramp (stablecoin → fiat). The design of these ramps — their location, their operators, their timing, and their fee structure — is as important as the blockchain transfer itself. Often more so.
Question 2: Who controls the wallet and the private key?
The entity that holds the private key controls the stablecoin. In enterprise payments, this means deciding whether your client, your platform, or a third-party custodian holds custody. This decision drives your compliance, risk, and operational design.
Once you have answered these two questions, the right architectural pattern becomes much clearer.
Architectural Pattern 1: Crypto-Rails, Fiat at the Edges (The Lift-and-Shift)
What It Is
This is the most pragmatic and widely deployed enterprise stablecoin architecture. The client’s experience does not change at all — they send a standard payment instruction in their local currency, and their counterparty receives local currency. Everything in between has been replaced by stablecoin rails.
It is called “lift-and-shift” because it lifts the payment off traditional correspondent banking rails and shifts it onto blockchain rails — without touching the client-facing interface or requiring the client to understand or interact with stablecoins directly.
The Flow
The Design Components in Detail
Payment Engine / Orchestration Layer
This is the brain of the architecture. It receives standard payment instructions — from PAIN.001, MT101, or a proprietary API — and orchestrates the stablecoin execution. Its responsibilities include:
- Parsing payment instructions and extracting Debtor, Creditor, Amount, Currency, Purpose, and Remittance Information
- Validating against compliance rules (sanctions check, Travel Rule trigger assessment)
- Selecting the optimal on-ramp exchange and off-ramp exchange for the corridor
- Initiating the blockchain transfer and monitoring for confirmation
- Generating status updates (equivalent to a PACS.002 payment status report) back to the originating system
- Handling exceptions — failed off-ramps, exchange downtime, liquidity shortfalls
On-Ramp
The on-ramp converts the originating fiat currency to USDC. Key design decisions:
Timing of conversion: Should the on-ramp run just-in-time (convert fiat to USDC only when a payment is ready to send), or should the system pre-fund a USDC wallet in advance?
- Just-in-time: No FX risk on held stablecoin balances, but adds latency and relies on exchange availability at payment time.
- Pre-funded: Faster execution, but the pre-funded USDC balance is exposed to de-peg risk until it is converted back to fiat.
For most enterprise use cases, a hybrid model works best: maintain a modest pre-funded float (enough for a few hours of expected payment volume) and top up during business hours.
Exchange selection: Use regulated, institutional-grade exchanges — Coinbase Prime, Bitstamp, B2C2, Wintermute. Do not use retail exchanges for enterprise payment volume. Negotiate fee structures and assess liquidity depth for your specific corridors.
Blockchain Transfer
Choose the blockchain based on the corridor requirements:
- Solana: Best for speed-critical, high-frequency, low-value flows. Sub-second finality, near-zero fees.
- Stellar: Best for corridors where Stellar has established exchange partnerships (e.g. certain Latin American and African corridors). Anchors (Stellar’s term for on/off ramp operators) provide deep local currency liquidity.
- Ethereum: Best for flows where regulatory or counterparty requirements specify Ethereum USDC, or where DeFi integration is part of the design.
Off-Ramp
The off-ramp converts USDC to local currency and delivers it to the beneficiary’s bank account. This is frequently the most complex part of the architecture because:
- Off-ramp providers vary enormously by jurisdiction — a regulated off-ramp in the Philippines (e.g. PDAX, Coins.ph) is not the same as a regulated off-ramp in Nigeria or Brazil.
- Local settlement rails must be used for the final delivery — the off-ramp exchanges USDC for local fiat and then uses a domestic payment instruction (RTGS, local ACH, mobile money) to credit the beneficiary.
- Operating hours, cut-off times, and weekend availability of local settlement rails still apply at the off-ramp stage.
What Makes This Pattern Powerful
The beauty of Pattern 1 is that it is invisible to both the Debtor and the Creditor. Neither party needs a crypto wallet, a stablecoin account, or any knowledge of blockchain. The payment arrives as local currency from a local institution. The stablecoin rails operated silently underneath, delivering the corridor cost and speed benefits without disrupting the client experience.
This is how Ripple’s ODL (On-Demand Liquidity) works commercially today, and how several major banks are quietly piloting stablecoin corridor settlements.
Architectural Pattern 2: Native Wallet-to-Wallet (Direct Institutional Transfer)
What It Is
Both parties hold stablecoin wallets — typically at regulated institutional custodians. Transfers happen directly between wallets on the blockchain, with no on-ramp or off-ramp required. There is no fiat intermediary.
This pattern is appropriate when both the sending and receiving institution are sophisticated, regulated entities who have established stablecoin treasury infrastructure — for example, two multinational corporations, two regulated exchanges, or a bank and a licensed PSP.
The Flow
The Design Components in Detail
Wallet Infrastructure
Both parties require institutional-grade custodial wallet infrastructure. Key platforms:
| Custodian | Description | Key Features |
| Fireblocks | Market-leading institutional wallet platform | Multi-sig, MPC (Multi-Party Computation) key management, policy engine, Travel Rule integration |
| BitGo | Established institutional custodian | Qualified custodian status, multi-sig, SOC2 certified |
| Anchorage Digital | OCC-chartered digital asset bank | Bank-grade custody, regulatory clarity |
| Copper | European-focused institutional custody | ClearLoop (off-exchange settlement) |
| BNY Mellon Digital Assets | Traditional custodian with digital asset capability | Bank credibility, regulatory relationships |
Multi-Signature Authorisation
For any institutional payment above a defined threshold, multi-signature (multi-sig) authorisation is a mandatory control requirement. Implemented correctly, it mirrors the dual-authorisation (maker-checker) controls in traditional payment systems:
- 2-of-3 multi-sig: Any two of three designated keyholders must approve a transaction before it executes. Common for operational payments.
- 3-of-5 multi-sig: Three of five designated approvers required. Used for large value payments or treasury movements.
- MPC (Multi-Party Computation): An advanced alternative to traditional multi-sig where the private key is never assembled in one place — it is split into shares held by different parties and used cooperatively to sign transactions without ever fully constructing the key. MPC is the institutional standard as of 2025.
Travel Rule Implementation
For Pattern 2 (VASP-to-VASP transfer), the FATF Travel Rule triggers when the transfer meets the threshold (currently $1,000 / €1,000 in most jurisdictions). The design requires:
- Pre-transaction: Originating VASP sends IVMS 101 data (Originator full name, wallet address, national ID or date of birth) to the Beneficiary VASP through a Travel Rule protocol (Notabene, Veriscope, or Sygna).
- Beneficiary VASP verifies the data, screens the originator, and responds with beneficiary IVMS 101 data.
- Only after this data exchange is complete does the on-chain transaction execute.
- Both VASPs retain the Travel Rule data for the required period (typically 5 years minimum).
This sequence adds seconds to minutes of latency to the transaction — a design consideration for time-sensitive flows.
AML Screening and On-Chain Analytics
Every wallet address involved in a Pattern 2 transaction must be screened before the transaction executes:
- OFAC SDN screening: The destination wallet address must be checked against the OFAC Specially Designated Nationals list. OFAC publishes a list of blockchain wallet addresses associated with sanctioned entities. As of 2024, hundreds of wallet addresses are on the OFAC SDN list.
- VASP identification: On-chain analytics tools can identify whether a wallet address is associated with a known VASP (exchange, protocol, or custodian). This matters for Travel Rule triggering — transfers to unknown or unhosted wallets may require additional due diligence.
- Risk scoring: Chainalysis, TRM Labs, and Elliptic assign risk scores to wallet addresses based on their transaction history. Addresses with exposure to darknet markets, ransomware, or other illicit sources should be blocked automatically.
Reconciliation Design
This is one of the most underestimated challenges in stablecoin payment architecture. A blockchain transaction generates a transaction hash — a unique identifier for that on-chain event. But your internal payment system uses payment references, message IDs, or instruction numbers.
You must design a reconciliation layer that:
- Maps every internal payment reference to a blockchain transaction hash
- Stores the mapping persistently and accessibly
- Triggers internal settlement accounting on confirmation of the on-chain event
- Handles edge cases — unconfirmed transactions, failed transactions, and the (rare) scenario of a transaction stuck in mempool (pending state)
This is the payment operations layer of stablecoin architecture. It is not glamorous — but it is where production systems succeed or fail.
Architectural Pattern 3: CBDC Bridge and Tokenised Wholesale Settlement
What It Is
This pattern represents the frontier of stablecoin architecture — not consumer or B2B payments, but wholesale interbank and central bank settlement. Instead of stablecoins issued by private companies, this involves tokenised central bank money (or central bank digital currencies — CBDCs) operating on shared distributed ledger platforms.
This is a live area of experimentation. Several projects are already at pilot stage with real transaction volumes.
The Core Concept
Traditional wholesale settlement between central banks uses a system of bilateral accounts and messaging (e.g. Fedwire in the US, CHAPS in the UK, TARGET2 in the EU). Cross-border wholesale settlement relies on correspondent banking at the interbank level — with the same frictions of cost, speed, and opacity that exist at the retail level.
CBDC bridge architecture replaces this with a shared distributed ledger where:
- Central Bank A issues a tokenised representation of its central bank money onto the shared platform
- Central Bank B does the same
- Settlement between the two currencies happens through atomic swaps — simultaneous exchange where both legs settle at the same instant with no counterparty risk
- Commercial banks’ nostro/vostro positions are updated in real time, automatically, without end-of-day reconciliation
Key Projects in Production/Pilot
mBridge (Multi-Central Bank Digital Currency Bridge)
mBridge is the most advanced live multi-CBDC project globally. Participants include the BIS Innovation Hub, the Hong Kong Monetary Authority, the People’s Bank of China, the Central Bank of UAE, and the Bank of Thailand.
In 2024, mBridge entered the Minimum Viable Product (MVP) stage — meaning real transactions at commercial scale are processing. The platform processed cross-border transfers between commercial banks in the participating jurisdictions using tokenised central bank money. Settlement was final within seconds, 24/7.
The BIS Innovation Hub has subsequently opened mBridge to more participants — a significant signal that this architecture is heading toward broader adoption.
Project Jura (BIS, Banque de France, Swiss National Bank)
Project Jura tested cross-border settlement of tokenised financial instruments (not stablecoins, but tokenised commercial paper and other assets) using wholesale CBDCs from France and Switzerland. It demonstrated delivery versus payment (DvP) — the simultaneous exchange of a tokenised asset and a payment, eliminating counterparty risk.
Project Guardian (MAS, Singapore)
The Monetary Authority of Singapore has coordinated Project Guardian — a series of pilots involving regulated financial institutions testing tokenised assets, tokenised foreign currencies, and DeFi protocols in a regulated framework. Participants include JPMorgan, DBS Bank, and BNY Mellon.
The Architecture Flow
Atomic Swap:
Both the CBDC-A debit and CBDC-B credit happen simultaneously in a single, indivisible transaction. If either leg fails, neither executes. This eliminates Herstatt risk (the risk that one party settles but the other defaults before settling) — one of the oldest and most important risks in cross-border settlement.
Why This Matters to Payments Architects Today
Even if CBDC bridges are several years from mainstream commercial deployment, architects working with central banks, systemically important financial institutions (SIFIs), or central market infrastructure (CCP, CSDs) need to understand this direction now.
The skills required — tokenised asset issuance, atomic settlement mechanics, shared DLT design, DvP implementation — are the same skills needed for the coming wave of tokenised securities, tokenised repo, and tokenised trade finance.
If you are advising a central bank or a major commercial bank on their 5-year payment infrastructure roadmap, CBDC bridge capability is a near-certain requirement.
The ISO 20022 Integration Challenge — Where Traditional and Blockchain Worlds Collide
This is the architectural problem that matters most for anyone building stablecoin payment systems for regulated financial institutions — and it is one that the industry has not fully solved.
The Problem
ISO 20022 messages — PACS.008, PACS.002, PAIN.001, CAMT.054 — carry rich, structured data about every payment:
- Debtor: Full legal name, address, account number, LEI
- Creditor: Full legal name, address, account number, LEI
- Remittance Information: Invoice references, payment purposes
- Regulatory Data: Tax identifiers, regulatory reporting codes
A standard Solana USDC transaction carries:
- Sender wallet address
- Receiver wallet address
- Amount (in USDC lamports)
- Transaction hash
- Optional: a small memo field (up to ~32 bytes)
The gap is enormous. A production payment in a regulated environment needs the ISO 20022 data richness. The blockchain provides only the settlement rail.
The Three-Layer Integration Architecture
Solving this gap requires a three-layer approach:
Layer 1 — Data Mapping
Build a mapping layer that extracts key ISO 20022 fields and stores them in an off-chain reference database, linked to the blockchain transaction by a unique identifier.
The mapping might look like this:
| ISO 20022 Field | Blockchain Equivalent | Storage Method |
| MsgId (Message Identifier) | Stored off-chain | Off-chain DB, keyed to tx hash |
| InstrId (Instruction Identifier) | Stored off-chain | Off-chain DB |
| Dbtr (Debtor Name + Address) | Not on-chain | Off-chain DB (for Travel Rule) |
| Cdtr (Creditor Name + Address) | Not on-chain | Off-chain DB (for Travel Rule) |
| Amt (Instructed Amount) | On-chain (USDC token value) | On-chain, readable |
| RmtInf (Remittance Information) | Memo field (limited) | Off-chain DB |
| PurpCd (Purpose Code) | Not on-chain | Off-chain DB |
Layer 2 — Reconciliation Engine
The reconciliation engine continuously monitors the blockchain for confirmed transactions and matches them against pending payment references in the off-chain database. When a confirmed transaction is found:
- The payment record is marked as settled
- The settlement timestamp (block timestamp) and transaction hash are recorded
- The internal accounting system is triggered (debit/credit positions updated)
- A payment status notification is generated for the originating system
This is the equivalent of a PACS.002 message — a payment status report confirming settlement — but derived from on-chain event monitoring rather than a SWIFT return message.
Layer 3 — Status Reporting
For clients using ISO 20022 payment initiation (PAIN.001), they expect PAIN.002 (payment status report) responses. The architecture must translate blockchain confirmation events into structured PAIN.002/PACS.002 messages:
- ACCP (Accepted by Creditor Agent) — equivalent to on-chain transaction broadcast and pending confirmation
- ACSC (Accepted Settlement Completed) — equivalent to on-chain transaction confirmed with sufficient block depth
- RJCT (Rejected) — equivalent to on-chain transaction failed (insufficient balance, invalid address, etc.)
This translation layer is complex to build but essential for integrating stablecoin rails into existing payment operations systems without requiring those systems to natively understand blockchain.
The Emerging Standards Gap — and Where It Is Heading
SWIFT has recognised this integration challenge and is actively working on solutions. Key initiatives:
- SWIFT’s tokenised asset experiments: SWIFT has conducted successful pilots where a SWIFT API layer sits above tokenised asset networks — allowing financial institutions to use familiar SWIFT connectivity to initiate and monitor tokenised transfers.
- ISO 20022 metadata in blockchain transactions: Some blockchain protocols (notably Hedera Hashgraph and XDC Network) are designed with richer transaction metadata capabilities, explicitly to support ISO 20022 data.
- The BIS and cross-border harmonisation: The BIS Committee on Payments and Market Infrastructures (CPMI) has published guidance on aligning the data requirements of ISO 20022 with tokenised payment flows.
For architects designing stablecoin systems in 2025–2026, the practical advice is: do not wait for the standards to fully emerge. Build the off-chain data layer now, design it to be ISO 20022-compliant, and plan for it to evolve as native blockchain support for richer metadata improves.
The Full Compliance Architecture
Every production stablecoin payment system requires these compliance components. None of them are optional in a regulated environment.
Component 1: KYC/AML Onboarding
Every entity that will hold a stablecoin wallet or interact with the payment system must be fully onboarded:
- Corporate KYC: Certificate of incorporation, beneficial ownership (UBO), directors
- Individual KYC: Government ID, proof of address, PEP (Politically Exposed Person) check
- Sanctions screening at onboarding (OFAC, UN, EU, HM Treasury lists)
- Ongoing monitoring: Annual or event-triggered KYC refresh
Who does this? For Pattern 1 (Lift-and-Shift), the exchange/custodian handles onboarding of your platform. For Pattern 2 (Wallet-to-Wallet), your platform must maintain its own KYC records for its clients, because you are the VASP.
Component 2: Transaction Monitoring
Every transaction must be monitored in real time for:
- Unusual transaction volumes or patterns
- Transactions to or from high-risk jurisdictions
- Rapid-fire transactions (structuring)
- Connections to known illicit addresses (flagged by on-chain analytics)
Tools: Chainalysis KYT (Know Your Transaction), TRM Labs, Elliptic Navigator. These tools integrate via API into your payment platform and return risk scores and alerts for each transaction.
Component 3: Sanctions Screening (On-Chain)
Distinct from KYC sanctions screening at onboarding, transaction-level sanctions screening checks every destination wallet address against:
- OFAC SDN list (including blockchain wallet addresses)
- UN Consolidated Sanctions List
- EU Consolidated Sanctions List
- HM Treasury Financial Sanctions (UK)
This screening must happen before the transaction is initiated — because once it is on the blockchain, it cannot be stopped. Build a mandatory pre-transaction screening gate into your payment engine.
Component 4: Travel Rule Implementation
For VASP-to-VASP transfers above the threshold:
- Integrate with a Travel Rule protocol — Notabene is currently the most widely adopted, with network effects across 200+ VASPs globally.
- Exchange IVMS 101 structured data with the counterparty VASP before initiating the on-chain transfer.
- Retain Travel Rule data records for the required retention period (5 years in most jurisdictions).
Design consideration: What happens if the counterparty VASP does not support Travel Rule protocols? This is a real scenario with unhosted wallets (wallets not held at a VASP). FATF guidance requires enhanced due diligence for transfers to unhosted wallets. Your policy engine must handle this case — typically by requiring additional KYC documentation before allowing a transfer to an unhosted wallet.
Component 5: Regulatory Reporting
Depending on jurisdiction, stablecoin payment activities may trigger:
- FinCEN reporting (US): Suspicious Activity Reports (SARs) and Currency Transaction Reports (CTRs) if thresholds are met
- FINTRAC reporting (Canada): Large cash transaction reports and suspicious transaction reports
- AUSTRAC reporting (Australia): Threshold transaction reports
- STR obligations (most jurisdictions): Suspicious Transaction Reports to local Financial Intelligence Units
Your compliance architecture must integrate these reporting workflows — automated where possible, with manual review queues for borderline cases.
Technology Stack Reference for Production Deployment
| Layer | Category | Leading Options |
| Blockchain | Settlement rail | Solana (speed/cost), Ethereum (ecosystem), Stellar (payments-native) |
| Stablecoin | Asset | USDC (regulated, MiCA-compliant), EURC (EUR flows) |
| Custody | Wallet infrastructure | Fireblocks, BitGo, Anchorage, Copper |
| On-Ramp | Fiat → Stablecoin | Circle (direct mint), Coinbase Prime, B2C2, Bitstamp |
| Off-Ramp | Stablecoin → Fiat | Corridor-specific: PDAX (Philippines), Bitso (Mexico), Yellow Card (Africa) |
| AML Screening | Transaction monitoring | Chainalysis KYT, TRM Labs, Elliptic |
| Travel Rule | VASP data exchange | Notabene, Veriscope, Sygna Bridge |
| On-Chain Analytics | Address risk scoring | Chainalysis, TRM Labs, Elliptic |
| ISO 20022 Integration | Data mapping + reconciliation | Custom middleware (no dominant vendor yet) |
| FX Rate Feed | Exchange rate sourcing | Bloomberg, Refinitiv, CoinGecko Pro |
The Final Decision Framework: When to Recommend Stablecoin Rails
Bring this framework to every payment architecture review:
| Decision Criterion | Weight Stablecoin Rails | Weight Traditional Rails |
| Cross-border corridor cost >$10 | Strong case | — |
| 24/7 settlement required | Strong case | — |
| Settlement speed < 1 hour required | Strong case | — |
| Emerging market corridor, thin traditional banking | Strong case | — |
| Both parties VASP-licensed and Travel Rule compliant | Required | — |
| Regulatory approval confirmed in all jurisdictions | Required | — |
| Payment reversibility / recall required | — | Traditional required |
| Consumer payment with dispute rights | — | Traditional required |
| Single transaction >$5M, thin corridor liquidity | — | Traditional or hybrid |
| Domestic payment in jurisdiction with strong local rails | — | Traditional preferred |
| Counterparty unable to access stablecoin off-ramp | — | Traditional until off-ramp exists |
The best architects do not have a preference for stablecoins or traditional rails. They have a preference for the right tool for the specific payment, corridor, counterparty, and regulatory context.
Key Takeaways
- Pattern 1 (Lift-and-Shift) is the most commercially viable architecture today — it delivers stablecoin rail benefits while preserving the fiat experience for both parties. The on/off ramp design is where most of the engineering complexity lives.
- Pattern 2 (Native Wallet-to-Wallet) is appropriate for sophisticated institutional counterparties and requires full Travel Rule compliance, multi-sig custody, and AML screening as non-negotiable design components.
- Pattern 3 (CBDC Bridge) is the frontier of wholesale settlement architecture — live in pilot, heading toward commercial deployment. Architects advising central banks or SIFIs must understand this direction now.
- The ISO 20022 to blockchain data gap is real and currently unsolved at scale. A three-layer architecture — data mapping, reconciliation engine, and status reporting — bridges the gap until native blockchain standards mature.
- Compliance architecture (KYC, AML, sanctions, Travel Rule, regulatory reporting) is not a bolt-on — it must be designed in from the start. Retrofitting compliance is far more expensive and risky than building it in.
Series Conclusion: You Are Now Stablecoin-Ready
Over these five articles, you have covered the complete stablecoin landscape:
- Part 1: What stablecoins are, why they exist, and the three types
- Part 2: The minting and burning lifecycle, reserve mechanics, blockchain infrastructure, and wallet models
- Part 3: Real-world payment flows, use cases, and the SWIFT comparison
- Part 4: Six risks and three major regulatory frameworks
- Part 5: Three architectural patterns, ISO 20022 integration, compliance architecture, and a decision framework
This is not the end. Stablecoins are developing rapidly. Regulatory frameworks are being finalised. New blockchains and new architectures are emerging. The mBridge project is expanding. SWIFT is piloting tokenised asset settlement. The ECB is progressing its digital euro.
The foundation you have built through this series will let you absorb, evaluate, and apply every development that follows. You have the mental models, the vocabulary, the risk awareness, and the architectural patterns.
The payments industry is changing. You are equipped to change with it — and to lead that change for your clients, your team, and your organisation.
