A virtual account deposit that has not been received is usually in one of four states: still in transit on its rail, held for compliance review, returned to the payer, or received but not matched to the account or rule. The deposit's status and the payer's rail reference show which one.
This guide is organized by symptom, then by rail, for teams that run named virtual accounts for their own customers. A deposit on hold usually comes with an RFI (request for information, a compliance hold that asks for a document before a transaction clears). The product is on the named virtual accounts page.
Match the symptom before you open a ticket
Symptoms of a missing virtual account deposit, with the likeliest cause and the first thing to check.
Symptom | Likeliest cause | First check |
The payer says it was sent and nothing shows, inside the rail window | In transit, or sent after the cut-off | The rail window table below |
Nothing after the full window | Wrong details, wrong rail, or the transfer never left the payer's bank | The payer's receipt and its reference |
The deposit is visible but nothing was converted or credited | Account not active yet, amount under the minimum, reference not matched, or the collection expired | Account status, amount, reference, expiry |
The deposit is under review | A request for information (RFI) from compliance | Email or Slack from compliance, and the 24-hour clock |
The money went back to the payer | Expired collection, unanswered hold, or a bank-level rejection | The return reason, which you ask for in writing, then a new collection |
Less arrived than was invoiced | Intermediary fees, or conversion to a stablecoin | The receipt or the MT103 |
How long should a deposit take on each rail?
Longer than the payer expects on bank rails, and instant on Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's interbank transfer system, run by Banxico). Anything sent after a cut-off or on a bank holiday waits for the next business day.
Cut-off and settlement target by rail, from the Lumx documentation read on November 1, 2026.
Currency | Rail | Cut-off (local time) | Settlement target |
BRL | Pix | None, runs 24/7/365 | Instant |
MXN | SPEI | None, runs 24/7/365 | Instant |
EUR | SEPA | None | SEPA Instant, or SEPA Credit Transfer same or next business day for 100,000 euros or more between 4:30 PM and 2:30 AM UK time |
GBP | Faster Payments | None, runs 24/7/365 | Instant, up to 1 million pounds per payment |
USD | ACH | 2:00 PM ET | 1 to 2 business days |
USD | FEDWIRE | 3:00 PM ET | Same business day, typically within hours |
USD | SWIFT | 3:00 PM ET | 1 to 5 business days, subject to intermediary bank hours |
A Pix or SPEI deposit missing after a few minutes is not inside a settlement window, because those rails have none, so the cause is on the payer's side, in matching, or a compliance hold.
Bre-B (Colombia's instant payment system) is instant, like Pix, and the Lumx cut-off page publishes no cut-off for it. On Lumx, paste the payment rail cut-off times into payer instructions, so the expectation is set before the money moves.
Why a deposit arrives but is not credited
Five things cause a deposit that shows on the payer's receipt but not in the ledger.
The account is not active. A named account waits for verification, then moves through requested and provisioning. Show payment details only after the account-active event.
The amount is under the minimum. The 50 USD floor applies to every deposit, and a deposit under it is never converted.
The reference did not match. A standing rule matches deposits by an identifier. On Pix it is embedded in the payment code, so a payer who scans or pastes the code carries it. On SPEI the payer types it as the memo next to the CLABE (the 18-digit Mexican bank account number), and a memo mistyped or left blank is the first thing to check. An MXN account can hold several rules, and the memo picks the rule. A SPEI payment without a memo still lands on the account and converts at a floating rate, with no rule applied. USD, EUR and GBP deposits are matched to the account instead, which is why those accounts take one active rule at a time. With no active rule and no on-ramp, the fiat stays on the account.
The collection expired. A per-invoice collection has a payment window, and a deposit that lands after it is not processed.
The deposit is above the limit. A deposit over the customer's on-ramp limit is held as a balance and not converted.
For a deposit that matches nothing, check the account status and send operations the account id and the payer's reference.
On Lumx the window is the quote's own expiry for a locked rate, 1 day for a floating Pix or SPEI collection and 7 days for a floating collection on other rails. A deposit under the 50 USD minimum goes to operations at operations@lumx.io. Only a deposit matched to a rule or a collection runs as a stablecoin on-ramp, so only a matched deposit produces onramp webhook events, from onramp.transferring_fiat to onramp.success, or onramp.expired and onramp.failed when it stops. Silence in the webhooks does not prove the money never arrived, and the account status plus a message to operations is the way to find it.
Why a deposit is held for review or returned
A hold is a pause, not a rejection: monitoring flags the deposit, and compliance releases it or asks a question. A first deposit from a payer, an amount out of pattern, or a payer name that differs from the invoice makes a reviewer ask who the sender is to the customer. RFIs come at three levels.
The three levels of RFI, what each pauses, and how it ends.
Level | What is paused | How it ends |
Customer | The KYB or KYC review | Resubmit documents, announced by webhook, and start a new verification |
Account | Provisioning of a virtual account | The answer goes back by email or Slack, then the account is active or rejected |
Transaction | One deposit or payout flagged by monitoring | The answer to compliance by email or Slack, then release or not |
If nobody answers within 24 hours, the transaction may be refunded to the sender, and the payer has to pay again against a new collection. The 24-hour window applies to every transaction. A limit increase is not a transaction RFI, unless it is a requirement to approve a transaction. Customer RFIs already have webhooks, but only for documents: an open question, such as one about how the business works, still goes by email or Slack. An API for account RFIs is due this year, and one for transaction RFIs between the end of 2026 and the first quarter of 2027.
I recommend that a client names one person who owns compliance holds before its first account goes live, and writes that person's name next to the 24-hour window in its runbook. The answer is usually a document it already has, such as an invoice or a line saying who the payer is to the customer. I would also have support answer a missing-deposit ticket from the status, never from the payer's screenshot, since a screenshot only proves the payer pressed send.
The customer-level review behind all this is a KYB (know your business, the verification of a company and its owners) file, explained in what KYB involves. On Lumx, holds reach the client by email or Slack with the transaction details. The purpose on a collection is a required field because banking partners use it for screening.
Why a deposit is returned
Why a deposit is returned, who returns it, and what the retry needs.
Reason | Who returns it | What the retry needs |
The collection expired before the money arrived | The provider, over the same rail | A new collection |
A hold went unanswered for 24 hours | The provider, to the sender | The answer, then a new collection |
Wrong account details, a closed account, or a beneficiary name the bank rejects | The payer's bank or the receiving bank | Corrected details from the payer |
The payer used a rail or currency the account does not take | The payer's bank, or the provider | The details for the right rail |
The name row needs one more sentence. A named account carries the customer's own legal name, and a payer's bank may check the beneficiary name against it. A buyer paying through a group treasury entity hands the receiving side a name it does not expect. Lumx permits third-party collections (COBO), but an unusual payer can trigger a hold and, as a result, a prompt return. Pooled and named accounts attribute money differently.
A USD account takes ACH credit, FEDWIRE and SWIFT, a BRL account takes Pix, and a MXN account takes SPEI. A EUR payer uses the IBAN of the EUR account (countries and rails Lumx covers).
On Lumx, a late deposit on an expired collection is refunded to the original sender on the same rail, and the retry is a new on-ramp.
How to trace a payment with the payer's bank
Trace with the payer's reference, never with the amount, because a bank's operations team can search by one and not the other. Check the details the payer used against the account for that rail, since a USD account has separate ACH and wire details.
On Pix, the payer's receipt carries an end-to-end identifier that the payer's bank can look up.
On SPEI, the payer's bank issues a tracking key, and Banxico's CEP service builds the electronic payment receipt from it.
On FEDWIRE, the Federal Reserve's funds transfer service, the sending bank's wire confirmation is the reference to quote.
On SWIFT, it is the UETR, a UUID that travels with the payment (36 characters with hyphens, per RFC 4122), plus the MT103 that shows the beneficiary and charges.
On the other rails (Bre-B, PSE, ACH, SEPA and Faster Payments), the receipt reference from the payer's bank is what the bank searches by.
Then send the provider one message with the account id, the amount, the date sent and the reference.
On Lumx, a UETR and an MT103 confirmation come with every SWIFT payout, and a per-rail reference comes with every transfer. For a missing deposit, the client checks the account status, looks at the onramp events if the deposit was matched, and writes to operations@lumx.io with the details above.
Why less money arrived than the payer sent
On wires and SWIFT, banks in the chain can deduct fees before the money lands, and the charge option the payer's bank chose decides who bears them. The MT103 shows which option was chosen. When the deposit converts to a stablecoin, there is a second cause that surprises finance teams: what arrives is the converted amount, net of the rate and any fee, not the invoice figure. A USDC wallet balance will not match the invoice, so book the conversion as its own line, as reconciling stablecoin transactions explains.
On Lumx, the receipt on a successful conversion carries the amounts, the rate and the fees, so the gap is itemized per deposit.
What if a stablecoin deposit has not arrived?
A stablecoin deposit fails differently. A stablecoin sent on the wrong network, or a token the address does not hold, is not a bank problem and no bank can recall it, so check the network and the token against the receiving address, then the block explorer.
On Lumx, every customer has a wallet address on each of Ethereum, Polygon, Base, Tron and Stellar, holding USDC or USDT depending on the network, and anyone can send supported stablecoins to it. Each wallet carries a block explorer link, so send to the address on the network it belongs to and check the link. A webhook for a deposit from an outside wallet is coming, so for now you read the balance.
When a named virtual account is the wrong tool for the deposit
Three cases: a business that wants to pool funds from several parties in one account, a one-time payer (a per-invoice collection is easier to match and close), and small deposits under the minimum. Collecting B2B payments through named accounts compares the standing and per-invoice modes.
On Lumx, pooling funds that belong to parties that are not onboarded is a nested structure, which needs the written approval of compliance, so a marketplace onboards each seller as its own customer and takes its platform fee through a partner fee.
What a held or missing deposit looks like on a Lumx account
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.
A Lumx virtual account is issued by a banking partner for the customer and tied to one currency, and it supports every rail the partner offers for that currency. BRL, MXN, EUR, GBP and USD accounts are in the customer's name, and a COP account carries the customer's name only for Colombian customers. BRL, MXN, EUR and GBP accounts activate right after approval, and USD accounts wait up to one business day for the partner bank. A COP account receives through a Bre-B key on the account, with PSE (Colombia's online bank transfers) as the other form of collection.
When a deposit is missing, the account status says whether it can receive, the onramp webhook events say where a matched deposit is (an unmatched one produces none), an RFI by email or Slack says a person is looking at it, and a refund on the same rail says the collection expired or the hold went unanswered. The Request for Information and Accounts pages cover both.
Methodology and sources
Read November 1, 2026: Lumx's Accounts, Transactions, Request for Information, Autoconversion Rules, Webhooks and Nested Payments pages, plus cut-offs. The UETR format follows the UUID definition in RFC 4122, the Fedwire description follows the Federal Reserve's page, the wallet networks follow the Stablecoin Wallets page, and the SPEI receipt follows Banxico's CEP page.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Pauline Bernfeld on Unsplash.
Virtual account deposit not received: what should you check first?
Check the rail window and the deposit's status first. Pix and SPEI settle instantly, so a deposit missing after a few minutes points to wrong details, a matching problem or a compliance hold, while ACH, FEDWIRE and SWIFT can take from the same day up to five business days. On Lumx, check the account status and the onramp webhook events (which exist only for a matched deposit), then email or Slack for an RFI, then write to operations.
How long does a virtual account deposit take to arrive?
Pix, SPEI, Bre-B and Faster Payments are instant, FEDWIRE settles the same business day, ACH takes 1 to 2 business days and SWIFT 1 to 5, and anything sent after the cut-off waits for the next business day. On Lumx, the published cut-offs are 2:00 PM ET for ACH and 3:00 PM ET for FEDWIRE and SWIFT, and they are targets rather than commitments.
Why is a virtual account deposit on hold?
Transaction monitoring flagged it and compliance is reviewing it. On Lumx, compliance reaches out by email or Slack, and a transaction not answered within 24 hours may be refunded to the sender.
Why was a virtual account deposit returned?
An expired collection, a hold nobody answered, wrong details or a closed account, or a rail or currency the account does not take. The money goes back to the sender. On Lumx, a deposit that lands after its collection expired is refunded to the original sender on the same rail, and the retry is a new on-ramp.
