Is there a standard way to define the ticks per size range (not by price range, which are in the SecurityList)?
I am currently facing with the solution invented by XETRA CSEEG which has created a new request/reply couple (35=XTR and 35=XTL) of messages to report this inventory information, but I would like to avoid to use custom messages for my internal FIX mapped messages.
Can someone help with this?
Thanks
@annacochetti is the spec for Xetra CSEEG publicly available? Looks like they have created user-defined messages that do not start with the uppercase “U”!?
Indeed, the new messages are named XTR (TickSizeRequest) and XTL (TickSizeList).
I have been provided the protocol documentation privately and I don’t think I can disclose it publicly.
@annacochetti what does the acronym “CSEEG” stand for? I have not been able to find it. How does this work on a high level? Is this maybe linked to ESMA Tick Size Regime that is based on average daily volume of an instrument, defining liquidity bands and related tick sizes?
See https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32017R0588&from=ES.
Sorry, my bad, the right acronym is CEESEG, not CSEEG.
https://www.wienerborse.at/en/technology/technical-interfaces-xetra-t7/ceeseg-fix/
The function looks like related to a different thing.
It allows to specify a tick precision depending on the tick size. I am not sure about the exact meaning, but in each message this is specified for specific securities.
A set of tick size ranges is specified with their relative precisions.
@annacochetti I found an older version of the spec thanks to Google. CEESEG is based on Xetra’s T7 trading system. It does look like a standard tick size table, using custom fields TickSizeLow and TickSizeHigh to denote the lower and upper bound of the price and then a third field TickSizePrecision to define the actual tick increment. The definition is “Lower/upper boundary of the tick size range” and does not explicitly define the nature of the range. However, I do believe it is the price and not the quantity of an order for a given instrument.
The tick size table from ESMA adds the quantity as another parameter to determine the tick size (see https://www.wienerborse.at/en/trading/trading-information/tick-size/). The liquidity bands are defined in terms of average daily number of transactions (ADNT) in an instrument. It is not the quantity of a specific order. Instruments may change from one liquidity band to another from time to time. The custom message type 35=XTL gives you the current tick sizes valid for the given trading day. A user is not interested in other liquidity bands that currently do not apply to the instrument.
To make a long story short, CEESEG could have used the standard FIX component TickRules that is part of BaseTradingRules that is part of SecurityTradingRules that is part of SecListGrp that is part of the SecurityList(35=y) message (which CEESEG does use). Admittedly, quite deeply nested and maybe that was the reason to create user-defined messages. 
Thank you very much @gtcpm