Hi Cryptosurf,
Well, I’m sure you know that SPEED does not guarantee winning at the
Retail Trading game. Along with speed, we also want consistency of
latency but, again, speed isn’t what makes money. It’s very difficult, for
example, to try to “chase” price with low latencies, and expect to win…
I’m developing trading over several different types of timeframe. And
one of those approaches does use BOTs, which I think of as “nibbling”
to exploit imbalances in relative Currency Strengths, or Order Flow
anomalies, where speed and precision are the keys to success.
Also, if I want a standard lot position in a Currency Pair, which is 100,000
units, I prefer to do that in several or even up to a dozen individual positions
which, taken together, give me a favorable VWAP. So, if you want to
close a dozen positions (which together constitute your overall position),
then that means closing a dozen or dozens of positions as quickly as
possible.
Closing them one at a time (with one instance of a MetaTrader terminal process)
would take 6 seconds, if closure time (which is a Market order) is 500 msecs.
If closure time is 100 msecs, then it takes only 1.2 seconds to serially close
a dozen positions. But I am using the NJ4X framework, which allows us to
allocate “pools” of MetaTrader 4 “terminal.exe” processes which are allocated
requests to execute “in parallel” or concurrently. This also helps improve response
times for multi-trade global positions in a single Currency Pair. (MT4 is synchronous
in its Order Processing).
Another big issue for me is that I use what I call “Virtual Limit Orders”. Basically,
instead of placing normal Limit Orders (which will trigger immediately), the idea
is to “simulate” a Limit Order which is “smart”. It will respect the pricing constraints
of normal Limit Order but, when Price is moving against and through the limit
price, it will NOT trigger until the “price run” is finished, and THEN it will trigger
using a Market Order. So this is a “latency sensitive” operation which almost
always gives “price improvement” over a normal Limit Order, and relies upon
“run length analyzers” as part of its behavior.
Having said all of this, if you followed down this far, Latency doesn’t Win in Trading,
all by itself. If your Analytics are no good, then Speed won’t save you !! So that’s
why low Latency and Consistency are so important, even though it is only one end
of the “trading spectrum” which does usually involve a BOT process inside the
Trade Manager. These are not EA’s inside a single MT4 terminal, because we
are using MT4 only as the “lowest layer” of execution, where “the rubber meets
the road” to give us broker portability. The BOTs are operating at a much higher
level, and can be much more complex than what can be written in MQL. Instead,
the BOTs are written in Java.
Developers who want to do this should seriously consider using the NJ4X.com
framework, which is licensed at a very reasonable cost. You’d need to be a Java
or a C# programmer to use such a framework, and it’s not designed for “arbitrage”
but it can then simultaneously connect to multiple MT4/5 brokerages. Where this
has value for me, is that I create a Master/Slave structure, where Trades in the Master
account are immediately reflected in a handful of Slave accounts, with the lowest
possible latency. The Slave’s responses depend upon quickly detecting the positions
of the Master, and then immediately replicating those individual trade positions in
ALL of the Slaves, in parallel, within a multi-threaded process, via the NJ4X.com
API framework. Just a fast version of Trade copying, but it allows me to
create some money for associates, as a “side effect” of Trades in the Master
account. The Slaves “scale up or down” the Lot Sizes of the Master account
but, otherwise, they replicate all positions.
All of this happens across 28 Currency Pairs, so we can have a situation where
we have trades in ALL pairs, each of which has multiple-entries; and also trying
to replicate all of that into Slave accounts… Again, latency and consistency is
needed but, in the case of Slaves, they may be in a different broker than the Master, with
its own pricing and latency characteristics…
hyperscalper