 I don't know if anyone's doing introductions today, but I can happily introduce myself. So I'm Chris West from Cosec, I work on the Vince Ombll team, and one of the maintainers for FDC3, as I know several of you know and have to deal with beyond a regular basis. But anyway, what I'm talking about today is the FDC3 workbench, which is intended to help you integrate FDC3 into your applications fast and easy. So for those of you who don't already work with FDC3, I'll give it a bit of a definition or an introduction to provide context. Essentially, as I'm sure you do know, banks and hedge funds all use a huge ecosystem of in-house and vendor applications, OMSs, trading applications, data apps, analytics, CRMs, et cetera. And the lack of interop between those applications or the ability for them to talk to each other and tell them what they're doing leads to having to implement lots of manual processes for workflows. And those are inefficient, error prone and are often operated inconsistently. We're often told that traders skip out things that they're supposed to use because they're going to get a response out in time, and it's just because it's inefficient. Now, proprietary solutions for those problems certainly do exist. We've had them in our product for four or five years now. But we're well aware they're not the right answer. They lead to market fragmentation, vendor lock-in, application vendors who don't know what to target or have to target multiple different proprietary APIs, so they can't do all of these things. So the solution to that, we believe, is the open universal connectivity standard that is FDC3. It's designed to help the desktop apps talk to each other without a back-end integration and is often described a bit like fix for the desktop, where fix messages often pass between back-ends. We pass messages between front-ends of apps. Now, FDC3 is put together out of four key concepts, often referred to as the four pillars. And that is a specification for context data, which is really the standard for the content of the messages. A set of intents which are sort of like verbs, actions that you want to happen. So I want to view a chart or view an analysis. They've got a predefined, pre-agreed meaning. There's an application directory that standard that is used as a registry of what applications are available on the desktop and what intents they support. And finally, an API, the desktop agent API, which is a set of shared operations or interface for operations that can be implemented and then used by lots of different app vendors. Now, there are generally two types of participant in FDC3. There's the desktop agents who we tend to refer to as the sort of hub of the desktop. They make the thing happen. They implement the FDC3 API and make it available to all the applications. An example of those are products like Finsombol, Glue42, and others. They're also in-house developed containers at various banks and by-sides. And even a browser extension that is another Finos project, the FDC3 desktop agent Chrome extension. The other side is the FDC3 enabled applications. If the desktop agent is the hub, these are the spokes of the desktop. And they use the API provided by the desktop agent to talk to each other, to send messages. And those are the things like the OMSs, EMSs, pricing charts, market data tools, et cetera that I've mentioned. Sitting between those is another thing provided by the desktop agents, which is a resolver UI, which is often used to pick applications to resolve intent. So I want to view a chart, show me a list of applications that can do that and let the user pick one. Now, how FDC3 is used in the world is to connect those applications from different vendors. For example, on a typical desktop, we might have Charles River, the investment management system, might be, you know, be using an order blotter or something. That's got built-in FDC3 support that they're developing with Finsombo at the moment, something like Bloomberg or another proprietary terminal that may or may not support FDC3. Bloomberg doesn't, but has terminal connect, which can be used through a translation layer you can put in. So FDC3 can drive terminal connect and show various things. You have your own applications that you've built. It's easy to add support for those. We're hoping to make that easier with the workbench and then something else like FX Connect, which again is currently implementing FDC3 support and which should be available to you soon. So a typical workflow through these might be clicking on an order in the order blotter in Charles River. That might drive some context into Bloomberg and bring up various charts, analyses, news, et cetera. It might also drive that on into your own proprietary calculations or signals, trader feedback applications, research applications, et cetera, ultimately resulting in being able to push something onward into something like FX Connect to actually stage or execute a transaction. In turn, that could notify other applications that something's been done, something's been executed. That will often then be reconfirmed by another protocol like FIX or something else. But how do you actually then do FDC3? How do you start using it in your applications? And I'll do this first from the perspective of an app vendor or in-house app development team. The typical first step is obviously to explore your use cases. What actions do you need to invoke or listen for? What messages do you need to send in order to make that happen? You're then going to start experimenting with the API. That means getting access to a desktop agent. For example, you can get Finsombo, which is free for non-production use cases. So if you're just trying to implement it into a vendor application, we'll let you go and do it. You then need to learn the API. That probably involves building a test application, some sort of toy app that you're going to make some of the calls in, see how it works. You then actually sit down and implement your integration into the real applications. That means adopting or creating context types to represent your data, picking or defining intents to represent your actions. Then finally setting up the context sharing, listening for the intents, listening for context broadcasts. Finally, you're going to test that integration, which means finding something else to talk to to make sure it works. Again, you're going to build a test application. This is often done to the bare minimum standard that you need in order to make it work. How do you do it FTC3 from the perspective of a desktop agent vendor or developer? This is obviously our experience of it. You're going to probably wade right in and implement the desktop agent API, but then you've got to test it for compliance with the FTC3 specification, and then we're back to building a test app again. Then once it goes out, you've got to provide support to application developers. That means helping them learn to use the API as they plug it into their applications. Again, you're back to publishing a test application or other examples for people to go and use. That's how it's done, but what's the problem? We found as we've helped multiple firms to do this that developers sometimes struggle to actually get started. Building that first test application sometimes takes them a while to do, because there's a lack of examples or learning material, something that Finos is actually going to address in November, I think, when they're releasing their training materials. It takes them a while to get going, but there's also a lack of reference implementations for compliance testing, both for your own app and for the desktop agent. That leads to lots of duplicated effort from lots of different firms on throwaway test applications implemented to that bare minimum standard. So our response to that is to introduce the FDC3 workbench. We've built it for our own use. We're contributing it to FDC3. It's been developed by the team working on Finsomble itself. It's essentially a developer app for FDC3. It's going to replace those throwaway test apps. It hopefully simplifies the learning curve for other teams getting started with it. They don't have to build any applications, get two copies of it up and start them talking to each other as I'll show you in a minute. And it will provide a test harness for apps and desktop agents. As the standard advances, we're going to need to do more testing of our desktop agents for compliance with those standards to make sure apps are really portable between different desktop agents, and we need the reference implementations to do that. So without further ado, I will wade into a demo of the workbench. And basically, I will load it up on Chrome. And the first thing you're going to get if you load it into Chrome is a message telling you the FDC3 API is not there. This is not going to work. It's not a standard web API. It's not there. So if it picks up that it's not there, it's not going to load for you. But if we have, if we mess with the Chrome extensions, for a moment, I can load up the FDC3 desktop agent Chrome extension written by Nick Colburn actually forms another separate project within Finos. So if we turn that on and reload the application, we've got a little icon up there with a channel selector, and this time the workbench loads. It's giving me back a list of channels returned by the extension. I can join one if you see the little icon up in the top on the extension, join the yellow channel and jump to the red channel. And there we go. You can also read that back through the API, which allows you to read your get current channel essentially. But the Chrome extension is currently in need of some maintenance doesn't support the latest version of FDC3 is starting to get some problems with some of the test apps. So I'm going to continue this demo in Finsombo, which supports FDC3 1.2. And I use my shortcut here to launch the workbench. And there it is again. Now we've got a different list of channels. So these are the ones that Finsombo sets up. So we happen to the number of them. They come with colors again. So if I join it, you can see it's actually displayed on the window Chrome for an individual window. Normally, these are set from the linker icon up in that top corner. So I can turn it off again. And there I haven't got a channel set. Join another one through the API. Now once we're on a channel, we need something to put onto it to create some sort of message. So I'm going to set a context to make life easy. The workbench helps you set up templates for context types. You don't have to keep typing it in. I know I've typed in an FDC3 instrument about 400 times in the last few months. So it helps to save these. It validates the JSON of what you put in. So if it's not currently, this one's not a valid context type yet, before I pop a type field in and name that type, we should get rid of that validation message down the bottom. It's not currently valid JSON. And then this is the minimum you need for an FDC3 context is a type field. But there are some other fields defined. So if I pop in an ID, and I make that a string that doesn't validate against the context schema, which is what it's warning me about there. I'm also missing a comma. We'll sort that out. So we're not valid against the context schema. And if I fix that, make it an object and then add in an ID field. They're usually named fields. These ones can be strings. We've now got a valid context type. So we'll go ahead and save my custom template there, which will pop it into a menu. And I could set the current context for the application, which is represented on the right hand side in the toolbox column. So I can work on a different one. So we can select any of the type standard that are built into the standard at the moment list that I hope to see get a lot longer over the next few months as we work out some others. But here's our basic Microsoft example from the standard. So that's the current context to switch back and forth. Typically, you probably want to set up different versions of the same type. So I like testing with Tesla. No prizes for guessing what my next car is likely to be. We just set that up. Have a guess at the Rick. And there is no way in the world I'm going to remember the icing code for Tesla. So we'll just delete that. And just save that as a custom example. So we've got it in our list. Make it easy for me to switch back and forward. Then after we've got context, we're going to need something to actually send this over to. So I'm going to start chart IQ, which the chart IQ advanced chart template now has built in support for FTC three. It's nice and easy to turn on. So we'll pop that on the same channel. And I can go and broadcast our current context. She's picked up by chart IQ and show that we switch back to the Microsoft example and broadcast that. Okay, we're testing context sharing. Quite easily, but we're getting ahead of ourselves a little bit here because chart IQ has already got built in support. So another way of working with this would be to have two copies of the workbench talk to each other to start with this simple little experiment that I think often gets developers over the initial hump of starting to work with the API and pop chart IQ down the bottom so you can still see what's going on. If I add that to the yellow channel as well and we go and broadcast our context again, nothing happens, which is correct because we haven't actually added context listener yet. So if we jump back to the context panel, we can go and select a context listener. So we'll listen for FTC three instrument, add a listener, which immediately you'll note on the right hand side picks up the context that's already sitting on the channel, which is what's supposed to happen according to the standard. So if we switch back to our Tesla type, create the context and broadcast it, there we go. There's our next message has arrived. And if we broadcast a contact, create that context, broadcast it again, nothing happens because we're not listening for that type. So the FTC three standard lets you listen for all context or specific ones, you get filtered lists. So if we add the old listener, you can see I've already received that contact and anything else that I transmit will be received on that particular one. So country also is picked up. So you've got you've got those two options. And we can basically just review a log of the things we've sent. If we're not getting the behavior that we're expecting, we can see exactly what sort of messages we sent, what the format of them look like when we receive them. Confirm that nothing's changed on the way through, which is something we might start doing in future in FTC three. So we've been talking about earlier on today. Now, let's just do a bit clean up, delete those listeners before we move on to the next bit is intense. Let's just set up a context again, because we're going to need it. Actually, pop back to this. If you're learning, it's easier to copy and paste. So one of the ways that it makes it easier to learn the standard is you can always copy code snippets or in this case, I've copied the context I've set up there. So I can just paste it off into my IDE. If I want code snippets for a particular action, there's a copy button next to every action button in the application. So I'm just copy, paste into my IDE, start adding a bit of code. Your code goes here. Let's go have a look at the intense support. It's intense again, work with the current context of the application of the workbench. It doesn't have to work that way in your app, but it makes this nice and easy to understand as you're going through. So we'll go back to the context panel and pick one of those context templates we've set up, create that context again, pop back to intense, and pick an intent type. So some sort of verb. We want to view a chart, raise that intent, and up pops the resolver that I mentioned earlier. This isn't provided by the workbench. This is provided by your desktop agent. It shows me the applications that I can launch. So in this case, we'll pick chart IQ again and launch a new instance of that with our context. And let's come in and immediately loaded Microsoft as per our context. Now an optional thing you can implement in desktop agent, you can send it to a running application as well, which is something that Fincambol supports rather than starting a new window every time. We'll pick it and send it down to our one that's looking at the bottom. We're expecting to do a bit more with instances in FTC3 in the future. Now if I want to do this in the workbench, I can go ahead and add a listener again, just like we did for a context type. So I'll pick a view chart listener. And as it's an optional feature of FTC3 sort of runtime registration, it wasn't registered in the app directory, Fincambol has popped up there a little warning message to me. It allows me to do it for development purposes. But now you'll notice the workbench doesn't appear in that list of new applications I can launch. But it does appear in the list of running applications. So I can select that one and route my intent over there where you can see it's received just like the context are and you can check the type of object. So where that's going to be useful is when you're starting to test the behaviour of your own application, make sure the data is formatted correctly, making sure it comes through okay. Your application directory has rooted it correctly. So for example, if I use this order management mock-up that we used to demo Fincambol, just add a couple of orders into it. And I can use the view chart button on this Rio Tinto order row to raise that intent for view chart. So Rio Tinto hit view, we got the resolver, send it over to FTC3 workbench and I can see the exact format of the message that the app developers for that application set up to send over for me. So useful for QA testers, for example, to see that they've got exactly the right thing. Also, we added in FTC3 1.2 the ability to raise just a context, which forces the desktop agents resolver to show you or should show you a list of the types of actions you could do, like you do with a file dialogue. What do you want to do with this file? So up here, I can view a chart or I can view news and I've got a different list of applications for each one. So I'm going to view chart and off we go to chart IQ again. So that's pretty much the size of it. That's the basic operations in FTC3. We've got a little bit more to add with app channels coming in. There are a bunch of other things that we're looking to add to FTC3 and 2.0, which will hopefully all then be represented in the workbench in short order. You might ask why we're open sourcing the workbench? Why isn't this just the fin sombal FTC3 workbench ship with the product? Leslie asked us when we started. We're basically cozy making a huge investment in FTC3. Both are both our products. Integrate it. We've got a desktop agent in fin sombal. We've got built in support in chart IQ so can be dropped into any desktop container. And we know the industry trend is happening. We're talking to people about it all the time. But firms are struggling individual developers are struggling to get started with just how to do it. We believe that contributing to the FTC3 standard and project is not just about writing the specification and raising issues to add new functions to it, but helping people to actually adopt it. That's why we're here speaking, but also why we create in the workbench. We're trying to make that easy to pick up. And you might also ask how you can get involved. Now I was going to ask you to come and review the PR. We've it's sitting ready to go into FTC3. But as a couple of the other maintainers reviewed that for me this morning, I think we can have a little bit of fun. I don't know if it's going to run to that screen. We've got a giant pool request up here. And I think at least on the improvements, we can go ahead and merge that pool request and have a little bit of open source in action. So, there you go. So, no, it's gone now. No takesie backsies. So don't review the PR. You can go and check it out when the GitHub workflow has run, assuming it runs without an error. Hopefully in a few minutes, you'll be able to access it up there instead of the URL we've got it hosted on. So we've added it straight to the FTC3 repository for maintenance with the spec and website didn't think a separate project was warranted. It needs to be maintained against versions of the specification. It's easier for all of us who are already involved to use it. And if you find a problem with it while you're using it, just raise a PR or an issue and help us get it sorted. If you're checking that out, you should also check out Johan Sanderson's another one of our maintainers from fax at FTC3 explained applications on a different PR. It's going to go into a similar spot. He's got a slightly different approach with it. He's built a vanilla JS application designed to be super simple code that's really easy to read and copy and paste into things where we develop more of a react application as a workbench. So different uses, but same same intentions. Also, we're always looking for new maintainers, editors, contributors for FTC3. So if you're using it, come along, provide us feedback, raise issues. Check out the to do list for this application with is also a to do list on the issues list for FTC3 itself. So if you or anyone at your organisation can spare a small amount of time to contribute, it'll be very much appreciated. Come and join the standards working group meetings. Once a month, there's also discussion groups with splitting off for things. We're going to splitting off one to look at context types and intents over the next couple of weeks as well for all those things that need to get added. And you can find it all there. So as I said before, one shameless plug. If you are a vendor looking to integrate FTC3 and need something to test it in, come and check out Finsombo. It's available straight on GitHub so you can just download it and get started. So we've got, I assume a few minutes left. I know the bar doesn't open for another 25 minutes. So if there are any questions, we've got 25 minutes to kill. But you don't have to stay here that long. I think Gav wants you for his closing remarks before then. Rico, that's why I look like a rabbit in the headlights. Well, we actually used the NPM module that you worked on that made life very, very easy to build. It does sound pretty set up. So it was the developer who did a lot of the work. I did a lot of the polish on the end. Another guy did a lot of the setting up. It was his first time using FTC3 and he found it really easy based on the NPM module and the documentation. So that was a great start. He did have a whole bunch of questions about how it should work. What's this thing supposed to do? So we worked up a lot of wire frames to explain it. And the goal is basically to eliminate that learning step for people in future. So he's now thoroughly polished on it. But with a bit of luck, people can get started by literally throwing up a copy of the work bench, throw up another one, start talking to it. We've got an introduction video based on that. Hopefully we'll find a way of shoehorning it into the FTC3 training as well. Because as soon as you've done it, a couple of times it's all really clear. It's a simple API to use. It's just when you're faced with a big documentation portal and a lack of videos or training materials, I'm finding like lots of the younger generation of developers really just want to watch a video on how to do it. Or they want to find a tool that they can copy and paste code out of. I mean, the older guys amongst us would rather go into documentation portal and scan, read it and get started. But the next generation really have a different approach to learning how to do things. They like reading code better than like copying paste video tutorials. So we've recorded a screencast, so a much shorter version of this tutorial that we'll post as well. I think we can probably link off the resources page too. And hopefully I've got an issue open for that resources page on the FTC3 website. So if anyone else has materials that about learning FTC3 or tools that are open for use, that they want to link off that do get in touch. I would like to think so. There is because FTC3 doesn't actually define some use cases doesn't actually define all the workflows. It is a little bit harder to build automated testing for every case. But I know there is a desire to work towards some automated compliance testing, for example, for desktop agents. That I think is a lot easier to build than general purpose automated testing for applications. So this will allow a scripted manual compliance test very simply for a desktop agent. You'll just run through a script. Does it do these things? Check these outputs. So a different tool for automated testing is probably needed, but it can probably be built on to the workbench as a base very, very easily. So you sort of hit go and it runs down doing tests, preferably in a way that can be also automated for end to end testing and on a GitHub repository. Definitely something we've talked about and something we'd like to work towards. I think we should be very grateful for the support that Linux Foundation and Finos have provided in finding and funding those people for the specification rewrite. Really, the goal is to take it from the quite narrative specification is at the moment to a formal, much more easily tested specification that will still be supported by friendly documentation, examples and tooling, but something that's a lot more precise and could even head towards a formal standard, perhaps not ISO, but perhaps some other certification, IETF or something. Thank you very much.