ICE TAS orders

, ,
1

Imported from previous forum

2

Does anyone offer FIX connectivity to ICE exchanges that support the TAS (trade at settlement) orders? I guess those are similar to market on close or limit on close orders; you submit them with an optional price specification of +/- one or two ticks from the settlement price, and the orders get matched by the exchange on a first come, first served basis. I was wondering what the recommended tags and values would be to specify the TAS order type (ExecInst?) and to specify the desired price.

Thanks.

3

[ original email was from Greg Wood - gregjwood@hotmail.com ]
Hi Terry,

This is an interesting question, and I haven’t got an answer for you regarding ICE trade-at-settlement products since we have not yet had the demand for these along side the regular contracts. I’d be interested to hear other views on this.

We support TAS products listed on GLOBEX, i.e. the former NYMEX complex. In this case there is a distinct product code for the TAS version compared to the regular contract - and a different RicCode, for example CLTN9 to distinguish the TAS contract from the regular July 09 Light Crude CLN9.

That make the identification of the TAS contract easy. Clients then trade the TAS contract in exactly the same way as regular products by placing bid and offers throughout the day at the base +/- their differential, and then the exchange does the match at the end of the day. We’ve used regular limit orders for this, no need for a market-on-close since that is implied in the contract definition.

ICE doesn’t make this quite as easy. They use the same exchange codes for the regular contract and the TAS version (e.g. just “B” for Brent Crude), plus there are no separate Rics or Bloomberg codes. I think that the main reason this has not come up for Credit Suisse is because the specialist community that uses this type of trade generally still uses WebICE directly rather than a broker execution service via FIX.

My gut feeling would be to use regular limit orders with the differential in tag 44 for ICE TAS with that extra piece of info to denote the TAS contract rather than - say - regular Brent Crude. If that can’t be synthesized via a distinct symbol then ExecInst seems a reasonable option, which we would need to translate into the appropriate identifier via the ICE FIX API. My interest is piqued and I’ll follow up on this with our contacts at the exchange itself.

A question back to you - how do you subscribe to market data on the TAS contract ? How you disseminate that in turn affects what codes are sent to a broker and the price sent/expected back.

Regards,

  • Greg

Does anyone offer FIX connectivity to ICE exchanges that support the TAS
(trade at settlement) orders? I guess those are similar to market on
close or limit on close orders; you submit them with an optional price
specification of +/- one or two ticks from the settlement price, and the
orders get matched by the exchange on a first come, first served basis.
I was wondering what the recommended tags and values would be to specify
the TAS order type (ExecInst?) and to specify the desired price.

Thanks.

4

Thanks, Greg, that is really useful information -

I’m not sure how to answer your question. We sell an OMS, and some of our users were asking about TAS orders on ICE and potential support via FIX. I was thinking of a TAS order as being just an order type on a single security/symbol in the database, not an order on a separate security/symbol. Having multiple securities for the same contract would complicate things in our product, since the ultimate position is in the plain old contract, right? So I guess we would need something under the covers to understand than some TAS orders are for a different exchange symbol, and others (like on ICE), are for the usual symbol. The market data would only be available for the raw symbol, wouldn’t it? And when a TAS order is filled, the price would come back net including the settlement base price, wouldn’t it? E.g., if the settlement price is 94.00 and my TAS offset is +0.05, I would get a fill at 94.05 - is that right?

Hi Terry,

This is an interesting question, and I haven’t got an answer for you
regarding ICE trade-at-settlement products since we have not yet had the
demand for these along side the regular contracts. I’d be interested to
hear other views on this.

We support TAS products listed on GLOBEX, i.e. the former NYMEX complex.
In this case there is a distinct product code for the TAS version
compared to the regular contract - and a different RicCode, for example
CLTN9 to distinguish the TAS contract from the regular July 09 Light
Crude CLN9.

That make the identification of the TAS contract easy. Clients then
trade the TAS contract in exactly the same way as regular products by
placing bid and offers throughout the day at the base +/- their
differential, and then the exchange does the match at the end of the
day. We’ve used regular limit orders for this, no need for a market-on-
close since that is implied in the contract definition.

ICE doesn’t make this quite as easy. They use the same exchange codes
for the regular contract and the TAS version (e.g. just “B” for Brent
Crude), plus there are no separate Rics or Bloomberg codes. I think that
the main reason this has not come up for Credit Suisse is because the
specialist community that uses this type of trade generally still uses
WebICE directly rather than a broker execution service via FIX.

My gut feeling would be to use regular limit orders with the
differential in tag 44 for ICE TAS with that extra piece of info to
denote the TAS contract rather than - say - regular Brent Crude. If that
can’t be synthesized via a distinct symbol then ExecInst seems a
reasonable option, which we would need to translate into the appropriate
identifier via the ICE FIX API. My interest is piqued and I’ll follow up
on this with our contacts at the exchange itself.

A question back to you - how do you subscribe to market data on the TAS
contract ? How you disseminate that in turn affects what codes are sent
to a broker and the price sent/expected back.

Regards,

  • Greg

Does anyone offer FIX connectivity to ICE exchanges that support the
TAS (trade at settlement) orders? I guess those are similar to market
on close or limit on close orders; you submit them with an optional
price specification of +/- one or two ticks from the settlement price,
and the orders get matched by the exchange on a first come, first
served basis. I was wondering what the recommended tags and values
would be to specify the TAS order type (ExecInst?) and to specify the
desired price.

Thanks.

5

Hi, BAXTER is a member of ICE but only routes/execute orders for FX. Is your request regarding FX or other/all ICE products ?
Let me know if I can help.

Franck

Thanks, Greg, that is really useful information -

I’m not sure how to answer your question. We sell an OMS, and some of
our users were asking about TAS orders on ICE and potential support
via FIX. I was thinking of a TAS order as being just an order type on
a single security/symbol in the database, not an order on a separate
security/symbol. Having multiple securities for the same contract
would complicate things in our product, since the ultimate position is
in the plain old contract, right? So I guess we would need something
under the covers to understand than some TAS orders are for a
different exchange symbol, and others (like on ICE), are for the usual
symbol. The market data would only be available for the raw symbol,
wouldn’t it? And when a TAS order is filled, the price would come back
net including the settlement base price, wouldn’t it? E.g., if the
settlement price is 94.00 and my TAS offset is +0.05, I would get a
fill at 94.05 - is that right?

Hi Terry,

This is an interesting question, and I haven’t got an answer for you
regarding ICE trade-at-settlement products since we have not yet had
the demand for these along side the regular contracts. I’d be
interested to hear other views on this.

We support TAS products listed on GLOBEX, i.e. the former NYMEX
complex. In this case there is a distinct product code for the TAS
version compared to the regular contract - and a different RicCode,
for example CLTN9 to distinguish the TAS contract from the regular
July 09 Light Crude CLN9.

That make the identification of the TAS contract easy. Clients then
trade the TAS contract in exactly the same way as regular products by
placing bid and offers throughout the day at the base +/- their
differential, and then the exchange does the match at the end of the
day. We’ve used regular limit orders for this, no need for a market-on-
close since that is implied in the contract definition.

ICE doesn’t make this quite as easy. They use the same exchange codes
for the regular contract and the TAS version (e.g. just “B” for Brent
Crude), plus there are no separate Rics or Bloomberg codes. I think
that the main reason this has not come up for Credit Suisse is because
the specialist community that uses this type of trade generally still
uses WebICE directly rather than a broker execution service via FIX.

My gut feeling would be to use regular limit orders with the
differential in tag 44 for ICE TAS with that extra piece of info to
denote the TAS contract rather than - say - regular Brent Crude. If
that can’t be synthesized via a distinct symbol then ExecInst seems a
reasonable option, which we would need to translate into the
appropriate identifier via the ICE FIX API. My interest is piqued and
I’ll follow up on this with our contacts at the exchange itself.

A question back to you - how do you subscribe to market data on the
TAS contract ? How you disseminate that in turn affects what codes are
sent to a broker and the price sent/expected back.

Regards,

  • Greg

Does anyone offer FIX connectivity to ICE exchanges that support the
TAS (trade at settlement) orders? I guess those are similar to
market on close or limit on close orders; you submit them with an
optional price specification of +/- one or two ticks from the
settlement price, and the orders get matched by the exchange on a
first come, first served basis. I was wondering what the recommended
tags and values would be to specify the TAS order type (ExecInst?)
and to specify the desired price.

Thanks.

6

Good day,

Have TAS orders been normalized since 2009?

I found they have been for trade capture reports (EP107) but the concerned tags are not useful for single orders. Maybe adding a specific PriceType (423) value (differential with settlement price) would be appropriate…

Xavier.

Hi Terry,

This is an interesting question, and I haven’t got an answer for you regarding ICE trade-at-settlement products since we have not yet had the demand for these along side the regular contracts. I’d be interested to hear other views on this.

We support TAS products listed on GLOBEX, i.e. the former NYMEX complex. In this case there is a distinct product code for the TAS version compared to the regular contract - and a different RicCode, for example CLTN9 to distinguish the TAS contract from the regular July 09 Light Crude CLN9.

That make the identification of the TAS contract easy. Clients then trade the TAS contract in exactly the same way as regular products by placing bid and offers throughout the day at the base +/- their differential, and then the exchange does the match at the end of the day. We’ve used regular limit orders for this, no need for a market-on-close since that is implied in the contract definition.

ICE doesn’t make this quite as easy. They use the same exchange codes for the regular contract and the TAS version (e.g. just “B” for Brent Crude), plus there are no separate Rics or Bloomberg codes. I think that the main reason this has not come up for Credit Suisse is because the specialist community that uses this type of trade generally still uses WebICE directly rather than a broker execution service via FIX.

My gut feeling would be to use regular limit orders with the differential in tag 44 for ICE TAS with that extra piece of info to denote the TAS contract rather than - say - regular Brent Crude. If that can’t be synthesized via a distinct symbol then ExecInst seems a reasonable option, which we would need to translate into the appropriate identifier via the ICE FIX API. My interest is piqued and I’ll follow up on this with our contacts at the exchange itself.

A question back to you - how do you subscribe to market data on the TAS contract ? How you disseminate that in turn affects what codes are sent to a broker and the price sent/expected back.

Regards,

  • Greg

Does anyone offer FIX connectivity to ICE exchanges that support the TAS
(trade at settlement) orders? I guess those are similar to market on
close or limit on close orders; you submit them with an optional price
specification of +/- one or two ticks from the settlement price, and the
orders get matched by the exchange on a first come, first served basis.
I was wondering what the recommended tags and values would be to specify
the TAS order type (ExecInst?) and to specify the desired price.

Thanks.

7

I need to find a way of specifying that a derivative order is to be matched at a TAS (Trade at Settlement) or TAM (Trade at Marker) price. There doesn’t seem to be a standard way of doing this. EP107 introduced new values of TrdSubType to indicate this on trades, but that tag is not present on orders. However orders do have a MatchingInstructions group, which is what these markers are in effect.

MatchingInstructions were introduced in EP99 and refer to the TagNum of a field to “allow more complex matching instructions to be added to an Order than is currently possible using the ExecInst (18) field”. Therefore it is possible to include a MatchingInstructions group in an order referring to a value of TrdSubType. The semantics here are “only match if the resulting trade will be of this type”. Furthermore TrdSubType has union datatype Reserved1000Plus, so addtional codeset values can be specified for further differentiation; for example, ICE has two distinct Minute Markers not just one, so a value is need for the Morning Minute Marker as well as the standard Minute Marker.

This all seems entirely standard-compliant, but convoluted. Is there a better way?

8

EP210 introduced ExecInst(18)=y (Trade at reference price). This was intentionally left generic to allow its usage for any kind of reference price. I believe you are right that more than one reference price is currently not supported on orders.

I do not recommend the use of MatchingInstructions for this even though it may technically be possible and I do not consider it to be standard-compliant. The intention was to provide a generic reference to tags that are present on the order (of both sides) to easily determine whether a match should occur or not. TrdSubType(829) is not on the order and should not be used as an instruction either. You can use MatchAttribTagID(1626)=18 to exclude normal orders trading against those trading at a reference price (18=y). A custom field would allow you to distinguish various reference price flavors and you can add that field to your matching instructions as well.

The question is whether TAS and TAM are order-level attributes and not product/instrument level attributes. Do you really want to support orders for the same instrument, some of which are traded at the current market price whereas other orders are subject to TAS?

9

With ExecInst=y it would not be instrument (reference data) level attribute. I do see trading at a reference price to be order based attribute - it’s conceptually like a pegged order (but not exactly the same behavior) in my opinion.

10

I would agree with that.

It would be good to know if there’s a way of specifying which reference price you are targeting (in theoretical situations where the destination system supports multiple reference prices).

11

I believe it is an order level attribute. Exchanges sometimes provide different instrument codes to distinguish these, but they are not really different instruments. You can buy today at a TAS price and sell the position tomorrow at a TAM price, the future or option contract is the same thing.

Using ExecInst=y allows the order to be flagged as for a reference price, but still requires a custom field to indicate which type of reference price to use. This is not a theoretical case. For example Brent Crude Futures may be traded on ICE at the order book price or at TAS, MM or Sing MM prices (strictly, at an offset to those reference prices) - see section “Markers”.

If entering an order for this product using a code other than the exchange code, which embeds the “Marker” in the code itself, then the type of reference price needs to be indicated.

12

@mordav, do you know if such separate products are usually fungible? I am wondering why exchanges are doing this. I can’t imagine that the only reason is due to a gap in the FIX Protocol :wink:

13

I think these are more than fungible, they are exactly the same product as far as I can determine. It’s not multiple exchange listings that are fugible for clearing purposes, it is one product that has a variety of prices on a single exchange. The “Minute Marker” prices for example are the VWAP of trade prices for a defined minute of trading. These periods set a fair price in a similar way to the closing auction on an equity market.

From what I can see these “markers” are just order price types.

The exchanges need to publish multiple prices for each instrument, and modifying the exchange ID is a lazy way to support this. ICE embeds a lot of information about the contract in the ID, such as the type of the contract, its expiry, its price type and more. Strictly these are separate attributes.

The issue is that third-party instrument identifiers, such a Bloomberg codes, don’t distinguish between the different “markers”. Rightly so IMHO. I need to find a way or indicating the price type on the order, so that I can map to the correct exchange code.

14

Considering my options here, what is the consensus about extending the codeset for tags that do not have an explicit union datatype such as Reserved100Plus?

For example I could extend PriceType (423) to include values from 100 for TAS, TAM, etc.

Is that considered worse than adding a new custom tag?

15

@mordav, the short answer is yes and I would advise against that approach, especially for a field like PriceType(423). TAS and TAM are not FIX price types that are used to explain the notation of Price(44) and not the point in time that Price(44) is determined. Using PriceType(423) for TAS etc. would make it impossible to also differ between a percentage price, price per unit, fixed amount or other. The semantic “violation” is worse than the data type issue. TAS and TAM are rather execution instructions on an order that can be expressed with ExecInst(18)=y together with a specific second field (that does not exist in FIX currently). A workaround for you may be to use the generic field OrderAttributeType(2594) that has Reserved1000Plus and is part of a repeating group.

There is also the field PegPriceType(1094). The field name was probably not the best choice back then as it is not a price type but a reference to another/official price. Formally, it also does not allow you to add user-defined values but semantically it is a much better fit, i.e. I would consider it to be better to use 100 etc. there than adding a custom tag that has little chance of being re-used by others.

In general, FIX fields that do not have Reserved100Plus or similar intentionally do not have that union data type to express the fact this is a key field where semantics should be centrally defined to avoid a loss of interoperability. More prominent examples of key fields are OrdStatus(39) and ExecType(150).

FIX members can put forward a Gap Analysis proposal to add missing elements to FIX Protocol.

16

Thank you @hanno.klein this is clear and I agree with your argument. Since PriceType is used in FIX to represent the price format (1/8ths, 1/16ths, percentages, etc.) it should not also be used to indicate the price determination method as well.

The use of ExecInst(18)=y together with OrderAttributeGrp suits my purpose. My ROE already contains the group for various MiFID-related values.

I will add something like this:

OrderAttributeType codeset supported for ICE exchanges:

| Name                   | Value | Synopsis                         | Elaboration                                       |
|------------------------|------:|----------------------------------|---------------------------------------------------|
| TradeAtSettlement      | 1000  | Trade at Settlement (TAS)        | The marker "Z" on ICE exchanges.                  |
| TradeAtBlockIndexClose | 1001  | Trade at Block Index Close (BIC) | The marker "B" on ICE exchanges.                  |
| TradeAtIndexClose      | 1002  | Trade at Index Close (TIC)       | The marker "Y" on ICE exchanges.                  |
| TradeAtPlatts          | 1003  | Trade at Platts (TAPS)           | The marker "P" on ICE exchanges.                  |
| TradeAtDailyMarker     | 1004  | Trade at Marker (TAM)            | The Daily Minute Marker "MD1" on ICE exchanges.   |
| TradeAtMorningMarker   | 1005  | Trade at Morning Minute Marker   | The Morning Minute Marker "MM1" on ICE exchanges. |
17

Small update, it was pointed out that it would be better to use OrderAttributeValue for the specific values for TAS, TAM, etc. so I’ve used a single custom value of OrderAttributeType to specify the attribute is a reference price, with OrderAttributeValue giving the value required, which is just a defined String.

### Codeset OrderAttributeTypeCodeSet type int (2594)

#### Synopsis

The type of order attribute.

| Name                            | Value | Id      | Synopsis                           | Elaboration                                                                                                                               |
|---------------------------------|------:|--------:|------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|
| LiquidityProvisionActivityOrder | 2     | 2594003 | Liquidity provision activity order | In the context of ESMA RTS 24 Article 3, when OrderAttributeValue(2595)=Y, it signifies that the order was submitted "as part of a market making strategy pursuant to Articles 17 and 18 of Directive 2014/65/EU, or is submitted as part of another activity in accordance with Article 3" (of RTS 24). |
| RiskReductionOrder              | 3     | 2594004 | Risk reduction order               | In the context of ESMA RTS 22 Article 4(2)(i), when OrderAttributeValue(2595)=Y, it signifies that the commodity derivative order is a transaction "to reduce risk in an objectively measurable way in accordance with Article 57 of Directive 2014/65/EU".                                              |
| SystemicInternaliserOrder       | 5     | 2594006 | Systemic internaliser order        | When OrderAttributeValue(2595)=Y, it signifies the order is submitted by a systematic internaliser.                                                                                                                               |
| ReferencePrice                  | 1000  | -1      | The type of Reference Price        | Required when ExecInst (18) = "y".                                                                                                                               |

OrderAttributeValue values supported for ICE exchanges:

| Name                   | Value | Synopsis                         | Elaboration                                       |
|------------------------|------:|----------------------------------|---------------------------------------------------|
| TradeAtDailyMarker     | 1000  | Trade at Marker (TAM)            | The Daily Minute Marker "MD1" on ICE exchanges.   |
| TradeAtMorningMarker   | 1001  | Trade at Morning Minute Marker   | The Morning Minute Marker "MM1" on ICE exchanges. |
| TradeAtSettlement      | 1002  | Trade at Settlement (TAS)        | The indicator "Z" on ICE exchanges.               |
| TradeAtAuction         | 1003  | Trade at Auction (TAA)           | The indicator "A" on ICE exchanges.               |
| TradeAtIndexClose      | 1004  | Trade at Index Close (TIC)       | The indicator "Y" on ICE exchanges.               |
| TradeAtBlockIndexClose | 1005  | Trade at Block Index Close (BIC) | The indicator "B" on ICE exchanges.               |
| TradeAtPlatts          | 1006  | Trade at Platts (TAPS)           | The indicator "P" on ICE exchanges.               |
18

I would be more specific with the name of the custom value. It is not the price but the source of the price you want to convey in OrderAttributeValue(2595). For example, ReferencePriceSource is semantically better :wink:

19

Agreed. I thought the natural description was ReferencePriceType, since it is a type of reference price (using ‘type’ in the usual sense here, not as synonym of ‘datatype’). But having an OrderAtributeType of ReferencePriceType seemed a bit redundant, so I dropped the Type, but the end result is not good.

I’m not keen on Source, since it isn’t really a source but a determination method. What about RefPriceDeterminationMethod?

20

@mordav I still think my proposal to use PegPriceType(1094) is still the better fit. OrderAttributeGrp is highly generic and major attributes should rather have explicit tags. Another issue is that using OrderAttributeValue(2595) with just “Y” or “N” allows users of FIX legacy versions that are unable to support repeating groups to use the UDF OrderAttributeTypes(8015) as a flat tag. You cannot do that if you use reference price types as values.

From a standardisation perspective ExecInst(18)=y and PegPriceType(1094) with new values are semantically preferred. One could also add a new text field inside the PegInstructions component, e.g. PegInstructionText(TBD) to provide more detail. OrderAttributeGrp only supports value pairs.

For example, ICE has several minute markers related to a point in time and a location (Brent Singapore Minute Marker at 16:29 and Brent London Minute Marker at 16:29, both in local time). The first one could then look as follows:

ExecInst(18)=y (Trade at reference price)
PegPriceType(1094)=TBD (Trade at minute marker)
PegInstructionText(TBD)=“Singapore 16:29”