Virtual accounts for cross-border payments: use cases, payment rails, and costs

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. 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.

Sources for the network speeds: the Federal Reserve on Same Day ACH, the European Payments Council on SEPA Instant, the Banco Central do Brasil on Pix, and BlindPay's own 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).

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).

For the payout half in one market, how to send USDC to a bank account in 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 and 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 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, and check the POBO and COBO guide for what your customer's payers will see.

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