Replies: 2 comments 1 reply
-
|
I understand that you are fully aware of how the strategy works and have rewritten it in your version, as the example heavily depends on rebates. The most important thing is to compare your backtest results with the live results, taking into consideration latencies (both feed and order) accurately. Additionally, based on my recent observations, it seems that filling orders in the queue is more difficult, so there is a need to apply a more significant penalty for queue fills. One of the variations In addition, the recent market has more volatile and higher trading volume. It also requires model or parameter modification. Some crypto futures in Binance Futures have a large tick size. Even at BBO, spread can be large. Also spread capture can happen over time. |
Beta Was this translation helpful? Give feedback.
-
|
Hey!
Yes, i got the gist of how it works. Some assets do indeed produce most of the returns due to high volumes and rebates, while some can achieve moderate volumes and returns are mostly speculative (judging by the return graphs).
Inone of your examples, you use latencies of the real exchange. But there is no example on how to actually implement it in backtesting. Can you elaborate a bit on it? I can save a file with latencies of order updates, for example. And latencies of making calculations - i do store them. So do i have to store the live feed of book updates along with those latencies and what is the correct way to do this? This step might bring me closer to simulating an environment i am trading in.
When comparing the results, you should ensure that the position changes over time are almost the same, in other words, order fill should be almost the same. Plotting live position over time with backtest position over time is helpful.
|
Beta Was this translation helpful? Give feedback.
-
|
As for order latency, please see https://hftbacktest.readthedocs.io/en/latest/latency_models.html#intporderlatency I don't know what data source you use, whether collecting yourself or purchasing it from a vendor, it has to have both receive timestamp by local and exchange timestamp. You need to pinpoint what makes a difference between the backtesting result and the live result. |
Beta Was this translation helpful? Give feedback.
-
Hi!
I am trying to test a strategy based on orderflow imbalance and volatility in live setting. While in backtesting on a few months it shows very promising results with high Sharpe ratio and returns, in live setting i am losing money. I get very low latencies, so this is probably not the issue. Although i haven't compared live data with that from Tardis to be able to check wether i am getting the same values of alphas in both testing and live, i am quite sure i have implemented the algo just like in the backtest.
In live setting, i can see that i get too much fills compared to backtest. Currently i am using SquareProbQueueModel and PartialFillExchange. Should i experiment with different models?
I can also see that for some assets, in order to get a profitable results in a backtest, one must use a very low skew - like 0.02 or similar. And i also note that in both live and backtest, fills are usually close to the bbo (like 1-2 ticks away at most) rather than capturing the spread like in the classical market making.
What would be your top things to check first?
Beta Was this translation helpful? Give feedback.
All reactions