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 a previous article we took a look at Bloomberg Licensing, whereas in this article we’ll dig a bit deeper. 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 microservice to compliment all its other managed realtime 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 realtime 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 realtime 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
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 need to install/update/support anything.
Here at Sherpa Consultancy we have many years of experience with data, display/non-display patterns, and application design.
