Electronic Trading (etrade): execution and market-making research

A research platform for the two businesses at the centre of electronic trading: executing large orders at low cost and making markets profitably. It starts from the canonical models, Almgren-Chriss (2000) optimal execution and Avellaneda-Stoikov (2008) market making, plus implementation-shortfall analytics, and builds outward towards what decides money in practice: realistic costs, informed flow, fees and ticks, fair-value signals and measurement after the fact.

Everything is implemented four times, in Python (the reference), C++, Rust and Java, from one pinned contract (API_SPEC.md), and held together by shared golden values checked in CI on Linux, Windows and macOS.

Where it stands. The models are exact and cross-validated; parameters can be stated in market units (price, tick, spread, daily volatility, ADV) with results in basis points. Execution now has a power-law impact model (square-root by default) with intraday volume curves, alpha-aware schedules and a pre-trade cost report; at alpha = 1 it reproduces the Almgren-Chriss trajectory (holdings within 1e-10 of X, costs within 1e-12 relative, asserted in every suite). Post-trade TCA measures slippage against four benchmarks, markouts and participation, and compares algorithms with a Welch t-test. Calibration estimators turn recorded data into model inputs, and three presets are fitted to one NASDAQ ITCH day (AAPL, MSFT, QQQ on 2019-12-30, with the caveats of API_SPEC.md Section 11.6). Execution extensions add transient (decaying) impact, adaptive re-planning and internalisation. Market making runs with a price grid, maker fees or rebates, stale quotes, informed flow and a fair-value signal, with an exact PnL attribution and markouts, and GLFT quotes beside A-S. Limit-order placement covers queue fill probability, the choice between posting and crossing, and liquidation with limit and market orders. Hedged market making lays inventory off in a correlated instrument, with the hedge PnL and costs in the same exact attribution, under a loss limit, a position limit, a quote throttle and a kill switch. The other five presets and the pinned volume curve are illustrative, not fitted to data.

Documentation site: https://ashjha0.github.io/electronic-trading/ (the guide, cookbook, contract, architecture notes and changelog, built from the Markdown files in this repository).

Every demo prints this for a US large cap selling 5% of ADV in one day with square-root impact and a U-shaped volume curve (API_SPEC.md Section 8):

At lambda = 0 the optimum matches VWAP to the printed precision: with no risk penalty and no drift, the temporary cost is minimised by trading in proportion to liquidity (the small permanent-impact term moves it slightly). The closed-form square-root-law estimate is 33.54 bps. With a 50 bps/day adverse drift behind the order, the drift-aware schedule costs 52.13 bps against 57.31 bps for VWAP, a saving of 5.18 bps.

Produced by every demo from data/presets.json (sell orders over one day; A-S spread at the open and at the close of the session):

The fitted rows take price, spread, volatility, volume and the fill intensity from one day of NASDAQ data; order size, risk aversion and the market-making settings follow the US large-cap and ETF templates. One day on one venue in the week after Christmas: read them as realistic magnitudes, not as estimates with known error (LEARN.md Section 3.10).

Every demo prints this friction ledger for the US large-cap A-S preset (one-share quotes, 5-second steps, one day; API_SPEC.md Section 9). Dollars per day, 20,000-path Python sample; each row adds or changes one friction, and every path satisfies PnL = spread + fees + inventory - liquidation exactly:

Informed flow raises spread capture and lowers PnL: the markout, the loss in the step after each fill, takes it back, and the inventory skew does not prevent it. Quotes 5 seconds stale are picked off and lose money on every day. The C++, Rust and Java demos print the same table from their own 5,000-path samples (LEARN.md Sections 6.7-6.12 read it row by row).

The same book (1-cent tick, 0.2-cent rebate, 15% informed arrivals), hedged in an instrument with correlation 0.9 at half a cent a share, or run under one risk control (API_SPEC.md Section 14). Dollars per day, 20,000-path Python sample (the hedging_golden.json reference); the 5% quantile is the pinned type-7 estimator. Every path satisfies PnL = spread + fees + inventory - liquidation + hedge PnL - hedge costs - risk costs exactly:

The hedge halves the A-S skew and cuts the fixed-spread book's standard deviation by more than half, for about 3 a day in hedge costs. The loss and position limits lift the 5% quantile from -40 to about -6; the loss limit pays for it in mean, the position limit does not here. The throttle leaves stale quotes to be picked off. Every demo prints these cases from its own 2,000-path sample with the control trigger counts (LEARN.md Section 6.13; COOKBOOK recipes 26 and 27).

1. F1. Market units and realistic presets (done; API_SPEC.md Section 7).
2. F2. Execution a desk would recognise (done; Section 8): square-root and power-law impact, alpha-aware (urgency) schedules, intraday volume curve, pre-trade cost report.
3. F3. Market making that can lose money (done; Section 9): informed flow, fees and rebates, tick grid, latency, PnL attribution, markouts, fair-value helpers, GLFT quotes.
4. F4. Calibration on recorded order-book data and post-trade TCA (done; Sections 10 and 11): benchmark slippage, markouts, participation, Welch A/B comparison; volume, volatility, spread and fill-intensity estimators; three presets fitted to one NASDAQ ITCH day.
5. F5. Strategy extensions (done; Sections 12, 13 and 14): adaptive scheduling, transient impact, internalisation, limit-order placement, hedged market making and risk controls (loss limit, position limit, quote throttle, kill switch).

Not investment advice and not a trading system; see the usage notes below.

electronic-trading/
  README.md                # this file
  LEARN.md                 # theory: microstructure, AC, A-S, impact, calibration, TCA, frictions, placement, hedging, regulation
  COOKBOOK.md              # task-oriented recipes in all four languages
  API_SPEC.md              # the pinned cross-language contract (normative)
  CHANGELOG.md
  mkdocs.yml               # documentation site (MkDocs Material)
  docs/
    ARCHITECTURE.md        # design, data flow, numerics, testing strategy
    GITHUB_PAGES.md        # how the docs site is built and published
    index.html             # stand-alone landing page (served until Pages switches to the Actions build)
    site/                  # MkDocs landing page and stylesheet
    diagrams/*.mmd         # raw Mermaid sources
  data/
    params_liquid.json     # liquid large-cap parameter set
    params_illiquid.json   # small-cap illiquid parameter set
    params_fx.json         # FX-like parameter set (tight spread, high k)
    parent_order.json      # parent order, lambda grid, IS decomposition inputs
    presets.json           # market-unit presets (5 illustrative, 3 fitted to one ITCH day)
    calibration/fit_itch.py           # ITCH dataset -> fitted aggregates (tooling, Python only)
    calibration/fitted_20191230.json  # the fitted aggregates (no raw data)
    generate_data.py       # regenerates data + golden values (seeded)
    generate_market.py     # regenerates presets.json + market golden cases
    generate_impact.py     # regenerates the power-law impact golden cases
    generate_tca.py  generate_calibration.py  generate_execution.py
    generate_mm.py  generate_placement.py  generate_hedging.py
    golden/golden.json     # 19 cross-language golden cases
    golden/market_golden.json       # 15 market-unit golden cases
    golden/impact_golden.json       # 8 power-law impact golden cases
    golden/tca_golden.json          # 11 TCA golden cases
    golden/calibration_golden.json  # 9 calibration golden cases
    golden/execution_golden.json    # 8 execution-extension golden cases
    golden/mm_golden.json           # 14 market-making golden cases
    golden/placement_golden.json    # 11 limit-order placement golden cases
    golden/hedging_golden.json      # 18 hedging and risk-control golden cases
  python/
    src/etrade/            # reference package (almgren_chriss, avellaneda_stoikov, analytics, impact, market, tca, calibration, execution, mm, placement, hedging)
    tests/                 # pytest suites incl. golden-value tests
    demo.py                # end-to-end demo report
    pyproject.toml  requirements.txt
  cpp/
    include/etrade/*.hpp   # C++26 library headers
    src/*.cpp  tests/*.cpp
    CMakeLists.txt  build.sh
  rust/
    Cargo.toml  src/lib.rs src/*.rs
    examples/demo.rs  tests/*.rs
  java/
    pom.xml
    src/main/java/io/github/ashjha0/etrade/*.java
    src/test/java/io/github/ashjha0/etrade/*Test.java

Every command below runs in CI on Linux, Windows and macOS on every push and pull request (.github/workflows/ci.yml).

pip install -e "python[dev]"         # installs etrade + pytest, ruff, mypy
python python/demo.py                # run the demo
pytest python                        # run the tests (575 tests; 6 benchmarks more with pytest-benchmark)
ruff check . && (cd python && mypy)  # lint and type-check

cmake -S cpp -B build -DCMAKE_BUILD_TYPE=Release   # GoogleTest is fetched if not installed
cmake --build build --config Release --parallel
ctest --test-dir build -C Release --output-on-failure   # run the tests (191 tests)

The demo is build/etrade_demo (build/Release/etrade_demo.exe with MSVC). Options: -DETRADE_BUILD_TESTS=OFF, -DETRADE_WERROR=ON, -DETRADE_SANITIZE=ON (ASan + UBSan, GCC/Clang).

cd rust
cargo test --release                 # run the tests (290 tests, 16 of them doc-tests)
cargo run --release --example demo   # run the demo

cd java
mvn verify                           # compile with -Xlint:all -Werror and run the tests (333 tests)
mvn -q exec:java                     # run the demo

pip install -r docs/site/requirements.txt
mkdocs serve                         # preview at http://127.0.0.1:8000/electronic-trading/
mkdocs build --strict                # what the Docs workflow runs on every PR

Test counts above are the suite sizes measured by running each suite on 2026-10-30 (Python 575, C++ 191, Rust 290, Java 333; 1,389 in total; the six Python benchmarks run only when pytest-benchmark is installed); every suite loads the same ten golden files, 120 cases: 19 model, 7 whole-trajectory, 15 market, 8 impact, 11 TCA, 9 calibration, 8 execution, 14 market-making, 11 placement and 18 hedging.

etrade demo — Almgren-Chriss execution & Avellaneda-Stoikov market making

=== Almgren-Chriss optimal trajectories (sell 1.0e6 shares, N=5) ======
 lambda_ra     kappa  half-life | holdings x_j (thousands)
   0.0e+00    0.0000        inf |   1000.0    800.0    600.0    400.0    200.0      0.0
   5.0e-07    0.4325      2.312 |   1000.0    636.9    394.8    227.8    104.0      0.0
   2.0e-06    0.8463      1.182 |   1000.0    428.6    182.9     76.3     27.6      0.0
   1.0e-05    1.7267      0.579 |   1000.0    177.9     31.6      5.6      1.0      0.0

=== Efficient frontier of execution (E[cost] vs sqrt(Var[cost])) ======
 lambda_ra      E[cost] $    sqrt(Var) $     kappa
   0.0e+00        600,000      1,040,673    0.0000
   1.0e-08        600,089      1,032,060    0.0616
   1.0e-07        607,557        961,623    0.1946
   5.0e-07        705,633        750,597    0.4325
   1.0e-06        848,727        603,431    0.6071
   2.0e-06      1,078,215        449,368    0.8463
   5.0e-06      1,472,888        272,687    1.2876
   1.0e-05      1,782,711        171,712    1.7267

=== Baselines: optimal vs TWAP vs POV vs instantaneous ================
    strategy      E[cost] $    sqrt(Var) $
  AC optimal      1,078,215        449,368
        TWAP        600,000      1,040,673
     POV 15%        941,406        639,488
     Instant      2,500,000              0
MC check (20k paths): E=1,075,336 (closed 1,078,215, se 3,177); Var/1e9=201.9 (closed 201.9)

=== Avellaneda-Stoikov market making (liquid large-cap) ===============
params: s0=100.0 sigma=2.0 gamma=0.1 k=1.5 A=140.0 T=1.0 dt=0.005 q_max=20
example quote at t=0, q=+3: bid=97.9546 ask=99.6454 (mid 100.0, reservation 98.8000)
         agent   mean PnL   std PnL  Sharpe  mean|q| mean max|q|   rms q   fills
           A-S    55.9191    6.3677    8.78    1.063       4.096   1.452    85.6
  fixed-spread    57.8418   12.8145    4.51    4.226       9.499   4.964    81.8
inventory control: A-S rms q = 1.452 vs fixed 4.964 (similar PnL, much tighter inventory)
stress (vol x2 after T/2): std PnL 6.3677 -> 7.9045

[FX-like market-making section omitted]

=== Implementation-shortfall decomposition (sell parent order) ========
decision 100.00, arrival 99.50, close 98.80; executed 900/1000
         delay:     450.00 $
       trading:     230.00 $
   opportunity:     120.00 $
         TOTAL:     800.00 $
participation rate example: 120k / 1.5m = 8.00%

=== Market-impact regression (cost/share vs participation, native OLS)
fitted: cost = 0.5035 + 7.9707 * participation (true 0.50 + 8.00), R^2 = 0.9934, n = 25

[presets, pre-trade and friction-ledger sections omitted: they are the tables at the top;
 TCA, calibration, execution-extension, placement and hedging sections omitted]

done.

The demo prints every section in full; the excerpt leaves out the FX-like market-making run, the tables already shown at the top of this file, and the sections for Sections 10-14 of the contract, whose numbers LEARN.md and COOKBOOK.md quote. The simulation rows are 2,000-path samples from the Python demo; the C++, Rust and Java demos print their own samples (e.g. A-S fills 85.2 / 85.5 / 85.3) that agree within the statistical bands. fills is the total number of fills per path, both sides counted.

data/golden/golden.json holds 19 named cases with inputs, expected outputs and a tolerance. Every language's test suite loads the same file and asserts agreement, so all four implementations are pinned to identical numbers:

• Exact cases (closed forms, deterministic constructions): each key must satisfy |actual - expected| <= tol * max(1, |expected|) with tol between 1e-10 and 1e-12. Examples: AC kappa/x_j/n_1/E/Var for two parameter sets, kappa at millisecond-scale tau (where the naive acosh form loses 8 digits), TWAP/POV costs, the lambda_ra = 0 = TWAP identity, A-S reservation price / spread / fill probability, both IS decompositions, the impact-regression fit on pinned RNG-free synthetic fills.
• Statistical cases (Monte Carlo): the file stores the Python 20,000-path reference value plus its standard error per statistic. Ports use their own native RNG (C++ std::mt19937_64, Rust ChaCha12Rng, Java SplittableRandom) with the same pinned logical draw order, run M >= 2000 paths, and must satisfy |stat - ref| <= 4*sqrt(se_ref^2 + se_own^2). Sample values differ across languages by design; distributions must agree.

Each suite additionally verifies determinism (same seed twice gives identical results), property-style invariants (trajectory monotonicity, inventory cap respected at every step, IS decomposition identity and price-shift invariance, frontier monotonicity), the literature identity between the Almgren-Chriss closed forms and the discrete sums, overflow/underflow safety at kappa*T > 2500, and every validation rule of API_SPEC.md Section 6 (non-finite inputs, size bounds, non-liquidating schedules, participation above 1, ...).

Eight further golden files follow the same schema and comparison rule: market_golden.json (15 market-unit cases, 1e-12, API_SPEC.md Sections 7.4 and 11.7), impact_golden.json (8 power-law impact cases, 1e-9, Section 8.5), tca_golden.json (11 cases, 1e-12, Section 10.6), calibration_golden.json (9 cases, 1e-12, Section 11.7), execution_golden.json (8 cases, exact at 1e-9 and statistical at 4 SE, Section 12.4), mm_golden.json (14 cases, exact at 1e-12 and statistical at 4 SE, Section 9.7), placement_golden.json (11 cases, exact at 1e-10 and statistical at 4 SE, Section 13.4) and hedging_golden.json (18 cases, exact at 1e-12 and statistical at 4 SE, Section 14.7). Each has a generator, data/generate_<name>.py (generate_data.py for golden.json); docs/ARCHITECTURE.md lists them all. Regenerate on Linux or macOS: the committed values come from there, and the last bit of some libm results differs on Windows.

What a practitioner gets, and what is deliberately left out:

• Scope. Almgren-Chriss (2000) static mean-variance execution with linear temporary and permanent impact and an arithmetic random walk; Avellaneda-Stoikov (2008) finite-horizon market making with exponential arrival intensities, plus a hard inventory cap and a terminal liquidation penalty; Perold (1988) implementation-shortfall decomposition; participation rate; a two-variable OLS; a power-law (square-root by default) generalisation of the execution problem with intraday liquidity weights and an adverse drift, solved numerically (API_SPEC.md Section 8); conversion from market units with reporting in basis points (Section 7); post-trade TCA (Section 10); calibration estimators on plain arrays (Section 11); transient impact with exponential resilience, adaptive re-planning under a drift signal and partial fills, and internalisation (Section 12); market making with a tick grid, fees, stale quotes, informed flow and a signal of given accuracy (Section 9); queue fill probability and liquidation with limit and market orders (Section 13); hedging in one correlated instrument with a fixed, known correlation, and risk controls checked once per step (Section 14). Nothing else: no venues, lots or order book; the frictions are stylised switches, not a matching engine.
• Units and conventions (API_SPEC.md Section 0): tau, dt, T are in an abstract time unit (the bundled sets use 1 = one trading day) — nothing ties them to a clock or a calendar (no day-count conventions or holidays; the intraday volume curve of Section 8 is a vector of per-interval weights, not a clock); sigma is arithmetic (currency per share per sqrt(time unit)); prices may go negative; AC shares are fractional (no lot rounding); A-S fills are one unit each; all costs are in currency (positive = loss); half_life is the paper's 1/kappa (an e-folding time), not ln 2 / kappa.
• Sell programs only in AC (X >= 0); mirror prices by hand for a buy program. The paper's fixed cost epsilon*sum|n_j| (half-spread, fees) is omitted — it equals epsilon*X for any one-sided schedule and does not change the trajectory; add it to E[IS] if you report total cost.
• A-S fill probability is the exact thinned 1 - exp(-lambda*dt), not the paper's first-order lambda*dt — mean PnL is ~12% below the paper's Table 1 for that reason; the PnL standard deviations agree.
• Validated at every public entry point (same rules in all four languages): NaN/inf anywhere, negative-where-invalid, empty grids, non-liquidating schedules, participation above 1, and every size beyond the pinned bounds (10 million intervals / POV clips / steps / paths) are input errors — Python ValueError, C++ std::invalid_argument (std::domain_error for the AC validity condition), Rust Err(EtradeError) (no panics), Java IllegalArgumentException. No function returns NaN or infinity from valid finite inputs; the AC trajectory is finite for any kappa*T (the sinh ratio is evaluated in exp/expm1 form) and kappa is free of cancellation for any tau (log1p form).
• Determinism. Same seed, same results within a language. Python is stable across NumPy releases (PCG64 is versioned) and Rust across rand 0.8.x; Java is guaranteed within one JVM build and platform (nextGaussian and Math.* are not bit-specified); C++ is deterministic per standard library because std::normal_distribution is implementation-defined. Cross-language agreement is statistical (4-SE bands), never bitwise.
• What is verified. 1,389 tests across the four suites: 120 shared golden cases (19 model at 1e-10..1e-12, 7 whole-trajectory at 1e-10 or 1e-9, 15 market-unit at 1e-12, 8 power-law impact at 1e-9, 11 TCA and 9 calibration at 1e-12, 8 execution at 1e-9 or 4 SE, 14 market-making at 1e-12 or 4 SE, 11 placement at 1e-10 or 4 SE, 18 hedging at 1e-12 or 4 SE), the paper's closed forms against the discrete sums at 1e-12, Monte Carlo against closed forms at 4 SE, and every validation rule; in the Python suite, the power-law solver against SciPy's constrained optimiser and the t-test against SciPy. What is not verified: the impact parameters eta, gamma_p, alpha and Y against real parent orders (the fitted presets take them from the literature), the sampling error of the one-day fits, and behaviour outside the documented model assumptions (LEARN.md Section 7).

Papers and standards the code implements or the documentation relies on:

• R. Almgren and N. Chriss (2000), "Optimal execution of portfolio transactions", Journal of Risk 3(2), 5–39. https://doi.org/10.21314/JOR.2001.041 (author copy: https://www.math.nyu.edu/~almgren/papers/optliq.pdf)
• M. Avellaneda and S. Stoikov (2008), "High-frequency trading in a limit order book", Quantitative Finance 8(3), 217–224. https://doi.org/10.1080/14697680701381228
• A. F. Perold (1988), "The implementation shortfall: paper versus reality", Journal of Portfolio Management 14(3), 4–9. https://doi.org/10.3905/jpm.1988.409150
• W. H. Wagner and M. Edwards (1993), "Best execution", Financial Analysts Journal 49(1), 65–71. https://doi.org/10.2469/faj.v49.n1.65 (the delay / trading / opportunity naming of the shortfall components)
• O. Guéant, C.-A. Lehalle and J. Fernandez-Tapia (2013), "Dealing with the inventory risk: a solution to the market making problem", Mathematics and Financial Economics 7(4), 477–507. https://doi.org/10.1007/s11579-012-0087-0 (the inventory-capped variant motivating q_max, and the GLFT quotes of Section 9.3)
• A. A. Obizhaeva and J. Wang (2013), "Optimal trading strategy and supply/demand dynamics", Journal of Financial Markets 16(1), 1–32 (transient impact, API_SPEC.md Section 12.1).
• R. Almgren and J. Lorenz (2007), "Adaptive arrival price", Trading 2007(1), 59–66 (adaptive execution, Section 12.2).
• T. G. Andersen, T. Bollerslev, F. X. Diebold and P. Labys (2001), "The distribution of realized exchange rate volatility", Journal of the American Statistical Association 96(453), 42–55 (realised variance, Section 11.3).
• B. L. Welch (1947), "The generalization of 'Student's' problem when several different population variances are involved", Biometrika 34(1–2), 28–35 (the A/B test, Section 10.4).
• L. R. Glosten and P. R. Milgrom (1985), "Bid, ask and transaction prices in a specialist market with heterogeneously informed traders", Journal of Financial Economics 14(1), 71–100 (adverse selection, Section 9).
• R. Cont, S. Stoikov and R. Talreja (2010), "A stochastic model for order book dynamics", Operations Research 58(3), 549–563 (the queue model, Section 13.1).
• A. Cartea and S. Jaimungal (2015), "Optimal execution with limit and market orders", Quantitative Finance 15(8), 1279–1291 (liquidation with both order types, Section 13.3).
• L. H. Ederington (1979), "The hedging performance of the new futures markets", Journal of Finance 34(1), 157–170. https://doi.org/10.1111/j.1540-6261.1979.tb02077.x (the minimum-variance hedge ratio, Section 14.3)
• O. Guéant (2017), The Financial Mathematics of Market Liquidity: From Optimal Execution to Market Making, Chapman and Hall/CRC (multi-asset market making, the skew on the risk-equivalent exposure of Section 14.3).
• R. J. Hyndman and Y. Fan (1996), "Sample quantiles in statistical packages", The American Statistician 50(4), 361–365. https://doi.org/10.1080/00031305.1996.10473566 (the type-7 quantile, Section 14.6)
• NASDAQ TotalView-ITCH 5.0 sample file 12302019.NASDAQ_ITCH50 (emi.nasdaq.com/ITCH/), the source of the fitted presets (Section 11.6).
• Regulatory texts cited in LEARN.md Section 12: Directive 2014/65/EU (MiFID II), Art. 17 and Art. 27; U.S. SEC Regulation NMS (17 CFR 242.600 ff.), Rules 605/606; SEC Rule 15c3-5 (Market Access).

MIT License — see the LICENSE file (Copyright (c) 2026 Ashish Jha). Provided without warranty of any kind; this is a validated reference implementation of published models, not investment advice and not an order-management or risk system.