--- In twsapi@y..., "marinindextrader" <marinindextrader@y...> wrote:
There is nothing in the files section that specifically deals with
trailing stops...though I can asure you that someday not to long
from
now it will
Wow!
Can't hardly wait :)
As to your trailing stop question:
It is my understanding that this can be handled in a few different
ways:
(whole explanation is about long postions)
IMO serverbased orders are always best (method B/C)because:
- Method A can be dangerous when loosing a connection. (client/ISP
down or internet overload with 11 sept like events)
- Serverbased orders have an other advantage IMO
Say there are 2 traders with a stop on MSFT.
TraderA=client based
TraderB=server based
TraderB is better of because:
a] The server 'knows' first about a stop being hit
b] The server order is older then the the order that TraderA submits
just after the stop is hit. And assuming the orders have the same
stop the server will execute the one that is the oldest first.
This can be an advantage when there is low volume or sudden
declines.
Stop system.....
I use an 'advanced' stop system (manually)
I use a adaptive stop system. Lemme explain.
a] I enter the market with a 5% stop
b] Calculate the expect price target (usually a res line)
c] The stop at the resline is 2%
So the stop gets gradually smaller as the stock rises.
Market vs limit orders.
I only use market orders as a last resort.
In most cases a stock just pull back. No critical situation of any
kind. Say from $100 to $98
Sell at $97.50 would be a 'fair' trade.
But what if the next bid is absurtly low? You know the $0.06 kinda
orders you see now and then....
If I get hit by such an trade I rather didn't use my stop.
You won't have that problem with high volume stocks like MSFT that
has 1000's of traders at each price. But with lower volume stocks
before/after markets hours this can be a real danger.
So we need to place a sell at the next bid (minus a few cents)
If the next bid isn't realistic just place an higher sell order.
Method A:
Have no server sided order and have an order on your client side
that
is ready to execute. You track the security price on your side,
then
if and when certain price events occur, you do one of two things:
modify the ready order, or go ahead and send it
Method B:
Have a standing order on the server, and if and when price events
occur one of two things happens. You do nothing and the standing
order is executed on the server side (you got stopped out), Or, You
resubmit the order with modifications using the identical id # (not
positive about this one), and the server sided order is modified
(an
event occured that triggered your modified order to send).
Method C:
Have a standing order on the server side, and when events occur
either one of two things happen. The order triggers (you were
stopped
out), or you cancel the order and resubmit a new order with your
new
parameters based on a price action event.
