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