5 ms·

If you take a look at the UBS quarterly report, you can read the specifics of their claim (quoted below and available in full on the UBS website). Essentially,

If you take a look at the UBS quarterly report, you can read the specifics of their claim (quoted below and available in full on the UBS website). Essentially, the bank asserts that NASDAQ initiated buy requests multiple times. Had Facebook stock sky-rocketed, as anticipated, I wonder if we would have ever heard a word of this? "Due to multiple operational failures by NASDAQ, UBS’s pre-market orders were not confirmed for several hours after the stock had commenced trading. As a result of system protocols that we had designed to ensure our clients' orders were filled consistent with regulatory guidelines and our own standards, orders were entered multiple times before the necessary confirmations from NASDAQ were received and our systems were able to process them. NASDAQ ultimately filled all of these orders, exposing UBS to far more shares than our clients had ordered. UBS's loss resulted from NASDAQ's multiple failures to carry out its obligations, including both opening the Facebook stock for trading and not halting trading in the stock during the day. We will take appropriate legal action against NASDAQ to address its gross mishandling of the offering and its substantial failures to perform its duties."

Camillo 14y ago
Shouldn't their "system protocol" have a way for the the server to recognize resends of orders it has already received, and ignore them?
- veyron 14y ago
  You may actually want to send multiple orders, which is why pretrade duplicate checks usually assume a fixed window (2 orders of the same price/quantity/side in a 50 msec window) For example, sending a large order to the market looks different from many smaller orders.
andr 14y ago
The order workflow is generally like so: 1) Client sends order to market. 2) Market acknowledges it has received the order, sending back the market-generated order ID. 3) The market tries to fill the order (takes from 1ms to a day, depending on the type of order). When the order is filled, the client is informed. 4) At any time before the order is filled, the client can cancel it. Perhaps during NASDAQ's issues the acknowledgements (step 2) were not sent and UBS didn't have the IDs of the orders they wanted to cancel.
- lambda 14y ago
  So, shouldn't the protocol involve the client generating the order ID, so that they can cancel the order without having yet gotten confirmation of it? Or at least, the client being able to include a "client handle" for this purpose, that is independent of the order ID but which they can use to refer to it before they've gotten the ID?
  - giulianob 14y ago
    Or have it do some high level of QOS where both sides need to acknowledge that the other side received the message otherwise cancel the request. This is pretty much what TCP does.
- veyron 14y ago
  The real problem, according to UBS, is that in absence of an acknowledgement they sent extra orders. UBS improperly acted. The first rule when you set up risk limits is to consider both actual position (acknowledged) and theoretical position (assuming all orders are filled). Standard risk controls would have prevented this.
  - sp332 14y ago
    How long do you wait before realizing that the system did not get your request? If you want to own some FB stock, and your request is not acknowledged, the obvious thing to do is send another request.
    - pdovy 14y ago
      It's better to miss an opportunity than potentially expose yourself to a loss. If the exchange side system has become obviously unreliable (not responding to requests would count here), it's generally wise to stop trading. I can see the temptation to just forge ahead on a one time only event like an IPO, but if you do so then I think you need to be prepared for the consequences. I also imagine that part of the usage terms for direct access include something that limit Nasdaq's liability in the event of a system error, so I'm not sure how UBS thinks they will get around that.
cgmorton 14y ago
"Thank you for your placing an order with NASDAQ. Please do not hit the back button or refresh this page, or your order may be registered more than once."

Camillo 14y ago

Shouldn't their "system protocol" have a way for the the server to recognize resends of orders it has already received, and ignore them?

veyron 14y ago
You may actually want to send multiple orders, which is why pretrade duplicate checks usually assume a fixed window (2 orders of the same price/quantity/side in a 50 msec window) For example, sending a large order to the market looks different from many smaller orders.

andr 14y ago

The order workflow is generally like so: 1) Client sends order to market. 2) Market acknowledges it has received the order, sending back the market-generated order ID. 3) The market tries to fill the order (takes from 1ms to a day, depending on the type of order). When the order is filled, the client is informed. 4) At any time before the order is filled, the client can cancel it. Perhaps during NASDAQ's issues the acknowledgements (step 2) were not sent and UBS didn't have the IDs of the orders they wanted to cancel.

lambda 14y ago
So, shouldn't the protocol involve the client generating the order ID, so that they can cancel the order without having yet gotten confirmation of it? Or at least, the client being able to include a "client handle" for this purpose, that is independent of the order ID but which they can use to refer to it before they've gotten the ID?
- giulianob 14y ago
  Or have it do some high level of QOS where both sides need to acknowledge that the other side received the message otherwise cancel the request. This is pretty much what TCP does.
veyron 14y ago
The real problem, according to UBS, is that in absence of an acknowledgement they sent extra orders. UBS improperly acted. The first rule when you set up risk limits is to consider both actual position (acknowledged) and theoretical position (assuming all orders are filled). Standard risk controls would have prevented this.
- sp332 14y ago
  How long do you wait before realizing that the system did not get your request? If you want to own some FB stock, and your request is not acknowledged, the obvious thing to do is send another request.
  - pdovy 14y ago
    It's better to miss an opportunity than potentially expose yourself to a loss. If the exchange side system has become obviously unreliable (not responding to requests would count here), it's generally wise to stop trading. I can see the temptation to just forge ahead on a one time only event like an IPO, but if you do so then I think you need to be prepared for the consequences. I also imagine that part of the usage terms for direct access include something that limit Nasdaq's liability in the event of a system error, so I'm not sure how UBS thinks they will get around that.

cgmorton 14y ago

"Thank you for your placing an order with NASDAQ. Please do not hit the back button or refresh this page, or your order may be registered more than once."