As the demands to minimise costs, ensure consistency and measurability in decision making, and outperform peers are on the rise, buy-side traders are seeking automation tools to overcome these challenges. FactSet’s Portware technology has been enabling efficient, data-driven trading at scale for leading buy-side trading desks for over a decade. During that time, the needs of our user base have evolved and with that so have our automation tools. In this article, we will discuss the four categories of new automation feature requirements as they relate to the trading workflow.
Automated signal detection and reaction through bespoke events
We think about automation across three different verticals: routing/placement, in-trade, and post-processing. Most traders are familiar with routing automation as these rules blazed a trail for the other trading automation verticals. Over the years, automated routing functionality has become ubiquitous amongst OMS and EMS providers.
One of, if not the earliest use-case for such functionality, is the automated routing of small orders (i.e., share quantity and/or notional value). This functionality freed up time for the buy-side trader to spend on larger, more difficult-to-trade orders and high-value tasks such as research or meeting with portfolio managers and stakeholders.
Traders then spotted unrealised efficiencies on the opposite end of the trade-order lifecycle. As a result, those traders went looking for post-processing automation for some of the mundane post-trade activities. The capability freed up more time and acted as a second set of eyes, monitoring for planned or unplanned events that occur at the end of the trade-order lifecycle.
We see an increasing number of requests to fill the gap between the routing and post-processing portions of the trade-order lifecycle (i.e., while the order is in a working state). This is, after all, the state of the order where there is a sustained, high-level demand for the trader’s attention. This demand for attention is exacerbated by both volatile market conditions and increasingly larger order books. In such an environment, it is entirely understandable that our cognitive capabilities can only take us so far; with so much noise, signals can be missed. It is these missed signals that are fueling these requests for new automation capabilities. Traders need a way to define meaningful signals through bespoke events. However, identifying such signals is only the beginning. In addition to signal monitoring, traders want to take action on these signals in an automated fashion.
Incorporation of proprietary data in the automation process
While it’s natural to think the increasing desire for in-trade automation is simply a progression of trading automation, we believe these requests were largely facilitated by previous interoperability efforts. We’ve long had significant demand to bring external data into the EMS. More specifically, our clients want to augment native EMS order and market data with their own proprietary data. It’s in many forms, with use cases ranging from simple custom classifications to sophisticated liquidity analytics.
Initially, requests to integrate proprietary data were for accessibility and/or visibility in a trade blotter. Most use-cases were some form of decision support but unrelated to automation. However, once the data was visible in the trading platform, the value of incorporating it into the automated routing process became obvious.
We observed the ability to incorporate clients’ proprietary data into the automation process had a significant positive impact with routing automation adoption. In that context, merging proprietary data is critical.
Explainability for increased automation transparency
In the early days of automated routing, back when automation rules were simple (often due to platform limitations) and didn’t deviate from auto-routing orders of 500 shares or less, there wasn’t a strong demand or need for explainability. One could see why an order was or wasn’t routed by way of common blotter columns (i.e., ordered quantity). Today, however, this is no longer the case.
As our clients adopt more automation capabilities, the logic becomes proportionately more complex. For example, much of the data is derived at a point-in-time and used solely for the purpose of automation. Because the data inputs and outputs change from moment to moment, troubleshooting and/or understanding why particular actions were taken can become difficult, if not impossible. This is typically a significant barrier to further adoption.
Explainability shines a light in an otherwise dark box. A comprehensive automation solution isn’t just an engine that executes the rules logic the end user puts in place. It is also responsible for letting the end user know what it did and why, enabling them to tell their stakeholders.
Explainability is also useful for rules testing, rules simulation, and usage metrics. While each of these offer value on their own, they can also be used to tune and optimise the automation system.
Oversight of automated workflows for risk reduction
As an automated trading solution becomes an increasingly critical capability at a buy-side shop, there is often a comparable increase in the need for checks and balances for implementation and configuration of the solution.
We have visibility into hundreds of automated trading rules of varying levels of complexity. It’s common to see a minor change to a single rule result in a significant change in the behavior. Often, it’s the editor’s intention, but there are times when the scale of the behavior change is unintentional. As a result, we see demand for oversight functionality as it relates to the deployment and maintenance of the automation rules. This mitigates the risk of those unintended, negative rule changes.
Requests are either for locking out users without certain permissions or for a robust change in the approval workflow. The desired functionality is not dissimilar to workflows surrounding compliance rules—only the approval of automation rules changes typically comes from somebody in a leadership position on the trading desk.
Conclusion
The volume of requests for automated trading, including those not discussed here, shows that buy-side traders are embracing automation far beyond simple, mundane tasks. This is especially true of the requests for at-trade automation, which suggest that traders are willing to use automation beyond getting an order out the door and use technology to monitor and adjust those orders, all the while leveraging their proprietary data.
A buy-side desk’s willingness to implement or expand the use of trading automation may be partially driven by the C-suite; however, any willingness or desire for expanded automation can be attributed almost entirely to early automation capabilities.
Those capabilities established confidence and trust, which evolved into ambition and aspiration for additional efficiencies. They’re behind every client request to drive automation across the entire trade-order lifecycle.
