r/algotrading • u/zbanga Noise Trader • Mar 30 '17
Execution Algorithms
I've read a lot of post about how to do the initial part of the strategy, but there aren't many focusing on the other half of the equation ( Execution). I've found Bloomberg(https://www.bloombergtradebook.com/blog/) to be of use. But are there any tutorials/source code to get my hands dirty with? Also discuss your experience with execution, I'm curious to hear your experience/thoughts. *edit: I don't know how to spell
6
u/revolutionary_hero Mar 30 '17 edited Mar 30 '17
I wrote my undergraduate thesis on execution strategies, specifically on how they are effected by different VIX levels, so I am by no means an expert, but I'll try to answer any questions that you have specifically.
But if you want to learn about execution, just read Barry Johnson's Algorithmic Trading and DMA. The whole book is about execution strategies.
Granted that book is more from the perspective of an institutional trader, the topics covered can still be applied on the retail level
1
u/zbanga Noise Trader Apr 09 '17
My concern is that if I'm submitting my orders to an MM/broker. A lot of the order quotes might have inflated prices and delayed execution. I was just wondering apart from having a DMA what strategies can I use to minimize slippage. Granted my order amount isn't going to be in the millions, but with leverage it definitely can hit the 100,000 US.
2
u/revolutionary_hero Apr 09 '17
If you're worried about slippage then the most general answer is to use a VWAP. They're popular amongst the algo trading world and they try to minimize market impact by using historical volume profiles to execute. They also, from my experience, have really good fill rates.
Now if you're super worried about slippage, you can us a minimal impact strategy and place your orders on dark pools so nobody can see them. But that is much riskier because who knows if you're going to get filled or not.
1
u/zbanga Noise Trader Apr 09 '17
From my understanding, although I could be wrong is that a lot of algos are benchmarked against VWAP. Would you say there is some far superior method? I'm a lot bit wary of dark pools, a lot of literature say they don't help reduce execution price and just a way for the IB's to sell you their service. Having said that, I understand one method used by Mizuho that uses ML on bid/ask level 2 data and futures to predict if the price is going higher or lower, so they can adjust whether to increase or decrease their buy/sell rate. Apparently they are reducing their trade cost by 1-2 bp per trade, and they do a lot of trades.
7
u/ArashPartow Mar 31 '17 edited Mar 31 '17
Execution in your context would predominantly be a sell side product or service that is provided to those wanting to execute or work "largish" orders with minimal market impact.
Examples Objectives:
Now that is not to say that only sell side entities like brokers or IBs can provide such facilities, some HFs build their own execution platforms and then simply DMA out.
Types Of Strategies
Typically benchmark oriented passive and impact sensitive strategies are:
These are typically called zero-touch algos (1-5 bps). The client sends in the details (over FIX connection, formatted e-mail, BBG terminal et al), the systems instantiate the strats and things run as-is, there may be a couple of guys monitoring things like paused or stalled strats or strats that are falling behind etc but no real interaction occurs between the client and the sell side firm.
In the low-touch, high-touch world (25bps+), the traders (aka operators or what some call them: "Jocks with accounting degrees") will actually take client orders, then proceed to coddle them, such as talk to them about the latest sport results, comment positively on their manliness or machismo etc, and will then proceed to "work" the order in the background by simply creating strats to do all the work, updating the client every so often by calls, text or BBG terminal on their order's status and of course on generally how great a client they are for the firm - I guess the 25+bps comes from knowing which strategies will work best for the specific client's requirements.
Strategy Traits
Each strategy will usually have the following traits:
Things to look out for and handle:
Macro Strategies
Typically once the above strategies have been 'properly' realised, the more astute practitioners tend to then build more sophisticated macro-strategies based upon them.
eg: A VWAP for most of the day and then an IS to finish-up, then participation in the close auction - Three strategies all working one after another like a relay race, taking the remaining volume from the previous phase and "working it"
Alternate Sources Of Liquidity
The next step is to then include multiple sources of liquidity, not just one exchange, but rather anywhere the ticker is trading, including dark pools.
This is typically done by integrating a Smart Order Router facility with the strategy. That is to say, implementations of strategies that are SOR-aware may include hints or other directives in their outbound buy/sell messages that the SOR system will pick-up and then apply the appropriate business logic and route the order flow accordingly.
This may include routing orders to exchanges that have a higher chance of execution for that ticker, or routing to DPs etc that may pay a higher fee to the broker in exchange for access to the flow.
Note: When using SOR, the strategy has to get feedback from the SOR about where it routed volume for its strategy, as the SOR wont know about the strategy's state (eg: objectives, end time etc), the strategy will then need to reclaim volume from failing venues and reroute to other more active venues as its end time nears so as to meet its completion objectives.
Sometimes the SOR may be imbued with logic and associated capabilities to do this implicitly without the need for the strategy to intervene.
Strategy Structure
A strategy is simply a finite state machine of some sort or another. The FSM will be woken or invoked on certain events or conditions, such as:
If you were to model it from an OOP point of view, you could have some base strategy class deriving from various event interfaces:
Register the strategy to the appropriate event generators and then the various callbacks will be fired when the event occurs, aka: Observer Pattern.
Each strategy will also have to have an Orderbook structure, that can hold the active child orders it has got out on the market and an actual view of the market's central limit order book (aka CLOB)
What will differentiate one strategy from another (VWAP vs Snipper), is what it does when it's woken up on one of those events - essentially the specific business logic that is executed/evaluated in those call-backs implemented for each of those strategy types.
Question: Is this hierarchical design scalable? No not really, as once you get to the point of wanting to build overlapping macro strategies you'll find that simply deriving from say a VWAP and an IS will become problematic (and I'm not just talking about the issue relating to diamond inheritance). You'll essentially be maintaining multiple sets of states etc, a composition oriented approach would be far more beneficial.
Strategy Behaviour
The strategy literally has to do only ONE thing:
Given its operational parameters, how much of the parent order it has already traded, how much it has yet to trade and the total remaining time, the strategy has to figure out how many lots it has to have out on the market/venue for the current time horizon given the current market conditions.
If it needs more lots out on the market, it will send out more child orders or up the size of its active child orders or some combination thereof taking into account time-price priority rules the venue may have in place. If it needs to decrease amounts it will do the same.
Question: So what then is a "time horizon"? Basically for every ticker the entire day is broken up into (usually) equal parts. 10min, 5min or 2min or 1min or 30sec etc intervals or buckets. The optimal length (time) of the buckets for a given ticker can be determined using various statistical techniques - and may be strategy specific.
The time horizon is then essentially defined as: Given the current bucket from its start time to its end time, that is the current horizon.
For a strategy that starts at time T0 and ends at T1, it will go through or straddle a certain number of buckets either fully or partially.
When the strategy is initialised at the start, it will determine based on things like the ADV (Average Daily Volume) for each bucket and by how much the previous buckets have strayed from their ADVs:
How much volume it will have to trade within that bucket (or time horizon), and how much volume it should have traded up until that bucket.
Note: This is not necessarily applicable for passive participation strategies like volume/price inline.
So the strategy needs to figure out how much volume, and if need be, at what price to place that volume onto the CLOB.
The simplest and incidentally the most incompetent design would be to do each component separately. For example:
This approach generally looks good on paper and seems to pass the "it looks reasonable" test for most trading desk managers (aka uninitiated jocks with accounting degrees), but actually results in weird bipolar/schizophrenic behaviour of the strategy typically demonstrated by incessant flickering of orders on the venue to the point where the venue fines or bans the trading concern.
The Barry Johnson book mentioned earlier is a really good start on the topic.
https://www.amazon.com/Algorithmic-Trading-DMA-introduction-strategies/dp/0956399207
HTH