How global merchants get paid across borders with stablecoins, no pre-funding required

Pre-funding means parking local currency in every market before money moves. Stablecoin virtual accounts remove it. A worked example across 4 countries.

Pre-funding means holding local currency balances in every market before a payment can move there: reais in Brazil, pesos in Mexico, euros in Europe, all parked in local accounts ahead of time. It ties up capital, spreads it thin, and exposes it to FX swings. Stablecoin-based virtual accounts remove that requirement. Value crosses the border as a digital dollar (USDC or USDT) and converts into local currency at execution, at a locked rate, then lands over the local rail in minutes. One float, in one place, instead of one per country.

That single change is what makes launching a new market a product decision instead of a treasury project.

Why do cross-border merchants pre-fund at all?

Because traditional rails can't move value across a border in real time.

A payout to a Brazilian seller over SWIFT passes through correspondent banks, each settling on its own schedule, over one to five business days. If a provider promises "instant" payouts in Brazil on those rails, the only way to deliver is to already have reais in Brazil. So they pre-fund. They keep balances in nostro accounts in every market, sized to cover the next few days or weeks of payouts, and top them up with slow wires.

That model has four built-in costs:

  • Trapped capital. Money sitting in ten countries is money not working anywhere.
  • Fragmented liquidity. Brazil runs dry while Mexico sits on a surplus. Rebalancing takes days.
  • FX exposure. Every idle local balance moves with the currency while it waits.
  • Banking hours. Top-ups stop on weekends and holidays, so buffers have to cover them.

Whoever carries those costs passes them on, usually as a wider FX spread on the merchant's payouts.

How do stablecoin rails change the model?

The stablecoin becomes the shared settlement asset across every market. Instead of pre-positioning reais, pesos, and euros, the merchant (or its provider) holds dollars in stablecoin form and converts at the moment a payment executes.

The flow looks like this:

  1. Collect. Customers pay into a virtual account by bank transfer, or pay in USDC/USDT directly. Bank deposits auto-convert into stablecoins.
  2. Hold one float. Balances sit in stablecoins, not in ten local accounts.
  3. Quote. When a payout is due, request a quote: amount, destination currency, destination account.
  4. Convert at execution. The rate is locked when the payment runs. No balance needed in the destination country beforehand.
  5. Deliver over the local rail. Pix in Brazil, SPEI in Mexico, SEPA in Europe. Minutes on instant rails.

BlindPay settles this way by design: no capital pre-positioned in destination accounts before a payout clears. It runs 24/7, so Saturday payouts don't wait for Monday top-ups. We wrote about why the stablecoin part should stay invisible to the merchant in Stablecoin for the Ordinary.

A worked example: one merchant, four markets

A US-based marketplace pays sellers in Brazil, Mexico, Colombia, and Europe. Monthly payouts: $400,000 to Brazil, $300,000 to Mexico, $150,000 to Colombia, $150,000 to Europe. $1M a month total.

These figures are illustrative, but the shape is what every finance lead running multi-market payouts recognizes.

Stablecoin virtual account modelTraditional pre-funded model
Capital parked in destination markets$0 in destination markets; one stablecoin floatTwo weeks of payout buffer per market: about $500,000
Cost of that capital at 8% a yearNone for destination buffersAbout $40,000 a year, before FX losses on idle balances
Local bank relationshipsOne API integrationFour, often with a local entity or partner in each
Time to launch a fifth marketDays to weeks, once the market is covered and your KYB is doneMonths: local entity or partner, bank account, compliance setup, then funding
Weekend payoutsYes, 24/7Limited by top-up windows
Payout speedMinutes on Pix, SPEI, and other instant railsFast only while the local buffer lasts
FX pricingQuoted per payment, spread and payout fee itemizedWider spreads to cover the provider's funding costs

The $500,000 is the number that gets a CFO's attention. It's half a month of payouts doing nothing, spread across four currencies, losing value whenever one of them weakens against the dollar.

The launch time is the number that gets a founder's attention. Adding Argentina under the old model is a project. Under the stablecoin model, it's a new destination currency in the same API call: Transfers 3.0 to a CBU or CVU.

How does local payment rail orchestration work on the payout side?

Stablecoins handle the border. Local rails handle the last mile, and they're different in every country. Orchestration means picking the right rail per destination and handling its quirks so the merchant doesn't have to.

DestinationRails BlindPay pays out onTypical speed
BrazilPix, TED, BoletoMinutes on Pix, 24/7
MexicoSPEIMinutes, 24/7
ColombiaPSEUsually minutes, within bank windows
ArgentinaTransfers 3.0 (CBU/CVU)Same day
United StatesACH, RTP, domestic wireSeconds on RTP; same day to 2 days on ACH
EuropeSEPA, across 40 SEPA-zone countriesSame day or next day
Everywhere elseSWIFT (POBO/COBO), with UETR tracking and MT103 confirmations1 to 5 business days

BlindPay covers 100+ countries and 80+ currencies this way, from one integration. The full list is on the coverage page.

On the collection side, virtual accounts do the reverse: BlindPay issues US and local bank accounts in your name or your customer's name. A US buyer pays by ACH or wire like any domestic invoice. The deposit auto-converts into stablecoins and can settle to your local currency right after. No US entity required. We covered this in detail when we launched Named Virtual Accounts.

What compliance does this model need?

Moving money across borders without a local bank in every market doesn't mean moving it without rules. Doing this legitimately takes:

  • KYB on the merchant. Company documents, beneficial owners, business activity. See what KYB is.
  • KYC on individual payees. Sellers, contractors, and creators receiving payouts get verified before their first payment.
  • Sanctions and watchlist screening on every counterparty and transaction.
  • On-chain monitoring of the stablecoin leg for exposure to sanctioned or high-risk wallets.
  • Local licensing in each market the provider serves. Brazil, for example, licenses virtual asset service providers under its own regime; see our PSAV explainer. The EU runs MiCA.

BlindPay runs KYC, KYB, sanctions screening, and transaction monitoring inside the same API, and publishes its licenses on the licenses page. The merchant stays responsible for its own tax and accounting records in each market.

Is this model right for your expansion plans?

Run through this checklist:

  • You pay out, or plan to pay out, in two or more countries.
  • You currently keep, or would need to keep, local balances in those markets.
  • Your payees are sellers, contractors, creators, or suppliers who want local currency in a local bank account.
  • Payout speed matters to retention: sellers leave platforms that pay slowly.
  • You want to launch new markets without opening a bank relationship in each.
  • Your finance team wants one reconciliation flow instead of one per country.
  • You can complete KYB and collect KYC data from payees.

Three or more checks, and the pre-funded model is probably costing you more than you think.

For more on the mechanics, read stablecoin settlement explained, and for a cost breakdown, stablecoin fees vs card processing fees. If you're comparing conversion partners, see how to choose an on/off-ramp provider.

Expand without parking capital

Every market you add under the old model costs a bank relationship and a buffer. Under a stablecoin model it costs a destination currency. If you want to map your current payout flows against this model, talk to the BlindPay team.

FAQ