A recipient gets less when the amount credited to their bank is lower than the payer expected, and the cause is almost always one of eight: the rate moved, a floating quote drifted, fees came off, the payer fixed the wrong side, rounding, a bank deduction, a wire intermediary, or a payout still in flight. The receipt shows which.
What are the eight reasons a recipient gets less?
Take a payout of reais over Pix (Brazil's instant payment system, run by the Central Bank). The payer typed one number and the statement shows another.
The eight causes of a short payout, what the customer says, where to look and who fixes it.
# | Cause | What the customer says | Where to look | Who owns the fix |
1 | The market rate moved | "The rate was better this morning" | Time of the quote against the time of the rate they saw | Payer, with an explanation |
2 | A floating quote drifted | "The estimate said more" | Quote type, base rate against final rate on the receipt | Payer's product, which should lock |
3 | Fees came off the amount | "They got less than the number I typed" | The fee lines in the quote and the receipt | Payer, by showing fees before confirm |
4 | The payer fixed the wrong side | "They had to get exactly BRL 5,000" | Whether the request fixed the source or the target amount | Payer's product |
5 | Rounding | "It is a few cents off" | Receipt amount against a recomputation | Nobody, usually closed as expected |
6 | The recipient's bank | "My statement shows less" | Final target amount against the credit line | Recipient's bank |
7 | A SWIFT intermediary | "The wire arrived short" | UETR and the MT103 confirmation | The intermediary chain |
8 | The payout is in flight or held | "Part of it is missing" | Transaction status and any hold | Payer or provider compliance |
Causes 1 to 4 are set by how the payer's product asks for the payout, so a team can remove them. On Lumx, they are visible in the quote before the payer submits, and causes 6 and 7 are traced with the receipt and the rail reference. Network fees are in who pays the network fee.
Read the receipt before you reply
The first lookup is the quote joined to the payout. Four questions:
Does the bank credit equal the final target amount on the receipt? If yes, the payout paid what it promised and the ticket is about expectations.
Was the quote locked or floating? A floating quote is a reference, so the rate at execution can differ from the estimate.
Did the request fix the source amount or the target amount? A fixed source lets the local amount follow the rate.
Is the rail SWIFT? Then look for deductions after the payout left.
A "short" complaint can also be "not arrived yet", so read the status first. The statuses are in what a stablecoin off-ramp is.
On Lumx, the receipt on the offramp.success webhook carries the base exchange rate, the base target amount, the Lumx and partner fee objects, the final target amount and the final exchange rate, plus a transaction reference. Each fee object lists a rate, a flat amount, a total and a currency. The rate is a decimal on the receipt, so 0.005 is 0.5%, not 0.005 bps. One record answers questions 1 to 3.
Splitting a short payment: rate first, then fees, then cents
Do the arithmetic in a fixed order and stop when the gap is explained.
The example uses the daily PTAX sell rates, the Central Bank of Brazil's reference rate and not a traded price, with USD/BRL standing in for USDC/BRL and fees left out so the movement is visible. A payer sizes an invoice of BRL 100,000 on October 26, 2026, when the PTAX sell rate was 5.5007, and the payout executes on October 27, when it was 5.3346.
A short payment of BRL 100,000 split into its parts. The fee step is read from the quote, not computed here.
Step | Calculation | Result |
Expected amount | The invoice | BRL 100,000.00 |
USDC sent, rounded to cents | 100,000 / 5.5007 | 18,179.50 USDC |
Market movement | 18,179.50 x 5.3346 | BRL 96,980.36, a gap of BRL 3,019.64 (3.02%) |
Fee lines | Read from the quote's fee objects | Subtract from the line above |
Rounding | Unrounded USDC (18,179.5044) x 5.3346 | BRL 96,980.38, two cents above the rounded figure |
Residual | Bank credit minus the receipt's final target amount | Zero, or the bank took it |
If the residual is zero, the payout did its job and the gap sits in rows 3 to 5. If it is not zero, the difference may have happened after the payout left, and the next section says where. If nothing explains it, escalate with the transaction id, the rail reference and the receipt. The upstream fix is an exact-amount quote, priced on the USDC to BRL and USDC to MXN pages.
On Lumx, a locked quote returns the base target amount, the fee objects and the final target amount before the payer submits, so rows 3 and 4 can be shown on screen. The 30-second lock has no extra fee; the 1-minute and 5-minute locks include one. The final target amount is all-in: it already counts the Lumx fees and the partner fee, which applies only when the request carries a partnerFeeId. How the fee lines are built is in how stablecoin payout pricing works.
Why a payout can differ by a few cents
A cent-level gap comes from two places, and neither is a missing payment.
Precision. In the Lumx docs' quote examples, USDC amounts carry six decimals and exchange rates four, while the receipt example shows two of each. Recompute a payout from a rate shown to four decimals and the last cent drifts. A true rate of 5.33464 shown as 5.3346 moves a payout of 18,745.55 USDC by about BRL 0.75 (an invented illustration).
Order of rounding. Rounding the USDC first, as in the table above, lands two cents from converting the unrounded amount.
The cure: store the receipt's amounts as strings and compare against those. A gap of a cent or two against a recomputation is expected. This post does not state Lumx's rounding rule or how it treats whole-peso COP, so confirm both before quoting them to a customer.
On Lumx, amounts travel as decimal strings, and the final target amount on the receipt is the figure to compare with the bank, not a number rebuilt from the rate.
Which deductions happen after the payout leaves?
Once the payout leaves the provider, two deductions remain: the recipient's own bank, and on a wire, the banks in between. Read the credit line against the receipt before concluding anything.
Who can reduce the amount after it leaves, by payout rail, as of November 1, 2026.
Rail | Currency | What Lumx takes from the amount that lands | Who else can reduce it | How the recipient checks |
Pix | BRL | No fee | The recipient's own bank | Compare the statement line with the receipt and the rail reference |
SPEI | MXN | No fee | The recipient's own bank | Banxico's CEP proof of payment, issued from the payment's date, tracking key, banks and amount |
Bre-B (Colombia's instant payment system) | COP | No fee | The recipient's own bank | Compare the statement line with the receipt |
SWIFT | USD | The fee lines on the receipt | Intermediary banks, which may deduct fees outside Lumx's control | The UETR, which every bank in the chain uses for the same payment |
Bre-B (Colombia's instant payment system) has a ceiling of 1,000 UVB per transaction, which is COP 12,110,000 in 2026. A payout above it is rejected, never split. Cut-offs are in payout limits and cut-offs by rail, and wires are compared in stablecoins vs SWIFT.
On Lumx, no fee is deducted from the amount that reaches the recipient on a Pix, SPEI (Mexico's interbank transfer system, run by Banxico) or Bre-B payout, and only the recipient's bank can charge them. SWIFT on Lumx runs in USD, every SWIFT payout carries UETR and MT103 confirmations, and every transfer carries a per-rail reference.
Nine reply macros that close the ticket
A good reply is short and ends with one action.
One reply per case. Brackets come from the quote, the receipt or the rail reference.
# | Cause | Reply |
1 | Market rate moved | "The payout used the rate quoted at [time], [rate], and [recipient] received [final target amount], the figure the quote showed. The rate you saw earlier was a market reference." |
2 | Floating quote drifted | "This payout was priced on a floating quote, which is a reference and can move before execution. The receipt shows [base rate] against [final rate]. For an amount that must not move, we can lock the quote." |
3 | Fees came off the amount | "The payout carried these fee lines: [fee lines]. They were part of the quote confirmed at [time]. [Recipient] received [final target amount]." |
4 | Wrong side fixed | "The payout fixed what we send, [source amount] USDC, so the local amount followed the rate. For an exact local amount we fix the receiving side instead." |
5 | Rounding | "The difference is [n] cents from rounding. The amount on the receipt, [amount], is the amount sent, and the bank credit matches it." |
6 | Recipient's bank | "We sent [final target amount] over [rail] with reference [reference]. Your bank shows [credit]. Your bank can confirm whether it applied a charge, using that reference." |
7 | SWIFT intermediary | "Wires can pass through intermediary banks that deduct fees. The payment's UETR is [UETR]. Any bank in the chain can trace it and show where the deduction was taken." |
8 | In flight or held | "The payout is at [status] and has not completed, so the full amount has not been sent. [If held: We need [document] to release it.]" |
9 | Residual unexplained | "We are checking this with the payout provider. Reference: transaction [id], rail reference [reference], receipt attached. We will reply with what they find." |
Promise no refund in any of them. A gap that traces to a rate or a bank is not an error; one nothing explains goes to macro 9.
I would answer every amount ticket from the receipt before writing a word, and I would keep the first reply to the numbers: the amount sent, the rate, the fee lines and the reference. I would not offer a refund or a credit in that reply, because a promise made before the lookup is one the team may have to retract. I would also tag every ticket with one of the eight causes, because a cause that keeps coming back is a product fix, not a support fix.
Show "you send", "they receive", the rate and each fee line before the payer confirms, and fix invoice and payroll quotes on the receiving side.
On Lumx, a locked quote can be requested on a source or a target amount, so the payer sees the final target amount before confirming. The transaction metadata field accepts any JSON object, so the quote id and invoice id can travel with the payout.
When a short payout is not an amount problem
Some "short" tickets are not about fees or rates.
The payout is still moving. An off-ramp runs from
TRANSFERRING_STABLECOINthroughTRADINGandTRANSFERRING_FIATtoSUCCESS, and untilSUCCESSthe recipient has not been paid in full.The payout is held. A transaction flagged by monitoring waits for an RFI (request for information, a compliance hold that asks for a document before a transaction clears), and the answer is the document, not a new quote. An RFI on any transaction left unanswered for 24 hours can end in a refund to the sender.
The payout failed. A failure arrives as
offramp.failed, and the reasons are in why stablecoin payouts get rejected.
On Lumx, each status change is a webhook. A held transaction is resolved with compliance over email or Slack. A held payout still settles at the quoted rate after the lock expires, because the fiat leg was already converted.
What a short-payment ticket 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.
Pricing is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. Rails and pairs are on the coverage page, the products on global payments, and COP payouts over Bre-B or ACH Colombia on USDC to COP.
Methodology and sources
Product behavior was read from the Lumx documentation on November 1, 2026: exchange rates, partner fees, transactions, destinations, webhooks, Request for Information, payment rail cut-off times, sender of record, coverage and the off-ramp API reference.
The PTAX sell rates (5.5007 on October 26, 2026 and 5.3346 on October 27) were read on November 1, 2026 from the Central Bank of Brazil's PTAX open data service. The arithmetic in the waterfall is computed here, and the 5.33464 rate is invented. The CEP proof of payment is on Banco de México's CEP page.
The Bre-B ceiling is the 1,000 UVB limit in Banco de la República's Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2, sheet of March 31, 2026, cited without a link. COP 12,110,000 is the 2026 value of 1,000 UVB.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Why did my recipient get less than expected?
Usually one of eight things: the market rate moved, a floating quote drifted, fees came off the amount, the payer fixed the sending side, rounding, the recipient's bank charged a fee, a SWIFT intermediary deducted in transit, or the payout had not finished. The quote and the receipt show which. On Lumx, the receipt on the off-ramp success webhook carries the base and final rate, the Lumx and partner fee amounts and the final target amount, so the first lookup is one record.
Can the rate change after the payer confirms a quote?
Not on a locked quote. A lock holds the rate for its window, while a floating quote is a reference that can move before execution. On Lumx, a locked quote lasts 30 seconds, 1 minute or 5 minutes, the 30-second lock has no fee, the longer ones include one, and the clock starts at creation, with the expiry in UTC. After expiry the payer requests a new rate, with a new exchange rate id.
Do fees come out of the amount the recipient receives?
Fees in the quote come out of the payer's side or the converted amount, and the receipt lists them line by line. The recipient's own bank is the other place a charge can appear. On Lumx, no fee is deducted from the amount that reaches the recipient on a Pix, SPEI or Bre-B payout, and the Lumx fee and the partner fee are separate lines in the quote, already counted in the final target amount.
Why is my payout off by a few cents?
Because of precision and the order of rounding. Rates show four decimals and USDC six. Compare the bank with the receipt, not a recomputation. On Lumx, amounts are decimal strings and the final target amount on the receipt is the number to match against the bank.
How do I prove what amount was sent?
Start from the quote and the receipt, then add the rail reference. On SPEI the recipient can download Banxico's CEP proof of payment, and on a wire the UETR lets every bank trace the same payment. On Lumx, every transfer carries a per-rail reference, every SWIFT payout carries UETR and MT103 confirmations, and webhooks report each status change.
