Trading Infrastructure Sequencing: Why Risk Controls Must Ship Before Your Execution Engine

---

Table of Contents

1. The $5.1M Sequencing Problem
2. How Execution Engines Depend on Risk Infrastructure
3. What Happens When You Ship Execution First: Two Case Studies
4. The Regulatory Floor: What SEC 15c3-5 and MiFID II Require
5. The Infrastructure Sequencing Framework
6. Diagnostic: Is Your Roadmap Upside Down?
7. Conclusion

---

The $5.1M Sequencing Problem

$3.2M. 18 months. A proprietary execution engine scoped in three phases.

My team was brought in to review the build plan before it went to the board. The roadmap was structured by a capable engineering team: execution core first, OMS integration second, risk infrastructure last. The rationale was straightforward — risk was assessed as the least complex module.

That sequencing decision exposed $5.1M in unguarded capital for six months.

The problem was structural, not conceptual. The team sequenced by perceived complexity. Risk sat at the bottom because the dependency mapping had not been completed — they had mapped what they understood (matching logic, venue connectivity, order management), not what the architecture structurally required.

A pattern I have observed across multiple institutional build engagements: teams scope what they can model, and defer what they cannot. Risk infrastructure tends to be deferred not because it is unimportant, but because its dependencies are invisible until the execution layer is designed. By the time those dependencies surface, the budget is committed and the sequence is locked.

The resequencing conversation that followed identified a single diagnostic question that every CTO overseeing a major infrastructure build should ask before Phase 1 ships:

What happens if Phase 3 fails?

If the answer touches everything above it in the stack, the roadmap is structurally inverted.

---

How Execution Engines Depend on Risk Infrastructure

The canonical execution architecture places the risk engine upstream of the execution engine — not as an audit layer, but as a structural prerequisite.

The dependency chain is direct: Strategy → Order Emulator → Execution Algorithm → Risk Engine → Execution Engine → Execution Client.

This is not an arbitrary convention. The execution engine depends on pre-trade risk gates for two structural reasons:

Position ceiling enforcement. Without pre-trade exposure limits already defined and operational, the execution engine has no ceiling on position size. Any order it generates can reach the market at full size. There is no upper bound until risk infrastructure is live.

Circuit-breaker connectivity. During a feed anomaly — a data feed spike, a connection drop, a venue clock drift — the execution engine needs a kill switch that can halt order flow immediately. That kill switch is a function of risk infrastructure. Without risk gates in place, the engine continues processing orders against potentially corrupted market data.

The OMS layer compounds the problem. OMS routes orders through pre-trade checks — but those pre-trade checks reference risk parameters that, in a Phase 3 sequencing model, do not yet exist. An OMS shipped into a stack without live risk parameters routes orders through checks that have nothing to validate against.

SEC Rule 15c3-5 (the Market Access Rule) codifies exactly this dependency. Broker-dealers are required to implement pre-trade risk controls that prevent orders exceeding pre-set credit or capital thresholds before those orders reach the exchange. The rule was enacted precisely because the opposite condition — execution reaching the market before controls are live — produces catastrophic outcomes. Unfiltered or “naked” sponsored access is explicitly prohibited.

The FIA Best Practices for Automated Trading Risk Controls (July 2024) draws a clear architectural distinction between pre-trade controls (hard order limits, position caps) and post-trade credit controls. The FIA guidance is explicit: pre-trade controls must exist before execution infrastructure can operate safely. Post-trade controls are not a substitute — they operate after capital has already been committed to the market.

Building the execution engine before risk infrastructure is architecturally equivalent to running live order flow through a stack with no kill switch, no exposure limits, and no circuit breakers. In the case described above, that condition would have persisted for six months.

---

What Happens When You Ship Execution First: Two Case Studies

The sequencing failure mode is not theoretical. Two of the most significant trading infrastructure incidents of the last five years trace directly to risk controls that were absent or insufficient at the point of execution.

Citigroup, May 2022: The Absent Hard Block

A Citi trader intended to sell $58M in European equities. An input error generated a $444 billion order. Citi’s systems blocked $255 billion. The remaining $189 billion reached trading platforms.

The UK’s Financial Conduct Authority and Prudential Regulation Authority imposed a combined fine of £62M ($79M). The FCA finding is the critical point: Citi had no “hard block” that would have rejected this large erroneous basket of equities in its entirety. The OMX Stockholm 30 Index fell nearly 8% in five minutes. At peak, €300 billion in market value evaporated.

The FCA’s investigation noted that Citi had received repeated supervisory communications about inadequate trading controls between April 2018 and May 2022 — a four-year window during which execution infrastructure and risk controls operated with a structural gap between them.

The architecture had execution. It lacked the hard stop.

Archegos Capital Management, March 2021: The Missing Cross-Broker Risk Gate

Archegos built leveraged exposure across multiple prime brokers simultaneously using total return swaps. No single prime broker had visibility into the total notional position. Each broker’s OMS could execute trades without cross-firm risk gates — because those gates did not exist.

Credit Suisse lost $5.5B. Nomura lost $2B. Morgan Stanley lost approximately $1B. UBS lost $774M. Total losses across prime brokers exceeded $10.3B.

The root failure is architecturally precise: risk infrastructure — counterparty exposure limits, cross-broker position aggregation — was not in place before leveraged execution was deployed at scale. Each prime broker ran execution infrastructure. None had the risk infrastructure that would have revealed the aggregate exposure. Execution shipped. Risk did not.

Both incidents share the same architectural signature: execution capacity exceeded the risk controls that should have bounded it. The sequencing was wrong — or the controls were never built.

---

The Regulatory Floor: What SEC 15c3-5 and MiFID II Require

Regulators have codified the dependency between risk infrastructure and execution in enforceable standards.

SEC Rule 15c3-5 (Market Access Rule) requires broker-dealers to implement pre-trade risk controls before orders reach an exchange. These controls must prevent orders exceeding pre-set credit or capital thresholds. The rule makes “unfiltered” access — execution without upstream risk gates — a regulatory violation, not just an architectural risk.

CFTC Electronic Trading Risk Principles (Final Rule, December 2020) mandates exchange-based pre-trade risk controls for all electronic orders, including messaging throttles, order size maximums, and heartbeat connectivity checks. These are not optional design elements — they are regulatory requirements that must exist in the architecture before electronic execution goes live.

MiFID II Article 17 and the ESMA Supervisory Briefing (February 26, 2026) require that pre-trade controls gate all order flow before market access. The February 2026 briefing was issued in response to evidence of divergence in supervisory practices — a signal that regulators are actively examining whether firms have implemented pre-trade architecture that meets the standard, not just declared they have.

What these three frameworks establish is consistent: risk controls must precede market access. They define the regulatory floor. The architectural question is whether the build sequence delivers that floor before execution ships, or after.

Firms that sequence execution first and risk controls later may spend months operating below the regulatory floor — not as a deliberate choice, but as a consequence of a sequencing decision made early in the project when the dependency was invisible.

---

The Infrastructure Sequencing Framework

The resequencing work on the $3.2M execution engine build followed a specific diagnostic method. My team mapped each component against a single question: if this module fails or is absent, what does it break above it in the stack?

Components that break everything above them are load-bearing. They must ship first.

The resequenced build looked like this:

Phase 1 — Risk Infrastructure (Months 1–8)

Pre-trade exposure limits. Kill switches. Position ceilings. Feed anomaly detection. Circuit breakers.

These components are not optional and they are not the least complex module — they are the foundation the execution engine stands on. Without them, execution cannot be safely deployed. This phase ships first because if it fails, nothing above it survives.

The $1.9M cost delta between the original $3.2M budget and the final $5.1M budget is the cost of this phase added to the original plan. Every dollar of that delta was the cost of building the foundation before building the machine on top of it.

Phase 2 — Execution Engine (Months 7–14)

Execution ships into a stack that already has guardrails. Position ceilings exist. Kill switches are live. Feed anomaly detection is operational. The execution engine has a ceiling on position size and a kill path during a data feed event on day one.

This is the only condition under which execution can go live without exposing unguarded capital.

Phase 3 — OMS Integration (Months 8–24)

The OMS reconciliation layer must validate against risk gates before it can be trusted in production. If the OMS ships before risk parameters are live, the pre-trade checks route orders through validation logic that has nothing to validate against. This phase extends because correctness of the OMS reconciliation layer depends on the risk infrastructure being stable and well-characterized — not newly deployed.

The board presentation was one page. Two columns. Original plan on the left, resequenced on the right. Each column showed phases, milestone dates, and one line item: total capital at risk during the build window. Left column: $5.1M unguarded for six months. Right column: $0 unguarded at any point.

The budget was approved in a single meeting.

---

Diagnostic: Is Your Roadmap Upside Down?

This framework applies to any multi-phase infrastructure build where components have structural dependencies. The five-question diagnostic below identifies the most common sequencing failure mode.

Question 1: What is your Phase 1 module, and what depends on it?

List every component in your roadmap that depends on Phase 1 being operational. If that list includes your execution engine or OMS, your Phase 1 selection may need review.

Question 2: What does your execution engine assume is already live when it ships?

Walk the dependency chain: what risk parameters, exposure limits, or kill-switch infrastructure does execution reference during normal operation? If any of those are in a later phase, execution will ship into a stack with structural gaps.

Question 3: What is the capital exposure during the gap between execution shipping and risk controls going live?

This is a number, not an estimate. Calculate the maximum notional position the execution engine can build during the gap period — the period when execution is live but pre-trade limits are not yet enforced. That number is your unguarded exposure.

Question 4: Does your OMS pre-trade check reference risk parameters that don’t exist yet?

Pre-trade checks that reference absent risk parameters are not checks — they are pass-throughs. Verify that every parameter your pre-trade logic references has a defined value before OMS goes live.

Question 5: If your risk module fails in production, what happens to the components above it?

Model the failure mode. If risk infrastructure failure causes execution to operate without limits, or causes the OMS to route orders without valid pre-trade validation, your architecture has a structural load-bearing dependency that your sequencing should reflect.

A team that can answer all five questions has completed the dependency mapping their sequencing should be built on. A team that cannot answer Question 3 has not yet quantified what they are exposing during the build window.

---

Conclusion

Infrastructure sequencing is a capital risk decision, not a project management preference. The order components ship in determines the exposure profile during the build window — and for execution engine builds, that exposure can reach eight figures if risk controls are treated as a Phase 3 deliverable.

The standard is that execution never reaches the market without pre-trade risk controls already operational. SEC 15c3-5, MiFID II Article 17, and CFTC Electronic Trading Risk Principles all encode this as a regulatory requirement. The architectural question is whether your build sequence delivers that standard before execution ships or after.

If your current roadmap has execution in Phase 1 and risk infrastructure in Phase 3, the question worth asking is: what is the capital exposure during the gap?

If the dependency mapping has not been completed before Phase 1 ships, the audit window is now. HFT Advisory Discovery Assessment exists for exactly that conversation.

---

Originally shared as a LinkedIn post.