Would the Stock Market Be Fairer If It Paused?

Most investors picture a stock exchange as a place where buyers meet sellers. The modern version is less romantic. It is a room of computers processing messages in sequence — buy, sell, cancel, replace — all day long.

The sequence matters. When two firms react to the same news, the first order to reach the exchange trades at the old price. The second may arrive a few millionths of a second later and find the opportunity gone. That difference is invisible to a person watching a screen. It is not invisible to a trading firm.

Nasdaq advertises connections with round-trip latency below 50 microseconds — one microsecond being one-millionth of a second. At that scale firms spend heavily on faster code, shorter network paths and specialized hardware. Not to understand a company better, but to act on public information before a competitor does. Which led economists to a strange question. What if the market stopped pretending that every infinitesimal moment must have a winner?

The market's race condition

A stock is offered at $100. News arrives that makes $100.05 the better estimate of its value. Several firms see the same news and race to buy at $100 before the quote changes. Only one succeeds, and its advantage may be nothing more than a slightly faster connection. The seller at $100 loses exactly what the fast buyer gains.

This is latency arbitrage, and it is not the classic picture of an investor discovering something about a business. The information can be public and seen by everyone at once. The profit comes from winning the race to orders that have not yet been updated. Research on London Stock Exchange message data found these races happen about once a minute per FTSE 100 stock, each lasting 5 to 10 microseconds. They accounted for roughly one-fifth of trading volume in that sample.

The deeper problem is structural. A continuous market creates an endless incentive to be marginally faster, because when one firm upgrades its rivals must consider upgrading too. The social value of the next microsecond may be small even when its private value is large.

A market that blinks

Frequent batch auctions propose a different design. Rather than process orders one at a time, the exchange collects them for a brief interval. Perhaps a tenth of a second. Then it executes everything compatible at a single price.

To a human the market would still look continuous, because a tenth of a second is faster than a blink. But computers racing over microseconds would land in the same batch, where arriving 10 microseconds earlier buys no priority at all. Firms would have to compete on price instead of speed. In theory that shrinks the prize from latency arbitrage, and with it the reason to spend on the arms race.

Changing a market's design invites new problems, though. An interval adds delay. Traders may cluster or pull orders just before an auction. A design that stops one kind of gaming can open the door to another. And fairness is not one statistic: a market can be equal in access and expensive to use, or execute quickly and still leave slower participants exposed. So the useful question is not whether batch auctions sound fair. It is what the design does to outcomes you can measure.

Building two miniature markets

The experiment builds two markets, populates them with the same simulated traders, and feeds them the same news. The first is a continuous order book, where orders execute in the sequence they arrive. The second gathers orders into short intervals and clears each at a uniform price. Four conditions vary: the speed advantage the fastest traders hold, how much ordinary liquidity is present, how often the public price moves, and how long the interval lasts. Every world runs both ways with the same seed, so the matching rule is the only difference.

The latency race did not shrink. It ceased to exist. When everyone in an interval clears together at one price, no stale price is left to trade against. The share of volume from picking off stale quotes is exactly zero at every interval tested. That part of the theory is not in doubt.

What is in doubt is whether anyone benefits.

The dial a regulator would actually have to set

The interval is the design's one real parameter, and its effect on price accuracy is not a straight line. This is the least obvious result in the study, and the one most likely to be assumed away.

Make the interval long and the visible price goes stale between auctions. Make it very short and each auction gathers too few orders to aggregate anything, clearing on a thin and unrepresentative handful. The least-bad interval sits somewhere in between, and where it falls depends on how fast orders arrive.

That thinness has a second consequence, and it is the one that should trouble anyone drawn to batching as a fix. A very short batch interval does not remove the value of being fast. The race share is zero. But in a thin auction the clearing price sits close to the stale quote anyway. A fast trader who reacts to news before the auction closes still captures much of the move. At a one-millisecond interval, fast traders still earn 6,507 ticks against 10,133 in the continuous market. Only when the interval is long enough to gather real order flow does speed stop paying.

Batching does not create wealth. It changes who ends up with it.

Reading the ledger

The three participant groups sum to zero in every run. That constraint turns an argument about fairness into an accounting question. If fast traders stop earning 10,133 ticks, where does it go?

In the continuous market, fast traders take 10,133 and market makers lose 2,009, while ordinary investors pay 8,124 through stale-quote losses. Batch at 100 milliseconds and fast traders drop to 762 — but market makers swing from −2,009 to +9,141, and investors are still down 9,904. The prize did not return to the people who had been paying it. It moved to the market makers, who no longer get picked off, and who can quote a tighter spread precisely because they no longer have to charge for that risk.

Whether that counts as an improvement rests on a question the simulation cannot answer: whether market makers compete that windfall away into tighter spreads still, or simply keep it. This model holds behaviour fixed. It cannot tell you.

What robustness did and did not establish

Across every combination of four speed advantages, three news rates, three liquidity levels and 12 seeds, the direction of each effect held almost perfectly. Batching improved the race share, stale-quote losses and quoted spread in essentially every world. It worsened fill rate, execution delay and price-discovery error in essentially every world.

The one measure that genuinely splits is the one investors care about most. Implementation shortfall — what it actually costs to trade — improved under batching in only 42% of worlds. That is close enough to a coin flip that only one summary is honest. Batching's effect on execution cost depends on the world you are in, and this study cannot tell you which world that is.

Ticks per simulation, means over paired worlds. Note that discovery error falls from 14.03 to 7.19 and then rises again to 9.79 — the interval is a real design choice, not a limit to be minimised.

Transparency is arriving before consensus

The debate is timely because U.S. execution reporting is changing. The Securities and Exchange Commission expanded Rule 605, which governs public execution-quality reports, with an August 1, 2026 compliance date. Better reporting does not pick a market design, but it makes the cost and quality of execution easier to compare.

For ordinary investors the lesson is not that fast traders are harmful or that slow markets are better. High-speed market makers tighten spreads and connect prices across venues — the same technology both supplies liquidity and races to remove it.

The rules of a market shape what its participants compete to do. A continuous market rewards being first. A batch market tries to make price matter more than microscopic differences in arrival time.

Markets are human institutions expressed in software. They do not have to run the only way we are used to seeing them run.

What this simulation cannot support

It is a model, and a deliberately small one: three trader types, one asset, one venue, no hidden orders, no order types beyond limit and market, no fees, no rebates, no queue jumping, no strategic order splitting.

And nobody in it changes behaviour in response to the mechanism, which is the limitation that matters most. Real traders would adapt to a batch auction. They would learn to cluster orders at the end of an interval, to split across intervals, or to move to whichever venue served them better. Holding behaviour fixed and changing only the matching rule isolates the mechanism's direct effect and says nothing about the equilibrium that would follow.

Fragmentation is not modelled at all, and it is probably the important question. A batch venue competing alongside continuous ones is a harder problem, and a design that is better in isolation can leave investors worse off if liquidity splits between venues.

Finally, the tie-breaking rule is a modelling choice with visible consequences. When several prices achieve the same volume, this implementation clears at the midpoint of that range. Some real auctions instead pick the price closest to the previous clearing price, which would reduce the thin-auction effect above. The rule is stated, tested, and deliberately not tuned to improve the result.

Companion repository continuous-vs-batch-markets, published with the verified results.

Repository specification

Build a publication-quality, fully reproducible GitHub repository named continuous-vs-batch-markets. It must compare a continuous limit-order-book market with a frequent uniform-price batch-auction market in a controlled agent-based simulation. The goal is explanation and causal isolation inside the model, not a claim that the simulator reproduces every feature of a real exchange.

Implement the reference simulator in Python 3.12 with typed, modular code. Both market mechanisms must receive identical seeded streams of fundamental-value changes, liquidity orders, cancellations and trader decisions. The continuous book should use price-time priority. The batch venue should collect orders for configurable intervals and clear at a single price that maximizes executable volume, with deterministic tie-breaking documented and tested.

Include at least three trader types: ordinary liquidity traders with heterogeneous arrival times and reservation prices; informed or news-reacting traders who observe fundamental-value changes; and fast arbitrageurs who observe the same public signal but have lower reaction latency. Make every behavioral assumption explicit in a configuration file. Avoid calibrating parameters to create a preferred result.

Run a parameter grid covering at least four latency advantages, four batch intervals, three news intensities and three liquidity conditions, with enough random seeds to report simulation uncertainty. Measure quoted and effective spreads, implementation shortfall, fill rate, execution delay, price-discovery error, volatility, fast-trader profits, stale-quote losses and the share of volume arising from latency races. Report both investor outcomes and market-maker outcomes.

Produce at least five publication-ready SVG and PNG figures: a visual explanation of continuous versus batch matching; latency-race profits by speed advantage; investor execution cost by mechanism; the trade-off between delay and price accuracy by batch interval; and a robustness heat map. Write exact article fields to reports/article_values.md, including the baseline parameterization, uncertainty intervals, sensitivity results and limitations.

Validate the matching engines with unit tests for price priority, time priority, partial fills, cancellations, crossed books, batch clearing, ties and conservation of cash/inventory. Add property-based tests where useful. Record runtime and seed for every simulation. Include README.md, LICENSE, pyproject.toml, Makefile, configs/, src/, tests/, reports/figures/, notebooks/, and GitHub Actions. make reproduce must regenerate every reported table and chart. The README should explain the mechanism in plain English before presenting the equations or implementation.