---
title: "Virtual accounts for cross-border payments: use cases, payment rails, and costs"
seoTitle: "Virtual accounts for cross-border payments"
description: "How virtual accounts let payers abroad pay a local-style account, which rails collect and pay out, what drives the cost, and five questions to ask."
date: "2026-08-30"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "Which countries can use a US virtual account for cross-border payments?"
    a: "Two sets of countries matter: where your customer is, and where the payer is. At BlindPay, some account types serve US customers and others serve non-US businesses from supported countries, and senders can be in the US, abroad, or both depending on the account type. Payouts reach 100+ countries. Sanctioned countries are blocked at customer creation."
  - q: "Can a virtual account receive SWIFT payments?"
    a: "Yes, if the account type supports it. At BlindPay, US virtual accounts receive international SWIFT wires, and SWIFT deposits in fact require an approved virtual account, because there is no memo-code fallback for international wires. The deposit reports the sender's name, bank, account number, and reference, so the receiver can match it without asking who paid."
  - q: "How is FX handled when a virtual account settles in stablecoins?"
    a: "A USD deposit settling into USDC or USDT needs no currency conversion, because both are dollar stablecoins. If the payer's account is in another currency, their bank converts it before sending the wire, at its own rate. FX happens again only when stablecoins pay out into local currency, and at BlindPay a payout quote locks the rate and fees for 5 minutes."
  - q: "Do I need a local entity to receive payments into a US virtual account?"
    a: "Not always. BlindPay issues US virtual accounts to non-US businesses on eligible account types, subject to the customer's country and the banking partner, so a company in Brazil or Mexico can receive US payments without opening a US entity. The customer still passes KYB and the account still goes through compliance and bank review."
  - q: "Does the payer need to know anything about stablecoins?"
    a: "No. The payer sees a normal bank account: a routing and account number for US transfers, or SWIFT details for international wires. They pay it the way they pay any supplier. The conversion into USDC or USDT happens after the deposit lands, on the receiver's side."
---

Virtual accounts simplify cross-border payments by giving payers bank details that look local to them. A US client pays by ACH, a foreign client pays by SWIFT, and both send money to an account in the receiver's name. The receiver collects centrally, often in stablecoins, and pays out locally from the same balance.

The payer's experience barely changes. Everything interesting happens after the deposit.

## Key takeaways

- A virtual account turns "open a bank account in every country your payers are in" into "issue an account number."
- Collection and payout are two separate rail choices. Most cross-border cost hides in the gaps between them.
- Settling collections in stablecoins means no pre-funded balances per corridor: the same dollars fund the next payout.
- Local collection in Latin America (Pix, SPEI) works through per-payment instructions, not virtual accounts. Know which is which.

## How do virtual accounts simplify cross-border payments?

A virtual account removes the need for the receiver to hold a bank account in the payer's country. The payer pays a local-looking account over a rail they already use. The provider routes the funds to the right customer and settles them where the business needs them.

Take a design studio in São Paulo with US clients. Without a virtual account, each client sends an international wire to a Brazilian bank: correspondent banks, deductions in transit, days of waiting. With a US virtual account in the studio's name, the clients pay by ACH or domestic wire, exactly like paying a US supplier. The studio receives dollars in the form of USDC, then converts to reais over Pix when it wants to.

The concept is covered in [what is a virtual account](/resources/more/what-is-a-virtual-account). This page is about the cross-border part.

## Which payment rails matter, and in which direction?

Each rail either collects money, pays it out, or both, and a provider may support a rail in one direction only. The table shows typical network speeds (provider processing adds time) and how BlindPay uses each rail.

| Rail | Where | Typical network speed | Collect at BlindPay | Pay out at BlindPay |
| --- | --- | --- | --- | --- |
| ACH | United States | 1 to 3 business days; same day with Same Day ACH | Yes, into a virtual account | Yes |
| Domestic wire | United States | Same business day | Yes, into a virtual account | Yes |
| SWIFT | Global | Up to 5 business days | Yes, requires a virtual account | Yes, minimum 100 USD |
| RTP | United States | Seconds, 24/7 | Yes, through payment instructions, not a virtual account | Yes |
| SEPA | Euro area | Within one business day; seconds for SEPA Instant | No | Yes, in EUR |
| Pix | Brazil | Seconds, 24/7 | Yes, through a Pix code per payment | Yes |
| SPEI | Mexico | Seconds to minutes, 24/7 | Yes, through a CLABE per payment | Yes |

Sources for the network speeds: the [Federal Reserve on Same Day ACH](https://www.frbservices.org/resources/resource-centers/same-day-ach), the [European Payments Council on SEPA Instant](https://www.europeanpaymentscouncil.eu/what-we-do/sepa-instant-credit-transfer), the [Banco Central do Brasil on Pix](https://www.bcb.gov.br/en/financialstability/pix_en), and BlindPay's own [cut-off times](/docs/kb/cut-off-times) for ACH, wire, and SWIFT windows. Cut-offs push late transfers to the next business day.

The pattern: in the US, virtual accounts collect. In Brazil and Mexico, collection runs on a Pix code or CLABE generated per payment, since those rails are instant and push-based already. Payouts work everywhere on the list.

## What are the main cross-border use cases?

Five use cases account for most cross-border virtual account demand.

- **Remittance.** A sender in the US funds a transfer by ACH into their own virtual account. The funds settle as stablecoins and pay out over Pix or SPEI to family abroad in minutes.
- **Payroll and contractors.** A client company funds payroll into its virtual account by wire. Contractors in Latin America get paid in local currency over local rails, without the company holding pesos or reais.
- **Import and export.** An exporter in Mexico gets a US virtual account so US buyers can pay invoices domestically. The exporter converts to MXN over SPEI when it needs to pay suppliers.
- **Marketplaces.** Each seller is onboarded, verified, and gets an account in their own name. Buyer payments land already attributed, and sellers are paid out on their local rail.
- **Latin America payouts.** A US platform collects dollars from its customers and pays thousands of recipients across Brazil, Mexico, Argentina, and Colombia from one stablecoin balance.

One rule runs through all of these: every party whose money moves through an account must be an onboarded customer. A marketplace can give each verified seller an account. It can't collect for unverified sellers through one master account. That's nesting, and BlindPay doesn't allow it ([nested payments](/docs/kb/nested-payments)).

## How does the collect-and-pay-out loop work?

The loop has money coming in through a virtual account and going out through a local payout, with stablecoins in the middle as the settlement layer.

1. **Collect.** The payer sends USD by ACH, wire, or SWIFT to your customer's virtual account.
2. **Settle.** The deposit converts to USDC or USDT and lands in the customer's wallet. Each deposit is its own payin.
3. **Quote.** When it's time to pay someone, request a payout quote for the destination bank account. It locks the rate and fees for 5 minutes.
4. **Pay out.** Execute the payout. The stablecoins convert to local currency and go out over Pix, SPEI, ACH, RTP, SEPA, SWIFT (POBO/COBO), or another local rail.
5. **Confirm.** Webhooks report each step on both sides, so your ledger matches the deposit on one end with the payout on the other.

At BlindPay, both directions are one integration. The industry terms for them come from corporate treasury. Collecting into an account in your customer's name is collection on behalf of (COBO). Paying out under their name is payment on behalf of (POBO). When a SWIFT wire lands, the payin carries `sender_name`, `sender_bank_name`, `sender_account_number`, and `transaction_reference`, so your customer's receivables can be matched without a follow-up email ([POBO and COBO](/docs/kb/pobo-cobo)).

For the payout half in one market, [how to send USDC to a bank account in Brazil](/resources/more/how-to-send-usdc-to-bank-account-brazil) walks through it end to end.

## What drives the cost of a cross-border payment?

Five things drive the cost, and most of them are invisible on the invoice.

- **FX spread.** The gap between the rate you get and the mid-market rate. It's often the biggest cost and the least visible, because it's baked into the rate.
- **Intermediary bank fees.** On SWIFT, correspondent banks between the sender and receiver can take a fee in transit. The charge code on the wire decides who pays: OUR (sender pays all), SHA (shared), or BEN (beneficiary pays). With SHA or BEN, the amount that arrives is less than the amount sent.
- **Network and rail fees.** Wire fees at both banks, ACH fees, and on-chain network fees for the stablecoin leg. On networks like Solana or Polygon, the on-chain fee is usually a fraction of a cent.
- **Pre-funding.** Holding a balance in each destination currency so payouts can go out fast. That capital sits idle, exposed to FX moves, and grows with volume.
- **Provider fees.** Per-account, per-deposit, and per-payout fees. Ask for them itemized.

Two things take friction out. **No pre-funding** means each payout is funded when it's sent, from the stablecoins the collection already delivered, so no money is parked per corridor. **Live quotes** show the exact rate, fee, and amount the recipient gets before you commit, so the FX spread stops being a surprise. [No pre-funding for stablecoin payouts](/resources/more/no-pre-funding-stablecoin-payouts) and [correspondent banking vs stablecoin liquidity](/resources/more/correspondent-banking-vs-stablecoin-liquidity) go deeper on both.

## What should you ask a virtual account provider for cross-border payments?

Five questions, in writing, before you commit:

1. **Which rails can collect into the account, and from which countries?** ACH-only accounts can't take a wire from a client in Germany.
2. **Whose name will the payer see?** Named accounts in your customer's name are easier for foreign payers and their compliance teams to accept.
3. **What does a deposit report about the sender?** Sender name, bank, and reference on every wire save a lot of support time.
4. **How do payouts work from the same balance?** One integration for both directions beats stitching two providers together.
5. **Is pre-funding required, and are quotes itemized?** If you have to park money per corridor, or can't see the fee before you send, the cost is higher than it looks.

## Where does BlindPay fit?

[BlindPay](/virtual-accounts) issues US virtual accounts in your customer's name that receive ACH, wire, and SWIFT and settle automatically to USDC or USDT. The same API pays out over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO) to 100+ countries, with UETR tracking and MT103 confirmations on SWIFT, live quotes, no pre-funding, and KYC, KYB, and sanctions screening in the flow.

## What to do next

Pick your largest cross-border inflow and trace one payment: the rail it used, the charge code, and the amount sent versus the amount that arrived. That gap is what a virtual account plus a local payout should close. Then create a test account on a free development instance with [create a virtual account](/docs/virtual-accounts-create), and check the [POBO and COBO guide](/docs/kb/pobo-cobo) for what your customer's payers will see.

*This article is for general information only and is not legal, tax, or financial advice.*