Usage is recorded as events and priced later
Table of Contents
1. Summary
The system pays vendors for market data, so it must know which party uses which feed. The service records usage as events. An event holds no price. A rating step applies a rate card later, so a price change or a new contract can be applied to old events.
2. Detail
2.1. The events
| Event | Fields | Recorded when |
|---|---|---|
| Subscription interval | party, provider, source, rights, from, to | A subscription or route opens or closes |
| Demand interval | party, instrument, from, to | An instrument enters or leaves a party's demand |
| Delivery count | party, instrument, period, count | The fan-out delivers ticks (batched) |
| Access record | party, user, provider, period | A person views the data (later) |
2.2. Why events and not amounts
The cost depends on contracts that change. Events are facts. The same events price under today's card, a new card, or a what-if card.
2.3. Where the events come from
Demand intervals and subscription intervals are by-products of control actions, so they cost nothing at tick time. Delivery counts are the only per-tick cost. The loop batches them with the store write.
2.4. Who reads them
A party administrator reads the party's own usage. The system tenant reads all. The usage screen shows usage by provider, instrument and period. See Four areas of the Market data menu cover the service.
2.5. Same for every source
A simulated source produces the same events. The usage of a development party shows what the same use would cost on a live source. See A rate card on the source turns usage into a bill the platform shares.
3. See also
- Market Data Architecture — the structure note that orders this cluster.
- A rate card on the source turns usage into a bill the platform shares — completes: how events become money.
- Demand drives what an adapter publishes — completes: the source of demand intervals.
- A party takes a provider's feeds through a subscription — completes: the source of subscription intervals.