Table of Contents

Date

Sep 7, 2017

Actions items from previous meetings

Agenda

Action items

Meeting notes

Johan Sandersson: When voting to move an object from working drafts to standards, should we have one person/one vote, or should we have one vote per organization?

Bruce Skingle: I think we should have simple majority of participants since we have such low attendance.

Paul Teyssier: I would slightly prefer to overemphasize people who actually participate and actually have projects.

Lawrence Miller: I think we should aim for consensus and not rely on the decision-making process to resolve conflict.

Johan Sandersson: I like that. I guess the potential risk is we don’t get to a decision without a cutoff time for taking a vote.

Lawrence Miller: My comment is that if someone objects to something, we should discuss that, and if everyone’s operating in good faith we should be able to resolve that.

Bruce Skingle: I agree, and see no evidence that we’ll find ourselves in a position where we can’t reach consensus.

Johan Sandersson: I’m all for making decisions in this meeting, but we also have a long list of members who do not regularly attend meetings, so I’m keen to put out an email so that people have notice and time to discuss the object before the call.

So in general, the preference of the group is that we send an email to the group according to the recorded voting process, and take a simple majority of respondents?

Hershal Shah: And we might also consider removing inactive people from the rolls.

Bruce Skingle: I don’t see a reason for that. If someone who doesn’t attend meetings votes no, we’ll invite them to the next meeting to explain themselves and we’ll all be better off.

Hershal Shah: Yes, I agree.

Johan Sandersson: How long should we keep the vote open?

Peter Monks: The proposed process says three days to keep things fresh in peoples’ minds.

Paul Teyssier: I think that’s too short. I think we should start with two weeks.

Johan Sandersson: Ok, I agree, let’s make that the decision. Hershal, any feedback?

Hershal Shah:

Johan Sandersson: And Jeff, moving to the Contact objects, we’ve moved it into the working drafts section…

Jeff Sternberg: I see the page but the actual object structure isn’t there yet.

Johan Sandersson: That’s right, I just created a page, and I think as we work through the draft we should keep it lightly specified…

Jeff Sternberg: Makes sense.

Johan Sandersson: Any other smaller matters or should we jump into the currency object? Ok. Through our conversations, we realized that we do need a currency object

Bruce Skingle: So Johan raised the question about consistency, and I realized that the example I put up previously is not technically valid. An object needs a type, version, and ID, and I didn’t have that. I think what we landed on before is that the ISO standard is the right way to identify currencies. We also discussed that there are other currency IDs commonly used that are not defined by the ISO standard. So the conclusion I came to is that if we have an attribute declared to be ISO 4217, we should not include any values not defined by that standard. So I propose we create a second ID type where we define a set of values that are needed but not defined by ISO 4217. I’m confident we don’t know anyone deeply knowledgeable about currency trading on this call, but it seems obvious that we need a way to talk about those different things, and splitting it in this way gives us a way to do that with precision and fin.ccy.currency lets us wrap those in an object.

Johan Sandersson: Is the issue you mentioned before about the previous object definition being invalid just that it doesn’t conform to a written schema, or that the system won’t accept or process it?

Bruce Skingle: There’s no validation.

Johan Sandersson: I think the first step is to get someone to use this object. If they do it wrong we can address that at the time, but I’d rather encourage adoption rather than enforce hard controls at this stage.

Paul Teyssier:

Johan Sandersson: Does that make sense to everyone? It’s not just about getting the EntityJSON to your backend, it’s also going to be used to display information in Symphony in a hovercard, either directly by Symphony or via a call to another app.

Hershal Shah: That’s clear and that’s my understanding of structured objects generally in Symphony.

Paul Teyssier: Yes, exactly.

Johan Sandersson: My last question for Bruce is, if we are to define another object, like the CDS or RFQ, that references a currency, should you refer to a main currency entity, or can you refer to a currency attribute in that other object or standard?

Bruce Skingle: Since the entity only contains a set of IDs, there’s no reason to refer to the entity. Either construct would be valid, but I’d be include to just refer to the attribute.

Hershal Shah: I’m going to review this with some SMEs from our currency trading group to confirm that it conforms to their expectations.

Paul Teyssier: That’s great.

Johan Sandersson: Should we include a field for human-readable names of currencies?

Bruce Skingle: There’s no point in maintaining a table of the names of these currencies because they’re defined by the standard itself. So anyone using currency codes already has that lookup. We’re just creating reconciliation problems by providing a mapping.

Paul Teyssier: Yeah, but getting to the EntityJSON is a lot easier than parsing it and doing a lookup. Based on my conversations with partners and customers, this might come up as a desired feature.

Johan Sandersson: Ok, so I propose we initiate the 2-week vote on the currency object standard tomorrow, and if needed restart the clock to incorporate information from subject matter experts into the standard.

Paul Teyssier: I’d also love to get contacts done.

Johan Sandersson: Yes, and Dov from MS expressed a lot of interest in this.

Jeff Sternberg: Great! I’m going to include a bunch of open questions in the working drafts page – where should I put those?

Bruce Skingle: I’d make it a subpage.

Jeff Sternberg: Ok, great.

Attendees