I traded a fully automated fx model at oanda with very high frequeny ( 200 * NAV of the account/day) With average half spreads of 1.3 BPS in the majors without any "edge" the money will fade away in about 40 trading days. I survived 3.5 month. Although the model had an edge it had no chance to survive in the retail market maker world.
with spreads that low & no comms, and even if there were a bit of shifting against you, i fail to see how it makes a significant difference whether you are running your model on Oanda "retail world" type, or HotSpotFXi / Currenex (except for the 10mio unit limit on Oanda). if your "edge" was around news / figures trading, high leverage, which the turnover ratio seems to tell us, perhaps Oanda was slipping big time, but at the same time since mid-2006 liquidity was down to about 0 around figures on my HSFXi/Currx screens, for fear of all the FlexTrade-powered boxes sitting by the servers in NY and ready to sweep the books on announcements :- ))) plse elaborate
the diffference is the possible market entry . Market Orders ( and in the retail market maker world even limit orders are market orders) will always cost you the half of the spread. It sounds not very much. 0.013 %. But if you are trading high frequently it is quite much. Of course there is not much difference if you trade market orders via ebs , reuters or even hotspot. The problem are the spread crossing marketorders. But you can only avoid them on ECNs like EBS .... or cme Currency Futures. How often do you trade your NAV per day ? Beore costs i had a sharpe of 7 !!!. After costs money was at zero within 3.5 month
before figures the model stopped placing "quotes" . but the normal spread is expensive enough. HOT SPOT and Cur. make real limit orders possible. but there is not to much agressive flow that can be exploitet. If you can not join EBS than try EUR/USD FUT. at cme. The other fx futures have not enough liquidity.
gotcha... my strategy / model takes transaction costs into account, and same goes for the backtests etc... basically they represent an opportunity loss, that dimishes as i manage to attract enough K so i can justify going back to HSFXi/FXAll type setup, and start placing bids & offers again... which in itself is not going to double the returns, just improve on them significantly... as for daily NAV turnover, i can't comment on that except to say, nowhere near the levels you were at. not with a blackbox... am not ready for that yet ;-) back on topic, what where the key technical challenges & lessons learned?
A friend of mine progammed the model . (oanda API) we had no technical problems . The robot traded without interruption . I have several robots running on differerent instrument. But never again i have seen such little problems. I am running different robots on several markets in the field of high frequency. But there are always some problems like a knock down in the infrastructure of brokers or a knock down on the exchange side. Not like with oanda someone alwas has to watch it...
Oanda?? It's one of the brokers we are using. I hear they used to be better, or perhaps its just they can't keep up with increasing transaction volumes... dunno what i do know though is this: . we have optical fiber & broadband as back-up, have checked our ISP etc and we know the connection problems are not at our end for the most part . on any given day we observe in excess of a hundred session disconnects, 100 separate socket exceptions, dozens of "rate thread died" exceptions, 100 read time-outs on execution confirms and dozens of other similarly nasty stuff (for a high-freq BB that is...) . oanda's protocol is conceptually flawed: if you get a time-out while awaiting an execution confirm, 99% it's because they got problems at their servers' level. all you can do is poll the transaction log to attempt to reconcile. oanda keeps no record of failed orders, they have NO mechanism for you to check status, ie done, rejected, still unknown etc if you get timed out on the sendOrder method (or whatever else its called). IF the order was in fact successful, then it eventually updates in the Transaction Log simultaneously with Positions etc . i have documented instances where their Transaction Log updates MINUTES after the order's been sent (and we got timed out awaiting the exec confirm... you bet!). The record so far is 6:27 minutes......... we got 6 orders we believed had all been rejected suddenly appearing as done in the Log... what a joy that was! i wouldn't call that a breeze....
Show me another mainstream language that supports: 1) closures 2) continuations (limited continuation) 3) type inference 4) lambda expressions nitro
...Ruby? SML? O'Caml? Possibly Erlang. Though I am sure your keyword was 'mainstream'...although I do believe that OCaml and Erlang will be much more mainstream in the next five years (or atleast derivative, or parallel (ala Alice), languages from them) 'Continuations' are probably the trickiest to find in a language -- as most functional languages have lambda expressions and closures. Though, C does have continuations in the form of setcontext()...which most people aren't aware of.
C#, now no longer owned by msft, still a good standard for windows boxes. In the early days, almost not distinguish it from Java from a code snippet. (the case sensitivity drives me crazy). C++ will always have a place as long as there is open source / Linux But, it comes down to the most productive language? (We are not even talking about Java here which is now the most-used, no longer C++). Maybe. Actually (and this is overlooked!) I think it comes down to the most robust, customizable IDE, being able to eek every bit of productivity out of it, especially with a large team, then almost anything, C#, C++, VB.Net. Hey, unless you are prototyping a rocket launch to the moon...most people are not.