Cross-Border Merchant Payments Without Pre-Funding in Stablecoins

Cross-border merchant payments without pre-funding are payments where the merchant collects in each buyer's local currency and converts to a dollar stablecoin when the money settles, instead of holding local-currency balances in every market beforehand. The merchant keeps one stablecoin float in one place, and each new market costs a rail and a verification, not a bank balance.

Pre-funding is a treasury habit more than a technical requirement: the usual cross-border path is slow, so a merchant that wants to pay out in minutes parks money in the destination ahead of time. FX swaps and local acquirers are the other route; this guide covers the stablecoin one. If the token is new, start with what a stablecoin is.

Pre-funding is a buffer, and it exists because refills are slow

Pre-funding means holding local currency in a market before a payment can move there: reais for Brazil, pesos for Mexico, euros for Europe. The merchant, or the provider acting for it, keeps a balance at a local bank and tops it up by wire.

The top-up is the problem. A USD SWIFT payment takes one to five business days according to the Lumx rail cut-off table, and it can pass through intermediary banks that each add hours or days and may deduct fees. A buffer has to cover at least as many days of payouts as the refill takes to arrive, because a refill by wire cannot be rushed once the balance is empty. Every market needs its own safety stock.

How much capital does pre-funding tie up?

The sizing rule is one line: buffer = daily payout volume x days of coverage, where days of coverage is at least the refill time in calendar days. The cost is buffer x your cost of capital.

Take a merchant paying out $1,000,000 a month across its markets, about $33,333 a day. The 8% a year below is an assumption for the example, not a market rate. Swap in your own cost of capital.

Capital parked in destination markets at $1,000,000 a month in payouts, 8% a year assumed.

The real number is worse: each market needs its own margin, and a balance in a local currency is exposed to that currency's moves, which the 8% leaves out.

One day of payouts held as a stablecoin float costs about $2,667 a year, against $18,667 for the 7-day buffer.

Without pre-funding, destination markets hold $0. The merchant still holds a stablecoin float, covered in its own section below, but it is one pool and it can be refilled on any day of the week.

Collect on the local rail, convert at settlement

The mechanism needs no balance in the buyer's country. The buyer pays on a local rail: Pix (Brazil's instant payment system, run by the Central Bank) in Brazil, SPEI (Mexico's interbank transfer system, run by Banxico) in Mexico, an ordinary bank transfer elsewhere. The deposit converts to USDC or USDT when it lands, so the merchant never manages the local currency as a balance. The stablecoin arrives in the merchant's wallet: one balance in one currency, whatever the buyer's country.

The collection account has to be in the merchant's own name. A named virtual account (a local account number issued in the customer's own name) does that, and the deposit identifies the merchant on arrival. See the named virtual account explainer and B2B invoice matching.

On Lumx, the merchant is a customer with its own wallet, and a foreign company can hold named accounts in BRL and MXN without an entity in Brazil or Mexico. EUR and GBP accounts are named too and collect from payers abroad, and the COP account is named only when the customer is Colombian, with the banking partner shown otherwise. For a checkout, the merchant creates an on-ramp with the rail, the amount and TRADE_TRANSACTIONS as the purpose, and the response carries what the buyer needs to pay: a Pix brCode or a SPEI CLABE (the 18-digit Mexican bank account number). The transaction moves through AWAITING_FUNDS, TRANSFERRING_FIAT, TRADING and TRANSFERRING_STABLECOIN to SUCCESS, and the onramp.success webhook is the cue to mark the order as paid. For deposits that arrive on a schedule, an autoconversion rule on the account converts every matching deposit to USDC or USDT without a per-payment call.

Rail by rail: what the buyer pays on and when it settles

The settlement and cut-off columns are Lumx processing targets, not guarantees, and the receiving institution can add its own hold.

Collection rails by currency, with cut-off and settlement targets from the Lumx docs, read on November 1, 2026.

Pair pages: BRL to USDC, MXN to USDC, USD to USDC. In Colombia, the COP account collects through a Bre-B (Colombia's instant payment system) key and through PSE (Colombia's online bank-transfer network).

Lumx picks the SEPA scheme and you always send SEPA. ACH, FEDWIRE and SWIFT follow US business days, and their cut-offs are processing targets that can push settlement to the next business day, so a merchant whose buyers pay by wire plans for that, not for the instant rails. ACH is credit (push) only, so the payer sends and Lumx never pulls. The USD account is also the slow one to open: BRL, MXN, EUR and GBP accounts are immediate once the customer is approved, while USD takes up to one business day for the banking partner's review. SWIFT on Lumx is USD only.

An on-ramp created per sale has a payment window, and an unpaid one expires: after one day for a Pix or SPEI payment at a floating rate, after seven days on other rails. A deposit that lands after expiry is refunded to the sender on the same rail. A deposit on an autoconversion rule needs no per-payment call and is converted when it arrives.

How the rate is fixed when there is no balance to absorb it

With a local balance, the merchant carries the FX risk while the money sits. With collect-and-convert, the exposure lasts only between quote and execution. A floating rate is a real-time reference with no lock, so execution can differ slightly. A locked rate fixes the conversion for 30 seconds, one minute or five minutes. The 30-second lock carries no fee, and the longer windows add a fee that covers the volatility risk. If the lock expires before the transaction is submitted, the quote is no longer valid and the merchant requests a new one.

On Lumx, the locked rate is a POST /exchange-rates call that returns an exchangeRateId, passed on the transaction request. The quote shows the base rate and the final rate after fees, so the merchant sees both numbers before submitting. An autoconversion rule always converts at market and does not take a locked quote. Locked quotes exist on the one-off transaction.

The float you still hold, and how to keep it small

"No pre-funding" does not mean no balance anywhere. A payout debits the merchant's wallet, so the wallet needs stablecoin in it, and a payout larger than the balance fails with an insufficient-balance error. What changes is where the balance sits and what it is made of: one wallet in a dollar stablecoin, not several local accounts. On Lumx, no pre-funding means no capital idle in settlement (nostro) accounts before a transaction; conversion and settlement happen when it starts, and a USDC balance in the wallet does not contradict that.

I would size that float to the slowest way you can refill it, not to a comfortable round number of days. If a merchant collects and pays out in the same markets, I would let the collections refill the wallet, and treat any shortfall as a sign to move the refill earlier, not to hold more. And I would write down, before launch, who is allowed to top it up and what happens when it is empty, because the empty wallet is the failure mode this model has.

Three habits keep the float small. Net inbound against outbound: each collection credits the wallet that funds payouts, so sales in Brazil and suppliers in Mexico leave only the difference. Refill without a bank: a stablecoin transfer works on any day. And choose the stablecoin on purpose: USDC versus USDT differ in reserve disclosures and network support, and holding either carries a small depeg risk.

On Lumx, every customer gets a wallet on each supported blockchain when it is created, and the wallet becomes usable once the customer is approved. Payouts are off-ramps from that wallet to a destination registered under the same customer.

What the merchant needs in place

The merchant is verified as a business: company documents, ultimate beneficial owners and business activity. That is KYB (know your business, the verification of a company and its owners). A compliance hold that asks for a document before a transaction clears is an RFI (request for information). A merchant collecting its own revenue is the simple case. Lumx requires that every transaction be the customer's own funds and the customer's own business: collecting for an entity that is not onboarded, or for several underlying businesses under one customer, is nested activity and needs written approval from compliance. A platform collecting for sellers onboards each seller as its own customer. Whether the merchant itself needs a license is a separate answer by country, covered in merchant licensing for stablecoin payments. For liability, see compliance ownership in a stablecoin API.

On Lumx, the KYB, the per-destination verification and the conversion sit inside the API, with Sumsub for KYC (know your customer, the verification of an individual) and Chainalysis for blockchain monitoring. Transactions flagged by monitoring are held pending review, which is the RFI above. Lumx targets two business days for KYB Standard and three for Enhanced.

When no pre-funding is the wrong model

Three cases point the other way, and in each of them the stablecoin leg adds steps without removing a cost. A merchant that sells and pays out in one market already holds that currency locally, so a stablecoin leg adds a conversion for no saving. A merchant whose revenue comes mostly through card networks has a different collection decision, and stablecoin versus card fees is where to start the arithmetic. And a refund-heavy business needs a refund process built around finality, since a stablecoin transfer cannot be recalled once it confirms; are stablecoin payments reversible covers it.

What this looks like on Lumx

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

The setup is short. Create the merchant as a customer and request the currencies it needs in the accounts array, since each currency account has to be requested before you collect or pay out in it: each becomes an account that waits for approval, then provisions. Create an on-ramp per sale, or an autoconversion rule per account, and subscribe to onramp.success and account.active so the order system learns of each change without polling. The product page for named accounts shows the account side.

The pricing model is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. Settlement tracking is UETR and MT103 confirmations on every SWIFT payout, per-rail reference on every transfer, webhooks. For activation, BRL, MXN, EUR and GBP accounts are immediate after approval and USD takes up to one business day; a 30-second locked rate carries no fee. For one country, see the Brazil merchant guide; for the conversion step, the on-ramp explainer.

Methodology and sources

Rail, cut-off, activation and expiry figures come from the Lumx documentation pages on Coverage, payment rail cut-off times, Accounts, Exchange Rates, Transactions, Stablecoin Wallets, Autoconversion Rules and Nested Payments, all read on November 1, 2026. The sizing table is arithmetic on stated assumptions, not a Lumx price.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Venti Views on Unsplash.