Preventing losses on market spikes

[szverev]

Hello and thank you @nkaz001 for the repo,
Maybe you could share some recommendations against losses on market spikes?
The algo might work well for several hours, and then lose everything in a couple of minutes, which happens quite often.
I've added exponential moving average to affect bid and ask depth, and it looks like it got slightly better, but still, it always gets negative after some time.

[nkaz001]

This should be the extensive research topic in HFT. While I don't have a clear answer, but several concepts come to mind.

Firstly, if you artificially reduce latencies, particularly amid rapidly moving markets-whether it's feed latency or order latency-you can see the potential to substantially curtail losses. In the specific case of crypto markets, a low-latency API would be a key factor. Essentially, having a low-latency API accessible only to eligible market makers could be a way to improve losses in spikes.

Secondly, integrating with alpha signals or broader forecasts could be beneficial. Short-term alpha, volatility forecast, reactions to news, and monitoring other markets might provide help to reduce the losses and enhance the profits.

Lastly, hedging could also mitigate this problem. By hedging effectively, you can maintain a position as close to flat as possible. For example, you could balance your total positions in various assets to be dollar-neutral. Alternatively, during price spikes, identifying the most cost-effective hedges in other markets or assets could help reduce exposure and potential losses.

Ultimately, it might be imperative to acknowledge losses during spikes while vigorously striving to accumulate substantial profits under normal market conditions that surpass the spike-induced losses.

In addition, regarding the example model specifically, there are two issues in terms of order arrival measurement.

Firstly, the exponential model's fit is not applicable across all ranges. Order arrival rates might not be well-captured in fast-moving markets.

Secondly, the measurement itself has an issue. In the given example, order arrival depth is measured as follows:

arrival_depth(t) = mid(t - 1) - sell_trade(taking bid) or buy_trade(taking ask) - mid(t - 1)

Under normal market conditions, given our short interval, the mid-price is likely to remain relatively stable, with most trades occurring around the prior mid.

But, during rapid market shifts, mid(t - 1) - sell_trade(taking bid) or buy_trade(taking ask) - mid(t - 1) can turn negative due to bids and asks establishing far from the prior mid. In our measurement of order arrival rate, the negative order arrival depth remains unaccounted for, potentially leading to an underestimation of order arrival depth in fast-moving markets, as the model uses symmetric modeling.

Consequently, the current model might not sufficiently increase the spread during spikes and it would induce losses.

[sunlei]

https://github.com/im1235/EIE

Does this help in calculating the trading intensity?

[nkaz001]

I didn't examine the code in depth, but the calculation is done in a similar way.

[sunlei]

This based on level 1 tick data.
In your example code, it is calculated using trades.

I attempted to implement this EIE, and the calculated values for A and K differ significantly, for example:

hftbacktest

A=26.892482423039848 k=0.028235842329383913

EIE

buy_a=0.1585462312683217 buy_k=241386.55721056912 sell_a=0.5841032707588829 sell_k=962431.6894458812

[nkaz001]

I think the difference comes from how the order fills are determined; I use trades.

[szverev]

Thank you very much for the detailed answer!
I've added the exponential moving average just to increase the spread during spikes.
I use it to add a linear multiplier to bid or ask depth, upon the threshold achievement, but maybe that's too simplistic and so gives not that much of profit. Will conduct further research.

[nkaz001]

In my experience, I haven't seen types of moving average of market being helpful, as they are typically lagging indicators.
I'm not sure, but I think it should be kinds of so-called 'nowcast' at least.
Regardless of whether an indicator is forecasting or lagging, a reaction speed(low latency) is crucial.

[nkaz001]

my recent finding on this issue might be helpful. https://hftbacktest.readthedocs.io/en/latest/tutorials/Risk%20Mitigation%20through%20Price%20Protection%20in%20Extreme%20Market%20Conditions.html