A rate card on the source turns usage into a bill the platform shares
Table of Contents
1. Summary
The platform owns the vendor contracts. It pays each vendor and shares the cost with the parties that use the data. A rate card on each source describes how the vendor charges. Rating applies the card to a period's usage events and gives the source bill. Allocation splits that bill among the parties. A simulated source has a simulated rate card, so its parties see a shadow bill that approximates the real one.
2. Detail
Figure 1: From usage events to a bill for each party.
Source: market_data_cost_flow.puml. Regenerate with
plantuml -tpng doc/knowledge/architecture/market_data_cost_flow.puml.
2.1. How vendors charge
Vendors charge on several axes together.
| Axis | Meaning | Evidence |
|---|---|---|
| Platform or connection | A fixed fee for the enterprise feed | Bloomberg B-PIPE and Server API are quoted apart from terminal seats |
| Display, per user | A fee for each person who views data | Bloomberg Trading Facility market data policy |
| Non-display | A fee for a system that uses data without display | Same policy |
| Derived data | A licence to compute from the data, priced for each legal entity | Bloomberg data fees disclosure |
| Instrument or request volume | A fee for each entitled instrument or request | General practice |
| Redistribution | A fee to pass data to another legal entity | General practice |
Bloomberg publishes no price list. We found no public LSEG fee schedule. Contract terms are the input for a real card.
2.2. The rate card
A rate card belongs to a source. It lists charge components. Each component has a driver and a rate.
| Driver | Charged for |
|---|---|
fixed_per_period |
The connection or platform, whatever the use |
per_instrument |
Each distinct instrument in demand in the period |
per_party |
Each subscribed party |
per_licence |
Each right held: non_display, derived |
per_thousand_ticks |
Delivered ticks |
per_display_user |
Each person with display access (later) |
A simulated source carries a card with illustrative rates, or published rates where they exist. The model is the same.
2.3. Rating
Rating reads the usage events of one period for a source and applies its card. The result is the source bill: the cost the platform bears for the source.
2.4. Allocation
Allocation splits the source bill among parties, by the driver of each component.
per_instrument: among the parties that demanded the instrument.per_partyandper_licence: to the party that holds it.per_thousand_ticks: by delivery count.fixed_per_period: no party driver exists. The default policy splits it equally among the active subscribers of the period. The policy is replaceable.
A composite has no card. Its demand counts as demand on its input providers, so their components allocate its cost. See A composite attributes its use to the providers of its inputs.
2.5. Real bill and shadow bill
The system pays the bill of a live source. The bill of a simulated source is a
shadow bill. It has the same lines and the same allocation. Nobody pays it. The
card is the only part that differs, and it is data. See
No code path may behave differently because a source is simulated.
2.6. One simplification
A real vendor could treat each party as a separate licensee. The first release assumes one payer, the platform, that shares the cost. A change to the contract holder changes who owns the card and not the model.
3. See also
- Market Data Architecture — the structure note that orders this cluster.
- Usage is recorded as events and priced later — completes: the events that rating reads.
- Display, non-display and derived rights are modelled on the subscription — completes: the rights that some components charge for.
- A live and a simulated source differ only inside the adapter — exemplifies: the rate card is a difference that remains.