Every product manager who works with market data learns this the same way: by building something useful and discovering late that displaying it to that user, in that form, is not covered by the licence. The feature works. The client wants it. And it cannot ship.
Market data is one of the few areas where a commercial contract behaves like a technical constraint, and it is almost entirely absent from general product writing.
The distinctions that determine what you can build
| Distinction | Why it matters |
|---|---|
| Real-time vs delayed vs end-of-day | Price differs by orders of magnitude; delayed is often free or near-free |
| Display vs non-display | Showing a price to a human and feeding it to an algorithm are separately licensed, and non-display is usually dearer |
| Internal use vs redistribution | Showing data to your own staff is not the same right as showing it to your clients |
| Derived data | A calculation from licensed data may still be licensed, depending on whether the original can be reconstructed |
| Per-user vs enterprise | Drives cost model; per-user counts can make a "just add it to everyone's dashboard" feature ruinous |
The one that catches product teams most often is derived data. Teams assume that once they have computed something — an average, an indicator, a portfolio valuation — it is theirs. Frequently it is not, and the test is roughly whether someone could work backwards to the underlying price.
The question is never "do we have the data?" It is "are we licensed to show this data, in this form, to this person, at this latency?"
Where the cost lands
Per-user licensing turns a design decision into a recurring cost decision. Putting a real-time price on a dashboard every user sees can multiply your data bill by your entire user count — including the users who never look at it.
Design levers that materially change the bill:
- Default to delayed. Most users do not need real-time; the ones who do will tell you.
- Make real-time opt-in per user, so entitlement follows actual need rather than screen layout.
- Do not put live prices in ambient UI. A ticker in a header is the most expensive decoration in financial software.
- Check whether the client is already licensed. Many institutional clients hold their own entitlements and can supply them.
Many agreements require you to report usage — user counts, application inventories, sometimes audits. That is an ongoing product and engineering obligation, not a one-off contract signature, and it needs an owner. Teams that discover this during an audit have a bad quarter.
Work the question early
This belongs in discovery, alongside the other assumption tests. Before designing anything that displays a price, establish four things:
- Source. Which vendor or venue does this come from?
- Right. Display or non-display, internal or redistributable?
- Latency. What are we entitled to, and what does the user genuinely need?
- Cost model. Per user, per query, or flat — and what does that do at scale?
Ten minutes with whoever owns market data agreements at your firm, before the design work, routinely saves a sprint. That person exists, is rarely consulted by product teams, and is usually delighted to be asked in advance rather than presented with a problem.
Firms frequently hold entitlements nobody in product knows about. The opposite is also common — paying for real-time feeds that only ever surface as end-of-day figures. Both are worth an afternoon of investigation, and the second one funds your next feature.
What to tell your team
Engineers will reasonably assume that if the data is in the system, it can be shown. Make the constraint visible rather than relying on it being remembered:
- Note the entitlement on the backlog item, next to the acceptance criteria.
- Encode the rule in the system where you can — entitlement checks belong in code, not in a wiki.
- Treat "which licence covers this?" as a standard refinement question for anything price-related.
It is the same discipline as the compliance work in product management when compliance has a veto: the constraint is not an obstacle to route around, it is a design input you gather early or discover expensively.