How to Architect a Stablecoin Payment System: 3 Design Patterns Every Solution Architect Needs (Part 5 of 5)

Four articles in, you know what stablecoins are, how they are minted and burned, how they stack up against SWIFT and SEPA, and where the regulatory risk sits. None of that tells you how to actually design the system. This article does.

Why Does This Final Article Matter More Than the First Four?

This is the point in the series where reading turns into building. The first four articles gave you the vocabulary and the risk map:

• What stablecoins are and why they exist (Part 1)
• How minting and burning work, and the reserve mechanics behind them (Part 2)
• How stablecoin rails compare to SWIFT and SEPA on cost, speed, and finality (Part 3)
• The six risk categories and the three regulatory frameworks you cannot ignore (Part 4)

This article covers three concrete architectural patterns, the ISO 20022-to-blockchain integration gap that most teams underestimate, the full compliance stack a production deployment actually needs, and a decision framework for when stablecoin rails are the right call and when they are not.

Bookmark this one. It is the article you pull up in a design review, or when a client asks you to defend a stablecoin recommendation in front of their risk committee.

What Two Questions Should You Answer Before Choosing an Architecture?

Every stablecoin payment design decision traces back to two questions. Answer these first and the right pattern becomes obvious.

Where Does Fiat Enter and Exit the Stablecoin World?

Any payment involving a party who pays or gets paid in fiat currency needs an on-ramp (fiat to stablecoin) and an off-ramp (stablecoin to fiat). Where those ramps sit, who operates them, how fast they run, and what they cost usually matters more than the blockchain leg itself.

Who Controls the Wallet and the Private Key?

Whoever holds the private key controls the stablecoin. For an enterprise payment system, that means deciding upfront whether the client, your platform, or a third-party custodian holds custody. That single decision shapes your compliance model, your risk exposure, and your operational design from there on.

Answer both questions and the pattern selection stops being a debate.

What Is the Lift-and-Shift Pattern (Crypto Rails, Fiat at the Edges)?

What It Is

This is the most pragmatic, most widely deployed enterprise stablecoin pattern in production today. Nothing changes for the client. They send a standard payment instruction in local currency, and the counterparty receives local currency. Everything between those two points has quietly been rebuilt on stablecoin rails.

It earns the name lift-and-shift because the payment is lifted off correspondent banking rails and shifted onto blockchain rails, without touching the client-facing experience and without requiring anyone client-side to know or care what a stablecoin is.

The Flow

[VISUAL 1 — Lift-and-Shift (Pattern 1) flow diagram showing fiat instruction, payment engine, on-ramp, blockchain transfer, off-ramp, and fiat delivery]

The Design Components in Detail

Payment Engine / Orchestration Layer

This is the brain of the architecture. It ingests standard payment instructions, whether that is a

This is the brain of the architecture. It ingests standard payment instructions, whether that is a PAIN.001 message, an MT101, or a proprietary API call, and orchestrates the stablecoin execution underneath it. It is responsible for:

• Parsing the instruction and extracting Debtor, Creditor, Amount, Currency, Purpose, and Remittance Information (see how these fields map in PAIN.001 Fields Explained)
• Running compliance checks — sanctions screening and Travel Rule trigger assessment — before anything touches the blockchain
• Selecting the best on-ramp and off-ramp exchange for that specific corridor
• Initiating the blockchain transfer and monitoring for confirmation
• Generating status updates back to the originating system — functionally equivalent to a PACS.002 payment status report
• Handling exceptions: failed off-ramps, exchange downtime, sudden liquidity shortfalls

On-Ramp

The on-ramp converts originating fiat to USDC. Two timing models exist, and most enterprise deployments end up somewhere between them:

• Just-in-time — convert fiat to USDC only when a payment is ready to send. No FX risk on a held stablecoin balance, but you inherit latency and depend on exchange availability at the exact moment you need it.
• Pre-funded — hold a USDC balance in advance for faster execution, at the cost of de-peg exposure until it converts back to fiat

The pattern that actually survives contact with production is a hybrid: keep a modest pre-funded float, enough to cover a few hours of expected volume, and top it up during business hours rather than running fully just-in-time or fully pre-funded.

Exchange selection matters just as much as timing. Use regulated, institutional-grade venues — Coinbase Prime, Bitstamp, B2C2, Wintermute. Retail exchanges are not built for enterprise payment volume, and their liquidity depth and fee structure will show it under load.

Blockchain Transfer

Pick the chain based on corridor requirements, not on which one is trending:

• Solana — sub-second finality, near-zero fees. Best for speed-critical, high-frequency, low-value flows.
• Stellar — strong where its Anchors (Stellar’s term for on/off-ramp operators) already provide deep local currency liquidity, notably in parts of Latin America and Africa.
• Ethereum — the right call when a regulatory or counterparty requirement specifically calls for Ethereum USDC, or when DeFi integration is part of the design.

Off-Ramp

The off-ramp converts USDC back to local currency and delivers it to the beneficiary’s bank account. This is usually the hardest part of the whole architecture, for three reasons:

• Off-ramp providers vary enormously by jurisdiction — a regulated off-ramp in the Philippines (PDAX, Coins.ph) bears no resemblance operationally to one in Nigeria or Brazil
• Final delivery still runs over local settlement rails — the off-ramp converts USDC to fiat and then pushes a domestic instruction (RTGS, local ACH, mobile money) to credit the beneficiary
• Local operating hours, cut-off times, and weekend availability still apply at this stage — the blockchain leg being 24/7 does not make the last mile 24/7

What Makes This Pattern Powerful

Pattern 1 works because it is invisible. Neither the Debtor nor the Creditor needs a crypto wallet, a stablecoin account, or any understanding of blockchain. The payment lands as local currency from a local institution, while stablecoin rails do the corridor-cost and corridor-speed work silently underneath.

This is the architecture behind Ripple’s ODL (On-Demand Liquidity) in commercial production today, and it is what a growing number of banks are quietly piloting for corridor settlement.

What Is the Native Wallet-to-Wallet Pattern?

What It Is

Both parties hold stablecoin wallets, typically with regulated institutional custodians, and the transfer happens wallet to wallet on-chain. No on-ramp, no off-ramp, no fiat intermediary at all.

This pattern fits when both the sending and receiving institution are sophisticated, regulated entities with their own stablecoin treasury infrastructure already in place — two multinationals, two regulated exchanges, or a bank paired with a licensed PSP.

The Flow

[VISUAL 2 — Native Wallet-to-Wallet (Pattern 2) flow diagram showing multi-sig authorisation, Travel Rule data exchange, and on-chain transfer]

The Design Components in Detail

Wallet Infrastructure

Both parties need institutional-grade custodial wallet infrastructure. The field has consolidated around a short list of platforms:

Custodian	Description	Key Features
Fireblocks	Market-leading institutional wallet platform	Multi-sig, MPC 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

Above a defined threshold, multi-sig authorisation is a mandatory control, not an optional hardening step. Done well, it is the on-chain mirror of the maker-checker controls already standard in traditional payments:

• 2-of-3 multi-sig — any two of three designated keyholders approve before execution. Typical for operational payments.
• 3-of-5 multi-sig — three of five approvers required. Used for large-value payments or treasury movements.
• MPC (Multi-Party Computation) — the private key is never assembled in one place. It is split into shares held by different parties who sign cooperatively without ever reconstructing the full key. As of 2025, MPC is the institutional standard, ahead of classic multi-sig.

Travel Rule Implementation

For a VASP-to-VASP transfer under Pattern 2, the FATF Travel Rule triggers once the payment crosses the threshold, currently $1,000 / €1,000 in most jurisdictions. The design has to handle:

1. The originating VASP sends IVMS 101 data — the originator’s full name, wallet address, national ID or date of birth — to the beneficiary VASP through a Travel Rule protocol such as Notabene, Veriscope, or Sygna
2. The beneficiary VASP verifies that data, screens the originator, and responds with its own beneficiary IVMS 101 data
3. Only once that exchange completes does the on-chain transaction execute
4. Both VASPs retain the Travel Rule data for the required retention period — typically five years minimum

Build for the latency this adds. It is seconds to minutes, and on a time-sensitive flow that is a design constraint, not a rounding error.

AML Screening and On-Chain Analytics

Every wallet address in a Pattern 2 transaction needs screening before the transaction executes, not after:

• OFAC SDN screening — check the destination address against the OFAC Specially Designated Nationals list, which now includes hundreds of flagged blockchain addresses
• VASP identification — on-chain analytics can tell you whether an address belongs to a known exchange, protocol, or custodian, which matters directly for whether Travel Rule applies
• Risk scoring — Chainalysis, TRM Labs, and Elliptic score addresses by transaction history; anything with exposure to darknet markets or ransomware should be blocked automatically, not flagged for manual review after the fact

Reconciliation Design

This is the part of stablecoin architecture that gets underestimated the most. A blockchain transaction produces a transaction hash. Your internal payment system runs on payment references, message IDs, and instruction numbers. Those two worlds do not speak the same language natively.

Your reconciliation layer needs to:

• Map every internal payment reference to its blockchain transaction hash
• Store that mapping persistently and make it queryable
• Trigger internal settlement accounting the moment the on-chain event confirms
• Handle the edge cases — unconfirmed transactions, failed transactions, and the rarer case of a transaction stuck pending in the mempool

None of this is glamorous. It is also exactly where production stablecoin systems succeed or quietly fall apart.

What Is the CBDC Bridge Pattern for Tokenised Wholesale Settlement?

What It Is

This is the frontier pattern — not consumer or B2B payments, but wholesale interbank and central bank settlement. Instead of privately issued stablecoins, this involves tokenised central bank money moving on a shared distributed ledger. It is a live area of experimentation, and several projects are already running at pilot scale with real volume.

The Core Concept

Traditional wholesale settlement runs on bilateral accounts and messaging — Fedwire in the US, CHAPS in the UK, TARGET2 in the EU. Cross-border wholesale settlement still leans on correspondent banking at the interbank level, with the same cost, speed, and opacity problems that show up at the retail level. For a deeper contrast between this model and central bank digital currency design, see CBDCs Explained.

CBDC bridge architecture replaces that 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 — both legs settle at the same instant, with no counterparty risk in between
• Commercial banks’ nostro/vostro positions update in real time, automatically, with no end-of-day reconciliation batch

Key Projects in Production/Pilot

mBridge (Multi-Central Bank Digital Currency Bridge)

mBridge is the most advanced live multi-CBDC project globally, with the BIS Innovation Hub, the Hong Kong Monetary Authority, the People’s Bank of China, the Central Bank of the UAE, and the Bank of Thailand as participants. For the full mechanics of how it works, see mBridge Explained.

In 2024, mBridge reached Minimum Viable Product stage, meaning commercial-scale real transactions are processing between banks in participating jurisdictions using tokenised central bank money, with final settlement in seconds, 24/7. The BIS Innovation Hub has since opened the platform to more participants, a clear signal of where this is heading.

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 proved out delivery versus payment (DvP): the simultaneous exchange of a tokenised asset and its payment, eliminating counterparty risk entirely.

Project Guardian (MAS, Singapore)

The Monetary Authority of Singapore has run Project Guardian as a series of pilots with regulated institutions testing tokenised assets, tokenised foreign currencies, and DeFi protocols inside a regulated framework, with JPMorgan, DBS Bank, and BNY Mellon among the participants.

The Architecture Flow

[VISUAL 3 — CBDC Bridge (Pattern 3) flow diagram showing atomic swap settlement between two central banks]

Atomic swap: the CBDC-A debit and the CBDC-B credit happen simultaneously, in a single indivisible transaction. If either leg fails, neither executes. This is what eliminates Herstatt risk, the risk that one party settles while the other defaults before settling, which is one of the oldest and most consequential risks in cross-border settlement.

Why This Matters to Payments Architects Today

CBDC bridges may be years from mainstream commercial deployment, but if you are advising a central bank, a systemically important financial institution, or central market infrastructure, this direction is already relevant. Tokenised asset issuance, atomic settlement mechanics, shared DLT design, and DvP implementation are the same skills the next wave of tokenised securities, tokenised repo, and tokenised trade finance will demand.

If you are shaping a five-year payment infrastructure roadmap for a central bank or a major commercial bank, CBDC bridge capability is close to a certainty on that roadmap, not a maybe.

Why Is Integrating ISO 20022 With Blockchain So Hard?

This is the architectural problem that matters most for anyone building stablecoin systems for regulated institutions, and it is one the industry has not fully solved. For background on how this data structure works in traditional rails, see Fundamentals of ISO 20022.

The Problem

ISO 20022 messages — PACS.008, PACS.002, PAIN.001, CAMT.054 — carry rich, structured data on 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, by comparison, carries a sender address, a receiver address, an amount in USDC lamports, a transaction hash, and an optional memo field capped at roughly 32 bytes.

That gap is not a formatting inconvenience. A production payment in a regulated environment needs the full ISO 20022 data richness, and the blockchain gives you only the settlement rail underneath it.

What Does a Three-Layer Integration Architecture Look Like?

Closing this gap takes a three-layer approach.

Layer 1 — Data Mapping

Build a mapping layer that pulls key ISO 20022 fields into an off-chain reference database, keyed to the blockchain transaction by a unique identifier. See Payment Identifiers in ISO 20022 for how these identifiers are structured on the traditional rail side. A typical mapping looks 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 watches the blockchain continuously for confirmed transactions and matches them against pending payment references in the off-chain database. When a match confirms:

• The payment record is marked settled
• The settlement timestamp (block timestamp) and transaction hash are recorded
• The internal accounting system triggers debit/credit position updates
• A payment status notification generates for the originating system

Functionally, this is your PACS.002 equivalent — a payment status report confirming settlement, just derived from on-chain event monitoring instead of a SWIFT return message.

Layer 3 — Status Reporting

Clients using PAIN.001 for payment initiation expect PAIN.002 status responses back. The architecture has to translate blockchain confirmation events into structured PAIN.002/PACS.002 messages:

• ACCP (Accepted by Creditor Agent) — maps to on-chain transaction broadcast and pending confirmation
• ACSC (Accepted Settlement Completed) — maps to on-chain transaction confirmed with sufficient block depth
• RJCT (Rejected) — maps to on-chain transaction failure: insufficient balance, invalid address, and similar cases

This translation layer is not simple to build, but without it your existing payment operations systems never need to understand blockchain natively — which is exactly the point.

Where Are the Emerging ISO 20022 Standards Heading?

SWIFT has recognised this integration gap and is actively working on it. Three developments worth tracking:

• SWIFT’s tokenised asset pilots — a SWIFT API layer sitting above tokenised asset networks, letting institutions use familiar SWIFT connectivity to initiate and monitor tokenised transfers
• Richer on-chain metadata — some blockchain protocols, notably Hedera Hashgraph and XDC Network, are being designed with richer transaction metadata specifically to support ISO 20022 data
• BIS cross-border harmonisation — the BIS Committee on Payments and Market Infrastructures (CPMI) has published guidance on aligning ISO 20022 data requirements with tokenised payment flows

The practical advice for 2025–2026 is not to wait for the standards to fully mature. Build the off-chain data layer now, design it to be ISO 20022-compliant from day one, and plan for it to evolve as native blockchain metadata support improves.

What Does a Full Production Compliance Architecture Require?

Every one of these components is required in a regulated deployment. None of them are optional extras you bolt on before launch.

Component 1: KYC/AML Onboarding

Every entity holding a stablecoin wallet or touching the payment system needs full onboarding:

• 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 against OFAC, UN, EU, and HM Treasury lists
• Ongoing monitoring — annual or event-triggered KYC refresh

Who owns this depends on the pattern. For Pattern 1 (Lift-and-Shift), the exchange or custodian onboards your platform. For Pattern 2 (Wallet-to-Wallet), your platform maintains its own KYC records for its clients, because you are the VASP.

Component 2: Transaction Monitoring

Every transaction needs real-time monitoring for unusual volumes or patterns, transactions to or from high-risk jurisdictions, structuring (rapid-fire transactions designed to dodge thresholds), and connections to known illicit addresses flagged by on-chain analytics. Chainalysis KYT, TRM Labs, and Elliptic Navigator integrate via API and return risk scores and alerts per transaction.

Component 3: Sanctions Screening (On-Chain)

Distinct from onboarding-stage KYC sanctions screening, transaction-level sanctions screening checks every destination wallet address against the OFAC SDN list, the UN Consolidated Sanctions List, the EU Consolidated Sanctions List, and HM Treasury Financial Sanctions in the UK.

This has to run before the transaction is initiated. Once it is on-chain, it cannot be pulled back. Build a mandatory pre-transaction screening gate into the payment engine — not a post-transaction alert.

Component 4: Travel Rule Implementation

For VASP-to-VASP transfers above threshold:

• Integrate a Travel Rule protocol — Notabene currently has the widest adoption, 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, five years in most jurisdictions

The design question that trips teams up: what happens when the counterparty VASP does not support Travel Rule protocols? This is a real, recurring scenario with unhosted wallets. FATF guidance calls for enhanced due diligence on transfers to unhosted wallets, so your policy engine needs a defined path for this — typically requiring additional KYC documentation before the transfer proceeds.

Component 5: Regulatory Reporting

Depending on jurisdiction, stablecoin payment activity can trigger:

• FinCEN reporting (US) — Suspicious Activity Reports (SARs) and Currency Transaction Reports (CTRs) once 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 the local Financial Intelligence Unit

Build these reporting workflows into the compliance architecture from the start, automated wherever possible, with manual review queues for the borderline cases that automation cannot confidently resolve.

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 to stablecoin	Circle (direct mint), Coinbase Prime, B2C2, Bitstamp
Off-Ramp	Stablecoin to fiat	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

When Should You Actually Recommend Stablecoin Rails?

Bring this framework into every payment architecture review where stablecoins are on the table.

Decision Criterion	Weight: Stablecoin Rails	Weight: Traditional Rails
Cross-border corridor cost above $10	Strong case	—
24/7 settlement required	Strong case	—
Settlement speed under 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 above $5M, thin corridor liquidity	—	Traditional or hybrid
Domestic payment in jurisdiction with strong local rails	—	Traditional preferred
Counterparty has no access to a stablecoin off-ramp	—	Traditional until off-ramp exists

The architects who get this right are not rooting for stablecoins or for traditional rails. They are matching the right tool to the specific payment, corridor, counterparty, and regulatory context in front of them — every single time, without a house bias either way.

Key Takeaways

• Pattern 1 (Lift-and-Shift) is the most commercially viable architecture today. It captures stablecoin rail benefits while preserving the fiat experience for both sides. Most of the engineering complexity lives in on-ramp/off-ramp design.
• Pattern 2 (Native Wallet-to-Wallet) fits sophisticated institutional counterparties and demands full Travel Rule compliance, multi-sig custody, and AML screening as non-negotiable design components, not add-ons.
• Pattern 3 (CBDC Bridge) is the frontier of wholesale settlement, already live in pilot and heading toward commercial deployment. Architects advising central banks or SIFIs need to understand this direction now, not in three years.
• The ISO 20022 to blockchain data gap is real and unsolved at scale today. A three-layer architecture, data mapping, reconciliation engine, and status reporting, bridges it until native blockchain standards mature.
• Compliance architecture (KYC, AML, sanctions, Travel Rule, regulatory reporting) has to be designed in from day one. Retrofitting it later costs more and carries far more risk than building it in from the start.

Series Conclusion: You Are Now Stablecoin-Ready

Across five articles, you have now covered the full 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 of the topic. Stablecoins are moving fast. Regulatory frameworks are still being finalised. mBridge is expanding its participant base. SWIFT is piloting tokenised asset settlement. The ECB continues progressing the digital euro.

The foundation from this series gives you the mental models, the vocabulary, the risk awareness, and the architectural patterns to absorb and evaluate whatever comes next. The payments industry is changing. You are equipped to lead that change for your clients, your team, and your organisation, not just react to it.

Frequently Asked Questions