Liquidity analysis across every connected venue
Consolidated depth at multiple price bands, volume-weighted spread, book resiliency and venue concentration, read live.
Most crypto execution analytics tells a desk what a trade cost afterwards. This runs before the order is sent: it reads live liquidity across every venue, forecasts the cost of this order at this size, proposes the split and tactic, then measures the result.
Six stages run on every parent order. The first five happen before a single child order leaves the desk; the sixth closes the loop and feeds the next forecast.
Live order books, streamed quotes and on-chain pools are consolidated across every enabled venue, reporting executable size at each price band, volume-weighted spread, book resiliency and how concentrated the depth is.
Slippage is the gap between the price a desk expects and what its order achieves. The model conditions on live depth, realised volatility, spread regime, time of day and the desk’s own fills, returning basis points with a confidence band.
Fill-probability prediction answers what sizing turns on: how likely this order is to complete, at this participation rate, inside this window — including the cost of a residual if the window closes unfilled.
Every venue is scored for this order on predicted cost, fill probability and fee-adjusted price. The recommendation returns an allocation per venue with a tactic: TWAP, VWAP, passive posting or request-for-quote clips.
Recommendations are proposals, never automatic orders. A trader reviews the reasoning, adjusts or overrides, and approves inside the operator’s participation caps and venue allowlists. The audit record is created at send.
Transaction cost analysis measures what the order actually cost against the same benchmark the forecast used, split into spread, market impact, timing delay and fees. Measured outcomes retrain the prediction models.
Order intent enters the pre-trade engine, comes out as a scored venue set and a tactic, executes through the order and execution management layer, and returns as measured cost.




Consolidated depth at multiple price bands, volume-weighted spread, book resiliency and venue concentration, read live.
An expected cost in basis points for this order at this size, from live depth, volatility, spread and fill history.
Completion probability across several horizons and participation rates, including the expected cost of an unfilled residual.
Temporary and permanent impact estimated apart from timing risk, separating the cost of moving the book from that of waiting.
Every enabled venue ranked on predicted cost, fill probability and fee-adjusted price, with reasons for the venues left out.
TWAP, VWAP, passive posting or request-for-quote clips, chosen against the order’s urgency window, with the reasoning attached.
The recommendation is a proposal; the smart execution layer runs it, so the recommended tactic is also the measured one.
It scores the venues Coiny already aggregates as a deployed service, so depth and price arrive live, not as a nightly file.
Achieved cost measured against the stored forecast on the same benchmark, aggregated by venue, tactic, trader and desk.
Spread, temporary and permanent impact, timing delay and fees broken out per parent order, so an outlier can be explained.
Recommended tactic, tactic used, override reason and result kept together per order, with reviewer sign-off and an outlier list.
Period reports by desk, venue and tactic, exportable for best-execution documentation and client reporting.
Each execution decision carries two numbers on this page: what the engine predicted before the order was sent, and what the desk actually got. Analytics that never publish the first column can only ever explain the past — this is the column incumbents leave blank.
| # | Execution decision | Predicted, before the order | Achieved, after the fill |
|---|---|---|---|
| 1 | Cost versus benchmarkarrival price by default | Slippage forecast with a confidence bandper venue and per tactic | Realised slippage on the same benchmarkreported per parent order |
| 2 | Fill certaintywill this complete in the window? | Fill probability by horizon and participation rateincluding passive-only completion | Actual fill rate, completion time and residualwith the cost of what went unfilled |
| 3 | Venue choicewhere the size should go | Venue scores from live depth, spread and fee-adjusted pricewith an allocation per venue | Cost achieved per venue, ranked against the forecastvenues drifting above forecast are flagged |
| 4 | Tactic choicehow the order should be worked | Recommended tactic — TWAP, VWAP, passive posting or RFQ clipswith the reasoning attached | Cost by tactic, including any trader overrideoverride reason recorded with the result |
| 5 | Market impactthe cost of moving the book | Temporary and permanent impact estimated for the order sizeseparated from timing risk | Impact decomposition from the executed child ordersspread, impact, delay and fees split out |
| 6 | Timingthe cost of waiting | Timing-risk estimate across the urgency windowfrom recent realised volatility | Delay cost measured from decision time to completionclosing the loop on the window chosen |
Execution Intelligence never sends an order on its own. Operators define the limits it may recommend inside, traders approve every plan, and each decision leaves a record that survives the review.
The analysis is only as good as the stack it can see. Execution Intelligence reads the same liquidity, routes through the same order management layer, and hands its recommendations to the same execution engines Coiny already deploys.
Execution Intelligence is built for the teams that already know their execution costs them something — and want the number before the order, not after the quarter.
Desks working parent orders large enough to move a book, needing a defensible cost forecast and a venue split they can justify.
Teams pricing size away from the visible book, comparing request-for-quote clips against working the order before quoting a client.
Execution traders answerable for implementation shortfall, needing attribution between decision cost and execution cost.
Operators offering execution analytics to their own institutional clients, with per-client scoping and configurable benchmarks.
Slippage prediction is a pre-trade estimate of how far an order's average fill price will land away from its benchmark price, produced before the order is sent. Coiny Exchange's Execution Intelligence builds that estimate from live order-book depth across connected venues, recent realised volatility, the prevailing spread regime and the desk's own historical fills, and returns a confidence band rather than a single figure. Accuracy varies with market conditions and order size, which is exactly why every forecast is measured against the achieved result afterwards.
Transaction cost analysis (TCA) is the measurement of what an executed order actually cost against a chosen benchmark, such as the arrival price at the moment the decision was made. Coiny Exchange's Execution Intelligence decomposes that cost into spread, temporary and permanent market impact, timing delay and fees, then reports it per order, per venue and per tactic. Because the pre-trade forecast is stored with the order, every post-trade review compares predicted cost with achieved cost on the same benchmark.
Execution Intelligence scores every connected venue for the specific order in front of it rather than in general. It reads live depth at several price bands, the volume-weighted spread, book resiliency and fee-adjusted price, estimates slippage and fill probability per venue, and proposes a split with sizing and pacing for each one. Venue allowlists, participation caps and price limits stay operator-defined, and a trader approves the proposal before anything routes.
The right tactic depends on the trade-off between market impact and timing risk, and Coiny Exchange's Execution Intelligence recommends one per order. A TWAP (time-weighted average price) tactic spreads an order evenly across a chosen window; a VWAP (volume-weighted average price) tactic paces it in line with traded volume; passive posting waits for the spread instead of crossing it; request-for-quote clips source size away from the visible book. Execution Intelligence proposes the tactic and the execution algorithms carry it out.
Execution Intelligence is the analytics layer: it predicts cost, scores venues, recommends a tactic and measures the result. An order and execution management system (OMS/EMS) is the operational layer that holds the blotter, applies pre-trade risk checks, routes child orders and handles allocation and reporting. Coiny Exchange deploys both, and Execution Intelligence writes its forecast and recommendation into the OMS/EMS so a trader can approve and send from one screen.
A trader can override any recommended execution tactic, because Coiny Exchange's Execution Intelligence produces proposals rather than automatic orders. The system records the recommended tactic, the tactic actually used, the reason given for the override and the achieved cost against the pre-trade forecast. Overrides that cost materially more than forecast surface in the desk's post-trade review and outlier reporting, so the decision stays visible without ever blocking the trader.
Execution Intelligence needs timestamped order and fill records plus market data for the venues traded in order to measure execution quality. Coiny Exchange supplies both natively when a desk runs on its order and execution management system and its aggregated liquidity, and accepts imported order records where a desk also trades elsewhere. Benchmarks, venue lists, desk hierarchy and reporting periods are configured per operator, and every report is exportable.
Walk through a live pre-trade forecast, a venue and tactic recommendation, and a post-trade review on order flow that looks like yours — then see how the same analytics deploy on your desk.
Book a Demo