4 ms·

If you trade highly leveraged stuff, you need stop losses; otherwise there is a considerable chance you will go bankrupt. Especially when you take bets on inter

If you trade highly leveraged stuff, you need stop losses; otherwise there is a considerable chance you will go bankrupt. Especially when you take bets on interest rate decisions, take the sweeps at market open and other stuff (you can gain a few hundred points on NQ1! per contract easily during such times). Also, it's a psychological thing: traders think in risk. If they were mistaken with a trade idea, they close the position with a small loss. Easy, just move on to the next! But when a position is already deep in the reds, it becomes increasingly harder to press the "close"-button and realize the loss. I know somebody who lost a few hundred grand just a few weeks ago because he was unable to close the position. He didn't set an initial stop loss, and then started believing in his trade (or the company) too much, although the market was telling him otherwise. He started doing dollar cost averaging and other stupid stuff. Actually, this guy is incredibly smart, but became too attached. I feel genuinely sorry for him. But that's what happens, when you don't have the discipline.

nradov 4y ago
Stop loss orders can work reasonably well for retail investors trading small positions in liquid securities, but they aren't completely reliable. Sometimes prices make a sudden discontinuous drop on bad news and blow past the limit order before it can be executed. Or if trading is halted they become useless. And for institutional investors trading large positions in less liquid markets, stop loss orders barely work at all. They usually employ more sophisticated hedges.
- dragonwriter 4y ago
  Sure, and a helmet and bulletproof vest with trauma plates doesn’t stop you from getting killed by shot in the face. But the lack of complete protection is a pretty bad argument against using the available protection. (There's some things a stop-limit is better for than a regular stop loss, but I'm not convinced that they are generally superior except in the technical sense that any stop loss can be issued as a stop-limit with a $0 limit.)
  - KMag 4y ago
    Minor nit pick: some products, such as exchange-traded calendar spreads, have prices that can go negative and in fact don't have a lower limit on price. When I was writing trading systems, it was a big headache to modify a system original designed only for equities to handle other asset types, especially those that could have negative prices.
    - KMag 4y ago
      Side note: if you're using IEEE-754 doubles (not a great choice for decimalized prices), use NaN to indicate no price, missing price, etc. instead of using an "impossible" value like -1.0. It's always possible the system will be expanded to some domain where -1.0 is valid, requiring lots of on-the-fly rewriting of live systems literally handling multiple billions of dollars per day. Better yet, use proper algebraic data types.
    - neomantra 4y ago
      Fun fun, that must have been quite the project! Price is so cross-cutting to such systems. When I added futures to my first system (>15 years ago), I had no idea about negative prices and had tons of sanity checks, including positive price checks. Even in 2020, some popular trading platforms failed to handle when oil futures went negative! Opportunity for the prepared, I suppose. EDIT: Oh and saw your follow-up -- we used 0 to represent "market" which is clearly broken in this scenario. Works fine for positive-only prices though :)
      - KMag 4y ago
        There are all kinds of problems with optionality not being properly represented in the data. At a C level, you really want a tagged union, and preferably you're using a higher level language that has first-class algebraic data types (which end up looking just like tagged unions, tagged pointers, or NaN-boxed values at the hardware level). We had one bespoke protocol for communicating between the order management system (conceptually a high-reliability database that holds order state and communicates with components connected to exchanges) and the trading engines (higher code churn rate, and can recover order state from the order management systems if they need to be restarted, so less critical). When we created a second version of the order management system, we created a wholly new bespoke messaging protocol where every field was optional with a default value, and had an unfortunate feature that if one side set a field in a message to the default for that data type, the messaging layer would size-optimize the messages by removing that field. Combined with encoding order amendments as messages where all of the unchanged fields were removed, it meant that if an order ever had a field amended to a default value, the other side of the communication would interpret it as no change, and would acknowledge the message but not amend the value. It wasn't a big deal for a lot of the order paremeters that got thrown into a single customization string, since it probably wasn't actually possible to amend on order to become completely vanilla (upstream systems tacked on some customizations between receiving the order from the customer and presenting the order to the OMS). However, amending a price to zero would result in this space-saving optimization, and the trading engine would interpret it as no change in price. The API did have separate calls for getting a field value (which would transparently return the default value for missing fields) and for checking if a value was actually specified. Though, due to the "optimization" in the messaging layer, checking of a value was specified was really just a check if the returned value was equal to the default value.
baobabKoodaa 4y ago
> If you trade highly leveraged stuff, you need stop losses; otherwise there is a considerable chance you will go bankrupt. This is false. In the context of high volume trading (which we are discussing here), a naive stop loss will obliterate any profits you might accrue with your strategy. Execution of your stop loss will simply eat through the whole order book and give you the worst possible price for your exit.

nradov 4y ago

Stop loss orders can work reasonably well for retail investors trading small positions in liquid securities, but they aren't completely reliable. Sometimes prices make a sudden discontinuous drop on bad news and blow past the limit order before it can be executed. Or if trading is halted they become useless. And for institutional investors trading large positions in less liquid markets, stop loss orders barely work at all. They usually employ more sophisticated hedges.

dragonwriter 4y ago
Sure, and a helmet and bulletproof vest with trauma plates doesn’t stop you from getting killed by shot in the face. But the lack of complete protection is a pretty bad argument against using the available protection. (There's some things a stop-limit is better for than a regular stop loss, but I'm not convinced that they are generally superior except in the technical sense that any stop loss can be issued as a stop-limit with a $0 limit.)
- KMag 4y ago
  Minor nit pick: some products, such as exchange-traded calendar spreads, have prices that can go negative and in fact don't have a lower limit on price. When I was writing trading systems, it was a big headache to modify a system original designed only for equities to handle other asset types, especially those that could have negative prices.
  - KMag 4y ago
    Side note: if you're using IEEE-754 doubles (not a great choice for decimalized prices), use NaN to indicate no price, missing price, etc. instead of using an "impossible" value like -1.0. It's always possible the system will be expanded to some domain where -1.0 is valid, requiring lots of on-the-fly rewriting of live systems literally handling multiple billions of dollars per day. Better yet, use proper algebraic data types.
  - neomantra 4y ago
    Fun fun, that must have been quite the project! Price is so cross-cutting to such systems. When I added futures to my first system (>15 years ago), I had no idea about negative prices and had tons of sanity checks, including positive price checks. Even in 2020, some popular trading platforms failed to handle when oil futures went negative! Opportunity for the prepared, I suppose. EDIT: Oh and saw your follow-up -- we used 0 to represent "market" which is clearly broken in this scenario. Works fine for positive-only prices though :)
    - KMag 4y ago
      There are all kinds of problems with optionality not being properly represented in the data. At a C level, you really want a tagged union, and preferably you're using a higher level language that has first-class algebraic data types (which end up looking just like tagged unions, tagged pointers, or NaN-boxed values at the hardware level). We had one bespoke protocol for communicating between the order management system (conceptually a high-reliability database that holds order state and communicates with components connected to exchanges) and the trading engines (higher code churn rate, and can recover order state from the order management systems if they need to be restarted, so less critical). When we created a second version of the order management system, we created a wholly new bespoke messaging protocol where every field was optional with a default value, and had an unfortunate feature that if one side set a field in a message to the default for that data type, the messaging layer would size-optimize the messages by removing that field. Combined with encoding order amendments as messages where all of the unchanged fields were removed, it meant that if an order ever had a field amended to a default value, the other side of the communication would interpret it as no change, and would acknowledge the message but not amend the value. It wasn't a big deal for a lot of the order paremeters that got thrown into a single customization string, since it probably wasn't actually possible to amend on order to become completely vanilla (upstream systems tacked on some customizations between receiving the order from the customer and presenting the order to the OMS). However, amending a price to zero would result in this space-saving optimization, and the trading engine would interpret it as no change in price. The API did have separate calls for getting a field value (which would transparently return the default value for missing fields) and for checking if a value was actually specified. Though, due to the "optimization" in the messaging layer, checking of a value was specified was really just a check if the returned value was equal to the default value.

baobabKoodaa 4y ago

> If you trade highly leveraged stuff, you need stop losses; otherwise there is a considerable chance you will go bankrupt. This is false. In the context of high volume trading (which we are discussing here), a naive stop loss will obliterate any profits you might accrue with your strategy. Execution of your stop loss will simply eat through the whole order book and give you the worst possible price for your exit.