Real time tick data for *all* NASDAQ, NYSE, and AMEX stocks

[Silicon]

As far as I know (please correct me), all commercial data feeds provide a limited number of simultaneous ticking items, e.g. up to 500 or 1000 symbols. In contrast, institutional traders often have access to data feeds which enable real time viewing/processing of tick data for every listed instrument on one or more exchanges, which has obvious advantages for system traders with programming skills. It may not be possible to use a 'complete' feed in combination with off-the-shelf trading software. E.g. NASDAQ, NYSE, and AMEX has approximately 8100 listed equities and to import the bid/ask/trade with volumes (48,600 ticking items) into an application such as TradeStation is probably not realistic.

Given a data feed which can provide all tick data for these three exchanges in real time while also retrieving historical tick data without bogging down a mid-range PC, would this be considered a good data offering or would it be largely meaningless because of being limited to traders who are also reasonably proficient at programming? I.e. would it be worth offering such a feed via an API, or is the market for such a specialized product simply too small?

 

[NotQuiteRandom]

I would buy it if the price was right and the technology was stable. My total data bill (including leased line) for US and non-US feeds was $68k in 2006 because I get every tick on a large number of exchanges including the largest (CBOE) by quantity.

Are you thinking web based or leased line?

Would there be a lot of demand? I guess that depends on the price, delivery method, format etc. Do you have a ticker plant capable of this?

 

[Silicon]

It is a web based offering, but in order to receive *all* data you will need a broadband connection (at least 512k). Our ticker plant is capable of it, but we need to decide on what to offer and at what price. Beta testing should tell us a lot but at this stage we are trying to get a preliminary idea of what the demand would be like. The question for us is whether there is sufficient demand for an API-only offering, i.e. without charting/trading software.

 

[NotQuiteRandom]

If you do decide to offer it please let me know. While I am in the process already of swapping one of my data vendors I am keen to keep up with who is offering what.

I have no interest in commercial charting software.

Thanks.

NQR

 

[Silicon]

I will post a notification to this list as soon as we open the public beta.

 

[dcraig1]

Here's a few suggestions:

1. Make the API open. Publish both the API source and the protocol specification, as do OpenTick : http://www.opentick.com

2. No local servers - and especially no local Windows servers that do caching etc. API should connect direct to the remote tick servers.

3. Platform independent. C, Java and whatever other languages you want to support.

 

[Silicon]

I am not in a position to make these decisions. The current situation is as follows:

1. We will provide sample projects which demonstrate use of the API in various languages (source code), but this source will be linked to a DLL for which we cannot provide the source. Also, the data will not be free.

2. The API connects directly to remote servers, but data caching may be enabled on client machines for reasons of efficiency (e.g. persistence across sessions). This mechanism is under control of the API user and can greatly reduce bandwidth usage (and speed) in many instances.

3. The API library (DLL) is implemented in .NET. It can be accessed from any .NET language and also runs on Linux and OS X via Mono.

 

[dcraig1]

3. The API library (DLL) is implemented in .NET. It can be accessed from any .NET language and also runs on Linux and OS X via Mono.

Nobody will use Mono for this. For all practical purposes it is Windows only.

 

[NotQuiteRandom]

WINDOWS?!?!?!?!?! Groan! I will NEVER use Mr. Gates' dodgey products with their viruses, spyware, trojans, crashing, black box source code etc.

I fail to understand why one would elect to take an expensive and dangerous option over a free and transparent one...

Linux over here please...

NQR

 

[Silicon]

Nobody will use Mono for this. For all practical purposes it is Windows only.

It is true that Linux has a very small market share relative to Windows on the desktop, but it is different in the server space. And since Mono is rapidly gaining momentum among developers, our thinking was that *if* there are Linux users needing good data via an API, a .NET/Mono API would be a good choice.

But I don't want this to turn into a "platform x vs. platform y" discussion. What I am trying to establish is what the takeup would be for an API providing real-time tick data (and history) for *all* items on NASDAQ, NYSE, and AMEX. By receiving all data in real time like institutional traders, systems can be implemented which are not otherwise possible (read more money). We consider this a big plus, but ultimately we need the traders out there to tell us whether this is something they want and what they would be willing to pay for it.

 

[dcraig1]

It is true that Linux has a very small market share relative to Windows on the desktop, but it is different in the server space. And since Mono is rapidly gaining momentum among developers, our thinking was that *if* there are Linux users needing good data via an API, a .NET/Mono API would be a good choice.

IMHO, this is a very wrong assessment. The amount of Java code running on Linux systems would be orders of magnitude greater than Mono code. Java is actively backed by Sun, IBM, BEA, Oracle etc. Only Novell is backing Mono and Novell is being viewed with some suspicion by the open source community following its recent deal with Microsoft. Java is now GPL, which means it will very likely be included in every Linux distribution and be viewed more favorably by the open source community. Java is mature and robust but there is a real question mark over mono. There are many, many Java developers familiar with Java on *nix. How many mono developers ? I can't think of any reason reason to use Mono for a new project, but I can see a lot of risk.

The reality is that developers are far more likely to use any of C++ (with something like QT4 for GUI), Java, Python etc than Mono on *nix systems or for cross platform applications.

If you provided a basic C API, developers could create bindings to just about any language that wished to use. A more open approach would be viewed favorably by prospective developers.

 

[Silicon]

Your arguments are sound and I do not disagree:

1) For all practical purposes it will be Windows only.
2) On Linux, Mono may not be the best choice of API.

But since Windows dominates the market, we have decided to provide a .NET API which also enables us to run on Linux and OS X. The API is extremely simple and provides immediate results for novice- and professional programmers alike (regardless of platform). This is not the case for many of the API's we have used ourselves (myTrack, IQFeed, REUTERS, etc.). If there is a need for a basic (open) C API, or if this would be viewed more favorably by prospective developers, then we will certainly be able to provide it.

The real question remains: Are 'limited' data feeds such as myTrack, IQFeed, REUTERS, etc. sufficient, or are there significant numbers of traders capable of extracting value from a 'complete' data feed which provides all market data. I.e. assuming an API in your programming language of choice, would you be willing to pay for such a feed? If not, would it be because (a) an API-only feed (without built-in charting/trading software) would not be useful to you, or (b) you do not see the value of having real-time access to all data for a number of exchanges?

 

[pp7]

Any update on this? Sounds like a very exciting project and something that I would pay for if the price is right!

 

[Silicon]

It would appear that the trading community is not overly enthusiastic about a data-only product. Perhaps the market for program traders (the most likely users of a data API) is not as big as we thought. As a result of this we have had to rethink our strategy and this has caused some delays. At this stage we are still planning on making the data available via an API, but we will also need basic viewing/charting facilities in order to reach a broader user base. This is currently under development. Our current plans are to start beta in the last quarter of this year. In the meantime, any thoughts/comments are welcome.

 

[pp7]

Any idea how much this would cost?

 

[Silicon]

There are currently very few data feeds which can provide all data for all exchanges as well as history in real time. Even feeds which provide only a subset of this are typically very expensive. We consider these feeds to be hugely overpriced and our belief if that a fairly priced product which provides accurate data, never goes down, is fast, stable, and easily accessible will prove popular. In summary, we are planning on pricing it very aggressively, but we need the community to provide us with an indication of what would be considered 'reasonable' for a product of this nature. Assuming that it operates as advertised, what would you consider a fair price? This is the question I initially asked in this thread.

 

[Silicon]

We are now accepting user registrations for the public beta. Interested parties can register at our website: FuturePrice or https://secure.futureprice.com

 

[tubemann]

We are now accepting user registrations for the public beta. Interested parties can register at our website: FuturePrice or https://secure.futureprice.com

The signup form is broken.

 

[Silicon]

Sorry about the delay. I did send a private message yesterday - not sure that you received it.

Please let me know which operating system and browser you are using, and the error message you are receiving.

 

[tubemann]

Sorry about the delay. I did send a private message yesterday - not sure that you received it.

Please let me know which operating system and browser you are using, and the error message you are receiving.

This morning the form worked for me. Thank you.