Home / Cross-Border Payments

Cross-Border USDC Payment Rail

On-chain USDC settlement in under 10 seconds with atomic FX conversion, real-time sanctions screening, and SWIFT ISO 20022 integration.

Cross-Border USDC Payment Rail

In Plain English

Imagine sending money from New York to Berlin. Normally it takes 3-5 days and costs $35. With Tokenize, the on-chain transfer completes in under 10 seconds and costs 2 cents — like sending an email instead of a letter. The full end-to-end flow includes off-chain banking steps (SWIFT messaging, SEPA credit) which add time but still beat traditional correspondent banking. Your money moves on blockchain, but the payment details travel through normal banking channels (SWIFT), so both banks can verify everything matches.

How It Works

Alice in the US sends 1,000 USDC to Bob in the EU. The payment leverages the CBPR (Cross-Border Payment Rail) smart contract on Sepolia testnet, with embedded compliance checks, corridor validation, and real-time settlement.

Demo vs Production: This demo shows direct USDC transfer (simplest flow). In production, the PvP FX swap (described below) converts USDC → EURC atomically, then EURC is redeemed to EUR fiat via SEPA Instant — so Bob receives EUR, not USDC.

UCITS Audit Trail: Under UCITS/AIFMD regulations, the TMMF→TMF transition is treated as two separate transactions: (1) redemption of TMMF shares (redemption event) and (2) subscription to TMF shares (new subscription). The smart contract emits two separate events (TMMFRedeemed and TMFSubscribed) to maintain the required audit trail for fund administrator sign-off and depositary verification.

Enterprise Architecture Context

Business Value: This demo replaces legacy SWIFT MT103 wire transfers (3-5 day settlement, $25-50 fees) with on-chain USDC settlement in under 10 seconds at ~$0.02 cost. Production uses ISO 20022 pacs.008 — under the SWIFT CBPR+ programme, MT messages were retired for cross-border payments in November 2025 (coexistence mode ran alongside during the transition). The CBPR contract acts as a smart escrow — funds are locked when the payment is initiated, validated against corridor rules and compliance status, then released to the recipient upon settlement confirmation.

Integration Architecture: In production, this blockchain layer sits alongside legacy banking systems. The Middleware Service receives payment instructions from SAP/Oracle Financials, validates them against the CorridorRegistry for routing rules, checks the IdentityRegistry for KYC/AML compliance, and then submits the transaction to the CBPR contract. Settlement status flows back to the legacy core via the same middleware.

3-5 days
Legacy SWIFT Messaging (3-5 day settlement via correspondent banks)
~$35.00
Traditional Wire Fee
<10 sec
Tokenize Settlement

Architecture Flow — Cross-Border Payment

Standards used: ERC-20 (USDC transfers), FATF Travel Rule (KYC/AML), ISO 20022 pacs.008 (payment data), SWIFT (bank routing), hash commitment (data integrity).

1
Payment Initiation
Frontend

Alice enters payment details. Frontend looks up Bob's BIC from IdentityRegistry (ERC-3643 T-REX identity standard for regulated tokens; custom contract on-chain, not ERC-725 which is a key manager standard).

2
Compliance Check
On-Chain

IdentityRegistry.checkCompliance() — FATF Travel Rule: verifies KYC, accreditation level, sanctions screening.

3
Corridor Validation
On-Chain

CorridorRegistry.validateCorridor() — checks active routes, min/max limits, sanctions restrictions.

4
USDC Escrow (ERC-20)
On-Chain Transfer

USDC.transferFrom() — Alice's USDC (ERC-20) transferred to CBPR contract as escrow.

5
Hash Commitment + SWIFT
Two Channels

Channel 1 (Blockchain): keccak256(SWIFT_XML) stored on-chain as tamper-proof receipt.

Channel 2 (SWIFT): ISO 20022 pacs.008 XML sent to Bob's bank BIC — carries full payment data (invoice, line items, tax).

6
Settlement & Verification
Final

Bob's bank: Receives ISO 20022 XML via SWIFT → computes hash → compares to on-chain hash → verifies integrity → credits Bob's account.

Blockchain: 3-of-5 multi-sig releases USDC from escrow to Bob's wallet address (ERC-20 transfer).

Step-by-Step Data Flow & System Integration

1
Payment Initiation — Frontend / Mobile App
User Action

Alice opens the Tokenize web application and enters the payment details: recipient address, amount, corridor (US-EU), and purpose of payment (memo). The frontend validates the inputs and displays a summary screen showing all payment details including fees, exchange rates, and estimated settlement time.

// Frontend constructs payment object
{ recipient: "0x9ABC...DEF0", amount: 1000, corridor: "US-EU", memo: "Invoice #INV-2024-001" }
2
Compliance Check — IdentityRegistry Contract
On-Chain Validation

Before any funds move, the CBPR contract calls identityRegistry.checkCompliance(Alice) to verify that Alice has completed KYC and is not on any sanctions list. This is a non-revertible check — if Alice is unverified, the transaction reverts immediately with "UNVERIFIED_SENDER". This ensures regulatory compliance at the smart contract level, not just at the application layer.

// CBPR.sol:83 — Compliance check
require(identityRegistry.checkCompliance(msg.sender), "UNVERIFIED_SENDER");
3
Corridor Validation — CorridorRegistry Contract
On-Chain Validation

The CBPR contract validates the requested corridor (US-EU) against the CorridorRegistry. This checks that: (a) the corridor is active, (b) the payment amount falls within allowed min/max limits for this corridor, and (c) there are no sanctions or restrictions on this route. In production, this would also include AML screening against OFAC, EU, and UN sanctions lists. The Middleware Service pre-validates this data before the on-chain call, but the contract performs the definitive check.

// CBPR.sol:81 — Corridor validation
require(corridorRegistry.validateCorridor(corridorId, amount), "INVALID_CORRIDOR");
4
Fund Escrow — USDC Token Transfer
On-Chain Transfer

Alice's USDC is transferred from her wallet to the CBPR contract using transferFrom(). This requires Alice to have previously approved the CBPR contract to spend her USDC (a one-time ERC-20 allowance). The funds now sit in the CBPR contract as an escrow — they are locked until the settlement is confirmed. This two-phase approach (escrow → release) provides a safety mechanism: if settlement fails, funds can be reversed back to the sender.

// CBPR.sol:84 — Escrow transfer
require(usdcToken.transferFrom(msg.sender, address(this), amount), "USDC_TRANSFER_FAILED");
5
Transaction Recording — Blockchain Ledger
Immutable Record

The CBPR contract generates a unique transaction ID using keccak256(abi.encodePacked(sender, recipient, amount, timestamp, corridorId)). This ID serves as the immutable reference for the entire payment lifecycle. The transaction is recorded on-chain with status PENDING and a PaymentInitiated event is emitted. This event is picked up by the Middleware Service, which updates the legacy core banking system (SAP/Oracle) with the new payment status.

// Event emitted to all listeners
emit PaymentInitiated(txId, sender, recipient, amount, corridorId);
// Middleware Service picks up event → updates SAP/Oracle
6
Settlement Confirmation — Multi-Sig Governance
Multi-Sig Release

Settlement requires 3-of-5 multi-signature approval via Gnosis Safe. The five signers are: (1) Sending Bank Node, (2) Receiving Bank Node, (3) Compliance Officer, (4) Platform Treasury, (5) Independent Validator. This ensures no single party can unilaterally release or freeze funds. The CBPR contract then transfers the USDC from escrow to Bob's address. The transaction status is updated to SETTLED and a SettlementConfirmed event is emitted. The Middleware Service propagates this to the legacy systems, completing the payment lifecycle.

// CBPR.sol:108 — Release escrow to recipient
require(usdcToken.transfer(paymentTx.recipient, paymentTx.amount), "USDC_TRANSFER_FAILED");

Payment Details

Sender

Alice (0x1234...5678)

Recipient

Bob (0x9ABC...DEF0)

Amount

1,000 USDC

Corridor

🇺🇸 US → 🇪🇺 EU

Purpose of Payment

Goods — Invoice #INV-2024-001

Transaction ID

0x... (generated on-chain)

Traditional Cost

$35.00

Tokenize Cost

~$0.02

Cost breakdown: The ~$0.02 figure reflects Sepolia testnet gas costs. In production, the platform would deploy on Base L2 (≈$0.001-0.01 per tx) or a permissioned EVM chain (zero gas). Legacy SWIFT MT103 fees ($25-50) include correspondent bank margins, not just network fees.

Receiver Information (KYC-Verified)

Legal Name

Robert Müller

Country

🇩🇪 Germany

Wallet Address

0x9ABC...DEF0

KYC Status

Verified

Bank (Legacy)

Deutsche Bank AG

IBAN

DE89 3704 0044 0532 0130 00

Legacy System Integration Points

SAP S/4HANA / Oracle Financials

Receives payment status updates via Middleware Service REST API. Ledger entries created for accounting reconciliation.

SWIFT Network (ISO 20022 pacs.008)

Used for rich payment data exchange between banks. The blockchain runs in parallel for USDC escrow and hash verification — it does not replace SWIFT.

KYC Provider (Sumsub / Jumio)

Off-chain identity verification performed before on-chain registration. Results stored as on-chain compliance flags.

Live Contract Interaction

Simulation Mode — All demos work without MetaMask. Click buttons to simulate the full flow.

Developer Mode — Direct Wallet Access

WARNING: Private Key Input

DEMO ONLY — Sepolia Testnet: This private key only controls testnet tokens with no real-world value. Never use real wallet keys on any demo page. In production, you'd use MetaMask, a hardware wallet, or ERC-4337 account abstraction (bank-sponsored gas, no seed phrases).

Enter your Sepolia wallet private key. Your key never leaves your browser.

Banking Production: Customers never pay gas directly. The bank sponsors all transactions via ERC-4337 Account Abstraction paymaster — customers interact with a simple web UI, no wallet setup needed.

Two channels require two identifiers:

Blockchain:
Wallet address (USDC escrow)
SWIFT:
BIC/SWIFT code (routes ISO 20022 XML)

For USDC escrow on-chain

For ISO 20022 XML delivery via SWIFT network

Stored off-chain; referenced by txId on-chain