Nested Trading Decisions for Joint Portfolio and Execution Backtests
Summary
This document presents a framework for testing trading decisions made at multiple time scales together. It argues that portfolio selection and intraday order execution should interact within one backtest because execution quality can change which higher-level portfolio strategy performs best. Evaluating each layer separately may therefore misstate combined results and leave optimization between layers disconnected.
Each layer pairs a trading agent with an execution environment. The agent processes information, forecasts, and generates decisions; the environment returns execution outcomes. Environments can contain finer-grained agents and environments, such as breaking a daily order into intraday decisions. Users can customize the frequency, decision content, and execution setup, and the document points to reinforcement-learning support and illustrative examples. It explains the design rationale but gives no quantitative comparison or empirical performance results, so it does not establish that nesting improves results in any particular market or implementation.
Key ideas
- Portfolio decisions and order execution can affect each other's measured performance.
- A joint backtest can represent interactions across decision levels.
- Each framework level combines an agent that makes decisions with an environment that simulates execution.
- An execution environment can nest a finer-grained trading workflow, such as intraday order splitting.
- The document describes a framework, not evidence of improved strategy performance.
Tags
Full text
# highfreq
.. _highfreq:
========================================================================
Design of Nested Decision Execution Framework for High-Frequency Trading
========================================================================
.. currentmodule:: qlib
Introduction
============
Daily trading (e.g. portfolio management) and intraday trading (e.g. orders execution) are two hot topics in Quant investment and are usually studied separately.
To get the join trading performance of daily and intraday trading, they must interact with each other and run backtest jointly.
In order to support the joint backtest strategies at multiple levels, a corresponding framework is required. None of the publicly available high-frequency trading frameworks considers multi-level joint trading, which makes the backtesting aforementioned inaccurate.
Besides backtesting, the optimization of strategies from different levels is not standalone and can be affected by each other.
For example, the best portfolio management strategy may change with the performance of order executions(e.g. a portfolio with higher turnover may become a better choice when we improve the order execution strategies).
To achieve overall good performance, it is necessary to consider the interaction of strategies at a different levels.
Therefore, building a new framework for trading on multiple levels becomes necessary to solve the various problems mentioned above, for which we designed a nested decision execution framework that considers the interaction of strategies.
.. image:: ../_static/img/framework.svg
The design of the framework is shown in the yellow part in the middle of the figure above. Each level consists of ``Trading Agent`` and ``Execution Env``. ``Trading Agent`` has its own data processing module (``Information Extractor``), forecasting module (``Forecast Model``) and decision generator (``Decision Generator``). The trading algorithm generates the decisions by the ``Decision Generator`` based on the forecast signals output by the ``Forecast Module``, and the decisions generated by the trading algorithm are passed to the ``Execution Env``, which returns the execution results.
The frequency of the trading algorithm, decision content and execution environment can be customized by users (e.g. intraday trading, daily-frequency trading, weekly-frequency trading), and the execution environment can be nested with finer-grained trading algorithm and execution environment inside (i.e. sub-workflow in the figure, e.g. daily-frequency orders can be turned into finer-grained decisions by splitting orders within the day). The flexibility of the nested decision execution framework makes it easy for users to explore the effects of combining different levels of trading strategies and break down the optimization barriers between different levels of the trading algorithm.
The optimization for the nested decision execution framework can be implemented with the support of `QlibRL <./rl/overall.html>`_. To know more about how to use the QlibRL, go to API Reference: `RL API <../reference/api.html#rl>`_.
Example
=======
An example of a nested decision execution framework for high-frequency can be found `here <https://github.com/microsoft/qlib/blob/main/examples/nested_decision_execution/workflow.py>`_.
Besides, the above examples, here are some other related works about high-frequency trading in Qlib.
.. note::
New source builds require ``HighFreqProvider`` artifact paths, including derived
cache files, to remain inside ``artifact_root`` (the current directory by
default). Cached pickle contents still require independent trust. See
:ref:`artifact_loading_migration` before reusing existing provider configurations.
- `Prediction with high-frequency data <https://github.com/microsoft/qlib/tree/main/examples/highfreq#benchmarks-performance-predicting-the-price-trend-in-high-frequency-data>`_
- `Examples <https://github.com/microsoft/qlib/blob/main/examples/orderbook_data/>`_ to extract features from high-frequency data without fixed frequency.
- `A paper <https://github.com/microsoft/qlib/tree/high-freq-execution#high-frequency-execution>`_ for high-frequency trading.Shown in full with attribution under the source's licence. Licence: MIT
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.