News for hackers. Stuff that matters.
Re:More challenging projects every programmer should try by henning on Sunday December 20, 2020 @06:03PM (#25490441)
As someone who has played with writing trading bots but never traded them with real money, some advice: if your results seem too good to be true, they probably are. Your trading bot may be doing unrealistic things or its results may not be reliable if the following are true:

- You are trading in a market with low liquidity or one that is controlled by a small number of market participants. I'm not an expert but I think this would apply more to markets like penny stocks and less to big markets like forex for major currency pairs

- You are not taking transaction costs into account or not doing so properly

- Your bot makes a low number of trades, making the results close or equivalent to lucky coin flips

- Your bot is simply making trades that cannot be executed, or may be doing simulated trades of something that is not actually tradable. This applies to a large number of research papers that assume you can just buy and trade the S&P 500 itself. You can trade ETFs that are tied to an index but an index is not a tradable instrument in of itself. Once you realize this, a lot of papers seem very weird

- You are not modelling other aspects of the trading process realistically, such as assuming the bot has infinite funds to trade, allowing it to take unlimited losses and continue trading when in reality you'd be hit with a margin call and your trading would be stopped

- Your code is committing any number of data snooping errors where the bot is asked to trade at time A (say the open of a trading session) but has access to future data (say the closing price of that day, future data that would not actually exist in a live environment)

- Depending on what you believe about how market conditions change over time, your bot may have worked in the past but would not work if used today. I.e., the market may have adapted to whatever edge your bot may have discovered

There are probably lots more pitfalls I don't even know about since I'm not an actual trader.

I'm not discouraging anyone from playing around or trying things, of course. I think it's great fun, which is why I do it.

Here's the good news: if you realize you don't actually have an edge and avoid risking your hard-earned money, you come out ahead of almost all people who ever trade.

Re:More challenging projects every programmer should try by atomicnumber3 on Sunday December 20, 2020 @07:05PM (#25490815)
I worked in this industry. 2 more common issues:

* Doing a latency-sensitive trade when you don't have good execution. It's easy to go wild in simulation and think you can flip in and out of positions. But if you're a retail trader (and in this context, by that I mean "not connected directly to the exchanges, at the minimum")

* Not taking into account the impact of your own trading on markets. This is obviously impossible to really simulate. Sometimes you can ignore it (if there's enough liquidity) but I've seen trades that looked great on paper and when trading at small-ish sizes, but then when you try to crank it up and do more volume, prices run away from you.

Obviously, there is money to be made in algo trading. It's big business and obviously not everyone is doing crazy latency sensitive stuff- there are quant trades that you could probably do with execution available to retail traders. And honestly I wouldn't be surprised if some retail traders manage it. But I will say that I think for an individual, it's not worth the effort even if you are ones of the ones who can consistently make a profit. Just buy sp500 ETFs and sit on them and do something else with your time.

Re:More challenging projects every programmer should try by IgorPartola on Sunday December 20, 2020 @11:22PM (#25492104)
Would you mind if I asked you a question since I have never worked in this industry but did play with crypto trading a while back. Before Mt Gox was shut down I was trading on a couple of tertiary small exchanges and at the time there was a lot of talk of arbitrage between different exchanges and how transaction latency and fees made it very risky at best and a losing proposition in most cases. But what I was wondering about is whether in a situation like that (one large exchange dominating the market, several smaller exchanges trading the same commodity) if it was possible to use the large exchange as a sort of oracle. Essentially my hypothesis was that Mt Gox sets the price and other exchanges follow on a delay so if I watch Mt Gox I can predict where the price on the secondary exchanges will go a few seconds to a few minutes ahead of it moving. I ran a bunch of historical data through some basic analysis scripts and noticed that indeed there was a pattern but when I actually implemented a bot to trade BTC it lost money more often than not. I am curious if (a) that idea has any validity and (b) was me losing money on this strategy due to latency and implementation errors or due to some fundamental principle of trading that I am missing.
Re:More challenging projects every programmer should try by caffeine on Monday December 21, 2020 @07:32AM (#25494307)
Your idea is right but the timescale is much shorter. Essentially it's a race. And in 2014 you could make good money doing exactly what you described, the timescale was millis. In 2016-2017 even more money, but different venues.

What you are describing is the most basic, canonical form of latency arbitrage.

That idea is implemented widely in the HFT industry across all sorts of products, not just crypto, with billions spent on trading the information faster

(Source: this is my job).

Re:More challenging projects every programmer should try by andrepd on Monday December 21, 2020 @10:55AM (#25496002)
Honest question: do you feel comfortable knowing that your job is doing something which is essentially net zero value to society? Negative in fact, you're burning resources which are needed elsewhere, and contributing to concentration of wealth.

Not being rude or judgemental, just want to know how you feel about this.

Re:More challenging projects every programmer should try by caffeine on Tuesday December 22, 2020 @04:24AM (#25504481)
Short answer: I am comfortable with my job.

I think your question makes some incorrect factual assumptions, but also it incorporates a world view that I don't subscribe to (not wrong, but also not what I believe).

I think that if I had your belief system and your set of facts, I would probably feel uncomfortable about it.

Re:More challenging projects every programmer should try by andrepd on Tuesday December 22, 2020 @09:33AM (#25506577)
The world view is simply that this technology arms race performs no useful work to society. It's simply people with capital investing enormous sums into gaming a system and extracting $$. Okay, this so far is not even a view, it's just how things are. The "view" is that it is wrong x) Much like one could argue that e.g. the yacht industry diverts resources and people from other more pressing needs.

As for "my" set of facts... well they're just facts :) not "mine" or "yours".

Re:More challenging projects every programmer should try by qw3rty01 on Monday December 21, 2020 @11:46AM (#25496615)
This is a pretty loaded question to then say "not trying to be judgemental"...take out the bias if that's actually the case: "What kind of benefit do you believe your work provides to society?" or "How do you justify the extra resources taken away from society that may be more beneficial elsewhere, such as X?"
Re:More challenging projects every programmer should try by andrepd on Tuesday December 22, 2020 @09:37AM (#25506613)
Well I don't know how to make it less loaded x) It's just how things are, it's a work that does no useful work in any meaningful sense, but serves to make some already fabulously rich people even richer (in fact, it extracts that value from non-HFT traders, so even those are shafted here).

My point is that I'm curious regarding how the people who work in these things feel about their job. Do they think they're doing a right thing? Do they "own it" to themselves that they don't care as long as they make money? Do they not think about it too much?

Re:More challenging projects every programmer should try by sbeller on Wednesday December 23, 2020 @04:50PM (#25522638)
> (in fact, it extracts that value from non-HFT traders, so even those are shafted here).

in return HFT provides liquidity (and by that smaller spreads) to the market, I would think.

If you ever bought or sold a stock with a market order, you profited from the work the HFT is doing.

Re:More challenging projects every programmer should try by logifail on Tuesday December 22, 2020 @01:13PM (#25509290)
> it's a work that does no useful work in any meaningful sense, but serves to make some already fabulously rich people even richer

Isn't Robinhood able to offer free trading to customers solely because they sell their order flow on to, among others, HFT firms?[0]

[0] https://www.cnbc.com/2020/08/13/how-robinhood-makes-money-on...

Re:More challenging projects every programmer should try by MockObject on Thursday December 24, 2020 @12:43PM (#25529596)
The abstraction of "society", that is presumably supposed to benefit from everyone's job, is hiding the crucial details.

His job facilitates trades between people who want to trade with each other. Since they are part of society, our society benefits from his work.

Evidently it's doing more than "make some already fabulously rich people even richer", because it's paying salaries for some programmers, as well.

Re:More challenging projects every programmer should try by wizzwizz4 on Monday December 21, 2020 @11:57AM (#25496733)
I'd argue that “how do you justify” is more loaded. “Do you feel comfortable with [objective description of the reason one might be uncomfortable with it]?” is better than how I'd ask it.
Re:More challenging projects every programmer should try by KittenInABox on Monday December 21, 2020 @11:02AM (#25496081)
Intuitively, providing more flow + allowing more efficient allocation of resources via algo is pretty valuable to society. Problem is that society is squandering that efficiency.
Re:More challenging projects every programmer should try by wizzwizz4 on Monday December 21, 2020 @11:55AM (#25496718)
The stock market is about allocation of profits, and high-frequency trading is about extracting profits from the profit allocation system. This isn't investment we're talking about; this is the stock market.
Re:More challenging projects every programmer should try by IgorPartola on Monday December 21, 2020 @08:26PM (#25501841)
Thank you. That makes a lot of sense. The problem was that I was doing this on my residential cable connection from the US and the exchange where I was executing trades would be in Eastern Europe. The ironic thing is that even back then I had a good idea of how to set up communications with a server like theirs to be significantly faster but it didn’t occur to me that milliseconds mattered. A typical trade if they executed it almost instantly still took 300ms. And they didn’t execute instantly so it was closer to 2 seconds more likely than not. Out of curiosity, what are the fancy examples of this vs this simplistic one?
Re:More challenging projects every programmer should try by caffeine on Tuesday December 22, 2020 @04:35AM (#25504537)
Trading the same product on two exchanges is the most basic one because you know it's the same product, so correlation should be 1, assuming the cost to transfer between exchanges is zero. Example is arbing US equities.

Crypto is one level more complicated, because you don't share inventory across exchanges and transaction costs are high, which means a coin on Exchange1 isn't perfectly fungible with a coin on Exchange2.

One level more indirect than that might be basis trades, where you trade a derivative ( like SP500 futures) vs it's underlying (the SP500 stocks, although in practice it's SP500 ETFs). So here the correlation is very high but there is a difference between futures, stocks, and ETFs fundamentally, and those play into the pricing.

Going even further might be trading correlated products that don't have the same underlying, example is Nasdaq futures vs SP500 futures.

To simplify: It's basically about the level of correlation between the products. The strategies used to trade different correlations look qualitatively different.

Re:More challenging projects every programmer should try by IgorPartola on Tuesday December 22, 2020 @07:58AM (#25505784)
That makes sense and sounds pretty interesting. How “exciting” is this field in terms of innovation currently? Is it mostly about getting high level access to exchanges to speed up trading (which presumably requires paying your way in), or is it more about finding novel signals and ways to use them?
Re:More challenging projects every programmer should try by lordnacho on Monday December 21, 2020 @02:25AM (#25492829)
Quant trading guy here. Most likely your simulation didn't account for market impact. It's maybe the hardest bit. See liquidity based bullet points above.

Other place to look is whether the data was recorded with timestamps of where the trading happened, but you probably thought of that one.

Idea makes sense though.

Re:More challenging projects every programmer should try by IgorPartola on Monday December 21, 2020 @08:27PM (#25501847)
I was moving very small amounts. I think my Max trade was set at like $50 equivalent so it wasn’t anything crazy. It seems my main issue was latency and not realizing that my time scales should have been significantly shorter.
Re:More challenging projects every programmer should try by tim333 on Monday December 21, 2020 @06:03AM (#25493819)
>prices run away from you

I've found that stuff a lot. People forget that on the other end of the price is a thinking human or robo delegate thereof trying to outsmart you. It's really hard to say what will happen until you try it with real money / assets.

Re:More challenging projects every programmer should try by UnpossibleJim on Monday December 21, 2020 @12:04PM (#25496826)
I see a question, so I'm sorry to ask another but as someone who hasn't done algo trading I'm curious. How quickly are you actually able to trade. I understand with low level trading, through a broker, the trades can be pretty instantaneous. On penny stocks, though, sans broker and with just an API or website that you set up with a field bot, how quickly can you expect for these trades to go through, really?

I hear these horrid tales of people killing themselves over bad trades and lines of credit and I wonder how much is poorly written code and how much is the chaos and whim of the market (don't worry, I'm not going to try algo trading).

Re:More challenging projects every programmer should try by sitzkrieg on Sunday December 20, 2020 @07:57PM (#25491073)
same here, aits definitely worth pointing out (as you me tion) simulating execution and realisitic fills (and dont forget rt commissions!) is extremely difficult and also will absolutely kill strategies that casually look profitable
Re:More challenging projects every programmer should try by pjc50 on Sunday December 20, 2020 @06:53PM (#25490753)
I worked on a unique HFT system which was capable of starting the response packet before the incoming packet's final byte had arrived. Negative latency. If it mispredicted the future, it would simply scramble the trailer and cause the packet to fail UDP checksum.

It didn't make money in the real world because the quality of decision that could be made at that speed wasn't good enough.

Re:More challenging projects every programmer should try by djoldman on Monday December 21, 2020 @03:26AM (#25493098)
This was an open secret. You can also send the start of a datagram on every incoming packet and then abort if you don't want to add/modify/delete an order by splitting your datagram into multiple packets. This worked on some exchanges because they ordered add/modify/deletes by when the beginning of the packet was received as opposed to the end.

If you do too much of this you will get angry exchange network people yelling at you as they may consider it spam/ddos. Some exchanges explicitly limit this.

It's also worth considering the possible gain. If you're in the fpga (0-150ns) or cpu(300ns-3us) space, the math can come out differently.

Re:More challenging projects every programmer should try by tijsvd on Monday December 21, 2020 @03:10AM (#25493031)
This is not unique, it's standard practice. Many exchanges send large UDP packets with the most valuable information at the front. Or the packet is structured such that you can make an informed bet based on size and first sub-message.

Failing the checksum was sort of common as well, but exchanges don't like it.

These days most tricks have to do with avoiding as much serialisation time as possible, e.g. by sending ahead part of the TCP payload and filling in with some innocent order if there was no opportunity.

Re:More challenging projects every programmer should try by twic on Monday December 21, 2020 @08:28AM (#25494699)
Exchanges have cracked down on this sort of thing a lot this year.

From a letter from the CME to the CFTC dated July 24, 2020:

> On July 26, 2020, an enhancement to the Market Segment Gateway (“MSGW”) will be introduced to further safeguard the CME Globex electronic trading platform (“CME Globex”) infrastructure by introducing a delay of at least three microseconds if the MSGW receives a partial order message as a means of ensuring the stability of the platform. Certain participants intentionally submit partial order messages to reduce latency, and only complete the order message upon the happening of an event or trading signal. Implementation of the enhancement is expected to reduce the frequency of intentionally split order messages as the additional processing time will serve as a deterrent.

The letter is on the web, but it's a PDF; the Google search result has a redirect link to it, DuckDuckGo can't seem to find it, and Firefox on Android won't tell me the URL it downloads things from, so I'm afraid I can't link to it!

CME also made a more general change, where if they decide a participant is sending dodgy messages, they will reroute all their packets to a special gateway for "additional checks", but in practice, to impose a latency penalty. Can't find the documentation on that at all, though.

Re:More challenging projects every programmer should try by eneveu on Monday December 21, 2020 @06:27PM (#25500999)
Re:More challenging projects every programmer should try by inopinatus on Monday December 21, 2020 @02:26AM (#25492830)
From time to time there comes a remark that is the absolute epitome of Hacker News, and I mean that earnestly and without any backhanded rancour, and I thank you for this flawless specimen.
Re:More challenging projects every programmer should try by pjc50 on Monday December 21, 2020 @03:34AM (#25493143)
Re:More challenging projects every programmer should try by KMag on Monday December 21, 2020 @02:01AM (#25492726)
To get such changes reliably with low latency, I presume you were modifying the DMA buffer, without any syscalls or other mechanisms to synchronize between the CPU and the NIC's processor(s), right? Did you just set up the race condition such that when you got bitten, it resulted in a failed checksum, or was the time window so large that in practice the race condition never bit you?
Re:More challenging projects every programmer should try by pjc50 on Monday December 21, 2020 @03:30AM (#25493125)
It was in a ridiculously expensive 10Gbit ethernet switch with an FPGA built in. Having to write trading algos in Verilog was an extra layer of difficulties.

I don't think it stored the packet at all, just advanced a state machine as each word arrived from the MAC.

Re:More challenging projects every programmer should try by _huayra_ on Monday December 21, 2020 @01:06AM (#25492512)
Wow this is wild! I never thought things would get so latency-sensitive that one would have to overlap request and response!
Re:More challenging projects every programmer should try by guscost on Monday December 21, 2020 @07:36AM (#25494339)
HFT is so latency-sensitive that it matters how physically close you are on Manhattan island.

It is so latency-sensitive that new “hollow” fiber-optic cables are being installed, because light moves faster in air than in glass.

Re:More challenging projects every programmer should try by vntok on Monday December 21, 2020 @08:23AM (#25494663)
See also how they slow down the whole network to level the field: https://hackaday.com/2019/02/26/putting-the-brakes-on-high-f...
Re:More challenging projects every programmer should try by KMag on Sunday December 20, 2020 @09:58PM (#25491735)
That's super clever!
Re:More challenging projects every programmer should try by lordnacho on Monday December 21, 2020 @02:27AM (#25492835)
What was the rest of the infrastructure? Was this at a proper HFT firm with everything else streamlined?
Re:More challenging projects every programmer should try by pjc50 on Monday December 21, 2020 @03:36AM (#25493152)
We were consultants to an HFT firm; supposedly set up correctly but I didn't see that part of the project.
Re:More challenging projects every programmer should try by imtringued on Monday December 21, 2020 @02:54AM (#25492959)
The reality is that stock market trading is like a normal business selling products except you provide liquidity instead of products. Now imagine the market you have chosen needs 1000 widgets per day. If there are competing factories in the market place that already produce 1000 widgets then your only chance of breaking into that industry is by displacing existing competitors. You need to have a better product (or what the finance guys call an "edge"). The vast majority of people don't have such a product idea. They would probably just produce the same stuff the big guys have been making and then wonder why it isn't making them a profit. The market is already saturated with those widgets and there is no need for more factories.

Replace widget with liquidity and factories with traders and you should immediately see why most traders are losing money. They are operating in markets where their liquidity simply isn't needed.

If you want to make money off of trading then you have to find a market with low liquidity where having more traders is actually welcome but why do hard work if you can just invest your money and still get good gains without working?

Re:More challenging projects every programmer should try by ddls on Tuesday December 22, 2020 @08:34AM (#25506059)
Because

- management fees, margins, and available capital can easily be modelled properly

- you can easily set up constraints (like no fractional trading for your S&P example)

- you can set up a proper point-in-time database to avoid snooping (especially if you're using earnings reports or other fundamental data which is often actually released _after_ it's published release date...)

- you can set up regime-shifting simulation environments (various market conditions)

- you can avoid over-fitting if you're back-testing (with dozens of techniques, most notably : test once and forget about parameter optimization)

I would say that with paper trading and back-testing the serious problems are that :

- your orders don't show up on the book so no one sees and reacts to your limit orders

- your "filled" orders don't affect the book, so you're not affecting liquidity, so the market doesn't change in response to your trading

- your bot has no access to market micro-structure strategies and conditional orders (and if you want to trade fast or are placing big trades you need them)

These are the problems that make any simulation unrealistic, and they are fundamental. It's shadowboxing, which is not entirely devoid of value, but which is certainly insufficient on its own.

(I've worked as a quant developing strategies for several funds these past 15 years)

Re:More challenging projects every programmer should try by gjvnq on Sunday December 20, 2020 @07:37PM (#25490968)
I tried making a bitcoin trading bot and almost all of the money (about 10 bucks, not no big problem).

My main mistake was using the historical trades instead of the historical offers as a testing dataset.

Re:More challenging projects every programmer should try by kamel3d on Sunday December 20, 2020 @08:38PM (#25491288)
did it work at the end? I want to make a crypto trading bot seems simpler than stock one
Re:More challenging projects every programmer should try by m3at on Sunday December 20, 2020 @11:13PM (#25492065)
Not the GP but I made trading algorithm for a living (not on crypto) and have friends still doing that (on crypto): yes it can work, but in 99% of cases you shouldn't do it for the money. Let me expand:

If you can afford to spare part of your income and invest that for long term buy and hold, that'll work better (ex. ETF).

If you can't spare anything, focusing on leveling up trendy skills, then you can land a better job on the short term.

However if you just want to trade for the fun of it, yes crypto can be simpler than stock, mainly because the API are better. Set up a maximum budget as a safety net and enjoy :)

Re:More challenging projects every programmer should try by elbear on Monday December 21, 2020 @10:12AM (#25495607)
Could you share what you learned in order to make that trading algorithm?
Re:More challenging projects every programmer should try by imtringued on Monday December 21, 2020 @02:58AM (#25492981)
If you can find some barely known crypto with a lack of liquidity then you might be able to get your feet wet and test out your algorithms. Doesn't mean you will earn a lot of money.
Re:More challenging projects every programmer should try by deanCommie on Wednesday December 23, 2020 @04:32AM (#25515970)
> You can trade ETFs that are tied to an index but an index is not a tradable instrument in of itself.

Out of curiousity, what's the difference?

Re:More challenging projects every programmer should try by contingencies on Monday December 21, 2020 @08:57AM (#25494954)
Good list. You forgot "over-fitting your algorithm to historical data".