Table of Contents

Date

29 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

Action items

• Jeff Sternberg (Deactivated): select an object (e.g. org.symphonyoss.obj.contact) to work on defining within Ipreo and notify the mailing list
• Johan Sandersson: update list of financial objects to into separate namespaces (e.g. fin, obj, idn)
• Aaron WilliamsonAaron Williamson: reach out to BNY Mellon to line up presentation from API developer working with ISO 20022

Meeting notes

Johan Sandersson: What is citi looking for re: FOS?

Hammad Akbar: We’ve rolled out Symphony, so we want to make sure we’re consistent with our approach so that when we’re communicating with other users we’re getting the most value.

Johan Sandersson: Some action items from the previous meetings. Hershal, any update on Frank’s actions?

Hershal Shah: The last milestone we were looking to achieve was to replace the on-prem keys to support MessageML v2. Now we need to continue building out the PoC for accessing CDS reference data using key pairs.

Johan Sandersson: Has any other org reached out to you about participating?

Hershal Shah: I don’t know, but I’ll follow up with Frank.

Johan Sandersson: Paul, you were going to work with your product marketing team about the FOS WG’s work.

Paul Teyssier: This is happening, we’ve had multiple working sessions. I can’t share anything yet, but we’re trying to articulate the vision of building an end-to-end workflow that’s FinServ specific. And we’re trying to flesh that out and make it as visual as possible.

Johan Sandersson: Ok, good. Is there any particular item that anyone wants to add to the agenda?

Ok, so I was looking into the existing pages. Bruce added a lot, and some others have contributed. I just felt that it’s a bit difficult to understand what financial objects are, what MessageML is, and what the structure is by which we’re sending FOs via symphony. I think it would be good to separate MessageML v2 as a way of sending objects from defining objects to be sent via MessageML v2, which is what we’re doing in this group. There’s no technical connection between MessageML and the objects we’re defining. We can define the object, and if we want to send that over Symphony that can be translated into MessageML v2.

Paul Teyssier: What would be the alternative?

Johan Sandersson: Just that we would be defining objects functionally before describing it in the MessageML format.

Paul Teyssier: At the end of the day, JSON is very simple and loosely-typed as a format, so there’s not much difference in my view between doing the work in JSON and in some other format. So my feeling is that we should start with JSON.

Johan Sandersson: I just think that sometimes we get hung up in the technical implementation, but if the EntityJSON is easy enough to work with in the same way, I don’t have any objections. What do you think Hershal?

Hershal Shah: Per-instrument, whether it be the entity or the pairing (with the obligation), there’s a series of data points that should be considered and extended depending on the use case. If I’m looking at a pair, there are X number of parameters, whereas if I’m looking at an obligation, I’m looking at Y parameters which is a subset of X. Doing the work of defining that will hopefully help flesh out the EntityJSON. Does that answer the question?

Johan Sandersson: Are you helped by working in a MessageML v2 format? If we come up with a MessageML v3 format, would it be helpful to have the object defined in a higher-level way to translate to v3.

Hershal Shah: I’d hope that we won’t have to redo much as we evolve. What we’ve done so far, defining the EntityJSON, we hope we’re standardizing the object so that it is useful for passing these objects back and forth.

Johan Sandersson: The idea is to foster a rich collaboration and set of objects to work on, I was thinking of separating the object descriptions from the EntityJSON definition.

Jeff Sternberg: I feel like the pages that we have on the WG site, I really like how the PresentationML and the EntityJSON work together, so you get a lot of context. You can imagine the EntityJSON broken out, but it’s very descriptive in the examples we have. I think keeping them baked in is really useful. Maybe more context about “why would I share this kind of information with someone else” would address your point.

Paul Teyssier: A complementary approach, in your orgs, what are the projects you’re currently considering, so we can work together on particular examples? That way we can get to a particular standard for a particular object. What do you think?

Jeff Sternberg: I’m actively trying to figure that out for Ipreo.

Hershal Shah: In focus for us is that use case, but we’ll happily consider participating in others.

Paul Teyssier: Jeff, do you know what use cases you’re considering?

Jeff Sternberg: We’re looking at integrating Symphony chat into our product, so an internal Ipreo analyst with someone on our platform. And the information we’re sharing is similar to what FactSet is taking about, but more issuer oriented.

Paul Teyssier: Like graph objects? Or more abstracted?

Jeff Sternberg: Lists of securities, links to other stuff in Ipreo, that kind of thing. Also contact information, CRM stuff.

Paul Teyssier: I think it would be good to cover one or two examples that subgroups could focus on, like a contact record.

Johan Sandersson: Should we jump straight on to that? Or should I make it an action item?

So, what I was thinking, Jeff, is that if you wanted to take on working on a financial object, put in an item here – a contact or a list – and just as we had with Markit’s CDS (I just made up a type here), but just a suggested type structure, the basic usage, your name, and a link to the page where you define it more. Then going forward, we’ll go through these objects, and when we’re happy with it, we change the status to approved.

Jeff Sternberg: I’d probably start with list, but I’ll have to see.

Johan Sandersson: Would that be a list of contacts, or…?

Jeff Sternberg: Actually, yeah, maybe I’ll start with a contact so I can make a list of things.

Paul Teyssier: Please speak up on the mailing list when you get started.

Jeff Sternberg: Cool, will do.

Johan Sandersson: I think we agree that the first thing we need to do is figure out the identifier. These are references to functionality or data that already exist. And my take is that’s separate from the FOs we’re trying to define. I think a good, typical example is CDS. If I have the entity or pair clip ID and access to a market data set, I can use that to find the information I want.

Hershal Shah: Right, in hierarchical fashion, represented as a data object in Symphony that will hopefully be consumed elsewhere.

Johan Sandersson: But if I don’t have access, the entity CLIP is meaningless.

Hershal Shah: Well, you can look up a freemium set of data. But not the portion our customers pay for.

Johan Sandersson: Yes, but if I’m just sent the CLIP, I need access to some database, even a free one.

Hershal Shah: True. One consider warranting access to a set of publicly available data points, like the issuer name, which you wouldn’t need to put behind a paywall. And that would still be materially valuable.

Johan Sandersson: And that could be solved by turning the end object into a CDS object. If you choose to send a CDS object over Symphony, it contains some of those data that you choose to make available. And I can see right in the PresentationML some of that information being rendered, as well as a link to the exact CLIP ID, so I can send that to my market data tool.

Hershal Shah: But I would say this applies to all reference data.

Johan Sandersson: Yes, that’s right. (…)

Paul Teyssier: That makes a lot of sense to me. One point on namespacing: org.symphonyoss is kind of set, then for everything finance related, fin. There’s some distinction here between fin and obj, where obj is a financial object. But the identifier is something an object can have one or more of. The pattern we’ve had is to have an ID array when there’s more than one ID. And each corresponds to a particular taxonomy. So I don’t know if I would separate the financial object namespace identifier from fin. I would use “id” to specify identifier functionality. Make sense?

Johan Sandersson: Yes, I think some of these are a little complex. I wasn’t really consciously trying to make that distinction, but just trying to differentiate a little.

Paul Teyssier: I think the spirit is not to put these in a separate namespace but just to put it one level deeper. I know some strings will become very long, but they’ll mostly be dealt with by machines so it doesn’t really matter.

Johan Sandersson: Do we want to try to standardize (…)

Paul Teyssier: I would go with separating them. There’s the other question of whether contact is part of a larger CRM space that should be available to a broader group? I think it’s on the bubble, but I would create a separate namespace for objects that aren’t strictly financial.

Jeff Sternberg: We’re working on some of the same namespacing issues. I kind of like obj, but for things like “Trade” or “Swap,” maybe those should be in fin.

Hershal Shah: I would anchor all of these as objects, so maybe leave fin instead of obj, and idn instead of fin. Then maybe we’d create CRM for contacts and the like.

Aaron Williamson: Where would something like “list” go, that might contain objects from different namespaces?

Paul Teyssier: I think there are archetypal data objects like that that come straight from the intrinsic data structure of JSON, so I’d consider addressing those when we come to them.

Johan Sandersson: I think that ties back in with what I was saying before, is that if we look to closely at this, we might miss some basic use cases, like “I want to make a list of these different types of objects” but I don’t know which namespace to put them in, so I just don’t put anything in the wiki.

Jeff Sternberg: Don’t let the namespaces get in the way of documenting.

Johan Sandersson: Exactly. So we’re getting short of time. One part of the charter is that we shouldn’t reinvent existing standards, but it would be interesting to see how other standards address these same things. We also hear anecdotally that firms are sending financial objects via Symphony using informal semi-structured syntax, like “$cashtag #urgent”. Does anyone have someone at their firms working on other standards like ISO or FIX who might want to come present their experience here?

Aaron Williamson: I spoke to a developer at BNY Mellon who designed their APIs by reference to ISO 20022. He said he’d be willing to come present. Is that of interest?

Johan Sandersson: I think so. Anyone else?

Paul Teyssier: Yes.

Attendees