Flagging Extreme Cryptocurrency Trade Errors with Dynamic Winsorization
Summary
The document considers how to identify suspicious cryptocurrency tick trades that could distort a backtest. Its example describes an apparent brief collapse in a coin’s recorded price followed almost immediately by a return to its prior level. The question discusses rolling-statistic filters and a reversal-time heuristic, noting that low dispersion can create false flags and that thresholds for move size and reversal speed can be hard to choose.
The response proposes dynamic winsorization based on recent price history, reflecting that crypto prices and volatility can change over time. It suggests treating very large tick moves as suspicious, while acknowledging that high volatility makes simple thresholds imperfect. It also offers a possible market-microstructure explanation: an order book may be cleared or restarted, allowing a poorly timed market order to execute against a newly placed limit order. That explanation is tentative, and the document does not validate it or specify a calibrated detection procedure. It therefore supports flagging trades for review rather than establishing a definitive automated error classifier.
Key ideas
- Extreme, quickly reversed tick moves can create misleading backtest results.
- Fixed rolling thresholds may produce false positives when recent price dispersion is low.
- Dynamic winsorization can adapt outlier limits to changing price levels and recent history.
- A large tick move is suspicious but is not proof of a bad trade in a volatile market.
- Order book clearing and restart behavior is offered as a possible explanation, not a confirmed cause.
Tags
Full text
# Process for Removing Error/Incorrect Cryptocurrency Trades # Process for Removing Error/Incorrect Cryptocurrency Trades I have many time series of cryptocurrency pair trade data from Kraken (available for batch download here) with some that are very long and others that are very short. I am attempting to build a basic backtesting framework, but have noticed that there are at least a few likely-to-be—error trades in some of the time series that have suspiciously extreme price changes (even given cryptocurrency volatility) leading to spurious backtesting results. For example, for XMRUSD (Monero/US Dollar) trades between 2018-01-13 11:23:10 UTC and 2018-01-13 11:23:21 UTC (inclusive), the price drops from ~400 to 0.01 and, immediately after this period, goes back up to ~400 and I was not able to find any references on why this occurred. Attached at the bottom is the trade prices and trade volumes between 2017 and now with the supposed-error trades drop circled in red. I am looking for a parsimonious way that is used in practice to identify these extreme price outlier errors in an automated fashion. The global series and/or all trade series together can be used since I don't think we are worried about look-ahead bias at this time. If a fully-automated approach is not feasible, I would like to know if a semi-automated approach where suspicious time series are flagged if they meet any suspicious criteria e.g. sharp changes in prices, etc. is something that could/has been applied. I have tried a few approaches like looking at both robust and not-so-robust rolling statistics, but ran into problems involving low dispersion incorrectly flagging many trades. I have also tried a sort of time-to-retracement measure where I look for the trades with the most extreme-in-magnitude returns in a given series and look at the number of trades between them, and if that is “small” and the magnitude of the returns is “large”, flagging all intermediate trades. This seems to work, but I feel as if there are edge cases that I am not able to think of and determining what “small” and “large” is feels arbitrary to me. Thanks! ## Answer by Bob Jansen (score 2) https://quant.stackexchange.com/a/84069 Just to put something out there: I think dynamic winsorization (that is, based on recent history as crypto's have gone from subcent prices to \$100+) is a fair approach. Yes, the market is volatile but jumps in tick data of 5% or more are suspicious). I also came up with one explanation for how these could have actually happened but I haven't looked into it: Kraken runs 24/7 but hickups where the order books are cleared/restarted seem inevitable. In such cases, a badly timed market order could take out a limit order that is inserted just after the book was cleared.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.