In FIX 5.0 “111(maxFloor) - Maximum number of shares within an order to be shown on the exchange floor at any given time.” has been replaced by “1138(displayQty)-The quantity to be displayed . Required for reserve orders. On orders specifies the qty to be displayed, on execution reports the currently displayed quantity”. Though I understand a name change was overdue but did not understand the move to a different definition not aligned with actual market usage. Clients, Brokers and Exchanges all use this field for typically Iceberg orders and clients define the MAX quantity to be displayed so that broker has the discretion to slice the original order to any quantity between 0(zero) and MAX quantity. DisplayQty(Qty) is the quantity, which is actually displayed on market/exchange and dilutes the real market usage of original field(MAX Qty).
Appreciate your inputs.
The term “reserve order” is the FIX term for orders that do not display their full quantity to the market. The term “iceberg order” is used in some regions and considered to be semantically identical. The definition for the new field DisplayQty(1138) did not change, especially since MaxFloor(111) was deprecated at the same time.
There was a business requirement to allow exchanges to explicitly send back the remaining displayed quantity for cases when reserve orders were immediately partially filled upon order entry or modification. The potential confusion was resolved with EP115 (FIX Extension Packs – FIX Trading Community v2.1) when a new field InitialDisplayQty(1608) was added. It is basically a simply echo of the input parameter from the order submitter and has the following description:
Used to convey the initially requested display quantity specified in DisplayQty(1138) on order entry and modification messages in ExecutionReport message. Applicable only in ExecutionReport message where DisplayQty(1138) is the currently displayed quantity and the requested display quantity of the order also needs to be conveyed. The values of the two fields are different as soon as the order is partially filled and also after a refresh of the order whenever DisplayMethod(1084) is not 1=Initial.
Appreciate your response. I am new to this forum and not familiar with what does EP115 etc. means so would be useful to understand what it is. My colleagues have suggested to follow onixs for FIX dictionary - https://www.onixs.biz/fix-dictionary/5.0.sp2/tagnum_1608.html and in this 1608 is used for different purpose. Nevertheless, my original question was with regards to regulatory background and typical regulatory requests, which I guess even 1138 and 1608 does not satisfy adequately. Regulators across the world are increasingly interested in clear segregation of client inputs vs what was actually done for execution. I understand 1608 is close to that interpretation and is being used for execution message. But there should be a tag similar to original 111, which singularly specifies that client has defined MAX display quantity let’s say 100 and now it’s upto the executing broker to choose slice the orders into chunks 1 to 100 for execution as deemed appropriate. So client defined input shall remain 100(i.e. MAX display quantity) and actual display quantity on the market side could be anywhere between 1 to 100 depending on the slices. Do you know of an equivalent field to capture client original input i.e. MAX display quantity because 1138 doesn’t have a clear MAX terminology as there was in 111.
Appreciate your inputs.
As Hanno mentioned the usage of DisplayQty is a full replacement for MaxFloor but with the additional benefit of supporting exchange order management of an Iceberg/Reserve order both simplistically in the standard way but also in more complex ways as defined with the other tags in the group DisplayInstruction. The usage you are referring to where 111 defined the maximum quantity to be displayed remains unchanged with the new tag.
The part where the broker displays any amount up to that Max quantity is more of a convention than an explicit instruction to the broker. One broker might interpret this one way and another that this quantity should always be the slice amount. More importantly, and this goes to your regulatory transparency point, the client may have a different expectation which they were unable to transmit with the old single tag. Maybe one client wants the max qty always to be shown to the market while another client expects the behaviour you indicate from the broker. With the new group of tags the client can provide much more explicit instructions such as indicating that the display amount can be handled with random amounts 1084 DisplayMethod =3. The client then can indicate within what range of low to high qty’s to display in this random handling. I am not sure this is the intended use case for this combination as I know many of these extensions fit to exchange requirements where randomized is provided but it should fit your use case as defined.
1 Like
Please let your colleagues know that only https://fiximate.fixtrading.org/ is the “golden source” for the FIX Protocol Standard. Websites such as ONIXS have apparently not been keeping up to date and are showing the wrong tag information. That is unfortunate and maybe this post motivates ONIXS to make a correction. ONIXS seem to show the initial version of the Parties Reference Data messages that was subsequently replaced. I assume that they missed the errata published by FIX more than 10 years ago (FIX 5.0 Service Pack 2 Specification with 20131209 Errata – FIX Trading Community v2.1):
The Errata 20110818 contains adjustments to the FIX 5.0 Service Pack 2 Specification document due to typographical errors or ambiguities, and rescinding of the Parties Reference Data messages. The nature and scope of these adjustments do not introduce new functionality or new messages. Unlike previous errata for previous releases of FIX, a set of new messages, Parties Reference Data, which was introduced in the original FIX 5.0 SP2 release has been rescinded. The rescindment of these messages has been reviewed and approved by the FIX Global Technical Committee Governance Board. A new set of redesigned Parties Reference Data messages was introduced as an enhancement to FIX 5.0 Service Pack 2 (see EP105 below). This FIX 5.0 Service Pack 2 with 20110818 Errata is considered the current version of the FIX 5.0 Service Pack 2 specification.
Appreciate the fact that you are unfamiliar with the concept of Extension Packs. Each EP is an incremental enhancement of the FIX Protocol, adding new elements such as messages, fields and values to reflect additional business requirements. EP documents are a useful source of information, especially if you want to find out more about the business background.
1 Like
I think what you are ultimately describing is simply OrderQty(38), especially if you bring in the interest of the regulator. Every order must have a quantity field to express towards the broker the MAX amount of a security that the broker is allowed to execute. It is secondary whether the broker does that by showing all of it to the market at once or by showing and executing one unit at a time (or any splicing in between). DisplayQty(1138) as well as previously MaxFloor(111) control this secondary behaviour. It is optional information from the client if and only if he would like to control the broker’s behaviour. You can omit DisplayQty/MaxFloor from your order but you cannot omit OrderQty. If you choose to omit then DisplayQty/MaxFloor is simply defined as equal OrderQty, i.e. “allowed to show everything at once”.
Please do not get hung up on terminology, just because the term “MAX” is missing in the field name DisplayQty that replaced MaxFloor. A term is never enough as it is open to interpretation. On the other hand, a standard is also not the superset of all terminology out there in the world. It is always about semantics and context.
Thanks for the info on EP and fiximate. I understand that context is most important and fix does not cover everything but thought to understand whether it intends to align with market practice with more specific fields with specific definitions or the generalized ones.