Change of symbol/instrument details due to corporate actions

, ,
1

Imported from previous forum

2

Thanks! That covers my question.

My mention of suffix wasn't about the SymbolSfx(65) field, it was a reference to the practice of appending a character to seperate a non-standard adjusted derivatives contract after a corporate action to differentiate the symbol from that of a standard contract (eg: DELL --> DELL1). In any case, these name changes can also be handled as you described.

3

I am looking to publish an instrument list (for clearing purposes) using the SecurityList message. The main identification fields I will be using are the Symbol, the ISIN, and a series of long/short names and descriptors (other than the symbol, the rest are contained within the SecAltID group). Symbol is the main form of identification, and ISIN is secondary (there is a low possibility that ISIN will not be present for some instruments)

In the event of a symbol and/or ISIN change (there is a possibility both may happen together)I am looking for a way to communicate what the original instrument is to the outside party. There appears to be nothing in the lines of a "previous" symbol

There is an invariant internal identifier available that I considered publishing in the SecurityID field to assist in identifying what the original instrument was, however the FIX defintion of this and the Symbol field implies that it takes secondary priority to Symbol in identifying an instrument.

So the question is, which is the more consistent approach

a. Use securityID with an internal invariate identification, with guidelines to users to capture this field and use it to identify a change of symbol against their historical data?

b.Introduce a new (or use an existing, if I missed it) field to reference the previous symbol?

c. Flag the change of symbol through some other field (eg: Using the Event groups?) Or a different message such as SecurityStatus?

The current scope of the list is equity and fixed income, though it would be desireable to have a method is consistent for derivatives (eg: change of symbol name through addition of a suffix when an ex adjustment series is launched)

4

If I understand your requirement correctly then you would like to change the primary key of an instrument. FIX does not provide a concept with OrigXXX fields like it does for orders or trades. However, you can use the SecurityListUpdateReport message for that purpose as follows.

  1. Use a separate message for each instrument being subject to that change
  2. Put the "same" instrument twice in the repeating group SecLstUpdRelSymGrp (NoRelatedSym=2), making the old identification the first entry and the new identification the second (and last) entry
  3. Set ListUpdateAction(1324) to M=Modify
  4. Use the SecurityStatus(965) field and set it to 2=Inactive in the first entry and 1=Active in the second entry

The sematic is then that you are replacing one by the other and not deleting the old and adding a new instrument. The user can keep a mapping table to be able to semantically tie together trades under the old and new primary key.

After the update messages for each affected instrument you can distribute the entire list of all instruments again with the SecurityList message and use the new primary keys of the instruments where a change took place.

Please note that SymbolSfx(65) should not be used to make Symbol(55) unique. I am not sure whether you meant this with "addition of a suffix" above. It is only for additional information on the instrument and currently only applicable to fixed income.