Entitlement as a Service

Entitlement is one of those words that gives us all the heebie-jeebies and represents a huge complexity for any organisation to get their head around. In fact, to just consider entitlement in isolation would be wrong. There are those identities (exchanges, brokers) who create and own content who offer the content at a fee dependent on what license you want to comply with. However, not many of us can afford the effort to go directly to these content vendors so we go to market data aggregators who assimilate/collate all these sources of content and make it available over a Terminal or DataFeed. However, these aggregators also have their own licenses they layer on top, and their own fees (which pay for the ingestion, distribution, normalisation, storage, enrichment, etc).

So, we have sources of content, distributors of that content, and licenses that need to be obeyed. We can do this through entitlement/enforcement systems, such as DACS and DART, but for this article I'm going to focus on Bloomberg's Entitlement, Management and Reporting System (EMRS).

How did all this start, where it’s going and can we remove the complexity?

In the beginning

Up until the late 80’s, most market data was presented on screens (terminals) by vendors such as Bloomberg and Reuters. Only those vendors had the engineering capacity to support feeds and the pace of change that went alongside connecting to venues. They also connected to multiple venues, so then had to start normalising the data from the venues. At this point they became known as ‘aggregators’ for the role they play. Today, these two vendors individually cover all the listed venues (exchanges, MTFs, OTFs), markets, OTC, cross-asset, broker-dealers, and, even crypto exchanges. The number of sources extends into the thousands and each of these sources mostly want to monetise and control its stream of data. For a list of all the listed markets see ISO10383 which describes the Market Identifier Codes (MICs).

Vendor of Record

Imagine though, that the aggregators have ingested the data and they are now free to distribute to their customers. At this point, the concept of where the bucks stops in terms of who is responsible for paying the exchange bill, is known as the Vendor of Record. For Bloomberg and its Terminal product, Bloomberg collects fees from the customer for the Terminal and all the exchanges they have enabled, but ultimately, Bloomberg is responsible for paying the bill to the exchanges. The Bloomberg user has no need for entering in to a commercial arrangement with the exchange. Bloomberg reports and Bloomberg bills on behalf of its users. In a previous article we spoke about how Bloomberg Terminals can extend their capabilities by adopting Server API (SAPI). This offering also falls under the same; Bloomberg reports and Bloomberg bills.

Go Big or Go Home

As a financial organisation, if you wanted to distribute market data beyond the bounds of Terminal users, then you need to consider going … Enterprise, with something like Bloomberg’s B-PIPE. Sign up to the offering and all of a sudden you have a big pipe ready to firehose all the worlds’ exchanges into your organisation. It’s an exciting thought, apart from one small thing.. you become the Vendor of Record and carry the responsibility.

Show me the money

The exchanges monetise based on a combination of quality and derived value. So, if you’re taking a delayed stream then the quality is deemed lesser than if it was realtime. If you’re processing a delayed stream you probably only have a passing interest in the market data, or maybe invest end of day or intra-day. As soon as you move to real-time, do you want to display (eye-ball) it, do you want to feed it into a blackbox, do you want to produce some derived rights and distribute throughout your enterprise ? There are many permutations, but they essentially categorise as;

• realtime vs delayed
• display vs non-display

Non-display is by far the most expensive as it likely generates the most value for any organisation. Invariably, non-display use cases are a complex field, and you’re likely to have to have a conversation with the exchange to validate and have your use-case categorised. To give you a flavour of the possible variations, look at the CME’s non-display policy. Most of us have lived and breathed this paradigm for many years. However, as exchanges look for new revenue streams, some of them are starting to innovate on their creativity with defined usage. One example of this is Deutsche Borse’s device counting for non-display trading activities.

To you, To me

Previously, I spoke about the who reports and who bills. Some exchanges will offload one or both to the vendor/aggregator (eg, Bloomberg). In many cases, as a Bloomberg customer you may find that Bloomberg bills you, and reports for you. You pay Bloomberg and they pay the exchanges. With the world of non-display, it’s more likely that you’ll have to report and you’ll have to pay the bill (direct to exchange).

Entitlement Systems

Reporting, is a process of honesty. Every month, you need to report about who or what could have used the data. This is about the opportunity cost, not the usage cost. But how do you know who or what could have used the data? Enter the entitlement system, the means to do “the right thing”. If the data is streaming through a large pipe into your organisation, then there’s nothing technically stopping sending that data to every user and application in the organisation. However, your license agreement with the exchanges would frown on that. So, you need a method of policing (and auditing) that will help your organisation do “the right thing”. Entitlement systems contain a database of users and applications mapped to exchanges (and other sources). Your applications need to consult the database to ascertain whether this user or application has the rights to consume the data. The market data system may also assist and guide you by rejection access to data by consulting this database.

All Entitlement and Reporting systems (essentially the database), are deployed and on-premise. That means you have to be able to consult the permissioning matrix wherever your data is being consumed. That could mean on-premise, in a remote office, in the public cloud, multiple countries, etc. Then, do you have one instance, many instances, federated instances ? Is the entitlement implicit (you push at the door and see if you have access), or explicit (ask for permission)? As well as an administrative interface is there an API?

There is one unique vendor though, Bloomberg’s Entitlement and Management Reporting System (EMRS) is deployed as a (micro)service to compliment all its other managed real-time services. In a way it’s a Platform as a Service (PaaS). As such you have an administrative web interface, and, you have an API to interrogate the database. All real-time offerings (streaming market data, retrieving history, etc) are available as a microservice. The entitlement system is no different. It has the name of “apiauth” and is available through the standard BLP API. It provides real-time read-only access to the entitlement database allowing you to do “the right thing”. If you wanted to go one step further and perform some integration with other systems you can also leverage a management REST API whereupon you add/remove users, applications, entitlements, etc. The best thing though, wherever your applications reside, you’ll have access to a holistic Entitlement system.

In Summary

Entitlement is a huge subject with many anomalies and cost implications. Get it wrong and you could be subject to audits and possibly fines. This article hasn’t touched on many other facets of entitlement, including;

• the art of “derived data”
• redistribution
• storing and retrieving at a later point
• netting
• Multiple Instances Single Use (MISU)

Bloomberg’s EMRS helps keep your market data application real-estate in-line with your agreements. It’s already deployed as Entitlement as a Service (PaaS) so no need to install/update/support anything.

Here at Sherpa Consultancy LTD we have many years of experience with data, display/non-display patterns, licensing and application design.?Reach out if you think we can help with your next project.