Bloomberg market data API made public for C++, .Net, Java, Perl(computerworlduk.com)
computerworlduk.com
Bloomberg market data API made public for C++, .Net, Java, Perl
http://www.computerworlduk.com/news/it-business/3334375/bloomberg-market-data-api-made-public/
17 comments
Vendor agreements are only part of it. We actually run one of the largest private networks in the world. There are huge fixed costs with just the physical logistics of the operation. On the data side, I was curious and checked.. The aggregate amount of incoming ticks/messages is upwards of 45 billion a day.
You are right, bloomberg is obviously in a different league. I meant there is an opportunity to offer market data to a different set of clients.
However, that is not to say that the size of bloomberg's infrastructure is the biggest obstacle to competing with it. Today there are technologies (nosql, HDFS, virtual clustures, etc.) which make it reasonable for ambitious engineers to think about competing with sections of bloomberg's business.
Bloomberg does have an immense, non-technical, advantage because traders often love their terminals. From the outside, it looks like an ugly, mainframe age technology with weird commands and ancient looking charts. But boy is it ever useful :) Proficient BB users would make vim users proud.
However, that is not to say that the size of bloomberg's infrastructure is the biggest obstacle to competing with it. Today there are technologies (nosql, HDFS, virtual clustures, etc.) which make it reasonable for ambitious engineers to think about competing with sections of bloomberg's business.
Bloomberg does have an immense, non-technical, advantage because traders often love their terminals. From the outside, it looks like an ugly, mainframe age technology with weird commands and ancient looking charts. But boy is it ever useful :) Proficient BB users would make vim users proud.
I'm honestly curious if 3rd party cloud pricing can allow competition that makes business sense, though. Maybe someone will attempt it..
As for the terminal, it is constantly evolving. Change takes time :) Mess with something that works and you might not like the outcome. Just ask Netflix ;)
As for the terminal, it is constantly evolving. Change takes time :) Mess with something that works and you might not like the outcome. Just ask Netflix ;)
I think it makes sense because someone can start an operation with few clients and limit infrastructure costs. As the number of clients grows, you can improve your infrastructure. By the time you get to thousands of customers, you can switch to bare-metal servers and dramatically improve your bottom line.
In other words, you don't need a big machine, expensive colocation, upfront bandwidth costs, just to serve two clients.
In other words, you don't need a big machine, expensive colocation, upfront bandwidth costs, just to serve two clients.
As for the terminal, it is constantly evolving
That explains why it installs .NET framework, Silverlight, Flash and God knows what else :)
That explains why it installs .NET framework, Silverlight, Flash and God knows what else :)
It's not a big enterprisey mish-mash if that's what you're thinking :) Everything has its place. Flash is used for the animated ipanels just because it is easier for the designers to use. (It also is used for IB video chat because of its easy hookup to the webcams installed on the box.) Silverlight is used for all the TV streaming because the live video streaming is built on top of WM smooth streaming tech. .NET is used as a hosting environment for bits and pieces such as the Bing maps integration. It is also how apps such as our dev IDE are run. I can log into any terminal anywhere in the world and run any of our internal stand-alone apps without admin rights. (And via any browser using BBA to login.)
When I worked in finance, long ago, I ended up having to do an animation of a few seconds of all NASDAQ traffic. It took hours to render...
In the past I've paid like $4 for the EOD prices and $9 for the implied vol calculations per year...the actual pricing is here:
http://www.ivolatility.com/data/data_download_intro.html
Derivatives data is priced much more reasonably & imho arguably more useful (it isn't tickdata or changing by the minute...and in any case, most option trading models are ok with 10-20 cents leeway. You can't buy a single call, you have to buy a minimum of 100, plus the trading fee, and in most cases its simply not that liquid - you will move the market unless you are trading spx etc
Also check out Activetick (no relationship with them) for a few months. It works on all platforms. They even had an example program that made their API accessible via HTTP. I got away just with that.
I compared their data with another feed and they matched.
http://www.activetick.com/activetick/contents/ActiveTickFeed...
I compared their data with another feed and they matched.
http://www.activetick.com/activetick/contents/ActiveTickFeed...
Looks like ActiveTickFeed works on a per-symbol-subscription model. Full market feeds are different because you don't subscribe to specific symbols.
Thanks, I appreciate the clarification.
I had no idea there was a service to stream the entire market to your desktop. my mind is blown.
I had no idea there was a service to stream the entire market to your desktop. my mind is blown.
I'm not convinced that they're actually offering the data for free here. Merely the use of the API is now free (You used to have to actually purchase Bloomberg terminals/hardware to use it). I've emailed both of their contact addresses requesting more information, will edit this as soon as I get a response.
Disclaimer: I work at Bloomberg.
The point of opening up the API is to allow products to be developed around it without any restrictions on shipping our code within the 3rd party application. That basically sums it up.
In order to receive data you need to have a data subscription and we pass through all exchange fees that exchanges charge depending on which particular pieces of data you would like to access. (We serve 350+ exchanges over this API)
Previously, the 3rd party app market was a bit restricted because app developers themselves couldn't necessarily bundle our SDK into their product due to the restrictive licensing and it was a hassle for the ecosystem of devs who write apps in this space. This makes it easier for them to build and ship products.
In order to become a data customer, you can either talk to a terminal with the SDK, or we sell a managed appliance that only serves the data. The SDK can talk to either without configuring it differently. All the rules on distributing the data apply no matter how you get it because the sources of the data (exchanges) are very, very restrictive about specific use cases of their data. The contracts spell out exactly who can place the numbers where and for what purpose. Basically, no matter who you get data from, displaying it publicly anywhere or distributing it as any part of service requires special legal contracts.
The point of opening up the API is to allow products to be developed around it without any restrictions on shipping our code within the 3rd party application. That basically sums it up.
In order to receive data you need to have a data subscription and we pass through all exchange fees that exchanges charge depending on which particular pieces of data you would like to access. (We serve 350+ exchanges over this API)
Previously, the 3rd party app market was a bit restricted because app developers themselves couldn't necessarily bundle our SDK into their product due to the restrictive licensing and it was a hassle for the ecosystem of devs who write apps in this space. This makes it easier for them to build and ship products.
In order to become a data customer, you can either talk to a terminal with the SDK, or we sell a managed appliance that only serves the data. The SDK can talk to either without configuring it differently. All the rules on distributing the data apply no matter how you get it because the sources of the data (exchanges) are very, very restrictive about specific use cases of their data. The contracts spell out exactly who can place the numbers where and for what purpose. Basically, no matter who you get data from, displaying it publicly anywhere or distributing it as any part of service requires special legal contracts.
Thanks apaprocki for the clarification. Dont you think that an additional step would be have a public API directly accessible through internet? In the past customers had to buy dedicated lines for your service, then BLB gave the opportunity to use internet connections, but with desktop software or appliance inhouse. The next step will be giving direct access to api from the internet without other software involved (opening probably in this way more market for new web applications/services integration)
Short answer.. I'm working on it :) I want to see it happen, but obviously can't guarantee it.
Yeah I think in retrospect this comment was sort of silly. We all read this post hoping that they were giving away a real time free financial data API (that would be huge), but really that's how they make money.
They just want to change their model a bit and have everyone able to access it easily by becoming a data API customer. It's probably a good move for them but I don't like the way they and the press covering this aren't mentioning that all it is is access to the same API as before without having to purchase the terminal now. (this is conjecture as I still haven't heard back)
Edit ... their response that confirms it:
They just want to change their model a bit and have everyone able to access it easily by becoming a data API customer. It's probably a good move for them but I don't like the way they and the press covering this aren't mentioning that all it is is access to the same API as before without having to purchase the terminal now. (this is conjecture as I still haven't heard back)
Edit ... their response that confirms it:
Hello Travis,
Thank you for your inquiry.
The Open BLPAPI initiative is meant to present the API as a free-use technology,
but the Bloomberg content and data services from Bloomberg
are still licensed products.
Our goal is to give you the freedom to develop applications using the API,
and once subscribed to a licensed data
service from Bloomberg you would be able to access the content.
Regards,
Bloomberg Open Market Data InitiativeSo, what's the difference between this and the current (previous?) access model where you use their already existing API to interact with their systems?
The only difference seems that they have published the API and you dont need to have a real bloomberg machine in order to build your code around them.. am i wrong?
Before this, even if you paid you still did not get api access. Or any documentation. They act as if it is still an analogue teletext service right down to the ghastly UI. The terms of service forbid you from storing the data. This seems to be some sort of tentative step out of the twentieth century.
afaik (please somebody correct me if i'm wrong) if you pay for a bloomberg workstation you can download API and use it on your system, but you're limited to using it on a licensed workstation (you cant interface another system in order to pull these data) and you cant pass it without elaborating them
so, as example:
NO you cant use a program on the licensed workstation that sucks data and push them to a database that is used to power a website that shows stock prices
NO you cant get the data from that workstation from other computers via API
YES you can create a custom C++ program that runs on your licensed bloomberg workstation that get data via API, elaborate them with your own algo and give you signals for buy/sell (or maybe create a report that you send to your customers)
so, as example:
NO you cant use a program on the licensed workstation that sucks data and push them to a database that is used to power a website that shows stock prices
NO you cant get the data from that workstation from other computers via API
YES you can create a custom C++ program that runs on your licensed bloomberg workstation that get data via API, elaborate them with your own algo and give you signals for buy/sell (or maybe create a report that you send to your customers)
This is basically correct. Anyone with a terminal can program against it and use the "desktop" API (the SDK connecting to the terminal). The same for any customer with just an API appliance.
To extend your example, some customers use it to process realtime data, mix in their own data that they do not want to leave their network, then perform some kind of algo on it, and ultimately use the API SDK to feed the results back to Bloomberg for publishing. The SDK is used by publishers who feed content to us -- it isn't just for receiving data.
To extend your example, some customers use it to process realtime data, mix in their own data that they do not want to leave their network, then perform some kind of algo on it, and ultimately use the API SDK to feed the results back to Bloomberg for publishing. The SDK is used by publishers who feed content to us -- it isn't just for receiving data.
The market data feed and the terminal are two separate products, priced and sold independently.
Bloomberg Professional (aka Terminal): http://www.bloomberg.com/professional/
Enterprise Solutions: http://www.bloomberg.com/enterprise/ http://www.bloomberg.com/enterprise/enterprise_products/data...
The latter obviously provides programmatic access to the real-time data, whereas the former is mostly intended for homo sapiens users.
Bloomberg Professional (aka Terminal): http://www.bloomberg.com/professional/
Enterprise Solutions: http://www.bloomberg.com/enterprise/ http://www.bloomberg.com/enterprise/enterprise_products/data...
The latter obviously provides programmatic access to the real-time data, whereas the former is mostly intended for homo sapiens users.
You never needed a terminal in order to use our API. We sell a managed 2U appliance that either the customer or we can host and it only serves the data feed.
The press release, http://open.bloomberg.com/pdf/bloomberg-open-pr.pdf, clarifies this. There's a footnote at the end.
"Bloomberg is offering its programming interface (BLPAPI) under a free-use agreement. This does not apply to any content."
"Bloomberg is offering its programming interface (BLPAPI) under a free-use agreement. This does not apply to any content."
What am I supposed to do with a free programming interface if I have no access to the data? Maybe they want to "force" other market data providers to define a common standard for this kind of API? Or maybe they hope it will bring more third-party partners interfacing with their systems? I dont understand if they have also "test feed" that you can use to develop without an expensive agreement (afaik a bloomberg machine+service costs around 20k$/year)
EDIT: from one of their docs: "Bloomberg customers, non-Bloomberg users, vendors and third-party application developers can now adopt the interface for their own use." and "Furthermore, Bloomberg is evolving its interfaces into candidates for an open standard. Under this initiative, an independent committee would be formed to manage the future development of BLPAPI, while ensuring its stability and openness" http://open.bloomberg.com/pdf/bbg-eps-open-market-data.pdf
sorry for not reading it before
EDIT: from one of their docs: "Bloomberg customers, non-Bloomberg users, vendors and third-party application developers can now adopt the interface for their own use." and "Furthermore, Bloomberg is evolving its interfaces into candidates for an open standard. Under this initiative, an independent committee would be formed to manage the future development of BLPAPI, while ensuring its stability and openness" http://open.bloomberg.com/pdf/bbg-eps-open-market-data.pdf
sorry for not reading it before
Ok this example probably clarifies the rationale:
"A programming interface that is proprietary severely limits the options for firms that use them. Typically, a proprietary interface is contractually tied to the associated product. If the client decides to stop using the product, any references to the interface must be removed from the client’s applications. Further, the proprietary interface may not be copied and used for any other purpose, even if the firm remains a customer of that vendor for other uses. Together, these restrictions prevent the creation of adapters that could mitigate the costs and risks of migration"
"A programming interface that is proprietary severely limits the options for firms that use them. Typically, a proprietary interface is contractually tied to the associated product. If the client decides to stop using the product, any references to the interface must be removed from the client’s applications. Further, the proprietary interface may not be copied and used for any other purpose, even if the firm remains a customer of that vendor for other uses. Together, these restrictions prevent the creation of adapters that could mitigate the costs and risks of migration"
As a follow-up, first real-world example I've seen so far of this release benefiting the community:
http://www.opengamma.com/blog/2012/02/02/bloomberg-market-da...
http://www.opengamma.com/blog/2012/02/02/bloomberg-market-da...
(Of course) the data won't be free. They don't get it for free--"tape" fees are a major source of exchange revenue.
(Although it's possible some delayed feeds may be available, etc.)
(Although it's possible some delayed feeds may be available, etc.)
> They don't get it for free--"tape" fees are a major source of exchange revenue.
This is the truth. It's pretty outrageous the prices the exchanges charge for real time data.
Though to be fair they are pretty good about letting you pay for what you want.
Most offer: - 15 minute delayed quotes, - real time top of book, - depth of book and the - raw fast data feed with not additions.
Pick what you want.
This is the truth. It's pretty outrageous the prices the exchanges charge for real time data.
Though to be fair they are pretty good about letting you pay for what you want.
Most offer: - 15 minute delayed quotes, - real time top of book, - depth of book and the - raw fast data feed with not additions.
Pick what you want.
Anecdote: I once asked how much it would cost if I enabled myself for realtime access to every exchange we offer and I was given the ballpark figure that it would cost the company $80k/year. Exchanges charge a lot.
Hmm, that seems cheap :)
TSX, NYSE, and NASDAQ are around $5000/month each for full depth of book.
TSX, NYSE, and NASDAQ are around $5000/month each for full depth of book.
I'm guessing that previously Bloomberg either charged or didn't allow 3rd party access to their APIs so that you could develop your own apps on top of the datafeed.
By making it open, it opens up the market for 3rd party tool developers to build apps that can access the Bloomberg feed data.
To those that are complaining, I have a developer subscription to IQFeed, which charges a fee of around $70/month for delayed data, and I pay $300/yr, so Bloomberg offering it for free is pretty good. Too bad their data feed costs ~$1000/month.
By making it open, it opens up the market for 3rd party tool developers to build apps that can access the Bloomberg feed data.
To those that are complaining, I have a developer subscription to IQFeed, which charges a fee of around $70/month for delayed data, and I pay $300/yr, so Bloomberg offering it for free is pretty good. Too bad their data feed costs ~$1000/month.
Does the cost depend on the volume of data accessed or is it just a fixed amount per month?
The cost of what, IQFeed? For IQFeed it's a fixed amount per month. I have no idea on Bloomberg.
There is a monthly cost and also tiered, metered usage. Keep in mind this isn't just for accessing North American exchanges. Our data customers can access all data we have, from the 110+ countries we collect feeds from.
Thanks for the response. Can you give a pointer to the Bloomberg pricing info, to get an idea of the fixed + variable costs?
If anyone wants licensed Bloomberg financial news content, we have that in our News API and can give to you guys at HN rates. Can be used for commercial use. We worked hard to get this agreement done with Bloomberg since we know a lot of finance startup could use this.
What is the cheapest way to get the actual data? A number of years back, opentick had a pretty cheap API for getting market data. However, they have shutdown. Is there anyone out there with a good api, and relatively cheap data feed?
Note that ths is just an API - to use it you still need to be a subscriber, and nothing they offer is cheap. In the tradition of their Excel APIs, this doesn't even come close to giving automated access to their entire database.
This API seems like a marketing tool designed to get people to build algorithmic applications around expensive real time feeds from Bloomberg.
This API seems like a marketing tool designed to get people to build algorithmic applications around expensive real time feeds from Bloomberg.
Is there an example of some data you need which isn't served over the API?
Having worked there, I can see that this is a very powerful move towards solidifying marketshare for then. They were drowning in complexity. Opening the API will allow them to acquire any small innovating startup at a fraction of the cost it would have taken them to develop inhouse.
maybe so, but Bloomberg is the dominant player in most of the markets it operates in. Perhaps with this initiative Bloomberg is looking to embrace new markets as some of their previous cash cows continue to struggle as debt markets can't seem to put 2008 behind them. Empirasign is a market data company whose focus is transaction prices for OTC MBS transactions. We currently license our market data to Bloomberg for internal use. Our raw data is a series of email messages, and the output is basically one big table whose key index is the Blomberg Ticker--which thanks to Open Symbology (bysm.bloomber.com) is license free. One new market that comes to mind for Bloomberg is online ad rates. If I were starting a new finance start-up today, I'd focus on gathering transaction prices for online ads, organize them into some form that made sense to finance types, and publish this data to Bloomberg via their API. Now you have two take-out bids: One in the tech space, and the other in the finance arena. Anyone interested in this, message us: [email protected].
This is great for small finance startups where previously the costs were astronomical.
I'm certainly going to look at incorporating this in to livelystocks.com which could benefit from some realtime finance data.
I was initially very excited but once you read the details it's the spec and implementation of the API for a realtime market data messaging system that is public and MIT licenced (unlike Bloomberg's competitors) not any actual data sources.
Presumably even if you want to test a new client implementation, you would need to have an account with Bloomberg (the magazine article mentions "beta" markets but I'm guessing that doesn't mean in finance what it means to developers).
Presumably even if you want to test a new client implementation, you would need to have an account with Bloomberg (the magazine article mentions "beta" markets but I'm guessing that doesn't mean in finance what it means to developers).
THere are alot of restrictions on what you can do with financial data in general.
Typically it's tiered pricing model so it's:
- at one rate for viewing internally at your company,
- another rate if it's used for automated trading purposes
-another, open your wallet and dump it out price if you want to redistribute the data to external viewers, ie put it up on a website.
Typically it's tiered pricing model so it's:
- at one rate for viewing internally at your company,
- another rate if it's used for automated trading purposes
-another, open your wallet and dump it out price if you want to redistribute the data to external viewers, ie put it up on a website.
I haven't looked at the license yet, but I suspect it may have certain restrictions with regards to providing the data to others without becoming a paying customer.
My experience with using anything Reuters or Bloomberg is that you do not want their code anywhere near a critical system. It's poorly designed, poorly documented, low on features, hard to integrate, and incredibly expensive. Moving data from one place to another is a solved problem. But not if you are using RMDS. Then it's just a problem.
I can't speak for Reuters, but I have worked with two generations of Bloomberg data. One was a trading backfeed over TCP/IP that was pretty complicated to implement. For example, whenever my side crashed or exited, I had to call the NY contact to restart his server end. That was a pretty tricky, but once up it was quite steady. And it was attached to a very critical trading system.
The second was a very rich set of all manner of indicative data--a superset of what you would imagine is behind the Terminal itself. This seemed to me to be a very cleanly specified and implemented system. And it was quite feature rich.
I am not clear on what relationship this has with their current offering.
The second was a very rich set of all manner of indicative data--a superset of what you would imagine is behind the Terminal itself. This seemed to me to be a very cleanly specified and implemented system. And it was quite feature rich.
I am not clear on what relationship this has with their current offering.
The first one sounds like some kind of custom FIX feed. That would be unrelated. The latter is essentially what was released today. The request/response mode is used for the indicative/historical retrieval and subscriptions are used for the realtime data.
What's your definition of "critical"? Because people have these plumbed into systems trading billions unattended...
Wow this looks pretty awesome. As a student who is interested in relating programming to finance, this definitely looks like it takes care of some barriers that were previously in place. I'm extremely excited to look into this.
Then why not just learn with Interactive Brokers API, you get access to their TWS test system API which is great for learning purposes.
Thanks, I'll give that a look as well.
Any way of using the api's in 'test' mode? Maybe have the methods return dummy / delayed data ? Or maybe have one instrument of each type available for free so that people can create mockups and test wrappers ?
Quick replies by Apaprocki is why the internet is so awesome right now.
They do not give away content, from their press release:
"* Bloomberg is offering its programming interface (BLPAPI) under a free-use agreement. This does not apply to any content."
[deleted]
Direct link: http://open.bloomberg.com/
But why make the docs .pdf?!
But why make the docs .pdf?!
This is a massive step for Bloomberg; let's give them a chance to improve over time. One day they might make an appearance on GitHub...
Already working on it.. I wrote a Node.js module for the API which I am most likely putting on there soon :)
Anyone know a service that provides easy access to historical income statements, balance sheet, and cash flow?
S&P Capital IQ -- http://www.capitaliq.com
Depends on your definition of easy I suppose, but they have a superior fundamentals database.
Looks like Capital IQ is already using Hadoop for their infrastructure.
http://strataconf.com/strata2012/public/schedule/detail/2258...
http://strataconf.com/strata2012/public/schedule/detail/2258...
The Bloomberg API provides access to that information. The only "hard" part is paying for the subscription.
This reporter couldn't make the distinction between and open and free?
I'm surprised how many people on HN are interested in this. If you are looking for real-time feeds, the best vendor I've found is http://www.nanex.net/ . They offer the whole feed, real-time, over the internet. Unfortunately you have to access it through their windows based dll. I can't understand why they don't have a native linux client...but they don't.
A very interesting source of data is BATS. I believe you can get free data feeds from BATS. Since they are a very liquid exchange, in many instances their prices can be proxies for the full market. Unfortunately, you need industrial strength bandwidth to access that data (you can't just get it over the internet).
I believe there is space in the market for another market data vendor. Use good compression to drastically reduce bandwidth (see nanex), provide diverse client APIs (NOT nanex), slowly start to aggregate feeds from international exchanges, provide intelligent routing (100 clients in china should not make 100 connections to a NYC data center, they should connect to a local node), offer limited access to no cost exchanges, etc.
Unfortunately vendor agreements for exchanges are expensive enough that they are out of reach for bootstrapped operations.