Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's the SECs job to regulate securities and exchanges. They regulate people, they can regulate algorithms.

It's not like Congress is passing a law that regulates what encryption standards can and cannot be used. It's the SEC regulating trade on the stock market no matter who or what is conducting the trades. Whether they should or should not ban it, it's well within their authority.

You're trying to make it into an all-computing type of issue. It's not. There is no slope, and it's certainly not slippery.



The SEC can get involved. The question is whether they should. See, people who write "bad" algorithms already get punished by the market and lose money. They already have an interest in improving.

What would a regulation against "bad" algorithms even look like?


> See, people who write "bad" algorithms already get punished by the market and lose money.

You've misunderstood what is meant by "bad" algorithms. They aren't universally "bad". The vast majority of the time they make a ton of money. The problem is, the reason they make money is because they have limited safe guards that protect it from doing something stupid 99% of the time, but the remaining 1% is left a mess in order to ensure that 99% of the time they execute faster than the next guy. Unfortunately, they are an increasingly dominant force during that 1% window because they are a few nanoseconds faster to make a trade the rest of the time.

> What would a regulation against "bad" algorithms even look like?

You don't regulate the algorithm, just like you don't regulate against bad traders. What you do is set the rules so that the risks & rewards favour a healthy ecosystem. If sub millisecond trading yielded no benefit, it'd do a lot to prevent problems.


Simple. All trades have a random time from 0-10 seconds prepended as a delay before the exchange starts the process to execute the trade.

Suddenly, microsecond trading algorithms are dead.


Nope. That existed for many years in implementation details at exchanges and the games were worse.

What actually happened in those cases is liquidity went away faster in drastic moves and the spreads had to account for the risk.

Further, you'd have all manner of snake oil consultants that would be selling true secrets of the NASDAQ randomizer (this exact thing happened before the exchanges standardized colocation. Guys would claim only they knew where in a data center had the shortest cable runs for instance). All of that inefficiency gets priced into the spread and is paid by all market participants.

If you really want to get rid of microsecond trading (I don't know why you'd care honestly, but if you did) get rid of the sub-penny rule. Make market making algorithms truly compete on price. Speed will still be important for canceling orders/gathering information, but you could counteract it by trying to do what we actually want the algos to do. Discover the right price cheaply.


No, this is wrong. You've simply increased the complexity and hence the risk of submitting a bid/ask which is going to lead to increased spreads and increased costs for people who buy and sell stock.


Um, so?

The goal here is to cut down on automated meltdowns caused by people trying to get a microsecond jump on everybody else.

A stock price is supposed to have some relation to the value of the company. With HFT, it is pretty clear that we left that realm many moons ago.

A random time within 10 seconds is hardly going to affect the stock price significantly. The fact that stock is going to be a couple of pennies more expensive isn't exactly going to gather any sympathy from me. And, a bigger bid/ask spread will stop stock price meltdowns which are more momentum-based (aka trader driven) rather than actual real information (aka business driven).


They should be forced to give some of those losses back.


"Giving back losses" was supposed to be humorous. Apologies.


? For the most part, they tend to be the ones who lose.. so they've already given them back.


They did, before the end of the session.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: