Don't worry, your program will be layered: you start simple and with the most important parts. Then you gradually add the parts that are less important and/or refine certain core parts. Simply placing a limit order could result in that your order does not get filled. So you won't get the position you intent to have. Is that acceptable for your system? The system I use is rather basic and probably not the most optimum solution. I want my orders to be filled, and am willing to wait only a few minutes maximum to get this filled. This gives for me the compromise between the best fill price (i.e. lowest additional cost) and the assurance that the order gets filled. The price of an instrument moves in fixed price step sizes. I use this to determine what to do: (i) If the spread is 1 stepsize then I cross the spread and submit a limit order. This will get filled immediately. (ii) if the spread is 2 or more stepsizes then I initially submit a limit order with a price halfway between the bid and ask price. My order becomes therefore the best bid/offer price, hopefully drawing attention. I wait until the order gets filled, but wait a maximum of one minute. If after one minute the order is not filled I modify the limit price to cross the spread. This will get the order filled immediately. This works satisfactorily for my small account and for the small order sizes I use. In case your order sizes are large might a more refined approach be necessary to make sure that orders are filled. To ensure that no unfilled order lines remain at the broker do I specify the duration, after which the order is cancelled. This makes it easier to do order line management, and avoids that you need to maintain a data base with order lines and logic on how to handle open or remaining order lines.
Thanks for giving me something to think about! I see for you getting filled is important. For me, I'm okay with losing the entry and waiting for the next one. However if it doesn't fill, the order isn't cancelled currently. I need to add in that functionality. I would say for my case, if it doesn't fill in 30 seconds, I should cancel it. What is a small order size for you?
See, your requirements for order execution is already different than mine. Which is why you shouldn't blindly copy some existing code, but think for yourself what you want to be done (and not done). I do not trade forex, as you do. I trade futures. In most cases is an order line about only one or two contracts.
Completely agree. I would love to get to the point where I can care about reducing my costs that much, but for now, I want the profit to take care of the commissions. What is the underlying that you're trading? Currency futures?
At least now you are aware that the bid/ask spread is costing you more money than the commissions. It is a "hidden cost", often overlooked. My program tracks a variety of futures: currencies, stock indexes, bonds, agriculture, oil&gas, metals. Most are in the USA, but some are in Europe and Asia. Which is why my program works around the clock. Near the end of the trading day for each instrument will it review whether trading in that instrument is required. This results in multiple review moments during a 24 hour period.
Update: I've figured out why backtests and live aren't matching up in executions: the data for backtests is DIFFERENT for live. WOW. I don't even know how this is happening!
Journal entry Profit: 862.50 After commission: 702.40 Once I realized that the data was bad, I tried to minimize where the bad data was coming from (I would treat it as unchanging, but low and behold, the data would change midday - data correction? bug in code?). Now I know where backtests are not matching live data. The next step is to slowly debug the issue. It's easy for me to verify when data is not matching, so theoretically I should track this down soon. To answer @kj5159: I'm getting the backtest data and live data from IB. I can actually run a backtest WHILE the live data is trading and I get different information. This means to me that I am likely processing something incorrectly, somewhere.