Sending USDC to a bank account in Colombia means selling the dollars for pesos and delivering them to the recipient's bank account over one of two Colombian rails: a bank transfer over ACH Colombia (the interbank clearing house for peso transfers), which pays to account details, or Bre-B (the Banco de la República's instant payment system, launched in 2025), which pays to a registered key. The blockchain moves the value to a provider, the provider converts it on the USDC to COP corridor, and a Colombian rail credits the account. To the sender it looks like one payment. The failures that cost money sit on the Colombian side: details that do not match the account, a quote that expired, or a Bre-B amount above the network's own cap.
This guide assumes you know what USDC is. The conversion leg is in the off-ramp explainer, and the Brazil version is sending USDC to Brazil.
What do you need before the first payment to Colombia?
A verified sender. The company paying runs through KYB (know your business, the verification of a company and its owners) once, and an individual runs through KYC (know your customer, the verification of an individual). The wallet stays disabled until approval, so start here. A customer based in Colombia goes through enhanced due diligence, so plan a longer verification window.
The recipient's details for the rail you pick. The rail is chosen when you register the recipient, and each rail asks for different data, so decide first and collect in writing rather than copying from an old invoice.
Rail | What the destination needs | Fits |
Bre-B | The recipient's Bre-B key, such as a phone number, an email or an identity document | Payments up to the Bre-B cap, credited instantly |
ACH Colombia | Name as the bank holds it, document type (CC, CE, NIT, PASS or PEP) and number, email, bank, account number and account type (savings or checking) | Payments to bank account details, including amounts above the Bre-B cap |
Bre-B keys are described in Blu Radio's report; ask the recipient which key they want to be paid on.
The recipient's legal name and tax ID. For a company, the legal name as the bank registered it, which can differ from the brand name on its website, plus its NIT (Colombia's company taxpayer ID). For an individual, the full name and the identity document the bank holds on file, usually the cédula de ciudadanía. The tax ID is a required field on the destination, so it cannot be skipped to save time.
The relationship between payer and recipient. Your own entity, a supplier, an employee and a contractor are different relationships, and the destination records the relationship to the customer. A destination marked as the customer's own is refused if the holder's tax ID differs from the customer's.
USDC or USDT on a network the corridor accepts. A COP payout can be funded with USDC on Ethereum, Polygon or Base, or with USDT on Ethereum, Polygon or Tron. Confirm the network before the first transfer instead of assuming the one you already hold on is the right one.
How the pesos reach the account
You do not run either rail yourself. On Lumx you register a COP destination with the rail already chosen, Bre-B with a key or ACH Colombia with bank account details, and every payout to that destination goes out on that rail. Lumx does not switch rails for you, so the choice you make at registration decides what a payout can carry.
Bre-B is the system the Banco de la República built for instant transfers between accounts and registered keys, and it carries a per-operation cap, described below. An ACH Colombia transfer pays to the account details themselves and has no such cap. Lumx publishes no cut-off table for COP, so test the timing with a small first payment and do not plan around a number nobody has published.
The steps, from USDC balance to pesos in the account
1. Register the recipient as a destination. Create a destination for the customer with the COP currency, the rail (Bre-B or ACH Colombia), the recipient's key or account details and the holder block. Type, name (legal name for a company, full name for an individual) and tax ID are required. The relationship is optional but worth setting, because compliance reads it. Run the destination, the quote and the off-ramp in the sandbox (api-sandbox.lumx.io) first, where the corridor is enabled, so the first real payout is not the first time the flow runs. The destination goes through verification before it can receive a payout, so do not submit the off-ramp until it is approved. Lumx tells your system by webhook (an automatic notification sent when a status changes): destinations.approved means go, destinations.under_verification means in progress, and destinations.final_rejection means permanently rejected.
2. Fund the wallet. Every approved customer has a wallet on each supported network. Send USDC to the wallet address on a network the corridor accepts, or on-ramp into it. One funding transfer can cover many payouts.
3. Check the room under the limit. Read the customer's remaining daily and monthly off-ramp limit and compare the amount with it. If the destination is on Bre-B, compare the amount in pesos with the Bre-B cap in the next section. The published Lumx limits are further down.
4. Quote. A floating rate is a live reference with no lock, fine for an estimate. A locked rate fixes the conversion for 30 seconds, 1 minute or 5 minutes, and only the 30-second lock carries no fee.
5. Submit the off-ramp. The request carries the destination, the USDC amount (or the locked rate), a purpose and an optional memo. PERSONAL_ACCOUNT is allowed only to a destination marked as the customer's own; a supplier invoice or a contractor fee uses a commercial purpose.
6. Follow the status. An off-ramp moves from the stablecoin transfer to the trade to the fiat transfer and then to success, and each change fires a webhook, with a separate event if it fails. Send a unique key with each request, so a retry cannot pay twice.
7. Keep the reference. Store the transaction id and the receipt returned on the transaction (it carries the blockchain transaction hash) next to your payout record. If a recipient says the money is missing, the transaction id is what you give support, and the recipient's bank can trace the credit on its side.
Webhook status | What it means | What to do |
| USDC is moving to the provider | Wait |
| USDC is being converted to COP | Wait |
| Pesos are being sent to the bank | Keep the transaction id |
| Funds left the banking partner | Mark sent; confirm credit with the recipient |
| The payout did not complete | Read the error code, fix the data, resubmit |
What the Bre-B cap means for the size of a payout
The Banco de la República sets a cap on each Bre-B operation of 1,000 UVB (the basic value unit, revalued each year), in its rules for interoperable immediate low-value payment systems. Blu Radio, reporting on April 8, 2026, put the 2026 cap at COP 12,110,000 per operation. Other coverage, such as Portafolio, quotes a rounder figure of COP 11 million, which looks like an older value: the cap moves with the UVB every year, so confirm the current value on the Banco de la República's Bre-B page before you build a limit into your payout run. This is a network limit: it applies to every provider.
The cap matters more than it looks, because it is small next to a business payout. With illustrative USD to COP at 4,000, the cap is about 3,028 USD, while the Lumx per-transaction limit for a standard KYB customer is 50,000 USD, so on Bre-B the network cap binds first.
A payout of COP 30,000,000 to a Bre-B destination is above the cap, and Lumx rejects it rather than splitting it or moving it to another rail. The answer is to register that recipient on ACH Colombia, with their bank account details, and pay the full amount in one operation. Splitting one payment into several Bre-B transfers to stay under the cap is the pattern transaction monitoring looks for, so do not build a payout run around it. Confirm the current cap, because Portafolio has reported a consultation on going beyond 1,000 UVB for larger segments.
What it costs and what limits apply
Three costs make up a peso payout, and the spread is the one most easily missed.
The network fee applies to any transfer you make to fund the wallet. The conversion spread between the quoted rate and the mid-market USD to COP rate is the real price. The platform and per-transaction fees are the third: a monthly platform fee plus usage-based fees, with no pre-funding. No plans are published, so we quote no number.
To compute the spread, use illustrative figures. Sending 10,000 USDC when mid-market USD to COP is 4,000 means 40,000,000 pesos at mid. A quoted rate of 3,980 delivers 39,800,000 pesos, so the spread is (4,000 - 3,980) / 4,000 = 0.5 percent, or 50 basis points, and the shortfall is 200,000 pesos. That shortfall is the number to ask every provider for on a locked quote. The per-transaction fee comes with the contract, and the network fee is a separate line on top. The mechanics are in how stablecoin payout pricing works.
A limit belongs to the customer and it is stated in US dollars against the verification tier. See limits and cut-offs by rail. These are the published defaults for a peso payout, which uses the off-ramp limit.
Published default transaction limits by verification tier, in USD, read October 29, 2026
Limit | KYC standard | KYC enhanced | KYB standard | KYB enhanced |
Per transaction | 7,500 | 25,000 and above | 50,000 | 50,000 and above |
Daily | 15,000 | 50,000 and above | 100,000 | 100,000 and above |
Monthly | 15,000 | 50,000 and above | 100,000 | 100,000 and above |
On standard KYB the monthly cap equals the daily one, 100,000 dollars, so one heavy day uses the whole month. A payment above its limit is rejected (TRANSACTION_LIMIT_EXCEEDED). A higher limit comes from enhanced verification and a documented request, which the documentation targets at one business day.
The API enforces a minimum amount per currency and returns MINIMUM_AMOUNT_NOT_MET, so handle that code when you design the flow.
Why do payments to Colombia fail or come back?
The tax ID does not match. A destination the customer marks as its own is refused when the holder's tax ID differs from the customer's (HOLDER_TAX_ID_MISMATCH) or the holder type differs (HOLDER_TYPE_MISMATCH), and a tax ID the bank rejects comes back as INVALID_TAX_ID. All three are data problems, and all three are fixed at the destination.
The destination is not valid. The payment destination was refused (INVALID_PAYMENT_DESTINATION). Check every field against what the recipient sent you.
The account is valid and belongs to someone else. No check on the sending side catches this, and what happens next depends on the receiving bank and the holder, so take it to your own bank and counsel.
The amount is over the Bre-B cap. A payout to a Bre-B destination above the cap is rejected. Register the recipient on ACH Colombia and send the full amount there, as the previous section describes.
The amount is over the customer's limit. The payout is rejected (TRANSACTION_LIMIT_EXCEEDED). Check the remaining daily and monthly limit before submitting.
The quote expired. A locked rate that lapses is rejected (EXCHANGE_RATE_EXPIRED), and so is one already used (EXCHANGE_RATE_ALREADY_USED). Quote right before you submit.
The wrong network on the send leg. USDC sent on a network the corridor does not credit is painful to undo. Confirm the network before the first transfer.
I recommend sending the first payment to any new Colombian recipient as a small test, and releasing the full amount only after the recipient confirms it arrived. It costs one extra payment and a short wait, and it covers what no validation can: whether the account belongs to the person you meant to pay.
A compliance hold. Transactions flagged by monitoring are held while compliance asks for context, usually the relationship between sender and receiver, the purpose and the expected outcome, an RFI (request for information). Compliance reaches out by email or Slack, and an unanswered hold may be refunded to the sender, so answer within 24 hours. It is a pause, not a rejection. The guide to why payouts get rejected has the full list.
When sending USDC to Colombia is the wrong tool
When the payment may need to be recalled. The blockchain leg is final, and once a bank credits the account, recovery depends on the receiving bank and the holder. Ask your own bank and counsel before you rely on it.
When a regulator question is the real question. This guide describes the mechanics of a payment. How Colombian law treats the stablecoin leg, including foreign-exchange reporting on inbound transfers, is a separate matter, and your counsel decides what applies to your company.
A Colombian payout 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.
A payout to Colombia on the global payments API is a transaction from the customer's custodial wallet to a COP destination. COP payouts go out over ACH Colombia or Bre-B, chosen per destination, and the rail coverage page lists the rails and currencies. The USDC to COP page shows the live rate for the pair.
Verification happens before money moves, for the customer and for each destination, and each stage emits a webhook. The legs are described in the corridor explainer.
Methodology and sources
Product behavior, the transaction limits, the error codes, the destination fields, the webhook events and the off-ramp lifecycle were read on docs.lumx.io on October 29, 2026, including the OpenAPI specification. The Bre-B cap of 1,000 UVB and its 2026 peso value come from press: Blu Radio's report of April 8, 2026, and the consultation on larger Bre-B operations from Portafolio, both read on October 29, 2026. Portafolio quotes a different, rounder figure for the current maximum. The Banco de la República's own Bre-B page answers automated requests with a bot check, so it was not read and is not linked; confirm the current value there. The COP payout rails (ACH Colombia and Bre-B), the per-rail destination data, the rejection of Bre-B payouts above the cap and the accepted networks were confirmed by Lumx on October 29, 2026, because the public docs do not list them yet. No COP cut-off table is published.
The 4,000 pesos per dollar rate in the examples is illustrative, not a quote.
Verified on October 29, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Ries Bosch on Unsplash.
Can I send USDC straight to a Colombian bank account?
No. A bank holds pesos, not tokens, so a provider sits in the middle to convert the USDC and pay the recipient over a Colombian rail.
What details do I need to pay someone in Colombia?
It depends on the rail. For Bre-B, the recipient's Bre-B key. For ACH Colombia, the name as the bank holds it, the document type and number (a NIT for a company), an email, the bank, the account number and the account type. Either way the destination records whether the holder is a business or an individual, and how they relate to the sender.
Is there a limit on a Bre-B payment?
Yes. The Banco de la República sets a cap of 1,000 UVB per Bre-B operation, which press reported as about COP 12.1 million in 2026. A Bre-B payout above it is rejected, so larger amounts go over ACH Colombia. Confirm the current value with the Banco de la República.
Can I send USDT instead of USDC to Colombia?
Yes. A COP payout accepts USDT on Ethereum, Polygon or Tron, as well as USDC on Ethereum, Polygon or Base.
