Understanding Interactive Brokers tick events

Question

When receiving financial tick data through Interactive Brokers' API methods tickPrice or tickSize the data will have the following parameters

• tickerId (symbol)
• field (1=bid, 2=ask, 4=last, 6=high, 7=low, 9=close)
• price
• canAutoExecute

From any other feed I would expect a tick to give me

• tickerId (symbol)
• bid
• ask
• bid size
• ask size

So my question is: Should I keep a dictionary with tickerId as key and a struct as value containing the above five properties, such that each time a tick event is raised I would update the struct's respective property and send the whole struct to my database as a tick? Ideally my tick database would look something like this

Date        Time            Symbol  Side    Price   Quantity
2012-10-31  13:51:13.784    AAPL    Bid     25.81   15007
2012-10-31  13:51:14.615    AAPL    Bid     25.82   10
2012-10-31  13:51:14.633    AAPL    Bid     25.81   13623
2012-10-31  13:51:14.684    AAPL    Ask     25.82   2500
2012-10-31  13:52:09.168    AAPL    Bid     25.80   12223

From the IB API documentation: This method is called when the market data changes. Does this mean that if e.g. bid price is updated, the other properties will remain the same?

Broca

wise question but there is something that is still not clear to me. How do you properly determine date and time of that particular tick? It doesn't seem that either tickPriceor tickSize return timestamped information. – Bone

IB doesn't send timestamps - you have to use the current system time on each tick. As mentioned in the answers below, the data is not real ticks but rather 200-300ms snapshots. – Broca

to me current system time is almost useless. It can have an arbitrary unknown unpredictable delay with reference to the real tick time. System clock skewness, network jitter, packet retransmissions etc.. I am not sure how you can you reliably use the current system time. – Bone

IB never was and probably never will be an accurate and reliable source of live, streaming market data. It's free. – Ferocious

@FredQuatro The tickPrice callback is indeed useless without timestamps. The latest API has tickByTickAllLast and tickByTickBidAsk which have timestamps. – Metallo

Answer 1

You are right. Whenever a certain property changes, a new tick event will be triggered. Your design of using a struct to save the tick snapshot is one of the standard approaches.

In other word, IB's API will send back each aggregated tick as they arrive. However, these ticks are not real ticks, as they are only 0.2 - 0.3 second snapshots. If you you are dealing with HFT, then these data may bot be reliable for order book simulation. However, if you are just performing basic data analysis, then their quality is acceptable.

Their high, low and close price in this case may not be useful, as standard order book will not contain high, low close information. I will usually discard them. Bid size and ask size are also not reliable in this case, since they are just synthetic ticks.

Hope my answer helps.

Shadbush

Thanks a lot. I agree IB isn't the way to go for production feed. – Broca

@Broca , I think that depends greatly on the strategy. For something working with hourly/daily and honestly even minute-level data, it's really fine. I think a lot of people want "true" market data, right up until they have a lot of symbols to track and it's a heavy day. Even with decent hardware and excellent network connections you can bog down, as where the IB API, because it's a snapshot, won't suffer those problems. – Pomerania

Answer 2

It depends on what you introduce in the reqMktData() method:

void reqMktData(       TickerId          id,
                 const Contract         &contract,
                       IBString         &genericTicks,
                       bool              snapshot,
                 const TagValueListSPtr &mktDataOptions
                       )

If you write snapshot = true, you will receive a single snapshot of the data.

If you write snapshot = false, you will receive a new variable bid or ask everytime it changes, or possibly aggregated at every ~0.2-0.5 seconds. If the bid or the price has moved you will get a callback in tickPrice or respectively for size/volume in tickSize.

Prandial

A nice piece, @Prandial - Would you mind to kindly add also some insights on how to add the dataFeed provider-side ( non-jitter-ed ) timestamps? – Copernicus

@Prandial - Are you sure about this? From IB website (interactivebrokers.com/en/software/api/apiguide/c/…) you can see it says: "Check to return a single snapshot of market data and have the market data subscription cancel. Do not enter any genericTicklist values if you use snapshot.". And according to my testing as well - setting the snapshot to true will return a snapshot data and will cancel the current data subscription. – Neuroglia

I am sure about it. But in any case if you have a problem like this you should call Interactive Brokers. – Prandial

Answer 3

Wen you consider the data feed that IB provides, consider the situation where you want to update the data in a display form/page. In this case, if an exchange generates a new best bid quote at the same bid price, only with a different size, then it only makes sense to send the new size (and not the bid price again which has not changed). In addition, IB will batch up these changes over something like 200 or 300 milliseconds so not every change is propagated.

If you look at it in this context, the data feed is actually quite efficient in terms of minimizing the size and frequency of messages.

Most folks are instead familiar with what a more complete Level 1 data feed is providing (such as the Consolidated Quote System). In this case, every change in price or size generates a complete new quote message which contains all of the fields.

Which type of data feed you require depends heavily on your specific use case. For example, I have worked on providing very detailed (e..g, every quote message) billion-record data sets to clients only to discover they were aggregating the data into 1-minute OHLCV bars.

So it is really a matter of being able to match your data data requirements to your analysis requirements. In some cases IB's data will work just fine. In other cases, it will not.

Ritter