Display, non-display and derived rights are modelled on the subscription
Table of Contents
1. Summary
Vendors license data by the use made of it. The system models three rights on
each subscription: display, non_display and derived. A right decides what a
party may do and what the party costs. The system models them now, so a later
real vendor contract fits without a change of model.
2. Detail
2.1. The rights
| Right | Meaning | Example |
|---|---|---|
display |
A person looks at the data on a screen | A trader's blotter |
non_display |
A system uses the data without display | A pricing or risk engine |
derived |
A party computes a new value from the data | A blended spot, a curve |
These follow the way vendors price access. A vendor licence for derived data covers internal use only and is priced for each legal entity. See A rate card on the source turns usage into a bill the platform shares for the sources.
2.2. Where the rights are checked
- A demand checks that the subscription holds the right that the use needs. A
pricing engine needs
non_display. - A composite needs
derivedon the subscription of every input provider. See A composite attributes its use to the providers of its inputs. - A screen read needs
display.
2.3. What the rights drive
Each right is a driver of a charge component in a rate card. See A rate card on the source turns usage into a bill the platform shares.
2.4. What is not modelled yet
Redistribution to another legal entity, and a limit on the number of display users, are not modelled. A later change adds them as new rights or new limits.
3. See also
- Market Data Architecture — the structure note that orders this cluster.
- A party takes a provider's feeds through a subscription — completes: the row that carries the rights.
- A composite attributes its use to the providers of its inputs — completes: the main user of the derived right.
- A rate card on the source turns usage into a bill the platform shares — completes: how a right becomes a charge.