Pre-Trade Risk Checks

Three different parties run pre-trade checks, for different reasons:

• The trading firm checks its own strategies: position, loss and message-rate limits per strategy and per trader.
• The broker with market access checks every client order it forwards (that's what 15c3-5 requires): credit, capital and erroneous-order limits.
• The exchange protects the market itself: price bands around a reference, maximum order size, message throttles, kill switches and cancel-on-disconnect for each participant.

Your exchange plays the third role, with per-account limits that a broker would set for its clients. The checks are the same in all three places. Only the owner and the configuration change.

In December 2005, a Mizuho Securities trader meant to sell 1 share of J-Com at ¥610,000 and instead entered 610,000 shares at ¥1. The firm lost roughly ¥40 billion. A fat-finger check catches orders whose price or size is implausible:

• Price band: reject a buy priced above reference + width or a sell priced below reference − width. It's one-sided on purpose. A buy far below the market is harmless: it rests and probably never fills. CME Globex documents exactly this rule for its price banding.
• Reference price: last trade, mid, an auction price, or the previous close, but always one with a known age. A stale reference after a halt makes the band either useless or a wall. Reject when the reference is missing or too old, and let operations override.
• Width: in basis points of the reference, with a minimum in ticks. For a 20-tick instrument, 5% is one tick, which would reject normal orders.
• Size and notional: maximum quantity per order and maximum price × qty × multiplier. Notional multiplies two large integers, so compute it in i128.
• Market orders have no price to band. Venues convert them to limit orders at a protection price (CME calls these protection points) or reject them when the book is thin.

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Side {
    Buy,
    Sell,
}

#[derive(Debug, Clone, Copy)]
pub struct BandConfig {
    /// Band half-width in basis points of |reference price|.
    pub band_bps: u32,
    /// The band is never narrower than this (protects low-priced instruments).
    pub min_band_ticks: i64,
    /// A reference older than this is unusable.
    pub max_ref_age_ns: u64,
}

#[derive(Debug, Clone, Copy)]
pub struct Reference {
    pub price: i64, // ticks; may be negative
    pub as_of_ns: u64,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum BandCheck {
    Accept,
    /// Buy priced above ref + width; `limit` = ref + width.
    AboveBand { limit: i64 },
    /// Sell priced below ref - width; `limit` = ref - width.
    BelowBand { limit: i64 },
    NoReference,
    StaleReference { age_ns: u64 },
}

/// width = max(floor(|ref| * band_bps / 10_000), min_band_ticks).
/// Order of checks: missing reference, stale (age = now - as_of, a future
/// as_of counts as age 0, stale if age > max), then the band for this side.
/// Edges are inclusive. Must not overflow for any i64 reference.
pub fn check_band(cfg: &BandConfig, reference: Option<Reference>, now_ns: u64, side: Side, price: i64) -> BandCheck {
    todo!()
}

A position limit that only counts filled quantity is easy to beat. Send ten buy orders of 100 each while your position is 0. Each passes "position + 100 ≤ max", and if they all fill you're 1,000 long. The correct check is the worst case: every open order on the side being increased fills, and nothing on the other side does.

long side:   position + open_buy  + new_buy  ≤  max_long
short side:  position − open_sell − new_sell ≥ −max_short

Implementing that means reservations. An accepted order adds its quantity to open_buy or open_sell. A fill moves quantity from open to position. A cancel, expiry or IOC remainder releases it. All of it is integer bookkeeping on one record per account, updated from the engine's own events. Open sells do not offset a new buy: if the sells are cancelled or never fill, the buys alone must still be within limits.

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Side {
    Buy,
    Sell,
}

/// Both limits are non-negative magnitudes.
#[derive(Debug, Clone, Copy)]
pub struct Limits {
    pub max_long: i64,
    pub max_short: i64,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Breach {
    /// projected = position + open_buy + qty (saturating); limit = max_long
    Long { projected: i64, limit: i64 },
    /// projected = position - open_sell - qty (saturating); limit = -max_short
    Short { projected: i64, limit: i64 },
}

pub struct Exposure {
    limits: Limits,
    position: i64,
    open_buy: i64,
    open_sell: i64,
}

impl Exposure {
    pub fn new(limits: Limits) -> Self {
        Exposure { limits, position: 0, open_buy: 0, open_sell: 0 }
    }
    pub fn position(&self) -> i64 { self.position }
    pub fn open_buy(&self) -> i64 { self.open_buy }
    pub fn open_sell(&self) -> i64 { self.open_sell }

    /// Check a new order (qty > 0) against the worst case for ITS side only.
    /// On success reserve qty as open; on breach change nothing.
    pub fn check_new(&mut self, side: Side, qty: i64) -> Result<(), Breach> {
        todo!()
    }

    /// `qty` of one of our working orders filled.
    pub fn on_fill(&mut self, side: Side, qty: i64) {
        todo!()
    }

    /// `qty` of a working order was cancelled, expired or killed: release it.
    pub fn on_release(&mut self, side: Side, qty: i64) {
        todo!()
    }
}

A kill switch has a scope (one account, one session, one firm, or the whole venue) and actions:

1. Block: reject every new order and modify in the scope from now on. Cancels are still accepted, so a client can always reduce risk.
2. Mass-cancel every resting order in the scope.
3. Leave positions alone. Flattening a position is a trading decision, so the switch stops new risk and doesn't create more.

The design question is what "from now on" means. A tempting implementation is an AtomicBool that the risk check loads with Relaxed on every order. It's cheap, but it makes the cut point timing-dependent. Which orders were accepted after the operator pressed the button depends on when the store became visible to the engine thread, and replaying the journal can't reproduce that decision.

The deterministic design makes kill a command in the sequenced input stream, like an order. The engine applies it at a precise sequence number. Every order sequenced before it was checked under the old state, and every order after it is rejected. Replay reproduces exactly the same cut. The mass-cancel is emitted as ordinary cancel events, so market data and the journal explain every one. An out-of-band flag at the gateway can additionally stop new orders from entering the queue, but the authoritative decision is the sequenced one.

The week's target is a full pre-trade check at p99 within 65 ns. That is roughly 200–250 cycles, and a single DRAM miss (~80–100 ns) blows it on its own. So the design rule is that everything the check touches is already in cache:

• Dense arrays, not hash maps. Assign each account a small integer at logon and keep risk state in a Vec<AccountRisk> indexed by it. Rust's default HashMap uses SipHash-1-3, which is DoS-resistant and costs tens of nanoseconds per lookup once you add the probable cache miss. You control the keys, so you don't need it.
• One or two cache lines per account. Keep the hot fields (limits, position, open quantities, the kill flag) together and cold fields (names, audit info) elsewhere.
• Precompute what changes rarely. Band edges change when the reference price updates, not when an order arrives. Compute upper and lower per instrument on reference updates, and the order-time check becomes two comparisons. The same goes for any division or i128 multiplication that can move off the order path.
• A straight-line accept path. Accepts vastly outnumber rejects. Evaluate all checks, combine them, and branch once. Build the reject reason in a separate cold function (week 38 formalizes this).

#[repr(C, align(64))]
pub struct AccountRisk {
    pub max_order_qty: i64,
    pub max_long: i64,
    pub max_short: i64,
    pub max_notional: i64,   // in price-ticks × qty units, precomputed per instrument
    pub position: i64,
    pub open_buy: i64,
    pub open_sell: i64,
    pub killed: bool,        // set by the sequenced kill command
}                            // 57 bytes of fields, padded to one 64-byte line

Where risk runs is a real trade-off:

• On the engine thread, before matching. Risk state is updated by the same deterministic event stream that produces fills, so open quantities and positions are exact, replay reproduces every decision, and there's nothing to synchronize. The cost is latency on the single most contended thread.
• In the gateway, before sequencing. Checks run in parallel across sessions and rejects never consume engine time. But fills happen on the engine, so the gateway's exposure state must be updated from engine events. It's always slightly behind, which is why reservations (count it when you send it) matter even more there.

Many real systems do both: cheap stateless checks (size, price band, throttles) at the gateway, and stateful position and credit checks where fills are known exactly.

Test it with the week 12 machinery. The core property: for any generated stream of orders, cancels and fill patterns, an account's position never exceeds its limits under any subset of its working orders filling. Add a differential test against a naive model that recomputes exposure from scratch by scanning all of the account's working orders on every check.