How to pay suppliers in Latin America from Europe with stablecoins

Paying suppliers in Latin America from Europe with stablecoins means sending euros over SEPA to an account that converts them into USDC, then paying each supplier locally: reais over Pix (Brazil's instant payments), pesos over SPEI (Mexico's interbank transfers), or Colombian pesos over Bre-B (Colombia's instant payments) or ACH Colombia. The supplier receives a domestic bank transfer, never crypto.

Two conversions happen before the supplier sees anything, and the invoice currency fixes the rail, the supplier details and, in Colombia, the payment cap. This guide starts where a European payer starts, with the euros leaving the bank.

How does a European company pay a supplier in Latin America with stablecoins?

In four legs, one rail per leg. The company pays euros into its own EUR account, the euros convert into USDC, the USDC waits in a custodial wallet until the invoice is due, and a payout converts it into the supplier's currency and sends it to the supplier's bank.

The four legs of a payment from euros to a supplier's local account

Each pair of currencies and rails is a corridor (what a stablecoin corridor is), and the last leg is an off-ramp (what a stablecoin off-ramp is).

On Lumx, the European company is one customer with a EUR account, a custodial wallet and one destination per supplier. Legs 1 and 2 run as an on-ramp transaction, leg 4 runs as an off-ramp transaction, and both sit behind the same API and the same webhooks.

Which rail pays the supplier in each country?

One local rail per country, with Colombia offering two. The rail fixes what the supplier has to hand over: a Pix key or a CNPJ (the Brazilian company taxpayer ID) in Brazil, a CLABE (the 18-digit Mexican bank account number) in Mexico, and in Colombia either a key on Bre-B (Colombia's instant payment system, launched in 2025) or bank details for ACH Colombia.

Payout rail, supplier details and settlement by country (Lumx docs, read November 1, 2026)

In Colombia the rail is chosen when you register the supplier, not when you pay. A Bre-B payout above 1,000 UVB is refused, and Lumx does not split it or send it down another rail. For 2026 that cap is COP 12,110,000 per payment, set by the Banco de la República in its Circular Reglamentaria Externa DSP-465 (Asunto 18, numeral 3.2, sheet of March 31, 2026). A supplier that invoices above it needs an ACH Colombia destination, which has no per-payment cap on Lumx, and a Colombian invoice that routinely passes it should not go to a supplier with only a Bre-B key.

Because a destination carries the rail, the same API call on Lumx pays a Pix key, a CLABE or a Bre-B key, and the supplier's statement shows the paying company as sender on Pix and SPEI, not Lumx. The full list of countries and currencies is on the coverage page.

The euro leg: SEPA in, and the cut-off that catches large invoice runs

The company sends euros from its own bank account to its own EUR account, by SEPA transfer to an IBAN. A EUR account turns ACTIVE right after the company's KYB (know your business, the verification of a company and its owners) is approved, with no extra wait for a banking partner review. Lumx targets one business day for KYB, so onboarding is the first thing to start.

SEPA settles around the clock. A payment of €100k or more submitted between 4:30 PM and 2:30 AM UK time goes to SEPA Credit Transfer instead and settles the same or next business day. Lumx picks the scheme itself, so you always send rail: "SEPA". A €250,000 run funded at 6 PM UK on a Friday settles on Monday, while the same run sent at 2 PM settles in the day. The SEPA routing log entry has the rule as published.

On Lumx there are two ways to collect the euros. A standing autoconversion rule gives one IBAN and BIC, and every matching deposit converts to USDC at the market rate, with no per-payment call. Each EUR account holds one active rule at a time, and each deposit has to be worth at least 50 USD. The alternative is a per-payment on-ramp for an exact amount: a deposit that lands after it expires is refunded to the sender on the same rail.

What to collect from each supplier before the first payment

The legal name on the invoice, the tax ID and the account have to describe the same entity. Compare all three against the invoice in the week before payday, when a mismatch is cheaper to fix than on the day.

For a Brazilian supplier, ask for the CNPJ and the Pix key registered to it. For a Mexican supplier, ask for the 18-digit CLABE and the tax ID, and read the CLABE back from a bank letter; our guide to Mexican stablecoin rules covers the payout side. For a Colombian supplier, ask which rail it prefers and whether any invoice will pass COP 12,110,000.

On Lumx, each supplier becomes a destination with holder.relationship set to SUPPLIER and a payment purpose of TRADE_TRANSACTIONS. The destination goes through verification before it can be paid: destinations.under_verification marks the start, and destinations.approved or destinations.final_rejection reports the result. When compliance needs a document, the customer or the account moves to RFI (request for information, a compliance hold that asks for that document) and a webhook says so, instead of a silent delay. For Brazil in detail, see USDC to a Brazilian bank account.

Paying the exact invoice amount, and how much to fund

A locked rate fixes the conversion for 30 seconds, 1 minute or 5 minutes and accepts a target amount, so you ask for the exact figure on the invoice and the quote returns the USDC it costs. The 30-second lock has no fee, and the longer ones carry one. Pass the returned exchangeRateId on the payout. If the lock expires, request a new quote and treat EXCHANGE_RATE_EXPIRED as a re-quote, not as a failure.

Lumx does not deduct a fee from the amount that reaches the supplier on a Pix, SPEI or Bre-B payout. A payout larger than the wallet balance fails with an insufficient-balance error, which is the reason to fund before you quote, not after.

I recommend that a European finance team starts with one supplier per country and a first payment small enough to lose without a meeting. The first payment tests the supplier's details, not the rails: the legal name, the tax ID and the Pix key, CLABE or Bre-B key have to agree with the invoice. I also recommend funding the EUR account for one payment run at a time instead of parking a large euro balance there, because every deposit converts to USDC on arrival and the team then carries a stablecoin balance until the invoices fall due.

What happens when a payment fails or is returned?

Each failure has its own signal. A locked rate that expired is refused before any money moves, and the fix is a new quote. A EUR deposit that arrives after its on-ramp expired goes back to the sender on the same rail. A payout that cannot complete ends in a failed status, reported by the offramp.failed webhook. After a failure, check the transaction state before resending, because a retry with a new idempotency key pays the supplier twice.

On Lumx, EXCHANGE_RATE_EXPIRED asks for a new quote, offramp.failed reports a payout that failed, and a retry that reuses the same Idempotency-Key does not create a second payment. The payout's status comes from GET /transactions/{id}, and the webhook is the trigger to read it.

What MiCA changes for the company paying

Very little for the payer. MiCA (Regulation (EU) 2023/1114) decides who may issue a stablecoin to the public in the EU and who may provide services with it. It reaches the issuer and the provider, not the company that uses a stablecoin to settle an invoice, and the euro leg stays an ordinary SEPA payment. Two checks remain on the company's side: which stablecoin the route uses, and whether the provider handling it is authorised for the service. Apply the second one to every provider on your shortlist, Lumx included. Our guide to MiCA for payment companies walks through both, by article, and your counsel decides how to classify a USDC balance.

Here is Lumx's position, so you can apply that test: the Brazilian side operates under Article 88 of Central Bank Resolution 520/2025, the US side is a FinCEN-registered MSB, and the EUR account is issued by a banking partner that holds the funds and runs SEPA, while Lumx runs KYB, custody and the conversion. Both USDC and USDT are available; the USDC explainer covers the one this route uses.

A euro bank wire against this route, leg by leg

The Federal Reserve's FEDS Note of March 30, 2026 puts numbers on it: more than 50 percent of international payments are in US dollars, according to SWIFT data, and over 60 percent of wholesale payments pass through one or more intermediaries. The same note says commonly traded pairs have shorter chains and less common pairs may need a broad network of correspondent banks, so a EUR to BRL wire may include a dollar leg that the sending bank does not show you.

A euro bank wire and the stablecoin route, compared on the points a payments team checks

The dollar case is in stablecoins versus SWIFT for B2B payments. For a euro payer, Lumx takes SEPA in, holds USDC, and pays Pix, SPEI or Bre-B out, so the speed gain comes from the local rail on the last leg. Lumx's SWIFT runs in USD only and is not part of this route.

When a stablecoin route is the wrong tool for a supplier payment

When the invoices are rare. A monthly platform fee does not pay back on one supplier invoice a quarter, and a bank wire is the sensible choice.

When the supplier sits outside Brazil, Mexico and Colombia. Check the coverage page before promising a corridor. For Asia, our guide to paying suppliers in China is the closer model.

When your group's policy requires the euro leg to sit with a provider that holds its own EU authorisation for crypto-asset services. Compare providers on that point first, starting from the positions in the MiCA section above; our Lumx and BVNK comparison shows how each one handles it.

When the money is not the paying company's. Paying another entity's suppliers through your account is nesting, which Lumx does not allow.

What a euro invoice paid in reais 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.

Take a German company with a São Paulo supplier. It requests a EUR account and receives an IBAN and a BIC for a named virtual account (a local account number issued in the customer's own name), then pays that IBAN from its own bank. The deposit converts to USDC, the supplier is registered as a SUPPLIER destination, and a locked quote for the invoice amount in reais goes to the off-ramp. The supplier receives a Pix transfer under the German company's name, and the company follows offramp.transferring_stablecoin, offramp.trading, offramp.transferring_fiat and offramp.success.

The cost is the same shape for every payment: a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. The FX shows up as a quoted amount before you commit, and the fees appear on the receipt of each transaction. The conversions are the part to compare between providers, and our guide to how payout pricing works shows how to read them.

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

Cover photo: Mikhail Mamaev on Unsplash.