From the outside, an institutional trading platform may seem like a giant black box of code. An asset manager sends in an order to buy or sell a particular stock, the black box crunches some numbers and in turn ships out smaller child orders to the street. If the algo does a good job, those child orders trade at relatively good prices.

But beneath the hood, there are many different jobs happening. There are dozens of specialized software applications performing various essential tasks such as FIX translation, order validation, risk management, monitoring, market data consumption, and post-trade processing. In this post, we dive into the key piece of code responsible for making trading decisions.

At a high level, we have two strategies/trading instructions that the customer can specify:

• VWAP: trades in-line with market volume based on a dynamic volume prediction model.
• PROOF: a hybrid liquidity seeker/impact minimization algo that balances speed of execution with avoiding undue market impact as per a home-grown quantitative model, with an opportunistic component searching for block liquidity in parallel.

Additionally, both algos have two available override checkboxes: 1) must complete, and 2) exclude the auctions. We try to keep our order ticket as simple as possible, while still covering the most common use cases.

Both of these top level strategies are implemented via a common software architecture. As we peel back the layers of the onion, it turns out that the trading strategy is itself a collection of modular pieces, each with an important role to play.

To really understand the interaction between these components, it is helpful to walk through the specific logic at the various phases of an order, from creation through completion or cancellation.

Order Arrival

Upon receipt of a valid order, the Algo subscribes to market data and then creates the Scheduler. For a VWAP order, the Algo creates a VWAP Scheduler; for a PROOF order, an Impact Minimization Scheduler. Then, the Algo asks the container for various wakeup callbacks: at the start time, shortly before the auction cutoff times, at the cleanup time (i.e. shortly before the end time), and at the end time.

Wakeup Logic

The container wakes the Algo at those various times as requested:

1. Upon a pre-auction wakeup, the Algo slices shares to the primary auction.
2. At the start time, the Algo creates the Worker and begins the first interval (see Interval Logic below).
3. Upon the cleanup wakeup, the Algo tells the Worker to complete any remaining scheduled shares.
4. Upon the end time wakeup, the Algo cancels any outstanding orders and then provides an out to the client.

Interval Logic

Both strategies treat the life of the order as a series of distinct “Intervals,” generally about 5–10 minutes windows of time that share common trading behavior.

At the start of a new interval, the Algo requests two pieces of information from the Scheduler:

1. The length of this interval, so as to request a wakeup at the end. Intervals are generally about 5–10 minutes in length, but depend on other factors too like the time of day — intervals are stretched longer in the morning when spreads are wider, and compressed as we get later in the day. Additionally, smaller orders have longer intervals and vice-versa. All interval durations are randomized.
2. The number of shares scheduled to trade during the interval — this is one of the two key differences between the two strategies. The VWAP Scheduler uses the dynamic volume prediction model to predict what percentage of the day’s volume will have traded by the end of the current interval. The Impact Minimization Scheduler gets this value by running a dynamic programming cycle of the impact minimization model. The Algo then uses this information to tell the Worker to complete any shares outstanding from the previous interval and start working the new interval quantity.

The second key difference between the two strategies is the liquidity seeking piece. Throughout the life of a PROOF order, the Algo tells the Worker to search for block liquidity at the midpoint with all remaining unscheduled shares using an Opportunistic Router.

Additionally, the Algo requests “catch up” wakeups throughout the interval where it checks if the Worker is falling behind, and if so, tells it to cross the spread to keep up pace.

Order Amendment

Upon receipt of a customer replace request, the Algo generally cancels or amends the Worker to comply with the new instructions. In most cases, the Algo also creates a new Scheduler to use from this point forward.

We designed this algo by thinking through how we would approach execution for ourselves if we were on the buy-side. The driving principle of course was best execution, with less emphasis on a “consistent” customer experience (e.g. the algo doesn’t immediately trade 100 shares so the customer can see it’s working).

Low Level

We have a great deal of experience in the world of sub-second/sub-millisecond trading dynamics, so designing that piece was relatively straightforward. At the micro-level, the objectives are two-fold: avoiding adverse selection when adding liquidity, and capturing as much volume at the best possible price(s) while removing:

• Avoiding adverse selection: When the market transitions to a new price level, there is a flood of trading activity where the fastest proprietary trading firms race to pick off resting orders at the old price level and establish queue position at the new price level (these are two similar but different strategies). As a sell-side firm, it is not plausible to effectively compete in these races, so the only viable way to prevent adverse selection is to utilize built-in protections on trading venues, such as IEX D-Peg and D-Limit, and Nasdaq MELO.
• Removing liquidity: rather than reinvent the wheel here, we are starting off by just using the IEX Router when crossing the spread, which costs only 1 mil and gets ~99% fill rates. In most cases, we first check various dark pools with midpoint all-or-none orders prior to crossing the spread. Because these midpoint pings are all-or-none, either the full amount gets done at the mid, or nothing happens and we’ve just wasted an immaterial amount of time.

High Level

Even more important than the low level strategy is the high level strategy — i.e. how should the algo spread out trading throughout the day. We have devoted a great deal of our energy toward researching this challenge. We started with 4 major questions below, each of which stoked major research endeavors, documented below. Our research on these topics is only just beginning, and we will continue to iterate from here.

1. How do we measure success at a high level?
• Distilled impact [blog post, paper].
2. How much volume do we expect to trade in the market throughout the day?
• Volume prediction model [blog post, paper].
3. How much should our algo be willing to trade during the life of the order?
• Pre-trade model [blog post, paper, pre-trade tool].
4. How should we pace our trading activity throughout the life of the order?
• Impact minimization model [blog post, paper].

Demonstrable better performance is the ultimate goal, but these questions are all extremely difficult to answer as higher level trading data is sparse and noisy. That, combined with an opaque industry-at-large, makes it tough to build confidence in the performance numbers or find a reliable point of reference. We are optimistic that our continued research focus on metrics, our collaboration with partners, and the growing set of our own trading data will help us to eventually get there.

In the meantime, our approach has been to bite off the significant low hanging fruit at the micro-level simply by avoiding harmful/conflicted practices and properly utilizing exchange and dark pool order types.

At the higher level, we are able to at least use the noisy performance numbers and individual case studies to build confidence that the algos are behaving reasonably and as designed, and that our historical quantitative models are consistent with the strategies’ real-world outcomes. For the purpose of external marketing, all we can do is lean heavily on our transparency around the design process and our research findings to demonstrate that our approach is compelling.

Elegance and simplicity

The product, the interface, the quantitative models, the system architecture — all of these things have a natural tendency to bloat and become more complicated with time. Unnecessary complexity introduces risk and noise, and it is just as difficult to be disciplined enough to keep a solution refined and elegant, as it is to come up with that solution in the first place. Throughout our initial design and build, we have attempted to keep things simple and intuitive, unless there is a clear reason to make them more complex, and we will continue to be vigilant as we iterate in the future.

Most institutional equities brokers are extremely opaque when it comes to the inner workings of their execution algos. They generally give two excuses, but we don’t think these hold up under scrutiny:

1. “If we publicly share how our algo works, adversarial counterparties can use this information to detect when we are present in the market and front-run or game us.”
2. “Our algo is our proprietary secret sauce; if we divulge how it works, our competitors will steal our ideas.”

For the former reason, our response is twofold: if your strategy leaves an identifiable footprint in the market, adversarial counterparties are going to find you whether you tell them or not. Conversely, if your trading activity is sufficiently randomized, it can be undetectable even to counterparty who knows exactly how the algorithm works.

For the latter concern, granted when a competitor copies your key differentiator, it does dilute your brand and muddle your marketing efforts. We had this happen to us at IEX, and it was irritating. But unlike a prop trader with a unique source of alpha, it does not materially hurt the efficacy of an execution strategy when others copy it. Ultimately, the best thing for the buy-side is for all of their brokers to employ an effective approach. Our stance is that our latest good idea is probably not our last, and our competitors are probably slower-moving than we are. We welcome them to utilize and riff on our ideas.

On the other hand, we think the upside to being transparent is very significant. Transparency creates accountability — it keeps us honest, aligns our incentives, and builds trust with our customers. It also creates a wonderful vector for collecting feedback and getting better, not just from our customers, but from friendly competitors, or even those outside the industry. Speaking of which, if you have feedback on our approach thus far, or if there are additional details you would like us to share, please let us know!

We believe the single biggest problem with this industry is the ubiquitous opacity. Conflicts of interest and harmful practices flourish in the shadows — and we’re not just talking about harmful trading practices. Our wish is to be an example that transparency can still be a sound business strategy and hopefully nudge this industry in the right direction, one step at a time.