Short executive summary
An FX rate on a screen, a stablecoin transfer onchain, and a finance reviewer closing an exception are three different pieces of evidence. A reference rate may not be executable. An executable quote may expire before acceptance. An accepted trade may still require signatures and funding. A completed FX leg does not prove that a downstream payout arrived.
This Brief asks a narrower question: what evidence connects the proposed rate, accepted commitment, funding, conversion, value actually received and closure of the exception — and what should a reviewer do when one of those links is unknown?
“Close” here means operational reconciliation evidence sufficient for a finance-reviewer handoff. It does not mean trade settlement, payment-case resolution, month-end close, accounting recognition or a legal conclusion are automatically the same event.
A rate is not a quote until the product says it is
Circle’s current StableFX API distinguishes a reference quote, described as indicative, from a tradable quote, described as executable. A quote response can carry a quote ID, rate, from/to amounts, creation and expiry timestamps, fee and collateral fields. The request fixes an amount on either the from or to side rather than both. See Circle — Create a quote.
Circle’s technical guide describes acceptance as creating a trade with the quote ID and an idempotency key. At that point, its documentation says the quoted rate becomes locked until the resulting trade settles, expires or breaches. Signatures and funding nevertheless remain separate steps. See Circle — StableFX Technical Guide.
Bridge documents a contrasting model. Its exchange-rate endpoint returns a current midmarket, buy and sell rate but explicitly says that it does not provide a quote there that locks a rate for an amount of time; the endpoint is an estimate of a later currency-exchange transfer. See Bridge — Exchange Rates.
| Object | Safe interpretation | Not safe to infer |
|---|---|---|
| Market/reference rate | A dated pricing reference under its stated methodology | Guaranteed execution |
| Indicative estimate | An estimate for a stated direction and time | Accepted commercial commitment |
| Tradable/executable quote | Terms offered under the product’s conditions | Settlement or payout completion |
| Accepted trade | A booked commitment under the product’s rules | Both sides funded |
| Completed FX settlement | The documented FX obligations settled | Recipient payout or finance close |
Acceptance starts a new evidence chain
Quote expiry and trade maturity are different clocks. In Circle’s documented model, the trade API links quoteId to a new trade id and can return rate, amounts, status, creation and update times, tenor, maturity, settlement transaction hash and completion date. An idempotency key identifies the mutating request. See Circle — Create a trade.
If a quote expires before valid acceptance, a new quote should remain a new record linked to the failed attempt. The old price should not be overwritten. Conversely, if the product says a valid acceptance creates a new trade and locks its rate, later expiry of the source quote is not by itself evidence that the accepted trade disappeared. The reviewer should follow the new trade’s signature, maturity and funding conditions.
Reviewer rule: preserve expired Q-001 → replacement Q-002 → accepted trade T-018. Do not rewrite Q-001 with Q-002’s rate.
Funding is not execution, and execution is not payout
Circle documents separate StableFX states including pending, confirmed, pending_settlement, taker_funded, maker_funded, breaching, breached, refunded, failed and complete. These states distinguish signature, onchain-recording, funding and terminal outcomes. See Circle — Trade States.
When both parties fund in Circle’s documented settlement model, the escrow settles the trade and transfers the applicable net amounts. Its console can expose contract trade IDs, transaction hashes, timestamps and step states. A missed funding deadline can instead lead to breach handling and the documented risk-buffer process. See Circle — Settle Trades and Circle — Risk Buffers.
Payment-versus-payment should not be expanded beyond its covered obligations. Basel’s FX-risk guidance continues to distinguish principal, replacement-cost and liquidity risk and treats confirmed and reconciled settlement as an important boundary for replacement-cost exposure. See BIS — Foreign exchange risks.
The fee field needs its own evidence
A fee may be explicit, reflected in an amount, charged on a different leg, or accompanied by a separate network or payout fee. Do not deduct the same economics twice.
Documentation caveat: the current Circle Create Quote schema describes its fee as denominated in the to currency, and the console documentation uses the same framing, while one sell-fixed-flow passage in the technical guide uses sell-currency fee language. Preserve the exact quote/API payload and applicable documentation version rather than silently harmonising those descriptions.
Bridge transfer receipts can separately expose fields such as initial amount, developer fee, exchange fee, subtotal, gas fee, final amount and a destination transaction hash. See Bridge — Transfers.
Source asset: full wallet debit = traded source amount + source-side fees actually charged.
Target asset: gross bought amount − target-side explicit fees = expected net received.
Residual: actual net received − expected net received.
Only after the residual has a supported cause should it be labelled fee, rounding, funding shortfall, pricing difference or another specific exception.
The FX-to-Close Exception Chain
| Stage | Minimum record | What it proves | What it does not prove |
|---|---|---|---|
| Rate observation | Source, pair, direction, timestamp, benchmark type | What rate was observed | Executable price |
| Quote | Quote ID/version, fixed leg, amounts, rate, expiry, fee basis | Terms offered | Acceptance |
| Acceptance/booking | Trade ID, linked quote ID, acceptance time | Commitment under documented product rules | Funding |
| Funding | Asset, amount, funding reference, deadline, state | Funds delivered or reserved under that leg | Both parties funded |
| FX settlement | Trade state, executed amounts, fee, settlement evidence | FX-leg outcome | Downstream payout |
| Payout | Payout ID, rail, destination amount and state | Downstream payment state | Finance reconciliation |
| Value received | Destination evidence and net amount | What actually arrived | Cause of every variance |
| Exception resolution | Reason, unresolved amount, owner, evidence | Current disposition | Accounting or legal conclusion |
| Finance handoff | Evidence pack and explained residual | Operationally reviewable case | Period-close approval |
Synthetic walkthrough
SYNTHETIC EXAMPLE. All IDs, rates, amounts, fees, timestamps and rules in this section are invented fixtures. They are not market data, provider terms, live trades, provider tests or customer incidents.
Expired quote and requote
Q-SYN-001 fixes 10,000.000000 USDC at 0.920000 EURC per USDC, is created at 10:00:00 UTC and expires at 10:00:30. An acceptance attempt at 10:00:35 creates no trade.
Q-SYN-002 is created at 10:00:40 at 0.918500 and validly accepted at 10:00:50. The old quote would imply 9,200.000000 EURC gross; the new quote implies 9,185.000000 EURC gross. The 15.000000 EURC difference is a requote difference, not slippage on an executed Q-SYN-001 trade.
At an explicit synthetic 0.0500% target-side fee, the fee is 4.592500 EURC and net received is 9,180.407500 EURC.
A separate 0.800000 USDC network cost makes the wallet debit 10,000.800000 USDC. It is not deducted again from EURC proceeds.
Partial funding and rounding
A separate synthetic model accepts 12,345.670000 USDC at 0.917333 but receives only 10,000.005000 USDC. The source shortfall is 2,345.665000 USDC.
The executed gross target is 9,173.334587 EURC. At a synthetic 0.075% fee, the fee is 6.880001 EURC and net receipt is 9,166.454586 EURC. A two-decimal finance display shows 9,166.45, leaving a 0.004586 EURC display-versus-wallet rounding difference. That is not an FX loss.
Conversion complete, payout rejected, return reopens the case
A third fixture has already completed its FX leg at 9,195.400000 EURC. For this fixture only, an explicitly assumed 1.000000 EUR/EURC redemption basis and a 5.00 EUR intended payout fee would produce 9,190.40 EUR for the beneficiary.
The payout is rejected. A duplicate webhook with the same object and event identity is not a second economic payment attempt. Later, the fixture records a 9,185.400000 EURC refund plus a 10.000000 EURC return fee, while the attempted 5.00 EUR payout fee is reversed.
9,195.400000 EURC debit = 9,185.400000 EURC refund + 10.000000 EURC return fee.
Actual beneficiary value is 0.00 EUR. The completed FX leg stays complete, but the end-to-end payment case had to be reopened.
Unknown is a state, not a failure reason
Bridge distinguishes states including awaiting_funds, funds_received, payment_submitted, payment_processed, undeliverable, returned, refunded, canceled and error. Its documented returned and refunded states do not mean the same thing. See Bridge — Transfer States.
Bridge also documents idempotency for POST requests so a retry with the same key during the documented window returns the original response rather than a duplicate operation. See Bridge — Idempotency.
The safest reviewer vocabulary is therefore confirmed, not confirmed, pending, returned, refunded, a specifically documented failure state, or unknown.
What should survive into finance review
- Quote: provider, quote ID/version, pair, direction, fixed leg, amounts, rate, fee fields, timestamps, expiry, acceptance conditions and documentation version.
- Trade: accepted quote link, trade/execution ID, booking time, accepted/executed rate, status, maturity and idempotency identity.
- Funding and settlement: amount, asset, state chronology, settlement references and refund/breach evidence.
- Value received: destination object, gross amount, itemised fees, net amount, payout status, receipt and return evidence.
- Exception: trigger, unresolved amount, known facts, unknown facts, next owner, required evidence, closure condition and reopen condition.
This evidence packet does not decide journal entries, realised accounting P&L, tax, legal responsibility, regulatory best execution or provider suitability. It lets the next reviewer reconstruct which price was merely observed, which terms were accepted, what was funded, what converted, what arrived, what did not, and why the case is — or is not — ready to close.
Reader action: before closing the next multi-rail FX exception, work backwards from value received to payout, conversion, funding, accepted trade and the exact quote that created it. If one link cannot be reconstructed, preserve that uncertainty explicitly.
Sources
- Circle — StableFX Technical Guide
- Circle — Create a Quote
- Circle — Create a Trade
- Circle — StableFX Trade States
- Circle — Settle Trades in the Console
- Circle — StableFX Risk Buffers
- Bridge — Exchange Rates
- Bridge — Transfer States
- Bridge — Transfers
- Bridge — Idempotency
- BIS / Basel Committee — Foreign exchange risks
- Elysium Technology Group — Post-Trade Solutions
Source retrieval date: 2026-09-08. Public product documentation describes documented semantics and should not be read as independent evidence of reliability, adoption, liquidity, performance or suitability.