How to publish a daily FX rate sheet from live stablecoin quotes

A daily FX rate sheet is a dated table of indicative exchange rates that a company publishes for customers or sales: one row per currency pair, priced at a stated reference amount, stamped with the snapshot time and labeled as an estimate. Every real conversion still runs on its own quote, created when the transaction happens.

Sales wants a number to send, and customers want to budget before they log in. A sheet serves both, as long as nobody reads it as a price: an unlabeled rate in a sales email is how a courtesy estimate turns into a dispute with the customer holding your own number.

What belongs on a daily FX rate sheet?

Seven columns per row and one paragraph of terms.

The columns of a daily FX rate sheet and why each one is there

Write every rate as local currency per one stablecoin, so rows read alike across currencies. And price the rows after every fee the customer will pay: a sheet that shows only the rate before fees looks better and produces the most complaints.

On Lumx, a quote returns the rate in local currency per USDC, and a locked quote returns the rates before and after fees in separate fields, so both columns come from one response.

Which corridors go on the sheet, and in which direction?

Publish the corridors your customers move money through, in the direction they use them. For a company that pays out from a USDC balance, that is USDC to local currency. A company that collects in local currency adds a second block with its own rows, never a midpoint of the two.

Corridors a Lumx-based sheet can carry, with the rail named on each row (as of November 2026)

The sheet does not replace those pages: a conversion page shows one public rate when you load it, while the sheet is your own dated table that sales can attach to an email. The quote request accepts COP, so a Colombia row works too. What a stablecoin corridor is covers the term, and the coverage page lists what is live on the day you build.

On Lumx, the rail in the quote request is the rail of the row: Pix (Brazil's instant payment system) for BRL, SPEI (Mexico's interbank system) for MXN, Bre-B (Colombia's instant payment system) for COP, SEPA for EUR and Faster Payments for GBP.

Pulling the rows from live Lumx quotes

The honest input is live quote data from the provider you execute with. A screen rate shows where the market is, not what customers get. Lumx has two quote types for this, both on the exchange-rates endpoint.

The two Lumx quote types as sheet inputs, from the docs read on November 1, 2026

For a sheet with a received-amount column, use the 30-second locked quote. No other response returns the rate after fees, and an unused lock has no side effect today, so a script that pulls five rows leaves nothing behind. The clock starts when the quote is created, and the response gives the expiry in UTC. You can quote again at any time, and each new quote returns a new ID. The 1-minute and 5-minute locks carry a fee, so they are the wrong input.

Every request needs a customer, so run the sheet under one of your own customers. Send the same reference amount every day. When the API refuses a row, leave it out with the reason, and never carry yesterday's number forward under today's time.

Your own markup goes through the same call. A partner fee ID on the request applies your fee inside the locked quote, and the response splits the fee by party and gives the total. A partner fee applies only when the request carries its ID; there is no default. The fee sits on top of what the payer funds, so in a BRL to USDC quote it raises the BRL to send for the same USDC credited. The sheet job names its fee ID on every request, so the published rate always carries the markup you intend.

On Lumx, a sheet row is one locked 30-second quote request, read for its after-fee rate and its fee fields, and the quote is never passed to a transaction.

A worked sheet with five rows

The rates in the sheet below are illustrative. The BRL row uses the figures from the example response in the Lumx docs, and the other rows were made up to show the layout. None of them is a market rate, and none should be quoted as one.

An illustrative rate sheet with five rows for 500 USDC, dated November 1, 2026, times in America/Sao_Paulo, illustrative only

In the docs example for the BRL row, 500 USDC at the rate before fees of 5.1750 would pay 2,587.50 BRL. The rate after fees is 5.1636, which pays 2,581.81 BRL. The difference is 5.69 BRL, or 5.69 / 2,587.50 = about 0.22%, which is 22 basis points. That example response was a 1-minute lock, so its 22 basis points include the lock fee and only illustrate before and after fees. A sheet built on 30-second quotes should publish the after-fee rate and, if it wants, the gap.

When to publish and how often to refresh

Publish once a day at a fixed time your readers learn, and refresh a corridor inside the day only if its rate moves faster than they can tolerate.

Snapshot time by audience, with the reason for each

Name the time zone by location (America/Sao_Paulo, not UTC-3) and pull every row inside the same few minutes. The ECB publishes its rates for information only, which is the posture a company sheet should take. Brazil's own central bank reference rate has a separate job, covered in PTAX vs live quote. Space the quote calls out and retry with backoff on a 429.

On Lumx, the scheduler is yours: nothing in the quote call depends on the time of day, so the snapshot time is the time you choose and write on the sheet.

The disclaimer, and what keeps a sheet from becoming a promise

A sheet becomes a promise when someone treats it as one, so the label has to sit on the sheet and name what the numbers are. The FX Global Code, in Principle 9, says market participants handling orders should make clear whether the prices they provide are firm or merely indicative.

A template:

> Indicative rates as of 12:05 America/Sao_Paulo on November 1, 2026, priced at the reference amount shown on each row. These rates are for information only and are not an offer. Every conversion executes at the rate and fees in the quote shown before you confirm.

Have legal review it once and never edit it per email. Three rules do the rest:

1. Sales quotes from the sheet as an estimate, in those words, and sends the customer to the confirm screen.

2. The product never pre-fills a payment with a sheet rate. The confirm screen shows a fresh quote with its fees and a countdown to expiry.

3. Support explains differences with the sheet's metadata: snapshot time, reference amount and direction.

I would publish the sheet from one script at one fixed time and refuse every hand edit of a row. The first hand edit, a rounded rate or a row "fixed" before a meeting, is the one that makes the sheet impossible to reproduce from the archive. If a row looks wrong, I would drop it with a note and rerun the pull, because a missing row is an honest answer.

A confirm screen that falls back to the sheet rate when a quote fails has quietly made the sheet binding, so the fallback is an error message.

On Lumx, a transaction settles at a locked rate only when the request carries the quote's ID, and an expired or already used quote is refused, so a sheet row cannot settle anything.

What to archive with each version

Keep every sheet version with its raw responses. When a customer disputes a conversion months later, the archive shows what the sheet said and when. It also shows the transaction ran on a separate quote with its own ID.

The record to store for each row of each published sheet

Keep it next to your transaction records, as in reconciling stablecoin transactions.

On Lumx, the quote response carries the ID, the fee breakdown and the expiry time, so the archive is a copy of the response, not a reconstruction (more IDs to store).

When a rate sheet is the wrong tool

A sheet is the wrong tool when the reader needs certainty. A customer who must know the exact reais amount of a payment next Thursday needs a quote at the time of payment, or a hedge bought from a bank or FX broker. A "rate for the week" invites the dispute the sheet was meant to prevent.

The fee schedule belongs in the agreement, not on the sheet; how a quote's margin is built is in how stablecoin payout pricing works, and provider prices are in stablecoin API pricing compared.

What a daily rate sheet 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.

A platform creates one customer of its own to own the quote requests, then runs a scheduled job that posts one request per corridor: type locked, a 30-second lock, the same reference amount of USDC as the source, the target currency and the rail of the row. If the platform charges its own fee on payouts, it adds its partner fee ID, chosen explicitly on every request, so the after-fee rate includes it. Each response gives the rate before fees, the rate after fees, the fees by party, the received amount and the expiry time, and the job writes those fields into the sheet and the archive.

When a customer converts, the platform requests a new quote for the real amount, shows the received amount and expiry on the confirm screen, and passes the quote's ID on the payout request so it settles at the quoted rate. Past the expiry, the API returns an expired-rate error and the platform asks again.

An autoconversion rule converts at market, so the sheet is a reference for it, not a price. Treasury teams converting BRL read BRL to USDC for corporate treasury, and the same quotes sit behind the global payments product.

Methodology and sources

Product facts come from the Lumx docs read on November 1, 2026 and Lumx's confirmations of November 2: Exchange rates, the Get an exchange rate reference, Partner fees, Error codes and Coverage. The BRL figures in the worked example are from the example response in the remittances guide.

The ECB's refresh time and its note on transaction use are on its euro reference rates page, and the firm versus indicative wording is in Principle 9 of the FX Global Code.

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

Cover photo: iSawRed on Unsplash.