Bloomberg Terminal - Go Big or Go Home

Life in Bloomberg was anything but static, no day the same as any other day, but, the focus was always the customer. This customer-centric approach always created trust and good will. In fact, one mantra was "always do the right thing" and that's tough sometimes when the inevitable revenue vs no-revenue conflict occurs. That spirit though, meant that I always invested time ensuring I understood the pain points and remained open-minded about solutions to avoid hammering round pegs into square holes every time.

One such experience was with a small commodity trading firm with half a dozen traders all with Bloomberg Terminals. They knew about the Bloomberg API (BLP API) and wanted to push the value envelope beyond just spreadsheets, so they hired a very bright engineer to start coding an application. The developer started asking us questions about how to do this, and how to do that, but he wouldn't share his vision believing he would be disclosing some IP. Unfortunately, most of the questions had to be answered out of context, and whilst not wrong, they weren't the best for his vision.

Using the Desktop API (DAPI), he had built some functionality (application) for trader #1, then trader #2 said he wanted some of that and more. Trader #3 then got involved. Trader #1 then want his environment updated with the collective value of the others. Well, this cycle just continued until the poor engineer couldn't keep up with the application revisions and spent more time working evenings/weekends to avoid business hours.

After a while I could see there was more pain than value and we got together, with a drains-up approach to understand what the business wanted and what Excel didn't give them that caused them to traverse this route in the first place.

To cut a short story long... the application being developed was honestly just a technical incarnation of the Excel spreadsheet. It still suffered with the same anomalies of;

• Unable to easily add value across the trading desk

• Support was still significant

• Technical limitations playing interference

Ultimately, the plan was to take this application, break it apart and essentially create an application with a client/server paradigm.

In the previous article "Bloomberg - The future's bright, the future's orange" I 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, almost any programming language) and build yourself an application. Whilst I spoke about three challenges, there’s always more lurking around the corner. The list right now could look like this

• Bloomberg Terminal Licensing

• Bloomberg Terminal Limits

• Application Longevity (24/5)

• Application Distribution

Before we discuss these, I wanted to introduce a new concept… Server API. It’s an additional service (yes, there will be additional fees) but it opens up the door to a new and bigger world of capability. The Server API is a server-based API gateway. To be more precise, it’s a Delivery Point for offering up the Bloomberg API (BLP API). Previously, we discussed the Desktop API (DAPI) and now we have the Server API (SAPI).

DAPI

SessionOptions sessionOptions = new SessionOptions ();

sessionOptions.setServerHost ("localhost"); // default value

sessionOptions.setServerPort (8194); // default value

Session session = new Session (sessionOptions);

if (!session.start ()) {

System.out.println ("Could not start session.");

System.exit (1);

}

SAPI

SessionOptions sessionOptions = new SessionOptions ();

sessionOptions.setServerHost ("61.45.1.8"); // server

sessionOptions.setServerPort (8194); // default value

Session session = new Session (sessionOptions);

if (!session.start ()) {

          System.out.println ("Could not start session.");

          System.exit (1);

}

What’s the difference ? In terms of API, they are identical, truly identical in; behaviour, API calls, API responses, fields, … everything. What’s different is the Delivery Point. With DAPI, the Delivery Point is located on the device that the Bloomberg Terminal runs. When you write code, or configure the Excel Addin, you’ll set it such that the Delivery Point is …. ‘localhost' (ie, on the same PC as your application). When we consider SAPI, the Delivery Point, is, well, somewhere else. For simplicity, let’s say the Market Data team have installed it on a server in the data centre, and they gave it a network (IP) address of; 61.45.1.8. That’s where the delivery point is.

We could… alter our Excel Addin configuration, or the Python application we wrote and change the ‘localhost' to that network address and in an instance we’ve moved into the realms of ‘servers’. What’s even more fascinating is that Excel and Python application will just run. This leverages a mode inside of SAPI called “User Mode” (vs “Server Mode”), effectively behaving like a DAPI Delivery Point but in a server configuration. Let’s talk about that ‘list’

Bloomberg Terminal Licensing

It’s a contentious subject, but you’ve paid your dues and you have to live with it. The fee for the Bloomberg Terminal and all the sources/exchanges you can access, entitle you to only view the data on your device… no storage, no distribution, no systematic workflow, no client workflow, no .. . That’s the business intent of the licensing. Yes, there’s a little bit of wiggle room, but at a high level that’s how it stands. Happy to work in those confines, great!

Bloomberg Terminal Limits

So, imagine that you have your Bloomberg Terminal and now, you want to pull all the history for every index member across all the exchanges and while you’re at it, why not get all 64,000 fields, and then you want the analytics extracted, and then… well, at some point imaginary alarm bells will start ringing at Bloomberg Central alerting someone to the demands you’re placing on the backend. Remember that the Bloomberg Terminal is a window/view on to an extensive set of functionality and data that all lives somewhere else (largely NYC). The general ethos is that all Bloomberg Terminal customers should play fair and consider the wider ecosystem (if you’re not the altruistic one, consider the impact to your company). To help encourage behaviour, Bloomberg has the concept of “limits”, where different functionality has a nominal load/weight associated with it, and the sum of those weights should not exceed the daily limit. You’re going to ask... what are the limits?, what are the weights? To be fair, they are not published, and if they were they would only be gamed, and, they’re constantly evolving and being tuned. If you’ve never experienced limits or had that phone call, all is good. If you have, then this article and SAPI is for you.

Application Longevity (24/5)

So, you’ve got the winning Excel Workbook with the timely buy and sell signals being generated, and maybe a Python application, both connected to your Bloomberg Terminal and DAPI (localhost), but then .. you go to lunch (login into your mobile Bloomberg), or logout and go home for the evening, or, it’s the weekend (but you’re trading FX). There’s just a whole raft of annoying instances when.. your analysis gets disconnected from the data. In reality, there’s little you can do with the Excel Workbook to protect against this situation. If you connect it to either DAPI or SAPI (in User Mode), when you logout, the authentication ‘token’ is going to expire and you as a Bloomberg User will (temporarily) cease to exist. However, for your Python application, which is currently designed as a ‘client’ application, there is hope and needs to be refactored (rewritten) and split into two parts. The client portion that you use when you are logged in, and the server portion which runs elsewhere and connects to the SAPI (in Server Mode). This is client/server architecture. In this mode, the server portion is not reliant on the Bloomberg Terminal, or you as a user being logged in, it can autonomously run 24/7 collecting and absorbing data. When you log back in, and run the Python application, it has a conversation with the server component. This conversation establishes who you are (authentication) and what you have access to (authorisation) and then delivers your content/analysis as though you had never stepped away.

Application Distribution

Back to the anecdotal story...

Imagine, as the business analyst/IT you've commissioned a client-based (not client/server) Python application that you’ve distributed to five/ten/more people in the Front Office. Day 2, someone has requested a change. You’d have to reinstall the application at all those users. Then, another change to the application requires that a new dependency/library is installed at all the application users. There’s opportunity here for this to get seriously impractical. The resolution to this challenge is a client/server approach. Previously, when speaking about Application Longevity (24/5) we spoke about splitting an application in two (the client and the server). However, another well-known pattern for this is a browser (client) coupled with a back-end (web) server. That way, all the functionality, value and dependencies can be built into the server and the browser merely presents the results. You’ll still need to authorise and authenticate but those methods are well understood.

Summary

I've spoken about some of the key challenges that face us when directly connecting to the Bloomberg Terminal for content. The above represents what could probably be best summed up as technology solutions to technology problems. Additionally, what about the cost? Yes, there’s a fee for the SAPI capability, but for that you get your limits raised and shared with a workgroup of like-minded individuals/business/roles. Efficiencies increase when the users leveraging SAPI are looking at the same range of asset classes/tickers. You can get a SAPI configured with a universe of 5,000 or 10,000 tickers. Additionally, from a user perspective there are no further fees (especially in the context of listed tickers). Your SAPI will have to pay for user fees across the spectrum of sources and venues, so it will look like an additional user, albeit a very powerful user/robot working in client/server architecture. Remember also, the SAPI API and the DAPI API are the known and trusted Bloomberg API (BLP API). SAPI is just DAPI on steroids!

In summary, SAPI is an enormous help in driving business agility by allowing you to create and deliver more value to the front office. It creates operational efficiencies with how you can deliver that value to the business, meaning less time spent on the technology and more time generating the revenue and returns. Above all, it’s going to help drive return on the investment made in your Bloomberg Terminal population.

In the next article I’ll talk about a solution where;

• you’re looking to address the limitations of SAPI (<10,000 tickers)

• you want non-Bloomberg Terminal users to benefit

• you want to create non-display applications

and as a sneak preview that means the big one… B-PIPE, and yes, still using the same API, the BLP API, meaning you can still leverage your Bloomberg Terminal investment. It will however, be moving from the realms of the Bloomberg Terminal to an Enterprise world. 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 our Bloomberg experts here at Sherpa Consultancy.

What's that? How did the commodity trading get on ? They are running a happy shop with their Python client/server application using SAPI, and the developer is not spending so much time in the evenings and weekends rolling out new functionality...