A quote is not a lock

Figo engineering · August 2026

You can price a movement before you commit to it. Ask /v1/orchestrate/quote and you get four numbers: what the customer pays in, what the recipient receives, the rate between them, and the fees.

The quote is optional and it is indicative. The rate settles when the pay-in lands.

Those two sentences are the entire subject of this article, because the gap between them is where integrations quietly acquire a liability.

What a lock actually is

A rate lock is not a technical feature. It is a commercial arrangement: somebody agrees to carry market movement on your behalf for a stated window, and prices that risk into the rate you are shown.

Every lock therefore has three properties, and if any is missing it is not a lock. There is a party carrying the risk. There is an expiry. And there is a worse rate than the market, because the risk was not free.

An indicative quote has none of those. Nobody has undertaken anything. There is no expiry because there is nothing to expire. And the rate is the market rather than the market plus an insurance premium.

That last point is worth sitting with, because it is the part that gets framed as a shortcoming. Not locking is why the number is honest.

Why the rate settles at pay-in

The mechanical reason is straightforward: until the funds have actually arrived, there is nothing to convert. A rate quoted before the money exists is a statement about the market, not about the transaction.

The interval between quote and pay-in is also not something the API controls. When a customer is given a temporary virtual account to transfer into, they might do it in ninety seconds or after lunch. A mobile-money push prompt sits on a phone until someone picks it up. Quoting a rate at the moment of the request means guaranteeing a price across a delay that belongs entirely to a third party.

Somebody has to carry that. Pricing it in means every movement pays for the volatility of the slowest customer, including the ones who paid immediately.

How to display it

This is where the practical damage happens. An indicative quote rendered as a firm number is a promise your interface made that your provider did not.

Show the quote as what it is: the price now. If your customer sees an exact recipient amount before paying in, they will treat it as a commitment, and the difference at settlement — in either direction — becomes a conversation. In one direction it is a complaint. In the other it is a windfall you cannot explain either.

Quote close to the moment of payment rather than early in a flow, and re-quote if the customer lingers. Reserve the exact figure for after settlement, where it is a fact, and use the timeline stages to carry the customer across the gap — rendering the stages rather than a single spinner is what makes a pending conversion feel like progress instead of uncertainty.

Fees are the part you can state exactly

Everything is denominated in USD — balances, amounts, fees — with the single exception of fields that explicitly name a local currency. The quote splits fees into a platform fee and a routing fee, both in dollars.

So while the converted amount moves, the fee does not. It is worth separating the two in your interface for that reason alone: one of these numbers is a firm figure you can commit to, and one is a forecast. Presenting them with equal confidence makes both look like guesses.

It also makes reconciliation tractable later, because a movement whose fee was fixed in dollars and whose conversion was not can be checked as two separate questions rather than one blurred one — the argument in reconciling payouts you don't control.

The honest summary

A quote tells you what a movement looks like right now. It is free, it is optional, and it costs nothing to ask again. What it is not is a commitment, and an API that pretended otherwise would be charging you for the pretence.

Quote endpoints and fields are in the recipes. Questions: hi@spendfigo.com.

Common questions

← All engineering writing