Execution algorithms: VWAP, POV and arrival price mechanics

Short answer: Execution algorithms are software that work one parent order as many child orders under a rule. The rule can be even slices over time (TWAP), a forecast volume curve (VWAP), a share of live volume (percent of volume, POV) or the price when the order arrived (arrival price, also called implementation shortfall), and it sets how an order is worked, not what to trade or when. A VWAP execution algorithm stays near the market's VWAP only as far as its volume forecast holds, and that gap is a distance from a benchmark, not a measure of profit.

This is a map for product and engineering leads deciding whether to use a venue's native algorithm or build one. A US SEC staff report (opens in a new tab) of 5 August 2020 (page 36) names the core types many brokers offer: VWAP, TWAP, minimum implementation shortfall and percent of volume.

Venue facts come from official documents read on 5 November 2026, as examples, not recommendations. No method here is presented as earning more, and automated trading can lose money.

What are execution algorithms?

What sets the pace of child orders decides how each family fails.

A 2012 survey by Cesari, Marzo and Zagaglia (opens in a new tab) groups them as impact-driven, cost-driven and opportunistic. All of them sit behind a crypto order management system; choosing venues is smart order routing.

How does a VWAP execution algorithm work?

It slices the parent order along a forecast of market volume, then measures the average fill against the VWAP that actually printed.

1. Build a curve: each time bucket's share of volume, from history.
2. Allocate: parent quantity times each share.
3. Place child orders in each bucket, under your price limit and the venue's size rules.
4. Measure: tracking error, the average fill's distance from market VWAP in basis points (bp).

tracking error = sum((your share - market share) x price) / market VWAP

That identity (one price per bucket), checked at the end of the code below, shows that a volume miss costs tracking only when it lands in the same buckets as a price move.

Crypto never closes, but it still has a curve. On Coinbase's public hourly candles (opens in a new tab) for BTC-USD, over 30 full UTC days from 6 October to 4 November 2026, the busiest hour (14:00 UTC) averaged 8.84% of daily volume and the quietest (10:00 UTC) 2.21%, against 4.17% if flat. On the median day, 21.4% of volume fell in other hours than the average curve predicted (32.6% on the worst day), against 26.1% for a flat schedule. Kraken's XBT/USD candles (opens in a new tab) over 29 days to 4 November gave 25.0% (curve) and 27.3% (flat) on its median day. Each curve was built from those same days, which flatters it; treat the figures as an order of magnitude.

A VWAP simulation in Python on synthetic data

The simulation measures each schedule's drift from market VWAP when volume behaves and when it does not.

import numpy as np

BUCKETS, DAILY, PARENT, DAYS = 48, 1_000_000, 10_000, 2_000     # all hypothetical
rng = np.random.default_rng(2026)
x = np.linspace(0, 1, BUCKETS)
curve = 1 + 1.6 * np.exp(-((x - 0.58) / 0.10) ** 2)
curve /= curve.sum()
flat = np.full(BUCKETS, 1 / BUCKETS)

def day(regime):
    v = DAILY * curve * rng.lognormal(0, 0.35, BUCKETS)
    if regime == "late surge":
        v[-8:] *= 4
    if regime == "dry second half":
        v[BUCKETS // 2:] *= 0.3
    px = 100 * np.exp(np.cumsum(rng.normal(0, 0.0015, BUCKETS)))
    return v, px

def pov(v, rate=0.01):
    if not 0 < rate < 1:
        raise ValueError("rate must be between 0 and 1")
    q = v * rate / (1 - rate)
    return np.minimum(q, np.maximum(PARENT - np.r_[0, np.cumsum(q)[:-1]], 0))

def measure(v, px, q):
    market = v + q                           # our orders add to the tape
    bench = (market * px).sum() / market.sum()
    done = q.sum()
    avg = (q * px).sum() / done
    return abs(avg - bench) / bench * 1e4, done / PARENT, (q / market).max()

print(f"{'regime':16}{'schedule':10}{'mean |TE| bp':>13}{'p95 |TE| bp':>12}{'filled':>8}{'peak part.':>11}")
for regime in ("as forecast", "late surge", "dry second half"):
    rows = {"flat": [], "curve": [], "pov 1%": []}
    for _ in range(DAYS):
        v, px = day(regime)
        rows["flat"].append(measure(v, px, PARENT * flat))
        rows["curve"].append(measure(v, px, PARENT * curve))
        rows["pov 1%"].append(measure(v, px, pov(v)))
    for name, r in rows.items():
        r = np.array(r)
        print(f"{regime:16}{name:10}{r[:,0].mean():13.2f}{np.percentile(r[:,0],95):12.2f}"
              f"{r[:,1].mean():8.1%}{np.percentile(r[:,2],95):11.1%}")

v, px = day("late surge")
q = PARENT * curve
market = v + q
ours, theirs = q / q.sum(), market / market.sum()
bench = (market * px).sum() / market.sum()
print(round((ours - theirs) @ px / bench * 1e4, 6), round(((q * px).sum() / q.sum() - bench) / bench * 1e4, 6))

Output, from Python 3.11 and NumPy 2.0 on 5 November 2026, all synthetic:

regime          schedule   mean |TE| bp p95 |TE| bp  filled peak part.
as forecast     flat               4.28       10.98  100.0%       3.5%
as forecast     curve              1.54        3.97  100.0%       2.8%
as forecast     pov 1%             3.22       10.59   99.8%       1.0%
late surge      flat              11.99       29.42  100.0%       3.3%
late surge      curve             11.30       27.43  100.0%       2.8%
late surge      pov 1%            14.64       35.08  100.0%       1.0%
dry second half flat              10.22       25.54  100.0%       9.6%
dry second half curve             12.09       29.51  100.0%       8.3%
dry second half pov 1%             0.00        0.00   63.8%       1.0%
40.7131 40.7131

TE is tracking error; peak part. is each day's largest share of one bucket (95th percentile); the last line computes the identity both ways.

• As forecast: the curve tracks closest, 1.54 bp against 4.28 for flat; POV's 99.8% fill means some days ended short.
• Late surge: every schedule drifts; POV completes as the surge begins and misses most of it.
• Dry second half: POV reads 0.00 bp because it stays proportional to volume, yet it filled only 63.8%. The fixed schedules finish at peak shares of 8.3% and 9.6% of a bucket.

Never read tracking error without the fill rate. A lower number means closer to a benchmark, not cheaper or better, and this model has no spread, fees or market impact.

Percent of volume: the math and the missing end time

POV sizes child orders from live volume, so participation is known and the finish time is not.

Volume is known only after it trades, so POV always trails the market a little, and thin periods can leave it unfinished at a deadline. Binance's Spot page says urgency sets the participation rate, with LOW as passive, MEDIUM as neutral and HIGH as aggressive, while its USD-M page calls it relative speed. Neither page, nor the Algo Orders FAQ (opens in a new tab), gives a percentage for any level, so measure the behavior first. USD-M has no duration field, and Spot defaults vpTimeLimit to 86,400 seconds yet says the order "runs until fully filled or cancelled". Size limits conflict too: Binance's futures help page (opens in a new tab), updated 2 April 2026, says 1,000 to 1,000,000 USDT, against the API page's above 10,000 USDT.

Arrival price and implementation shortfall mechanics

Arrival price algorithms balance two costs: trading fast moves the price against the order, and trading slowly leaves it exposed to price moves.

Almgren and Chriss (opens in a new tab) build an efficient frontier of schedules from a simple linear cost model, and a risk-aversion setting picks a point on it. With no risk aversion and no price drift, their answer is a straight line: equal blocks over equal intervals, which is the TWAP schedule. Kato (opens in a new tab) adds a volume process to that model and shows the risk-neutral solution following expected volume, which is VWAP, and collapsing to TWAP when volume is constant. Busseti and Boyd (opens in a new tab) model uncertainty in total volume and report a 10% lower RMSE of VWAP deviation than the standard static solution in simulations on NYSE data.

These results hold under each paper's assumptions, and none uses crypto data. An implementation must supply impact, volatility, volume and risk aversion, and each can be wrong. Measuring the result afterward is the job of transaction cost analysis.

Digital currency execution algorithms: native options

In the documents read, crypto venues mostly offer time-based and participation orders, not a VWAP order with a published curve.

No VWAP or POV order appears in OKX's v5 documentation, which lists TWAP and iceberg, in Coinbase Advanced Trade's order_configuration or on Hyperliquid's order types page. No native order was placed: that needs real keys. Account types and API access vary by venue and country. In FIX, TargetStrategy (847) (opens in a new tab) sets an order's target strategy: 1 VWAP, 2 Participate, 3 minimize market impact, and 1000 and above for bilaterally agreed values. Two crypto differences change the math: trading never closes, so the day's boundary is your choice, and since each venue publishes its own trades, market VWAP means one venue's VWAP unless you say otherwise.

Build or use an execution algorithm?

A native order moves the schedule logic to the venue, and a build moves every failure mode to you.

A small team can usually maintain a schedule-based slicer on an order management system; forecasting and impact models are open-ended research. Check data rights early: Binance's dataset terms (opens in a new tab), updated 26 August 2026, limit its public datasets to non-commercial use, and sections 9.3 and 9.4 of the OKX API Agreement (opens in a new tab), last updated 28 July 2026, require written approval for commercial services and limit market data to your own non-commercial use.

Who may run execution algorithms for others?

Running an algorithm on your own orders under your own rules is software, while working other people's orders is a regulated service in many jurisdictions.

In the EU, MiCA lists execution and reception and transmission of orders on behalf of clients as crypto-asset services (Article 3(1)(16)(e) and (g)). This is not legal advice, and rules depend on your jurisdiction and each platform's terms. For readers in Turkey: Article 99/A of Capital Markets Law No. 6362 treats activity by foreign crypto-asset platforms directed at Turkish residents as unauthorized. The Capital Markets Board (SPK) says being on its operating list (opens in a new tab) does not mean authorization.

Fincode builds software to the customer's written rules, on the customer's own account and key, and does not work client orders. For integration work in general, see Fincode's algorithmic trading page; naming a venue or broker here does not mean Fincode integrates it or has built on it.

Frequently asked questions

Does a VWAP algorithm get a better price?

It does not promise one. It tries to stay close to the market's VWAP, which says nothing about whether that average was a good price.

What is tracking error in VWAP execution?

The distance between your average fill and the market VWAP over the same period, usually in basis points. Read it together with the fill rate.

Why can a percent of volume order fail to finish?

Its speed follows market volume, so thin volume can leave it short at your deadline.

Can I run an execution algorithm on clients' accounts?

That is usually a regulated activity, such as execution or transmission of orders under MiCA in the EU. Take legal advice in your jurisdiction first.

Sources

• SEC: Staff Report on Algorithmic Trading in U.S. Capital Markets (5 August 2020) (opens in a new tab)
• Almgren and Chriss: Optimal execution of portfolio transactions, Journal of Risk 3(2) (opens in a new tab)
• Kato: VWAP Execution as an Optimal Strategy (arXiv 1408.6118) (opens in a new tab)
• Busseti and Boyd: Volume Weighted Average Price Optimal Execution (arXiv 1509.08503) (opens in a new tab)
• Cesari, Marzo and Zagaglia: Effective Trade Execution (arXiv 1206.5324) (opens in a new tab)
• Binance Algo Trading: Future Algo, Volume Participation new order (opens in a new tab)
• Binance Algo Trading: Spot Algo REST API (TWAP and Volume Participation) (opens in a new tab)
• Binance Algo Trading: Change log (Spot VP, 9 October 2026) (opens in a new tab)
• Bybit Help Center: Percentage of Volume (POV) Order (updated 1 October 2026) (opens in a new tab)
• Coinbase Prime: Order types (TWAP, VWAP) (opens in a new tab)
• Interactive Brokers: TWS API, IB Algorithms (marked deprecated) (opens in a new tab)
• Kraken: Algo trading guide, TWAP (opens in a new tab)
• Hyperliquid: Order types (opens in a new tab)
• ESMA interactive single rulebook: MiCA Article 3, definitions (opens in a new tab)
• Capital Markets Law No. 6362, consolidated text, Article 99/A (Turkish) (opens in a new tab)

This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the editorial policy.