SWIFT or Local Rails for Neobank Transfers to Latin America

The right route for a neobank transfer to Latin America is the destination's local rail, such as Pix (Brazil's instant payment system, run by the Central Bank) or SPEI (Mexico's interbank transfer system, run by Banxico). SWIFT fits recipients needing USD wires or lacking a local rail. Local rails settle in seconds, SWIFT in 1 to 5 business days.

The route is a corridor decision, not a customer decision

A neobank user presses Send with two inputs: who gets the money and how much. The rail, the cut-off and any fee off the principal are the backend's problem.

Rails are national: Pix only delivers inside Brazil and SPEI only inside Mexico, while a SWIFT wire reaches almost anywhere. So the decision belongs to the corridor, which we cover in what a stablecoin corridor is. The treasury version is stablecoins vs SWIFT for B2B payments.

The persona here is a US or European neobank paying Latin American recipients, with customers who fund their wallet by ACH, FEDWIRE, SWIFT, SEPA or Faster Payments.

On Lumx, the transfer is an off-ramp from the sender's stablecoin wallet to a destination registered for the recipient. The destination carries the rail, so the corridor decision is made once, when the recipient is added.

Should a neobank use SWIFT or a local rail for each corridor?

For every corridor where a local rail exists, use it, and keep SWIFT as the fallback. The table lists what each corridor looks like on Lumx today. The first three rows are the Latin American destinations. The last three are funding corridors, which describe how the sender gets money into the wallet.

Route by corridor, with the case for SWIFT (Lumx rails, as of November 2026)

Settlement is a processing target, not a promise: the receiving bank can hold funds for its own review, and an RFI (request for information, a compliance hold that asks for context before a transaction clears) stops a payment until it is answered. "Seconds" describes the rail, not the whole journey: a transfer funded from a USD balance is converted first.

What does the recipient see on each route?

Three things differ for the person receiving the money: how much arrives, whose name is on the credit, and what they can show their bank.

On a local rail, the amount that arrives is the amount in the quote. On SWIFT, intermediary banks can take their own fee on the way, so the amount can be lower than the amount sent. Our documentation says so for the USD wire leg; the charge codes are in wire fee charge options.

On the name, the recipient's statement shows the customer's registered legal name on SPEI, ACH, FEDWIRE, SEPA, Faster Payments and SWIFT, per the sender-of-record page. A transfer to a Brazilian recipient over Pix shows the neobank's customer as the payer too, because BRL accounts on Lumx are now named. On COP the leg runs under a banking partner's program, so for a customer who is not Colombian the recipient sees the banking partner's name. A recipient who does not recognise the payer will question the credit.

On proof, every route leaves a bank statement line. Banxico says an SPEI payment should not take more than 30 seconds after approval, and the sender's bank issues a payment ID, the search code, to identify it later.

A locked rate holds for 30 seconds at no fee, or for 1 or 5 minutes with a fee that covers volatility. Lumx takes no fee from the amount that reaches the recipient on a Pix, SPEI or Bre-B (Colombia's instant payment system, instant like Pix) payout. Only the recipient's own bank can charge them.

The cost has layers. Lumx's pricing is a platform fee plus usage-based per-transaction fees, and the neobank sets its own partner fee on top, as a rate in basis points, a flat dollar amount, or both. A locked quote returns the base amount and the final amount after fees. The gap between the two is the Lumx fee, the partner fee and any lock fee, with no FX margin built into the rate, so the user sees what the recipient gets before confirming. SEPA carries a flat Lumx fee, as every rail does. SWIFT adds a variable layer: the customer cannot choose OUR, SHA or BEN, Lumx takes its wire fee from the sender, and correspondent banks can still deduct fees outside Lumx's control, which no quote can fix in advance.

Where the time goes: cut-offs and limits

Pix, SPEI and Faster Payments have no cut-off and run 24/7/365. SEPA is real-time all days, and ACH (2:00 PM ET), FEDWIRE and SWIFT (3:00 PM ET) follow US business days. SWIFT also depends on intermediary bank hours.

A SWIFT transfer submitted after 3:00 PM ET goes out the next business day. The same transfer to a Pix key goes out at once, even at 4:00 AM on a Sunday. The per-rail detail is in payout limits and cut-offs by rail.

Limits are the second constraint, and they come from two places. Individuals are verified through KYC (know your customer, the verification of an individual) and companies through KYB (know your business, the verification of a company and its owners).

• The customer's verification tier sets the ceiling on any rail, in US dollars. A standard individual has 7,500 per transaction and 15,000 per day and per month. A standard business has 50,000 per transaction and 100,000 per day and per month. These limits are global.

• Bre-B has its own regulatory cap of 1,000 UVB per transaction, about 12.1 million pesos or 2,870 dollars in 2026, under Circular Reglamentaria Externa DSP-465 of the Banco de la República. It applies to every provider.

A Lumx payout to a Bre-B destination above the cap is refused, never split or sent down another rail, because the rail is fixed to the destination. ACH Colombia has no per-payment limit, so a neobank expecting larger Colombian transfers registers an ACH Colombia destination for that recipient.

How do users track each kind of transfer?

Show one tracking screen for every route, backed by the rail's own reference. On SWIFT, the reference is the UETR (unique end-to-end transaction reference) that travels with the payment, and the bank confirmation is an MT103. On a local rail, it is the reference the rail issues, such as the SPEI search code.

On Lumx, every SWIFT payout carries UETR and MT103 confirmations, and every transfer carries a per-rail reference. An off-ramp moves from stablecoin transfer to trading, to fiat transfer, to success, and each change fires an off-ramp webhook, so the neobank updates the user without polling. A transfer flagged by transaction monitoring is held as an RFI. Compliance contacts the partner on the usual channel, email or Slack, and asks for the relationship between sender and receiver, the purpose and any context. The API flow for transaction RFIs is not available yet, so the neobank's ops runbook should name who answers those messages, and answer within 24 hours, because the transfer may be refunded if there is no reply.

The routing rule a neobank backend can run

Write the choice as a rule on the backend, evaluated when the recipient is added, not when the money is sent.

1. Read the destination country, currency and the details the user entered.

2. If a local rail exists for that currency and the details fit it (a Pix key, a CLABE, a Bre-B key, an IBAN), register the destination on that rail.

3. If the recipient gave BIC and account details for a USD account abroad, or no local rail exists, register a SWIFT destination.

4. Set the holder relationship on every destination, from the closed list in the API. This is a compliance field, so it comes from the neobank's own records of who the recipient is to the sender.

5. Before each payment, read the customer's remaining limits and apply the Bre-B cap, and stop with a clear message.

6. Quote with a locked rate, show the amount the recipient gets, and send with an idempotency key stored against the neobank's own payment reference, so a retry cannot pay twice.

7. Confirm with a transaction read before telling the user it arrived, and keep SWIFT available as the fallback until one full cycle has reconciled.

Lumx covers each step in its API: destinations, locked quotes, idempotency keys, transaction reads and webhooks. The prompt for migrating SWIFT wires to local rails builds the corridor table for a team moving off wires, and the SWIFT leg is in sending a SWIFT payout from USDC.

Why I would hide the rail from the user

I would keep the rail out of the sending screen and make it a backend rule per corridor. A neobank customer knows who they are paying and how much, and nothing about SEPA, Faster Payments or SWIFT should be their problem. The one place I would show the choice is the SWIFT fallback, with the arrival window and the chance of intermediary deductions in front of the confirm button.

When a local rail is the wrong route

A local rail is the wrong route when the money has to land where the rail cannot reach.

• The recipient wants dollars. A supplier or relative with a USD account abroad expects a USD credit, and converting to a local currency and back adds a spread for nothing.

• There is no local rail for the destination. For countries outside the rails in the table, such as the Asia-Pacific markets on the coverage page, USD by SWIFT is the route, or a stablecoin sent to the recipient's wallet.

• The recipient's bank asks for the wire message. A business that files a SWIFT confirmation is asking for an MT103, which only the SWIFT route produces.

The opposite holds too: a SWIFT wire to a recipient with a Pix key or a CLABE (a Mexican bank account number) takes days and can lose a slice to the chain.

What this looks like on a neobank transfer with 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.

For a neobank, the sender is a customer, verified once through KYC, and the money sits in that customer's custodial wallet. A US user funds it with ACH or FEDWIRE into a USD account, and an autoconversion rule turns each deposit into USDC or USDT at market rate. The transfer is an off-ramp from the wallet to a destination: Pix in Brazil, SPEI in Mexico, Bre-B or ACH Colombia in Colombia, SEPA for euros, Faster Payments for pounds, and SWIFT in USD for the rest. Lumx handles compliance and conversion inside the API: KYC or KYB of the customer, verification of each destination, and conversion from stablecoin to local currency.

The Lumx pricing model is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. The neobank can add its own partner fee on top. The pieces price together as described in how stablecoin payout pricing works, and the payout leg is explained in what a stablecoin off-ramp is. Rails per country are on global payments, the regional picture is in cross-border payments in Latin America, and the operator map shows who does what in a payout chain.

Methodology and sources

Rails, settlement times, cut-offs, sender of record, limits, destinations, rates, the transaction lifecycle and webhooks come from the Lumx documentation (coverage, cut-off times, sender of record, limits, destinations, exchange rates, transactions, the remittances use case and webhooks), read on November 1, 2026. BRL accounts are named, so the recipient sees the customer's name on Pix. UETR and MT103 on SWIFT payouts, the pricing model and the absence of a deduction on Pix, SPEI and Bre-B payouts are confirmed by Lumx.

The SPEI 30-second rule and the payment ID are from Banco de México's interbank electronic payments page, read on November 1, 2026, which cites Notice 17/2010, no. 3.3. The Bre-B cap is Circular Reglamentaria Externa DSP-465 of the Banco de la República, Asunto 18, numeral 3.2, sheet of March 31, 2026 (compendium updated August 6, 2026), with 1,000 UVB at 12,110,000 pesos for 2026.

SWIFT timing comes from Lumx's published range, not from network statistics. No per-corridor price is given, because the total depends on the neobank's own partner fee and, on a wire, the charge option and the intermediary banks.

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

Cover photo: Jaymon S on Unsplash.