How importers and exporters collect cross-border payments with virtual USD accounts and stablecoins

Importers and exporters lose time and money to correspondent banking, the chain of banks an international wire passes through. A virtual USD account shortens the chain. An exporter gives overseas buyers a virtual USD account to pay by ACH, wire or SWIFT. The deposit is converted to a stablecoin, and the provider pays the exporter's local bank account, which avoids slow correspondent banking steps.

This guide is for a finance lead at an import and export business, or the fintech that serves one. A stablecoin is a token pegged to a currency such as the US dollar, and a payin is fiat arriving and stablecoins going out to a wallet.

Key takeaways

• A virtual USD account gives the exporter its own US routing and account number. Buyers pay it like any US bank account.
• Each deposit creates a payin that BlindPay converts to USDC or USDT in a linked wallet.
• Invoice matching relies on the payer's reference and the payin record. International wires report sender name, bank and reference.
• Payouts to the exporter's local bank run over rails such as Pix, SPEI, SEPA or SWIFT. Speed depends on the rail.
• Compare total cost, not headline fees. Include FX margin and the monthly account fee.

What problem do exporters face with international wires?

Exporters face slow, costly and opaque wires. A wire to an exporter often crosses one or more intermediary banks, each of which can add a fee, a delay or a request for documents. The buyer's bank may charge the sender, an intermediary may deduct from the amount, and the exporter's bank may charge to receive it. The exporter often sees the final amount only when it lands.

Typical pain points:

1. Unclear arrival date. Cut-offs and time zones decide whether a wire lands today or next week.
2. Fees taken from the amount. Deductions along the chain make the received amount differ from the invoice. See hidden fees in international wires.
3. Weak payment references. Short or stripped references make invoice matching manual. SWIFT messages carry a limited reference field.
4. No local USD account. Buyers want to pay in dollars, but the exporter has no US bank account.

SWIFT publishes its own explainer of the unique end-to-end transaction reference (UETR), the identifier that lets banks track one payment across the chain.

How does a virtual USD account change the flow?

It replaces the exporter's missing US account with a dedicated one. The buyer pays a US account in USD. The provider converts the deposit to a stablecoin and delivers it to a wallet. The exporter, or its fintech, then pays out to a local bank. The long correspondent chain is replaced by one deposit and one local payout.

On BlindPay, a US virtual account is issued to one customer and settles to one blockchain wallet. Per the virtual accounts docs, US accounts accept ACH, wire and SWIFT, and there are account types for businesses with foreign senders. Each account costs $1.50 per month. Fees on deposits depend on the amount: below $100.00 they accrue to your invoice, and from $100.00 they are charged at the time of the transaction.

The account goes through a two-stage review. First BlindPay's compliance team reviews it (pending_review). Then the banking partner does a final review (verifying). Issuance SLAs depend on the account type, and approval is not guaranteed. On a development instance, accounts are created approved so you can test. The exporter must first pass KYB. See KYC and KYB for stablecoin payins.

Before and after, step by step:

How do I match payments to invoices?

Match on three things: who paid, how much, and what reference they used. Every deposit into a virtual account becomes a payin with its own ID, amount and timestamp, so reconciliation starts with a clean record rather than a bank statement line.

For international wires, the BlindPay payin reports sender_name, sender_bank_name, sender_account_number and transaction_reference, per the POBO and COBO docs. The payin.complete webhook carries them too, so the finance team does not have to ask who paid.

Invoice to payout flow, in order:

Rules for clean matching: ask for the invoice number first in the reference, keep amounts exact, and run a daily job that lists payins and compares them with open invoices. The webhook is the fast path and the API list is the safety net. See virtual accounts for B2B receivables for a worked collection flow.

How do payouts to a local bank work?

You create a payout quote for the amount, then execute it. The quote locks the rate and fees for 5 minutes. The funds move from the funding wallet to the destination bank account over a local rail. The exporter's bank account is added once as a bank account on the customer.

BlindPay's docs list estimated arrival times by rail:

High volumes can affect times, and the SWIFT cut-off is 10:30 AM ET with settlement of up to 5 business days under the general network window (cut-off times). Payouts that go on compliance hold can wait up to 30 days. If the exporter pays its own account in another country, set the recipient relationship to first party, and the beneficiary name must match the customer.

Importers use the same mechanism in reverse. They fund by ACH or wire into a virtual account, then pay overseas suppliers by local rail. How Brazilian and Mexican companies pay US suppliers shows the full chain. For how PSPs and platforms package this for clients, see stablecoin payins for PSPs, remittance and payroll.

What are POBO and COBO?

POBO means payment on behalf of. COBO means collection on behalf of. They let a platform pay or collect for its customers instead of forcing every customer to open an overseas account. POBO is outbound: you pay a supplier for an obligation that belongs to your customer. COBO is inbound: you collect a payment that belongs to your customer.

At BlindPay, both rest on a virtual account issued to a specific onboarded customer, and on the Named Account setting, which puts that customer's name on the payment instead of BlindPay's. Named Account is available on ACH, domestic wire and international SWIFT. It is enabled per customer on request and takes up to 1 business day.

The compliance line is visibility. The customer must be onboarded, must have passed KYC or KYB, and must hold a virtual account in its own name. A customer that pays or collects for its own clients, whom BlindPay has never onboarded, creates a nested structure, which is prohibited. For SWIFT payouts to anyone other than yourself, a document proves the relationship: invoice, purchase order, delivery slip, contract, customs declaration, bill of lading or others. Every SWIFT payout starts on_hold until review. Reference: POBO vs COBO explained and the POBO and COBO over SWIFT page.

Two details to plan around. Only the first 30 characters of the payment description reach the beneficiary bank, so put the invoice number first. And BlindPay does not fill the ISO 20022 ultimate-party fields. The customer's identity reaches the payee through the account title and the reference.

What does it cost compared with a wire?

Compare every line of cost for your usual invoice size. There is no single answer, and this guide does not quote a wire fee because wire fees vary by bank, by country and by who pays. For a method to audit a quote, see the 7-point wire quote audit.

BlindPay's pricing is a monthly plan plus per-transaction fees that vary by rail and network. The live quote discloses them before you execute, and pricing explains the structure.

Where does BlindPay fit?

BlindPay offers virtual USD accounts with ACH, wire and SWIFT payins, conversion to USDC or USDT, local payouts, and KYC and KYB in the same API. The docs describe each piece used in this guide.

• US virtual accounts issued per customer, settling to one wallet each, with a two-stage review.
• SWIFT payins that require an approved virtual account, and payer fields on the payin for matching.
• Payouts to 12 rail types, including Pix, SPEI, SEPA, Faster Payments, ACH, wire, RTP and SWIFT.
• POBO and COBO over SWIFT with Named Account and a document gate for third-party payouts.

BlindPay offers payins to an external blockchain wallet the customer controls, or to an optional BlindPay-managed wallet (beta). Hub: virtual accounts for stablecoin payins. Check supported countries before you promise a corridor, because some countries restrict or prohibit third-party payments.

Sources

• SWIFT, What is the unique end-to-end transaction reference (UETR): https://www.swift.com/payments/what-unique-end-end-transaction-reference-uetr (checked on 2026-11-07)
• BlindPay docs, Virtual accounts: /docs/virtual-accounts
• BlindPay docs, POBO and COBO: /docs/kb/pobo-cobo
• BlindPay docs, Cut-off times: /docs/kb/cut-off-times
• BlindPay docs, Pay out to bank (rails and estimated arrival): /docs/bank-accounts

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