Market Data Entitlement Software: How a Trading Firm Proves Who Actually Consumed Which Feed

The audit is the reason this system exists

An exchange sends a notice that it will review your usage for the past several years. What it wants is not a list of your subscriptions. It wants proof of who consumed the data, on what device, in what capacity, and whether each of those consumptions was declared correctly month by month. The difference between display and non display use, between a person reading a screen and an algorithm reading a price, is where the money is, and the money is retroactive.

Most firms discover at that moment that their entitlement picture is a composite. Terminal counts come from the vendor administration tool. Feed handler permissioning comes from a data access control system. Internal application usage comes from a developer who remembers building a price cache in 2019 that four other systems now read from. The monthly declaration was compiled by a market data analyst who left last year, from a spreadsheet that carries forward last month's numbers with a few manual edits.

That composite is not a control failure by anyone in particular. It is what happens when the system of record for a large recurring cost is a set of exports from other people's systems. The audit simply forces you to look at it.

Why generic software licence tools do not work here

Software asset management assumes a licence attaches to a user or a machine and stays there. Market data does not behave that way. One user may be entitled to a level of depth on one venue and only top of book on another. A single physical server may carry an entitlement that is counted per application rather than per device. A price that arrives from one exchange, is transformed by your own model and shown to a client, may become derived data with its own rules and its own fee. A subscription cancelled today may still bill for three months because the contract has a notice period, and that notice period is not in any inventory system you own.

Then there is the unit of count itself. Exchanges do not agree on what they are counting. Some count users, some count devices, some count applications, some count per instance of a non display process, and some count the same population twice under different products. A tool designed around seats will misreport all of them, and the misreport is silent until it becomes a back charge.

Where TRG Screen and MDSL stop

Both are real products doing real work, and a firm without any inventory discipline will get value from either quickly. They hold contracts, subscriptions, cost lines and invoice reconciliation, and they know the shape of the market data problem in a way a general procurement tool never will. If your requirement is a central inventory with invoice checking and a recharge report, that is on the shelf and you should buy it.

The gap opens at instrumentation. A packaged inventory knows what you told it. It does not know that a particular internal service read the Level 2 book 40,000 times last month, or that a risk engine restarts nightly and each instance counts, or that a client facing calculator has been quietly redistributing a vendor field into a portal for two years. Those facts live in your own applications, your own entitlement middleware, your own identity directory and your own logs. Nobody can sell you a connector for a system you wrote. That is what pushes serious firms into a build, usually alongside a packaged inventory rather than instead of it.

What a custom build has to include

A single entitlement model that can express user based, device based, application based and non display counting at the same time, because your estate contains all four and a model that only expresses one will corrupt every declaration downstream.

Automated collection from the places truth actually lives. The vendor administration exports for terminals. The data access control system for permissioned feed users. Your identity directory for joiners, movers and leavers, so a trader who moved desks last quarter is not still counted against the old cost centre. Your own application inventory and service registry for internal consumers. Where an internal service consumes prices, the build should record consumption at the point of use rather than infer it from a deployment diagram.

A declaration engine that produces each exchange's monthly return in the format that exchange wants, from the same underlying counts, with the reconciliation between the raw population and the declared number preserved. That reconciliation is the artefact that makes an audit survivable. You are not trying to prove you were right. You are trying to show your working.

Contract and notice period tracking with an alerting calendar. The cheapest saving in market data is cancelling something nobody uses before the notice window closes. A build that tells you in July that a September renewal needs a July notice pays for a meaningful slice of itself in the first year.

Usage evidence with a retention policy that matches the audit look back. If exchanges can review several years, your evidence has to survive several years, which is a storage and immutability decision made at design time rather than a feature added later.

Cost allocation to desks by your own rules. Direct attribution where a subscription belongs to a named user, and a defensible allocation basis where it does not. The output is a recharge file the finance system can post and a desk level report the head of the desk cannot dismiss as arbitrary, which is the actual political requirement.

What it costs and how long it takes

A first release covering the entitlement model, automated collection from your two or three largest sources, contract and notice tracking, and a first set of exchange declarations runs $85,000 to $170,000 and ships in 12 to 18 weeks. A full platform adding non display instrumentation inside internal applications, derived data tracking, full invoice reconciliation against vendor billing files, desk recharge posting and multi year evidence retention runs $230,000 to $520,000 phased across 6 to 12 months.

Cost drivers specific to this domain: the number of distinct exchanges you declare to, because each declaration format and policy interpretation is separate work. The number of internal applications that consume prices, since each needs instrumentation and each has a different owner to negotiate with. Whether you have any usable identity data, because firms without clean joiner and leaver feeds spend weeks on data quality before anything else works. And whether legal and compliance want the evidence store to be write once, which changes the storage design.

What keeps cost down: start with your single largest exchange bill and your single largest vendor. Getting one exchange declaration produced automatically end to end teaches the whole model, and the second one takes a fraction of the time.

When to buy instead

Buy if your estate is small enough that a market data manager can hold it in their head. Fewer than roughly 150 subscriptions, one or two vendors, no internal redistribution, no derived data products, no non display declarations beyond the obvious. In that world a packaged inventory plus a disciplined monthly review is proportionate, and a custom build would be an expensive way to reproduce a spreadsheet.

Build when any of the following is true. You have been audited and could not evidence your declarations. Your non display usage is a judgement call rather than a measurement. Desk heads dispute their recharge and you cannot defend the basis. Or you have internal applications distributing exchange data to clients and nobody has mapped which fields those are.

How to choose a developer for market data entitlement software

Ask them to explain the difference between display and non display use before you explain it to them. If they cannot, they will build a subscription tracker and you will still be exposed on the expensive half of the problem.

Ask how they would instrument an internal service that consumes prices. The good answer involves recording consumption events at the point of use with an application identifier and an entitlement reference, and being honest that this requires cooperation from the teams who own those services. The bad answer is a spreadsheet of applications maintained by hand.

Ask what they will do about the evidence store. You want an append only record with a retention period set against the longest audit look back you can be subject to, and you want to hear that requirement raised by them rather than by you.

Ask how declarations are versioned. When a policy interpretation changes, last month's numbers do not retroactively change, but the reasoning does, and both states have to be reproducible. A developer who has done this will already be thinking about immutable monthly snapshots.

Ask who owns the code and settle it before kickoff. You should hold the repository, the infrastructure accounts and the right to engage any other firm. At Digital Heroes the client owns the code from the first commit, which for a system that holds audit evidence is not a preference but a control requirement.