Executing orders consistantly at predefined increments

Discussion in 'Order Execution' started by Aston01, Nov 29, 2014.

  1. Aston01

    Aston01

    I've seen a lot of discussion on buy/selling relative to the bid with limit orders and also more indiscriminate entries/exits using market orders hoping to just get execution in a general range. I know there are several of you on here that are considerably more knowledgeable about order execution than most, and for those individuals I have a question.


    If you were dealing with a liquid instrument currently priced at $100 and you knew you wanted to buy 1 unit (share/contract) every $.01 between $100-101 how would you do it with as few of moving parts as possible?


    Obviously you could code a system to loop every tick and constantly check price and order status, but could you effectively achieve the same desired result with fewer moving parts using a queue of StopLimit orders every $.01 increment? Or is there another better way ?
     
  2. Is the objective a 1 unit position at every price between $100 - $101? Or is your target a total position with an average price of $100.50? Does it matter if you miss a price level (perhaps because price moves too fast)?

    What is the time horizon over which you need to build the position? Do you start first time price is $100, and want to be in the desired position if and when price first reaches $101? Or is it OK to aim to build into the position say by the end of the session, for example?
     
  3. The market will move against your first position. It makes more sense to buy a unit every $.01 between $99-$100.

    After the whole position is in, the market will move against the whole position. Then, you are in trouble.
     
  4. Aston01

    Aston01

    Yes, ideally a 1 unit position every $.01 between $100-$101. The challenge is entry granularity so even though you could effectively arrive at the same result (final average entry price of $100.50) through a wide variety of different entry combinations that is not the task. Obviously there are always going to be a lot variables like price moving through a range too fast and causing you to possibly miss a price level, but to a certain extent that is a scenario you can have little control over.

    As I mentioned in the original post, the two most common options I am aware of are a series of StopLimit orders or a script to actively poll price data & order status firing off limit orders as appropriate. Personally I am all always in favor of the method with the fewest moving parts, but I was curious if there were other options that could achieve the desired result more effectively?

    FWIW - this somewhat of a hypothetical question so time constraints and risk controls are largely irrelevant as I am primarily interested in order entry mechanisms.
     
  5. Is the mandate to execute at every price level or beat the average price? Why not user a relatively priced iceberg and combine it with with a tick functionality? Place your child order at the bid and using with a tick, if the ask starts to go away you'll pay up and lift the offer.
     
  6. Aston01

    Aston01

    Hypothetically the mandate would be to execute the desired volume at every price level to obtain optimal granularity and pacing, but in reality if you could use an iceberg order with child orders to control the desired entry pace it would be achieving a similar end result. Tick functionality would likely greatly add to the precision of entry control.

    Beating the average price wouldn't be nearly as important as pacing position entry relative to instrument price. So getting all in at an average of $100.10 wouldn't be as ideal as maintaining even entry distribution correlated to instrument price movement from $100 to $101 and only achieving an average total position cost of $100.50 as price reached $101.

    I have looked for execution algorithms that could track an average like that, but most are limited to things like time based entry increments or relative to VWAP. If you have seen anything similar to what I mentioned above or that could possibly be augmented with custom code I would be certainly appreciate the recommendation.
     
    Last edited: Dec 1, 2014