Aggregator technology is designed to improve execution by consolidating liquidity – in the form of bid and ask prices and amounts – from multiple sources into a single unified order book.
However, the optimal design of an aggregator is far from trivial, given that each client will have different execution objectives and adopt a particular execution style, and that the liquidity provided by the dealer is bespoke to that client.
The first decision for a trader is the number of liquidity providers to aggregate.
“Some clients deal on single-dealer bank platforms, whereas others aggregate two or three liquidity providers and at the other end of the spectrum there are those aggregating 30 or more,” he says.
The next step is to decide which liquidity providers to include. Again, there is no agreement across the board on whether a provider that internalizes trades by holding the risk until it finds opposing interest from other traders is preferable to one that externalizes trades by immediate one-for-one hedging on public venues, thereby creating an instantaneous market impact.
Market participants are aware of the distinction, but the implications for aggregator design and transaction costs are less clear, says Oomen, adding that it is not possible to make a blanket statement regarding the optimal aggregation model because each client’s requirements for liquidity will be different.
The conclusion to be drawn from the research and from client feedback is that while there is a cost to creating the aggregator model, it is relatively inexpensive to add additional liquidity providers once the technology has been set up and integrated into a client’s business.
“If we go back a few years, many clients would have had more than 10 liquidity providers in their aggregator,” he says. “Now an increasing number of those clients are scaling back the number of liquidity providers in their aggregator, partly on the basis of their own research and also work we have done with them.
“Maintaining so many relationships is time-consuming and they are questioning how those with limited share of the aggregator benefit execution.”
As well as working with fewer liquidity providers, market participants are also specifying their requirements in greater detail. Combined with a more quantitative, data-driven approach to trading, this creates a more in-depth discussion that is not just about spread but also market impact, reject rates and consistency of pricing.
According to Oomen, the structure that works best for many of his clients is to execute the full amount with a small number of internalizers rather than stack-sweep execution, where the client divides up the order into a multiple of standard amounts and spread execution of these across as many providers at their best prices.
The usual argument for using stack-sweep is that each child order or smaller trade is of a lesser size and will therefore cross a tighter spread than what is charged for a single full-amount order size.
However, this assumes that the liquidity providers offer the same liquidity to a trader irrespective of execution style.
With stack execution, a single liquidity provider that has quick market access and for whom it is relatively expensive to internalize risk can effectively force all other providers to externalize the trader’s flow, thereby maximizing the market impact and aggregate costs levied on to the liquidity providers.
“For clients with natural liquidity demands whose trades are not motivated by very short-term, latency-sensitive price fluctuations, this approach can work well,” says Oomen.
“However, there has to be a commitment from the liquidity provider to deliver liquidity on that basis, while the client has to be prepared to constrain the liquidity pool and only send flow into that pool that is compatible with the liquidity relationship.”
Regardless of the strategy adopted, Oomen reckons changes are relatively easily made and that clients can clearly measure the benefits in terms of reduced trading costs as well as increased liquidity access.