Date

31 Mar 2016

9am PDT, noon EDT, 5pm BST

Attendees

Former user (Deleted)
Doug Esanbrock delegating for Christopher McCullough
David Schachter
Frank Tarsillo
Gabriele Columbro
James Turck
Lawrence Miller
Samuel Krasnik
Johan Forsell
Johan Sandersson

Goals

Approval of the WG charter (see https://symphonyoss.atlassian.net/wiki/display/WGFOS)
Discussion of Use Cases in general and Alice thinks IBM has tested its lows and likely to rally, and wants to refer Bob to its recent price action. in particular
Elaboration of a set of use cases which the organizations represented by WG participants would actually use on "day one".
Agreement of actions.

Discussion items

Time	Item	Who	Notes
5 min	Welcome	Bruce Skingle	I shall endeavor to start the meeting at 5 past the hour, please join the call before then if at all possible.
10 min	Approval of charter	All	Please give this some consideration before the call so that we can have a meaningful conversation given the limited time available.
30 min	Discussion of Use Cases	All	Please read and understand the use case at Alice thinks IBM has tested its lows and likely to rally, and wants to refer Bob to its recent price action. and give some thought to what use cases your organization might actually make use of on "day one".
5 min	AOB	All	Any other business
5 min	Wrap Up	Bruce Skingle	I shall endeavor to close the meeting at 5 to the hour given everyone's hectic schedules.

Minutes

After some discussion and a few alterations the working group charter was approved. The approved version is now shown on the WG Home Page (Working Group - Financial Objects Standardization).

It was agreed that in general the originator of any message containing complex financial objects should provide as many identifiers for the entity being referred to as it has available, and that the originator should indicate the order of preference for these identifiers. For example in the case of a bond, the originator should send an ISIN, a CUSIP and an OpenFIGI identifier for the bond being referred to if it has them. The originator MUST indicate the order of preference of the use of these IDs and SHOULD place the ID it uses internally as the 1st choice.

When displaying a message containing a complex financial object the receiving entity SHOULD use the first identifier it is capable of using in the order of preference supplied by the originator.

This has the effect of providing predictable behavior in the event that a message is sent containing several IDs which refer to different entities.

It was not formally agreed at the meeting, but it seems obvious that "Originators MUST NOT emit complex financial objects which contain conflicting IDs (i.e. which refer to different entities, such as an ISIN for a share traded on one exchange and a CUSIP for the same share traded on a different exchange)".

There was some discussion of an inheritance mechanism and the possibility that an entity could provide multiple levels of detail. For example in the use case Alice thinks IBM has tested its lows and likely to rally, and wants to refer Bob to its recent price action. the embedded financial object could have several levels of detail, e.g.

IBM Corporation
IBM Common Stock, traded on NYSE
The Price of IBM Common Stock, traded on NYSE from 1 Jan 2016 to 31 March 2016
As above, with particular reference to the low point on 27 March 2016

This would allow less sophisticated receivers (the app providing the renderer rather than the human user) to display some useful information at a higher level of abstraction, whereas more capable receivers could render a price chart with annotations highlighting the points the sender wanted to make.

There was discussion of the possibility of allowing for processing of messages after the user presses Return to send the message and before it is sent, in order to parse the typed text and enrich the message with structured data, there were some concerns that this could lead to unpredictable results and unhappy users.

There was discussion about the issue of licensing for certain types of security identifier and Lawrence kindly agreed to speak to someone at S&P about this. One possible approach would be for Symphony to require customers who can send and receive structured objects to enter into a legal agreement that they will only use identifiers for which they have appropriate licenses.

For logistical reasons the next meeting, which would have fallen on April 14th cannot take place on that day and it was agreed to meet instead at the same time on Wednesday 13th April. Amended calendar invitations have been sent out.

Action items

Lawrence Miller (Deactivated) to speak with S&P about licensing issues surrounding use of instrument identifiers

Browser not supported