The Big Time with Bloomberg

Previously, we spoke about the possibilities of supplementing the Bloomberg Terminal with added value. This was achieved through applications and Excel leveraging the Bloomberg API (BLP API). Although we considered just a Bloomberg Terminal with the Desktop API, and, looked at a Client/Server approach through Server API (SAPI), essentially, it’s still all the Bloomberg Terminal. If you’ve explored these options in your organisation, it’s about as far as you can take the Bloomberg Terminal ecosystem in supporting applications.

Additionally, we spoke about the licensing, which gives you the right to eyeball the data. This is because Bloomberg is considered the Vendor of Record. Bloomberg pays the exchange bills, Bloomberg assumes the responsibility for collecting and distributing the data, Bloomberg assumes the liability that you’ll do the right thing with the data. If you’re a Bloomberg customer with Bloomberg Terminals you may or may not be aware of the oversight/surveillance that takes place in terms of use of the data from Bloomberg Terminal. Ultimately, if an exchange has an issue with how its data is being used from the Bloomberg Terminal, it will have to be Bloomberg that explains. So, where do we go from here and break out of the constraints of the Bloomberg Terminal? Here’s some facets of providing data and value that you’re looking to explore, where the Bloomberg Terminal ecosystem is holding you back.

• Require that non-Bloomberg Terminal users see data, added-value, applications

• Need to entertain a universe of tickers/instruments greater than 10,000

• Build applications that derive and distribute to an in-house audience

• Build applications that make systematic trading decisions (blackbox)

If you have any of the above challenges, then you need to consider a different approach. This different approach requires that you take on a new paradigm and this is a datafeed. Datafeeds represent the digital delivery of financial data. As you can imagine, taking a datafeed of digital data comes with some responsibilities; who’s seeing the data, who or what is deriving value from the data, who or what has paid for the data, etc. We’ll cover the responsibilities later, but for now, let’s look at the solution to the list of challenges, Bloomberg’s B-PIPE.

Bloomberg’s B-PIPE is an enterprise offering, that essentially provides one or more Delivery Point(s) that surfaces up the Bloomberg API (BLP API). So yes, we had DAPI, SAPI as discussed in previous articles, and now the B-PIPE API, but, they are all the same API, the BLP API! It’s the same library/extension to your applications, it’s the same calls, the same data, same behaviour. Bloomberg’s B-PIPE provides a very comprehensive set of capabilities and features that we’ll look at deeper in another blog article. For now, what about those challenges?

Non-Bloomberg Terminal users

It often comes as a surprise that you have the ability to deliver data from Bloomberg’s B-PIPE to 'Terminal’ users that are not Bloomberg Terminal users. This might apply to users who take another vendor’s ‘Terminal’ or perhaps they have no ‘Terminal’ at all, eg Middle/Back-Office, and they just want access to data through a spreadsheet, in-house or 3rd Party application. We spoke about 3rd Party applications and how they leverage Bloomberg data in our “Seamless integration with the Bloomberg terminal” article. Bloomberg Terminal users do carry favour when accessing B-PIPE, so if your user is not a Bloomberg Terminal user, the lack of favour means there’s a seat/user fee. However, it is a cost effective way of accessing Bloomberg data via B-PIPE.

Tickers/Instruments universe that exceeds 10,000

If you’re a hedge fund looking at a large universe of instruments, or perhaps focused on derivatives, or your global holdings/portfolio exceeds that order of magnitude, the Bloomberg Terminal (DAPI/SAPI) options will not keep you happy. Bloomberg’s B-PIPE can handle a universe up to a million, and in fact has gone beyond that in some circumstances. Not only can it service large numbers of instruments, but it’s truly elastic in that one month/year you might be at one level, and the next you open in new markets, onboard your client base, and double your usage. B-PIPE aligns with business, no minimum commitments.

Derive and Distribute

Up until now, the only type of application we’ve discussed is one that takes raw data and displays it, whether that’s through the Bloomberg Terminal, Excel, an in-house or 3rd Party application. However, it might be that you want to create your own intellectual property (IP) from the data. One unrealistic example is that you want to create the MID price from the raw BID and ASK. There’s lots of urban myths/rules about what makes a derived value. Some will say non-reverse engineerable, ie, one could never take a MID and calculate the BID and ASK. Adding a spread to BID and ASK is somewhat questionable, in that if you understand the spread, you’d be able to determine the originating/raw data. However, some exchanges ask for more than the reverse engineering constraint. That said, the basic spirit is that you don’t distribute raw values to individuals that have not paid their (access) fees. 

It’s interesting to note that most of these rules originate from exchanges/venues, where instruments are listed. It is these entities that are likely to audit your usage, constrain your usage, bill for usage, etc. On the other hand, Over The Counter (OTC) sources have few strict rules, although Bloomberg will still press/enforce similar principles.

To finish off derivation, distributing your intellectual property (IP) requires no controls in place. You’re free to distribute internally, externally, store in a database, publish to the internet, etc. However, be warned that whilst derivation may be black and white in terms of how/what Bloomberg fees you attract, the exchanges/venues will not be so black and white. They will want to understand how much value you are extracting, and, to whom or what the value is being delivered. Enter the next challenge.

Systematic Trading/Blackbox

This is one step on from the derivation as now we are derivating a trading signal, and not only creating the signal, but acting on it systematically. On one hand, you’re not distributing your intellectual property, but nominally improving your bottom line (revenue) with an exchange’s data. The exchange will be very interested in your use and you will have to declare exactly what your stated purpose is. 

Summary

Over a few articles we’ve discussed using Bloomberg data into applications. We’ve covered the spectrum from displaying to Bloomberg Terminal users all the way through to blackbox trading with an algo application. The beauty of the Bloomberg solutions is the single API, the BLP API. Making an investment in that API means that your organisation can write applications that accommodate most if not all use cases associated with market data. Not only is there an ROI from the API, but remember we mentioned that the B-PIPE offering has elastic billing, flexing with your usage. This helps deliver true business agility.

In the next article, we’ll look at the various options available in terms of how a B-PIPE is delivered, with articles to follow on the capabilities available through a B-PIPE that goes beyond market data. If you can’t wait, want to discuss something in this article, need some help discussing application architecture, or how to get the most out of your Bloomberg ecosystem, don’t hesitate to get in touch with us here at Sherpa Consultancy.