Tape/Time and Sales: why actual trades do not decrease bid/ask sizes?

traderwerks · August 20th, 2012, 10:52 AM

Nicolas11

I have made a similar test with YM @ CME, for which I have both Level I and Level II through DTN IQFeed.
Seems "normal", as illustrated here-below.

The numbers between [] are the ID numbers of the messages in the feed (to be sure that I have not missed any).

There are two cases.

1st case: the trade(s) do(es) not take all the liquidity at the level. Then next bid/ask update reflects the decreasing liquidity.

Example: 1 trade at the ask

[128935] Update without trade: Ask = 18 @ 13215 - Bid = 8 @ 13214 | 2012-08-20 16:36:38
[128936] New trade at the ASK: 1 @ 13215 - Ask = 18 @ 13215 - Bid = 8 @ 13214 | 2012-08-20 16:36:38
[128937] Update without trade: Ask = 17 @ 13215 - Bid = 8 @ 13214 | 2012-08-20 16:36:38

Example : 2 trades at the bid

[127848] Update without trade: Ask = 22 @ 13212 - Bid = 11 @ 13211 | 2012-08-20 16:36:01
[127849] New trade at the BID: 2 @ 13211 - Ask = 22 @ 13212 - Bid = 11 @ 13211 | 2012-08-20 16:36:02
[127850] New trade at the BID: 1 @ 13211 - Ask = 22 @ 13212 - Bid = 11 @ 13211 | 2012-08-20 16:36:02
[127851] Update without trade: Ask = 22 @ 13212 - Bid = 8 @ 13211 | 2012-08-20 16:36:02

2nd case: the trade(s) do(es) take all the liquidity at the level. Then next bid/ask update reflects the up/down tick

Example : 1 trade at the bid

[127061] Update without trade: Ask = 23 @ 13212 - Bid = 1 @ 13211 | 2012-08-20 16:35:58
[127062] New trade at the BID: 1 @ 13211 - Ask = 23 @ 13212 - Bid = 1 @ 13211 | 2012-08-20 16:35:58
[127063] Update without trade: Ask = 23 @ 13212 - Bid = 32 @ 13210 | 2012-08-20 16:35:58
[127064] Update without trade: Ask = 23 @ 13212 - Bid = 30 @ 13210 | 2012-08-20 16:35:58
[127065] Update without trade: Ask = 23 @ 13212 - Bid = 29 @ 13210 | 2012-08-20 16:35:58
[127066] Update without trade: Ask = 24 @ 13212 - Bid = 29 @ 13210 | 2012-08-20 16:35:58
[127067] Update without trade: Ask = 25 @ 13212 - Bid = 29 @ 13210 | 2012-08-20 16:35:58
[127069] Update without trade: Ask = 27 @ 13212 - Bid = 29 @ 13210 | 2012-08-20 16:35:58
[127070] Update without trade: Ask = 2 @ 13211 - Bid = 29 @ 13210 | 2012-08-20 16:35:58

The green part illustrates a very short-term "liquidity vaccum": we have to wait 5 messages until the bid/ask spread reduce to 1 tick.

Example : 2 trades at the ask

[127673] Update without trade: Ask = 3 @ 13210 - Bid = 37 @ 13209 | 2012-08-20 16:36:00
[127675] New trade at the ASK: 1 @ 13210 - Ask = 3 @ 13210 - Bid = 37 @ 13209 | 2012-08-20 16:36:00
[127676] New trade at the ASK: 2 @ 13210 - Ask = 3 @ 13210 - Bid = 37 @ 13209 | 2012-08-20 16:36:00
[127677] Update without trade: Ask = 28 @ 13211 - Bid = 37 @ 13209 | 2012-08-20 16:36:00
[127678] Update without trade: Ask = 26 @ 13211 - Bid = 37 @ 13209 | 2012-08-20 16:36:00
[127679] Update without trade: Ask = 26 @ 13211 - Bid = 39 @ 13209 | 2012-08-20 16:36:00
[127680] Update without trade: Ask = 24 @ 13211 - Bid = 39 @ 13209 | 2012-08-20 16:36:00
[127681] Update without trade: Ask = 21 @ 13211 - Bid = 39 @ 13209 | 2012-08-20 16:36:00
[127682] Update without trade: Ask = 20 @ 13211 - Bid = 39 @ 13209 | 2012-08-20 16:36:00
[127683] Update without trade: Ask = 19 @ 13211 - Bid = 39 @ 13209 | 2012-08-20 16:36:00
[127684] Update without trade: Ask = 18 @ 13211 - Bid = 39 @ 13209 | 2012-08-20 16:36:00
[127685] Update without trade: Ask = 18 @ 13211 - Bid = 2 @ 13210 | 2012-08-20 16:36:00

Nicolas

Orders are being cancelled and you are not getting those messages.

August 20th, 2012, 10:57 AM

traderwerks

Orders are being cancelled and you are not getting those messages.

Here, we are just talking about best bid / best ask, so the 1st level in the DOM on each side.
You are saying that, if a limit order resting on the 1st levels of the DOM is cancelled, there is no update message in the T&S.
I am not so sure.
For example, let's have a look at this sequence (extracted from above):
[127064] Update without trade: Ask = 23 @ 13212 - Bid = 30 @ 13210 | 2012-08-20 16:35:58
[127065] Update without trade: Ask = 23 @ 13212 - Bid = 29 @ 13210 | 2012-08-20 16:35:58
I think that the 2nd message reflects that 1 order was pulled out from the DOM.
I do not pretend to be right. Just discussing. I'm new in the T&S party. And eager to learn.

Nicolas

Jigsaw Trading · August 20th, 2012, 11:06 AM

Is Ninja the platform here?

Just so you know - there's a couple of places Ninja stores the current bid/ask and they are not updated @ the same frequency.

Can you show the lines of code you have that are displaying this?

August 20th, 2012, 11:11 AM

The platform is Sierra Chart.
So there is no "storage issue" as with Ninja Trader. I mean: everything is built-in.
The code is very short and uses the built-in function sc.GetTimeAndSales which gives access to the T&S messages.
The code just reads these T&S messages one after the other and adapts the printing according to "new trade" or "update" (it is a "field" of the message).

Jigsaw Trading · August 20th, 2012, 11:34 AM

Nicolas11

The platform is Sierra Chart.
So there is no "storage issue" as with Ninja Trader. I mean: everything is built-in.
The code is very short and uses the built-in function sc.GetTimeAndSales which gives access to the T&S messages.
The code just reads these T&S messages one after the other and adapts the printing according to "new trade" or "update" (it is a "field" of the message).

I don't think each individual T&S message contains the qty at bid & at ask - there are separate messages for trades/depth changes/price changes.

August 20th, 2012, 02:28 PM

Nicolas,
it could be a Sierra problem. I havent it install anymore, but if you look at the times and sales window on their site you will see that the bid and ask sizes change only on the next tick, ie at 1:09:58 the sizes remain constant till 1:10:00. Dont know if this is fixed now.

August 20th, 2012, 02:31 PM

@SPMC,

I think that this behaviour is normal.

As you say, T&S Window only updates at each new transaction.

However, sc.GetTimeAndSales() gives more information:
- what happens at each transaction (same as T&S Window)
- and update of best bid / best ask between transactions

Nicolas

Jura · August 20th, 2012, 04:26 PM

Interesting. MultiCharts 8.0 with ZenFire on 6E has the same behaviour (bid and ask don't change after trade):

Code

20-08_22:25:40  6E Update without trade. InsideBid: 15  InsideAsk: 4
20-08_22:25:41  6E Update without trade. InsideBid: 15  InsideAsk: 4
20-08_22:25:41  6E Update without trade. InsideBid: 15  InsideAsk: 4
20-08_22:25:41  6E Update without trade. InsideBid: 15  InsideAsk: 4
20-08_22:25:41  6E Trade done: 7. InsideBid: 15  InsideAsk: 4
20-08_22:25:41  6E Update without trade. InsideBid: 15  InsideAsk: 4
20-08_22:25:41  6E Update without trade. InsideBid: 14  InsideAsk: 4
20-08_22:25:41  6E Update without trade. InsideBid: 14  InsideAsk: 4
20-08_22:25:41  6E Update without trade. InsideBid: 14  InsideAsk: 4
20-08_22:25:42  6E Update without trade. InsideBid: 14  InsideAsk: 4
20-08_22:25:42  6E Update without trade. InsideBid: 14  InsideAsk: 4

Perhaps a coding error from my part?

Code

Variables:
	IntraBarPersist PrevBid(0),
	IntraBarPersist PrevAsk(0),
	IntraBarPersist PrevVolume(0),
	sizeOfTrade(0), bidSize(0), askSize(0);
	
if (dom_isconnected) then begin 	
	bidSize = DOM_BidSize(0);
	askSize = DOM_AskSize(0);	
end;

if (Ticks <> PrevVolume) then begin 

	if (BarStatus(1) = 1) then 
		sizeOfTrade = Ticks
	else 
		sizeOfTrade = PrevVolume - Ticks;	

	Print(TimeNow, SymbolName, " Trade done: ", NumToStr(sizeOfTrade, 0), 
		". InsideBid: ", NumToStr(PrevBid, 0), "  InsideAsk: ", NumToStr(PrevAsk, 0));

end else begin 

	Print(TimeNow, SymbolName, " Update without trade. InsideBid: ", NumToStr(PrevBid, 0), 
		"  InsideAsk: ", NumToStr(PrevAsk, 0));

end;
	
PrevVolume = Ticks;	
PrevBid = bidSize;
PrevAsk = askSize;

RecalcLastBarAfter(0.1);

August 20th, 2012, 04:32 PM

Jura,

Is it correct to say that, roughly speaking, your code is executed again and again at each new tick or after 100ms, whichever comes first?

Nicolas

Jura · August 20th, 2012, 04:38 PM

Nicolas11

Is it correct to say that, roughly speaking, your code is executed again and again at each new tick or after 100ms, whichever comes first?

Yes indeed, due to the RecalcLastBarAfter keyword.

Tape/Time and Sales: why actual trades do not decrease bid/ask sizes?

Discussion in Traders Hideout

Tape/Time and Sales: why actual trades do not decrease bid/ask sizes?