Pre-trade risk and trading controls in HFT systems

Why automated trading needs a distinct control layer

Discretionary trading has a natural rate limit: a human can only act so fast. Automated trading removes that limit, and with it the informal protection it provided. A strategy with a sign error, a feed handler that misreads a price, a stale reference dataset or a deployment of the wrong configuration can all produce correct-looking orders at full system rate.

The failures that have cost firms most were rarely sophisticated. The recurring pattern is mundane: a deployment inconsistency, a repurposed flag, a disabled safeguard, a stale limit that nobody owned. What turns these into disasters is the absence of a bound on how wrong things can get before something stops them.

This is why the control layer is designed as an independent system rather than as a feature of the strategy. A strategy cannot be trusted to limit itself, because the scenario the limits exist for is precisely the one where the strategy is behaving incorrectly.

The layers of control

Controls are deliberately duplicated across independent layers, on the assumption that any one of them can fail or be misconfigured.

The gateway layer is the one firms own and the one that matters most, because it is the last point under the firm's control through which every order must pass.

The checks themselves

Order-level validation. Price within a band of a reference price, quantity below a maximum, notional below a cap, instrument permitted for this strategy, order type permitted, account and tag valid. These catch the single catastrophic order and are cheap to evaluate.

Rate and message controls. Orders per second, messages per second, and order-to-trade ratio, applied per strategy and in aggregate. These catch runaway loops, which are the most common automated failure mode. Many venues impose their own message limits with financial penalties, so the firm's internal throttle also protects a commercial relationship.

Position limits. Per instrument, per strategy, per desk and firm-wide, usually with both a gross and a net form. The engineering difficulty is maintaining an accurate position at the gateway in real time, including orders in flight, since a check against a stale position is not a check.

Loss limits. Intraday realised and unrealised loss thresholds, typically tiered: a soft limit that alerts and restricts to risk-reducing orders only, and a hard limit that stops the strategy. Tiering matters, because a strategy that is stopped dead while holding inventory has converted a trading loss into an unmanaged position.

Self-trade prevention. Where a firm runs multiple strategies on the same instrument, it must avoid trading against itself, which is both costly and a conduct issue. Prevention is implemented internally and, on most venues, also available as an exchange service.

Duplicate and sequence checks. Detection of repeated orders, out-of-sequence messages and replays, typically caught at the session layer.

Cancel-on-disconnect and session integrity. If the connection to the venue drops, resting orders must be cancelled rather than left live. Most exchanges provide this; a firm that relies on it alone should know exactly how it behaves.

Kill switches

Every automated trading operation needs a way to stop, and the engineering requirements are specific:

• Reachable in seconds by a human who may not be an engineer, through an interface that is always available.
• Independent of the trading system. If the kill switch is a function of the application that is malfunctioning, it may not work.
• Granular. Stop one strategy, one instrument, one desk, or everything. An all-or-nothing switch gets used too late because the cost of using it is too high.
• Risk-reducing-only as an intermediate state. Frequently more useful than a hard stop, because it allows a position to be unwound while preventing new risk.
• Tested. A kill switch that has never been exercised in production conditions is an assumption, not a control. Mature firms test theirs on a schedule.

The decision rights matter as much as the mechanism. It should be unambiguous, in advance and in writing, who can pull it, under what conditions, and that nobody will be penalised for pulling it when a reasonable person would have. Hesitation while authority is established is where the losses accumulate.

Where the controls sit, and the latency argument

There is a standing tension between risk and trading over the cost of inline checks, and it is usually resolved with a combination of three approaches.

Pre-compute everything possible. Limits are resolved to simple numeric comparisons at configuration time, so the hot path performs integer comparisons against values already in cache rather than any lookup or computation.

Push the strictest checks into hardware. Where an FPGA already sits on the order path, the price band, size and rate checks can be implemented there at a cost of tens of nanoseconds, with the significant additional property that software cannot bypass them.

Separate blocking from monitoring. Checks that must block an order are inline. Checks that only need to raise an alarm, such as pattern surveillance, conduct monitoring and drift detection, run out of band on a copy of the order flow, where they can be as expensive as they need to be.

The argument that controls cost too much latency to implement properly is, in practice, almost always an argument about implementation quality rather than about physics. A well-built gateway check costs a fraction of the network path it precedes.

Regulatory and exchange expectations

The specifics differ by jurisdiction, but the direction is consistent across the markets we recruit into. Supervisory frameworks for algorithmic and high-frequency trading generally require firms to demonstrate pre-trade limits, kill functionality, testing and certification of algorithms before deployment, change control, order-to-trade discipline, audit trails with synchronised clocks, and named individuals accountable for the controls.

In India, algorithmic and co-location activity on the NSE and BSE operates within SEBI's framework for algorithmic trading, with exchange-level approval and controls applying to strategies and their changes. Firms operating across Singapore, Hong Kong, the UAE, Saudi Arabia and Japan face parallel obligations from each regulator and venue, which is a meaningful part of why multi-market desks need genuine compliance engineering capability rather than a policy document.

The hiring consequence is that a control framework is not only a technical artefact. It must be documented, owned, testable and explicable to a regulator, an exchange, a clearing member and an investor. That requires people who can do both the engineering and the explaining.

Talent implications

This is one of the clearest under-hired functions in the market, and the pattern is consistent: controls are built by whoever has capacity during a build-out, then inherited by nobody. The gap surfaces at the worst possible time: during an exchange audit, an investor's operational due diligence, or an incident.

The roles that matter here:

• Risk engineers build and own the gateway: inline checks, limit distribution, real-time position, throttles and the kill path. The profile is a strong systems engineer with real latency experience who is temperamentally suited to owning something that must not fail. Compensation sits close to core low-latency engineering, and firms that try to pay less than that staff the function with people who cannot do it.
• Quantitative risk analysts set the limits rather than implement them: sizing, stress scenarios, correlation assumptions, capital allocation. Hired from quantitative backgrounds with real statistical depth, and valuable in proportion to their willingness to argue with the trading desk.
• Trade surveillance and market conduct specialists own out-of-band monitoring for manipulative patterns, self-trading and venue rule compliance. A growing specialism as venues and regulators automate their own surveillance, and one where candidates with both exchange-side and firm-side experience are scarce.
• Heads of risk at trading firms are a genuinely difficult search. The requirement is someone technical enough to be respected by engineers and traders, independent enough to stop a desk, and credible enough to present a framework to a regulator or an allocator. The pool is small, and the firms that find good ones usually do so by promoting from inside or by paying well above their initial assumption.

Three observations from running these searches:

1. Independence must be structural. A risk function reporting into the trading desk it constrains is not a risk function. Candidates worth hiring will probe the reporting line in the first conversation, and a weak answer loses them.
2. Hire the function before the incident, not after. Post-incident searches run under time pressure, with a damaged story to tell, at a premium. The same person was available more cheaply six months earlier.
3. Testing capability is the differentiator. Many candidates can describe the controls. Far fewer have built the infrastructure to test them under production conditions, which is the part that establishes whether they work.