Take the 2-minute tour ×
Quantitative Finance Stack Exchange is a question and answer site for finance professionals and academics. It's 100% free, no registration required.

The bid-ask bounce is the bouncing of trade prices between the bid and ask sides of the market. It introduces a systematic bias to the data which can cause serious problems in analysis.

What methods can be used to control for the bid/ask bounce when using high-frequency data? One approach is to use the bid/ask midpoint, but what about with trade data? Even using n-minutely VWAP prices doesn't guarantee that you won't have spurious mean-reverting behavior.

share|improve this question
    
Given sufficient liquidity, I just mark positions to mid; the last trade price can highly variable. –  chrisaycock Jun 23 '11 at 13:48
    
@Shane, please see meta.stackoverflow.com/questions/5234/… –  user508 Dec 31 '12 at 23:34
add comment

3 Answers

up vote 6 down vote accepted

Why not just use the weighted mid-market price, quoted as (Bsize * Aprc + Asize * Bprc) / (Asize + Bsize)? This measure doesn't suffer a bounce per se and allows you to directly take moving or exponential moving averages.

share|improve this answer
    
Thanks. Weighted mid-price is the best approach that I can find. –  Shane Jan 1 '13 at 19:27
    
@Foo, can you comment why prices are weighted by amount of another side? I could not find any information about it. Or it is a typo? –  Ilya Aug 28 '13 at 8:16
    
@Ilya That's not a typo. When there are many buyers, they repeatedly hit the ask price, lowering the available ask size. So we weight the bid less heavily, and the weighted price rises. Likewise, when sellers arrive, the weighted price falls. –  pteetor Oct 22 '13 at 20:00
add comment

You don't say what it is that you do with trade data that is made difficult by the bid-ask bounce.

If it's for the purpose of establishing the price at which you can trade and it's at a frequency where the bid-ask bounce is a problem, then I think having realistic execution assumptions is the way to go. In particular this means that you should be mainly looking at quotes rather than trades in order to establish prices.

For most other applications that I can think of, either smoothing or reducing the frequency of the data seem the way to go.

share|improve this answer
    
Do you happen to know of any papers that discuss this? –  Shane Jun 23 '11 at 9:53
add comment

IMO transaction data is a better approach, because you have both sides of the trade agreeing that the price is "right." The literature tends to decompose the transaction price $P$ into a true/efficient price $P^e$ plus micro-structure noise, which I think originates from Hasbrouck '93 in the Review of Financial Studies. So you end up with something like $$P^e_t = P^e_{t-1} + \nu$$ and $$P_t = round(P^e_t + c_t Q_t, d)$$ where $\nu \sim N(0, \sigma^2_t)$, $c_t > 0$, $Q_t \in \left\{-1, 1 \right\}$, and $d$ is the tick size. Note that $c_t$ provides the spread and $Q_t$ tells you if the transaction is buyer or seller initiated (typically determined with the "Lee-Ready algorithm"). I found this particular presentation in a 2002 working paper from Engle and Russell; I think this is pretty standard and you can probably find a good deal of research that tries to provide $c_t = f(\cdot)$. It looks like a Andersen, Bollerslev, and Diebold have a 2007 NBER working paper that provides a more thorough treatment of these ideas.

When you're dealing with (ultra) high-frequency data you also have the problem of time to transaction. Engle has a 2000 Econometrica paper in which he describes how to account for time to transaction, but he's using bid-ask midpoints, not transactions.

I don't have any first-hand experience to know if using the midpoint is a bad assumption in practice, but the 2000 and 2007 papers should be a good start.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.