Critical process/components for building bullet-proof high speed trading systems

Quote from WinstonTJ:

The platform is a huge part of the system. Not dwelling on it is sort of like worrying about what type of brakes & tires you are going to buy without taking the type of car into account.

Also, I doubt you are directly connected to an exchange unless you have access from a current employer. The feeds and lines alone for that are very expensive and most people don't turn that stuff on until they have a working system ready to trade.

A prop firm telling you they are "directly connected to the exchange" is most probably a lie.
More...

Alright, lets admit that we don't have control over those.

We have to act within an existing framework that we inherit.

Any more thoughts?
 
First, what you did is crazy. The fact that you could buy but could not sell suggests the bug was in the market connection, not the trading system logic. So, you should have started manually sending limit orders far enough from the market so that they don't get accidentally executed. Then you could send an order that gets executed but do so during congestion period so that there is a good chance of breaking even if you wait for a minute or 2.

Second, if you actually ARE connected directly to an exchange (I guess WinstonTJ has proved you wrong) exchanges tend to offer access to "test" servers for testing market connectivity. These work exactly like real servers except the "trades" are not real trades. All features of a market connection should be tested on such a test server before going live.
 
For my experience to connection my application to the ARCA servers I can say that you have to pass a certification process before you can go live. They will check if your app follows the communications (in most cases the FIX protocol) and exchange rules. If you pass that, you are allowed to access the production servers of the exchange.
 
Quote from LeeD:

First, what you did is crazy. The fact that you could buy but could not sell suggests the bug was in the market connection, not the trading system logic. So, you should have started manually sending limit orders far enough from the market so that they don't get accidentally executed. Then you could send an order that gets executed but do so during congestion period so that there is a good chance of breaking even if you wait for a minute or 2.

Second, if you actually ARE connected directly to an exchange (I guess WinstonTJ has proved you wrong) exchanges tend to offer access to "test" servers for testing market connectivity. These work exactly like real servers except the "trades" are not real trades. All features of a market connection should be tested on such a test server before going live.
More...

no he just used simple open-source code and didn't properly debug before he compiled.

don't waste your time. he is just looking for someone to tell him how to buy back the book quicker than goldman
 
Quote from TrailingStop3:

For my experience to connection my application to the ARCA servers I can say that you have to pass a certification process before you can go live. They will check if your app follows the communications (in most cases the FIX protocol) and exchange rules. If you pass that, you are allowed to access the production servers of the exchange.
More...
yes... this... any true/pure DMA or direct access will require this.

OP you can't "suppose" you have "constraints"

If you can execute in 200ms then build a box that makes money in the 200ms space... its easy - be realistic and thats that - shooting for 5ms while you are in the 500ms space is foolish.
 
Quote from mizhael:


Therefore my question is how do we build a robust bullet-proof high speed trading system.
More...

Superhuman patience and persistence over years and some brain. :-))

Tom
 
Quote from LeeD:

First, what you did is crazy. The fact that you could buy but could not sell suggests the bug was in the market connection, not the trading system logic. So, you should have started manually sending limit orders far enough from the market so that they don't get accidentally executed. Then you could send an order that gets executed but do so during congestion period so that there is a good chance of breaking even if you wait for a minute or 2.

Second, if you actually ARE connected directly to an exchange (I guess WinstonTJ has proved you wrong) exchanges tend to offer access to "test" servers for testing market connectivity. These work exactly like real servers except the "trades" are not real trades. All features of a market connection should be tested on such a test server before going live.
More...


as you know the QA simulator exchange is crappy and you often need to massage the "send-trades-out" function in order to get a test trade filled...

then when we turn back to real-exchange, we somehow changed the code, etc. so that happened...

that's why we are asking for better process control...
 
Quote from mizhael:

as you know the QA simulator exchange is crappy and you often need to massage the "send-trades-out" function in order to get a test trade filled...

then when we turn back to real-exchange, we somehow changed the code, etc. so that happened...

that's why we are asking for better process control...
More...
Are you simulating or are you trading?

If your programmer/s can't debug and you guys can't sort out simulation vs. real trading I don't suggest connecting to an exchange.

I still have a very hard time believing that you are "directly connected to an exchange" since the cost to do that would far outweigh the cost of a decent programmer.

you seem to be grasping at straws and looking for anything that will make you rich quick...

Here is a good HFT strategy, simple, easy and can make a killing:

Develop an envelope/spread a penny or two outside the bid/offer. When someone buys the book up you get filled... when the book fills back in use that as your out - make 1-3 cents per share and kill it...

Good luck!
 
If you use a Liquid helium cooled josephson for your primary logic, you would be able to cut your latency enough that you would be able to beat out the colos.

There is a company called E-systems that sells liquid helium cooled SQUID (150 million gate josephson logic array) systems that would meet your requirements, it requires programming in Lisp and Assembly and a Front End Processor (FEP could be a Cray running Unicos and HIPPI interconnect)

The starter package (MASS-4000 series, 5 picosecond roundtrip license) with the daily liquid helium deliveries should get you going in the right direction.

I forgot to add, for DASD it requires the use of TMS (Texas Memory Systems) RAMSAN's the RAMSAN-6300 which can do 14,000,000 IOPS and 140 GB/sec of sustained, random bandwidth.
 
You must log in or register to reply here.
Back
Top