Best execution for stablecoin payouts means getting the best total result on each conversion, not the tightest rate: the amount the recipient receives after every fee, the time to funds and the odds that the payout settles on the first try. For payouts it is an operator's standard that you set and prove, not a legal duty.
This guide gives a scorecard to compare providers with test payouts and six metrics to run after launch. How stablecoin payout fees work covers fee mechanics.
What does best execution mean for a stablecoin payout?
It means judging a conversion on six factors at once, because a good rate on a payout that fails or arrives late is a bad result. Price and costs set how much arrives; speed and settlement set when and whether; size and nature decide which matters most.
The six factors of a payout, how each is measured and where the number comes from on Lumx.
Factor | What it means on a payout | How to measure it | Where it lives on Lumx |
Price | The rate you got against the market rate | Mid-market value minus amount received, over mid-market value, with the reference captured at the quote minute | baseExchangeRate and finalExchangeRate on the locked quote, rate on the receipt |
Costs | Every fee line, plus network and bank costs | Fee lines as a share of the base target amount | fees.lumx and fees.partner on the receipt, fees.total on a locked quote |
Speed | Time from execute to money at the recipient's bank | Creation time to success event | createdAt, offramp.trading, offramp.transferring_fiat, offramp.success |
Likelihood of settlement | Share of payouts that land on the first try | Successes over successes plus failures, per rail | offramp.success and offramp.failed |
Size | Whether the price holds at your amount | The same payout at three sizes | sourceAmount |
Nature | Who is waiting and how much it matters | A payout category in your own ledger | the purpose field and the metadata object |
On Lumx, a locked quote (POST /exchange-rates) returns baseExchangeRate, finalExchangeRate, the fee lines with fees.total, and expiresAt. The receipt on offramp.success is slimmer: rate, sourceAmount, targetAmount, fees.lumx and fees.partner. Measure price and cost from those against a reference you capture yourself; the metadata object tags each payout with its category.
Where the term comes from and where it stops
The phrase comes from securities regulation. Article 27 of MiFID II (Directive 2014/65/EU of May 15, 2014) tells investment firms to "take all sufficient steps to obtain, when executing orders, the best possible result for their clients taking into account price, costs, speed, likelihood of execution and settlement, size, nature or any other consideration relevant to the execution of the order" (per the ESMA Interactive Single Rulebook, read on November 1, 2026).
That duty is written for orders in financial instruments. A payout is a payment, so the rule does not reach it by default.
The wholesale market has its own text. The FX Global Code, last updated in December 2024, sets good practice for foreign exchange and says on the Global Foreign Exchange Committee site that it imposes no legal or regulatory obligations. A treasurer can still ask providers whether they have published a commitment to it.
How do you score providers with test payouts?
Run the same payouts through every shortlisted provider and score what happened, because a sales-call quote is not evidence. Fix the corridor, the weights and a reference rate source first, and capture the reference at the minute each quote is created. Use one named, timestamped mid-market source for every provider; a provider's own rate page cannot be its yardstick. Spread math and market makers explain the price scored.
Use three sizes (the smallest payout you make, a typical one and the largest you expect), two times of day (one well inside the rail's cut-off and one after it or on a weekend) and each stablecoin the provider offers on the corridor, usually USDC and USDT. That makes 12 payouts per provider and corridor, the smallest set that fills every cell once. It compares price and timing but cannot rank reliability: 11 of 12 against 12 of 12 is noise, and only the post-launch metric over real volume shows settlement. USDC and USDT compared for payments covers why the two can price differently at the same size.
Eight criteria, the test for each and what a top score looks like. The steps are placeholders: set your own first.
Criterion | Test | A 5 looks like (placeholder) |
Effective cost | Mid-market reference against amount received, at each size | Lowest on the shortlist, one point off for each extra 10 bps |
Fee transparency | Is every fee line on the quote before you execute? | Every line is itemized on the quote |
Time to funds | Creation to success, at two times of day | Median inside the provider's stated target for the rail |
First-try settlement | Successes out of the 12 payouts | All 12 reach success |
Size depth | Effective cost at the largest size against the smallest | One point off for each 10 bps added at the largest size |
Rate certainty | Can you lock the rate, for how long and at what cost? | A lock that covers your approval time |
Counterparty disclosure | Who provides the liquidity? | Named by category in writing |
Settlement evidence | What does a completed payout return that you can match to a bank record? | A reference on every payout, plus webhooks |
Try the mechanics first in the Lumx sandbox (api-sandbox.lumx.io) and score rate and timing on small production payouts. On Lumx, a floating estimate carries no fee, so quotes at each size cost nothing to collect. A locked rate lasts 30 seconds, one minute or five minutes: the 30-second lock has no fee and the longer ones include a fee for volatility risk. Lumx converts with its own liquidity and institutional counterparties only, BTG Pactual among them.
Weigh cost against speed once, by payout type
Write the ranking down per payout type before any quote arrives, then apply it every time. The scorecard weights come from it.
A starting ranking by payout type. Change the order only if the reason changes.
Payout type | Rank first | Rank second | Why |
Payroll | Likelihood of settlement | Speed | People are waiting and a failure is visible the same day |
Supplier on 30-day terms | Cost | Likelihood of settlement | The terms already pay for the time |
Refund | Likelihood of settlement | Speed | A second attempt is the expensive part |
I would set the weights before the first test payout and keep them fixed. A scorecard filled in after the quotes arrive tends to turn into a defense of the cheapest one. I also put settlement certainty above cost for any payout a person is waiting on, because a failed payout costs a second quote, a support ticket and a recipient who stops trusting the payment.
Providers A and B are placeholders with illustrative scores, weighted for a supplier payment where cost leads.
Illustrative scoring on a 0 to 5 scale. A wins on cost and loses the total.
Criterion | Weight | Provider A | Provider B |
Effective cost | 40 | 5 | 4 |
First-try settlement | 25 | 3 | 5 |
Time to funds | 10 | 2 | 5 |
Size depth | 25 | 4 | 3 |
Weighted score out of 100 | 79.0 | 82.0 |
Each total is the sum of weight times score, divided by five.
Which six metrics measure execution after launch?
Six numbers, reviewed per corridor and per rail, carry the test into production.
The six metrics, the formula for each and the Lumx field it reads from. Review monthly unless the last column says otherwise.
Metric | Formula | Lumx source | Review |
Effective cost | (mid-market value minus amount received) over mid-market value, in bps | targetAmount on the receipt, plus your reference rate | Monthly |
Fee share | Lumx and partner fee totals over the receipt's source amount | fees.lumx and fees.partner on the receipt | Monthly |
Quote drift | Floating: estimate rate minus receipt rate, over the estimate rate, before fees. Locked: lapsed locks over locks requested | targetAmount and sourceAmount on the floating estimate, rate on the receipt, expiresAt on the lock | Weekly |
Time to funds | Success event time minus creation time, median and 90th percentile | createdAt and the arrival time of offramp.success | Monthly |
First-try settlement | Successes over successes plus failures, per rail | offramp.success and offramp.failed | Monthly |
Stuck age | Time in a non-final status (TRANSFERRING_STABLECOIN, TRADING, TRANSFERRING_FIAT), by status | updatedAt and status of each transaction | Daily |
Quote drift has two readings. On a floating quote it is the gap between the estimate rate you showed and the receipt rate, measured before fees so it does not double-count Effective cost. On a locked quote the fill matches the lock, so watch how often a lock lapsed unused, which says the approval step is slower than the window. An expired lock is replaced by a new request, and a payout ends as a success or a failure. A compliance hold, an RFI (request for information), shows up as a payout that stops moving; the cut-off section below covers it. How long a payment quote lasts covers the window itself.
Illustrative arithmetic, not any provider's quote. A 10,000 USDC payout, a mid-market reference of 5.2000 BRL per USDC and a mid-market value of 52,000.00 BRL. The recipient receives 51,636.00 BRL, so effective cost is (52,000.00 minus 51,636.00) over 52,000.00, which is 0.70%, or 70 bps.
On Lumx, each status change emits a webhook with an eventId, and the webhook-id header lets you deduplicate a repeated delivery. Failed deliveries are retried over eight attempts, so stamp each event with your own arrival time.
Records that prove the result
A fair result needs the provider's records and the market at the same minute. For each payout keep the quote or lock ID and expiry, the base and final rates, every fee line, the amounts sent and received, your reference rate with its source and time, any competing quote from the same minute, and the final status with any error object. Accounting needs another shape: reconciling stablecoin transactions.
On Lumx, the quote and the receipt carry the rate and fee fields, the transaction carries your metadata, and the receipt of a completed payout has the transaction hash and block explorer link. A failed payout carries an error object in its state, so store it whole.
When a best-execution scorecard is the wrong tool
Skip the full protocol when you pay a handful of times a year: twelve test payouts cost more than the spread saved.
A quote that expires in minutes cannot protect an invoice due next month; that takes a forward contract from your bank or FX broker. Retest when volume jumps, a new corridor opens or a metric drifts for weeks.
If the recipient must receive an exact amount, test it differently. On Lumx, a locked rate can be requested on the target amount, so ask for the exact amount to land and score the source amount you would pay.
What this looks like on a USDC payout to Brazil over Pix
A payout to a company in Brazil over Pix (Brazil's instant payment system, run by the Central Bank) shows the scorecard on one transaction. 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 platform requests a locked rate for the payout and stores the returned id and expiry along with the rates and fee lines. It then creates the off-ramp with that exchangeRateId and the destination's ID, or sends a floating request with the source amount when the payment does not need a fixed price. The statuses run from TRANSFERRING_STABLECOIN through TRADING and TRANSFERRING_FIAT to SUCCESS, each with its own offramp event, and the success event carries the receipt. The Brazil conversion page shows the pair, and the global payments product page shows the flow.
Lumx does not deduct a fee from the amount that arrives at the recipient on a Pix payout, and only the recipient's bank can.
Per the Lumx cut-off page, Pix has no cut-off and runs every day of the year, so on Pix the second time of day in your test is a night or weekend run. The cut-off test applies to the USD rails: ACH cuts off at 2:00 PM ET, FEDWIRE (the Federal Reserve's same-day wire system) at 3:00 PM ET and SWIFT at 3:00 PM ET, with SWIFT taking one to five business days. The page calls these targets, not contractual guarantees, and a payout held for an RFI (request for information, a compliance hold that asks for a document) waits for review. Cut-offs and limits by rail lists them by rail.
For settlement tracking, Lumx returns UETR and MT103 confirmations on every SWIFT payout, per-rail reference on every transfer, webhooks. SWIFT on Lumx is USD only, and the SWIFT comparison explains when a stablecoin payout is the better route. Lumx's pricing model is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. No pre-funding means no capital parked in settlement accounts before a payment, because conversion and settlement happen when the payout starts. The basics are in what USDC is and what a stablecoin off-ramp is, and the coverage page lists rails by currency.
Methodology and sources
Read on November 1, 2026: the Lumx docs on exchange rates, transactions, webhooks, partner fees and cut-off times, the off-ramp API reference and the production OpenAPI file; Article 27 of MiFID II on the ESMA rulebook; and the FX Global Code page of the Global Foreign Exchange Committee. Weights, score steps and the worked example are illustrative, not Lumx data.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Lucas Santos on Unsplash.
What is best execution for stablecoin payouts?
Best execution for stablecoin payouts is the best total result on each conversion: what the recipient receives after every fee, how fast it arrives and how likely it is to settle on the first try. It borrows its factor list from MiFID II, but for payouts it is a standard you set, not a legal duty. On Lumx, the quote and the offramp.success receipt carry the rate and fee fields to measure it.
Is best execution a legal requirement for stablecoin payouts?
Not by default. Article 27 of MiFID II covers investment firms executing orders in financial instruments, and a payout is a payment. A written policy with quote records is what a reviewer can check. On Lumx, those records come from the quote and the receipt, and the policy stays yours to write.
How do you compare stablecoin payout providers on execution quality?
Run the same 12 test payouts with each provider (three sizes, two times of day, each stablecoin on offer) and score eight criteria with weights fixed beforehand. Compare the largest size with the smallest to see whether liquidity is deep or thin. On Lumx, conversion uses its own liquidity and institutional counterparties only, with no volume figures published, so the size test is the check; a floating estimate carries no fee, so quotes at each size are cheap to collect.
How do you measure the gap between the quoted rate and the rate you got?
On a floating quote, compare the estimate rate you showed with the rate on the receipt, before fees; the gap is drift, because the rate is a live reference with no lock. On a locked quote the fill matches the lock, so measure how often locks lapse unused instead. On Lumx, a floating rate may vary slightly at execution, a locked rate settles at the quoted rate when you pass its exchangeRateId, and an expired lock is invalid, so you request a new one.
Which records prove a payout got a fair result?
Keep the quote or lock ID and expiry, the rates, every fee line, the amounts sent and received, your reference rate with its source and time, and the final status with the error object from its state. On Lumx, store the transaction ID, the exchangeRateId, the receipt fields, the success or failed event and your metadata reference. SWIFT payouts also return UETR and MT103 confirmations.
