OrderAttributeType and reserved PartyID Short Code values

Robert Mitchell
29 May 2017 5:05pm
Can anyone help clear up the overlap between the reserved short code PartyID values for AGGR, and PNAL and the OrderAttributeType values for AGGR, PNAL, ALGO, etc.?
It seems like AGGR and PNAL can be represented both in Short Code and in OrderAttributeType. And Liquidity provision OrderAttributeType value can be equally well represented in TradingCapacity value 6 (Market Maker).
Algorithmic order in OrderAttributeType can be represented in PartyRoleQualifier value 22 (Algorithm).
But Risk reduction order and Systemic internalizer orders can only be represented using the appropriate OrderAttributeType.
My question, I suppose, is why the partial overlap? Would it not be best to have a single field (OrderAttributeType) to represent this information and purge the partially overlapping values from the proposed Short Code reserved values and TradingCapacity to make it clear how users should be representing this information?
And while we’re talking about OrderAttributeType/OrderAttributeValue, it seems clunky to use the Type/Value pattern here when the value is only ever “Y”.

Hanno Klein
30 May 2017 8:06am
The FIX policy is to express semantics explicitly, hence the OrderAttributeType values. ESMA has unfortunately chosen a different modeling approach and overloads a number of fields with multiple concepts (e.g. OTC post-trade indicator).

  1. Short codes 1,2,3 have been agreed as market convention due to ESMA modeling, they are not part of the core standard, i.e. you will not find them in FIXimate.
  2. PartyRoleQualifier requires the presence of an instance of the Parties repeating group, i.e. you cannot use it to qualify an order as algorithmic. It qualifies a party as being an algorithm. These are two different things semantically.
  3. TradingCapacity is about the capacity of the party submitting the order which is semantically not the same as an information about the order, e.g. that the order was submitted to provide liquidity. The latter was added to cover an ESMA requirement whereas the former was already added with EP131 to distinguish order submitters. Admittedly, there is an overlap with OrderCapacity which was intentional at the time due to distinguish between trading and clearing capacities in the sense of an account type. See tags 1815 and 1816.
  4. Risk reduction is not about a party but only about an order
  5. Systematic internaliser can also be used to qualify a party with party role 63
  6. FIX has to be generic to accomodate as many use cases as possible. OrderAttributeValue may be Y in most cases but not all. We wanted to have that option. Some of the FIX encodings support constant values, i.e. no actual value in the wire format.