Hybrid Quant System Architecture: Integrating Risk Management, Position Sizing, and Execution in a Unified Framework

Most quant systems that fail in production don't have a signal problem. They have an architecture problem.

Their signals work. Their backtests are convincing. But when they hit a live environment, the internal structure can't handle real pressure — because Risk Management, Position Sizing, and Execution were designed as three separate entities that only connect at the end.

This article is about how to design a unified framework — one where these three layers are built as a single system from the start, not three parallel projects bolted together at the finish line.

Why Siloed Architecture Fails in Quant Systems

The common assumption goes like this: build a signal model, wrap a risk layer around it, connect an execution engine to its output. Done.

That assumption is wrong — not in terms of logic, but in terms of information timing. Each layer makes decisions that depend on the state of the other layers. When those layers are isolated, each one operates with an incomplete picture.

The State Fragmentation Problem

When the Risk Engine doesn't know the Execution Engine is in the middle of filling a large order, exposure calculations go wrong. When Position Sizing doesn't know how much of the previous order has been filled, the new position size is miscalculated. The result: actual slippage diverges from modeled slippage, and drawdown hits at moments when the system believed it was protected.

The Inverted Feedback Loop Problem

In a siloed architecture, none of the layers receive real feedback from the others. The Risk Engine only learns about final positions, not the execution process itself. This means the system doesn't know its actual risk until a position is fully filled — and in volatile markets, that delay can be fatal.

The Unified Framework: Three Layers, One State

A unified architecture rests on one simple principle: all three layers must be fed from a Single Source of Truth, and each layer's output must be immediately accessible to the other two.

That means a central State Manager that tracks not just open positions, but orders currently being executed, partial exposures, and the real-time status of every instrument.

Layer One: Risk Engine as Gate, Not Filter

The common mistake is treating Risk Management as a final-stage filter — signals come in, and if they're "too risky," they get rejected. That's too late.

In a unified architecture, the Risk Engine is a Gate. Before Position Sizing even runs its calculations, the Risk Engine must answer:

• Does the portfolio's current exposure in this instrument allow a new position?
• Does this signal's correlation with existing positions create concentration risk?
• Is the current volatility regime consistent with the risk parameters this strategy was designed for?
• Has current drawdown crossed a threshold that requires reducing position sizing?

If the answer to any of these is "no," the signal never reaches the sizing stage. This ensures Position Sizing always operates in a clean risk space.

Layer Two: Position Sizing as a Dynamic Function, Not a Fixed Number

In most entry-level systems, Position Sizing is either fixed (say, 2% of capital) or calculated using a simple formula like the Kelly Criterion. Both approaches operate in isolation.

In a unified system, sizing must be a function of several simultaneous variables:

This means Position Sizing draws inputs not just from the Signal Engine, but from the Risk Engine and Execution Engine as well. No layer makes decisions in isolation.

Layer Three: Execution Engine as an Informed Actor

In weak architectures, the Execution Engine is a "blind executor" — it receives a number and tries to fill it in the market. In a unified architecture, the Execution Engine must be connected to the Risk Engine and State Manager, making decisions throughout the execution process.

Three critical capabilities:

1. Partial Fill Reporting: Every portion of an order that fills is immediately reported to the State Manager so the Risk Engine knows the actual exposure at any moment.
2. Market Impact Awareness: If order size exceeds a threshold relative to market volume, the Execution Engine must confirm with the Risk Engine whether to continue or reduce size.
3. Abort Capability: If the Risk Engine detects a breach during execution — say, the correlation of another instrument suddenly spikes — it must be able to pause or modify the in-flight order.

State Manager: The Heart of Unified Architecture

Without a central State Manager, none of the capabilities above are possible. The State Manager cannot be a simple database — it must be a real-time, low-latency system that all layers can read from and write to simultaneously.

State Manager Structure

The State Manager must track at minimum the following entities:

• Open Positions: with size, entry price, unrealized PnL, and live exposure
• Pending Orders: orders that have been submitted but not yet filled — this is the part most systems ignore
• Partial Fills: portions of orders already executed — required for accurate exposure calculation
• Portfolio Metrics: including total exposure, current drawdown, realized volatility (not just historical), and correlation matrix
• Risk Limits: defined constraints by instrument, sector, and overall portfolio

Technology Selection for the State Manager

Choosing the wrong technology can collapse the entire architecture. Here is a practical comparison:

Practical recommendation: for most systematic trading systems at moderate scale, Redis as a real-time state cache alongside PostgreSQL for persistence is sufficient. Kafka makes sense only when multiple independent strategies share a common infrastructure.

Integrated Risk Management: Beyond Stop-Loss

When we talk about Risk Management in unified systems, we don't mean stop-loss alone. Stop-loss is a reactive tool — it works after the loss has already happened.

Real Risk Management in a unified system has five layers:

1. Pre-Trade Risk Checks

Before every order, the system must run several automated checks:

• Does this order's notional value exceed the maximum allowed for this instrument?
• Would adding this position push total portfolio exposure past a defined threshold?
• Has the number of orders in the past hour exceeded a set limit — a potential sign of a bug or runaway loop?
• Is the current market spread above a reasonable threshold that makes optimal execution impossible?

2. Intra-Trade Risk Monitoring

This layer is frequently overlooked. Between the moment an order is submitted and the moment it is filled, market conditions can shift. The system must maintain monitoring within that window as well.

3. Portfolio-Level Risk

This level of risk cannot be managed at the instrument level. You need to see the full portfolio picture:

• Concentration Risk: Is a large share of exposure concentrated in a single sector or asset class?
• Tail Risk: In a worst-case scenario, how much capital is actually at risk? This cannot be derived from simply summing individual stop-losses.
• Liquidity Risk: In a sudden crash, can you exit all positions at reasonable prices?

4. Regime-Based Risk Adjustment

This is where advanced systems diverge from simple ones. Risk parameters must change with market regime.

A practical example: in a low-volatility, strong-trend regime, you can operate with larger position sizes. In a high-volatility, range-bound regime, the same strategy should run with smaller sizes and tighter stops — even if signal strength looks identical.

For regime detection, you can use simple approaches like comparing rolling volatility to its historical percentile, or more sophisticated models like Hidden Markov Models (HMM).

5. Circuit Breakers

Circuit breakers are the last line of defense — not the first. If the system reaches a circuit breaker, it means the four layers above have already failed. That said, never operate without them:

• If daily drawdown exceeds X%, halt all trading
• If an instrument moves Z% in less than Y minutes, open no new positions
• If the exchange connection drops for more than N seconds, switch to safe mode

Advanced Position Sizing: Kelly and Beyond

The Kelly Criterion is one of the most foundational Position Sizing frameworks. The core formula is straightforward: f* = (bp - q) / b, where b is the return per unit of risk, p is the probability of success, and q is the probability of failure.

But Kelly Criterion has serious problems in the real world.

The Practical Problems with Kelly Criterion

First: Kelly assumes you know p and b. In practice, both parameters are noisy estimates. If your estimate of p is wrong, Kelly can push you into severe over-sizing.

Second: Kelly is designed to maximize growth, not control drawdown. Full Kelly can produce drawdowns that are psychologically and operationally unsustainable.

Third: Kelly assumes independent bets. In trading, positions are correlated — especially during market crises.

Fractional Kelly and Volatility Targeting

The common solution is Fractional Kelly — typically Half-Kelly or Quarter-Kelly. This approach significantly reduces drawdown while preserving most of the edge.

But in a unified system, Volatility Targeting is often more practical. The idea is to size each position so that its volatility contribution to the portfolio remains constant. For example:

If the goal is for each trade to add no more than 0.5% to portfolio volatility, and the current annualized volatility of an instrument is 20%, position size is calculated automatically — not from a fixed number.

This approach has one major advantage: it automatically reduces size during high-volatility periods and increases it during low-volatility periods — with no manual intervention required.

Execution Engine: Designing for Market Reality

The Execution Engine is where the largest gap between backtesting and live trading opens up. In backtesting everything is clean: take the close price, order fills. In live trading, that simplicity doesn't exist.

Slippage and Market Impact

Real slippage in quant systems comes from several sources:

• Bid-Ask Spread: The simplest and most visible cost
• Market Impact: The effect your own order has on price — when your size is large relative to market volume
• Timing Slippage: The gap between decision price and execution price — significant in fast-moving markets
• Queue Position: In the order book, your place in line can determine whether an order fills at all

Order Type Selection as a Strategic Decision

Most simple systems default to market orders. That's a mistake — not always, but often.

A simple decision tree for order type selection:

• If urgency is high and your edge is time-sensitive → Market Order, accepting slippage
• If the instrument is liquid and your size is below 1% of average daily volume → Limit Order near mid-price
• If size is large → TWAP (Time-Weighted Average Price) or VWAP to reduce market impact
• If you want entry at a specific price → Limit Order with a clearly defined timeout

Execution Monitoring and Feedback

After every order executes, the system must compare Expected Execution against Actual Execution. This gap — known as Implementation Shortfall — must be tracked continuously.

If Implementation Shortfall is deteriorating over time, that's a signal: either the market has changed, your strategy has grown large enough for market impact to matter, or your execution logic needs optimization.

Common Mistakes in Implementing This Architecture

1. Over-Engineering from Day One

One of the most common mistakes is trying to build all these layers perfectly and completely from the start. The result: a system that never reaches production.

A better approach: start with a simple State Manager and baseline layers. Only after the system is running live and the edge is confirmed should you add more sophisticated layers.

2. Backtesting with Unrealistic Assumptions

If your backtest assumes fills always happen at the close price, slippage doesn't exist, and order size has no constraints, your backtest results will have no relationship to live performance.

Minimum requirements for a realistic backtest:

• Simulate bid-ask spread using historical data
• Model market impact as a function of size relative to volume
• Apply realistic latency between signal generation and execution
• Account for commissions and funding costs

3. Ignoring Correlation During Crises