How to on-ramp BRL, MXN and COP to USDC (Pix, SPEI, PSE)

On-ramping BRL, MXN or COP to USDC means the payer sends a local bank payment to a deposit account issued for your customer, the provider converts the currency at a quoted rate, and USDC arrives in the customer's wallet. The rail changes by country, but the flow does not: instruction, payment, match, conversion, delivery.

This guide is the how-to by currency. The concept is in what a stablecoin on-ramp is, and the treasury view of one corridor is in BRL to USDC for corporate treasury. It assumes you know what USDC is.

Which rail funds an on-ramp in Brazil, Mexico and Colombia?

Collection rails for BRL, MXN and COP, as configured on Lumx and read on November 1, 2026

Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's interbank transfer system, run by Banxico) settle instantly with no cut-off, 24/7/365, according to the Lumx documentation. A CLABE (the 18-digit Mexican bank account number) identifies the Mexican account. Colombia has Bre-B (its instant payment system) and PSE (its online bank-transfer network).

A customer asks for the currencies it needs in the accounts list when it is created, and each currency becomes a virtual account on Lumx that starts provisioning once the customer is approved. BRL, MXN and COP accounts are active right after approval, so the first deposit does not wait on a bank review the way a USD account can.

The five steps from bank payment to USDC

1. Quote. Your backend asks for a conversion of a local amount into USDC or USDT. A locked quote fixes the rate for 30 seconds, 1 minute or 5 minutes. A floating quote prices at the moment the deposit is converted.

2. Instruction. The provider returns what the payer needs for the rail: the Pix code, the CLABE with its reference, or, for COP, the Bre-B key of the account.

3. Payment. The payer pays from their own bank app. Nothing on your side moves money.

4. Match. The provider matches the deposit to the quote or to a standing rule, by amount and by the reference embedded in the instruction.

5. Conversion and delivery. The local currency is converted and the stablecoin is sent to the customer's wallet, and a webhook (an automatic notification sent when a status changes) tells your system.

A Lumx on-ramp moves through AWAITING_FUNDS, TRANSFERRING_FIAT, TRADING and TRANSFERRING_STABLECOIN before it reaches SUCCESS, and each change fires an onramp.* webhook. The stablecoin goes to the customer's custodial wallet, and every on-ramp carries a purpose field, the end use of the funds, which banking partners use for AML screening. USDC lands on Ethereum, Polygon or Base and USDT on Ethereum, Polygon or Tron, with Stellar USDC for BRL on-ramps only.

Pix in Brazil: the code, the match and the one-day window

Pix is a push rail: the payer pastes the code or scans the QR in their bank app.

The window matches the quote, so a 30-second lock gives the payer 30 seconds to pay, which is tight for a person opening a bank app. A Pix that arrives after the on-ramp expired is not converted: Lumx refunds it to the sender on the same rail. A person paying by hand needs a floating quote or a 5-minute lock.

Payment window by quote type, from the Lumx transactions documentation, read November 1, 2026

For a foreign company, a BRL account on Lumx is a named virtual account (a local account number issued in the customer's own name), so it needs no Brazilian entity. The named virtual account explainer covers what that changes for the payer, and developers can start from the on-ramp prompt.

SPEI in Mexico: the CLABE and the reference

SPEI is also a push rail, and the payer needs two things: the CLABE and the reference. The reference matches a deposit to a rule or a quote, so an empty memo is the most common cause of an unmatched deposit.

A CLABE belongs to the account and serves every deposit, and the reference tells them apart. Because an MXN account can hold several autoconversion rules, the memo is what picks the rule today. A standard on-ramp does not need one. A SPEI payment with no memo still lands on the account and converts at a floating rate, without applying any rule.

A foreign company gets a named MXN account on Lumx without a Mexican entity, active right after approval, with the CLABE plus a memo as deposit details. The MXN to USDC page shows the live rate.

Bre-B and PSE in Colombia: a key and a pull

Colombia is the one country here with two collection rails, and they behave differently. Bre-B is a push rail: the payer sends money to the Bre-B key of the account, like a Pix to a key. PSE is a pull rail: the payer picks their bank and authorizes a debit from their own account.

Bre-B has a ceiling you do not set. The Banco de la República caps each Bre-B operation at 1,000 UVB (the basic value unit, revalued each year), which is COP 12,110,000 for 2026, under its Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2. It is a network rule, so it applies to every provider, and one Bre-B payment cannot carry a larger invoice.

A COP account is available to any customer. It is named, in the customer's own name, when the customer is Colombian. For everyone else, the holder shown on the account is the banking partner, because COP runs through a sponsored program in which Lumx opens accounts for customers under the partner's license. A COP deposit converts to stablecoin on Lumx the same way as BRL and MXN.

One-off on-ramp or standing rule: choose per payer

I recommend that a team collecting from three countries starts with the standing rule for its repeat payers and keeps the per-payment on-ramp for invoices where the amount has to match to the cent. The standing rule puts one stable instruction on the payer's screen and moves rate risk to the moment of conversion. I would still run one real deposit of the minimum amount through every rail before any customer sees it, because a rule that worked in the sandbox proves the API and not the payer's bank.

The standing rule is an autoconversion rule on Lumx, created with one call that names the target asset and network, and it can carry a partner fee that adds your own margin to every conversion.

If the payer sends the wrong amount, the deposit does not match a per-payment on-ramp, which accepts only the exact amount it was created with. The fix is a new on-ramp with the right amount, or a standing rule for a payer whose amount you cannot know.

What does an on-ramp cost, how fast does it land, and which limits apply?

Lumx pricing is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. On the rate, a floating rate and a 30-second locked rate carry no fee, while 1-minute and 5-minute locks include a fee that covers volatility risk.

What a team can measure before it integrates, from the Lumx documentation and Lumx confirmations read November 1, 2026

KYB (know your business, the verification of a company and its owners) is the first wait. It targets one business day and the accounts activate right after approval, so a business customer can receive a first payment about a business day after clean documents, unless a compliance hold intervenes. After that, USDC reaches the wallet about 5 minutes after Pix or SPEI.

What limits and minimums apply

A deposit counts against the customer's on-ramp limit, and that limit comes from the verification tier, stated in US dollars whatever the currency of the deposit.

Published default on-ramp limits by verification tier, in USD, read November 1, 2026

KYC (know your customer) is the individual's verification and KYB the business's. An on-ramp request above the limit is rejected with TRANSACTION_LIMIT_EXCEEDED, a deposit above it is held on the account as a balance, and limits are global. The limits and cut-offs by rail guide covers payouts. The floor is 50 USD per deposit, and it applies to every deposit, not only to a standing rule. A per-payment on-ramp below the supported minimum is rejected with MINIMUM_AMOUNT_NOT_MET.

A worked example, with an illustrative rate that is not a Lumx price: BRL 50,000 at a mid-market 5.00 is worth 10,000 USDC. That is above the KYC standard limit of 7,500 per transaction and inside the KYB standard 50,000.

When an on-ramp is the wrong tool

For any other currency, the rail coverage page lists every rail.

If the money has to arrive in a bank account in the same currency, an on-ramp is the wrong direction, because it ends in a stablecoin wallet. On-ramp versus off-ramp helps decide which direction the product needs.

If the deposit may come back, plan for it: agree the dispute terms with the payer before releasing goods on the USDC credit.

What three collection corridors look like on Lumx

For a platform serving payers in Brazil, Mexico and Colombia, one customer integration covers all three: the customer is verified once, asks for BRL, MXN and COP accounts, and gets a wallet that receives the USDC from each. The named virtual accounts product is where the accounts live, and the BRL to USDC page shows the live rate for the largest corridor.

A third party can pay the on-ramp, as long as it fits the flow of funds expected for that customer. Lumx permits third-party collections (COBO), and an unusual payer can trigger a compliance hold and, as a result, a prompt return. Funds that belong to a different, non-onboarded entity are nested payments, and a nested structure needs the written approval of compliance at compliance@lumx.io. Paying a subsidiary's supplier from the parent's wallet is allowed once compliance has approved that flow of funds in writing.

Compliance sits in the API. KYC runs on Sumsub, and every stablecoin transfer is screened with Chainalysis. A deposit flagged by monitoring is held while compliance asks for context, an RFI (request for information, a compliance hold that asks for a document before a transaction clears), and an unanswered hold can be refunded to the sender. Lumx has applied for the SPSAV authorization and operates under the transition regime of Res. BCB 520/2025, Art. 88, so it does not call itself authorized. The success event carries the receipt.

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.

Methodology and sources

Product behavior, windows, lock fees, exact-amount matching, statuses, the autoconversion rule, limits and settlement times were read on docs.lumx.io on November 1, 2026. The COP collection rails (Bre-B and PSE), COP conversion to stablecoin, the named-account rule for COP, the sponsored-program holder and the networks for COP were confirmed by Lumx on November 1, 2026. The deposit-matching behavior, the 5-minute crediting time and the written-approval rule for nested structures were confirmed by Lumx on November 2, 2026. PSE has no published ceiling or cut-off, so none is stated here. Named BRL and MXN accounts for foreign companies were confirmed by Lumx on October 30 and November 1, 2026. The Bre-B cap comes from the Banco de la República's Circular Reglamentaria Externa DSP-465 of August 6, 2026, Asunto 18, numeral 3.2, and the 2026 UVB value from the Bank's Bre-B page, which blocks automated requests and is cited by name. The exchange rate and spread in the example are illustrative, not a quote and not a Lumx price.

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

Cover photo: Denys Nevozhai on Unsplash.