Building a New Institutional Trading Algorithm: Aggressive Liquidity Seeker

Over the course of my career, I have designed and built many institutional equities execution algorithms and order types. The first algo I ever built was RBC’s dark aggregator, just a simple router that would split an order across several dark pools, and reshuffle between them as it got fills. My second algo was RBC Eclipse, a fairly aggressive liquidity seeker that quickly became our most popular product. Literally trillions of dollars of stock has traded through Eclipse, and it’s pretty crazy to think I built it when I was 22 with effectively no trading or market structure experience. I wrote the code, but I can’t take credit for the design; the head of our desk had been a manual trader for many years prior, and Eclipse was basically the translation of his trading style into a computer program. It was very mechanical, and there was no modeling or quant research that went into it (note: RBC of course has iterated on their algo offering since we left). Out of the box, Eclipse always maintained at least a minimum participation rate (I think maybe 10 or 15 percent), and anytime it fell behind, or alternatively if there was outsized liquidity available (ie the total amount quoted at the inside was above a certain threshold versus the average), it would cross the spread and capture as much as it possibly could in that moment. It also continuously swept through dark pools with the entire balance, and it was willing to get done at the mid at any time. In practice, because quoted volumes grow toward the end of the day, it would get far more aggressive going into the close. This wasn’t exactly intentional when we built it, but that is when the market is most liquid and can absorb that kind of shock, so it was not unreasonable. The algo was simple and easy to explain, and it heavily leveraged our key tool (THOR), and our clients gravitated toward it.

Our flagship algo at Proof is also a liquidity seeker, and it similarly is willing to get done in line at any moment, but it is far more passive than RBC Eclipse was. The objective of the Proof algo is zero impact, and its behavior when there is no natural counterparty is intended to blend in with normal random market activity. We designed it the way we would want to trade if were on the buyside, and a lot of thought went into the impact model that drives its baseline behavior. We also were able to leverage several exchange and dark pool order types that didn’t exist yet back when I was at RBC, including the tools we helped build at IEX.

I’ve mentioned in recent quarterly updates (1, 2) our intention to build our third algo, a more aggressive liquidity seeker. We believe this to be the largest gap in our offering as it is a common request from current and prospective clients. We originally planned to just design and build the algo. Our tech platform is nimble and flexible, and we could probably pump out a pretty solid algo in a month’s time if we hunkered down. Late Q4 would have been an ideal time to build an algo, particularly because things slow down dramatically on the sales/meeting front during the holidays. As President and CEO of the business, respectively, Allison and I get pulled in many different directions, and extended relatively quiet time like this is great for coding and research.

But after some thought and discussion, we decided to take more time designing this algo, and in particular use this as an opportunity to more deeply engage with existing and prospective clients. We are not in a particular hurry, and it would be great to hear more perspectives on different buyside firms’ priorities and workflows in this context.

We have already documented the algo framework we developed at Proof, but in this blog I will walk through how an algo comes into existence. This post, as well as future posts, will illustrate the journey from initial idea to actual live trading product.

What is a Liquidity Seeking Algorithm?

The primary objective of a liquidity seeking algorithm is to find a natural (i.e large, institutional, single-sided) counterparty so that you can transact in large volumes immediately. You want to buy a million shares of AAPL? Best case scenario is you find a seller who will sell you that whole amount right now in line with the current market and boom, you’re done.

Large market participants like this are not generally going to openly advertise their presence for fear of impacting the market. That is, if other market participants catch wind that I want to buy 1M shares of AAPL, they are going to raise their prices accordingly — this is simple supply and demand. This scenario is called “information leakage,” and avoiding information leakage is critical to building a successful liquidity seeker.

Most large equity trades like this happen away from the open market, for example via dark pools, hidden exchange order types, crossing networks, or upstairs (ie human) block trading desks. It is not enough to just utilize venues like these though. All of these venues have a variety of counterparties, including ones you might not want to interact with, for example a proprietary trading firm who might “sniff you out” by sending small feeler orders out to many dark venues, and then turn around and effectively front run you if they probabilistically detect the presence of a natural. You also need to be careful about which venues and order types you use when searching for natural liquidity as some venues may send out IOI’s to other desks at the firm or other market participants that may leak information and cause market impact. There have even been high profile cases of dark trading venues that were purported to be a safe haven for natural institutional interaction but secretly allowed internal or external prop traders to prey upon their participants (1, 2, 3), so one must be ever vigilant.

In addition to seeking out block liquidity, most liquidity seeking algorithms also have logic to ensure they still trade some even when they don’t find a natural counterparty. A similar concern around undue market impact exists in this fallback logic: you probably don’t want to trade in an overly aggressive or predictable way that alerts the market to your presence and causes the stock to move away from you before you can get done.

So in summary, a liquidity seeking algorithm generally has two types of market interaction: a “liquidity seeking” component that seeks out large pockets of immediate liquidity, if available, and a minimum baseline level of market interaction.

What does “aggressiveness” mean in this context?

On any given order of any size, our flagship Proof algo will trade the entire order immediately if it finds a natural counterparty. Even though we consider it a relatively “passive” liquidity seeker, it can still trade huge amounts and be 100% of the volume. The difference with this “aggressive” liquidity seeker is the fallback behavior when it doesn’t find block liquidity. Whereas our existing algo attempts to blend in with normal random market activity and have zero impact, this new algo will be willing to make more of a splash, accepting that it will likely have market impact in exchange for greater volume executed.

A basic mechanical/tactical starting point

Here is the initial rough outline we came up for can modify our existing Proof algo to be more aggressive — we think this is a solid starting point, and we plan to iterate from here based on research findings and client feedback.

Algo purpose and goals

• Be at least a 20–25% participation rate on average
• Leverage our existing Proof algo quant research to the extent possible
• Complete the order quickly if you can

Features

• If the order is marketable and can be completed at the inside, cross the spread and complete the order
• Shortened effective end time based on pretrade model/volume curve?
• Much smaller dark min qty
• Min pov trigger to cross the spread — maybe with a randomized timeout so it’s not too aggressive?
• More aggressive take router for min pov trigger (possibly for every time we cross the spread)
• Oversize @ the inside (instead of routing through the inside)
• Protection in case market data is suspect
• Spray lit and dark simultaneously

Key Tactical Components

Liquidity seeking (in the dark)

The central tactical component of a liquidity seeking algo is the mechanism for sourcing block liquidity, generally in the dark at the midpoint. The specific venues, order types, parameters, and reshuffling logic all come into play. Is it better to cast a wide net and split your interest across many venues, or sit on just a few to avoid the potential for ships crossing in the night? Do you want to limit your interaction to only large counterparties by using high minimum quantities or accessing dark pools with counterparty filtering turned on? Do you want to leave bread crumbs out in the market such as small displayed orders or IOIs that might notify natural counterparties of your presence and attract them to you, or is the risk of leaking information to adversarial market participant too great? Are there actions we can take to try to sniff out large counterparties ourselves, for example by regularly pinging a wide variety of venues with midpoint orders?

So far, we have erred on the side of caution when liquidity seeking in our Proof algo, placing a small handful of orders with very high minimum quantities, generally in only the largest dark pools. We also try to take advantage of order types with protection from adverse trades when the market is in transition, for example IEX DPeg and Nasdaq MELO, although the minimum quantities are probably an effective filter against these trades as well.

With our aggressive liquidity seeker, this will be a good opportunity to explore the above trade offs and decision points. Since avoiding impact will no longer be the utmost priority, and in the balance between liquidity capture and information leakage, we will be shifting more toward liquidity capture, it will likely make sense to incorporate new venues and order types, and potentially loosen our constraints.

Liquidity removing

Another likely important ability of an aggressive liquidity seeker is the algo’s ability to capture maximal liquidity when removing. If you’re going to take an aggressive action, which will likely alert the market to your presence, you want to make sure you’re getting a good bang for your buck in the form of a high fill rate.

When I was at RBC, our platform’s “killer app” was our router THOR, which specialized in capturing all available liquidity at the NBBO by staggering its orders to arrive at each exchange and dark pool at the same time, so that there would be no opportunity for market makers to see it coming and get out of the way. At Proof, we currently use the IEX router, which doesn’t stagger orders or access dark pools, but at least gets near 100% capture rates of quoted liquidity just by having consistent low latency connections to the other exchanges.

Another way to maximize liquidity capture is to blast ISO’s (intermarket sweep orders) at prices more aggressive than the NBBO. Ideally, a router would have the ability to send staggered aggressive ISO’s that hit all exchanges and dark pools simultaneously, or at least in close succession.

Unlike the other tactics our algos employ, liquidity removal is a scenario where low latency, or at least reasonable consistent latency, is highly relevant. It will likely be helpful to migrate our trading system to the AWS NY Local Zone prior to building a proprietary router for liquidity removal ourselves.

Key Quantitative Models to Enhance the Algo

Though it is impractical to exhaust the space of possible designs and have scientific backing for every decision that goes into creating a fully functioning algo, there are several opportunities we can take for leveraging quantitative research. Here are some of the questions that may be well-suited to quantitative study and may provide actionable insights for our aggressive liquidity seeker.

Baseline Level of Activity

• If the algo cannot find a natural counterparty, how much should it trade and when? To turn this into a research question, we will need to specify a criterion for what “good” trading in the absence of a natural counterparty looks like. For our more passive flagship algo, our notion of “good” here targets minimal expected impact. For an aggressive liquidity seeker, we may want to increase our tolerance around impact or formulate our goal in a different way.

Moments of Outsized Liquidity

• If the algo has the ability to remove large quantities of stock in a single blast, what specific situations should trigger this action?
• Are there certain moments when we expect the stock to be able to absorb such an action with less price impact, for example on high volume days and/or as we approach the close?
• Are there certain moments when we expect an outsized amount of liquidity to be present, for example based on outsized current quotes, or perhaps based on some sort of heatmap or pattern of activity on the tape?

Studying these questions will involve sifting through historical market data for features that are indicative of heavy volume, as well as for examples of what we expect such blasts to look like. If we can model the impact of these kind of blasts from historical examples (perhaps under a variety of market conditions), we can make more informed decisions about the tradeoffs such tactics represent.

Auction Interaction

• How much can/should the algo participate in the auctions on normal days- what is a good balance of liquidity capture and impact?
• Are there certain days that warrant outsized/undersized auction participation, for example based on certain events such as earnings, news, options expiry, or index rebalancing? Can we build a general dynamic intraday model of auction impact using historical market data?
• How should the algo adjust its behavior based on real-time auction imbalances?

Questions about auctions are probably easiest to tackle from a perspective of volume prediction: what features in terms of events, intra-day trading, or imbalances are associated with relatively small and relatively large auction volumes? If we can better predict the size of an upcoming auction, we may be in a better position to control our impact on it.

Success Metrics

Given the level of noise in the market, evaluating the performance of a newly created algo is often much harder than coming up with the algo in the first place. As a general rule of thumb, noise accumulates at greater timescales, so performance at short time scales (like milliseconds) is much easier to measure than performance at longer time scales (like hours or days). It is also generally easier to see progress on behavioral goals (like how closely a VWAP algo tracks the volume curve) than on price goals. As a result, our process for evaluating new algos starts with behavioral and short timescale metrics and extends to longer time horizons and price-based metrics as we collect more data.

In the early days of evaluating a newly launched algos, we will be pouring over individual examples for a few different reasons:

• To verify that the algo behavior matches our intentions, step by step, in both common and uncommon situations.
• To hone our intuition for the relative importance of different scenarios.

For example, if we design to our aggressive liquidity seeker with a certain order size and time horizon in mind, we will want to see how well that matches up with how our clients are using it. Knowing how clients use the algo — in what situations and with what goals — is an important input to our prioritization of research and algo enhancements. Obviously this can change over time and a small sample can be misleading, but it is one of the few things that we can start to meaningfully learn from initial data.

Evidence of adverse selection at short timescales

Short-term price outcomes are relatively robust and can generally be measured on a monthly or quarterly basis. We can use short-term (eg sub-second) markouts on a venue by venue basis to see whether we’re getting picked off while the market is ticking, and if some venues or order types perform demonstrably better than others at these time scales. Such metrics can validate the intuition we draw upon when designing algo tactics, or prompt us to revisit and update our low-level tactical approach.

Evidence that the algo is performing as designed

Some behavioral metrics may be robust and meaningful on relatively early data, such as:

• Liquidity capture when removing:

If we employ an aggressive order router, we will want to measure its efficacy, for example by measuring its fill rate versus quoted shares. When crossing the spread, we expect to consistently capturing everything that’s displayed, and hopefully a fair bit of hidden liquidity on top.

• Evidence of information leakage:

We can screen for differences in market behavior around our major liquidity events (both passive and active). Any way that the distribution of price movements around our events differs from the general market distribution when we are not trading would warrant further investigation.

Expected vs. actual impact

Ultimately, the gold standard is measuring algo performance is looking at our overall price performance vs. the arrival benchmark, as this benchmark is presumably uninfluenced by our subsequent trading activity. However, given the high amount of variance in the distribution of market prices over the timescales that represent typical order lifetimes, we would need a LOT of data to make this metric meaningful. We do have a technique for mildly de-noising the arrival benchmark using contemporaneous price movements in correlated ETFs, which we call distilled impact. This generally makes a meaningful dent in the amount of noise in overall performance metric, but the amount of noise remaining still forces us to wait for a depressing volume of data before we can responsibly pin down our all-in performance on price.

Next Steps

1. Circulate the plan and current design
2. Solicit feedback from existing and prospective clients who show interest, while exploring these research topics in parallel
3. Iterate on the design and repeat
4. Build and test the algo
5. Deploy to production (and possibly update our algo ticket)
6. Measure performance and continue to iterate

Closing thoughts

As we move through the process from feedback collection to design refinement, to actual coding and testing, we plan to publish subsequent post detailing the progress and what we learn. Our hope is not only to build the best product we can by embracing open collaboration, but also to illuminate what it takes to build an institutional-grade trading strategy. If you’re a market participant in our space and have any thoughts or feedback for us, please don’t hesitate to reach out to us at info@prooftrading.com. Thanks!