Show HN: Simple algorithmic trading in JavaScript
cloud9trader.com
cloud9trader.com
To weigh in on the mention of using doubles for finance....
Using double for finance, perfectly fine. All trading systems I've seen use double, from HFT systems to deep learning AI systems that open and close potions over months. Double is fine for most algo trading, heck the exchanges and dark pools I've talked with use double.
What you can possibly do with this.
1) Learn how to write the logic of an trading algorithm.
2) learn the basics of technical trading, with MACD, Keltner channels, vortex and Bollinger band indicators. They've definitely put the time in to getting the indicators that FX traders like to use.
What you can't do with this system.
1) React to currency fluctuations on a tick by tick basis. FX is just so fast and precise, there is a reason that professional FX traders mix FX spot quotes from multiple sources, we use 4 at the fund I work at and some use up to 10 sources. There is also a reason why FX is quoted to 4 decimal places while equities are to 2, sometimes 3 for penny stocks.
2) Use this in a real world setting. I can't see any privacy policy or contract indicating what happens when shit goes wrong. We are talking about money here, you can't just half ass this kind of thing.
Plus they use FXCM which had this new out about them:
http://online.wsj.com/news/articles/SB1000142405270230425560...
> LONDON—Foreign-exchange trading firm FXCM Inc. FXCM +0.08% agreed to pay fines and refunds totaling almost £10 million ($16.7 million) to settle allegations by a U.K. financial regulator that the company withheld profits from clients and failed to inform British authorities that it was under investigation in the U.S.
> The Financial Conduct Authority said that U.K. units of FXCM withheld £6 million from customers on foreign-exchange transactions between August 2006 and December 2010. The regulator said the broker pocketed profits when exchange rates moved in its customers' favor while a trade was in process, but it passed on losses that occurred on other trades.
Isn't the reason that most FX rates are O(1) (eg EURUSD is about 1.34, cable is about 1.7) whereas most stocks are O(10) or even O(100) and O(1000)?
If you take an FX rate that isn't O(1) eg USDJPY which is about 100, the convention is that it's quoted to 2 decimal places, like a stock (though there are some exceptions, eg USDMXN is around 13 but it's quoted to 4dp, and USDRUB is around 35 and also quoted to 4dp).
I don't see any reason why they couldn't aggregate prices and compute them tick-by-tick? JavaScript can run really fast these days
> [Can't] Use this in a real world setting. I can't see any privacy policy or contract indicating what happens when shit goes wrong. We are talking about money here, you can't just half ass this kind of thing.
I mostly agree and I wouldn't use it, but if you're just starting out and can't afford to build your own platform, it might be worth considering?
> There is a reason that professional FX traders mix FX spot quotes from multiple sources, we use 4 at the fund I work at and some use up to 10 sources.
We use 15 :) (Although two are internal flow from other desks)
> Plus they use FXCM which had this new out about them
We use FXCM. If they quote and fill the best price, I don't really care how they arrived at it. But that's just me.
We find no issues running scripts of reasonably high complexity. Of course if you have a particularly heavy algorithm it may be better suited to running at interval close.
With regard to legal position, you're absolutely right. While we're in beta you can connect to live broker accounts, though we are blocking order requests from actually being sent. We want to be water tight both technically and legally before we full launch with regulatory authorization, lifting this restriction and allowing real money to be risked.
As with brokers, we just want to support as many as we can. FXCM were a natural first choice for integration as they have excellent support for API solutions and have the most fully featured FIX implementation we've come across. Of course it's up to the trader to establish if any conflict of interest scenario exists between themselves and the broker.
Trading might be simple but being profitable definitely is not.
"We make tax law simple!"
"We make heart surgery simple!"
^^ similar silly things, only you don't ever see them
The thing is, no one actually DOES make anything simpler. They just restrict the toolset with which you can solve problems to things that work for the 80% cases.
Im wondering how they do this.
Anyhow, for user-submitted code like this trading site, I think JS is the only realistic option since it can be sandboxed so safely.
I don't know of a single firm that's successful in the time horizon that a lot of pseudo-HFT systems operate in. (The 10ms-3s range) And that's assuming an ideal fee situation...
Most of the people ignoring the LL arms race target RV opportunities on the 30s+ range. This involves taking a pretty big step back from microsctructure/toxicity models.
Would you mind explaining more about this?
There're a lot of silly myths about investment software on hacker news / reddit. Truth is that the code is usually much more hastily written, but with more tests or redundant systems implemented to cross validate results.
The idea that precise decimal types will be used throughout the systems is a bit silly. All the data typically will be going though off the shelf machine learning models, all of which just used plain floating types.
2^53 is 9,007,199,254,740,992
If you want to denote that the last three digits are for fractional dollars (i.e. each integer represents 1/10th of a penny) then you can store any monetary value from -$9 trillion to $9 trillion.
EDIT: Note that it's tempting to think that you can skip converting decimal currency to integer as long as you only use <= 3 digits after the decimal and you're storing values of less than 9 trillion, i.e. it's tempting to think you're safe storing a value like $1,283.212 directly in a double without converting to integer. But I'm pretty sure that's mistaken. You always need to convert to integer so that you're storing 1,283,282 in a double, not $1,283.212
The reason is because certain decimal values which can be represented in base 10 can't be represented in base 2. For example, $0.1 can't be stored into a double as-is; if you try to store 0.1 into a double, you'll get:
0.1000000000000000055511...
Of course, the error may be so small as to be insignificant, but the point is, I'm absolutely certain that integers between -2^53 and 2^53 can be perfectly represented by doubles, but I'm not certain that <= 3 digits of decimal precision can always be accurately represented by doubles for values of less than 9 trillion.
EDIT2: You have to be careful when converting between currencies, too. For example, right now $2 = 204 yen. If you're storing yen, 2^53 yen is different from 2^53 one-tenth-pennies, so the max value that you can store is specific to each currency. This seems like potentially a tricky problem, and may be what the parent commenter was referring to when saying doubles aren't so good for financial work. Still, though, 2^53 integers of precision may be sufficient regardless of which currency you're using.
[1] http://stackoverflow.com/questions/3730019/why-not-use-doubl...
We will be adding a wide selection of brokers to that list and will prioritize on basis of demand.
Please let us know if there are any particular brokers you'd like us to support.
I was waiting to see the thing in action before commenting, but here goes anyway. What are your latencies like (market data and orders)? Do your algo's have to depend entirely on current indicators/market data, or is there a way to use historical data? I'm a former HFT/algorithmic trading systems dev myself and the performance requirements in that particular domain was pretty high. At one point, even C++ and close-packed binary data transfer wasn't enough. I was wondering how you're managing with Javascript?
You can stick the following in your browser console to log server latency stamps on incoming market data:
require(["registry"], function (registry) { var instrument = registry.get("instruments").get("EUR/USD"); instrument.on("tick", function (data) { console.log("Server latency (ms):", data.get("serverLatency")); }); });
Of course replace "EUR/USD" for whichever instrument you want to monitor. 10-20ms is typical for comms between our instances and the brokers (we get similar results for outgoing trade execution requests, factoring in the round trip).
Our stack is largely JavaScript. We've found NodeJS to be blisteringly fast and lending itself perfectly for this kind of application (low memory, high throughput, heavy processing).
We have a backesting framework for running against historical data. Do you have a requirement for pulling historical data into an algorithm during live trading? We haven't included this in out API, though it would be fairly trivial to implement. It's key though that algos run with as little in memory data as possible. We also include a framework for writing your own custom technical indicators. These are naturally set up to pull historical data so may be what you're after. These and the built in indicators can be used in your script by just calling e.g. sma(10)
1. Does the API allow writing an algorithm that deals with more than one instrument?
2. Thought about including Bitcoin?
Currently the API doesn't support multiple instruments though an individual trading session already pulls in whatever currency pairs are required to convert from term currency to your account currency to calculate unrealized profit and to allow you to set quantity in as a risk percentage of account balance... basically not much work involved in supporting. Will get it prioritised.
Definitely would like to include Bitcoin and are looking into our options at the moment.