Proper Understanding of Tag 529 values

, ,
1

Imported from previous forum

2

Hello All,

I am looking to get an understanding of tag 529 (OrderRestriction). I am aware that this tag is used in conjunction with tag 528 (OrderCapacity) but not too sure of the following:

  1. What are the different meanings of each of the values?
    Valid values (can contain multiple values):
    1 = Program Trade
    2 = Index Arbitrage
    3 = Non-Index Arbitrage
    4 = Competing Market Maker
    5 = Acting as Market Maker or Specialist in the security
    6 = Acting as Market Maker or Specialist in the underlying security of a derivative security
    7 = Foreign Entity (of foreign government or regulatory jurisdiction)
    8 = External Market Participant
    9 = External Inter-connected Market Linkage
    A = Riskless Arbitrage

  2. How is ‘”Competing Market Maker”, “Acting as Market Maker or Specialist in the security” and “Acting as Market Maker or Specialist in the underlying security of a derivative security” different?

  3. Which values cannot coexist? For example, I assume Index Arbitrage and Non-Index Arbitrage cannot coexist. Can Index Arbitrage or Non-Index Arbitrage coexist with Riskless Arb? My assumption is no.

  4. Can a value of program trade be set by itself, or does it have to be specified as being an index arbitrage or non-index arbitrage trade? i.e. can I do 528=A and 529=1 vs 528=A and 529=1 2 or 528=A and 529=1 3

  5. Can a program trade be a riskless arbitrage? My assumption is no.

  6. I assume the market making activities cannot coexist with program trade?

  7. What would be an example of using riskless arbitrage with order capacity? Would buying 100 shares of IBM @ $50 on the NYSE exchange by sending 528=A (AGENCY) and 529=A (RISKLESS ARBITRAGE) and simultaneously selling 100 shares of IBM @ $55 on a different exchange with 528=A (AGENCY) and 529=A (RISKLESS ARBITRAGE) suffice?

I have used this site as well for reference: http://www.onixs.biz/fix-dictionary/4.4/app_6_f.html#12

3

Dwayne, please post such questions in the more specific forum for FIX Semantics (http://www.fixtradingcommunity.org/pg/discussions/171099/fix-semantics/). You are asking a very broad question which I will try to answer generically first.

Valid values of FIX fields are driven by specific use cases (often more than one over time) and there may even be some overlap or inconsistency between the different values. You are apparently trying to understand the values without having a specific use case in mind or problem to solve, e.g. “how should I set tag 528/529 to show the characteristics X, Y and Z of an order?”. Terminology is subject to interpretation in many cases and FIX does not want to be the superset of all terms used in the industry and will rather pick one term for a valid value and show additional terms in the elaboration. Or you can show additional, local terms in your Rules of Engagement to define how to map the standard values to local terms.

To be a little more specific, be look at Volume 6 section 12 of the FIX Specification. It explains the deprecation of the Rule80A field (tag 47) and how it is to be mapped to tag 528 and 529. So I guess the best answer to your question is to go back to the introduction of Rule80A in the US to find out more about the regulatory regime that has driven the definition of valid values.

The specific regulatory regime may define which of the valid values may coexist or not. FIX currently does not define this. There are other cases (e.g. ExecInst(18)) where it does, i.e. where valid values are mutually exclusive for all use cases and a user may not change that. Typically, FIX would be less restrictive to avoid a situation where a business requirement cannot be covered by FIX due to this.

Feel free to suggest elaborations for the valid values to add the clarity you are currently missing. You can do this in FIXwiki which permits annotations also on that level of detail (e.g. http://www.fixwiki.org/fixwiki/OrderRestrictions/1_ProgramTrade).

4

Hanno,

Thanks for the help. I have reposted it in the FIX Semantics portal. Do you know where can I find the Volume 6 section 12 FIX specification document?

5

From the home page, follow Tech/Specs-FIX Application Layer ==> Version 5.0 Service Pack 2 ==> FIX 5.0 Service Pack 2 with 20110818 Errata Specification - Volume 6.

The direct link is http://www.fixtradingcommunity.org/pg/file/fplpo/read/29960/fix-50-service-pack-2-with-20110818-errata-specification-volume-6

6

Hi All,

I am trying to decide the best set of scenarios to use a new field called “Previous Visible Size”. Currently, We only display this field when the Execution Type = amend. But what about you an ice berg order? shouldnt we stamp previous visible size after a replenishment?

Greatly appreciate your help.

7

How is your question linked to the original question about tag 529 that started this thread?

In general, the ER message does not have duplicate fields to convey previous values of amended fields like order type price, quantity or any other attribute of an order that can be changed. This is redundant information to the recipient that uses the ER to update his order book. Upon updating, one can preserve the previous values of fields.

If I have misunuderstood your question, please post it again in a thread of its own, ideally in the forum called “FIX Semantics”, and elaborate on the use case.