Katkat
Back

Design a Pre-Trade Risk Check for an Electronic Order Path

Chicago Trading CompanySoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a high-throughput, low-latency risk engine capable of atomic exposure validation before orders reach an exchange, while balancing concurrency and strict fault tolerance.

Problem Statement

Design a pre-trade risk gateway for a high-frequency trading firm. The system must inspect every outgoing order before it leaves the firm's network to ensure it stays within defined risk parameters (e.g., maximum position size, maximum order value, and daily loss limits).

Functional Requirements

  • Pre-trade Validation: Every order must be checked against account-level limits in real-time.
  • Atomic Reservations: If an order is accepted, the system must atomically reserve the required buying power to prevent double-spending.
  • Fail-Closed: If the risk service is unavailable or latency exceeds a threshold, all outgoing orders must be rejected by default.

Non-Functional Requirements

  • Latency: The validation logic must add no more than 10 microseconds of overhead to the order path.
  • Throughput: Support 100,000 orders per second per trading gateway.
  • Auditability: Every decision (Approved/Rejected) must be persisted asynchronously with full context for regulatory compliance.

Deliverables

  1. High-level architecture diagram and component interaction flow.
  2. Strategy for maintaining state consistency (e.g., how to prevent two parallel gateway threads from exceeding the same daily limit).
  3. Handling of asynchronous trade execution feedback (e.g., an order is partially filled at the exchange).
  4. Strategies for high availability and disaster recovery without compromising the fail-closed guarantee.

Hints

Hint 1

Consider using an in-memory lock-free data structure or pinning risk checks to specific CPU cores to avoid contention.

Hint 2

Think about how 'state' is synchronized between the risk gateway and the exchange feedback loop, and whether event sourcing could assist with auditability.

Hint 3

Address the trade-off between strict synchronous consistency and the low-latency requirements by exploring pre-allocated 'shards' of risk limits.

Follow-up questions

  • How would you handle a scenario where the order is rejected by the exchange, but your internal system has already 'reserved' the buying power?
  • If your trading system scales across multiple geographic regions, how do you handle the propagation of risk limits to ensure a global limit is never breached?
  • What specific monitoring or fault-injection testing would you implement to ensure the system consistently fails-closed under extreme market volatility?