Named virtual accounts and one-time deposit instructions are two ways to tell a payer where to pay. A named virtual account (a local account number in the customer's own name) stays the same for every deposit. One-time deposit instructions are generated for a single payment and discarded after it.
This post compares them for collections in Brazil, Mexico and Colombia, rail by rail. Whose money sits in the account is a different question, covered in named virtual accounts vs pooled accounts, and the object itself is defined in what a named virtual account is.
What each model puts in front of the payer
A one-time instruction is created for one expected payment. It carries the amount, an identifier and an expiry, and it is finished when the money arrives or the window closes. The payer gets new details every time.
A standing instruction is issued once and reused. The account number, or the code that points to it, belongs to one customer, so any deposit that lands is that customer's by construction.
Pix (Brazil's instant payment system, run by the Central Bank) shows how thin the line between the two can be. The Central Bank's Pix initiation manual, version 2.10.0 (the stable version when read), says a static QR code can carry a transaction identifier (txid) of up to 25 characters that the payer's bank must pass along intact, so the receiver can reconcile. Its own static example leaves the field unused, so a static code identifies only the receiver unless the issuer sets a reference. A dynamic code uses a txid of 26 to 35 characters.
How do the two models compare in BRL, MXN and COP?
On every rail the question is the same: what does the payer hold, and what ties the transfer back to a customer or an invoice.
One-time and standing collection instructions in Brazil, Mexico and Colombia, as of November 1, 2026
Country and rail | One-time instruction | Standing instruction | What ties a deposit to its sender |
Brazil, Pix | A dynamic Pix code issued per charge | A static Pix code, or the account's agência and conta | The txid the issuer sets in the code (a Lumx rule embeds one), or the account itself |
Mexico, SPEI | Transfer details with the amount to send | The account's CLABE | A memo reference the payer types, plus the amount on a one-off |
Colombia, Bre-B | None: the payer pushes money to a key | The Bre-B key of the account | The key identifies the account, so invoice-level matching is on your side |
Colombia, PSE | A PSE payment the payer authorizes at their own bank | None: the payer authorizes every debit | The payment the payer authorized |
A standing instruction does not always remove the reference. In Mexico, on SPEI (Mexico's interbank transfer system, run by Banxico), a CLABE (the 18-digit Mexican bank account number) says whose money it is, but a memo still tells the rule or the invoice apart, and a memo is a free-text field a person types. On a Lumx rule the reference sits inside the static Pix code, so a payer who pastes it cannot drop it. Colombia does not offer both models on both rails. Bre-B (Colombia's instant payment system) is standing by nature, because a key is a standing address, and PSE (Colombia's online bank-transfer network) is one-time by nature, because a pull rail needs the payer's authorization each time.
Bre-B has a ceiling nobody sets per customer. The Banco de la República caps each Bre-B operation at 1,000 UVB (the basic value unit, revalued each year), which is COP 12,110,000 for 2026, under its Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2. A standing Bre-B key serves any payer up to that line, and one Bre-B payment cannot carry an invoice above it.
For US payers the picture is simpler: USD collections on Lumx are matched to the account, not to a per-rule reference. That case is in receiving USD as a Brazilian company.
On Lumx, a BRL account is a named virtual account with agência and conta, and it takes Pix only. A standing autoconversion rule on a BRL account returns a static Pix code that embeds its reference, and an MXN rule returns the account's CLABE with a memo reference. A one-time on-ramp returns the payment details for one expected amount, a Pix code on Pix, and a COP account takes Bre-B on its own key and PSE. The COP account is named when the customer is Colombian.
Where each model breaks
A one-time instruction fails on time and on amount. Lumx's on-ramp transactions have a payment window: a locked quote expires with the quote, a floating Pix or SPEI on-ramp stays open for 1 day, and a floating one on other rails for 7 days. A deposit that lands after expiry is not processed and goes back to the original sender on the same rail. A payer who sends a different amount hands you a manual case.
A standing instruction fails on identity. A payer saves old details and pays the wrong invoice, a treasury system truncates the memo, or a third party pays under its own name. The money lands in the right account, and the ledger still has to decide which invoice it closes. Lumx permits third-party collections (COBO), but a payer that looks unusual can trigger a compliance hold and a prompt return. A deposit above the customer's limit is held as a balance. On Lumx, an autoconversion rule converts at market, with no locked quote, and the 50 USD minimum applies to every deposit, so a standing instruction suits real amounts, not dust. An MXN account can hold several rules, and the memo picks the rule. A SPEI payment with no memo still lands and converts at a floating rate, without any rule. On a USD or EUR account with no active rule and no on-ramp, the fiat just sits on the account.
Both models share one failure: a deposit that compliance monitoring flags is held for an RFI (request for information, a compliance hold that asks for a document before a transaction clears), whichever instruction the payer used. On Lumx, compliance reaches out by email or Slack, and the deposit may be refunded to the sender if nobody answers within 24 hours. When a deposit does not show up, the first question is which model it came through, and deposits that were not received walks through the rest.
Setup, cost and compliance before the first payment
On Lumx a customer must be approved before any transaction, so a business goes through KYB (know your business, the verification of a company and its owners) either way, and what KYB involves is the same for both models. Lumx targets one business day for the review.
What differs is account provisioning. BRL, MXN, EUR, GBP and COP accounts reach active status right after approval. The customer has to request each currency's account before it can collect or pay out in it. MXN, EUR and GBP accounts are named and collect from payers abroad. A USD account can take up to 1 business day for the banking partner's review. The account.active webhook says when any of them is ready.
On cost, the Lumx pricing model is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. The platform pays the items, not the end customer: one fee per customer verification, charged once at onboarding; one fee per virtual account opened, once per currency; and a monthly fee per active account. There is no transaction monitoring fee, and the figures come by agreement. The rail-by-rail view is in fees and KYB by rail.
Choosing by payer: account, wallet address or one-time instruction
A payer on a local bank rail needs a bank-style instruction. A payer who holds stablecoins needs a blockchain address.
Collection instrument by payer type and reconciliation effort
Payer | Best instrument | Reconciliation effort |
A Brazilian company that pays you every month over Pix | Standing account or static Pix code | Low: the account or the embedded reference does the match |
An individual or small business paying one invoice over Pix | One-time Pix code for the amount | Low: the amount and the code are unique to the payment |
A Mexican company paying from an ERP over SPEI | Standing CLABE with a memo reference | Medium: the CLABE gives the customer, the memo gives the invoice |
A Colombian payer at a bank checkout | PSE payment | Low: the payer authorized this exact payment |
A Colombian company that pays often | Standing Bre-B key | Medium: the key gives the account, your ledger gives the invoice |
A payer who holds USDC or USDT | Wallet address on the network they use | Low: one address per customer, one transfer per credit |
A US payer by ACH or wire | Standing USD account | Low: matched to the account, with no reference to lose |
On Lumx, every customer also gets a custodial wallet on each supported blockchain, provisioned with the customer. The wallet address holds balances and can receive direct transfers, so a payer that holds USDC or USDT sends to the address and skips the bank rail and the conversion. A webhook for a deposit from an outside wallet is coming, so for now you read the balance. Accounts handle the payers on local bank rails, and the wallet handles the payers who are already on a blockchain.
When to move a payer onto a standing account
Start every payer on whichever instruction fits their first payment, and move them on a signal, not a calendar. Three signals count: the same payer pays twice, a deposit arrives with a missing or wrong reference, or the payer pays from a system that reuses saved details.
I recommend moving a payer to a standing account at the second invoice, or at the first deposit that arrives without its reference, whichever comes first. A one-time instruction for the second invoice is a bet that this payer will copy the code correctly again, and the cost of losing that bet is a person matching a deposit by hand. I would keep one-time instructions for anything quoted at a locked rate with a deadline, because there the expiry is the feature.
When a named virtual account is the wrong tool
When there is no standing relationship. A single invoice, a one-off checkout or thousands of consumers each paying once need an instruction per payment, and an account per payer is overhead.
When the account would pool other people's money. A flow that collects from many buyers into one account and distributes to sellers the provider never saw is the structure that named virtual accounts vs pooled accounts explains. Lumx treats it as nested payments, which need the written approval of compliance.
When the product needs a bank. An account that only receives and converts is the wrong shape for a payer who needs a bank relationship.
The reverse also holds: one-time instructions are the wrong tool for a recurring B2B payer whose accounts-payable system reuses saved bank details. Named virtual accounts for B2B collections covers that case.
How Lumx runs both models
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 choice is per payer, not per integration. A per-payment on-ramp takes the customer, the rail, the source amount and the target stablecoin, and returns the details for that payment: a Pix code on Pix. It moves through AWAITING_FUNDS, TRANSFERRING_FIAT, TRADING and TRANSFERRING_STABLECOIN to SUCCESS, and each status change fires an onramp webhook. A standing autoconversion rule is created once on an account, names the target asset and network, and converts every matching deposit with no call per deposit.
The accounts behind both are issued by a Lumx banking partner, one currency per account, and in every currency except COP the payer sees the customer's name. A BRL account has agência and conta and takes Pix only. A foreign company gets a named BRL or MXN account without a local entity in Brazil or Mexico. A COP account is available to any customer and is named, in the customer's own name, when the customer is Colombian. For other customers the holder shown is the banking partner, because COP runs through the partner's sponsored program. The named virtual accounts product is where they live, and the rail coverage page lists what is live in each currency.
Live rates are on the BRL to USDC and MXN to USDC pages. The vendor view is in Lumx and Avenia compared, and the concept behind a route is what a stablecoin corridor is.
Methodology and sources
Account activation, the on-ramp payment window and late-deposit rule, the autoconversion rule with its minimum and deposit details, the wallet schema and the nested-payments rules were read on docs.lumx.io on November 1, 2026. Pix static and dynamic transaction identifier lengths come from the Central Bank of Brazil's Manual de Padrões para Iniciação do Pix, version 2.10.0, read on the same date (the page also lists a 2.11.0 release candidate). The Bre-B cap is taken from the Banco de la República's Circular Reglamentaria Externa DSP-465 of August 6, 2026, with the 2026 value of 1,000 UVB at COP 12,110,000 from its Bre-B page, which blocks automated requests and is cited by name. The COP collection rails, the BRL named account, the COP naming rule and the accounts for foreign companies were confirmed by Lumx between October 27 and November 1, 2026.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Kote Puerto on Unsplash.
What is the difference between named virtual accounts and one-time deposit instructions?
A named virtual account is a standing account number in one customer's name, reused for every deposit. One-time deposit instructions are generated for a single expected payment and expire with it. The account identifies the payer's customer on its own, and an instruction identifies a payment through its amount and reference. Lumx runs both: a per-payment on-ramp returns one-time details, and a named account with an autoconversion rule gives standing ones.
When should a payer move from one-time instructions to a named account?
Move them when the same payer pays twice, when a deposit arrives with a missing or wrong reference, or when the payer's system reuses saved bank details. Keep one-time instructions for quoted amounts with a deadline. On Lumx, a customer's BRL and MXN accounts are active right after approval, so the standing details are ready the moment you decide to switch.
What happens if a deposit arrives late or without its reference?
A late deposit on a one-time instruction is not processed and goes back to the sender on the same rail. A deposit without its reference lands in the right account but needs a person to say which invoice it closes. On Lumx, an on-ramp that expired refunds the sender on the same rail, and an autoconversion rule converts at market any deposit that matches the rule (by reference for BRL and MXN, by account for USD, EUR and GBP) and is worth at least 50 USD.
Can a named virtual account receive Pix, SPEI and Bre-B?
Yes, with one qualifier in Colombia. Bre-B transfers are capped at 1,000 UVB per transaction, about COP 12.1 million. On Lumx, BRL and MXN accounts are named for any customer, including foreign companies: a BRL account takes Pix with agência and conta, and an MXN account takes SPEI on its CLABE with a memo reference. A COP account takes Bre-B on its own key and PSE for any customer, and is named when the customer is Colombian.
Do both models need KYB before the first payment?
Yes. A business has to be an approved customer before it can collect through either model, so verification comes first and the instruction type comes after. On Lumx, the KYB review targets one business day, and BRL, MXN and COP accounts become active right after approval.
