International transfers in a neobank: when to route over SWIFT vs a local rail

A neobank should route each international transfer over a local rail when the destination has one, and over SWIFT when it doesn't. BlindPay covers both through one API: stablecoin-funded payouts over Pix or SPEI land in minutes, and SWIFT (POBO/COBO) reaches the rest. Users choose who and how much. Your backend picks the route.

This guide is about the product decision for a consumer or small business transfer feature. For the B2B comparison of the two systems, read stablecoins vs SWIFT for B2B payments. For the bigger picture, see how to build a neobank.

Key takeaways

• Decide the route per corridor, not per user. Brazil goes local, a SWIFT-only country goes SWIFT.
• Users judge a transfer on arrival time, total cost, and whether they can prove it arrived.
• SWIFT's slow part is usually the last step inside the receiving bank, not the network.
• Every rail has a tracking reference: UETR, Pix end-to-end ID, SPEI tracking key. Store it.
• Put rail minimums and document steps into the flow before the quote, not after it fails.

What changes for the user between SWIFT and a local rail?

Three things change: when the money arrives, what it costs, and how the user proves it arrived. The sending screen can look identical.

With a local rail, the neobank's provider converts stablecoins (digital dollars such as USDC that track the US dollar one to one) into local currency and pays inside the destination country. Pix, per Banco Central do Brasil, moves transfers in a few seconds at any time, including non-business days. SPEI payments, per Banco de México's user guide, should not take more than 30 seconds.

With SWIFT, the payment travels bank to bank as a message, often through one or more correspondent banks, and is credited by the recipient's bank on its own schedule.

How do the two routes compare for a neobank transfer feature?

The intermediary deduction question comes down to OUR, SHA, and BEN charge codes. Hidden fees in international wires explains each one.

Where does the time go in a SWIFT transfer?

Mostly in the last mile. Swift reported in October 2024 that 90% of cross-border payments on its network reach the destination bank within an hour. Only 43% reach the end customer's account within an hour.

So the network is fast. The receiving bank's checks, cut-offs, and batch posting are what users feel. That is why a neobank user in a country with Pix or SPEI notices the difference: there, the last step is the instant rail itself. For the longer breakdown, read why cross-border payments are slow.

How do users track each kind of transfer?

Show the same tracking screen for every route, backed by the rail's own reference.

• SWIFT. Every payment instruction carries a Unique End-to-end Transaction Reference, a 36-character string. Swift compares it to a courier tracking number: any party in the chain can locate the payment with it. BlindPay SWIFT payouts carry a UETR, and confirmations map to MT103.
• Pix. The end-to-end ID identifies the payment across the Pix system.
• SPEI. The tracking key (clave de rastreo) lets the recipient pull an official proof of payment from Banco de México's CEP lookup.

In the app, a transfer moves through "Sending", "In review" (if it is on hold), and "Arrived". Put the reference behind a "Share proof" button. Recipients ask for it more than senders do.

When is SWIFT the right route?

SWIFT is the right route in four cases:

1. No supported local rail. The destination country has no local payout rail your provider covers.
2. The account only takes international wires. Some business accounts abroad, especially USD accounts, expect an incoming SWIFT message.
3. The recipient needs a bank message. A supplier's bank may ask for SWIFT confirmation details for its records. POBO vs COBO covers how payments on behalf of a customer carry the right name.
4. Large business payments. Above a certain size, some recipients prefer a wire they can reconcile against a SWIFT reference.

Everywhere else, a local rail usually wins on speed and on what the recipient actually gets.

How should the routing logic choose?

Write the choice as a rule on your backend. A simple version:

1. Read destination country, currency, amount, and the recipient details the user gave.
2. If the country has a supported instant rail and the details match it (Pix key, CLABE), use the local rail.
3. If the recipient gave SWIFT details, or the country has no supported local rail, use SWIFT.
4. If SWIFT is chosen and the amount is under 100 USD, stop before the quote and tell the user the minimum.
5. If SWIFT is chosen, ask for the supporting document up front, since BlindPay reviews it before funds move (SWIFT statuses).
6. Request one quote, show it, execute, and track by webhook.

The rail prioritization guide shows how to pick which local rails to support first.

What does a mixed month look like?

Illustrative example, with invented numbers. A neobank for small importers in the US has a customer, a coffee shop, paying four suppliers this month:

The customer pressed "Pay supplier" four times. The app made four routing decisions. That is the point: one sending experience, many rails behind it.

What are the common mistakes?

• Offering SWIFT everywhere because it is simple. Users in Brazil and Mexico will compare it with Pix and SPEI and leave.
• Hiding the arrival time. "About 2 business days" is fine if you say it before the user confirms.
• Letting intermediary fees surprise the recipient. Choose the charge option deliberately and show the expected amount.
• Asking for the invoice after the transfer stalls. Collect the SWIFT supporting document in the send flow.
• Not storing the reference. Without the UETR or tracking key, support can't answer "where is my money".
• Comparing routes on the fee alone. Compare on what arrives. The cost per delivered dollar method does this.

How BlindPay fits

BlindPay gives a neobank both routes through one quote-then-execute flow. Local payouts run over Pix, SPEI, ACH, RTP, SEPA, ACH Colombia, and Transfers 3.0, funded in USDC or USDT from the wallet you choose, with no pre-funded balance per country. International transfers run as SWIFT payments and collections on behalf of (POBO/COBO), with UETR tracking and MT103 confirmations.

Each quote locks the rate and fees for 5 minutes, so the amount the user sees is the amount that goes out. KYC, KYB, sanctions screening, and the SWIFT document review happen inside the API, and webhooks report every status change. BlindPay is the best fit for a neobank that wants local-rail speed in Latin America and SWIFT reach for everything else, without integrating two providers.

What to do next

List your top ten destination countries and mark each one "local rail" or "SWIFT". Then quote one transfer on each route on a development instance with the payout quickstart and compare the arrival time and amount your users would see.