
Market Data as a Service
Sounds kind of cool doesn’t it? We’ve got everything else available as a service, anything from compute, storage, email, databases, software, platforms.. You name it, it’s available as a service, all except.. Market Data. But then, what do we mean by Market Data, certainly it’s not the generic reference to static market data, which is available across the board from various vendors, including aggregators like Bloomberg, Snowflake, SIX, ICE, LSEG, etc but let’s focus on the Real-Time (“I need it now”) access to financial content. Yes, typically this is a reference to streaming, ticking data, but it doesn’t always need to be, but the pattern helps understand the need.

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.

Build scale into the Bloomberg Terminal
In a previous blog article “Increase the value of your Terminal” we explored the fact that not only was there Excel Addin access to some of the value in the Bloomberg Terminal, but that this was underpinned by a Bloomberg API known as BLP API. In the context of the Bloomberg Terminal, it’s known as the Desktop API, DAPI. So, as a user you could explore capability through Excel, or if you wanted to go further you could write some Python (in fact most programming languages) and build yourself an application. Whilst we spoke about three challenges, there’s always more lurking around the corner.

Seamless integration with the Bloomberg terminal
While working with a small OMS/IBOR start-up provider out of the Nordics there was a philosophical discussion with the CEO and founder of the company. The discussion talked about the pros/cons of building functionality, acknowledging that similar capability was already well developed within the Bloomberg terminal. We examined the business opportunity and return on investment for two options; go ahead and build the capability into the OMS/IBOR product, or, integrate with the Bloomberg terminal and leverage the existing functionality. Ultimately, an investment was made in adopting the Bloomberg integration technology, and developing tight integration between the two offerings.

Increase the value of your Terminal
The Bloomberg Terminal.. thousands of functions, across all asset classes, more technical analysis than you know what to do with, a vast wealth of static reference data, artificial intelligence built in, messaging, sentiment analysis on news. It doesn’t get much better .. or does it? As I mentioned in my last article, Bloomberg supplemented the Terminal with a point of integration, a means of programmatically getting at the power of the Terminal. They created what we call the Desktop API (DAPI), or more formally, the Bloomberg API (BLP API).

Nothing up the sleeve
The Bloomberg Professional Services Terminal (aka Bloomberg Terminal) was released in the early 80’s and has been evolving and thriving ever since. Anyone who used the Terminal back in the early days would certainly recognise it in its current modern form. Whilst it’s a Microsoft Windows based application, it has carved out a unique user-experience (UX) that has been popular with more than 325,000 users since inception. It has that very distinctive orange on black branding and has bucked the UI Windows style of menus to access features. This is not out of arrogance but is there to support access to the vastness of value available in the Bloomberg ecosystem, something no menu system could ever accommodate. Instead, it provides a command line interface (CLI) for the ever-growing repertoire of features.