Skip to content

Stablecoin to SWIFT payout: when to route to SWIFT instead of a local rail

Use local rails first and SWIFT as the fallback. A routing table, the data a SWIFT payout needs, the 100 USD minimum, and a copyable routing policy.

A stablecoin payout can reach a bank account in most countries over SWIFT, but it should be your fallback, not your default. Route to a local rail first (Pix, SPEI, ACH, SEPA and so on) and use SWIFT only when no local rail covers the recipient. SWIFT starts at 100 USD and takes about 2 to 5 business days.

This guide is for teams with recipients in many countries and a growing long tail. It reflects BlindPay's docs as of October 2026. For the full picture of the product, start with what a stablecoin payouts API is. BlindPay publishes this post, so read the BlindPay-specific claims as ours and check them in the linked docs.

Key takeaways

  • Local rail first, SWIFT as the fallback: Pix, SPEI, Transfers and RTP settle instantly, while SWIFT takes about 2 business days per BlindPay's bank accounts docs and up to 5 on the network.
  • A SWIFT payout needs a minimum of 100 USD on the requested amount, checked before fees.
  • Every SWIFT payout starts on_hold until compliance documents are submitted and approved.
  • Third-party bank accounts are allowed when recipient_relationship is not first_party.
  • BlindPay's SWIFT rail is global and subject to country tiers. Check the supported countries list before you promise a corridor.

What does "local rail first, SWIFT as fallback" mean?

It means your payout service picks the destination's local rail whenever one exists, and falls back to SWIFT only when none does. This keeps most volume fast and predictable.

A local rail is the domestic payment system of the recipient's country. Brazil's Pix is run by the central bank and works around the clock. SWIFT is a messaging network between banks, so a payment can pass through one or more intermediary banks, each with cut-offs and checks of its own.

BlindPay supports these payout rails: SWIFT (global), ACH, wire and RTP (US), Pix, PIX Safe and TED (Brazil), SPEI (Mexico), ACH COP (Colombia), Transfers (Argentina), SEPA (Europe) and Faster Payments (UK). The rule is simple: if the recipient's account fits one of the local ones, use it. Which payment rail by scenario goes deeper on the trade-offs, and SWIFT vs local rails for neobank transfers covers the user experience.

What is the routing decision table?

Use one row per corridor, with a preferred rail, a fallback and the expected speed. The speeds below are BlindPay's estimated times of arrival from the bank accounts docs.

CorridorPreferred railFallbackExpected speed (preferred)
United States (USD)RTP, then wire or ACHSWIFT for non-US accountsRTP instant, wire ~1 business day, ACH ~2
Brazil (BRL)PixPIX Safe, then TEDPix instant, TED ~1 business day
Mexico (MXN)SPEISWIFT for non-Mexican accountsInstant
Colombia (COP)ACH COPSWIFT~1 business day
Argentina (ARS)TransfersSWIFTInstant
SEPA zone (EUR)SEPASWIFT for non-EUR accounts~1 business day
United Kingdom (GBP)Faster PaymentsSWIFT5 to 30 minutes
Any other supported countrySWIFTNone~2 business days (network up to 5)

Two caveats. First, high volumes can move estimated times, as the docs note. Second, rails have cut-offs: international SWIFT has a 10:30 AM ET cut-off in BlindPay's cut-off times reference, and a payout submitted after it can slip a day. Settlement times for stablecoin payouts explains how to read these numbers.

What data does a SWIFT payout need?

A SWIFT payout needs the beneficiary's bank identifier, account number or IBAN, and full addresses for both the beneficiary and the bank. Missing or badly formatted fields are the main reason SWIFT payouts stall.

Per the bank accounts docs, the required fields for international_swift are:

  1. name, account_class (individual or business) and recipient_relationship.
  2. swift_code_bic, the bank's BIC. If it has 8 characters, append XXX.
  3. swift_account_holder_name and swift_account_number_iban.
  4. The full beneficiary address and the full bank address.
  5. Conditional fields: swift_payment_code for some countries (for example CH, CN, HK, IN, JP), and an IFSC branch code for India.

Formatting matters. BlindPay's SWIFT deliverability guide asks for uppercase, plain text without punctuation, and a beneficiary address that stays under 140 characters in total. How to send a SWIFT payout from USDC walks through each field.

SWIFT payments carry structured data end to end since the network ended the coexistence of MT and ISO 20022 cross-border messages on 22 November 2025, so clean fields pass screening faster.

How does the 100 USD minimum apply?

The minimum is 100 USD on the requested amount, before fees. A request below it is rejected with swift_minimum_is_100_usd and no payout is created.

"Before fees" means the check looks at the amount you request, not at what the recipient gets after fees. A 100 USD request passes even if the fiat received ends up lower once fees come out. The check applies to quote-based payouts and offramp wallet payouts alike.

Practical consequences for routing:

  • Small payouts to a country with a local rail (10 USD minimum sender amount on most rails) belong on that rail.
  • Small payouts to a SWIFT-only country need batching or a higher minimum on your side. Validate the amount in your own service before you call the API.
  • SEPA and Faster Payments use their own minimums, covered in our guide to stablecoin payouts to SEPA and Faster Payments.

How do third-party bank accounts work on SWIFT?

You can pay a bank account that belongs to someone other than your customer. Set recipient_relationship to a value other than first_party, such as vendor_or_supplier, employee or independent_contractor.

This skips the name-match check that applies to first-party accounts. In exchange, BlindPay's payout quotes docs say documents are required when the recipient relationship is not first_party: an invoice, purchase order, delivery slip, contract, customs declaration or bill of lading that shows the relationship between sender and recipient. Documents are submitted after the payout is created, within 30 days, and reviewed within 8 days of submission, according to the SWIFT statuses guide. A document that does not show the relationship leads to rejection.

The payout therefore sits on_hold with tracking_documents.status: waiting_documents, then compliance_reviewing, then moves to processing. Build your UI around that wait. First-party vs third-party payouts explains the compliance reasoning, and stablecoin payout compliance covers KYC, KYB, sanctions and the travel rule.

What is a copyable routing policy template?

Below is an illustrative pseudo-config. It is not a BlindPay API object: it is a shape you can adapt inside your own payout service.

yaml
# illustrative routing policy, adapt to your service
routing_policy:
  default: swift
  swift:
    min_request_usd: 100        # reject below this before calling the API
    require_fields: [swift_code_bic, swift_account_number_iban, beneficiary_address, bank_address]
    third_party_requires_documents: true
    expect: "~2 business days, network up to 5, starts on_hold"
  corridors:
    BR: { prefer: pix,             fallback: [pix_safe, ted] }
    MX: { prefer: spei,            fallback: [] }
    CO: { prefer: ach_cop,         fallback: [swift] }
    AR: { prefer: transfers,       fallback: [swift] }
    US: { prefer: rtp,             fallback: [wire, ach, swift] }
    GB: { prefer: faster_payments, fallback: [swift] }
    EU: { prefer: sepa,            fallback: [swift] }   # SWIFT only for non-EUR accounts
  rules:
    - if: "local rail exists and account fits it"
      then: "use local rail"
    - if: "rail is swift and amount < min_request_usd"
      then: "reject or batch"
    - if: "rail is swift and country not in supported list"
      then: "reject at bank account creation"
    - always: "create a quote, show the fee breakdown, execute before expires_at"

Run the policy before the quote, so a payout never fails on the minimum or on a missing field. Then create the quote, which locks the rate and fees for 5 minutes, and execute the payout. Read expires_at in epoch milliseconds. How stablecoin payouts work step by step covers the flow.

Is SWIFT slower than a local rail?

Yes, and you should say so to your users. The honest range is about 2 business days from BlindPay's docs and up to 5 business days for the network, plus any document review while the payout is on hold.

Holds can last up to 30 days before the payout times out and fails. A failed payout is not refunded automatically: contact support@blindpay.com. BlindPay's custody and refund rules are covered separately. Use webhooks (payout.new, payout.update, payout.complete) to show status rather than polling.

Costs also differ. BlindPay's fees vary by rail and network and appear in the quote, and hidden fees on international wires explains charge options on the bank side. See stablecoin payout API pricing for how to read a quote.

Which countries can you reach with SWIFT?

SWIFT on BlindPay is global but not unlimited. BlindPay lists every country by tier (standard, high-risk, prohibited), and a prohibited country blocks customer and bank account creation, including the SWIFT beneficiary, bank and intermediary country fields.

BlindPay's supported countries page is the source of truth, so this guide gives no country count. High-risk countries need KYC Enhanced for individuals, with manual review of up to 1 business day. Test the exact corridor on a free development instance before you commit it to a routing rule: development payouts complete automatically, and request_amount 66600 forces failed.

How does BlindPay handle SWIFT payouts?

BlindPay lets you add a SWIFT bank account once, quote the payout in USDC or USDT, and execute it through the same API as every local rail. Cross-border wires run as SWIFT (POBO/COBO) payments and collections on behalf of, with UETR tracking and MT103 confirmations. The compliance document step is part of the payout status, so your code handles one flow.

For custody, BlindPay states: BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. If a payout cannot be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or to the sending wallet when none is set; on Pix and other non-USD local rails the refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review. Optional BlindPay-managed wallets (beta) are custodial when you choose that path.

On pricing, BlindPay's wording is: BlindPay combines a monthly plan (platform access) with per-transaction fees that vary by rail and network and are disclosed only in the live quote before execute. BlindPay does not publish a static flat rate card; always cite the quote's fee breakdown rather than a fixed bps number. There is no setup fee and no monthly minimum, and development instances are always free.

Methodology and sources

External sources: Swift on the ISO 20022 switch (22 November 2025), Swift UETR explainer (the reference that lets a SWIFT payment be tracked end to end), and the Central Bank of Brazil's Pix page.

BlindPay docs used: bank accounts, payouts, payout quotes, SWIFT deliverability, SWIFT statuses, cut-off times, supported countries and billing. Related reading: SWIFT POBO vs COBO.

What to do next

Write your routing table for your top ten corridors, mark each one as local rail or SWIFT, and add the 100 USD check to your payout service. Then see all the rails in the payment methods reference and run a SWIFT payout on a free development instance with the payout quickstart.

FAQ

One API.
Multiple payment rails.

Blind Pay, Inc. (“BlindPay”) is a United States-based financial technology and payments infrastructure company, incorporated in the State of Delaware on May 2, 2024. BlindPay is duly registered as a Money Services Business (“MSB”) with the Financial Crimes Enforcement Network (“FinCEN”) under registration number 31000277566153. BlindPay is not a state-licensed money transmitter and does not, in its own capacity, engage in regulated money transmission services. All such regulated activities are conducted exclusively through, and under the licenses of, duly authorized financial institution partners. BlindPay's role is limited to providing financial technology, virtual account management, payment processing, and related payments infrastructure services that facilitate payment flows and account functionalities. These services are provided in coordination with its licensed partners and in compliance with applicable federal MSB requirements and relevant state regulatory frameworks.

Blind Pay, LLC (“BlindPay”) is a Delaware limited liability company formed on June 24, 2025. BlindPay is duly registered as a Money Services Business (“MSB”) with the Financial Crimes Enforcement Network (“FinCEN”) under registration number 31000318334247 and is listed in the Nationwide Multistate Licensing System (“NMLS”) under NMLS ID #2745309.

BLIND PAY SOCIEDADE PRESTADORA DE SERVIÇOS DE ATIVOS VIRTUAIS LTDA. (“BlindPay”) is a Virtual Asset Service Provider (“VASP”) operating in Brazil. The company is presently completing the regulatory adaptation process required of Virtual Asset Service Provider Companies (SPSAV) under Central Bank of Brazil Resolution No. 520/2025, and remains subject to the transitional regime set forth in Article 88 of that Resolution. Registered address: Avenida Princesa Isabel, nº 15, Sala 1405, Edifício Martinho de Freitas, Centro, Vitória/ES, 29010-361.

BlindPay is a stablecoin API that enables individuals and businesses to move money worldwide.