Bloomberg Licensing
Why do the majority of procurement and market data teams struggle to understand Bloomberg licensing? There’s probably a couple of reasons:
Bloomberg’s origins as a Desktop (Terminal) company
Most procurement and market data teams with a long time exposure to enterprise data licensing from LSEG/Refinitiv
These two factors have led to a large confusion in the industry understanding Bloomberg’s licensing, how best to use their content and a misperception that the licensing is challenging, mysterious and expensive.
The aim of this Bloomberg licensing blog series will be to help give context to why Bloomberg commercialises its products differently than most of the industry, the origin of the desktop licensing and how that evolved into enterprise data licensing. We’ll also look at how best an organisation can navigate the licensing to “sweat the asset” of Bloomberg solutions.
First, we will cover off market data licensing and where Bloomberg sits between three types of financial market data licensing areas:
Market data originators
Market data distributors
Market data consumers
It is important to understand that Bloomberg is both an originator of unique & derived content as well as a distributor of 3rd party originated content. This places Bloomberg in a position where they want to adhere to the redistribution agreements of the 3rd party originators as well as protect their own proprietary content. Bloomberg has decided to label its proprietary content as “Bloomberg Professional Services” data also referred to as BPS user data. The “Bloomberg Professional Services” is also the legal name of the industry known term “Bloomberg Terminal”. Initially, Bloomberg was willing to begin distributing its proprietary content only to Terminal users. Over time this category of data has become a “catch all” for data Bloomberg is uncomfortable making commoditised and more readily available to enterprise-wide workflows.
So why is BPS user data so important in the industry and why do so many firms fall foul of Bloomberg licensing agreements?
This is where understanding the origins of Bloomberg as a desktop business become very important. In the 1990’s and early 2000’s enterprise-wide data licensing by originators, including Bloomberg, was very broad and flexible. This was primarily due to the fact that most downstream consuming financial applications were still predominantly eye-ball based and it was easy for data originators and distributors to monetize market data based on number of users you had at an organisation. Bloomberg during this time was able to negotiate very exclusive agreements with brokers, banks, and unique data source providers to place their “premium” data sources over the Bloomberg terminal. Prior to some newer financial regulations, it was very common in the industry, for example, that a Bank would have tiered pricing sources available to its customers based on volumes and size of transactions running through the trading desk. This resulted in a scenario where for example a Tier 1 bank’s trading desk would offer a higher quality price to a specific terminal user’s identification (UUID) vs. another user at another firm. This was well known in the industry and was controlled by an “entitlement management” function in the terminal for sell side desks to provide tiered pricing based on relationship levels.
Fast forward to the 2010’s and the premium pricing sources available over the Bloomberg terminal for specific users became highly valuable to firms like hedge funds, multi-strat shops and anyone running semi-automatic or automatic trading algorithms or pricing engines, referred to as grey/black boxes. Without realising it Bloomberg had accidentally created very high-quality pricing sources that were available over the Bloomberg terminal and subsequently the Bloomberg API which was of much higher quality than any contributed pricing sources from the same brokers, banks, premium data providers over its competition.
So why did this occur? Why did other vendors not have access to the same premium data sources?
This was due to the Bloomberg terminal eye-ball login that was very easily locked down and thus easily monetized by both Bloomberg and its data originator partners. When Reuters designed its architecture in the 90’s it was always based around an enterprise-wide distribution which would run through its Platform before hitting downstream user desktops and applications. Due to this architecture framework the data originators were always cautious to enable premium data sources over the distribution architecture (eg, Triarch, RMDS, TREP, RTDS) of Reuters. However, because Bloomberg’s distribution architecture didn’t exist and everything originated from individual Bloomberg terminals, the originators were more confident with Bloomberg’s ability to lock down data to individual eye-balls.
Now we come to the challenges facing organisations today due to these 2 factors around Bloomberg’s desktop origins and the fact it had access to premium data sources over its competition. Post financial crisis, Bloomberg decided it needed to diversify its revenue streams beyond the desktop terminal. At the time the majority of Bloomberg’s revenues were from the terminal and it was prudent as a growing organisation to diversify revenue streams as any large organisation would aim to achieve to avoid becoming another Blackberry or Blockbuster Video.
Thus, began the launch of a new division within Bloomberg, called Enterprise Products and Solutions (EPS), and Bloomberg moved any existing small business units, such as Data License, into a consolidated division that would be responsible for all future revenues based on market data. Over the first few years this division quickly came to realise it would have to license data that matched what was available in the industry across its competitors and would have to segregate the “premium data” sources it had available due to the legacy data originator agreements over the Bloomberg terminal. This began the origins of the Bloomberg licensing agreements referring to “market data” and “BPS data”. Bloomberg needed to adhere to its existing licensing agreements with the data originators and thus created a product called “Entitlement Management & Reporting System” (EMRS), where all data entitlements would be managed for any down-stream consuming applications.
Presently all organisations must use EMRS, similar to the LSEG/Refinitiv DACS, reporting system to provide monthly statements of usage for licensing reconciliation and reporting. The Bloomberg Server API (SAPI) and B-PIPE were the first two enterprise-wide API licenses an organisation could receive that would permit market data and BPS data to be delivered within an organisation's enterprise. The challenge most organisations then began to face was they needed to create entitlement controls within their enterprise in order to distinguish between an enterprise user and a “Bloomberg Professional Services” user (BPS User). This became a huge challenge for clients and the pressure was coming from the front-office because they desperately wanted the premium data sources that only Bloomberg had available.
Expanding this challenge further was the fact that the majority of 3rd party financial software had been originally written to consume market data from LSEG/Refinitiv and also didn’t have the capability to distinguish between an enterprise user and a BPS user. Bloomberg had to hire staff and create a 3rd party team and launch a 3rd party program in order to educate and re-write the authentication schemas of almost every major FinTech software available in the industry. Systems such as Aladdin, Charles River, Eze, Orchestrade, Calypso, TradeWeb, SimCorp, Murex, Misys, Kondor, and many more all had to write in authentication schemas in order to consume BPS User data for Bloomberg terminal users.
Once this hurdle was overcome another new challenge appeared which was the fact that the majority of organisations had accidentally over the years built databases off the back of their OMS and IBOR systems and had connected many smaller downstream reporting, risk, and analytics applications off the back of their daily transaction and order management databases. This resulted in the OMS being compliant with Bloomberg’s BPS User data entitlements but the BPS data accidentally leaking out of the database due to legacy architecture constructed prior to Bloomberg offering enterprise data solutions and the organisation previously using LSEG/Refinitiv data.
Still today the above OMS database scenario persist in the majority of organisations and though many firms implemented Enterprise Data Management systems, the majority of front-office OMS solutions bi-pass the centralised EDM workflows in order to stay timely and give the front-office T+0 access to live pricing data and new issued securities and securities that change due to corporate actions or rolls. These challenges have created the need for market data teams to have an active knowledge of the following areas:
Licensing
IT Architecture
Workflows
Entitlements
Traditionally, market data teams were more heavily specialised in the procurement and licensing side of the above 4 areas and would augment the team with data analysts and business analysts. We at Sherpa have concluded that the new breed of market data teams will need to be proficient in all four areas if you are to successfully manage “sweating the asset” of your Bloomberg solutions and avoiding falling foul of Bloomberg’s unique market data licensing.
Sherpa Consultancy is a team that specialises in all four areas to assist organisations in gaining all the amazing benefits of Bloomberg solutions without the operational risks of being non-compliant and inefficient with Bloomberg’s solutions. Contact us if you wish to learn more about how we can help.
