 Hi everybody. Thanks for joining us. I'm Mike Lynch, Chief Product Officer of Symphony. I'm Leslie Spyro, the CEO of Tick42, the proud owners of Glue42. And our good colleague and collaborator, sadly, Demeter, is out sick today. So he helped us a lot and this is really his, a bit of his brainchild. So we, unfortunately, we'd love to do a live demo for you, but given the little last few last minute changes, we have, we're gonna do a, we're gonna have a video and we're gonna, we're gonna narrate the video and, you know, hopefully Leslie and I can tiptoe our way and tap dance our way through this. So really excited to be here and share with you some of the collaboration that Symphony and Glue42 have been doing around the Desktop Interoperability Standard, FTC3. And what we'll do is we'll walk you through Desktop Interoperability, the FTC3 standard, walk you through the demo where we're gonna showcase Symphony, Glue42 and single track. And then we'll talk to you a little bit more about the future. Yeah, I think as it says, we're really trying to talk about real-world use cases. So we assume, I recognize some of you, I assume many of you know quite a bit about what FTC3 does. So there will be a little bit of an introduction for people maybe who watch this cold on YouTube or wherever it ends up. But primarily we want to talk about some real-world use cases and how existing applications and platforms kind of can support Interop where we go from there. Yeah. So, shall we get going? Yeah. So why do we have Desktop Interop, what's it for? Does it solve a problem? And that kind of is the problem. You have many of us work with on desktops running lots of... Can we shut the door? Actually, just to keep making it maybe a little bit quieter. So we talk about Desktop Interop not because most of the applications are native existing applications running only on a Windows operating system, but because many of our users run a desktop typically with multiple screens and use lots of applications, many of which are web-based, some of which are SaaS. And we kind of get used to this idea that each of these applications are individual and separate and there's third party, there's in-house, there's web and there's... People call them legacy, I hate that term. Let's call them native applications. Let's call them production applications that have decades of business knowledge and UX feedback built into them, which maybe we need to change the technology because it's quite hard to get junior.net developers now. But they're good products and we work with some Java swing applications and bring them into this space. We've got one client who is a big VB6 application, still use it, support for VB6 withdrawn in 2008, but still it kind of runs and it does this up. And we kind of taught users almost too well. The first question most of your users need to answer when they phone a help desk with a problem is which application are you using? Because everybody understands there's a dev team who delivers an application and everything within that application is in their domain and everything outside of that application who cares. And so often we talk to a lot of people about starting on this desktop interoperability journey using Blue42, using FDC3 but APIs and data contexts. And the first thing you say is what do you do? And they go, oh, well, my user uses my app to work with my data. And you'll go, that's interesting. Do they run Bloomberg? Do they run Symphony? Do they run Excel or Outlook? And they go, yeah, maybe. But we just talk that everything happens. You can only feedback within a single application. And there's these silos, every support thing, which dev team do I need to route it to? And there's no real thought about what else your user is using your application, what other applications your user is running. And the point of desktop interop is to break down those silos. And to accept that the unit of analysis, the unit of work, the unit of delivery should not really be the application, but it should be the workflow. What are you trying to do? I have a job to do. I'm going to move between applications. And this isn't that helpful. Every application running on its own, very well isolated so that one bad app doesn't crash the system. That's a great idea. But the idea that the only way I communicate between applications is copy and paste or click and highlight a window. That's not a good thing. And that's what interop is here to do. And FTC3, Pele, is a large part in that. We're talking about the bits that it doesn't cover. But this basic interop, what at glue 42 we call click to sync channels and click to launch, which are intense and we'll come back to what those mean a bit later. That is the problem we're facing in all these third party applications that we're trying to solve. And so this is what a solution within my product, glue 42, there are many other good products out there from, quite good products out there, from other vendors. My friends from Kozeg smiled at that. But with a fairly fixed smile. So yeah, other options are available. And the key point is we're trying to bring these things together so the user can consider getting a job done with a load of applications that cooperate, including third party and in-house applications. And FTC3 is a key part of that. And FTC3 1.2 very successful. FTC3 2.0 even more successful. But the biggest success for FTC3 2.0 is not lots of fancy new APIs. It's not lots of new features and functions. The big, big change is in the intense, which is where applications say I can do this job to anybody who wants to connect to it. And this is how I'm going to describe a chat, a counterparty, an instrument, what we call FTC3 data contexts. And those are the key. And so to me, the biggest improvement, biggest change in FTC3 2.0 was the arrival of companies like Symphony and Singletrap, who take part in the data context and intense discussion groups. And to me, that's where the biggest changes come, that we have real people, but they're always real people, real applications talking about the data context for real use cases. Whereas in 1.2 is kind of pretty much us container vendors or desktop agents, the term in FTC3, talking about things like an instrument and a counterparty, but not really having real use cases. Whereas when Symphony came in, they were about how do we describe a chat, how do you initiate it? When Singletracker, how do I log a call or contact and that kind of stuff. So for me, that's the biggest change with 2.0. And the thing I would ask all of you, see some of our clients here, is that you could contribute a huge amount of sharing your use cases, working on data contexts within the context of FTC3 2.0. So that would be my big ask that the APIs find, may or may not use it, we have examples of where it's kind of handy that software vendors have used it, but the big thing that I think that all of you could contribute is more use cases and richer data contexts. And we'll show that a little bit as we're going through the demo. So I think probably that's what I wanted to say here. And some of this stuff is a quick refresh on FTC3. I won't go to very much detail, but it's a messaging standard. It's about APIs, not message formats for doing two major tasks. Click to sync, click to launch. And here, if I have a pointer I would highlight, maybe I can reach up, is the FTC3 enables true plug and play interoperability and discovery on the desktop without prior bilateral agreements. That without prior bilateral agreements is another key tenant of interop. It talks about the fact that I can write and publish an application that's FTC3 aware. And then a year later somebody may be in a client, writes an application. I have no knowledge of that application. It didn't exist even as a spec when I wrote my app. And it runs in the FTC3 environment and it just works. There's no need for us to negotiate. So in the demo that Demeter prepared for Mike and I, when we run the video, you'll see these interactions. And it will look great. You know, a single track will work really closely with symphony. But the point is single track have not written to a symphony API. They're publishing and using FTC3 APIs, FTC3 data context and that's the key benefit I think there. And they work together because that's what FTC3 is for, no prior bilateral agreement. And the final bit is think fix for the desktop. So in GNU42 we're talking about straight through workflows, trying to build on the straight through processing for OMSs. And I think FTC3 is fix and both on the good side and the bad side. So it's fix because it's standard and it's built co-operatively between competing companies. It's fix because it's very easy to use it in incompatible ways, right? I don't know if those of you who work on OMSs is very easy to have valid fix messages that don't mean anything to the other side because fix for a long time just focused on the message flow and didn't say these are the tags you need to describe an order and exchange traded equity. I mean that's grown over the years. And it's also fix because it's not sufficient to deliver an OMS or an EMS. Fix is a key, really important part and you need a load of other stuff to deliver a great PMS and OMS and in the same way FTC3 vital for doing interop, but there are other services that you need from your desktop agent of choice. So yeah. I think I'll just, you know, why Symphony is here and sort of why we're excited about this. We're, our journey with FTC3 interop is fairly new. Last year we announced that we were going to be a supporter, we're now a maintainer of the FTC3 standard and for us, you know, at our core from our product point of view, we believe in openness, flexibility and connectivity and that is sort of the same mantra that exists with FTC3 and desktop interoperability. We want to enable our customers to create connectivity and workflow within their desktop and then for us, you know, Symphony where we're a community of 500,000 financial professionals across buy side, sell side, tier one, tier two's being able to then create inter firm connectivity and inter firm flexibility where you can now take, I have, I can get to the information I have, I need quickly and then provide that relevant content to my customer, to my counterparty seamlessly by connecting FTC3, you know, the desktop interop, you know, containers and of course Symphony as the messaging and collaboration layer. And we're going to show that to you now. So what we have is a demo where we will play together, it will be a fun sort of two headed person. We're going to play a typical sell side research sales person who's monitoring content news, you know, trade recaps on their desktop. They see something that is of interest and they want to be able to connect with their customer and provide relevance and context as quickly as possible in using a number of tools in Symphony such as our, what we call our signals, our new enhanced tags and then using a glue 42 sort of desktop creating that connectivity both from Symphony to Google 42, back to Symphony to single track the sales person CRM, then back to Symphony and to the customer and then in the end actually wrapping that all back in the CRM so that you can show, you know, being able to connect all of that all without, the only thing we'll ever type is an actual message. Everything else will be, you know, single click here, single click there removing that swiveling and context switching for our customers. I'll just add one thing. It's not particularly well scripted, so Mike did not really modest about Symphony because where before FD, before Finos was Finos, it was the Symphony Software Foundation and so some of this goes back to those days so I don't look at it as a new commitment, I look at it as a return to... Fair enough. But I think the other bit is just to pick on this idea of workflow between applications. So most of what the demo you're about to see uses what are called FTC3 intents. So this is the idea about I can invoke a method of function and operation in another application by using FTC3 and that's primarily what you're going to see. And the channels that click to sync, big part of Symphony is not part of this demo, didn't really make sense in what the flow. But the point I wanted to make was that the primarily FTC3 talks about flow between applications running on a single desktop agent like Glue42 or any of the others. That's what it is, it's about flow between applications running in a container. Now Chris and the team from Kasek have been leading an initiative which they're talking about later today to allow bridging between platforms so that within the desktop you can have say Glue42 and you're running for ensemble, those applications will work together. So that extends the scope of the flow between one desktop agent running on the desk and another desktop agent. But what Symphony does, and I think this is something really worth bringing out, is extends the flow between participants. So a flow might originate from user one in a completely different firm and arrive at user two through the secure Symphony channel. Then because Symphony is committing to FTC3 it can do the whole interop and loading applications that work together. So that kind of expansion of the flow from a single desktop agent to multiple desktop agents which Kasek will be talking about later and then talking about extending it between users using Symphony as a secure and trusted channel and then also they've got their workflow development kit which is like a BPMN type thing from rooms that can also generate those kind of flows from a server to a front end. So I think that's a real theme of 2.0. Not so much new APIs or a few changes, better data context and then expanding flow between desktop agents on the same user and between users using something like Symphony. Exactly and one of the things that we're seeing really powerful and we'll get in the demo in a moment, is that with Symphony we connect Symphony to Symphony, so customers, but we now have connectors to WhatsApp we chat SMS for our customers who need those compliant ways of communicating with their customers on those channels. You can have a user have these interoperability powered workflows and then connect to their customer on their customers preferred channel. So really opening up in that theme of connectivity and flexibility. So let's get through it. That works so far. Excellent. So what you're looking at is a highly simplified version of a sell side sales person's desktop. We have Symphony on the left and then we have single track on the right and before I get into Symphony maybe you talk a little bit about single track and what single track is all about. Single track is a CRM for the financial markets a lot for wealth management and it uses Salesforce in part, but it's focused on the CRM for sales traders and people like that. And so it's a major product and runs its own space and they've committed to FTC3 to enable the kind of interoperability. We ran a similar demo a few weeks ago with Paul Dyson with a much better description of what single track does it's a CRM. Exactly. And here on the Symphony side what you're looking at is across the top this user has a number of workflows you see their clients workflow, their external, their internal and then what we're actually looking at is what we call our signals view on Symphony. So they've got a filter view of all their incoming Symphony content based on the tag that they think is most important to them or us or we and in this case it's looking at the market color tags you see the hashtags of market color. So this is a sort of a general filter that the sales person has for any kind of incoming content that might be coming into their Symphony view and you can see we have sort of user content and then we have bot content as well so in this case what we have is a trade recap that was posted automatically by an application that could have been using RWDK which is our low code, no code ability to create bots and workflows visually and you'll see here in this case it's a trade recap and the user has seen it and it's about all their tree asset management which is an important customer and you see this market color button here and that market color button is an FDC3 enabled workflow so I can now click on that market color button to understand more color around Tesla the underlying security and immediately open up my Glue 42 desktop to be able to see that and we'll see if we can sync up the video with the click in the second or so or otherwise I'll pause but being able there you go I clicked on it and now immediately I'm seeing order history, a chart, market depth I don't know if you want to talk more about this is a Glue 42 demo version I agree with you, Barton invoked an FDC3 intent called start workflow, the start workflow we have an implementation of that that loads a Glue 42 workspace that lets them do the work they want around the market color and here you see a load of applications in a workspace all focused on Tesla which was where the market color came from and that's you've got and that's a key piece obviously what you've got is potentially very trivial we've run a few applications focused on but there's no searching for windows starting copy paste anything like that it's just a natural extension of how the user wants to work they want to move from their market color message to a workspace that lets them explore what's happening with Tesla and now they're looking at this they're looking at the order history and they're going to see what messages have I had around Tesla and that's going to be taking them back so now you'll see an intent sent back to Tesla I'll just pause it to make sure we kind of make sure that that's clear so now we're going the other way so from Glue 42 there's an FDC3 intent for view messages with the context of Tesla so the ticker this is where our enhanced tags come through and now my view on Symphony has up yet where I'm specifically looking at any messages that I've received that refer to the secure with the security Tesla so TSLA in there and you see some of them also have market color but in this case it's a specific filter for Tesla with a single click. I'd like to see it from Glue 42 but actually that's not the case what you've got here is a set of in-house applications hosted in Glue 42 and they've decided to make use of an intent and move back from the in-house applications to Symphony so what we see here is Symphony a major third party application single track and called third party application load of in-house applications all working together none of which were designed with each other in mind they're just FDC3 aware so that's the only point I wanted to bring out. Yeah very fair and I think and now what we're seeing is in this case we're using our new Symphony enhanced tags so Symphony's had sort of cash tags and hash tags since its inception and you know those are you know dumb isn't the right word but maybe it is they're just you know text with an object in front of it to signify this should have structure. With our new enhanced tags and you see it on this view we now have securities that have that understand the underlying identifier so ice and figgy etc so you can now create truly far more rich far more intuitive and intelligent workflows because you'll actually you'll be able to share and identifier across application so in this case I see that Tesla is referring to this icin and I have a variety of actions and this this list of actions can be customized per user so if I have various Symphony applications or other workflows that I connect to I can I can look at my internal research I can do I can create various workflows off of that security view all powered potentially by FDC3 and in this case what we're going to do is we're going to go view that instrument and again to Leslie's point pass back an intent in this case you'll see an intent where there are multiple applications on that user's desk that they can then choose from based on the workflow that they want to create so in some case I might want to look at a piece of research or I might want to open up my CRM so if you want to you want to talk about the intent resolver in this case Leslie. I mean so view instrument is a predefined FTC3 intent any applications are free to offer it and what happens when you're running you see which applications are available started or defined that can offer view intent and if there's more than one then you provide the user with a check a selection box and here they selected to see the instrument in the context of single track to see which of my clients are interested in that instrument but the important points I think are that if I want to go to a particular application I don't have to show a selector the application could say call view intent in single track but here it was just whatever is running at the moment that can do view instrument let the user choose it and that's what we're doing here and so the user selected selected to see single track and here he's seeing the instrument in everything to intent. In this case we're using single track to look at recent research readership of my customers on Tesla pulled up Megan who is the same customer at Aldertree so he can now also see again these single clicks to say a trade was done I can see what research of mine that customer has read recently and now I'm actually going to go and share an update it's at a research that trade is now a reason for a conversation where we're seeing a single track workflow where Demeter has selected a piece of research and is going to send it back to the end user again being able to provide all this context throughout their workflow and I'm going to pause it here there we go to kind of talk about the next again we have this selector component again. Michael spoke about a single track workflow for sharing research with clients and what it really is is that's how in the old ways you might have looked at it but obviously the actual share research with clients involves finding the research finding the client that what happens within single track and then choosing to distribute it with them which is when single track might go oh however you want to do that and now we using symphonies FTC 3 capabilities to move directly from single track out to symphony to complete that workflow which is really a user workflow which starts in symphony and starts seeing a track and ends in symphony exactly and what we had it we've kind of we've purposely chosen this selector here to highlight something new in terms of symphonies FTC 3 journey so what we've been using here on the left hand side is what we call the symphony SDA which is our electron powered desktop application we also now have what's called the symphony ECP which is our embedded collaboration platform and what ECP is it's a modularized embeddable version of the application that can be put in a web app in a variety of configurations styles and use cases and it can be complemented with human as well as bot and other workflows that are powered generally by symphony and what that allows a user our customers to do is if they have a web application imagine it's their operations platform or it's a research platform or one of our third party partners that symphony can now be embedded in that application minimizing that context flow context switching it also is now FTC 3 enabled so it can also be embedded in a desktop interop providers container so in this case we're going to show it in the glue 42 container but it could also been embedded in another one of the desktop interop providers to again create that seamless connectivity and unlock more workflows in and around messaging workflows for our customers minimizing the need to switch contexts so you'll see a situation where a user has two versions of symphony on their desk this isn't admittedly realistic more likely they'd have one or the other but just to sort of illustrate that we have that flexibility now that we didn't have before to provide sort of that contextual workflow of messaging and connecting to the end user I pause it for too long now here's the tap dancing here exactly and this is something that you know just the ECP sort of you know this is again very new for symphony in the way that we think about how symphony exists within our users workflow ecosystem and the connectivity that it provides so you can now put symphony in the context throughout this you see messaging in the context of a CRM messaging in the context of data visualization and all this about workflow so here we go demeters opened up symphony you now see it's the you know it sent an intent with send message we you know we put in a piece of text demeters gonna add some more customization to that to show value to their his customer and then he's gonna again add an enhanced tag so you can also you saw through the visualization of the enhanced tag once it's already been entered but you can also manually enter those texts so it enables both you know application to application workflows around structured objects but also end user so he's gonna add a market color hashtag and then he'll add again hashtag Tesla but you see in that auto complete he's actually selecting Tesla US the US dollar version of the equity ticker and today the first version of our enhanced tags does support equities and will be expanding to more asset classes throughout 2023 that's next year I got there so yeah so he's gonna press send here and you'll see that open up into a symphony message this is where he's again pausing talking about how great enhanced tags are thank you to me anything before so we're going to the last sort of phase of this so he sent it in and that's entered it into a message so he's now in the conversation with Megan his customer you have the piece of research from single track the hashtag as well as the enhanced tag and in this case we also have an intent to share the actual message body with another application any application that is fdc3 enabled so in this case he sees that prior message from Megan says oh that's an important interaction that I want to capture in my CRM with a single click so no more entering of call note no more re keying I can simply type up you know click on the message overflow button there and click on I believe it's a share message the thing I'd make out is a single track use salesforce so what you'll see actually is a salesforce lightning component come up in the context of single track which also has a glu42 enabled and so they're using both the single track connection and our salesforce connector to take the whole message the whole context and log it into the CRM you saw with that that share that message and it opens going to open up single track where you see now the interaction captured in single track with just a single click using two clicks overflow and share message and that can be shared with other application this is a CRM use case but that body of that message is in the context of that message is useful in other applications again the power of fdc3 is any fdc3 enabled application can capture that and that is the demo so hopefully what we've shown is a real world use case a load of single tracks and in-house applications which are obviously mock and single track and symphony working together using fdc3 showing how the fdc3 intents allow applications to work together without being pre-written so actually should someone be foolish enough to have a different track system single track will continue to work and if a symphony user is using some other CRM that would also just work and that is the power of fdc3 and that's really about why as a cross industry consortium and it's so powerful and why these data contexts to be agreed between parties are so useful. I won't really go through too much about what's going on in fdc3 2.0 I covered that at the beginning but I will mention just one piece that we added which was there's been an application directory kind of an app store from the very first 1.0 and that used to say that the definition of the application depending on which container so the application directory might hold an open fin or fin symbol or a blue 42 definition so one thing we did was to create a cross container application definition which can be used by any supporting container which I think is important as the number of desktop agents containers grows and the idea about as a software vendor the extent to which fdc3 allows you to write your code you don't care which platform which desktop agent is there that's an important part that we started doing not sure how far we'll go because actually if you want to deliver the kind of integrated experience that we're talking about here workflows workspaces there's a load of other features you really need to provide that kind of coherence which outside the scope of fdc3 workflows layout notifications which may come in at 2.1 window management streaming scripting the ability to control something another application those are all things which you may want as a software vendor which are platform specific functions outside of fdc3 so hopefully that's a little bit of what's in 2.0 a little bit of why fdc3 helps solve some real problems and some real code running to show what it does I don't think we have time for questions whether any questions and whether there's anybody who can even bring them through so there's no slide though so if you want to do old school if anybody's got any questions please shout out or stick your hand up if you're sorry so I mean I've got a very very very strong background in market data distribution systems right so going back to the original pdw and so it's not necessarily an fdc3 issue there are fdc3 integration interop is not designed for high performance streaming glue 42 as a streaming function you can use so there's a desktop channel named color context or colored context you could choose to write something in the background on the desktop that pushed values there that everybody watching like market data dot ibm might see updates that's outside the idea is that there'll be some engine on the desktop that would read it and publish it and so in the demo you just saw symphony was that engine so some of those market colors were coming from a server and it was being published by symphony and symphony was on the desktop participating in the fdc3 environment so whatever mechanism you're using to push out your updates you'd have a client on the desktop reading and pushing it out so for example we have a bloomberg market data adapter piece and that sits there reads the bloomberg api on the desktop or from the server api and publishes it out there so that's the magic of fdc3 that's you know from that click sent an intent to the other application on the desktop the fdc3 api is an api you bring in an implementation so you bring in a gloom 42 or an ensemble implementation and it makes use of whatever's going on so most of us are using a web socket based component that is sending stuff through there but when you write to the fdc3 api you don't actually see the underlying messages and stuff it's just a javascript function called sending a message to you so you call an api function and you pass a chunk of jason which is the data context so for example the start workflow was a javascript call that says call intent name is start workflow and here's the context and then that gets packaged up and distributed depending on which agent you're using yeah so fdc3 is an api and not an implementation and so what you get is what are called desktop agents the gloom 42 open in the ensemble that implement those things and you don't care which one you're running on you should have no knowledge but yeah there's something underneath that pushes messages around all of the implementations have got some kind of messaging in them and there's a talk later on this afternoon from someone from cosette showing how you can move those messages between one desktop agent and another desktop agent I think the next group is coming in so