Front-office trading platforms are increasingly getting cloud makeovers. The same is true for risk systems sitting in the middle office. The next frontier for cloud evolution would logically be post-trade and the back office. But the back office is an area that is notoriously underfunded and contains a hodgepodge of legacy systems that connect to myriad different applications—whether that’s data coming into the firm, or data moving from the front and middle offices into the back office, and vice versa.

However, as more banks and asset managers embrace the cloud and want tools delivered as a service or as a managed service, more vendors are responding to demand in the post-trade space to help customers figure out where they should focus their attention as they migrate systems to the cloud.

Firms could start, for example, with position management, says Danny Green, head of international post-trade at Broadridge, as this is an area where multiple systems are performing the same function. “In theory, you could deliver a general position management component, and then ultimately switch it off from all of the multiple systems,” he says. “By doing that, you get to have a global position management capability quite quickly. So instead of replacing the entire system, you start with replacing position management, but everywhere.”

That way, firms can have visibility of global positions in real time, and provide that data via APIs from the back office to the front office. “That would be a function you could deliver as a single component, for example. That then shrinks the overall footprint of your legacy systems and gets you on that journey of slowly replacing them,” Green says.

James Marsden, managing director and head of post-trade business for Asia-Pacific at Broadridge, says it’s easier to put something new in the cloud rather than to migrate a legacy platform to the cloud.

“Sometimes in a legacy platform, the code has grown over 20 or 30 years, and nobody quite knows what it does. But when you implement a new platform, or a new component—like position management, for example—we can implement that as a cloud-enabled component. And it doesn’t have to be everything in one shot,” he says. He recommends finding areas that logically lend themselves to tools that don’t have so much coding drama underneath.

Green says Broadridge has been looking at transaction capture, a middle-office function, since its acquisition of Itiviti. If firms put a layer between the front office and all their post-trade systems by looking first at the middle office, they could improve how they send trade confirmations to clients, and how they communicate generally with clients, he says.

“We’ve been doing a lot of studies of that kind of front-to-back relationship, and that whole transaction-capture, middle-office piece is another good place to start,” he says.

The key, Green says, is to plan carefully before deciding on any innovation program. “What does the future look like for you? That could include things like data, the use of APIs and other technologies such as cloud and distributed-ledger technology (DLT). Once you’ve got the target operating model of what you want to achieve, now let’s work with you to create a roadmap of how you can achieve that,” he says.

The API play

Many banks’ core systems reside in the back office, making ripping out and replacing those systems a nightmare.

Gurvinder Singh, CEO at New York-based trading, risk, reporting, and data management solutions provider Indus Valley Partners, says that, where possible, firms should look to lift-and-shift monolithic applications from on-premises to the cloud. From there, the key is to re-architecture applications and services to a microservices model so that they can more easily be transitioned, should the need arise, in the future.

“The next stage [after the lift-and-shift] is to start carving services out that make sense, while preserving legacy monolith cores where there are no functional or performance challenges,” he says. “This is the design pattern that has been successfully implemented by many enterprise B2B firms, and is the way to go for all.”

These systems have been built over many decades, with some still running on the Cobol programming language.

“They’re older, they’ve got a lot of logic and nuances that are not as easily migratable to cloud infrastructures,” says Neelesh Prabhu, managing director of architecture and enterprise services in information technology at the Depository Trust & Clearing Corp. (DTCC).

This means that firms approach these modernization efforts incrementally, so there won’t be a big-bang approach to innovation in the space. Prabhu says, though, that it’s relatively straightforward to move systems that sit on the edge of the overall IT ecosystem to the cloud.

“That is the web front ends, and the systems of engagements that banks and larger financial institutions have built. Those are relatively modern as they’ve been built in the last 10 to 15 years, and can be easily adapted to the cloud,” Prabhu says.

This is where APIs come in—provided they’re done right. With APIs, banks are moving small processes/pieces to the cloud, and in doing so, de-risking the programs in question.

“On the front end, there is heavy migration. On data, there is a lot of interest and migration. And on the core systems side, there is migration, but firms are choosing to do it in a way that’s mindful of the risk that moving some of these systems to the cloud may bring to them,” Prabhu says.

He says APIs provide the ability for firms to connect the logic and the functionality provided by a particular system with other systems, but at the same time, lets the teams hide the internal details of how those functionalities are implemented.

Say there’s a system built on mainframe technology. The first thing to do is build an API layer around that system to create an endpoint for all the other systems connecting to it. Once that’s done, the firm can replace the internal technology with a more modern system.

“It’s the idea of using the API as a construct of encapsulation and the cloud to bring functionality quickly,” he says. But the key to these platform conversions is for both the business and technology teams to work together. The design of the API needs to make sense in the business context.

“As these systems talk to each other—it’s not just one connectivity point, but that the structure is built with business understanding that they can stand the test of time,” Prabhu says. “The structure you’re putting in place is foundational to future connectivity points which could exist or come into play.”

Born free

Innovation in the capital markets is often cyclical. Pre-2008, banks were all about building proprietary systems; after the financial crisis, because of a flood of new regulatory demands, banks cut IT staff to the bone and leaned heavily on third-party providers to lower costs and improve margins.

The idea of leaning on a major public cloud provider like Amazon Web Services (AWS), Google Cloud, Microsoft Azure or IBM Cloud for key trading and data management needs was dismissed on sight. But slowly, banks—and even asset managers—have begun to consider cloud. New regulations led to firms having to suck in and store increasingly larger amounts of data. At the same time, new datasets became available as, vitally, the ability to store and run compute on massive datasets became more viable as public cloud providers made these services more cost-effective and improved time to market on new tools.

This gave birth to the fields of alternative data and software-as-a-service models. More data and the availability of tools to analyze data—and, thus, find previously unforeseen correlations or areas of risk or productivity enhancement—led to firms wanting not only more data, but they wanted context wrapped around that data.

This is a major reason why firms want to modernize their post-trade processes: It provides more and better-structured data from which to derive insights, rather than leaning on creaky legacy platforms. It provides the potential to deliver alpha and reduce risk.

As more vendors look to shift their legacy platforms to the cloud, several startups have come to market looking to jump ahead of stalwart vendors because their tools are born in the cloud and utilize new data delivery systems, most notably, APIs.

“Cloud creates the infrastructure for allowing the automation of expensive and risky workflows, creating a situation where staff can focus on areas to create value,” says Brad Bailey, head of market intelligence at broker-dealer Clear Street. “APIs are another key tool to facilitate the exchange of information.”

Clear Street launched in 2018 and its mission is “to build better infrastructure to improve market access for all participants.” As a startup, it has its sights set high and there’s no way of knowing whether it will succeed, but if the company can figure out a way to streamline the post-trade space, that could give it a leg up on competitors that are in the process of migrating legacy systems to the cloud.

“Solving the fundamental problems in the post-trade ecosystem requires a native rebuild for core problems to be addressed,” Bailey says.

Then there is RQD, a company that obtained a limited clearing license in 2018. Instead of establishing presences at Equinix datacenters, it decided to go all-in on the cloud. RQD uses Microsoft Azure and other Microsoft technologies, such as SQL Server and .Net.

RQD COO Nicolas Louis says the company had the luxury of starting the process from scratch.

“When you are a clearing firm that’s been around for a long time … you may have thousands of processes running against your [on-premises] systems every day—whether it’s a margin calculation, updating a position, or building a report for Finra, those systems are working non-stop. So now, people have been saying, ‘You need to maintain these systems, and that’s expensive and hardware can fail. Let’s move to the cloud,’” Louis says.

But this is where firms encounter a challenge because moving features to the cloud is easier said than done. One reason for that is they are moving it bit by bit, taking very specific pieces of their process, isolating it, and moving it to the cloud while everything else runs on-premises.

“So you have this hybrid setup, which sounds like a great idea, but all you did was add more points of failure,” Louis says. “For example, you may lose the connection to your cloud, and end up with a worse position, with processes running on different environments but not able to communicate with each other.”

Stability, resiliency, and the availability of post-trade systems are hugely important. If the lights go out, it could result in duplication of transactions or settlement failures for which firms could be penalized. So they end up running both systems in parallel.

“You have the new environment running in the cloud for a specific need, and you have a shadow back-up environment running on-premises that still needs to be supported,” he says.

The arrival of startups like these, paired with the modernization efforts at established players like Broadridge, DTCC and Indus Valley Partners, shows that there is a shift underway when it comes to cloud and post-trade. As ever, the back office will lag behind the front office, but nevertheless, change is coming. Firms will have to consider what they aim to achieve in their modernization process, and then only look at applying or using technologies such as cloud and APIs to help them get there. Applying the hammer-looking-for-a-nail ideology will not fly.