Pre-Trade Risk Checks

In 2012, a mis-deployed piece of trading software at a major market-making firm sent a flood of erroneous orders into the market in about 45 minutes, before anyone could shut it down, producing a loss reported around $440 million and nearly ending the firm. The software wasn't malicious — it was a bug that no human caught in time, because nothing automated stood between the algorithm's decisions and the exchange. That single incident is a large part of why pre-trade risk checks — automated, microsecond-fast validation of every order before it leaves the building — are now both an industry standard and, in the US, a regulatory requirement under the SEC's Market Access Rule.

What gets checked, and why it has to be fast

A pre-trade risk check sits in the order path between the strategy generating a decision and the gateway sending it to the exchange, validating things like: is the order size within a sane limit for this symbol? Is the price within some percentage of the current market (catching a fat-finger $1.00 limit order on a $100 stock)? Has this account already hit its maximum position or daily loss limit? Is the order rate within the exchange's message throttle? Each check has to run in microseconds, because it sits directly in the latency-critical path of every single order a firm sends — a risk check too slow to matter defeats its own purpose by either being bypassed under time pressure or making the firm uncompetitive on speed. This tension — real risk logic, real-time budget — is why pre-trade checks are typically implemented as simple, hard-coded comparisons in the fastest part of the software or even in hardware (FPGAs), not as a flexible rules engine that would add latency.

Because checks must be both fast and comprehensive, firms layer them: cheap, critical checks (price collar, size limit) run inline on every order with near-zero added latency, while expensive aggregate checks (running position, cumulative daily loss) are updated asynchronously and simply consulted rather than recomputed each time.

Worked example: catching a fat finger

A trader intends to enter a limit order to buy 100 shares at $50.00 but a decimal-point slip in the order-entry system generates an order to buy 100,000 shares at $500.00 — a notional error of roughly $100{,}000 \times 500 - 100 \times 50 = 49{,}995{,}000$, nearly $50 million more exposure than intended. A price-collar check comparing the order's $500.00 limit against the current market price of roughly $50 immediately flags it as more than 10× away from the reference price and rejects the order before it ever reaches the exchange — the entire check-and-reject cycle completing in microseconds, long before a human could have noticed the typo on a screen.

What this means in practice

Pre-trade risk checks are the last automated line of defense against software bugs and human error, and regulators treat them as mandatory because self-policing without them has repeatedly failed at real cost. The design challenge is specific: keep checks fast enough to survive the critical path while still catching what matters — a system with no checks is one bad deployment from a career-ending loss, and one with slow checks can't compete on speed.