Table of Contents

Date

15 Jun 2017

Actions items from previous meetings

• Former user (Deleted) develop a proof-of-concept bot to recognize CDS entity references and respond with in-line data about the security.
  • All: contact Former user (Deleted) if you're interested in working on a custom renderer for the CDS data returned by the bot
• Former user (Deleted) will work with Symphony LLC's Product Marketing team to create proposed "marketing" material describing the WG's activity in business-friendly terms.

Agenda

Standing Action Items

• Provide feedback to Former user (Deleted) on experience with MessageML 2.0 & Structured Objects

Action items

• All: Attend the IHS Markit hackathon on June 20th, at Markit's offices: 450 West 33rd Street, New York, NY 

• Aaron Williamson tell Paul & Johan which members are attending the Members Meeting

Meeting notes

Johan Sandersson: FactSet has been in the Foundation from the start and many of our clients are using Symphony or will, and we want to provide integrations for those users, and we’re working closely with the Symphony LLC development team. We’re not requiring things from Symphony for our own sake but our customers’ sake. So what we’d like to hear from the working group is what our clients want. I’m personally very interested in this interworking between companies—every year we talk about identity, but we’ve never decided on a single standard for identifying organizations and users. And the same is true of financial objects, so that’s what I’d like this group to focus on. Paul?

Paul Teyssier: My name is Paul, I run the platform team at Symphony LLC, meaning anything allowing customers and vendors to build things within Symphony. We’re working with several working groups. With the release of 1.46, which has the Structured Objects functionality that supports financial objects, providing an opportunity to agree on standards for representing those.

Johan Sandersson: As Paul said, some capabilities have just been released in 1.46 and I’m wondering if anyone’s worked on that or tried that functionality out?

Paul Teyssier: I’d love to hear candidly from the group whether you’ve used the functionality and what feedback you have so far.

Hershal Shah: Frank has been doing some backend stuff for us. As far as requirements are concerned, we’ve begun looking at a PoC, and I’ll try to get an update, but I know we’ve started playing with the UAT.

Paul Teyssier: I’m hearing about some customers that are starting real projects, especially around RFQ and IOI use cases. I’m advocating for those groups to provide feedback earlier rather than later.

Johan Sandersson: And those are the kinds of use cases we’re focused on as well. Have people described their overall workflows to you?

Paul Teyssier: The historical behavior of this marketplace has been that there’s machine-to-machine on one hand and person-to-person on the other, and some of our customers are trying to migrate their existing machine-to-machine workflows to the Symphony platform rather than trying to change workflows, so I think that’s where most of the focus will be at first.

Johan Sandersson: So our next agenda item was the charter, which specifically says that the WG is intended to facilitate transactions involving at least one human. And I think as you say, since machine-to-machine is a focus of users, maybe we should revise it to allow for those interactions as well.

Bruce Skingle: The reason that’s in there is that the ESCo wanted to discourage people from discussing reinventing FIX and similar technologies.

Johan Sandersson: We can discuss this at the Members Meeting, but I’m not sure it’s a high priority now. The new members, Ipreo and ChartIQ, what are your thoughts on what you’d like to get out of the working group? Did the charter impact your evaluation of the WG.

Sidd Dalal: We basically build visualizations, and we have a lot of issues connecting the different data sources—everyone has their own data representations and storage formats, and it would be really nice to have a standard object to represent financial objects and time series. We don’t care much about machine-to-machine, but we do care about the human side.

Jeff Sternberg: This is Jeff from Ipreo. Our participation is similar in that we’re interested in human-to-human communications mostly. Our users are primarily working on new issuance of equity, etc., and there’s a lot of back-and-forth in those cases. We tend to be highly integrated with our clients and we need to map identifiers, entities, etc. We’re planning to integrate Symphony chat with our products but we’re in the early stages of that planning.

Johan Sandersson: So you’re interested in a standard format for representing entities to make them easier to map between systems.

Jeff Sternberg: Yes, I’d agree with that. Companies, users, people, contacts…

Johan Sandersson: Do you maintain any of that yourself?

Jeff Sternberg: We have a pretty large entity-management team tasked with mapping internal identifiers to our “golden copy,” which itself isn’t as perfect as we’d like it to be, but we spend a lot of energy on that. A universal identification system would be really helpful.

Johan Sandersson: To give you some background, what we have mainly discussed is that the various market data providers should provide as many identifiers in the object as possible, to allow participants to go through it to find the one they want to work with. We haven’t really gone into trying to define one single type of entity to work everywhere, but more trying to provide as much information as possible.

Jeff Sternberg: Does that allow for extensions to internal identifiers?

Johan Sandersson: It does.

Bruce Skingle: The intention is that this WG will define a set of type identifiers and that anyone can specify any kind of type identifier they want to use. In the original XML definition there was an explicit priority for different types of ID. With the current JSON-oriented format, the list of identifiers is implicitly in order of preference.

Johan Sandersson: My personal hope in the future is that, after a while of having this capability, we realize that if we all include a particular identifier, e.g. OpenFIGI, it will make for a smooth transition to a de facto standard. Paul, could you talk a little bit about the LLC roadmap?

Paul Teyssier: Basically there are two or three major items. First, a number of fast-follow capabilities called Structured Objects 1.1, either in the 47 or 48 release. Today you can add contextual action on a cashtag or hashtag, but you can’t do it generically, and this would add that. Second, the ability to compose objects from the UI, which would be via an extension capability with autocomplete functionality, which will probably come in the second half of the year. Third, in the same timeframe, the equivalent of that on mobile – to view and compose objects. That’s the high-level view.

Johan Sandersson: Since you mentioned 47 and 48, what’s your timeframe between releases?

Paul Teyssier: We had a long release cycle for 46 because we wanted to do a significant change of the user experience. Now we’re back to our normal 6-week development cycle. So late July then mid-September.

Johan Sandersson: The other idea I had regarding getting more engagement in the group would be to start a subgroup or smaller team to work on a single interesting object, like a trade, to define what needs to be included there. We’ve had some people on the call that had that type of example, but from what I hear now, people are mostly interested in identifiers. Frank, have you had further thoughts on the CDS example?

Frank Tarsillo: We wanted to start off with something simple, so the red codes are understandable as a field, but moving out from there to pricing data, that gets into generic object formats like pricing and fee liability. And you need to think about how to control access to the content within the objects themselves. How do you know you’re allowed to send that data over to the requester?

Johan Sandersson: Do you think it would make sense to break each of the objects out into a separate page in the wiki to show that they’re objects we’re currently discussing. And we can put in some examples – trade, IOI, RFQ, and start discussing what they should contain?

Frank Tarsillo: Are we getting to the question of a full trading workflow?

Johan Sandersson: I guess that’s one of the reasons people are looking at this. But I’m wary that we’d be moving too fast if we went there now. I would like to try to discuss what is a trade object without necessarily going into the whole workflow.

Frank Tarsillo: I feel like we’re replicating existing standards, which is not bad, but I think the question is, how do we want to model existing protocols in the existing community into what’s necessary across the Symphony network. The bigger question is, are we really going to map out everything all over again onto a new entity definition? We could go and break out all of the objects that are used today. Or we could wrap entity definitions in enough information that they’re usable across the network.

Johan Sandersson: That’s a good point and goes back to the WG charter—what is the main goal of the group? I’m more than happy to scale back and work solely on identities for now, and move into more advanced areas where other protocols exist later.

Frank Tarsillo: One suggestion I’d make is, is it as simple as identifying the protocol you’re transporting in the entity definition? More of a wrapper and identifier of the information within the payload. That’s one way to make Symphony a bridge between the many protocols that are already out there.

Johan Sandersson: I think that was discussed at a recent meeting. But there were some concerns about that, although not any kind of decision. What would other people say?

Jeff Sternberg: I think it makes sense. I haven’t worked with FIX or 20022, but I like wrapping and focusing on how that information gets incorporated into Symphony.

Paul Teyssier: One challenge of wrapping is that it gets more complex at the edges of the network…

Frank Tarsillo: That’s right, but my concern is that we have all of these systems today. And do you tell them to change to a new standard on this network, or do you adapt to what they need so you get more integration with those systems from the start?

Paul Teyssier: I understand the point. And MessageML was designed to support many different types of objects, and it’s a question of where we want to put the complexity. I don’t know if we should have a strong position at this stage. It seems too early to me.

Johan Sandersson: We only have a little time left. I think we have some interesting tracks so we’re lined up for an interesting session at the Members Meeting. I was going to try to reach out to everybody who’s in the working group to check if they’re the right person in their organization to participate in the working group. But I think that for the people on the call, that’s clear. I think in the meeting we should talk about entities, the existing protocols and how to treat them, and can we start working on defining some objects and get some traction on that.

Hershal Shah: We’re holding an informal hackathon the night before the Members Meeting, on June 20^th, at our offices. And we encourage everyone to attend.

Johan Sandersson: Yeah, I’m looking forward to it.

Attendees