Live data from Hacker News

Case study: Algorithmic trading with Go

polygon.io

131–140 of 311 posts

Re: Case study: Algorithmic trading with Go

#131
post #57

also having worked in the space: HFT should not exist. Break up the day into segments and have a single crossing. Do it every five minutes or whatever for sufficient timeliness. the millisecond race does not make anything better for anybody except the people doing the trading.

There should be transaction fees on all trades on all exchanges that go to the government, yes I mean a tax.

Why?

Re: Case study: Algorithmic trading with Go

#132

Earlier quoted context omitted.

[flagged]

> but overall it performs a valuable economic function Can you explain what that is? > To understand this requires understanding markets very deeply Apparently you aren't the only person on this forum who does. Are we just supposed to take your word for it?

He’s referring to the fact that the HFT “provides liquidity” as in getting a share off your hands and flipping it to someone else that is not you a moment later. This way you didn’t have to wait 3 seconds or 1 minute or whatever to sell your shares because someone knew they could flip them (alpha) on a short notice so they participated in a transaction with you. He’s assuming that without the HFT, the transactions wouldn’t be as frequent and you’d have to either a) wait for the fill on your trade , or b) lower your ask price if selling under time deadline. Analogously for buy orders.

The only parties with semi-global visibility are prime brokers by definition; they see every position of everyone who custodies with them.

The parties with global visibility of the US market are TRF (trade reporting facility) and those are the only parties who can sort of evaluate the HFT claims without bias or vested interest. Most of the studies in the field have some sort of an angle or vested interest so it’s hard to evaluate the veracity of the claims one way or another.

A counterpoint to HFT is that stock markets existed before the the advent of computers and they had runs, panics and blow ups just like regular markets do now.

Re: Case study: Algorithmic trading with Go

#133
While I was laid off and looking for work, I connected with a cryptocurrency market making firm that had access to a private broker feed which is not attached to any matching, so would occasionally go crossed and offer a pure arb opportunity for the same pairs. I had done some algo trading with Java in Kospi 200 options in 2011-2012 so I decided to put together a simple bot for them to try and grab the crossed markets when they occur. Even an incredibly simple trade like this requires quite a lot of work to get the risk management in place. I also took it as a chance to catch up on new Java features since I had been out of that ecosystem for awhile.

It did successfully grab the arbs but there wasn't enough juice to justify more work on it and I got a job in the meantime, so I open sourced the whole thing: https://github.com/abissell/cempaka

Re: Case study: Algorithmic trading with Go

#134

I've been building a bot with Typescript because it is what I know and Python because of the tools available. It is an overwhelming lonely endeavor. With all my other projects, I've always worked on teams, although they have always been very small teams and most of my work was autonomous -- still there was the occasional meeting and stand-ups. I've been working on this for six months and thought about bringing a frie…

This article is well-timed as I was about to use options monitoring as an excuse to get into some other technologies. Probably not going to make a ton of progress as a side project, but I'm always up for a chat!

Re: Case study: Algorithmic trading with Go

#135

Earlier quoted context omitted.

Single point of failure is a simple justification right off the top of my head. What happens if you have a critical failure that brings down an exchange for several days?

As a counter I had some VW shares I couldn’t access for 6 months because they were moved to another exchange. 20 calls to the broker to find out what had even happened. Eventually I was able to sell them.

What do you mean « moved to another exchange » ?

Shares are not held at an exchange.

Re: Case study: Algorithmic trading with Go

#136
post #2

Happy to answer any questions about this. It's been a side project that turned into a full blown obsession. There is nothing too secret about the system since it's more about having a solid platform that you can plug your strategies into. I'd probably even open source it but I'd have to clean up all my hacks :)

You connect to IB's TWS API... If you execute your trade there only, wouldn't it be an option to fetch the price in real-time from the IB API and not having to use polygon.io at all?

I have no idea: does IB send the price feed in real time? (they certainly send the data in real-time to TWS as it constantly updates right? But is the order book available through their API?)

Basically and even though I know this was published on polygon.io's blog, would that work by only using IB / TWS's API?

Re: Case study: Algorithmic trading with Go

#137
post #57

also having worked in the space: HFT should not exist. Break up the day into segments and have a single crossing. Do it every five minutes or whatever for sufficient timeliness. the millisecond race does not make anything better for anybody except the people doing the trading.

[deleted]

Re: Case study: Algorithmic trading with Go

#138

Earlier quoted context omitted.

> but overall it performs a valuable economic function Can you explain what that is? > To understand this requires understanding markets very deeply Apparently you aren't the only person on this forum who does. Are we just supposed to take your word for it?

He’s referring to the fact that the HFT “provides liquidity” as in getting a share off your hands and flipping it to someone else that is not you a moment later. This way you didn’t have to wait 3 seconds or 1 minute or whatever to sell your shares because someone knew they could flip them (alpha) on a short notice so they participated in a transaction with you. He’s assuming that without the HFT, the transactions wo…

I don’t have time to reply properly until a few hours from now.

In the meantime what I can say very simply in the hope that someone else knowledgeable can contribute earlier.

It’s simply an empirical fact that the costs of intermediation to the system are the lowest they have ever been. The US and other global electronic markets are incredibly efficient and deliver unmatched liquidity, information efficiency, and the lowest costs to the entire capital markets than at anytime in history. That march forward is continuous and brutally competitive

There are many many way to see this and measure it, any serious quantitative analysis, by professionals, for instance trained in econometrics and with access to the raw data, like those at say the Fed, or those operating exchanges, as examples.

Re: Case study: Algorithmic trading with Go

#139

While I was laid off and looking for work, I connected with a cryptocurrency market making firm that had access to a private broker feed which is not attached to any matching, so would occasionally go crossed and offer a pure arb opportunity for the same pairs. I had done some algo trading with Java in Kospi 200 options in 2011-2012 so I decided to put together a simple bot for them to try and grab the crossed market…

Cool. Did you think Java was a good choice for this kind of work? Why not Go like OP or something else?

Re: Case study: Algorithmic trading with Go

#140

Go itself, or any other language won't give you too much of an advantage. What gives you advantage is trading algo, which is always hard to find. I've spent months on figuring out the best parameters for trading. Ended up this working only on historical data, while in reality it was totally different. I could use Visual Basic, and it would be better than Go, Rust, or whatever it is out there, given the algo and strat…

> What gives you advantage is trading algo, which is always hard to find.

At the end it is necessary to make a decision whether to buy or sell (and how much), which will compete with other decisions made based on some logic. Developing such a logic (strategy) manually is of course quite difficult. I developed an intelligent trading bot which derives its trading strategy from historic data:

https://github.com/asavinov/intelligent-trading-bot

Currently it works for cryptocurrencies but can be applied to other markets:

https://t.me/intelligent_trading_signals

> I've spent months on figuring out the best parameters for trading. Ended up this working only on historical data, while in reality it was totally different.

It is a typical situation. The whole problem is to develop a strategy which works for future (unseen) data. Even backtesting algorithms should be designed in such a way that future experience (data) does not leak to the past.

Post reply on HN