You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Main goal of this proposal is to enhance the current FillModel implementation and allow complete flexibility in simulating order fills during backtesting. The proposal is based on this design proposal https://gist.github.com/stefansimik/fe9577649d8eb60dcc163830b003212d , that demonstrates the implementation approach through practical examples.
The core idea is to extend the existing L2 OrderBook-based processing with two key simulation points:
Market order fills - simulating how orders consume liquidity from the orderbook
Limit order fills - simulating partial fills when market price touches the limit price
Background & Motivation
The current FillModel handles only very basic order-fill scenarios and has significant limitations in its ability to simulate more complex scenarios such as:
Competition for liquidity
Varying liquidity conditions across trading sessions
Price impact for large orders
Partial fills
Order queue position simulation
Complex L1 data simulation
Proposed Solution
The proposal suggests extending the FillModel with two new methods that were analyzed and suggested by @cjdsellers as the best hooks for implementation:
Keep the current FillModel responsibility of determining if/how much of an order is filled
Default to no-op implementations for backward compatibility
Key benefits:
Enables simulation of any imaginable order-fill scenario
Centralizes all order-fill simulation logic
Leverages existing L2 OrderBook processing
Maintains clear responsibilities of FillModel
Historical Context
Currently, FillModel has only two primary settings (as documented in backtesting.md):
prob_fill_on_limit - Controls limit order simulation when price touches the order price
prob_slippage - Controls market order simulation and potential slippage
Importantly, all existing functionality can be easily replicated using the newly suggested model. The design proposal (see above link) includes specific examples demonstrating how to implement current behaviors, including probabilistic fills and slippage, while also enabling much more sophisticated simulation scenarios.
The text was updated successfully, but these errors were encountered:
The content of article can be summarized this way:
Dynamic Simulation and Meeting the Article's Expectations
The article emphasizes realistic order book modeling, simulating the arrival and departure of orders (including cancellations), incorporating partial fills, and reflecting continuously changing liquidity. Our proposed new FillModel effectively addresses these requirements by:
Core Concept – Dynamic L2 Order Book
The get_orderbook_for_fill_simulation(...) method allows returning a customized L2 order book at each "tick" or event (e.g., a new bar, a change in market state, or changing volatility). This flexibility makes it possible to swiftly adapt to shifts in liquidity, the arrival of new orders, or cancellations of existing orders.
Ability to Incorporate Queue Position and Partial Fills
By freely defining levels and volumes on the bid/ask sides, the model can precisely specify how much of an order is filled at a particular price level, with the remainder moving on to subsequent levels (thus reflecting partial fills). Likewise, it is possible to simulate price-time priority if the fill model's internal logic tracks queue position.
Adaptation to Various Trading Conditions
Depending on current market conditions (volatility, trading hours, heightened demand, etc.), the model can dynamically generate different liquidity profiles. The level of granularity is limited solely by the amount of detail we embed in the method's internal rules.
Accurate Approximation, Not Absolute Perfection
While this solution offers a high degree of flexibility in simulations, it is still an approximation of real markets, where unexpected factors can play a role. In practice, however, the ability to modify the order book in real time (whenever a fill is attempted) is robust enough to satisfy the advanced requirements described in the article.
In conclusion, this universal approach can largely meet the demanding expectations for microstructural simulations, while remaining both transparent and simple to configure.
Summary
Main goal of this proposal is to enhance the current
FillModel
implementation and allow complete flexibility in simulating order fills during backtesting. The proposal is based on this design proposal https://gist.github.com/stefansimik/fe9577649d8eb60dcc163830b003212d , that demonstrates the implementation approach through practical examples.The core idea is to extend the existing L2 OrderBook-based processing with two key simulation points:
Background & Motivation
The current
FillModel
handles only very basic order-fill scenarios and has significant limitations in its ability to simulate more complex scenarios such as:Proposed Solution
The proposal suggests extending the
FillModel
with two new methods that were analyzed and suggested by @cjdsellers as the best hooks for implementation:.process_market_fills
- integrated at: https://github.com/nautechsystems/nautilus_trader/blob/develop/nautilus_trader/backtest/matching_engine.pyx#L1577.process_limit_fills
- integrated at: https://github.com/nautechsystems/nautilus_trader/blob/develop/nautilus_trader/backtest/matching_engine.pyx#L1483Key implementation details:
FillModel
responsibility of determining if/how much of an order is filledKey benefits:
FillModel
Historical Context
Currently,
FillModel
has only two primary settings (as documented in backtesting.md):prob_fill_on_limit
- Controls limit order simulation when price touches the order priceprob_slippage
- Controls market order simulation and potential slippageImportantly, all existing functionality can be easily replicated using the newly suggested model. The design proposal (see above link) includes specific examples demonstrating how to implement current behaviors, including probabilistic fills and slippage, while also enabling much more sophisticated simulation scenarios.
The text was updated successfully, but these errors were encountered: