FX Policy for Stablecoin Payouts: Template and Cost Forecast

An FX policy for stablecoin payouts is a short internal rulebook that fixes in advance which routes you pay, which quote type you execute on, how far the live rate may drift from the approved estimate, who signs off at which size, and how much stablecoin you hold. It turns rate decisions into rules a second person can follow.

Every number below is an example, labeled "example, set your own", not a recommendation or a Lumx default. Definitions of spread and fees are in how stablecoin payout pricing works.

The policy template in eight clauses

Eight clauses of an FX policy for stablecoin payouts.

Each clause as policy wording you can copy and edit. Every value is an example, set your own:

> 1. Payouts leave only by approved routes: USDC to BRL by Pix, MXN by SPEI, COP by Bre-B or ACH Colombia, EUR by SEPA. > 2. Every payout executes on a locked quote, and the quote ID is logged. > 3. One approver under USD 25,000, two up to USD 250,000, two plus the finance lead above. > 4. A run returns to the approver when the locked rate has moved from the estimate by more than the route's tolerance, up or down: 50 bps on BRL and MXN, 75 on COP, 25 on EUR. > 5. Stablecoin held stays between 3 and 10 business days of payouts. > 6. Only USDC and USDT are approved; the policy owner pauses one that trades more than 50 bps under one dollar on the named intraday source for an hour. > 7. An expired quote is replaced, never retried; failed payouts are reviewed within 1 business day. > 8. The policy owner reviews numbers monthly and the document yearly.

A route is a currency pair on a rail, such as USDC to BRL by Pix (Brazil's instant payment system); see what a stablecoin corridor is. On Lumx, routes depend on the rails enabled for your project and customer, listed on the coverage page, and a COP payout runs on Bre-B (Colombia's instant payment system, launched in 2025) or ACH Colombia, whichever is registered on the destination.

Put a maximum per route next to the approval tier, since a tier does not replace a rail cap. A Bre-B payout above 1,000 UVB (about USD 2,870) is refused, not rerouted, because the rail is fixed on the destination (Banco de la República, Circular Reglamentaria Externa DSP-465, March 31, 2026 sheet). A larger COP payout must go to a destination registered on ACH Colombia. See payout limits and cut-offs by rail.

Two clauses need a mid, an independent market mid-rate: a rate from someone other than the party quoting you. The mid must be an intraday source you can time-stamp, such as your bank's or broker's mid or a market-data feed, because you compare it with a lock that lasts seconds. Name the source per route in the policy, so tolerance and quote cost use the same yardstick every month. Lumx documents a floating rate as a real-time reference with no price lock; the policy's mid is a separate, independent source.

Daily reference fixings suit month-end checks of your intraday source, not the same-moment comparison. The Central Bank of Brazil publishes PTAX under BCB Resolution 45 of November 24, 2020, Banco de México publishes the FIX exchange rate, and the ECB publishes its euro reference rates around 16:00 CET each working day.

How far may a quote drift before someone re-approves the run?

Drift is the move, in basis points (0.01%), between the rate the approver saw and the rate the run executes at. The tolerance is the band inside which a run proceeds without a second look.

For example, finance approves R$ 400,000.00 of salaries on an estimate of 5.5000 BRL per USDC, 72,727.27 USDC. When the run starts, the live quote reads 5.4780.

Worked drift check on a BRL run, illustrative rates only.

At 5.4340 the same run drifts 120 bps and needs 883.33 USDC more than approved. That is outside the band, so the run pauses and goes back to the approver. The approver sees a new estimate and the run restarts on a new locked rate (clause 7). A move in your favor is also drift, or operators learn to wait for the good side. Set the band per route.

On Lumx, the estimate comes from a floating rate and execution from a locked rate that returns a base rate and a final rate. Recording both on each run gives you the drift and the quote cost.

Floating, locked or standing rule: which quote does a run execute on?

Quote types on Lumx and their place in the policy. Source: docs.lumx.io, exchange rates and autoconversion rules, November 1, 2026.

A locked rate carries an exchangeRateId. You pass it on the transaction, and the transaction settles at the quoted rate. If the lock expires first, the ID is no longer valid and you request a new rate, which is clause 7: an expired quote is replaced, never retried.

The 30-second lock costs nothing but needs execution without a person in the loop. The longer locks cost a fee that buys time to confirm; for the general question, see how long a payment quote lasts.

An autoconversion rule converts every matching fiat deposit to stablecoin at market, with no locked quote, because a standing rule has no moment where someone accepts a price. Treat it as market execution and measure it against your mid afterward.

Float limits are a treasury control, not a rail limit

Clause 5 caps how much stablecoin you hold ahead of payouts, in days of payouts rather than dollars.

Float sizing from the forecast volume below (USD 750,000 over 21 business days). Example, set your own.

A stablecoin rule needs a trigger and an owner. The trigger measures the stablecoin's price against one dollar on your time-stamped intraday source, held for the stated time. The policy owner, not the operator on shift, lifts the pause; runs in flight finish on the quote they hold. This is policy, not a product feature.

On Lumx, deposits converted by an on-ramp or an autoconversion rule land as stablecoin in the customer's wallet, and the wallet holds stablecoin, not separate per-currency balances. So a limit per currency means days of payouts per currency, and an off-ramp larger than the wallet balance fails with an insufficient-balance error. See automating corporate treasury. Lumx also applies limits per transaction, per day and per month for each customer, separate from yours and readable with includeTransactionLimits=true. The example volume here assumes a limit increase request or Enhanced verification, since the default KYB (know your business) Standard limits are USD 50,000 per transaction and USD 100,000 per day and per month.

How do you forecast the monthly FX cost of payouts?

Budget per route with two lines: quote cost on every run, and an allowance for adverse drift.

The quote gap is the locked final rate against your intraday mid, read at the moment you request the lock, in basis points. It covers the Lumx fee, any partner fee and lock fee, and the source difference, and the quote cost is that gap applied to monthly volume. The gap between the base and final rates in a Lumx quote is the Lumx fee plus any partner fee and lock fee, with no FX margin built in, so the mid comparison adds whatever separates your source from the base rate. The drift allowance is the average adverse move between estimate and execution. Both start as placeholders; after month one, use your own quotes and log.

Monthly FX cost forecast for four routes. Volumes and basis points are illustrative placeholders, not Lumx prices. Replace them with your own quotes.

The total, USD 3,890 on USD 750,000, is 52 bps blended. The pricing model on Lumx is a monthly platform fee plus per-transaction fees, with a monthly minimum, so keep it on its own line. None of the basis points above is a Lumx fee.

Each month, put the budget next to actual cost per route. Whether you absorb or charge on the cost is covered in absorbing or passing on FX costs.

On Lumx, each locked quote returns a base rate and a final rate, and the gap between them is the fee layer. Compare the final rate with your mid, read at the time of the request, to get the quote gap per run. Conversion pages: USDC to BRL, USDC to MXN, USDC to COP, USDC to EUR; the BRL treasury side is in converting BRL to USDC for treasury.

Who may change the numbers

I would not let anyone widen a tolerance in the middle of a run. Whoever is looking at a paused payroll will find a reason the number is fine. If the drift is wider than the band, the run goes back to the approver, and the band changes in the monthly review, never during the run. I would also start every tolerance tighter than feels necessary, because the first month of data shows where the band belongs.

The float ceiling, approval tiers and token rule belong to the policy owner, and each change is logged.

What to measure each month and what auditors ask

Four numbers per route are enough: re-quote drift in bps, share of quotes that expired unused, delivery success rate, and cost per delivered dollar against the forecast.

Auditors ask for evidence that the policy runs: who can approve, sample runs with approvals, quotes and payouts, every exception and how it closed, and review notes. Keep the quote ID next to each executed payout, because it records the price you accepted. Name an owner for the quote log, and set a retention period for it that matches your own record-keeping rules.

On Lumx, webhooks announce each status change, so the system can write the log.

When a written FX policy is the wrong tool

If you pay out a few times a month on one route, a one-line rule does the job. The policy also cannot decide whether to hedge: a tolerance controls execution on the day, not a rate for a payable due in 90 days. That instrument comes from your bank or FX broker; see live quote versus forward contract.

How this policy runs 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 policy is your internal control: approval tiers, tolerance bands and float limits live in your own approval system. Lumx supplies what they act on: a floating rate for the estimate, a locked rate for execution, an exchangeRateId that ties a transaction to the accepted rate, and webhooks.

A run under this policy, on BRL by Pix: finance approves on a floating-rate estimate. At execution, the system requests a 30-second locked rate per payout, checks the drift against the route's tolerance, and proceeds or pauses for the approver. The locked-rate request takes a rail and a currency pair, and all four routes work, COP included, as does a quote by target amount. The system stores the quote ID, the amounts and the status for the month-end comparison. Request locked rates as described in the exchange rates docs and compare each final rate with your intraday mid. The product overview is in Lumx global payments.

Methodology and sources

Quote types and fees come from the Lumx exchange rates page, and the autoconversion row from the autoconversion rules guide. Partner fee and limit details come from partner fees and transaction limits, read November 1, 2026.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Chester Alvarez on Unsplash.