Table of Contents

Date

10 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

Action items

N/A

Meeting notes

Johan Sandersson: Want to focus on financial objects (identifier) and currency, so I’m going to move them into working drafts so we can kick them off. Right now we have this org.symphony with things under it. Do people think the best thing to do is break the ones we’re working on out from the tree, then put them back in as they become standardized?

Bruce Skingle: You mean just putting them into working drafts but just under the same namespace?

Johan Sandersson: Yes.

Paul Teyssier: Yes, I think that makes sense and we should do it.

Johan Sandersson: Ok. The next item is our special guest, Matt Howell at T. Rowe Price. He’s going to talk about how his team is working in Symphony and how we can work together and add more structure and automation.

Matt Howell: As background, I am in London on the XT trading desk. We’ve been using Symphony for the best part of 18 months, a year for some traders. Growth has taken off internally recently and we’ve been doing a lot of cross-pod work with brokers to sort out how to use hashtags and cashtags, and what the taxonomy is. We have a basic one and know our peers do too, and that they’re not exactly the same. We have a couple cross pod chatrooms with 6 or 7 brokers using it to some extent. They’re porting across the content they’d typically send on legacy platforms, but now they’re tagging the content. And were telling our salespeople that the tagging makes the content much more valuable to us.

We use the tagging as a curation tool internally. We can create comingled signals around topics we really care about. So here’s a keyword signal and I’ve got content feeding into that signal that I can share with analysts. We’re using this to cut down the noise in our channel. On legacy platforms, it’s up to us to read every piece of content that comes through. That’s where we see the value in a dynamic feed based on the XT holdings in our portfolio, that we can share with traders and portfolio managers, etc., making our curation effort much more automated.

We’ve also got portfolio managers engaging with the platform. At the moment, that’s a very manual curation process but we’re starting to use tags more consistently. So here, there’s a stock that’s moved 2% so we send you a tagged message and you can reload it and we can process it into our workflow. That’s the dynamic conversation going backward and forward between portfolio managers and traders all around the world. This workflow would have historically be conducted over email and would take much longer. As people have got more comfortable, we’ve see the speed go up as well.

Johan Sandersson: So I see “Mark” sending some numbers here. What do you do when you see that information? Do you look it up elsewhere?

Matt Howell: First they’ll go to their market data platform and pull up that name, then look at their portfolio and see how it’s effected. Some PMs use technical signals around some names, RSI indicators e.g. to help them select names to trim or add to. So they’ll go to disparate platforms based on what they see here.

Then we start thinking about what comes next. There are lots of use cases, but I’m coming from a PM & external interaction POV. We’re seeing more users come into the platform, and we’re looking at making Symphony an enterprise-wide solution. We also see buy-side firms looking at using Symphony and we’ve been actively engaged with them. The sell side is increasingly reaching out to us to see what value we can provide to them. On both sides we see potential integrations – sell side: IOI, analytics, market data, etc. We’re going to be looking at using bots for different things. We have a prototype bot that takes an ax from a trading platform, looks for a match on our system, and if there’s one will notify the relevant trader. Also automating the picking up of orders mentioned in chat rather than having them manually copy it over. Then there’s further functionality coming from Symphony – screen-clipping has been really popular here, and screen-sharing is on the road to doing the same thing. So we’re looking forward to the additional functionality.

Questions?

Frank Tarsillo: You described your use of IOIs or RFQs across the network. How are you looking at that.

Matt Howell: I think at Markit where there are a number of separate IOI solutions, I see Symphony as the perfect place for the integration of those signals. E.g. in fixed income you could aggregate axes from different solutions, compare them to an internal list, and create targeted alerts. And maybe traders and PMs could wishlist items they’re particularly interested in. I think as we see this grow, you’d want to let a trader highlight an opportunity in a chat and do an IOI.

Frank Tarsillo: Would you want them to be able to initiate a trade?

Matt Howell: Our workflow doesn’t really support that, but I can see it happening down the line.

Johan Sandersson: You spoke of taxonomy from multiple providers. How much of an issue has that been? Does it seem to be a real issue or just an initial training issue?

Matt Howell: I think we’re sufficiently advanced in x-pod communications that we’ve been able to set those protocols, but it’s not scalable. As the number of users and integrations go up, it’s going to become more and more of an issue. As that snowballs, it will be hard to pack it back in and reorganize it. So the opportunity to solve for that now is something I often emphasize to Symphony. Right now it’s not a massive challenge for us, but going forward I can only see trouble.

Paul Teyssier: Matt, you said there are places you see the workflow being improved by a more precise taxonomy. Which would make the most difference?

Matt Howell: I think if I’m honest as I look at what’s driving adoption, I think automation around the order flow and integration with our systems internally, providing PMs with a one-stop shop for position data, market data, etc. Our PMs and analysts still like some manual curation of their feeds, because a common name will bring in too much data. So what will bring them in is data that they’d otherwise have to search for outside the platform.

Johan Sandersson: How much do you go back in history? So a signal for xyz corp. – do you look back a week? More or less?

Matt Howell: I’d say max a week, but I sit on the trading side so our attention span is short. An analyst might want to see much more, particularly as they’re just getting familiar with a company.

Johan Sandersson: As long as a year? Longer?

Matt Howell: I’ve never really thought about it, mainly because our retention requirements make us keep it longer than that anyway, but I can’t imagine needing to go back more than a year.

Our focus is growing adoption within the investment process. I don’t think the external offering for brokers is ready for prime time, as it basically represents existing solutions with tagging added. But I’m talking to one now who’d like to send us a fat pipe of the data they’re using internally, all tagged. And that’s where I see it going in the future.

Johan Sandersson: And tagged both by hashtags but also company identifiers?

Matt Howell: Yes.

Johan Sandersson: Have you got any way past discussing what type of identifiers they use today?

Matt Howell: In typical buy-side arrogance, I assume they’ll use what we tell them to. But in seriousness, I expect that to come up in upcoming conversations.

Johan Sandersson: If we can be part of those discussions, that would be great.

Matt Howell: Absolutely. When I have these conversations with the banks, I’ve made a point of mentioning this group. For people on the trading side, I think it’s hopefully been useful.

Johan Sandersson: Frank, do you want to give an update on your CDS work?

Frank Tarsillo: Yes, we have a demo to show. We created the CDS bot to present CDS information over Symphony using financial objects and MessageML. We put all of our CDS data into elastic search. We have a client bot sitting in a multiparty conversation listening. The purpose of this is to show that you can be in a conversation with a bot, put out some CDS identifiers, and the bot will put out some information about that CDS.

Johan Sandersson: What’s the difference between the client and CDS bots?

Frank Tarsillo: I’ll show you. This is the conversation. If I do a T, which is AT&T, it should reply with PresentationML. There’s a ticker symbol, that works well, this is coming off the entity data coming in through the UI, as part of the renderer. We’ve done some trickery here, showing you the red code, CUSIP code, and the obligation identifiers. So this is red information. It’s based on elastic search, so you can type the ticker, the name of the company, etc.

Let’s look under the hood. As I mentioned, the chat client’s going to pick up the PresentationML coming through the wire. Looking at the ticker, you see class “entity” and “data-entity-id” is “T”. Where’s that coming from? Here’s the entity data, here’s all the data included with the message. This renderer’s only going to pull the first item in the list, here it’s a ticker symbol with the ID “T”.

Johan Sandersson: Is the scratch one HTML what you’re sending?

Frank Tarsillo: That’s what the bot is sending – the PresentationML you see here plus the entity data which is part of MessageML 2.0. So anybody can pick up that data – a bot could just access the underlying data. Here are several other pieces of data we’re sending as entity data, here’s how we’re representing it in PresentationML.

So, you’ll see these formats and the cashtags representing the values here, we want to register this as the underlying attribute so the popup is aware of the underlying instrument. So there’d be a price viewer for a red code, a UI application associated with that type of data. It doesn’t work great with the default renderer, but I think if we built our own, it would.

Any questions?

Johan Sandersson: No, that’s great, I think it really illustrates is that the user has to pick which data he’s interested in when what we really want to do is send the whole data object over to the third-party app, so the app itself can pick out the data it understand.

Frank Tarsillo: That’s right. You could also filter based on the identifier and launch an app that understands that.

Bruce Skingle: Everything you’ve suggested is a good idea, and the only obstacle is what we’re able to build. But in the meantime, you could use cards to get some of this functionality, albeit without a popup.

Frank Tarsillo: Definitely something we could implement, so I’ll come back with that.

Peter Monks: Frank, previously you talked about limitations of PresentationML, how do you feel about the new stuff?

Frank Tarsillo: It’s still very limited. The thing I’ve found is that it’s difficult to position data within the HTML divs and spans. I don’t see how to implement different column widths, that sort of thing. So it’s a great start but it’s limited if I want to do something significant with style.

Johan Sandersson: Do you have other applications that view this data?

Frank Tarsillo: We do. It’s primarily a batched-service data feed, but we do have web-based desktop applications like a price viewer that present this data.

The next step – this is the reference data – we’d like to link in pricing data, hopefully in card form, or build a small app that represents the pricing data, or we create a desktop application, but I really don’t want to do that.

Johan Sandersson: What’s the negative bit of just having a link here that send you to the desktop app if you have it installed?

Frank Tarsillo: There’s no negative. We were having some problem with links working in tables, which is another issue I have to raise. We were going to use a predefined URL with a query coming off the back containing the red code, and it would bring up an app with the pricing information.

It would be nice to have a way within the renderer, when you click on an identifier, it would interpret the entity data and a javascript function would construct the URL to call based on entity data provided over the network.

Any other questions? Ok. Thank you!

Johan Sandersson: Ok, we’ve got five minutes for any other business. I think this was a lot of good stuff. I don’t see Jeff. Has anyone talked to him?

Bruce Skingle: I’ve given some feedback in confluence. My concern is that there’s a danger in mixing references with data, especially in the context of personal data. Having it stored in Symphony messages may be problematic with regard to data protection regulations.

Johan, there was an organization ID in there, e.g. for unlisted corporations. Do you have a database for that?

Johan Sandersson: We do.

Bruce Skingle: Is it very expensive?

Johan Sandersson: Not too bad, but I’d need to look into the rights issues and whether we can share those even if we’ve licensed them. It’s definitely something to consider. I like your idea that the object should contain references to where the data comes from rather than the data itself.

Bruce Skingle: It seems like this working group could link people who need references to things with people who can create and maintain those taxonomies.

Johan Sandersson: Ok, see you all on Symphony!

Attendees