From tap to fill: how a crypto order travels through a fintech's stack

“I bought EUR 500 of bitcoin and the app says I spent EUR 499.65. Where is the rest?”

A fintech that offers crypto trading can expect a message like this sooner or later, and the answer is rarely a bug. The customer's money went exactly where your systems sent it. Explaining where that was means retracing the order through eight steps, and at several of them your team made a decision it may not remember making.

Is the crypto price on your screen a promise?

The order's history starts before the customer touches anything, with the price your app displays. That number arrives on a market data feed from your execution provider or from one or more exchanges, and it refreshes every few moments.

What kind of number is it? An indicative price is a recent observation of the market with no commitment behind it. A firm quote is a price the provider will honour for a short, stated period. Showing an indicative price means some customers will be filled at a slightly different level from the one they saw. Showing a firm quote removes that surprise and hands you a new job, which is dealing with the quote that expires while the customer is still deciding.

Either choice can work. Trouble comes from an app that presents an indicative price with the visual confidence of a firm one, large and unqualified, a moment before a fill at a different number.

Our customer saw EUR 90,000 per bitcoin, an illustrative figure, and it was indicative.

What does your platform check before a crypto order leaves?

The tap reaches your backend, and for a moment the market is irrelevant. Your systems confirm that this customer may trade this asset, compare the order with their limits, and verify that EUR 500 is available.

Then comes a hold on the money, a step that looks like bookkeeping and works as protection. Customers double-tap. Apps retry. A hold stops two orders from spending the same balance before either has been booked. It is written to your ledger, the internal record of what each customer owns, and it stays there until the order is resolved.

How does EUR 500 become a crypto order?

Your customer thinks in euros. Trading venues frequently think in units of the asset, and they set a minimum increment for those units.

At EUR 90,000 per bitcoin, EUR 500 buys 0.0055555 bitcoin, with the fives running on indefinitely. With a smallest increment of 0.00001 bitcoin, the order has to be rounded down to 0.00555. At the displayed price that quantity costs EUR 499.50, leaving 50 cents that were never going to be spent.

The same step fixes the order type. A market order accepts the available price and almost always completes. A limit order names the worst acceptable price and may be left unfilled. A fill-or-kill order executes in full at once or is cancelled, which suits a product where every purchase should be all or nothing. Customers rarely see this setting, and it governs everything that can happen to their order afterwards.

What happens when the API call to your execution provider gets no reply?

The order now leaves your systems over an API integration, bound for an execution provider or directly for an exchange. Many fintechs use a provider for this leg, since connecting to several venues and keeping those connections healthy is a substantial job in its own right.

Networks lose messages. You send an order, the connection drops, and nothing comes back. You cannot tell whether the order never arrived or arrived and was filled, and sending it again risks buying twice with a customer's money.

The usual protection is a reference of your own on every order, commonly called a client order ID. A provider that sees the same reference a second time treats the message as a repeat and returns the status of the original. Retries become safe, and a timeout stops being a reason to open an investigation.

Some failures are louder. A provider can refuse an order outright because the asset is suspended, the quantity is below the venue's minimum, or your account has reached a limit. A rejection is good news of a kind, since it is definite. Your product needs a plain-language message for each reason, because “something went wrong” sends the customer straight to support.

How is a crypto order executed on the venue?

Once your provider has run its own checks, the order goes to market. On an exchange, a buy order is matched against the sell orders resting in the order book, cheapest first.

An order as small as this one normally meets a single resting order and fills in one piece. Bigger orders can use up the cheapest offer and continue into the next, collecting several fills at rising prices, and a provider that routes across venues may gather those pieces from different exchanges. Every piece is its own fill, with a price and a quantity.

Our customer's order fills in full at EUR 90,027. The market moved by EUR 27 in the instant between display and execution, so 0.00555 bitcoin cost EUR 499.65, which is 15 cents more than the screen implied.

How does the fill get back to your platform?

The outcome returns as an execution report, and usually on a different channel from the one that carried the order. You submit, the provider acknowledges, and the fills follow on a streaming connection or as messages pushed to an address you have registered.

Your systems need a state for every point on that path. This order went from submitted to acknowledged to filled. On another day it might be partially filled, rejected, cancelled, or expired, and a product that only understands the happy path will behave strangely the first time an order leaves it.

There is a choice about what the customer watches in the meantime. A spinner that waits for the fill feels fast when the market is calm. An “order received” message, followed by a confirmation, holds up better on a busy day.

What goes into the customer ledger after a crypto trade?

The fill triggers the bookkeeping. The EUR 500 hold is released, EUR 499.65 is debited along with your fee, 0.00555 bitcoin is credited, and the unspent cents go back to the available balance.

The confirmation screen is drawn from those entries. It is the only part of the whole journey the customer reads closely, and it is where the message we began with either gets answered or gets written. A screen that shows the quantity bought, the price achieved, your fee on a separate line, and the amount returned leaves very little to ask about.

The provider's fee to you is a separate matter from your fee to the customer. Keeping the two apart in your own records lets you see what each trade earned.

Is a crypto order finished once the customer sees a confirmation?

For the customer, yes. For you, two obligations remain.

Your ledger now says this person owns 0.00555 bitcoin, and a matching quantity of real bitcoin has to exist somewhere. In many retail products the assets sit in pooled wallets held for all customers, with the ledger recording each person's share. You also owe your provider for the purchase, and that is commonly settled as one net amount covering a whole day of customer orders.

Reconciliation checks those records against each other: your ledger against the provider's statement, and both against the balances actually held. Small differences turn up daily from rounding, from fees recorded at different moments, or from fills that arrived after a cut-off. Teams that clear them every day keep them small.

The raw material for this check is the execution reports from earlier in the journey, which is one reason to care about their detail. A report that gives a single average price for the day supports a much weaker check than one that lists every fill.

What the crypto order lifecycle asks of a fintech product team

The customer's 35 cents were never missing. They went back to the available balance. The order fell 50 cents short of EUR 500 because of a rounding rule, and it then cost 15 cents more than the screen suggested because the price was indicative. Both were product decisions, and the customer met them for the first time on the confirmation screen.

Much of the chain also runs on systems you do not own. From the API call to the returning fill, you experience the order only as messages from a provider. That makes a short list of questions worth settling with any provider before launch. How are duplicate orders prevented? How quickly are fills reported, and on what channel? Can every fill in an execution report be traced to a venue and a price?

The customer who wrote that message deserves a two-line reply. A team that knows its own order journey can write it without opening a ticket with engineering.

If you're adding digital assets to your product, speak to us.