London Stock Exchange Group plc (LSEG) Earnings Call Transcript & Summary

Hello. Good morning. Good afternoon. Good evening. This is Matt Eddy, and welcome to another Refinitiv Real-Time customer webinar. We're at the 25th of January. And if you're like us, then time's flying by already, and it's like we haven't even stopped for the new year. So in that spirit, we've got 90 minutes of an action-packed agenda, as we always have. If I can just step through to the next slide. What you can see on the screen right now is all of the presenters, hopefully in the order that they'll be presenting. You don't need to remember this. But as always, we will share the presentation with you after the fact so you'll have all of our names if you want to reach out to anybody that you hear presenting today over the next 90 minutes. Next slide, please. What you might also realize is we're using a slightly different platform to previous events. And so I wanted to spend a couple of minutes just going through the housekeeping. Hopefully, everyone kind of got familiar with what the platform looks like. You've got your main panel. You've got your active speaker. What you'll also have on the right-hand side is another section that's got our Q&A section and also our polls. Now that is powered by Slido. It's embedded into this dashboard so you can find that if you've X-ed it out and you can pull it back up. You can also log in through any other device, whether that's another laptop, through a mobile device. Just go to slido.com, put Real-Time Q1 in. You can post any questions there. We've got a bank of moderators that will look through that to make sure all are appropriate and fit for work, and then they'll post them up. Also, what we'll be doing, I think we've got about 4 polls to go through, and we'll direct you across to the right-hand side or onto your device to vote for those to feed that back. Also importantly to note, we are recording today's session. So it will be available offline for your own subsequent entertainment. And we'll also be sharing all of the material and any past webinars or anything to go by, all of the questions we don't have a chance to answer in the next 90 minutes. We will wrap those up into a document, and then we'll post those out as well. Any issues, refresh your browser. But hopefully, it should be stable, and we should be able to move on. So next slide, please. Okay. So with that, the agenda. We've got a lot wrapped up. We're covering off what we normally cover off in terms of our RTDS road map. But more specifically, given time, we're going to focus a bit more on some of the capabilities that we've got in 3.6.3, and we'll have a little demo of some new capabilities there. Making a first appearance at our webinar, we've got Luke O'Sullivan, who is the product owner for Real-Time Optimized. He's been spending a lot of time working with our platform team working around our new identity access management and the changes in the behavior and also the kind of the user experience changes you'll see and a lot of enhancements, hopefully, we think you'll enjoy that. So Luke will do a bit of a walk-through that in a demo. We're then going to talk a little bit more about our APIs and our end of life strategy, which we spoke about previously. We'll give you an update on where we are with that. And then also talk about a new capability or maybe a capability that not many people are aware of in terms of the data library for Python, and Olivier will walk through how simple that is to use and some of the use cases around that. Jeff and Ted will go through what's new in DACS 7.9, and Ted will walk you through some demos on that as well and some important information and some changes in the support. And then last but not least, Vesna will wrap up with an ATS road map update from what we've done in '22, but also importantly, what we're going to be delivering in '23. So without further ado, because we like to say we've got a lot on, I'll move on to the next slide, and then we'll move across to Jeff. But like I say, use the question-and-answer functionality through the course of the event. If I see any questions I think are important, I'll try and drop them into the conversation, or we'll try and wrap them up at the end or in a subsequent follow-up. Okay. So with that, I will hand over to Jeff Soule, and we'll move on to the next slide. Thank you.

Thank you, Matt. Good day, everyone. Thank you for joining us for another customer webinar. Initially, I'm going to run through the large enhancements on the road map for version 3.6.3, which we just released last month. You'll see the first 3 lines of the road map that we added 3 large enhancements in this release. Time-based preferred host failback is the top line, first large enhancement. Your preferred host is generally going to offer you the lowest latency or a route that is the lowest cost to connect to. So when preferred route is not available, you'll define alternative servers and routes to fail over to for resiliency. So prior to 3.6.3, the process to reconnect back to that preferred host when it becomes available was a manual process. And now with 3.6.3, there's a new feature that provides you the ability to automatically fail back to the preferred host when it becomes available at a designated date and time, which you define, which is likely to be obviously after market hours or maybe even over the weekend. I think the most -- I think most of us would agree, the ability to define a designated time to automatically fail back to your preferred host is better than requiring a manual intervention. And after all, the reason you have a preferred host is for one of the benefits I mentioned. So reconnecting back to your preferred host is something that you can now configure to happen automatically. And as soon as I run through the rest of this page, I'm going to have Parivat run through a demo of the new feature for time-based preferred host failback, right? On the second line, we have support for field filtering for a range of fields. Let's face it. Sometimes a record has more fields of data than you need, which consumes extra processing overhead and bandwidth to disseminate. So field filtering allows you to select only the fields of a record that are important to you, and then simply drop the rest on the floor. So you can select the list of fields you require by adding each in every field identifier, or FID, to the list. This, as many of you know, can be a very arduous process. So we came up with this new feature that allows you to designate a range of fields within the full record by using a hyphen or a dash between the first and the last FID of a particular range you want to use. So the benefit is simply the ability to define a range or filter a range of fields using this hyphen rather than typing in each individual field. So it will reduce time and overhead it takes to designate each -- the list of full fields that you want included, right? Number three here is the evaluation of serverless in the cloud. And although we began offering Real-Time Optimized data feed in 2018, there have been many, many other use cases and many, many other years before we got involved in the cloud with customers that had different use cases and different requirements and different infrastructures. We have not been using serverless, but we had a request to run the Real-Time Connector in a serverless environment, which is called Fargate at AWS. We have completed the evaluation at this point, and the ability to run RTC on Fargate is promising. But there's still a couple of outstanding issues to be addressed before we can actually qualify it and offer categories -- Category A support, which is our highest level of support. So the throughput has improved significantly. That's the main thing that we're looking for. But there's still -- we're still seeing some inconsistencies. Just so you have a little bit of an idea, so there's some performance issues here. We're seeing odd occasion and some dropped connections. So again, once we -- we were working with the Fargate team. And once we are able to address those deficiencies, we will be able to offer a fully qualified category support. And hopefully, that will be by the next time we have another webinar, right? The last line on this table indicates there's a number of small enhancements and bug fixes that are included with each release. The what's new for 3.6.3 is available to download from MyRefinitiv and includes a succinct description of each enhancement, large and small, and the bug fixes. So now I'm going to turn this over to Parivat, and he'll give us a demo of the time-based preferred host failback. Over to you, Parivat.

Thank you, Jeff. Hi, everyone. My name is Parivat Pongbhaesaj, RTDS software developer. Today, I am going to demo the preferred host failback feature, which was introduced -- is the latest version of RTC and ADH 3.6.3. Before we get to the demo, let's go through one slide real quick. Next slide, please. Yes, this feature is specific to the setup where there are multiple hosts within a route, right? In the diagram here, I have host 10 and host 11. And whenever there is a failover, typically, the RTC will attempt to connect to the next host in the host lift, which is host 11 here. This behavior has been there for years. Nothing has changed here. But as Jeff said, this new feature basically allow the RTC to automatically fail back to the preferred host that's on your choice of configuration. And that's kind of the overview. Let's get to the demo. So I'm going to share my screen. So in my setup, I have 2 test servers running on different hosts. The left one is my preferred host; and the right one, up top, is my nonpreferred host. And let me show my RTC configuration [ info ]. So it's pretty simple. I have only one [ route ], which is host SSL. And to enable the new feature, I set enable preferred host to 2. And from my host list, I have 2 hosts configured, 17 and 16. The first line will always be the preferred host right? And for the preferred host failback mechanism, I have 2 choices here, right? The first one, I can specify a specific date and time that I want my RTC to fail back, right? This is configured in conjunct format with the preferred host detection time format on FID parameter. For the item option, right, I can just simply use a time interval, and this time interval will be the time period that my RTC will, theoretically, attempt to fail back to the preferred host. Let me start up my RTC 3.6.3. And so my RTC is up. So it is up. Right now, it's connected to the preferred host. So if I go to the [indiscernible] statistic screen, you can see that the new feature, which is preferred host failback, has been enabled here. And then I set the interval to 30 seconds. And then I'm going to simulate a failover from my RTC -- between my RTC and the preferred host. And so I'm just going to simply [ queue ] my test server running on the preferred host. And as usual, my RTC should failover to the next host in the host list. And so if I look at my rtc.log, I can see that right now, my [ route ] host SSL is connected to a nonpreferred host. Nonpreferred host failback timer has been activated. We attempt to fail back every 30 seconds. And then I'm just going to bring my test server running on the preferred host backup. And within 30 seconds, my RTC should go back to the preferred host. Here we go. So my RTC just fail back to the preferred host. And this conclude my demo for today. Thank you, everyone.

Thanks very much, Parivat. Hopefully, that was quite straightforward to everybody. Again, this was in the 3.6.3 release that came out in December. And the more you play with that, I think the more you'll be able to experience what's going on. We'll move across to polling question, something that we've been thinking about how we can best supply different software, put into the hands of our end community. There's a question on the Slido poll right now. So we update our Real-Time Connector image on Docker Hub quarterly. But is it up to the customer to perform their own security and patches, as in sort of the red hat patches, you have to localize that. So do you use our real-time image Or Real-Time Connector image? Or do you build your own container? And we've got -- I think you can pick from as many of the options as you want. No, you didn't know it was there. No, we're not allowed to do that. We've had some customers that say they're not allowed to get access to Docker Hub from their corporate network. Yes, we do use that, but we build our own specific Docker container. Or yes, we use the container that we download from the Docker Hub, and pretty much that's the one that we roll into production. So those are your 4 options. It might be you do a mix of 1, 2, 3, 4. And so if you have a vote on that, and then we can hopefully somehow see the results. Again, the poll is on the right-hand side of the screen. Or if you're logged in to Slido, then you can see them there as well. All right. We've got a couple of more votes coming in. They're kind of coming in slowly. So we'll give it another few seconds, and then we'll close that poll and we'll have a look at it once it's up on the screen. So can we close that poll and then we can see the results to see what they look like?

It's [indiscernible] jumping in here. I just want to let you know that we won't be able to show the answers live on the screen, but just wanted to read those out to you. So we've had several votes coming in from this. And the most popular choice, it was actually an equal tie between [ all ] the audience members not knowing it was there and also not being allowed to download the RTC, ADH or ADS containers at work. And then in the last place was using the Refinitiv RTC container to download from the Docker Hub with 7% of the vote. So it was an equal tie really between the 2 answers I just read out at the beginning there.

Thanks for that, [ man ]. And yes, I think that kind of correlates to what we're seeing as well. There's some activity. But we want to make sure we're doing the right things. So if you've got any ideas or any suggestions on that, please put it into the Q&A or reach out to myself or to Jeff directly and let us know what's stopping you from taking advantage of that capability because it's quite powerful and does probably save you time in the long run as well. Okay. Thanks for that. Should we move on to the next section, please? Thank you. Mahesh, I'll hand over to you. Thank you.

Sure. Thank you, Matt. Hello, everyone. I'm Mahesh Bommanayakanahalli. I'm the Development Manager for RTDS. Next slide, please. So typically, we have shared our performance metrics covering the various connectivity protocols like RSSL, RWF, WebSocket, JSON and SSL, full fan-out, how many connections can you make assuming fixed inbound message rate, conflation, the cost of encryption, the snapshot and the regular image retrieval. As we have looked at the last 2 versions, we have added more capabilities. Now there is REST snapshot. We have made some improvements to conflation performance. There is encryption for REST and WebSocket in addition to the RSSL that was always there. We have introduced channel threads, and then we support the RWF over WebSocket in addition to JSON2 over WebSocket. And then we have improved the WebSocket common view performance in the last -- 3.6.1 version, and then there is protocol-specific writer threads. So the new set of tests that we have been doing is, in addition to the previous set of metrics, is accounting for these capabilities. And also, based on the customer feedback, we have limited most of the tests to the 10 gig bandwidth because that seems to be the most common deployment, even though we do see customers moving into 25 Gbps, both on-prem and in the cloud. And also, based on some analysis of the live data on the [ electron ] real-time, we have increased our payload for this testing. Now the image size is 4x what it used to be, and the update is 130 byte. And also, to account for the RTC style of deployment, which is the 2-tier RTC, which is a TCP [ desk solution ] mostly used in the cloud, we are also doing tests with the different watch lists and the different fan-outs than the traditional 100,000 item watch list. Next slide, please. So one of the important things to understand for the RTC is the threading model. We have various ways in which the RTC can be deployed. We have a bank of channel threads, which feed in the messages from the publishers to a set of item threads. Item threads are the place where we do the caching, the conflation [ delay ]. And the writer threads is the one that is interacting with the end applications. That is where the last-mile features, such as compression/encryption, traffic management buffering, all those things, happen. So this is something to remember as we do the performance analysis and also the deployment. This threading model really scales well. And based on your requirements, you can choose different types of threads based on the computer and the bandwidth that is available. Next slide, please. So I touched upon the need for using the larger messages. That's because venues have added more fields, and the granularity of the time stamps have increased. And also, some of the fields have overgrown, and we validated this with the live data captures. So what we see is that there is an impact for both compute and the bandwidth because of this reason. So if we have some previous results based on the 74-byte messages, we see that with the new message sizes, that would be about 70% through compared to the prior one. So this set of slides will show you what is the cost of the bandwidth and what is the cost of the compute so that you can still leverage some of the earlier published results. Next slide, please. Okay. One of the capabilities that the Refinitiv Workspace uses is dynamic field filtering, Jeff touched upon field filtering capability that's been there in the RTDS platform. That is a static field filtering, so that you define the set of fields that is available through a service for all the users of that service. The dynamic view is defined by the client application. So different applications can request different set of fields that still reduces the amount of fields and the data that is needed based upon the application's requirement. And some of the captures we have done, leveraging the best template from Workspace, they used 55 fields, shows that you get 3 fields for a quote update and 5 for a trade update. So that reduces the message size by a factor of 3. Next slide, please. So what this means, as you can see from these 2 slides, is that there is more work to do on the sending side. So if you look at the WebSocket/JSON2-V, that is with the common views, so the throughput -- there is a throughput impact on the sender, the ADS or the RTC. And on the right-hand side, you will see that we made some enhancements for our view processing. So we see like a 50% boost when there is a full commonality. This is 100% commonality, a fan-out of 100. So if you are using Workspace, the version 3.6.1 gives a big boost in performance. Channel threads is another one that we introduced a while back. That's more of a simplification connection management aspect rather than the performance, as you will see at the bottom. So if you use the same number of [ ports ] and -- so there's actually a small drop in the throughput. But we still think this is a better deployment because it helps with the backing upstream and also reduces the connections. Providers may not have capability to take 10, 12 connections per user sometimes based on the configuration. So that's another aspect to consider there. And then the other one that I want to touch upon here is we -- in addition to the JSON2 or WebSocket, we also have the RWF, the binary format, over WebSocket. So that gives you the performance that is closer to the socket performance of the RWF. Next slide, please. So this is just a quick comparison. So the existing RTDS deployment with the multicast [ REST and ADH and then ADS ] as we all know, and the recommended architecture for the TCP desk solution is 2 layers of the RTC. So one of the performance aspects to consider, an ADH just message -- writes the message once on the backbone and that [ leaves its ] throughput. Whereas for an RTC, because of the TCP mesh, it has to write the message multiple times to the fan-out layer depending on the [ interest ] at the distribution level. So that's one aspect to consider. Next slide, please. One of the other questions that we keep hearing is, okay, so the 100,000 item watch list that you use for the benchmark is good, but we have a need for using 1 million items or 2 million items. So what is the impact when we have no commonality or when we have 100% commonality? So these set of slides are showing that there is really no impact for the performance because we have taken the hit with the 100,000 watch list itself with all the data going out of the processor L1, L2, L3 cache. So as you increase the item list -- watch list in the cache, so the only impact is that you need more memory. Other than that, the fan-out and the throughput remains the same. So that's all I had. And if there are questions, I'm happy to answer. Back to you, Matt.

Thanks very much, Mahesh. And also just as a quick aside for those who don't know, Mahesh has been with us for a long time and most recently, third-level support. But he's also taken on responsibility as a development manager now. So Mahesh, I think you're now working 24-hour days rather than the 16 you were doing before?

Something like that, yes. No, [ that's not right ].

I just want to say congratulations. Okay. So we can move on to the next slide. Jeff, I don't think we're going to run through these in any detail. Is there anything you wanted to pull out just for the sake of time? Jeff, if you want to [ take yourself out of mute ].

[indiscernible] Essentially, we don't have a lot of time. A couple of things I think are important. If you can go on to the next slide, just -- actually, I'm just going to hit on Q1, the first 3 items here, right? Cloud-friendly licensing system. Let's face it. We all know, and anybody who's attempting to migrate to the cloud or has already migrated to cloud, we know our existing node-locked licenses with the static host name and IP do not work in cloud deployments. And this is something we've been looking at. We had to push it out to Q1, but we're working on a floating license server with the benefit -- it will basically allow you to take advantage of elasticity within the ephemeral environment within the cloud. So we're expecting to have that done by the end of this quarter. That's what we're looking at. The next item down, the JSON web token for authentication. Authentication and security have become top priorities for anyone moving to the cloud, and we're implementing a new level of authentication for RTO. I'm going to let Luke talk about that, so that saves me a couple of seconds here. And then the other item, the third item here I want to talk about is an open source operating system. Basically, there are strategic advantages provided by moving to open source. In this case, it'd be both for on-prem customers and for customers migrating to the cloud. There's a survey here that was done by the Fintech Open Source Foundation that was just published last month. The link is there. That will be available when you get the docs -- the follow-up docs. It discussed the benefits of open source applications. In this case, they're talking specifically about improvements in time to market and lowering the total cost of ownership by using open source products. It's something we've been asked about from time to time for another operating system. Ubuntu gives us a little bit more flexibility, which I'll get to when we discuss the DACS piece later. But that's the direction we're going to use to be able to qualify the Ubuntu operating system at the end of Q1. So that's it for me at the moment, Matt. We will try to preserve some time here. Thank you, everyone. And if you have questions, please send me questions. Thank you.

Thanks very much, Jeff. Let's move on to the next slide. And just while we're doing that, I know it's quite a few questions have come in around the failback. We'll endeavor to get to those at the end. If not, maybe do a write-up because there's some really good points around kind of the level of detail that you guys need to know. So let's move on to the next section that Luke will be presenting. I'll hand the microphone over to Luke, Luke O'Sullivan. Thank you.

Lovely. Thanks very much, Matt. Thanks, Jeff. So my name is Luke O'Sullivan. I'm Product Manager for Real-Time Optimized, and today I'm going to be talking about Real-Time Optimized, some enhances we've got coming along and kind of how they specifically relate to the Customer Identity and Access Management platforms, bit of a mouthful, called CIAM, coming through for this year. Before we do that, let's see, we want to just touch on some highlights from last year for what we've got through for Real-Time Optimized. So we've got support of consumer warm standby -- we've launched 2 additional AWS regions for Real-Time Optimized. We've got Tokyo and Frankfurt. That brings our global coverage now to 6 centers, all fully redundant with 2 availability zones there. And we've also launched a live life service for Real-Time Optimized over our last mile offering delivery direct. But what really here to talk about today is what we've got coming up for 2023 and the changes to the [ SIEM ] platform. So if you go to the next slide, please. So there was a presentation or a webinar in November last year by our colleague [indiscernible] around about an hour going around the background for changes to [ SIEM ] the reasons we're doing it and what it means for a variety Refinitiv products. I think the highlights are highly resilient cloud-based platform and then the seamless updates of kind of security and product features. If you weren't able to make that webinar, we've got a link for it here, who is really good. It goes into good detail about the background for it and the technical implications for various products as well. We don't have time today to talk about the technical side. What we actually want to focus on is the kind of product features and enhancements that are coming alongside that. So if we can go to the next slide, please. So along with the change to the SIEM platform, the Real-Time Optimized, we're actually moving the product or moving it in step with the launch of Refinitiv platform administration tool. So this is going to give customers the ability to do a lot more themselves, which they currently can't. So we've been taking feedback from clients for a while, right? We're slow to get IDs, ready, support of simultaneous logins isn't as good as it could be. Customers don't have a lot of view of what's going on with her ID once they use them. So we're actually building that into the platform administration tool. So from this, customers are going to be able to create their own IDs, they're going to be able to entitle them as well. So we're looking forward to seeing the reduction in times it gets customers to get into production with them. We are reducing the complexity. We think the customers who are running large platforms that currently need lots and lots of IDs to support it. We're going to reduce those down to a few IDs as possible. And in the Service Insight dashboard part that we're releasing as well you get a view of the status of the service Real-Time Optimized as well as a view of what your IDs are doing kind of right now. So we're looking to move to this model late Q1 this year. As said [indiscernible] webinar goes into details around timelines for those as well. Please do watch it. But what I'm going to do next is give a walk-through of the platform [indiscernible] too to give you an idea of sort of speed it is to create an ID for yourself and then a view from the service insight dashboard. So I'll need to share my screen in a second. There you go, right. So hopefully, this is sharing -- hopefully, this is sharing the platform administration tool? So first thing to mention is there are a couple of cosmetic changes, which are going to come through as well before it goes into production. And I'll point those out when we get to them. So this is the landing page for a customer. So I'm using an Refinitiv account we've got set up for our technical specialists. So what I do is talk through how to raise an ID. So you do this through application management click through here. I've already set up 1 set of IDs for our team when customers move in here, this is going to be -- this part will be blank. The first thing you need to do is to create an application. So an application being that the actual app that is going to make a direct amount of Real-Time Optimized. So if you've got an enterprise-wide platform, a lot of different apps there, you don't do this for all of those apps. You do it once for the app that's going to draw in the feed. You should always give it a name which is relevant for yourself, so I'm going to call this webinar RTDS. There will be a few certification questions to say what is the application going to be used for? This is one of the things that's going to be changed. We're kind of working on these, but you get the idea is you have an enterprise-wide platform. Do you have an entitlement platform of your own, if so, what is it? And what kind of use cases are you -- using a real-time for? There will be full training materials that we provide here as well. So this isn't a training session, just given a quick overview. But once you've done this, you click add application. This is a worrying bits. And there we go. So we see now you've got a second application showing here, and it's underneath this application where you'll create your ID or IDs. The reason you can create and the IDs will be kind of linked to what we call a service accounts. You can create multiple service accounts here. The reason being, if you do have RTDS to the platform, you might have a production environment, a UAT environment, a disaster recovery environment. And so you can create if you needed multiple instances or just one. So to do this quite simple, click on create service accounts. We would enter the name here, I will call it webinar RTDS production. This looks a bit stupid right now because it's a drop down of one entry. As Jeff mentioned earlier, we're introducing a second authentication system for Real-Time Optimized as well, which will be JWT. So when that's available later this year as a customer, you'll get the choice of having client secret, which is a password or JWT, at the moment, it's password only. So when you click on add service accounts. get a success message, which is good. And what you see here is a service ID, which is unique. So the service account name that you give can be used -- multiple customers can give exactly the same service account name doesn't matter. You'll get a unique service ID. And then you see the password. It's very important to make a copy of that password because once you click close, it goes away and you don't see it again. But it's very easy to reset a password in this tool as well. You're just going here, click reset and [ show ] password. You've got the same service ID and a different password. So that's kind of how quick it takes to create an ID. This IP can't do anything at the moment, though, because it hasn't got any permissions against it. So the next part is how do you get the data on the ID. You do this from managed licenses. So when you click on managed licenses, this will show you the available licenses that you've got agreements with -- Refinitiv or third-party exchanges and specialist state providers that you can pick from. So if you click on managed license, get 2 options here, general license and real-time license. General license will show every license for any platform enabled products that you have at the moment from a real-time point of view, it's only Real-Time Optimized, but other products will come on board. So what the platform team has done have introduced a wizard for real-time licenses -- and again, as other products come on, there'll be visits for those various products. So we use real-time licenses here. And this prompts you to pick from at least 3 sections and potentially 4. So the first section is the Stream ID. This relates to the product you've bought. So Real-Time Optimized is the only product you've bought, then you'll only see 1 stream ID. So that's what we take there. Watch list licenses is basically what size watch list have you taken? In this demo because it's an internal account, there's a variety of different watch lists. There would only be what you signed for that would appear in there. These next 2 parts or other parts where there's a cosmetic change. So everything is going to be moving to a drop-down method at the moment. Unfortunately, in the version, I'm demoing here, you have to start typing, but this would be the data license such as your exchange-traded instruments or over-the-counter type license. So you'd add those is not very good with having to type there. Unfortunately, that's why we're changing it before it goes out into the field as a drop-down. And then if you take any exchange data and specialist data, then that would appear in there because this is an in-house account, we've kind of got a specialist in-house exchange code that we use the principle is the same as it was for those other parts. So we then add those licenses, and we're hoping to see a green success bar. There we go. So that's good. So these licenses are now pending assignment. So it takes a couple of minutes for those licenses to kind of assign through the platform part and then around 10, 15 minutes to get all the way through the system. So what that's taken, what, maybe 5 minutes or so to get through this part and then another 15 minutes or so to get through the system. So within about 20 minutes we're expecting customers to have a usable ID for Real-Time Optimized. So there we go. We can see those licenses are already assigned now. So that's kind of one of the enhancements there about getting through the speed of production, as I say as well, this ID can be used simultaneously, right? So if you're running a resilient RTDS platform, you wouldn't need necessarily to have 2 IDs. You could just commission 1 ID once and use it in both sides of your platform. So that kind of reduces the risk we see at the moment where you have multiple IDs being entitled individually, we can kind of remove that risk as well. So next part we want to look at very quickly is the Service Insight dashboard. So this is where you see the health of the service and what your IDs are doing. There's a lot of white screen on the top half at the moment because we've got a full roadmap of features as well, but these are the features we'll be going into production with. It shows you the 6 regions that we're in and the status of them and this is a production environment as well. So this isn't a pre-prod environment or any CIAM data this is live, what we have now. We have, as you know, hopefully multiple endpoints for any sensor. So a couple of customer managed 1 Refinitiv managed and then 3 tiers as well. So by kicking on here, you can open this up and see exactly what's going on. You can click on the map, it opens it there as well. So if there was an incident, for instance, in customer managed 1 small tier for Frankfurt, this would be either orange or red in this part, but in the map it would appear orange just to say some things up -- it would only appear red if the [ insight sent ] this down. So you could click on there, say, okay, customer managed 1, we've got a problem. It's not a big deal on medium-tier customer, medium-tier Refinitiv managed. So it gives a lot better visibility of exactly what's going on. And this part -- this kind of top half of screen is common for all customers. The lower half with the service account status, that's where you would see exactly what's going on with your own IDs. So we've got a couple of IDs that we've set up and connected to the environment as well or an ID that we set up. You can see us making 2 simultaneous amounts, 1 with about 5,000 instruments, 1 was about 1 active instrument and just for the benefit of those on smaller screens, I'll try and expand that. So hopefully, that's showing nicely. So this just gives you the detail of what they're called. You can see this is a unique [ legal ] name we've given it. It means something to me. So I know what's up. Here, we've got the service ID, random string of letters and numbers. What we see under the watch list part is capacity is the watch list that we would have assigned. So it's a 50,000 watch list. We can see which -- how much each amount is using and then we see a percentage of the overall capacity of what you're at. So you'll be able to see there if your usage is going up and up and getting towards kind of 100% at the moment, customers are a bit blind. So that -- this gives you the ability to see kind of in real time what's happening. We haven't got enough decimal points, unfortunately. So it's rounding down. So if you do have 1 instrument and you've got a 50,000 capacity, it shows a 0, but that's just the way that the rounding down has worked. Then further to the right, it shows detail here on which set of infrastructure, any ID is connected to. So you can see that we have 1 connection to customer manage 1, once a customer manage 2, one is in the large tier because it's a web socket connection. So 50,000 instruments is a large web socket connection, 1 in the medium tier because it's RSSL type connection. And they're both -- or 1 has gone to U.S. East on A side and 1 to EU Central 1B side. That kind of also shows supportability of IDs. You can use them in any of the available Real-Time Optimized centers you want. So these are the features we're kind of going live with. What we've also got coming along is at the moment, you want to see service alerts, unfortunately, this is going to take you to my Refinitiv page we show active service alerts and maintenance alerts. We're going to embed those into this page, see that have to jump off. Same with help and support. This is going to take you to contact us kind of web form to raise a ticket. We're building a chat agent into this green as well, where directly from the screen, you can start talking to somebody. The good thing is this page has a log of your account number. So if you raise a ticket through the chat agent, you don't have to worry about scrabbling around for your account number anymore. It's already going to be embedded in the ticket. You've got easy access to the service IDs that you might be talking about through here as well. So it should make for a much quicker, simpler process for raising tickets as well. We're going to look to show historical maximum usage by day as a graph and also be able to dump that as a number of Rics. So over the last 3 weeks, what's my max Ric usage per day. That's quite important to customers. And embed product change notifications in here as well. So if you're looking at the screen, you log in, we've got a change notification. It will appear as a banner. You have to read it before you can shut the banner down. So it kind of avoids missing product change notifications as we know, unfortunately, not everybody subscribes to them. So in the interest of time and when there, we've got many more features to come through for these. And obviously, we're very interested to hear your feedback or what else you would like us to add. So my contact details are in the webinar. So please do get in touch. And that concludes my demo. Thank you.

Great job, thanks very much, Luke. A lot to pack into 20 minutes or so there. I appreciate it, there's probably a lot of questions, as Luke mentioned. We're going to come up with a lot more material on that. There's going to be tutorials, documentation, walk-throughs, separate sessions. There's a bunch of questions that have popped in around that as well. So we'll aim to get to a couple of those. Just before we do move to Tirthankar, I did just want to address one of the questions that Chris brought on before it gets upvoted anymore. Do I understand correctly, multicast is no longer the recommended architecture for RTDS. Categorically, I can say that is not the case. Apologies if that came over. It might have been as we're talking around what we're doing in the cloud purely unicast at the moment, as we talked about before. And for some customers, they're looking to simplifying their network infrastructure and actually looking to going unicast on-prem. We don't plan to drop any of that support. And indeed, it's critical to what we do internally as well as to many of our other customers. So I just did want to nip that in the bud before it got a bit of a head of steam on the Slido poll. Okay. I will now pass over to Tirthankar, who's going to talk about some API strategy updates with a help of a few others. Tirthankar over to you, please.

Thank you very much, Matt. So my name is Tirthankar Bhaumik, I'm the Product Manager on the real-time APIs. As most of you will be aware, we are going to be end of lifing the legacy APIs, SFC, RFA and support for Market Feed and SSL on RTDS. The end-of-life notice that this will go out in March 2023. However, RTDS, on the other hand, are also planning to roll out a rolling obsolescence program. So I think it is very important for us to understand how these 2 end of life -- the end of life on one hand and the rolling obsolescence on the other hand will work together. So to start this off, I'd like to invite Jeff to talk us through the RTDS rolling obsolescence first, and then I will overlay the Market Feed, SSL end of life on top of that. Jeff?

Sure. All right. Thank you, Tirthankar. Some customers are aware of this because I've talked to some over the past 6 or 8 months, whatever it's been. But basically, what we're going to do, we're supporting many, many versions of software out there right now. So we're announcing a rolling obsolescence plan to end support for older versions of RTDS. That will include ADH and ADS and ADS POP and eventually will even include RTC, but not initially. The plan goes into effect the 1st of October of this year. And at that time, we'll only be supporting versions 3.5 and higher. So to make it easier to keep track of what's supported -- what releases are supported, we'll offer an ongoing support for the current version and 2 previous versions of RTDS software or T-minus 2 as Matt likes to say. So it's probably easier -- let me run through an example. So we anticipate the next version of RTDS that we're going to launch at the end of March would be 3.7, right? So at that time, you're going to also receive a 6-month notice that the current and 2 previous versions will be supported as of October 1. So that means as of October 1, we'll continue to offer support for version 3.5, 3.6, and then 3.7. And again, the rolling obsolescence plan will mean when we get into next year -- October of next year, then we'll deprecate 3.5 and go with 3.6, 3.7, 3.8 right? The objectives of the plan are really simple. We're going to provide you a reasonable shelf life for RTDS software of approximately 3 years. We're positioning you to take advantage of newer features and newer capabilities and it allows us to continue to innovate and add value to the platform by focusing on newer software releases than supporting older releases. So that's it for now for me. If there's questions, obviously, we can address those, but I'll pass this back to Tirthankar. Thank you.

Thank you very much, Jeff. So now I will overlay the end-of-life changes -- the legacy Market Feed end-of-life changes on top of Jeff's rolling obsolescence plan. Next slide, please. So if we just run through the milestones sequentially. So Milestone 1, Quarter 1, 2023, which is essentially going to be March 2023, we send out the end-of-life notice for Market Feed -- for support for Market Feed and SSL on RTDS and end of support notification for the legacy APIs, RFA and SFC. There will be parts of LPC, which is the OMM to Market Feed conversion that will be end of lifed as well. So we send out that notification in March 2023. And then -- so you will be given in that notification 3 years to migrate your applications from legacy APIs to our strategic APIs. That 3 years comes to an end in around Quarter 1, 2026, probably February 2026, which is Milestone 2. So at Milestone 2, February 2026, the legacy API's RFA 7.x and SFC will become unsupported. However, these APIs will continue to work. Because for another 30 months, there will be a version of RTDS. There will always be a version of RTDS for the next 30 months that supports Market Feed and SSL. So at that Milestone 2, there will be 3 versions of RTDS, 3.7, 3.8 and 3.9 that support Market Feed. Time line 3, when we release RTDS 4.0, that no longer supports Market Feed, but you still have 3.8 and 3.9 supporting Market Feed. Milestone 4, RTDS 4.1 is released. Now we've got 2 versions of RTDS that don't support Market Feed, but 3.9 continues to support. And then at Milestone 5, 4.2 is released. Now we have 3 fully supported versions of RTDS that support -- that do not support Market Feed, and there is no version of RTDS that supports Market Feed. So at Milestone 5, there is no version of RTDS that supports Market Feed so at that milestone, your APIs -- the legacy APIs will now stop working. The essential takeaway from this is this, you will initially be given 3 years to migrate. If you haven't been able to complete your migration by then, you still have another 30 months to complete your migration. So all in all, what you have is just under 6 years to complete your migration. It is very important we understand this because it may have ramifications for you. So I think we have a polling question after this.

Yes, we do. We'll leave this polling question open for a while. We're obviously not going to read the results. It's going to be down to each individual, but it will allow you to understand what you want to get out of this. Hopefully, the last couple of slides and then when you have the presentation, you either understand what the implications are now when you're in control or you might want to digest it or no, actually, can you please contact me, which Tirthankar is very happy to kind of sit down one-on-one and walk through what those plans mean in a little bit more detail and the implications around that. So we'll leave that poll to run in the background. We won't close it until the end of the webinar. And then for those that have said, no, please contact me, absolutely, we can do that. If I just have a quick look where we are at the moment. It's probably about 60% get the idea, 40% don't. So it sounds like Tirthankar you're going to be on the phone a lot. But let's see how do they digest the results. So let's move on to the next slide then, please, Tirthankar.