Table of Contents

Date

17 Aug 2017

Actions items from previous meetings

Former user (Deleted): move com.symphony definitions into "proposed standards" or "working drafts" section as appropriate.
Johan Sandersson: move security and currency definitions to "working drafts"

Agenda

Time	Item	Notes
5 min	Convene & roll call
10 min	Review action items from previous meetings	See above



5 min	AOB & adjourn

Action items

Johan Sandersson: review the Decision Making Mechanism and propose voting procedure to WG via mailing list.
Johan Sandersson: initiate vote to approve org.symphonyoss.fin.ccy.id.iso4217 [A] as a standard object.
Former user (Deleted): work internally in IHSM to add CDS object(s) to working drafts and move the CDS Use Cases toward standardization.
Jeff Sternberg (Deactivated): move contact object from Sharing Contacts use case to working drafts to begin standardization process.

Meeting notes

Johan Sandersson: Paul moved com.symphony into Working Drafts?

Paul Teyssier: Yes, Bruce and I are iterating a bit more

Bruce Skingle: I think the Standards section should only include org.symphony.oss things that we agree on in this group. I don’t think the other entities’ stuff should be in there, but once the owner decides they’re published, they should be marked as such in a separate section, called “Published.” Meaning they’re final and released but defined by someone else.

Johan Sandersson: Ok.

Hershal Shah: Can we please call it “Published Standard” for consistency in naming?

Bruce Skingle: I think that would be confusing since we already have Standards. How about “Existing Standards?”

Hershal Shah: Doesn’t the namespace accomplish that?

Bruce Skingle: Yes, I would be fine with leaving them there.

Johan Sandersson: Ok, we’re done with this action. I moved “security & currency” to “Working Drafts” to signal that we want to get that into Standards as soon as possible. I think it makes sense to think of Security as a separate entity.

Bruce Skingle: I think this entity should just be moved to currency.id – I think everyone uses the ISO three-letter ID and I see no reason to support anything else.

Hershal Shah: I think cryptocurrency IDs are in line with this expectation. Not sure it’s defined as part of ISO, but I can look that up.

Johan Sandersson: How do we want to present this?

Bruce Skingle: I don’t know why anyone would want to see more than the three-letter code.

Hershal Shah: To date there’s not a representation from a tokenized perspective but I can see people wanting to do more with it, but I think the 3-character representation should suffice.

Paul Teyssier: There’s the question of what’s in the standard or not – the human-readable version is sort of a denormalized view. If USD resolves to “$” or “US Dollar,” it doesn’t become a different object. I would err on the side of uniqueness in the standard.

Hershal Shah: When I think of platform interoperability, the standard should be USD, and the presentation should be up to the platform.

Bruce Skingle: Maybe for the sake of consistency we should change this to fin.ccy.iso.4217.

Hershal Shah: Effectively adopting that as the standard?

Bruce Skingle: Yes.

Johan Sandersson: I agree with that.

Paul Teyssier: How should we vote on this?

Bruce Skingle: I think what we do in other working groups is send an email and give people two meetings to respond.

Hershal Shah: I think what we’re trying to do is define the process for approvals.

AW: I agree, Hershal, since this group hasn’t voted in the past it hasn’t had to define its process for that.

Peter Monks: There is a recommended process documented on the wiki. The API WG uses that model with some minor modifications. So it would be worth looking at that to consider whether it’s appropriate here. And it covers questions of quorum, etc. We’ll send out a link to everyone.

Hershal Shah: I also wanted to say that the vote-bot incorporates the email workflow, so I’d suggest looking at that.

Paul Teyssier: What about submitting one standard for proposal and approval, and making sure we have a process for that. I would suggest, in the interest of time, that Johan make a proposal in the next week or so.

Johan Sandersson: I’m interested in using the vote-bot. What would that take?

Hershal Shah: Forking it, loading it with user data, maintaining it.

Peter Monks: I think that’s a great idea, but right now it’s an ESCo bot and will require some modification to work more generally.

Hershal Shah: That’s fair. I think it’s worth doing the work.

Bruce Skingle: Let’s do that and get it established as a generic process for working groups.

Paul Teyssier: I agree, but I also want to move forward quickly, so let’s fall back to email if Vote Bot isn’t ready in the next couple of weeks.

Bruce Skingle: I think we should just send out an email to everyone in the WG laying out the existing process and using simple majority of respondents. I’ll update the page and move it into Proposed Standards.

Hershal Shah: The adoption of these into Symphony itself – does that make its way into a development cycle, or…

Bruce Skingle: It’s up to anyone who’s using it to implement it.

Johan Sandersson: So Hershal if we’re going to work on something together, there should be no discussion of how we’re going to send currency, it will just be as in the standard.

I also created an entity for you guys at Markit to try to push it from a use case into a standard. I don’t know if you’re ready to use this page to write down an example of how to use the CDS object that you’re producing…

Hershal Shah: I would say yes, we’d like to document an example and demonstrate how in fact it’s used in the real world. I’ve recently just caught up with our product owner for the RED database, and there’s capacity to discuss this both from a standards and industry use case perspective. I’ll have to look into timing.

Johan Sandersson: Absolutely. And I’ve done the same for Ipreo and their contact object, to move it from a use case into defining a contact object. And this is not a fin but an obj piece. Is anyone from Ipreo online? They’ve started a little further in defining an object and I didn’t want to move that, so I’ll email Jeff separately.

My last piece on this is that I’m trying to get work going to define the RFQ object. I know Tick42 was interested in this, so I’m going to talk to them. It raises some questions where I could use your technical input/thoughts. An RFQ to some extent is just referencing other financial objects. So it could have its own ID, which would probably be a vendor-specific one. But to present it nicely in Symphony, it could also have references to securities, currencies, etc. This might touch on what Frank discussed with the CDS object. If we want to reference other EntityJSON objects within an EntityJSON object, how do we do that? Just reference it, or bundle them…?

Hershal Shah: Embedding objects within objects I think will be commonplace against many of the standards we define. We’ll have to do that.

Johan Sandersson: Absolutely, even with a pair trade that contains two different securities would need to do this.

Hershal Shah: Right, and I could define a bespoke product that’s not standard at all but is a tradeable object. I don’t know if you can distill an RFQ down into a standard without defining every asset class, etc.

Paul Teyssier: I’d suggest we do, but with an indirection layer in the middle that for the time being, the less commonplace portions are not standardized or maybe never will be.

Johan Sandersson: My question is mostly about how to refer to an object within another objects. If my RFQ includes other objects, like an instrument, should I embed it or refer to a separate EntityJSON object.

Bruce Skingle: There’s no way to do that. Unless the thing you’re referencing exists elsewhere and has its own ID, you have to embed it. There’s no way to refer from one EntityJSON object from another one. I’m a little concerned with Symphony becoming a database – you really want to identify objects by IDs as much as possible.

Hershal Shah: I’ve struggled with this in trying to think about how to define an RFQ, because it will vary drastically based on asset class.

Bruce Skingle: So maybe you just define not a generic RFQ but one for a specific asset class. So the namespace would look like org.symphonyoss.fin.rfq.[asset class].

Johan Sandersson: Ok. Those are the items I wanted to talk about.

Bruce Skingle: On the currency page, the ID is obviously not an entity, so it needs to be wrapped in something, so I just created a “com.example” to put it in. But here’s an example of how the currency identifier would be used.

Johan Sandersson: Should currency ID not be its own object? If I wanted to send someone a link to a currency, how would I do that?

Bruce Skingle: Maybe I made this more complicated than necessary. There, I’ve revised the page. Are we happy with that?

All: yes.

Attendees

Name	Organisation	Present?
Johan Sandersson (co-chair)	FactSet	Y
Paul Teyssier (co-chair)	Symphony Communications Services LLC	Y
Hammad Akbar	Citi
Afsheen Afshar	JP Morgan Chase
Matthew Bastian	S&P Capital IQ
Hamish Brookerman	S&P Global Market Intelligence
Brett Campbell	Citi	Y
Anjana Dasu	Symphony LLC
Prashant Desai	Ipreo
Doug Esanbock	Dow Jones
Anthony Fabbricino	BNY Mellon
Matthew Gardner	Blackrock
Michael Harmon	Symphony LLC
Dave Hunter	S&P Global
Richard Kleter	Deutsche Bank
Nick Kolba	OpenFin
Samuel Krasnik	Goldman Sachs
Former user (Deleted)	Deutsche Bank
Former user (Deleted)	BNY Mellon
Former user (Deleted)	S&P Capital IQ
Former user (Deleted)	Dow Jones
Jiten Mehta	Capital
Lawrence Miller (Deactivated)	Symphony LLC	Y
Former user (Deleted)	Credit Suisse
Linus Petren	Symphony LLC
Scott Preiss	S&P Capital IQ
Former user (Deleted)	FactSet
Former user (Deleted)	IHS Markit	Y
Former user (Deleted)	Symphony LLC	Y
Jeff Sternberg	Ipreo
Former user (Deleted)	TradeWeb
Kevin Swanson	CUSIP
Former user (Deleted)	Markit
Former user (Deleted)	Credit Suisse
Gavin White	Tradition
Former user (Deleted)	HSBC
Former user (Deleted)	Symphony Software Foundation
Peter Monks	Symphony Software Foundation	Y
Aaron Williamson	Symphony Software Foundation	Y