
Building a stablecoin remittance app requires five infrastructure components: embedded wallets for sender and recipient, a transaction orchestration layer to route payments, gas sponsorship so users never pay network fees, KYC/AML integration for compliance, and optional off-ramp connections to convert stablecoins into local currency. This guide walks through each layer, the architecture decisions you'll face, and how to go from zero to a working prototype.
Why stablecoins for remittances
The global remittance market moves over $800 billion annually [Source: World Bank Migration and Development Brief, 2025]. The average cost of sending $200 across borders is 6.4% — roughly $51 per transaction [Source: World Bank Remittance Prices Worldwide, Q4 2025]. That cost falls disproportionately on the people who can afford it least: migrant workers sending money to families in low- and middle-income countries. Traditional rails — SWIFT, correspondent banking, money transfer operators — add fees at every hop.
Stablecoins collapse the cost structure. A USDC transfer on an L2 like Base or Arbitrum costs under $0.01 in network fees and settles in seconds. Even accounting for on-ramp and off-ramp costs, total corridor costs can stay under 1% for many routes. The math is straightforward: fewer intermediaries, lower fees.
Speed matters too. Traditional cross-border transfers take 2-5 business days. Stablecoins settle on-chain in seconds to minutes depending on the network. For a family waiting on rent money, the difference between "arrives Friday" and "arrives now" is material.
Then there's access. An estimated 1.4 billion adults globally remain unbanked [Source: World Bank Global Findex Database, 2024], but smartphone penetration continues to rise in the same regions. A stablecoin wallet doesn't require a bank account, a credit check, or a physical branch visit. It requires a phone and an internet connection.
The regulatory environment is catching up. The EU's Markets in Crypto-Assets (MiCA) regulation provides a clear framework for stablecoin issuance and services. In the US, stablecoin legislation is progressing through Congress with bipartisan support. These frameworks reduce legal ambiguity — the biggest barrier that kept serious operators out of the space.
Architecture of a stablecoin remittance app
Here's the high-level architecture. Every production remittance app needs some version of these components:
_10[Sender App] --> [Wallet Layer] --> [Transaction Layer] --> [Settlement] --> [Recipient Wallet]_10 | | | | |_10 Auth + Embedded Gas Sponsorship On-chain Off-ramp_10 KYC Wallets + Orchestration Settlement (optional)
Let's walk through each layer.
User onboarding and auth
Your users are sending money to family. They are not interested in seed phrases, browser extensions, or gas tokens. Onboarding must feel like signing up for any fintech app: email, phone number, or social login.
The KYC integration point sits here. Depending on your corridor and licensing, you'll need identity verification before the first transaction. Most teams integrate a third-party KYC provider (Sumsub, Onfido, Jumio) via API. Design your onboarding flow so KYC happens inline — don't send users to a separate portal.
Key decisions at this layer:
- Auth method: Social login (Google, Apple) for fastest onboarding. Phone/SMS for markets where email usage is low.
- KYC timing: Upfront (before first transaction) vs. progressive (allow small amounts, require full KYC at thresholds).
- Data residency: Where you store PII matters for compliance. Pick a KYC provider with regional coverage for your target corridors.
Wallet creation
Each user — sender and recipient — needs a wallet. The wallet must be:
- Embedded: Created automatically during signup. No separate install or setup step.
- Non-custodial: The user controls their keys, not you. This matters for licensing (custodial wallets trigger money transmitter requirements in most jurisdictions).
- Invisible: The user sees "balance: $50.00" — not "0x7a3b...wallet address." They never interact with the wallet directly.
Smart accounts (ERC-4337) are the standard approach here. They give you programmable wallets with recovery options, spending policies, and session keys — without requiring the user to manage private keys.
The wallet layer is the hardest to build in-house. Key management, account abstraction, recovery flows, and multi-device support represent 3-6 months of engineering work. This is where most teams reach for infrastructure.
Transaction orchestration
This is the core of your remittance product. The flow:
- Sender initiates a transfer ($100 to recipient in Mexico)
- System converts fiat to stablecoin (if sender deposits fiat) or debits sender's stablecoin balance
- Compliance checks run (sanctions screening, transaction monitoring)
- Stablecoin transfers from sender's wallet to recipient's wallet
- Recipient is notified
- Recipient withdraws to local currency (off-ramp) or holds stablecoin balance
The orchestration layer handles routing, retries, fee calculation, and policy enforcement. You need:
- Transaction policies: Spending limits, daily caps, recipient allowlists. These are often regulatory requirements.
- Compliance hooks: Pre-transaction checks against sanctions lists (OFAC, EU sanctions). Post-transaction monitoring for suspicious patterns.
- Multi-step execution: A single "send money" action may involve multiple on-chain transactions (approve, transfer, bridge). The orchestration layer abstracts this into one operation.
- Status tracking: Users need real-time status updates. "Processing," "Sent," "Available for withdrawal."
Gas sponsorship
This is non-negotiable for a remittance product. If your user in the Philippines has to acquire ETH to pay gas fees before sending USDC, you've lost them. The remittance app must sponsor all transaction costs.
Gas sponsorship works through paymasters (ERC-4337). The paymaster contract pays gas fees on behalf of the user. Your app funds the paymaster, and you absorb gas costs as a cost of doing business — or build them into your fee structure.
The economics work in your favor. On L2 networks, gas costs per transaction are fractions of a cent. Even at scale, gas sponsorship is a rounding error compared to the revenue from remittance fees.
Off-ramp (recipient side)
The recipient needs local currency. This is the "last mile" problem and often the hardest piece of the stack.
Options:
- Mobile money integration: In sub-Saharan Africa and Southeast Asia, mobile money (M-Pesa, GCash) is the dominant payment method. Integrate via aggregators like Flutterwave, Chipper Cash, or local providers.
- Bank transfer: Direct deposit to a local bank account via local payment rails (PIX in Brazil, UPI in India, SPEI in Mexico).
- Cash pickup: Partner with cash pickup networks for markets where digital payments are limited.
- Stablecoin-native: In some corridors, recipients prefer to hold stablecoins (e.g., recipients in Argentina or Nigeria where local currency depreciates). No off-ramp needed.
You don't have to build the off-ramp yourself. Companies like Unlimit, Wyre (depending on availability), or regional providers handle fiat conversion. Your infrastructure connects to their APIs.
Multi-chain considerations
Not all chains are equal for remittances. What matters:
| Factor | What to look for |
|---|---|
| Transaction cost | Sub-cent per transfer |
| Settlement time | Under 30 seconds |
| Stablecoin liquidity | Deep USDC/USDT pools |
| Off-ramp support | Fiat providers integrated on-chain |
| Reliability | 99.9%+ uptime, no frequent reorgs |
Practical options in 2026:
- Base, Arbitrum, Optimism (Ethereum L2s): Low fees, strong USDC support, large ecosystem of off-ramp providers. Good default choice.
- Solana: Fast and cheap, growing stablecoin ecosystem. Strong in Latin American corridors.
- Tron: Dominant in USDT transfers, especially Asia corridors. Higher centralization concerns but massive existing volume.
- Stellar: Built specifically for cross-border payments. Native anchor network for fiat on/off ramps. Smaller developer ecosystem.
Pick based on your target corridor. If you're building for US-to-Mexico, Base + USDC is a reasonable starting point. If you're building for Asia, Tron's existing USDT liquidity is hard to ignore.
Build vs. buy vs. stitch
Three approaches to assembling your infrastructure stack:
| Approach | Time to ship | Ongoing maintenance | Cost | Control |
|---|---|---|---|---|
| Build in-house | 6-12 months | High | High (3-5 engineers full-time) | Full |
| Stitch 3-5 vendors | 2-4 months | Medium (multi-vendor coordination) | Medium ($2-5K/mo across vendors) | Partial |
| Stablecoin product infrastructure | 1-2 weeks | Low (one vendor) | Low ($99-599/mo) | Full (if open-source) |
Build in-house
You hire cryptography engineers, build key management from scratch, implement ERC-4337 bundlers and paymasters, and own every line of code.
When this makes sense: You're a well-funded company with 12+ months of runway, the wallet layer is your core differentiator, and you have engineers with production smart account experience.
When it doesn't: You're a startup trying to validate product-market fit in a specific remittance corridor. Spending 6 months on wallet infrastructure before sending your first transaction is a fast way to run out of money.
Stitch multiple vendors
You combine a wallet provider + a gas sponsorship service + a transaction monitoring tool + an on-ramp/off-ramp API. Each does one thing.
When this makes sense: You need best-of-breed for each layer and have the engineering bandwidth to integrate and maintain multiple vendor relationships.
The problem: Integration overhead. Each vendor has its own SDK, auth system, error handling patterns, and release cycle. When something breaks at 2 AM, you're debugging across four dashboards. Version upgrades cascade. Your "simple" architecture diagram becomes a spaghetti of API calls.
Stablecoin product infrastructure
One SDK that handles embedded wallets, smart accounts, gas sponsorship, and transaction orchestration. You focus on your remittance product logic — corridors, pricing, user experience — instead of infrastructure plumbing.
When this makes sense: You want to ship a working product in weeks, not months. You need the infrastructure to be reliable while you focus on what actually differentiates your product (corridors, partnerships, user experience, pricing).
The tradeoff: You're depending on a provider. This is mitigated if the infrastructure is open-source — you can fork, audit, self-host, and avoid lock-in. Look for providers that give you full control over keys and data.
Key infrastructure decisions
Custodial vs. non-custodial
This isn't just a technical choice. It determines your regulatory burden.
- Custodial: You hold user funds. This triggers money transmitter licensing in most jurisdictions (FinCEN in the US, FCA in the UK, national regulators across the EU). Licensing timelines: 6-18 months. Legal costs: $50K-500K depending on jurisdiction.
- Non-custodial: Users control their own keys via smart accounts. You provide infrastructure but never hold funds. This reduces (but doesn't eliminate) licensing requirements. You may still need to register as a virtual asset service provider (VASP) depending on your jurisdiction and services.
Recommendation for most startups: Start non-custodial. It lets you ship faster and validate your corridor before investing in licensing. If your product works and you need custodial features, add them later.
Which stablecoins
| Stablecoin | Best for | Considerations |
|---|---|---|
| USDC (Circle) | US-originated corridors, regulatory-sensitive markets | Fully reserved, regular audits, MiCA-compliant. Blacklisting capability. |
| USDT (Tether) | Asia, high-volume corridors | Deepest liquidity globally, dominant on Tron. Less regulatory clarity. |
| Regional stablecoins (BRZ, MXNT, EURC) | Specific corridors | Reduce FX conversion steps. Lower liquidity. |
Recommendation: Start with USDC for regulatory clarity. Add USDT if your corridor demands it. Consider regional stablecoins only when you have enough volume in a specific corridor to justify the integration.
KYC/AML integration
Don't build KYC in-house. Integrate a provider that covers your target markets:
- Global coverage: Sumsub, Onfido, Jumio
- Emerging markets: Smile Identity (Africa), Hyperverge (India, Southeast Asia)
- Transaction monitoring: Chainalysis, Elliptic, TRM Labs
Design your compliance architecture so the KYC provider and transaction monitoring are pluggable. Regulations change. You may need to swap providers or add layers as you enter new corridors.
Pricing your remittance product
You have costs: gas fees (negligible on L2s), on-ramp/off-ramp fees (0.5-2%), KYC costs ($0.50-2.00 per verification), infrastructure costs, and compliance overhead.
Common pricing models:
- Flat fee per transaction: $1-3 per send. Simple, transparent.
- Percentage fee: 0.5-2% of transaction amount. Scales with volume.
- FX spread: If you handle currency conversion, build margin into the exchange rate. Less transparent but standard in the industry.
Recommendation: Start with a flat fee. It's the easiest to explain and the hardest to hide margins in — which builds trust with your users.
Regulatory landscape
MiCA (EU)
The Markets in Crypto-Assets regulation, fully in effect since mid-2024, creates a clear framework for stablecoin services in the EU. If you're operating in or serving EU users:
- Stablecoin issuers need authorization as an Electronic Money Institution (EMI) or credit institution.
- Crypto-Asset Service Providers (CASPs) need licensing to offer services including transfers and custody.
- Non-custodial infrastructure providers face lighter requirements, but consult legal counsel for your specific case.
US stablecoin legislation
As of early 2026, US stablecoin legislation continues to advance. The direction is clear: federal framework for stablecoin issuance, state-level options for payment stablecoin licensing, and integration with existing money transmission frameworks. The specifics matter for your business — work with a fintech attorney who tracks this space.
How infrastructure choice affects compliance
Non-custodial, open-source infrastructure gives you two compliance advantages. First, you're not holding customer funds, which simplifies licensing in many jurisdictions. Second, open-source code is auditable — regulators and partners can verify exactly how funds are handled. This matters more as regulatory scrutiny increases.
Getting started: zero to prototype
Here's how to go from nothing to a working stablecoin remittance prototype in one to two weeks.
Step 1: Choose your corridor. Pick one sender country and one recipient country. US-to-Mexico, UK-to-Nigeria, UAE-to-Philippines — start narrow. Your corridor determines your stablecoin choice, chain choice, off-ramp partners, and compliance requirements.
Step 2: Choose your stablecoin and chain. For most corridors, start with USDC on an Ethereum L2 (Base or Arbitrum). Low fees, fast settlement, broad off-ramp support. You can add chains later.
Step 3: Set up wallet infrastructure. You need embedded, non-custodial wallets for both sender and recipient. This is the core infrastructure layer. Options include Openfort (open-source, one SDK covering wallets + smart accounts + gas sponsorship), or assembling separate wallet and account abstraction providers. [Openfort docs: https://openfort.io/docs]
Step 4: Integrate a KYC provider. Connect Sumsub, Onfido, or a regional provider. Implement identity verification in your signup flow. Start with document verification + selfie match — it covers most jurisdictions.
Step 5: Build the user flows. Three core screens: Send (amount, recipient), Transaction Status (real-time updates), and Receive/Withdraw (view balance, cash out). Keep the UI simple. Your users are sending money, not trading.
Step 6: Add gas sponsorship. Configure a paymaster so users never see gas fees. With Openfort, this is a policy configuration — set which transactions to sponsor and fund the paymaster. Your users see: "Fee: $1.50" (your remittance fee), not "Fee: $1.50 + 0.0003 ETH gas."
Step 7: Test with real transactions on testnet. Deploy to a testnet (Base Sepolia, Arbitrum Sepolia). Run end-to-end flows: create sender account, create recipient account, send stablecoins, verify receipt. Test edge cases: failed transactions, insufficient balance, KYC rejection.
Once testnet works, move to mainnet with small amounts. Monitor every transaction for the first few weeks.
Openfort provides the infrastructure layer for stablecoin remittance apps — embedded wallets, gas sponsorship, and transaction orchestration under one SDK. Start building free.
