Date

26 Oct 2020

Attendees

Agenda

1) Use Case reminder

2) Where we are on our road map.

3) Open Action Items

4) JIRA Issues Review - https://jira.edmcouncil.org/projects/SEC/issues/SEC-7?filter=allopenissues

5) Todays content discussion.

SMIF OWL-UML

SKOS

RDF/S

6) For next week.

Proceedings:

Further discussion of corporate actions - both Ian and I think they should be moved to SEC, possibly in their own subdomain area, but banks consider them to be part of securities. The use cases we have that reference corporate actions are with respect to how the value of securities are impacted by corporate actions, and it makes sense to move it and manage them there. Elisa will send a note to Ashwin to get his thoughts from a DB perspective.

Discussed Pete's PriceGroup proposal, which everyone agreed was very data centric. Having a daily summary of prices might be useful, an instantaneous bid/ask might be useful to traders, daily summary might be useful to others. But what Pete did appears to be a structure related to some set of historical prices. This lacks pricing source, for one thing, and pricing source is critical. So at a minimum, a grouping would need the source and methodology - mark to market, etc. The question is really what is the purpose of the price group, and what competency questions are being addressed.

We get the need to reduce some of the overhead with respect to retaining prices historically - so the question is, is this price group in addition to what we already have, as a convenience, that might be ok, but it can't replace the more granular representation that we need for other use cases. We would need to show how this relates to the more detailed use cases. The max and min would be related to the trades executed on a specific exchange during a day, so perhaps a new structure that is exchange-specific, using the listing (as in Pete's example)?

We don't have an obvious standard way of creating a summary of pricing statistics over some period, but do have a PriceAnalytic class that could be augmented as a parallel structure to economic indicators. Pete's use case is specifically for historical pricing, for representing historical performance of an instrument with respect to a specific source. It would be a summary of what happened in a given day of all the historical values - open, close, mid-price, official close, high, low, and possibly adjusted prices for all of the above. A trading day is perhaps the most granular thing, but a summary could be for any period of time.

We should add subclasses of date period for trading day, trading session (morning, afternoon, evening) ... for Pete the most granular thing is a trading day. Futures are pegged to a particular trading session, though. We need trading day and trading session as subclasses of date period as a starting point. The concept of a trading day needs to include the date and time, using xsd date time, rather than the date alone.

Banks need to capture both the actual prices for trades, for example for an executed trade, and it's pricing source, etc. for valuation purposes. Pete's requirement is historical prices for performance analysis and reporting purposes, for a market data provider rather than for an institution, however.

Decisions:

Action items

Browser not supported