[rotskoff]

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."

[cgmorton]

"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."

[andr]

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]

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]

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]

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.

[pdovy]

Yeah this seems like a baseless claim to me. I work on these kinds of applications and we always assume that an order is eligible to execute from when it's sent until the exchange confirms it has been canceled/deleted. This is pretty standard and it's surprising that a big bank would have such an obvious hole in their risk system, and disappointing that they would then fail to take responsibility for their own mistake.

[cube13]

I think the standard IPO buying strategy for a large institution like UBS is to make many large buy requests to make absolutely sure that all the brokers that want stock get it, then cancel when enough orders are fulfilled.

Since interest was very high on the FB IPO, the assumption would be that it would be fairly hard to actually get stock. So the bank would make a lot of requests, on the hope that a certain percentage would be fulfilled immediately(say 30-40%), after which they could cancel the remaining orders.

Unfortunately, this turned out not to be the case, because a LOT of FB stock was released to the market. Add to that that NASDAQ(as UBS contends) did not give a confirmation ID to UBS, and it's pretty easy to see why this happened.

[sp332]

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]

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.

[Camillo]

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]

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.