Virtual Accounts for Cross-Border Payments: Use Cases and Rails

Virtual accounts for cross-border payments are account details issued in a customer's name, so a payer abroad pays over a local rail instead of an international wire. The provider matches each deposit to its owner, converts it if asked, and pays out from the customer's balance in a separate step. The account is only the collection leg.

The label matters because the alternative is slow and leaky. A SWIFT deposit takes 1 to 5 business days, and intermediary banks may deduct fees. A payer who uses a domestic rail skips that path, but only if the account exists in the payer's currency.

Providers use the label for a ledger line, a routable account in the customer's name, or a reference code on a shared account. This post covers the second, a named virtual account (a local account number issued in the customer's own name). A BRL or MXN account is named because a banking partner issues it in the customer's name. The Pix (Brazil's instant payment system) QR code or the SPEI (Mexico's interbank transfer system) memo only tells Lumx which rule a deposit belongs to. The definition is in what a named virtual account is.

A cross-border payment has two legs, and only one is the account

The first leg is collection: a payer pays into an account that carries your customer's name. The second is payout: money leaves toward a destination that belongs to someone else, or to the customer's own bank. Each leg has its own country, rail and cut-off. "Do you offer virtual accounts" is a question about the first leg only.

On Lumx the collection leg is an account and the payout leg is an off-ramp (stablecoin to local currency) to a destination the client registers.

Which rails collect into an account, and which pay out?

Rails are not symmetric. The map shows what Lumx runs, with targets from its documentation read on November 1, 2026. Pix and SPEI carry BRL and MXN. A CLABE (the 18-digit Mexican bank account number) is the SPEI address. Bre-B (Colombia's instant payment system) and PSE (Colombia's online bank-transfer network) carry COP. FEDWIRE (the Federal Reserve's same-day wire system) and Faster Payments (the UK's real-time bank transfer network) cover the US and UK.

Ten rails across six currencies: where each collects into an account, where each pays out, and how fast.

Each currency maps to one account, and every rail for that currency runs on it: the USD account takes ACH, FEDWIRE and SWIFT. A rail that collects does not always pay out, so check both columns for every route. On Lumx the Pix code and the CLABE with memo are standing details tied to the rule, reusable for every deposit; only a one-off on-ramp is per payment.

The Bre-B cap comes from Banco de la Republica, Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2, sheet of March 31, 2026. A UVB is a basic value unit, and 1,000 UVB is COP 12,110,000 for 2026 per the bank's "Conozca Bre-B" page. The cap applies to every provider, not only Lumx. ACH Colombia has no per-payment limit.

SWIFT on Lumx is USD only, so euro and pound legs run on SEPA and Faster Payments. Settlement figures are targets, not guarantees. On SEPA, transfers of 100k euros or more sent between 4:30 PM and 2:30 AM UK time settle the same or next business day.

Four jobs a cross-border virtual account does

Four use cases, the account each one uses, and the payout that follows.

Receivables are the oldest case: a Brazilian company with US clients gives each client a US account in its name, so the client pays a domestic transfer. Payer region maps to rail: US payers use ACH or FEDWIRE, the UK Faster Payments, the euro area SEPA, Brazil Pix, Mexico SPEI and Colombia Bre-B or PSE. Payers elsewhere fall back to SWIFT; the coverage page lists countries. Receiving USD as a Brazilian company walks through it. Stablecoins vs SWIFT covers the wire.

In the Lumx marketplace guide, a seller who only sells through the platform's checkout needs no account: each sale gets Pix or SPEI payment details, and the seller's wallet receives the stablecoin net of the platform's fee. A seller paid by outside platforms gets a USD account. The treasury guide onboards each subsidiary as its own business customer with its own wallet, so funds move between entities as stablecoin transfers. The B2B collections guide covers collection mechanics.

How a deposit becomes a payout

The account owns only the first two steps of the loop. A payer sends money to the account details, and the account matches the deposit to its customer. A rule or a transaction converts it to a stablecoin and credits the customer's wallet. The customer later creates a payout to a destination, the stablecoin converts to local currency, and a local rail lands it.

Conversion has two modes on Lumx. A standing autoconversion rule converts every matching deposit to USDC or USDT with no per-deposit call, at market rate, and the US$ 50 minimum applies to every deposit. A smaller deposit is not converted, and the client writes to operations@lumx.io. On a MXN account with several rules, the memo picks the rule; a SPEI deposit without one converts at the floating rate with no rule applied. A USD or EUR deposit with no active rule or on-ramp stays as fiat on the account, and a deposit above the on-ramp limit is held as a balance. A one-off on-ramp transaction is created in advance for an exact amount and is the mode that can use a locked quote. If a deposit lands after its on-ramp expires, Lumx refunds the sender on the same rail: floating-rate Pix and SPEI on-ramps expire after one day, other rails after seven.

The payout leg is the stablecoin corridor: the asset crosses the border, and a local rail lands it. Cut-offs run in the rail's own time zone, and a payout submitted after a cut-off, on a weekend or on a bank holiday is processed the next business day. The docs' own example: an off-ramp triggered at 4:00 PM in Sao Paulo lands after FEDWIRE's 3:00 PM ET cut-off.

How long before the account can receive money?

After the customer is approved, the time to active depends on whether Lumx has direct reliance with a local banking partner.

Account activation after customer approval, by currency.

Lumx targets one business day for KYB (know your business, the verification of a company and its owners), and the KYB explainer covers what goes into the file. An account can also pause in RFI (request for information, a hold that asks for a document before the account or a payment moves). Once it is reviewed, the account moves back through provisioning, and an active-account webhook is the signal to show payers the details.

What the payer sees, and what you need on your side

The payer sees an account number, an IBAN, a sort code or a Pix QR code, and pays it like any local supplier. They never touch a stablecoin. On Lumx the banking partner holds the funds and executes the rails, and Lumx is not a bank.

You do not need a local entity in the payer's country. A foreign company can hold a named BRL or MXN account without an entity in Brazil or Mexico. You do need an approved customer, and the customer requests each currency's account before it can collect or pay out in it. The supported countries page sorts jurisdictions into standard, enhanced due diligence and restricted, and Colombia sits in the enhanced tier today. COP accounts are open to any customer and are named only when the customer is Colombian; for everyone else the holder shown is the banking partner that runs the Colombian program.

Under the Lumx Nested Payments rules, an account serves the onboarded customer's own activity and may not pool the funds of several third parties, so a platform onboards each seller. See named virtual accounts vs pooled accounts.

Pick the two rails separately, then count the cost

I would make two lists before talking to any provider: where your payers are and which rail each one uses, then where your payees are and which rail each one needs. I recommend asking every provider to show one payment from deposit to payout, with both references on a single record, because that record is what your finance team reconciles against. My position is that a provider who shows only the collection leg has sold you half of the product.

Ask any provider three things: which legs are a named account and which a reference code on a shared account, whether each rail you need collects, pays out or both, and how long until the account is active.

A cross-border payment costs four things, per our cost breakdown: FX spread, intermediary bank fees, rail fees on each leg, and capital parked in balances.

Lumx prices as a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans.

When a virtual account is the wrong tool

When you need a bank. An account issued for collection and conversion does not pay taxes, earn interest or give credit.

When the money belongs to parties you have not onboarded. A named account is the visible end of a verification file.

When a handful of payers pay rarely, a reference code on one account is enough.

What this looks like on Lumx

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

The client creates a customer with the currencies it needs. The customer completes KYB or KYC (know your customer, the verification of an individual), and each account moves from awaiting onboarding through provisioning to ACTIVE. For a standing flow the client creates an autoconversion rule and shares the returned details: a Pix QR code for BRL, a CLABE plus a memo for MXN, account and routing numbers or a BIC for USD, an IBAN and BIC for EUR, a sort code and account number for GBP. Each matched deposit becomes USDC or USDT in the customer's wallet.

The payout is a separate call. The client registers a destination, creates an off-ramp from the wallet, and follows it through a stablecoin transfer, a trade and a fiat transfer to success. Every transfer carries a per-rail reference, so deposit and payout can sit in one ledger.

Prove the loop before real money moves. The sandbox is open, with every currency enabled, and takes no real deposits: the client calls simulate-deposit with the rule's reference, or creates a regular on-ramp, and the same webhooks fire.

The named virtual accounts page lists the currencies, and global payments covers payouts. Pairs: USD to USDC, EUR to USDC. Next step: in sandbox, create a rule for your main payer currency, call simulate-deposit and confirm deposit and payout land on one record.

Methodology and sources

The Colombian rails (Bre-B and PSE collection, Bre-B and ACH Colombia payout), COP activation and the named BRL account reflect Lumx's current product, effective November 2026. The rest comes from the Accounts, Coverage, Payment rail cut-off times, Transactions, Destinations, Autoconversion Rules, Request for Information, Nested Payments and Supported countries pages and the Marketplaces and Treasury management guides in the Lumx documentation, read on November 1, 2026.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Maxime Galliot on Unsplash.