Same-day FX conversion in stablecoin settlement: when the rate is fixed, who bears the move, how to prove it

Same-day FX conversion inside a stablecoin settlement means the rate applied to the customer is fixed, the conversion is executed and the destination currency is delivered on the same business day, with the stablecoin acting as the settlement asset between the two fiat legs. The rate should be fixed at the point the institution can actually fill or hedge it, the move between quote and fill should be assigned to a named party in the product terms, and the rate applied must be evidenced by a record that links the quote, the fill, the ISO 20022 message and the on-chain transaction. This article explains where the rates sit in the flow, when to fix them, who bears the move, how to run the conversion same day, and what an auditor and a customer expect to see.

Where does FX actually sit in a stablecoin settlement flow?

Take a payment from a customer holding Canadian dollars to a beneficiary who must receive Mexican pesos. On a correspondent route the FX happens at one bank in the chain and the customer learns the rate afterwards. On a stablecoin route the flow is three legs: the originating institution converts CAD to a dollar stablecoin, the stablecoin moves on chain to the receiving institution's wallet in minutes, and the receiving institution converts the stablecoin to MXN and delivers it through local clearing. There are therefore two conversions and potentially a third if the originating institution buys the stablecoin in dollars, with an internal CAD to USD rate first.

Each conversion has a rate, a time at which it is fixed and a party that executes it. Where the originating and receiving institutions are different, the CAD to stablecoin rate belongs to one and the stablecoin to MXN rate to the other, and the customer sees an all-in rate that one of them quotes. The operational decision is which institution owns the customer rate, and the design usually follows the commercial model: the institution that faces the customer quotes the all-in rate and takes a rate from the other side for the leg it does not execute. In ISO 20022 terms, the instructed amount in pacs.008 carries what the customer asked to send, the interbank settlement amount carries what moves, and the exchange rate element carries the rate that links them; the charge bearer code states who pays the fees.

When should the customer rate be fixed?

The rate should be fixed no earlier than the institution can lock its own cost. If you quote a rate to a customer at 09:00 and fill the conversion at 11:00, you hold the market move for two hours on your own book. If you fill at 09:00 against the quote, the move is minutes. A settlement flow that completes in minutes on chain allows the second design, provided the liquidity provider will quote and fill within the same window.

Three fixing models are common. In an indicative-then-firm model, the customer sees an indicative rate at initiation and receives a firm rate at the moment of execution, with a tolerance band outside which the payment is held for re-confirmation. In a firm-quote model, the institution obtains a firm quote from its provider, adds its margin, shows the customer a rate valid for a short window, and executes on acceptance. In a fixing model, all payments in a corridor are converted at a published fixing at a set time, for example a mid-morning rate, and the customer accepts that rate in advance. The firm-quote model gives the customer certainty and gives the institution the least exposure; the fixing model suits high-volume, low-value corridors where quoting each payment is impractical.

Whichever model is used, the record must show the fixing time, the source of the rate, the margin applied and the validity window. The control that prevents most disputes is a rule that a payment cannot be released to the chain unless a rate record with those four fields exists and is referenced in the payment.

Who bears the move between quote and settlement?

Between the customer rate being fixed and the conversion being filled there is a move, and someone owns it. The product terms must say who. If the institution absorbs it, it is a market risk position on the institution's book, sized by the volume between fixing and fill, and it needs a limit, a hedging policy and a daily profit and loss line. If the customer absorbs it, the terms must say so plainly, the customer must have accepted an indicative rather than a firm rate, and the final rate must be reported back before or at delivery. If the liquidity provider absorbs it under a firm quote, the provider's quote validity window is the constraint and a late acceptance falls back on the institution.

The stablecoin leg itself carries a small version of the same question. A dollar stablecoin is designed to hold par, but its market price on an exchange can differ from par by small amounts, and an institution that buys tokens on a book rather than minting at the issuer carries that difference. Treat the stablecoin conversion as a rate with a fixing time, not as an identity, and record it. The mid-article discipline that matters is a single ledger entry per payment that shows the customer rate, the achieved rate on each leg and the resulting difference, so that slippage is measured per payment rather than discovered in the monthly margin.

There is always a party carrying the rate between quote and fill. If your product terms do not name that party, it is you, and you are carrying it without a limit.

How do you run the conversion and delivery on the same day?

Same-day delivery depends on the sequence of legs and on the calendars behind each. The on-chain leg is the fast part and settles in minutes at any hour. The fiat legs are governed by the local rails: in the euro area SEPA Instant is available around the clock, in the US same-day ACH has fixed submission windows and wires follow Fedwire hours, in Canada EFT follows the clearing cycle, and in many destination markets local instant schemes have their own cut-offs and holidays. The liquidity provider's own bank cut-off adds a further constraint on the fiat side of each conversion.

A same-day flow that works in practice runs as follows.

• The customer initiates in the morning of the originating market; the institution obtains a firm quote from its provider and fixes the customer rate within the quote's validity window.
• The institution converts customer fiat to the stablecoin, either from a pre-funded operating wallet that is replenished later in the day or by an immediate fill with the provider, and records the fill.
• The stablecoin moves on chain to the receiving institution's wallet, and the pacs.008 travels with it, with the exchange rate and instructed amount populated and the UETR assigned.
• The receiving institution converts to the destination currency at the rate agreed with the originating institution, records the fill, and submits the local payment before the local cut-off.
• A pacs.002 status report confirms acceptance into local clearing, and the customer receives the confirmed rate and the delivery time in the same message that closes the payment.
• Any leg that misses its cut-off is held with the rate record intact, and the customer is told the new delivery time rather than left to discover it.

The pre-funded operating wallet is the key to making the first legs fast. It is a till, not a vault: sized to the corridor's expected morning volume, replenished by a provider fill against the day's fixing and swept at close. Pre-funding it with a stablecoin rather than with a nostro in each destination currency is what allows the same-day design without trapped local balances.

How do you evidence the rate applied for the customer and for the auditor?

The customer needs a confirmation that shows the amount sent, the rate applied, the fees and the amount delivered, and it should match the pacs.008 fields exactly, because a mismatch between the customer document and the interbank message is the first thing a dispute reviewer finds. The confirmation should identify the rate as firm or indicative, and if indicative, the final rate should follow with the delivery confirmation.

The auditor, and in a regulated firm the examiner, wants a pack per payment that can be pulled by UETR and contains the quote record with source, fixing time, margin and validity; the provider fill record with reference rate, spread and execution time; the pacs.008 with instructed amount, interbank settlement amount, exchange rate and charge bearer; the on-chain transaction hash with block time; the receiving institution's fill record for the second conversion; the pacs.002 acceptance; and the customer confirmation. If the institution emits or accepts MT103, the same data appears in field 33B for the instructed amount, field 32A for the settled amount and field 36 for the exchange rate, and the mapping between the MT fields and the ISO elements should be documented once and applied by the system rather than by hand.

Across payments, the daily report that satisfies both a treasurer and a reviewer is slippage by corridor: the customer rate against the achieved rate, in basis points, with the count of payments outside a tolerance and the reason for each. A corridor whose slippage moves in one direction over several days usually has a fixing time that is set too early or a provider whose quotes are drifting, and the report shows it before the margin does.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. Its settlement flows, including fiat-to-crypto on-ramp, digital asset settlement and crypto-to-fiat off-ramp with last-mile delivery through local fiat rails such as ACH, SEPA and EFT, are the legs described in this article, with the stablecoin leg in regulated tokens such as USDC and USDT completing on public blockchains in minutes while customers keep custody. The platform is ISO 20022 native: the pacs.008 carries the instructed amount, interbank settlement amount and exchange rate elements inside a head.001 envelope, the pacs.002 returns the acceptance, and the whole payment is tracked by UETR against the on-chain hash, which is the spine of the evidence pack an auditor asks for. MT103 is accepted and emitted with the same data mapped to the MT fields. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.