Risk, Limits & the Regulator — Both Sides

Before you start. This chapter leans on:

Venue anatomy — gateway → sequencer → matching engine, because pre-trade risk has an exact seat in that pipeline: ch23

Gateways and sessions — cancel-on-disconnect and mass-cancel live at the edge: ch24

The broker/OMS side — per-client risk before routing: ch26

Event sourcing — surveillance and regulator queries run on the sequenced log: ch13

Change management — kill switches and replay-tested config, extended here to risk limits: ch17

Read those first — 20 minutes there saves an hour here.

Every trading system you’ll interview about — venue or broker — carries a second system inside it: the control plane that decides what is allowed to trade, stops it when something goes wrong, and can prove afterwards what happened. This chapter is that control plane, from both sides of the wire. It’s also where your payments background pays off most directly, because the shapes — pre-auth checks, idempotency keys, the big red pause button, triple reconciliation, suspicious-activity monitoring — are the shapes you already operate; the vocabulary and the latency budgets are what’s new. Interviewers use this material to separate “built a fast thing” candidates from “could be trusted with production” candidates.

The control plane, both sides

 BROKER SIDE                                VENUE SIDE
 ───────────                                ──────────
 client order                               participant order
      │                                          │
 [OMS pre-trade risk]                       [gateway pre-trade risk]
  buying power, limits,                      price collar, size, rate,
  duplicate check           ── SEC 15c3-5 ──  self-match, session limits
      │                                          │
 [SOR] ──► child orders ──────────────────► [sequencer] ─► [matching engine]
      │                                          │
      │◄──────── acks / fills ───────────────────┤
      │                                          │
 [position keeper]                          [drop copy] ──► clearing/risk
      │                                          │
 [recon: internal book vs venue             [surveillance jobs on the
  statements vs custodian]                   sequenced log: wash, spoof]
      │                                          │
 [kill switches: per-client /               [kill switches: per-session /
  per-venue / global]                        per-symbol / market-wide]

Same skeleton on both sides: an in-line gate before anything reaches the market, a real-time copy of what happened flowing to watchers, reconciliation loops proving the books agree, and a fast path to stop everything. The regulators (bottom of the chapter) are there to force each box to exist.

Pre-trade risk: an in-line latency budget

Pre-trade risk — the checks that run on the order’s critical path, before it can reach a matching engine — is the one part of the control plane that costs latency on every single order, so it’s engineered like a hot path, not like a compliance afterthought. The venue runs it in the gateway before the sequencer (a bad order must never consume a sequence number it didn’t deserve — rejects don’t enter history); the broker runs it in the OMS before the SOR (a breach must never reach a venue). Why rejects must stay out, restated from ch13: the sequenced log is the replayable official history every downstream system folds over, so a reject inside it would make garbage part of the permanent record.

The standard battery, with realistic per-check budgets on a venue-grade gateway (nanoseconds):

Check	What it stops	Typical cost
Price collar / band — reject orders further than X% (or N ticks) from reference price	fat fingers, decimal-place bugs	~10–20 ns (two compares vs cached band)
Max order size / notional cap	“sell 1,000,000” instead of “1,000”	~5–10 ns
Position + open-order limit — current position ± all working orders must stay inside limit	slow-bleed breaches across many small orders	~20–50 ns (atomic read + add)
Credit / buying-power check	trading beyond collateral	~20–50 ns against an in-memory counter; the update pipeline behind it is the hard part
Rate limit (orders/sec per session)	runaway algos, DoS on the book	~10 ns (token bucket)
Self-match prevention	wash-looking prints from one firm’s own flow	~50–100 ns (check resting-order ownership at the touch — the best bid/ask, where the next trade happens)
Duplicate / replay detection via client order ID	double-submits after timeouts/reconnects	~50–100 ns (hash-set probe on recent IDs)

Total budget: a few hundred nanoseconds venue-side — small against a ~5–50 µs gateway-to-ack path, which is exactly the argument you make when someone proposes skipping checks “for latency.” A crypto platform on cloud hardware runs the same battery at low-microsecond cost, and that’s still fine: the WAN hop to the venue, measured in milliseconds, dwarfs it.

Two of these are old friends renamed. Client order ID dedup is the idempotency key: the client stamps each order with a unique ID; a resubmit after an ambiguous timeout hits the dedup set and returns the original outcome instead of a second order — the same mechanism that stops double-charges in payments, for the same reason (retries against an uncertain outcome are mandatory, so the server must make them safe). The credit check is the auth-hold pipeline: reserve on order entry, release on cancel, convert on fill, and the failure modes are leaked holds and double-releases, found by reconciliation.

Self-match prevention (SMP) deserves its own beat because interviewers probe the policy options. When an incoming order from firm F would match F’s own resting order, the venue can: cancel-newest (reject/cancel the incoming — the aggressor loses), cancel-oldest (cancel the resting order, let the incoming trade on — the aggressor keeps its intent), or cancel-both. Venues offer these as flags because different participants want different semantics (a market maker re-quoting wants cancel-newest; an algo sweep wants cancel-oldest). Two words first: a print is an executed trade appearing on the public feed, and the feed’s running record is “the tape.” Why SMP exists at all: self-matches print volume that looks like wash trading (surveillance) and can be used to paint the tape, so the venue prevents them mechanically rather than adjudicating intent afterwards.

Implementation craft: the limit counters these checks read are updated from multiple flows (entries reserve, cancels release, fills convert) while being read on every order. Venue-side that means the padded-atomics discipline from your hot-path work (ch11) — per-session counters cache-line-aligned to kill false sharing (padded so no two counters share a 64-byte line), relaxed loads on the check path (the cheapest atomic read — safe here because the counter isn’t a synchronization primitive), no locks anywhere near the gateway. The reference data (bands, limits) is versioned config swapped in atomically by pointer — never a mid-order partial update.

Stopping: kill switches, cancel-on-disconnect, mass-cancel

Kill switch — a pre-built, tested control that halts order flow at some scope — is a taxonomy, not a single button. Both sides layer them:

Scope	Venue side	Broker side	Who can pull
Session/client	disable one session, cancel its orders	halt one client, cancel their children	risk desk, on-call, the client themselves
Symbol/venue	halt one instrument	stop routing to one venue + mass-cancel there	ops, automated circuit breakers
Firm/global	disable a participant firm entirely	stop everything, cancel everything everywhere	senior risk officers, named individuals

Design rules that interviewers listen for: the kill path is pre-authorized and drilled (MiFID II RTS 6 literally mandates kill functionality and periodic testing — a kill switch you’ve never pulled is a rumor, same as an untested backup); pulling it must not require the system being killed to cooperate (out-of-band path to the venue: a dedicated mass-cancel endpoint, or the venue’s own participant portal); and it’s cancel then investigate, never the reverse. Analogy: the “pause payouts” button every payments platform builds after its first fraud incident — pre-wired, permissioned, logged, and the postmortem question is always “why did it take N minutes to press.”

Cancel-on-disconnect (CoD) — the venue automatically cancels a session’s resting orders when its connection drops — is the default safety rail both sides negotiate. The subtlety: CoD triggering on a network blip while your strategy is fine mass-cancels your queue position (expensive); CoD not being armed while your strategy is dead leaves stale quotes in the market getting picked off (more expensive). So CoD is per-session configuration with heartbeat-timeout tuning, and the broker-side mirror (ch26) is the client-disconnect policy: takers get CoD, long-running algos keep working because the OMS owns the parent, not the TCP connection.

Mass-cancel must be the fastest path in the system. One message cancels everything for a session/symbol/firm. When it’s used, the market is moving against someone and every millisecond of cancel latency is money; a mass-cancel that walks the book order-by-order through the normal pipeline is a design failure. Venues implement it as a first-class sequenced operation; your own engine should too (index orders by owner so cancel-all is O(orders-owned), pre-reserved capacity in every queue so the cancel can’t be backpressured by the very flood it’s trying to stop).

Post-trade: drop copy, triple recon, and the liquidation engine

Drop copy

Drop copy — a real-time duplicate feed of your executions (and often order events), delivered on a separate session to risk, clearing, and compliance systems — is the venue telling you what you did, as you do it. Analogy: a CDC stream off the ledger — the same events your trading session already saw, but delivered independently, so a bug in your trading-session handling can’t blind your risk view. Why it matters architecturally: your risk system’s position should be built from drop copy (venue-authoritative), not from your trading gateway’s view of its own acks — independence of the watcher from the watched. It’s also the input regulators expect your firm-wide kill decision to be based on: 15c3-5 asks brokers to monitor aggregate exposure in real time, and drop copy is the venue-side feed for it.

Reconciliation: the triple loop

Straight from your payments world — internal ledger vs PSP report vs bank statement — with the nouns swapped:

 internal book  ◄──recon──►  venue statements  ◄──recon──►  custodian / chain
 (event-sourced    (drop copy live;               (where assets actually
  positions)        EOD statements)                sit: custody, wallets)

Three-way, because any two can agree and still be wrong together (your book and the venue agree you hold X on-venue; the custodian view says the venue can’t cover it — that’s the FTX shape). Live recon runs continuously against drop copy (position drift alarms in seconds); statement recon runs on venue cutoffs; custody recon runs on withdrawal/deposit confirmations and on-chain balances. Breaks go to a suspense workflow with aging alarms — an unexplained break that survives an hour is an incident, not a ticket. In a 24/7 crypto shop there is no end-of-day batch window; recon is a streaming job with rolling cutoffs, which is genuinely harder than tradfi’s nightly batch and worth saying in interviews.

The liquidation engine (operator side)

You know perps as a consumer of the mechanics; the venue-design interview asks you to specify them. The chain:

Funding rate — periodic payments between longs and shorts keeping the perp tethered to spot. Operator concern: computed from observable inputs on a published schedule, because participants arbitrage any discretion.
Mark price vs last price — margin and liquidations are computed on a mark price (an index of external spot venues, smoothed), not the venue’s own last trade. Why: if liquidations keyed off last price, a thin book lets an attacker print one small trade at an absurd price and cascade-liquidate everyone — so mark-price design is manipulation resistance, and it forces index composition rules: multiple constituent venues, outlier rejection (drop the deviant constituent), staleness handling (a constituent that stops updating leaves the index), and published weights. This is consensus-from-unreliable-oracles, an engineering problem you can whiteboard.
Liquidation waterfall — the ordered stages a losing position falls through as its margin runs out. One number to hold first: the bankruptcy price is the price at which the trader’s margin hits exactly zero. Tiny worked example: a 10x long opened at $100 has margin worth a 10% move, so its bankruptcy price is $90, and the venue starts intervening early, say a margin call around $92. The stages:
1. Margin call — the position is flagged; the trader can add margin or reduce.
2. Partial liquidation — the engine reduces the position (reduce, don’t nuke).
3. Full liquidation via the book — the remainder is closed as limit orders, rate-limited, so the engine doesn’t crash its own market.
4. Insurance fund — absorbs the gap if the position closed worse than its bankruptcy price.
5. ADL (auto-deleveraging: forcibly closing profitable opposing positions, by a published leaderboard) — the last resort when the fund is exhausted.
Each stage is a documented, tested policy — the waterfall is the venue’s version of “who eats the loss,” which in payments you know as the chargeback/liability waterfall.
The liquidation engine is itself a trading system with the same needs: deterministic, sequenced inputs (mark-price ticks are events in the log), rate limits, and its own kill switch — a runaway liquidation engine is one of the worst self-inflicted incidents a venue can have.

Surveillance on the sequenced log

Market surveillance — detecting manipulative patterns in order flow — is, architecturally, a set of stream jobs consuming the sequenced log, and the single-sequencer design (ch13) pays its compliance dividend here: because every order event has one global sequence number, questions like “what did the book look like when this order was placed” have exact answers, not log-grep approximations.

The two patterns every interviewer names:

Wash trading — trading with yourself (directly or via colluding accounts) to print fake volume. Detection: join trades where buyer and seller resolve to the same beneficial owner (accounts, funding sources, withdrawal addresses in crypto — an entity-resolution graph problem), plus statistical tells: self-crossing rates, volume with zero net position change, round-trip times. Crypto’s historical incentive: exchange volume rankings — which is why “real volume” studies embarrassed so many venues, and why running SMP + surveillance is a credibility signal for a serious one.
Spoofing / layering — posting orders you intend to cancel to fake pressure (spoofing: one large order; layering: a stack of them) and trading the other side. Detection features on the log: order-to-trade ratio per account, cancel-latency distributions (spoofers cancel fast when approached), imbalance placed opposite to subsequent aggression, repeated patterns across sessions. These run as windowed stream jobs; flagged cases go to human review with a replayable book reconstruction as the evidence bundle — the surveillance analyst’s UI is a book-replay tool, which is why venues that can’t replay their book can’t really do surveillance.

The payments analogy is exact: transaction-monitoring rules (velocity, structuring, mule networks) running on the payment ledger, alerts to a case-review queue, SAR filings. Same architecture, different features.

The regulators: name-drop depth

You are not expected to be a lawyer. You are expected — at Talos-style firms especially — to know these regimes exist and what each one forces architecturally. That’s the depth interviewers check: one sentence of what, one sentence of forcing function.

SEC Rule 15c3-5 (US, “Market Access Rule,” 2010): brokers providing market access must have pre-trade financial and regulatory risk controls under the broker’s own control — you cannot rent your pipe to a client unchecked (“naked access” ban). Forcing function: the OMS pre-trade gate in ch26 is mandatory, must be broker-controlled (not client-configurable-off), and aggregate credit exposure must be monitored in real time.
MiFID II RTS 6 (EU, algorithmic-trading controls): firms running algos must have kill functionality, pre-trade limits, real-time monitoring, annual self-assessment of their algo systems, and testing of algos against disorderly-market scenarios. Forcing function: the kill-switch taxonomy above stops being optional engineering hygiene and becomes an audited requirement with named owners; “we test our kill switches” needs evidence.
MiFID II more broadly: best execution (ch26), clock synchronization (RTS 25 — timestamps traceable to UTC, which is why ch07’s PTP chain is a regulatory artifact in the EU), and order-record keeping (years of retention — the log-retention economics of ch13).
Crypto’s messier map: no single rulebook; per-jurisdiction licensing. MAS (Singapore — your home turf): the Payment Services Act’s DPT (digital payment token) licensing covers exchange and transfer services, with the Financial Services and Markets Act extending custody coverage — MAS licensing is the credibility bar for SG-based platforms, and you can say you’ve watched that regime professionally from Singapore. VARA (Dubai’s virtual-asset regulator) and MiCA (the EU’s Markets in Crypto-Assets regulation, phasing in from 2024) are the other names to have: one-liners suffice. The architectural consequence of the messiness: per-jurisdiction feature flags (which clients may touch which products), geofencing as a real subsystem, and travel-rule data exchange on transfers (the travel rule: regulations requiring sender and recipient identity to accompany crypto transfers between platforms).

Interview frame, verbatim if you like: “I’m not a compliance officer, but I know 15c3-5 means the pre-trade gate is legally mine as the broker, RTS 6 means my kill switches get audited annually, and MiFID’s clock-sync rules mean my PTP chain is evidence. I design assuming the log will be read by a regulator.”

Limits are config, config is code

Who changes a risk limit, how, and how fast — this is ch17 applied to the control plane, and it’s an interview topic because it’s where discipline usually fails.

Limits-as-code: risk configuration lives in version control, deploys through a pipeline with schema validation, dry-run against current positions (“this change would put 3 clients in breach — proceed?”), staged rollout, and automatic audit trail of who/what/when/why. Not a database row someone UPDATEs.
The 2am call: a client (or your own desk) hits a limit mid-move and wants it raised now. The answer is never “ops edits prod config”; it’s a pre-built emergency path: dual-approval (risk officer + on-call), bounded pre-approved uplift sizes, auto-expiry (the emergency raise reverts in N hours unless ratified), and the same audit trail as the slow path. Process beats heroics because the 2am raise that stuck around is how firms discover, months later, that their real limits are nothing like their documented ones. Payments version: the merchant screaming to lift their processing cap during a flash sale — same pressure, same answer.
Intraday ownership: named roles own limit changes (RTS 6 wants this anyway); engineering owns the mechanism, risk owns the numbers, and the system enforces that separation — engineers shouldn’t be able to change a client’s credit limit, risk officers shouldn’t need a deploy.

Plain-English recap

Every trading system carries a control plane: an in-line pre-trade gate, layered kill switches, a real-time copy of what happened (drop copy), reconciliation loops, surveillance on the log, and a config discipline for the limits themselves.
Pre-trade risk is a hot path: price collars, size/notional caps, position and credit checks, rate limits, self-match prevention, and client-order-ID dedup — a few hundred nanoseconds venue-side, built on padded atomic counters. Dedup is the idempotency key; the credit check is the auth-hold pipeline.
Kill switches are a taxonomy (client/session, symbol/venue, global), pre-authorized, drilled, and out-of-band; cancel-on-disconnect is per-session policy; mass-cancel must be the fastest path in the system — the big red “pause payouts” button, pre-wired.
Post-trade: drop copy is CDC off the venue’s ledger and should feed a risk view independent of your trading session; reconciliation is the triple loop (internal book / venue / custodian) you know from payments, running continuously because crypto has no close.
A perps venue’s margin stack — funding, mark price with manipulation-resistant index rules, liquidation waterfall, insurance fund, ADL — is itself a deterministic trading system with its own kill switch.
Surveillance (wash trading, spoofing) is stream jobs on the sequenced log; the deterministic log is what makes both surveillance and regulator queries tractable.
Regulatory anchors to name, not lawyer: SEC 15c3-5 (pre-trade risk mandatory at the broker), MiFID II RTS 6 (kill switches + annual self-assessment), RTS 25 (clock sync as evidence), MAS PSA/DPT in Singapore, VARA/MiCA one-liners. Each one forces a box in the diagram.

Interviewer will ask

Q1: “What pre-trade checks would you run, and what’s the latency budget?” Placement first, because it matters as much as the list. At the venue, the checks run in the gateway before the sequencer — the sequenced log is the replayable official history, so a bad order must never consume a sequence number. At the broker, they run in the OMS before the SOR — a breach must never reach a venue.

Then the battery, each with its one-line why. Price collar against a reference band — catches fat fingers and decimal-place bugs before they walk the book. Max size and notional cap — the “sell 1,000,000 instead of 1,000” stopper. Position-plus-open-orders limit — catches the slow bleed across many small orders. Credit/buying power — no trading beyond collateral. Per-session rate limit — contains runaway algos. Self-match prevention — stops wash-looking prints from a firm’s own flow. Duplicate detection on client order ID — makes retries after an ambiguous timeout safe. Two of these I’ve effectively built in payments: the dedup check is an idempotency key, and the credit check is an auth-hold pipeline with reserve/release/convert semantics.

The budget closes the argument. Each check is a compare or an atomic read against in-memory, cache-line-padded counters, reference data swapped atomically by pointer — a few hundred nanoseconds total, venue-side, on a gateway path that’s already 5–50µs. So skipping checks “for latency” buys back a few percent of the path at best while removing the only thing standing between a bug and the book.

Q2: “Design self-match prevention. What are the policy options and who wants which?” Mechanically: at match time, if the aggressing order and the resting order at the touch resolve to the same firm or SMP group, don’t print — apply the configured policy. Options: cancel-newest (aggressor dies, rester keeps queue position — market makers re-quoting want this), cancel-oldest (rester dies, aggressor trades on — sweepers want their intent to survive), or cancel-both. It’s a per-session or per-group flag because different participants legitimately want different semantics. The reason venues do this mechanically rather than adjudicating afterwards: self-matches print volume that’s indistinguishable from wash trading on the tape, so preventing them is both a surveillance and a credibility measure. Cost is a ~tens-of-ns ownership check at the touch — cheap because order structs already carry owner IDs.

Q3: “Tell me about kill switches. Who can pull what?” Start with the ladder of scopes, because a kill switch is a taxonomy, not a button. Per-session/client: disable one session, cancel its orders — pullable by risk, on-call, and the client themselves. Per-symbol or per-venue: halt an instrument venue-side; stop routing and mass-cancel broker-side — ops or automated breakers. Global: everything stops — named senior individuals only.

Then three design rules, each with its because. The kill path is pre-authorized and drilled, because an unpulled kill switch is a rumor — RTS 6 makes the testing an audited requirement in the EU. It must not depend on the sick system cooperating, because the thing being killed is by definition misbehaving — so there’s an out-of-band route. And the doctrine is cancel-then-investigate, never the reverse, because while you investigate, the market is moving against someone.

Mass-cancel itself is engineered as the fastest path in the system: one sequenced operation, orders indexed by owner, capacity pre-reserved so the cancel can’t be backpressured by the very flood it’s stopping. It’s the payments “pause payouts” button, pre-wired — and the postmortem question is always why it took N minutes to press.

Q4: “What is drop copy and why does it exist if you already get execution reports?” Drop copy is a real-time duplicate feed of your fills and order events on a separate session, delivered to risk and clearing independently of your trading session — CDC off the venue’s ledger. It exists because the watcher must be independent of the watched: if my risk position is built from my trading gateway’s own view of its acks, a bug there corrupts both trading and risk simultaneously; drop copy gives risk a venue-authoritative stream that my trading code never touches. It’s also the practical input for firm-wide real-time exposure monitoring, which 15c3-5 expects broker-side. In my triple-recon design, drop copy is the live leg — internal book vs drop copy in seconds, vs statements at cutoffs, vs custodian on settlement — three-way because any two can agree and still be wrong together, which is the FTX shape.

Q5: “Why mark price instead of last price for liquidations, and what does that force?” Because keying liquidations off your own last trade makes a thin book a weapon: one small print at an absurd price cascades liquidations, and the attacker profits from the carnage. So margin runs on a mark price — an index over multiple external spot venues, smoothed — and that forces index-composition engineering: several constituents, published weights, outlier rejection so one deviant venue is dropped, staleness rules so a stalled feed leaves the index, and a fallback when too few constituents survive. It’s consensus from unreliable oracles, and it’s specified publicly because participants arbitrage any discretion. Downstream sits the waterfall — margin call, partial liquidation, full liquidation via rate-limited book orders, insurance fund, ADL last — each stage a documented policy, and the liquidation engine itself gets sequenced deterministic inputs and its own kill switch, because a runaway liquidator is the worst self-inflicted incident a perps venue can have.

Q6: “How would you detect wash trading and spoofing on your venue?” As stream jobs on the sequenced log — which is the architectural point: one global sequence means “what did the book look like when this order arrived” has an exact, replayable answer, and surveillance without book replay isn’t really surveillance. Wash trading: entity-resolve accounts into beneficial owners (shared funding sources, withdrawal addresses — a graph problem in crypto), then flag self-crossing rates, volume with zero net position change, and tight round-trips. Spoofing/layering: per-account order-to-trade ratios, cancel-latency distributions — spoofers cancel fast when approached — and size imbalance posted opposite subsequent aggression. Flagged cases go to human review with a book-replay evidence bundle. This is the same architecture as payments transaction monitoring — velocity rules on a ledger feeding a case queue — with different features, and self-match prevention upstream removes the innocent-explanation cases before they reach the queue.

Q7: “What do 15c3-5 and RTS 6 actually force you to build?” 15c3-5 — the US market-access rule — says a broker giving clients access must run pre-trade financial and regulatory checks under the broker’s own control: so the OMS gate before my SOR is legally mandatory, cannot be switched off per client request, and aggregate credit exposure needs real-time monitoring, which is what drop copy feeds. RTS 6 — MiFID II’s algo-trading standard — mandates kill functionality, pre-trade limits, real-time monitoring, and an annual self-assessment: so my kill-switch taxonomy needs named owners, test evidence, and documentation that survives an audit. I’d add MiFID’s RTS 25: timestamps traceable to UTC, which turns the PTP chain into a regulatory artifact. I’m not a lawyer and say so in the room — but I design assuming the event log will be read by a regulator, which is cheap if you’re event-sourced from day one and impossible to retrofit if you’re not. In Singapore, my home market, the equivalent gate is MAS’s PSA/DPT licensing regime for crypto platforms.

Q8: “A client calls at 2am demanding a limit raise mid-move. What happens?” Run the clock. 02:03 — the call routes to the risk on-call, not to engineering, because “ops edits prod config” is not a path that exists; the mechanism won’t accept a raw edit. 02:05 — on-call opens the emergency-uplift tool and sees the client’s current limit, live utilization, and a short menu of pre-approved uplift sizes — say 1.5× or 2×, sized in a design review months ago, not invented on the phone. Meanwhile the client’s orders above the old limit are still bouncing with explicit limit-breach rejects — the system stays correct while the humans decide. 02:07 — the second approver, another risk officer, confirms from their phone: two distinct identities required, so one tired human can’t wave it through alone. 02:08 — the uplift goes live, the client’s next order passes, and they’re told both the new number and its expiry. 06:00 — the uplift auto-expires and the limit snaps back, unless someone ratified it through the normal daytime pipeline with full review. Every beat — who called, who approved, what size, when it lapsed — lands on the same audit trail as the slow path. The ceremony exists because of the counterfactual: the 2am raise that quietly sticks is how firms discover, months later, that their real limits bear no resemblance to their documented ones. I’ve watched the payments version — a merchant demanding their processing cap lifted mid-flash-sale — and the answer is identical: the emergency path exists, it’s fast, and it’s paved with audit. One split keeps it honest: engineering owns the mechanism, risk owns the numbers, and the system enforces that neither can do the other’s job.

The HFT Gap Closer