A virtual account provider is a bank-backed service that issues local account details to receive payments for your customers. Choose one on twelve checks, because price is only one: whose name the account carries, which rails each currency receives, who holds the funds, and how failures surface. Run each as a test.
Which 12 checks separate one virtual account provider from another?
The 12 checks, the test for each, and what a pass looks like.
# | Check | Test to run | A pass looks like |
1 | Account name | Send a small deposit from a third-party bank and read the statement on both sides | The payer and the statement show your customer, not the provider |
2 | Rails per currency | Ask for the rails that receive and the rails that send, per currency, on one account | Each rail is live today and written down, not on a roadmap |
3 | Opening time | Ask the time from an approved customer to an active account, per currency, and what restarts the clock | A number per currency, plus an event when the account flips to active |
4 | Verification scope | Ask which KYB documents are needed, for which owners, and the review target | Documents named, the owner threshold stated, a target in days |
5 | Custody | Ask in whose name funds sit, at which institution, before conversion and after it | One plain sentence per stage naming the party and the type of institution, with no "your funds are safe" language |
6 | Conversion | Ask whether deposits convert on arrival, and at which rate type | A standing rule or a per-deposit call, with the rate type stated |
7 | Reconciliation data | Pull one successful deposit record and one failed record | Each has its own id, a status, and a rail reference |
8 | Failure handling | Ask what happens to a held, a rejected and a late deposit, and who answers a hold | A named hold status, a reason you can get in writing for each hold or rejection, a return path, and a named channel with a response window |
9 | Limits | Ask the limits per transaction, per day and per month, by verification level | Numbers per level, and a written path to raise them |
10 | Price | Ask for one deposit costed end to end, FX included | Every fee appears on the record where it was charged |
11 | Third-party funds | Ask whose money may pass through the account | A written policy that matches how your product collects, plus the screening run on each party and the prohibited activities listed |
12 | Test and exit | Run a deposit in the sandbox, then ask how accounts move out | A sandbox without a sales call, and an exit that reissues details |
Name and rails: the two checks that decide the shortlist
The name test costs one transfer. A named virtual account (a local account number issued in the customer's own name) shows your customer on the statement. A pooled account shows the provider and relies on a reference someone typed into a free-text field. Named vs pooled accounts covers the difference, and the named virtual account explainer the basics. Virtual account vs virtual IBAN sorts the labels.
Read rails as a list per currency, never as a country count. "We cover Latin America" tells you nothing until each currency has its receiving and sending rails named. Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's interbank transfer system, run by Banxico) are both real-time rails. PSE (Colombia's online bank-transfer network) is a pull rail, where the payer authorizes a debit, so it collects but never pays out. Bre-B (Colombia's instant payment system) can do both.
On Lumx, a BRL account collects over Pix and a MXN account over SPEI, using a CLABE (the 18-digit Mexican bank account number). A COP account collects over PSE and over Bre-B, on a Bre-B key in the account. USD, EUR and GBP accounts run on the local rails listed in the table below. Accounts are issued by a banking partner in the customer's name, USD, EUR and GBP included; the exception is COP for customers outside Colombia, where the banking partner is the holder shown. A foreign company can hold named BRL and MXN accounts without a local entity, and the customer requests each currency's account before it can collect or pay out in it. The live list is on the coverage page.
Opening time and KYB scope: ask per currency, not per provider
Opening time depends on the provider's local bank relationship, so it varies per currency. Ask what restarts the clock: a rejected document, a missing owner, an extra review.
Then get the KYB (know your business, the verification of a company and its owners) scope in writing. A company usually has to show formation documents, its representatives and its owners above the provider's ownership threshold, a recent proof of address, and what it expects to move and from whom. KYC (know your customer) asks an individual for an identity document and a liveness check. A provider that cannot list this before the contract will ask for it later. The KYB explainer covers what each document proves.
On Lumx, an account is created with its customer and waits for verification, and the KYB documents are in the table below. BRL, MXN, EUR, GBP and COP accounts are active right after approval, and a USD account takes up to one business day while the banking partner reviews it. The account.active webhook tells you the moment an account can receive funds.
Reconciliation and failure handling: read the records before you sign
Ask for a successful deposit record and a failed one, each with its own id, a status that moves in named steps, and the rail reference. Matching them to your ledger is virtual account reconciliation.
I score failure handling above price when I compare providers. A cheaper account that returns a rejected deposit with no reason costs more in support hours than the fee gap saves. I would run check 8 before check 10, every time, and drop any provider that cannot get me a written reason for a rejected or held deposit.
Failures come in three kinds. A hold is a compliance pause, an RFI (request for information), and it should say what is missing. A rejection ends the attempt and should say why. A late deposit arrives after the payment window closed, and the provider needs a rule for where it goes. Reconciling stablecoin transactions covers the matching.
On Lumx, settlement tracking is UETR and MT103 confirmations on every SWIFT payout, per-rail reference on every transfer, webhooks. An account moves from requested to provisioning to active, with an event for each step and for RFI, rejected and inactive. A customer RFI carries reject labels and a comment per document. For an account or a transaction on hold, Lumx compliance reaches out by email or Slack with what it needs, and a held transaction may be refunded to the sender if nobody answers within 24 hours. A deposit that lands after a single on-ramp has expired is refunded to the original sender on the same rail. The answering channel for a hold is operations@lumx.io.
Custody and third-party funds: who holds the money, and whose money is allowed
Two ownership questions sit under the account number. The first is who holds the money at each stage: the bank behind the account while it is fiat, and someone else once it is converted. The answer should name the party and the institution. The second is whose money may pass through. A provider that verifies every party will refuse accounts used to collect for businesses it never onboarded, so get that policy on paper first. Also ask which screening runs on each party, and where prohibited activities are listed (supported countries is one place to look). Licensing sits in the provider-level checklist, and the B2B case in named virtual accounts for collections.
On Lumx, the banking partners behind an account hold the fiat and execute the rails, and Lumx orchestrates provisioning and verification. After conversion, Lumx holds the stablecoin in each approved customer's custodial wallet, one per supported blockchain. Screening is KYC via Sumsub and KYT via Chainalysis. Every transaction ties to an onboarded customer, nested structures need written approval from compliance, and a marketplace onboards each seller as a customer.
Conversion, limits and price: the numbers that surprise teams later
Conversion decides when money turns into a stablecoin: some providers convert each deposit on arrival, others wait for a person. Ask the rate type.
Every provider caps what one customer can move, by verification level, so ask for the numbers. Regulation can add a cap no provider controls: Bre-B has a ceiling of 1,000 UVB (Unidad de Valor Básico, a Colombian inflation-indexed unit) per transaction, COP 12,110,000 for 2026, under Banco de la República's Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2, sheet of March 31, 2026. It applies to every provider, so never accept it as a selling point. On price, ask for the fee types: platform or monthly fee, per-deposit fee, FX markup, payout fee and minimums, and whether a SWIFT wire can pick up intermediary-bank fees the invoice does not show.
On Lumx, an autoconversion rule converts every fiat deposit that lands in an account to stablecoin with no per-deposit call, always at the market rate. A locked quote exists only on a single on-ramp. Default limits are in the table below. Pricing is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans.
What are the red flags when you evaluate a virtual account provider?
"We cover Latin America" with no list of rails per currency (check 2).
"Instant named accounts" with no mention of review: pooled, or reviewed later (checks 1 and 3).
No answer to "in whose name, at which institution?" for the fiat and for the converted balance (check 5).
A hold or rejection with no reason you can get in writing (check 8).
Fees that appear only on the invoice, never on the deposit record (check 10).
One bank behind every account, with no plan if that bank exits.
Scoring the answers, and the answers that end the call
Score each check 0 when the provider gave no written answer, 1 when it answered but you could not test it, and 2 when the answer passed your test. A 0 on check 1, 5 or 8 disqualifies whatever the total says, because the name, the custodian and the failure path cannot be fixed after launch. Then double the checks your business leans on.
Which checks to double, by business model.
Business model | Double these checks | Why |
Marketplace or platform collecting for sellers | 1, 7, 11 | Each credit belongs to one seller, and the third-party policy shapes the design |
Payroll or contractor platform | 6, 9, 10 | Funding converts in bulk, so rate type and limits drive the economics |
Neobank or wallet app | 3, 4, 8 | Onboarding time and review scope are the user experience |
B2B collections | 2, 7, 12 | Payers choose the rail, and finance lives in the records |
When a virtual account provider is the wrong choice
If your payers pay by card, a virtual account is the wrong tool, because it receives bank transfers. If you only send money out, skip it.
What the 12 checks return when you run them 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 table runs the checklist on Lumx (comparison pages), from the accounts documentation and the webhooks documentation, read on November 1, 2026, and from the product page.
Lumx against the 12 checks.
# | Check | Lumx |
1 | Account name | Issued by a banking partner in the customer's name, USD, EUR and GBP included. Exception: a COP account for a customer outside Colombia shows the banking partner |
2 | Rails per currency | Collects: BRL over Pix, MXN over SPEI, COP over PSE and Bre-B, USD over ACH, Fedwire and SWIFT, EUR over SEPA, GBP over Faster Payments. COP pays out over Bre-B or ACH Colombia; PSE collects only |
3 | Opening time | Active right after customer approval for BRL, MXN, EUR, GBP and COP, up to one business day for USD |
4 | KYB scope | Formation documents, representatives, owners above 25%, proof of address within 90 days, transactional information. Review target of one business day |
5 | Custody | Fiat held by the banking partners behind the account. After conversion, Lumx holds the stablecoin in the customer's custodial wallet. Screening is KYC via Sumsub and KYT via Chainalysis |
6 | Conversion | Autoconversion rule for every deposit, at market. Locked quote on a single on-ramp |
7 | Reconciliation data | Per-rail reference on every transfer, status events for each step, webhooks |
8 | Failure handling | Events for RFI, rejected and inactive. Customer RFI carries reject labels and a comment per document. Account and transaction holds go through compliance on email (operations@lumx.io) or Slack, which gives the reason; a held transaction may be refunded after 24 hours without a reply. A deposit after a single on-ramp has expired is refunded to the original sender on the same rail |
9 | Limits | KYB Standard $50,000 per transaction and $100,000 per day and per month, counted per transaction type |
10 | Price | Monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans |
11 | Third-party funds | Every transaction ties to an onboarded customer, and nested structures need written approval. Third-party collections are allowed, and an unusual one can trigger an RFI. Marketplace sellers are customers |
12 | Test and exit | The sandbox is open and self-serve, with every currency enabled. The sandbox quickstart simulates a deposit for an autoconversion rule or a regular on-ramp with no bank transfer, and an invalid destination is rejected. An account moves to inactive when it is closed or its customer becomes inactive, with an account.inactive event |
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Belov Sergey on Unsplash.
How do I choose a virtual account provider?
Run the twelve checks in the table above and write down each answer. Score each from 0 to 2, and treat a 0 on name, custody or failure handling as a disqualifier. On Lumx, BRL and MXN accounts are named, USD accounts open in up to one business day, and every deposit surfaces as webhook events you can match to your ledger.
Can I switch virtual account providers later?
Yes, but plan for it. Switching means issuing new accounts and asking every payer to update their details, so key your ledger on your own customer ids. On Lumx, each account is tied to one customer and one currency, the account.active event tells you when a new account can receive funds, and an account moves to inactive, with an account.inactive event, when it is closed or its customer becomes inactive.
Do I need my own bank to offer virtual accounts?
No. The provider brings the banking relationships, and you bring verified customers and a clear purpose for each account. On Lumx, the accounts are issued by banking partners that hold the funds and run the rails, and Lumx handles provisioning and verification through the API.
Should one provider handle the whole flow?
One provider means one ledger and one webhook stream, which simplifies reconciliation, but a single review or outage then reaches every stage. Run the checks per stage however you split it. On Lumx, one API covers the flow from collection to payout, with named virtual accounts, custodial wallets and KYB/KYC built in.
What compliance documents will I need for virtual accounts?
Expect KYB for each business customer and KYC for each individual, plus the purpose of the account, expected volume and source of funds. On Lumx, the KYB asks for formation documents, representatives, owners above 25%, a proof of address issued within 90 days, and transactional information, with a review target of one business day. If the account moves to RFI, the account.rfi event fires and Lumx compliance reaches out with the specific information needed. A customer RFI carries reject labels and a comment per document.
