Which payout rails should a neobank launch with? A corridor-first method for 2026

A neobank should launch with the payout rails behind its top two or three destination corridors, chosen from its own user data. For a US app serving Latin America, that is usually Pix, SPEI, and ACH or RTP, with SWIFT as the fallback. BlindPay covers all of them through one API, so each new corridor is a configuration change.

Most teams get this backwards. They read a provider's coverage page, see 100+ countries, and promise users everything on day one. Then support tickets pile up for the three corridors that actually carry the volume. This guide shows how to pick rails corridor by corridor, then how to route each transfer once you have more than one rail. It is part of our series on how to build a neobank.

Key takeaways

• Choose corridors first, rails second. A rail only matters if your users send money where it runs.
• Score each corridor on demand, rail quality, compliance load, and margin. Launch the top two.
• Instant local rails (Pix, SPEI, RTP) beat SWIFT on speed and hours for consumer transfers in their country.
• SWIFT stays in the stack as the fallback for countries without a supported local rail.
• Write the routing rule down before launch: rail order, amount limits, and what happens when a rail fails.

What is a payout rail, and how is it different from a corridor?

A payout rail is the payment system that delivers money into the recipient's bank account. A corridor is the route between a sending country and currency and a receiving one, such as US dollars to Brazilian reais.

One corridor can have several rails. USD to BRL can land over Pix, over TED, or over SWIFT. One rail can also serve many corridors: SEPA covers euro transfers into the whole SEPA zone of 41 countries. The payment corridor explainer goes deeper on why corridor liquidity sets the rate you get.

For a neobank, the useful order of questions is:

1. Where do my users need to send money?
2. Which rail delivers best in each of those places?
3. Which provider reaches those rails through one integration?

How do the main payout rails compare?

Each rail has a home region, an operating schedule, and a job it does best. The table below uses each operator's own description, plus BlindPay's published estimated arrival per rail from its bank accounts docs.

BlindPay also pays out over ACH Colombia (about 1 business day) and Transfers 3.0 in Argentina (instant). The Latin America payout cheat sheet lists the bank details each of these needs.

How do you pick which corridors to launch first?

Score each candidate corridor on four factors, then launch the two highest. It takes an afternoon with a spreadsheet and saves months of building rails nobody uses.

1. Demand. Count where users want to send. Good signals: sign-up country, the home country users enter during KYC, transfer requests in your waitlist survey, and support tickets that ask "can I send to X?"
2. Rail quality. Does the destination have an instant rail with 24/7 hours and a traceable reference? Pix and SPEI score high. A country reachable only by SWIFT scores lower for consumer transfers.
3. Compliance load. Some corridors need more documents, more screening, or extra disclosures. Count the extra steps your onboarding and support teams take on.
4. Margin. Estimate what stays after rail fees and FX. A corridor with heavy demand but thin margin can still lead, if it is your acquisition story.

Give each factor a score from 1 to 5 and weight demand double. Demand is the one you can't build your way out of.

What does the scoring look like in practice?

Illustrative example, with invented numbers. A US-based neobank has 18,000 users on its waitlist. It looks at the destinations they asked for:

Compliance load is scored so that a higher number means less work. The team launches Pix and SPEI first, adds domestic ACH and RTP as the "move money to my own bank" feature, and keeps SWIFT behind a "more countries" option for the long tail.

The numbers are invented. The method isn't. Run it on your own data before you write a line of payout code.

How should a neobank route each transfer?

Write a routing rule your backend applies to every transfer, so rail choice is consistent and testable. Here is a decision tree in text that works for most consumer and small business transfer features:

1. Is the destination a country with an instant local rail you support? Brazil goes to Pix, Mexico to SPEI. If yes, use it.
2. Did the recipient give a Pix key or a CLABE, or only bank and branch details? In Brazil, bank details without a key can go over PIX Safe or TED. Map the details the user has to the rail that accepts them.
3. Is it a USD transfer inside the US? If the receiving routing number is RTP-eligible and the user wants it now, use RTP. Large amounts go by wire. Everything else goes by ACH.
4. Is it a euro transfer into the SEPA zone? Use SEPA.
5. Is the amount below the rail's minimum? SWIFT on BlindPay starts at 100 USD. Block or re-route before the quote, not after.
6. Nothing local fits? Use SWIFT (POBO/COBO), show the longer arrival time, and keep the UETR for tracking.
7. Did the payout fail? Don't retry on a different rail automatically. Show the status, fix the bank details, and requote.

Keep the rule in one function with tests per branch. When you add a corridor, you add a branch.

What do users expect to see for each rail?

Users judge the rail by three things: when the money arrives, what it costs in total, and whether they can prove it arrived.

• Arrival. Show "usually within minutes" for Pix and SPEI, "1 to 2 business days" for ACH, and the longer window for SWIFT. The cut-off and weekend guide explains why bank-day rails slow down on Fridays.
• Total cost. Show the amount the recipient gets in their currency, the fee, and the rate, before the user confirms. The add money and withdraw screen guide covers the quote screen.
• Proof. Store the rail's reference: the Pix end-to-end ID, the SPEI tracking key, the ACH trace, or the SWIFT UETR. Support will need it.

What are the common mistakes when picking payout rails?

• Launching 20 countries at once. Every corridor adds support scripts, compliance reviews, and failure modes. Two corridors done well beat twenty done badly.
• Using SWIFT where a local rail exists. It works, but users in Brazil and Mexico expect money in minutes, not days.
• Ignoring rail minimums. A 50 USD transfer to a SWIFT-only country fails at the quote. Catch it in your UI.
• No fallback plan. If a rail is down or a bank rejects the account, users need a clear status and a next step, not a spinning loader.
• Hardcoding rail choice in the app. Put the routing rule on the backend so you can change it without shipping a new app version.
• Forgetting receive-side details. Each rail needs different recipient data. Collect it in the format the rail expects, from the first screen.

How BlindPay fits

BlindPay is one API for the payout side of a neobank. Your backend creates a customer, adds the recipient's bank account for the rail you picked, requests a quote that locks the rate and fees for 5 minutes, and executes the payout. The same flow serves Pix, SPEI, ACH, Wire, RTP, SEPA, ACH Colombia, Transfers 3.0, and SWIFT (POBO/COBO). Adding a corridor means adding a branch to your routing rule, not signing a new bank partner.

Payouts are funded in stablecoins (USDC or USDT) from the wallet you choose, so there is no pre-funded balance per country to manage. BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets. KYC, KYB, and sanctions screening run inside the API, and webhooks report each payout from processing to completed. For a deeper look at how providers compare, see the best stablecoin infrastructure for neobanks.

What to do next

Pull your sign-up countries and transfer requests, score your top five corridors, and pick two. Then open a development instance and send a test payout on each rail with the payout quickstart.