Execution research that reconciles: quantities, costs and decision clocks

01 /Specify the execution contract before selecting a policy

An execution algorithm turns a parent instruction into orders, fills and a remaining obligation. Its contract must identify side, target quantity, arrival benchmark, completion deadline, permitted venues and operational constraints. A policy can then be evaluated against that contract. Without it, low reported cost might mean useful execution, selective measurement of easy fills, or simply leaving a difficult order unfinished.

This note develops a small quantity-and-cost ledger as a research specification. The ledger records decisions separately from broker acknowledgements and executions. It uses a deterministic synthetic example to check arithmetic, then describes how to evaluate richer policies. The equations are elementary bookkeeping under stated assumptions; no claim of a new matching algorithm or measured trading advantage is being made.

The research on execution relative to client reference strategies provides a useful example of why the mandate matters: it formulates the broker’s optimization around a specified reference strategy in an Almgren–Chriss setting with execution risk. Its analytical results belong to that model. They do not make different client benchmarks interchangeable. [3]

Define acceptance criteria before running a comparison. A completed-order cost objective, an inventory penalty and a hard deadline encode different preferences. Record which are mandatory constraints, which are measured outcomes and which appear only in the policy’s training reward.

02 /Keep observations, actions and outcomes on separate clocks

For every decision, preserve the information available to the process at that moment. An exchange timestamp, local receipt timestamp and normalized feature timestamp describe different events. A late message must not be inserted into the earlier decision state merely because its exchange timestamp precedes that decision. Historical replay should reproduce the selected availability rule, including how corrections and delayed messages are handled.

Use separate identifiers for a parent instruction, a child order, an order revision and an execution. The order ledger represents intention and acknowledged state; the execution ledger represents changes to positions and cash. An event describing the same cumulative quantity is not automatically another trade. Specify whether an adapter event contains a cumulative filled amount or an incremental execution amount before applying an update.

Alpaca’s order documentation describes client-provided order identifiers, querying orders by identifiers and streaming updates for maintaining order state. It also describes account buying-power checks. These support an adapter’s order-tracking design; they do not establish how an exchange allocates queue priority or prove that every market event is observable through a broker interface. [7]

A replay harness should attach the input-state version to each decision and preserve the event that changed it. This makes a disagreement reproducible: another engineer can reconstruct what the strategy knew, what it requested and what the ledger subsequently accepted as an execution.

03 /Separate price uncertainty from a monetary cost bound

A latency stress test needs consistent units. Suppose the illustrative local price model has a constant diffusion coefficient sigma_P in dollars per share per square root of second. Over a fixed interval delta_t, its standard-deviation scale is sigma_P times the square root of delta_t. Multiplying sigma_P by delta_t would have the wrong units for a price change.

The displayed scale is not a worst-case bound. Under the additional Gaussian, zero-drift assumption, choosing z gives a corresponding two-sided normal probability for an increment over a fixed interval. Jumps, stochastic volatility, market impact and decision-dependent delays can invalidate that interpretation. A study must specify those assumptions instead of converting a volatility estimate directly into a guaranteed cost interval.

As a synthetic arithmetic check, sigma_P = 0.04 dollars per share per square root of second, delta_t = 0.025 seconds and z = 2 give approximately 0.012649 dollars per share. These inputs are chosen for illustration. They are not measured volatility, a broker latency promise or an estimate of achievable execution quality.

The unit check catches modeling mistakes before calibration. If volatility is expressed in returns instead, specify the price used to convert that relative scale to a price scale. A dollar cost still requires a quantity, an execution rule and a benchmark; the price scale by itself does not supply them.

04 /Use a consistent FIFO quantity recurrence

Consider one price level with known price-time priority, one tagged resting order and no cancellations or revisions. Let a be shares ahead, r the tagged order’s remaining shares and b shares behind. An eligible opposing trade of size v consumes the front of this queue. Its eligible volume must not exceed the displayed quantity represented by these three buckets.

First consume quantity ahead. Only the excess can reach the tagged order, and the fill is capped by its remaining quantity. Further excess consumes the bucket behind it. Apply all expressions to the state before the event. Reusing an already-updated ahead quantity while calculating the same event’s fill would count part of the trade twice.

The paper on aggregate-book FIFO execution explains a separate identification problem: price-level data can omit order identities and cancellation placement needed to recover a unique passive-fill history. Its reported empirical results apply to its reconstruction and dataset. The known-queue toy here exercises basic accounting rather than that reconstruction method. [1]

In an empirical replay, eligible volume must be justified by side, price, venue and sequence information. Aggregate depth reductions may include cancellations; a reduction cannot be treated as a trade without evidence. If priority or the initial queue is unknown, represent that uncertainty explicitly and distinguish assumed fills from directly observed executions.

05 /Reproduce a fully specified synthetic example

Start with 120 shares ahead, a tagged order of 50 shares and 100 shares behind. Four eligible trades at that price have sizes 80, 30, 25 and 50. After the first two events, the ahead bucket falls to 40 and then 10 shares while the tagged order receives no fill. The third event consumes those last 10 ahead and fills 15 tagged shares. The fourth fills the remaining 35 and removes 15 from behind.

The resulting tagged fills are 0, 0, 15 and 35 shares. Total queue depth moves from 270 to 190, 160, 135 and 85 shares. Each reduction equals its event’s trade size, and all state variables remain nonnegative. The snippet includes checks for these conservation properties and rejects an event that exceeds its represented queue.

For a separate illustrative cost calculation, take a buy-arrival reference of 100.00 dollars per share, a fixed tagged fill price of 100.01 and an assumed fee of 0.001 dollars per filled share. The completed 50-share order has price cost 0.50 dollars and fees 0.05 dollars: 0.55 dollars, or 1.1 basis points of its 5,000-dollar arrival notional. The reference can precede joining the queue; it is not asserted to be the contemporaneous midpoint.

Every number in this example is synthetic. Its purpose is reproducible quantity and unit checking. Actual calibration requires market data and the applicable matching rules.

# Synthetic unit-check fixture; no market data or order submission.
from math import isclose, sqrt

def fifo_step(ahead, remaining, behind, eligible_volume):
    if min(ahead, remaining, behind, eligible_volume) < 0:
        raise ValueError("Quantities must be nonnegative")
    if eligible_volume > ahead + remaining + behind:
        raise ValueError("Trade exceeds the represented queue")
    filled = min(remaining, max(0, eligible_volume - ahead))
    next_ahead = max(0, ahead - eligible_volume)
    next_remaining = remaining - filled
    next_behind = behind - max(0, eligible_volume - ahead - remaining)
    assert next_ahead + next_remaining + next_behind == (
        ahead + remaining + behind - eligible_volume)
    return next_ahead, next_remaining, next_behind, filled

ahead, remaining, behind = 120, 50, 100
trace = []
for volume in [80, 30, 25, 50]:
    ahead, remaining, behind, filled = fifo_step(
        ahead, remaining, behind, volume)
    trace.append((ahead, remaining, behind, filled))
assert trace == [(40, 50, 100, 0), (10, 50, 100, 0),
                 (0, 35, 100, 15), (0, 0, 85, 35)]
assert sum(row[3] for row in trace) == 50

synthetic_cost = 50 * (100.01 - 100.00) + 50 * 0.001
synthetic_bps = 10000 * synthetic_cost / (50 * 100.00)
assert isclose(synthetic_cost, 0.55, abs_tol=1e-9)
assert isclose(synthetic_bps, 1.1, abs_tol=1e-9)
price_scale = 2 * 0.04 * sqrt(0.025)
assert isclose(price_scale, 0.012649110640673518, abs_tol=1e-12)
print("Synthetic trace:", trace)
print("Synthetic cost bps:", round(synthetic_bps, 6))

06 /Report remaining inventory alongside shortfall

A cost report must distinguish filled notional from the parent obligation. For a parent quantity Q, let f_j be the absolute size of each fill and R its remaining quantity. Direction d is plus one for buying and minus one for selling. A deadline mark p_T provides an explicitly chosen opportunity-cost benchmark for the unfinished portion. Fees are monetary amounts, including their signs if a rebate is modeled.

The displayed measure includes realized fill differences and the deadline mark of remaining quantity. Its unfilled term is a counterfactual benchmark, not a recorded trade or cash movement. Report that term separately, together with the completion fraction. If the mandate demands actual completion, simulate or observe the terminal execution policy and its liquidity constraints instead of assuming an unlimited fill at the mark.

Closing-auction liquidation research illustrates why completion and terminal inventory deserve separate attention. The supplied study compares learned policies in a simulated continuous-trading and auction environment using inventory-penalized implementation shortfall, distinct from its training objective. These are model-dependent findings; they do not demonstrate a universal live ranking of execution algorithms. [2]

Keep the chosen benchmark fixed across compared policies. Changing the denominator to each policy’s filled notional can conceal differences in completion. Display total parent quantity, filled quantity, fees, benchmark cost and remaining obligation before presenting an aggregate score.

07 /Connect broker events without inventing venue guarantees

A broker adapter sits between the policy and the account ledger. Its responsibilities include request validation, stable identifiers, lifecycle transitions, event deduplication and reconciliation after interruptions. The adapter’s observed messages need not reproduce an exchange’s complete order book. Document what each event actually establishes and what additional state is inferred.

Interactive Brokers’ API solutions page describes trading, market-data, account-management and reporting capabilities and its API offerings. That supports a high-level integration scope. This note does not infer account-specific buying-power formulas, minimum price increments or queue-observation guarantees from that overview. Those details require the relevant technical documentation and account configuration. [5]

Alpaca’s streaming documentation describes trade_updates events for fills, partial fills, cancellations and rejections, including event-specific fields. An implementation should parse the actual schema and distinguish those outcomes rather than treating every message as a fill. [8]

Its working-with-orders documentation demonstrates placing orders and using client order identifiers to track strategy orders. An adapter can keep a durable mapping from its own parent and child identifiers to those broker identifiers. The examples establish API operations, not a promise about event latency or order execution. [9]

After reconnecting, reconcile acknowledged orders and account positions before issuing a replacement target. Store the discrepancy as an event with a clear operator or automated response. A transmission retry should not silently create a second economic order.

08 /Evaluate learned policies against controlled baselines

Use identical parent instructions, information availability, cost definitions and completion rules for every evaluated policy. A deterministic schedule supplies an interpretable baseline. More complex policies can then be examined for incremental value under matched assumptions. Repeated policy selection on the final evaluation interval compromises the comparison, regardless of how sophisticated the policy is.

The analytically solved broker–trader study provides an example of diagnosing a learned controller against a known reference. Its supplied abstract reports that accurately implemented rewards and representational capacity were insufficient for the tested PPO policies in some stochastic settings. Those findings motivate reference-action and reward checks in that setting; they do not prove that PPO generally fails at execution. [4]

For the research ledger, distinguish environmental changes from action changes. If a policy receives auction access, a richer observation set or a different terminal rule, that is a different experiment. Show the baseline with the same access before attributing the outcome to the learning algorithm. Save all random seeds and the budget spent selecting parameters.

Separate calibration, policy selection and final forward evaluation. Predefine the parent-order sampling rule so that canceled, unfinished and operationally failed episodes remain in the denominator. Compare completion, costs and constraint violations by market condition, then inspect whether one unusual episode dominates the result.

09 /Validation, limitations and reproduction records

The synthetic recurrence assumes one fully known FIFO queue, eligible trades at one price and no cancellations, revisions, hidden liquidity or priority changes. It cannot determine historical queue position from aggregated observations. The latency calculation assumes a fixed interval and a simple diffusion. The cost calculation assumes specified prices and fees. Each assumption belongs in the experiment record rather than being hidden behind an engine’s defaults.

A real-data study should version its raw-event manifest, sequence-repair rules, availability-time convention, execution schema and fee schedule. Identify episodes with incomplete coverage. Test stale inputs, delayed acknowledgements, duplicate messages and rejected requests. Every simulated control response should update both the outstanding-order state and the remaining parent obligation.

Keep raw outcomes separate from any reconciliation or repair procedure. Record how often the procedure runs, which quantities it changes and how the comparison responds when repair is disabled. A result that depends on an unverified fill assumption should be reported with that dependency, not promoted as a measured market outcome.

The practical deliverable is a reproducible chain from information to decision, order, execution and cost. Include the executable unit fixture, configured mandate, adapter tests, forward evaluation protocol and a failure ledger. The next research iteration should answer a specific unresolved question with a matched test, so that increasing model complexity remains accountable to evidence.