Imported from previous forum
Locate Code on a US Tied-Stock Complex Option Order
Does anyone have a suggested method for including locate information when submitting a tied-stock complex order to the US options market when the equity leg is a sell short? The simplest solution that I can think of is to include the usual LocateBroker(5700) or the LocateIdentifier(5701) tag at the top message level of the complex order. I’m saying that for the following two reasons:
- All the US options exchanges that support complex orders limit their members to one equity leg per NewOrderMultileg(AB) message. (and I haven’t heard anything about that changing)
- The LocateReqd(114) tag is currently defined on the NewOrderMultileg(AB) message.
However I can appreciate that it might be more ‘correct’ to keep the locate information on the equity leg. For those people who have customers sending tied-stock complex orders where the customer is shorting the equity leg, how do you allow them to indicate the broker code that they’re using to locate the inventory?
Some background for those who might be curious…
Locate Codes
In the US equities space, a person can borrow a security from a third party with the intention of buying back the same security at a later date. This arrangement of borrowing is referred to as a ‘locate’. When that person sends their order to sell short the security to their broker, they must confirm what broker-dealer from which they are borrowing the securities. Note, many times it is the same broker-dealer to which they’re sending the order. (feel free to google ‘short sale’ for a much more complete picture)
In early 2000 the SEC approved a rule that required a broker-dealer to require a locate code before accepting a short sale order from any nonmember (non-FINRA) broker-dealer. So today whenever a registered broker-dealer receives an order to sell from a customer that is not a (registered) broker-dealer, there must be a ‘locate’ code specifying where the customer is going to borrow the inventory. If that information is NOT there, the broker-dealer must either be willing to commit their own inventory or they can not accept the order. This prevents the dreaded ‘naked short sales’ that you may have read so much about in 2008. ::: cute spooky music :::
Stock-Tied Option Orders
In the US listed options space, often times a trader wants to employ an investment strategy where they simultaneously take a position in an underlying security while taking on one or many derivative positions (in this case, using listed US options). When doing these transactions there is a risk of adverse selection. The trader would prefer a way to put on all these positions on at the same time.
(Also) In early 2000 some of the US listed options exchanges began offering a kind of order where there is one equity leg and one or more option legs. This is sometimes referred to as a tied-stock complex order or just a buy/write (though technically a buy-write/covered call strategy is more narrowly defined). The order is submitted as a NewOrderMultileg(AB) to the exchange where one leg is an equity and one or more of the legs is a US listed option. The exchange will not fill any part of the individual legs unless each leg component can be filled in proportion.
To achieve this atomicity, the options exchanges will lock their order book as they go to find the opposite side of the equity leg. Once found they will execute the option portion and the member that entered the order gets each portion of the leg filled in proportion to the order.
That’s a really good question…
First off, the tags LocateBroker(5700) and LocateIdentifier(5701) exist in a rather liminal state. Ostensibly, they are user-defined, as they are numbered in the 5000 range. However, they are part of a small group of user-defined tags where FPL endorsed their usage, in this case for Reg SHO compliance purposes. See http://www.fixprotocol.org/documents/1004/FPL%20Americas%20REG%20SHO%20(2).pdf
As stated in that document, these two fields are for use in FIX 4.0-4.2.
FIX 4.3 and above make use of the Parties component. One should send the locate broker in PartyID(448) where PartyRole(452) = 8 - Locate / Lending Firm (for short sales). And within this repeating group instance, one specifies a PtysSubGrp component. The locate ID is sent in PartySubID(523) where PartySubIDType(803) = 27 - Security locate ID.
Now 803=27 doesn’t exist in FIX 4.4; it was added in FIX 5.0. However, I would consider sending 803=27 in FIX 4.4 to be an acceptable deviation, and I’d imagine most FIX engines wouldn’t make too much fuss about an unknown enumeration in a known field. Or, tag 803 could be omitted entirely, and the inference would be that the PartySubID of a locate broker is always the locate ID.
Now it seems what you are asking is a trick question. New Order - Multileg didn’t exist in 4.2; it first appeared in FIX 4.3. And that’s also when the Parties block first appeared. So if you are using New Order - Multileg, it follows that you should be specifying this in the Parties block and not using 5700 and 5701.
If so, that provides a very nice answer to your question. New Order - Multileg has a Parties component at the root level, which would apply to all legs. If a multileg order could have, at most, one equity leg, then this could be used. But the message also has a LegOrdGrp component, and that component contains the NestedParties component. The fields NestedPartyID(524), NestedPartyRole(538), NestedPartySubID(545) and NestedPartySubIDType(845) are analogous to the fields in the Parties and PtySubGrp components. So they could be used if one wished to send a locate ID and broker for a specific leg, and it would permit a multileg order to have multiple equity short legs.
One additional complication:
LocateReqd(114) exists only at the root level of New Order - Multileg. Some inference may be required if a New Order - Multileg has multiple short equity legs. E.g. if LocateReqd=Y, one short equity leg specifies a locate broker and ID in NestedParties, and one leg doesn’t, that could mean the broker must do a locate for the leg where no ID was specified, but shouldn’t do a located for the leg where an ID was specified. That isn’t entirely clean; I think a business case could be made to amend the FIX spec to add a LegLocateReqd field.
Unfortunately, even if FPL added the field, there would be implementation challenges. I’d guess a fair number of FIX implementations may have issues with inserting a field they don’t know about in the middle of a repeating group.