|
PureBytes Links
Trading Reference Links
|
Earl, sorry for taking so long to get back to you. I wanted to check a
couple of things and still did not get all the answers I sought. Below are
my comments.
In a message dated 1/6/01 7:30:14 AM Central Standard Time, eadamy@xxxxxxxxxx
writes:
<< John, I for one certainly appreciate your time and patience in explaining
with as much detail as possible, how stops are handled. If I might, I'm
going to take a crack at summarizing what you've said from the POV of the
retail trader with respect to stops on electronic (e.g. Globex2 and A/C/E)
futures trading systems:
a) most, if not all, orders (of all types) arrive on the exchange computers
via TOPS or FIX routing
****** Of retail orders, this would be a correct statement. However, there
is a third interface with Globex2 called the "Frontal Interface" by some
inside the CME. This is the socket that Interactive Brokers and GL Win
connect to Globex2 via. It is similar to the FIX API in that it has
streaming quotes. Globex2 workstations on the floor would connect this way.
b) stop orders, depending on order handling system deployed by the broker,
are held in one of 3 places: a broker "folder" on the exchange servers, the
broker's own servers, or the remote client computer. In no event, are stop
orders part of the system "book".
****** Right, although Stop Limit orders are held directly by Globex2.
c) as prices are received from a real-time price feed, the stop orders are
checked, and if triggered, released to the order execution system where they
become part of the system "book" on a first in, first out basis (same
price).
***** That sounds right.
d) the time delay required to move stop orders from the stop folder to the
system book is a function of: transmission time/delay of the real-time feed,
unknown priorities in processing broker stop folders on the exchange
computers, processing capabilities of broker and/or remote client computers,
and the transmission time required to move the triggered stop order to the
system "book".
***** Yes, although I would not characterize this as a "time delay." Just
the "time" takes for an order to be successfully routed to the Globex2 host,
which can and will vary depending on any number of variables.
e) high quality, high speed direct communications connections probably add
little to the total time while poorer quality connections e.g. dialup
internet might in fact incur significant transmission delay. Thus, stops
held on a broker server might incur near negligible delay compared to stops
held in broker folder on exchange server, however stops held on a client
dialup internet connection might incur considerable delay.
****** Personally, I don't know that the time differences will yield the
results you expect. I expect that you will find a bell curve distribution of
fill results around your stop prices for all methods. Is one system more
susceptible to the prices spikes? I think that is more a matter of luck, or
the lack of it actually. Personally the stops I get from the OM server that
TOPS routes to are just fine. Other people using FIX API have reported
similar results. As for the PATS Interface, and similar systems, which hold
the stops on the user machines, I have not tried this yet. My concern about
this method is more theorhetical than practical, so I will have to see. I am
a person who likes as much information and control as practical, so having
the stops on my own machine that I can monitor is not completly a negative
thing. I will let you know when I have enough data points for stop fills to
be able to assess this type.
f) stop with limit orders are handled differently than stop orders in that
they are held as part of the system "book".
***** Depends on the system and firm. Globex2 does accept stop limit orders,
but that does not mean a firm necessarily uses this function.
g) Globex2 can handle 35 transactions per second (1 order every 30
milliseconds), which might itself impose limitations in execution under fast
market conditions.
***** Absolutely, but I think you will find a traffic problems elsewhere in
the network may create execution speed or fill reporting speed problems as
well. Sometimes it is not the execution which is delayed, but rather the
fill reporting. Orders are routed to different markets, systems and
locations, but the fills all get dumped into the same bucket in the end.
Something to keep in mind.
Forgive me (and please correct), if I have missed something important here.
Earl
>>
***** No, that was an very good summary.
Regards,
John J. Lothian
Disclosure: Futures trading involves financial risk, lots of it! John J.
Lothian is the President of the Electronic Trading Division of The Price
Futures Group, Inc., an Introducing Broker.
To unsubscribe from this group, send an email to:
realtraders-unsubscribe@xxxxxxxxxxx
|