MarkitSERV executives sat down with WatersTechnology to preview its soon-to-be-launched TradeServ platform, which will be rolled out even as the firm is on the market to be sold.
In May, after IHS Markit bought data specialist Ipreo, the company also announced its intention to divest MarkitSERV, a platform which has been described as the nerve center of the post-trade market in derivatives, given that it handles 130,000 derivatives processing actions per day.
Traditionally, when a company is on the auction block it runs lean, it shines itself up and is wary to take risks. Why dump a ton of money into innovation when the future is so murky? With MarkitSERV, IHS Markit is taking the opposite approach. On September 10, the company will launch TradeServ, a cloud-based platform that will eventually house its other platforms, including MarkitWire, Markit Trade Manager (MTM) and DSMatch. The platform-as-a-service (PaaS) offering is about four years in the making, and despite the potential for a future sale in the works, the way forward for MarkitSERV—whether it remains with IHS Markit for the near-term or is sold to someone else in the coming months—will be in the cloud.
“We have always innovated—whether people knew it or not, we just did it,” Bradford Levy, CEO of MarkitSERV, tells WatersTechnology. “When you’re selling, there’s even more scrutiny on you, which is good. While the scrutiny is higher, we have to be even more clear with what we’re doing and more committed to doing it right, just because people are watching us. I love the fact that we’ve said we’re selling. Obviously, it creates some stress, but it just makes us that much more watched and therefore we have to be that much better. And I’ve seen us rise to the occasion as a franchise so many times that I know we can do it.”
The first rollout of TradeServ will begin on September 10 and will focus on foreign exchange (FX) for non-deliverable forwards (NDFs). As a conduit to LCH, MarkitSERV handles the bulk of cleared NDF trades, and has recently been averaging processing volumes of just under 120,000 per month. The second phase will bring in FX options, which is expected to be launched in 2019.
The third phase will bring in credit. That launch date is targeted for the first half of 2019—and, loosely, for February—but that will depend, in part, on the Depository Trust & Clearing Corp. (DTCC). February is when the settlement specialist plans on going live with its Trade Information Warehouse (TIW) using distributed-ledger technology (DLT). TradeServ will connect with TIW, but MarkitSERV can’t go live with credit on the platform until the distributed ledger is up and running, though the launch will also require that MarkitSERV is up to speed as well as industry participants.
“I’d argue that [TradeServ] is not a step forward from DSMatch and it’s not a leapfrog—it’s simply not comparable,” Levy says. “TradeServ is a leapfrog over MarkitWire; MarkitWire is a monolith and TradeServ is our future PaaS offering.”
The purpose of TradeServ, which is using Amazon Web Services (AWS) to host its cloud functionality, is to allow customers better access to their data to enable improved analytics, easier integrations and a customized user interface (UI) through automation. Easy enough said, harder still to deliver.
At its core, MarkitSERV has two matching platforms: DSMatch for credit and FX; MarkitWire for rates and equities, which is a monolith that is plumbed into banks and clearinghouses across the globe. Markit Trade Manager (MTM) is specifically architected for the buy side, replete with its own dedicated interface. There is also its FX trade processing service, Dealhub, and its connectivity service, Trade STP, short for straight-through processing. This forms a network-of-networks; combined, the company covers everything from confirmation and routing, through to clearing, reporting and more.
TradeServ, which incorporates RESTful application programming interfaces (APIs), will eventually house all of MarkitSERV’s offerings, though that end-state is well down the road. Rather than do a complete relocation of the MarkitWire platform into TradeServ, the company is currently componentizing MarkitWire’s various pieces so that they can be more easily fed into TradeServ over time—a process that could take up to five years, Levy estimates.
“We are not going to do a lift-and-shift from MarkitWire to TradeServ,” Levy says. “Over time, you pick off the pieces and have a kernel of what you started with, and you never really lose old MarkitWire—that just becomes its own application living within a PaaS world.”
The DSMatch replacement is expected to go live in the first half of 2019, with a rough launch date penciled in for February. DSMatch was built on a COBOL-powered mainframe and is decades old, hence the need for re-platforming. TradeServ will interface with the new distributed-ledger-based TIW. Once that platform is live and in production, MarkitSERV will decommission DSMatch.
Improvements to MTM will include a streamlined trade-break resolution process, where, with the click of a button, a chat room pops up, it brings in the trade—as well as the parties that can resolve the trade—into a Symphony-like environment, and from there the entities hammer out the details at which point MarkitSERV and client systems that are integrated are automatically updated. This allows users to cut out the hodgepodge workflow of phone, email and disconnected apps that don’t provide context around the trade.
TradeServ will also allow for the firm to be more agile in responding to changes in the marketplace and allow for more experimentation, says Frank Tarsillo, managing director for architecture at IHS Markit. As of mid-August, two buy-side firms and two sell-side firms were using TradeServ in pilot form.
“This environment allows development teams to spin up, literally, their own entire stacks, with a hundred microservices, in minutes. Because of that luxury, they are embracing testing,” he says. “So they’ll spin up the entire TradeServ environment—click, it shoves out 100 microservices and it’s their own little world. That can be one developer—one tester—managing and running against one slice of that network. So there are 20 different environments that teams are testing off of for different aspects of the system. And that’s fantastic.”
The most immediate change that users will notice on Day One will take place in the spheres of the platform’s UI and workflow. It supports federated single sign-on, click-and-drag functionality, elastic search, and the ability to customize the information to each individual user’s needs. The default set of columns is six, but users can add or remove columns and can move those columns left or right, as fits their needs.
So, for example, a user can create a view to see open trades for a particular client, another for unconfirmed trades against another client, another for all open trades, or just have those three particular columns in one view.
Users can see trade breaks and the platform lets them see the best match for a particular trade, using a percentage as to how sure the MarkitSERV algorithms are to create a match. So, one match is listed at 80 percent confidence, two others at 70 percent, and so on, decreasing as confidence lessens. Users can click on those trades to see where the differences are.
“Every trade that comes through the system, we have to have a cache of all the trades so that for every trade we can figure out what their closest match is,” Tarsillo says. “So it’s scanning thousands and thousands of trades every time and coming up with the top 50 or 100 trades for each one of those activities. It’s very hard to maintain that and scale that effectively across the network, and that’s one of the benefits for the platform—the new matching system is scalable.”
Since this platform is designed to push MarkitSERV into the future, there will be continued rollouts and enhancements, such as consent for novations and in the novation workflow, overall.
“There’s still a decent amount of functionality that we need to build and then obviously test that,” Levy says.
Article continues after box.
Project Voltron: From Monolith to Microservices
The MarkitWire stack is big and complicated, with over 20 years of development and IP underpinning it. What started as a confirmation system now includes clearing and reporting, and MarkitSERV has put a lot of code into the monolith just to get the reporting piece completed—about 30 to 40 percent of MarkitWire code is for that, Levy estimates. The system had grown, through acquisition and development, to the point where it was unwieldy.
“We’ve been called plumbers in suits and I don’t accept that—we’re both electricians and plumbers,” says Levy, partially joking, but also with some seriousness. “We’re not just the flush, we’re also the connectivity. We are liquidity. If you don’t know your risk as a bank, you’re not trading, and you’re certainly not trading aggressively. So the moment you know you’re good, you can then make your market for your next trade. And we allow people to know they’re good immediately, and then to get it through their risk overnight. We used to be thought of as just the overnight-batch-guys, but with clearing and real-time flows, we are now plumbers and electricians.”
MarkitSERV started to see that the age of monolithic hardware and platforms was coming to an end, thanks to the cloud and through fintech disruption. The way forward was away from on-premises solutions toward PaaS, even if back in 2014, some of their clients didn’t quite realize that just yet.
The idea for TradeServ came about four years ago in response to this, and its codename was inspired by a popular 1980s cartoon—Voltron. Broadly, Voltron is a giant robot comprised of five individual components—in this case, flying robot lions—that can fight both as individual machines but can also combine into one super flying robot that fights villains. What’s technology without a bit of nerdom?
MarkitSERV is not going to throw the baby out with the bathwater. True to its original codename, the vendor is peeling off those different pieces to create, say, a standalone reporting service that you could add into TradeServ without breaking any of the clearing or matching flows. Levy says that this process could take five years to complete and the next 24 months will be a full-scale effort to chip away and containerize those pieces.
“We industrialized our platform for a world that was going to be faster and have more volume. That was our focus from [about 2012]—industrialization and scale,” Levy recalls. “Then, by 2014 and 2015, we started to develop a view that we both needed a brand-new platform that was cloud-friendly or PaaS, that [could offer] microservices and containerization. …But the world doesn’t go modular and small quickly.”
The move toward PaaS was also further pushed forward by the DTCC’s decision to embrace DLT. MarkitSERV wanted to take DSMatch in-house so that it was sitting in their world and, thus, they could better control its development. This would also help to bolster the idea that bringing the other various platforms under the MarkitSERV umbrella would be better served if they were brought onto a unified platform.
“The end state is what’s quite interesting here,” Tarsillo says. “TradeServ was never about replacing DSMatch—that’s just part of what it’s going to do. It was about building something that could not only replace DSMatch but that could incorporate all the other assets that we had over time… it’s the fabric of the platform that’s being built that lays the groundwork for everything else we’re going to do moving forward.”
An Analytics Play
So what will future benefits entail? At present, MarkitSERV is focused on getting through the next steps to enable TradeServ’s future state. Currently, MarkitWire and MTM are being componentized so that they can eventually be “snapped” into TradeServ as an application—or a tab—inside of the larger TradeServ platform. Through a window in TradeServ, users will be able to bounce between the various MarkitSERV offerings should they have multiple needs.
“The idea is that you can’t actually evolve these things into one without making them similar technologies that are compatible,” Tarsillo says. “By thinning out MarkitWire over the same time that we were building TradeServ out, we knew these things would eventually be able to join up in the end.”
This process will involve moving the MarkitWire and MTM UIs into the TradeServ glass so that a user doesn’t need to have multiple screens running. The backend services of MarkitWire—which includes over 20 years of IP development—will eventually become pieces in the TradeServ environment, Tarsillo says.
The company has yet to decide whether MarkitWire or MTM will be first to be aligned with the TradeServ platform. MTM, Tarsillo says, requires “a little bit of refactoring on the front-end, but the back-end would be relatively easy,” while MarkitWire will require more work on the back-end “but the UI front-end is more easily snapped into this container.”
Additionally, while users will immediately be able to customize their views, in the future they’ll also be able to create templates that can be shared across the group to improve workflow. Also, as new regulations come down the pike, or as current regulations are amended—for instance, a new clearinghouse gets approved, or there’s a new product, a new index or a new currency pair being cleared, or some data update—those changes can be made almost immediately and across users, rather than today, where one feature change requires dozens of regression tests across numerous components.
Perhaps most interestingly for the future, TradeServ could help MarkitSERV to offer a robust data analytics offering, Tarsillo says.
“We store all of the client’s transactional data today—it’s all there sitting in our world. What does the customer want? They want a copy of that data in their world. Why do they want a copy of that data in their world? They want it so they can perform analytics, scrubbing, whatever it is. This is high-compute that’s required on the customer side,” he says. “Well, we’re all moving to the cloud and the cloud gives some general and physical advantages. Wouldn’t it be interesting if we could segment, in the cloud, a safe space or a true sandbox for our customers to come into our environment in a secure setting, and query and look at the data in our environment directly?”
Essentially, MarkitSERV would provide the analytics interface to the client’s transactional data. This way, instead of the content being exported out to the customer, the customer would go into TradeServ and use the platform’s logic and compute power to slice-and-dice the information in a secure, client-only sandbox.
“The customer says ‘I want to perform analytics on my data.’ I’m holding 20 years of their data. Instead of exporting the 20 years of data and doing the reconciliation, we’ll give you a safe space in our world, come into our world, here’s a bunch of APIs and ways you can access the data, we’ll give you the compute—you can even bring in data to run against that dataset—you’re optimizing the ability to actually compute information locally, versus bringing all that data down into your world.”
Tarsillo is quick to point out that this is not yet an offering and that this would come well down the line, but it also highlights why this move toward PaaS is so vital. In today’s environment, the data—and the ability to offer services around analyzing that data—is becoming increasingly valuable as end users want to be able to dig deeper into the data without making a massive internal investment in technology.
Regardless of whether MarkitSERV will be acquired in the near future, or if MarkitSERV, itself, acquires another firm, the idea will be that TradeServ will house any new offering going forward, so as to streamline its offering and allow it to move into new business arenas.
“The whole purpose of this platform is that you adhere to it as you move forward,” Tarsillo says. “So if we acquired a new technology stack, I don’t see a difficulty in morphing it into this new platform.”
Additional reporting by James Rundle.
Blackstone's CTO talks about the firm's cloud strategy and looks at some of the lessons learned as they've migrated systems to the cloud.Subscribe to Weekly Wrap emails