Execution references for calendar spreads

, ,
1

Imported from previous forum

2

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

Here’s an interesting one for those of you in the futures space. When you trade a calendar spread via 4.4, the execution report only gives you the ability to report back a unique ExecID at spread execution level, not leg level.

That’s fine for the mechanics of ensuring uniqueness on each execution message, but it does not allow for easy post-trade allocation of the individual leg trades (via FIX, file, etc) since you need to reference each trade for each leg, not each trade of the spread.

For those of you unused to futures, you trade the spread between different maturities as a way of ensuring each leg is traded in tandem (for example “buy ESM8-U8”) but for post-trade purposes each leg (sold ESM8 at X, bought ESU8 at Y) settles individually and back-office processes expect unique allocation instructions for each trade for each leg. They don’t care that the execution occurred as part of a spread. To use ExecID means referencing two trades - the sell of ESM8 and the buy of ESU8.

FIX 4.4 provides the best mechanism for trading calendar spreads compared to earlier versions that don’t support Multileg message types, but it lacks a LegExecID tag that can be subsequently referenced for allocations.

I’m tempted to use tag 672 LegIndividualAllocID as a placeholder for a unique reference per trade per leg that will be consistent against execution reports and what our back-office sees, but that is not really what it should be used for.

I would be interested to hear how other parties have addressed this issue.

Thanks,

  • Greg
3

Hi Greg;

One technique that is popular for those of us in Futures & Options is to have our listed spread orders come in as New Order Singles (35=D).

The Fills then are reported on multiple execution reports (35=8) as follows using your example of a ESM8-U8 calendar spread:

First Exec Rpt: Symbol = ESM8-U8, Multileg Report Type (442) = 3(multi-leg security), Fill price = SPREAD Fill price.

Second Exec Rpt: Symbol = ESM8, Multileg Report Type (442) = 2(Individual leg of a multi-leg security), Fill price = price of the M8 leg.

Third Exec Rpt: Symbol = ESU8, Multileg Report Type (442) = 2(Individual leg of a multi-leg security), Fill price = price of the U8 leg.

Hi all,

Here’s an interesting one for those of you in the futures space. When
you trade a calendar spread via 4.4, the execution report only gives you
the ability to report back a unique ExecID at spread execution level,
not leg level.

That’s fine for the mechanics of ensuring uniqueness on each execution
message, but it does not allow for easy post-trade allocation of the
individual leg trades (via FIX, file, etc) since you need to reference
each trade for each leg, not each trade of the spread.

For those of you unused to futures, you trade the spread between
different maturities as a way of ensuring each leg is traded in tandem
(for example “buy ESM8-U8”) but for post-trade purposes each leg
(sold ESM8 at X, bought ESU8 at Y) settles individually and back-office
processes expect unique allocation instructions for each trade for each
leg. They don’t care that the execution occurred as part of a spread.
To use ExecID means referencing two trades - the sell of ESM8 and the
buy of ESU8.

FIX 4.4 provides the best mechanism for trading calendar spreads
compared to earlier versions that don’t support Multileg message types,
but it lacks a LegExecID tag that can be subsequently referenced for
allocations.

I’m tempted to use tag 672 LegIndividualAllocID as a placeholder for a
unique reference per trade per leg that will be consistent against
execution reports and what our back-office sees, but that is not really
what it should be used for.

I would be interested to hear how other parties have addressed
this issue.

Thanks,

  • Greg
4

[ original email was from Greg Wood - gregjwood@hotmail.com ]
Thanks for this feedback Tayloe, and to others for similar feedback regarding the use of individual execution report messages for the spread and the legs.

Ironically this is very similar to the approach that we have adopted for executions on spreads via FIX 4.2.

We have found the FIX 4.4 multileg messages the easiest to integrate with most 3rd parties, though some vendors still prefer 4.2. This limitation regarding unique execution IDs for post-trade allocation has so far been the only problem that I have found regarding the 4.4 implementation and I would suggest the implementation of a LegExecId tag in later versions, if not already there.

For maximum flexibility we will probably port the individual execution report approach to our 4.4 messages, though I have to say that it seems a shame to modify the generally well defined and somewhat more elegant approach of the FIX 4.4 multileg construction.

Cheers,

  • Greg

Hi Greg;

One technique that is popular for those of us in Futures & Options is to
have our listed spread orders come in as New Order Singles (35=D).

The Fills then are reported on multiple execution reports (35=8) as
follows using your example of a ESM8-U8 calendar spread:

First Exec Rpt: Symbol = ESM8-U8, Multileg Report Type (442) = 3(multi-
leg security), Fill price = SPREAD Fill price.

Second Exec Rpt: Symbol = ESM8, Multileg Report Type (442) =
2(Individual leg of a multi-leg security), Fill price = price of
the M8 leg.

Third Exec Rpt: Symbol = ESU8, Multileg Report Type (442) = 2(Individual
leg of a multi-leg security), Fill price = price of the U8 leg.

Hi all,

Here’s an interesting one for those of you in the futures space. When
you trade a calendar spread via 4.4, the execution report only gives
you the ability to report back a unique ExecID at spread execution
level, not leg level.

That’s fine for the mechanics of ensuring uniqueness on each execution
message, but it does not allow for easy post-trade allocation of the
individual leg trades (via FIX, file, etc) since you need to reference
each trade for each leg, not each trade of the spread.

For those of you unused to futures, you trade the spread between
different maturities as a way of ensuring each leg is traded in tandem
(for example “buy ESM8-U8”) but for post-trade purposes each leg
(sold ESM8 at X, bought ESU8 at Y) settles individually and back-
office processes expect unique allocation instructions for each trade
for each leg. They don’t care that the execution occurred as part of a
spread. To use ExecID means referencing two trades - the sell of
ESM8 and the buy of ESU8.

FIX 4.4 provides the best mechanism for trading calendar spreads
compared to earlier versions that don’t support Multileg message
types, but it lacks a LegExecID tag that can be subsequently
referenced for allocations.

I’m tempted to use tag 672 LegIndividualAllocID as a placeholder for a
unique reference per trade per leg that will be consistent against
execution reports and what our back-office sees, but that is not
really what it should be used for.

I would be interested to hear how other parties have addressed
this issue.

Thanks,

  • Greg
5

Hi all,

I know this message is very old but I am currently facing a very similar problem.

I am working with Trading Technologies FIX Adapter and I am stuck with FIX 4.2 My application needs to process spread orders and be able to accurately identify individual legs and the corresponding spread price for each fill. As in Tayloe's example I get one ExecutionReport for the SPREAD fill and one ExecutionReport for each individual leg.

ESM8-U8 calendar spread:

  • First Exec Rpt: Symbol = ESM8-U8, Multileg Report Type (442) = 3(multi-leg security), Fill price = SPREAD Fill price.
  • Second Exec Rpt: Symbol = ESM8, Multileg Report Type (442) = 2(Individual leg of a multi-leg security), Fill price = price of the M8 leg.
  • Third Exec Rpt: Symbol = ESU8, Multileg Report Type (442) = 2(Individual leg of a multi-leg security), Fill price = price of the U8 leg.

The difference is that I need to be able to group these messages into something like

{ 10  lots, SPREAD Price: 0.4,
   Leg1: {10 lots, price: 10.4},
   Leg2: {10 lots, price: 10.8}}

Since there is no field in the ExecutionReport that links these messages togheter, my question is, can I rely on the fact that these messages will always be delivered to my FIX Session as a group? I mean can I assume that no ExecutionReport for two fills for the same order but at different price levels, will not be intercalated?

Regards,

Dan

6

Greg,

My experience has been that the complex order must have all legs executed prior to sending the execution reports for the spread order back to you. Each leg would be an individual execution report stating the price for the lot. The LegExecId should be used to tie each leg to the parent order, and to identify the lots.

John

7

Unfortunately LegExecId is only available in FIX5.0 and not in FIX 4.2
Has anyone managed to reliably correlate individual Leg Fills ((442) = 2(Individual leg of a multi-leg security)) with the corresponding Spread Fill ((442) = 3(multi-leg security)) in a FIX 4.2 session?

Or am I chasing the impossible?

Regards,
Dan

8

Dan,

In 4.2, TAG 654 (LefRefID) is used to link the legs to the parent order. Below is an example of a execution of a 3-legged order in 4.2. The use of alternate or user-defined tags were going to be leveraged in order to stay 4.2, echoing the use of some 4.4/5.0 tags. This was a configuration agreement with the OMS for a specific FIX instance of a FIX environment (the OMS routed all my orders to intended exchanges). But this was for complex orders. I did not get into derivatives in my build. So not sure if my examples will help or confuse.

John

Equity Leg 1
|8=FIX.4.2|9=0|35=EXEC_REPORT|49=BRAS1|56=PFQR1|34=25|52=20120927-11:39:38|37=NASD|11=676332213369|17=011070000026|20=NEW|39=PART|1=11111111|38=20.000000|40=LIMT|44=0.000000|32=6.666667|31=0.000000|14=6.666667|75=20120927|60=20120927-11:39:46|150=PART|151=13.333333|

555=1|600=AEP|608=ES|616=NYSE|623=1.00|624=1|556=USD|687=20.00|565=0|654=AA0001|566=3.20|10=0

Option Leg 2
|8=FIX.4.2|9=0|35=EXEC_REPORT|49=BRAS1|56=PFQR1|34=26|52=20120927-11:39:38|37=NASD|11=676332213369|17=011070000027|20=NEW|39=PART|1=11111111|38=20.000000|
40=LIMT|44=0.000000|32=6.666667|31=0.000000|14=13.333333|75=20120927|60=20120927-11:39:46|150=PART|151=6.666667|

555=1|600=AEP130119C30|608=OC|610=201301|611=20130119|612=30.00|616=ISE|623=1.00|624=2|
687=20.00|564=O|565=0|654=AA0002|566=2.20|10=0

Option Leg 3
|8=FIX.4.2|9=0|35=EXEC_REPORT|49=BRAS1|56=PFQR1|34=27|52=20120927-11:39:38|37=NASD|11=676332213369|17=011070000028|20=NEW|39=FILD|1=11111111|38=20.000000|40=LIMT|44=0.000000|32=6.666667|31=0.000000|14=20.000000|75=20120927|60=20120927-11:39:46|150=FILD|151=0.000000|

555=1|600=AEP130119P55|608=OP|610=201301|611=20130119|612=55.00|616=ISE|623=1.00|624=2|687=20.00|564=O|565=0|654=AA0003|566=2.30|10=0

9

Hi Dan,

I’m part of the FIX team at Trading Technologies and wanted to add my thoughts. Our issue historically with correlating legs with spread execution reports is that we did not have sufficient information on the messages we received from the exchanges to make that determination ourselves.

Over time, a number of derivatives exchanges, including CME, ICE and several others, began to provide tag 526 (secondaryClOrdID) to link execution reports to the original spread transaction and use 527 (secondaryExecID) to link individual fills to each other (example below). However, that information is not available the X_TRADER / 7x platform you’re currently developing on.

Trading Technologies launched a new platform about 2 years called simply “TT”. All components including the TT exchange gateways and FIX services have been re-architected from the ground up and the new TT platform does support the functionality you require for every exchange that provides TT with necessary information. Please contact me directly or thru TT FIX Support for more information regarding exchange specifics. The sample messages that follow are from the new TT platform.

Regards,

Mike Agnew
mike.agnew@trade.tt
fixintegration@trade.tt

Recv: 8=FIX.4.2|9=01006|35=8|49=DUFFEYDCUAT|56=DUFFEYDCUAT|34=12|50=MDUFFEY|142=US,IL|52=20160830-15:46:13.500|129=MDuffey|37=e7e70daa-6356-436f-9b0d-1918b975f0b6|198=64372645927|526=1472410472|10011=2|453=2|448=123|452=14|447=D|448=GU9999|452=83|17=64295:929762|20=0|150=0|18=2|39=0|1=mduffey|55=ES|48=12543370505965797755|167=MLEG|207=CME|100=XCME|762=Calendar|15=USD|54=1|38=1|40=2|44=-720|59=0|151=1|14=0|6=0|60=20160830-15:46:13.485|77=O|1028=Y|18216=L18004|528=G|582=1|10553=matt.duffey+dts@tradingtechnologies.com|18220=19|18221=DTS|454=4|455=ESU6-ESZ6|456=98|455=ES Sep16-Dec16 Calendar|456=97|455=ESU6-Z6|456=5|455=1394|456=8|555=2|600=ES|602=14853266203675106247|609=FUT|610=201609|611=20160901|18314=1|616=CME|18100=XCME|624=2|623=1|556=USD|18212=M|604=4|605=ESU6|606=98|605=ES Sep16|606=97|605=ESU6:FV|606=5|605=1905|606=8|600=ES|602=10230388223789838760|609=FUT|610=201612|611=20161201|18314=1|616=CME|18100=XCME|624=1|623=1|556=USD|18212=M|604=4|605=ESZ6|606=98|605=ES Dec16|606=97|605=ESZ6:FV|606=5|605=50361|606=8|10=188|

Recv: 8=FIX.4.2|9=01077|35=8|49=DUFFEYDCUAT|56=DUFFEYDCUAT|34=13|50=MDUFFEY|142=US,IL|52=20160830-15:46:13.500|129=MDuffey|37=e7e70daa-6356-436f-9b0d-1918b975f0b6|198=64372645927|526=1472410472|527=643726459272016083033|10011=2|453=2|448=123|452=14|447=D|448=GU9999|452=83|17=64295:M:124252TN0000033|20=0|150=2|18=2|39=2|1=mduffey|55=ES|48=12543370505965797755|167=MLEG|207=CME|100=XCME|762=Calendar|15=USD|54=1|38=1|40=2|44=-720|59=0|32=1|31=-720|151=0|14=1|6=-720|75=20160830|60=20160830-15:46:13.485|77=O|442=3|1028=Y|18216=L18004|528=G|582=1|10553=matt.duffey+dts@tradingtechnologies.com|18220=19|18221=DTS|454=4|455=ESU6-ESZ6|456=98|455=ES Sep16-Dec16 Calendar|456=97|455=ESU6-Z6|456=5|455=1394|456=8|555=2|600=ES|602=14853266203675106247|609=FUT|610=201609|611=20160901|18314=1|616=CME|18100=XCME|624=2|623=1|556=USD|18212=M|604=4|605=ESU6|606=98|605=ES Sep16|606=97|605=ESU6:FV|606=5|605=1905|606=8|600=ES|602=10230388223789838760|609=FUT|610=201612|611=20161201|18314=1|616=CME|18100=XCME|624=1|623=1|556=USD|18212=M|604=4|605=ESZ6|606=98|605=ES Dec16|606=97|605=ESZ6:FV|606=5|605=50361|606=8|10=109|

Recv: 8=FIX.4.2|9=00685|35=8|49=DUFFEYDCUAT|56=DUFFEYDCUAT|34=14|50=MDUFFEY|142=US,IL|52=20160830-15:46:13.500|129=MDuffey|37=e7e70daa-6356-436f-9b0d-1918b975f0b6|198=64372645927|526=1472410472|527=643726459272016083033|10011=2|453=2|448=123|452=14|447=D|448=GU9999|452=83|17=64295:M:124254TN0022787|20=0|150=2|18=2|39=2|1=mduffey|55=ES|48=14853266203675106247|167=FUT|200=201609|541=20160901|205=1|207=CME|100=XCME|15=USD|18211=M|54=2|38=1|40=2|44=-720|59=0|32=1|31=217930|151=0|14=1|6=0|75=20160830|60=20160830-15:46:13.485|77=O|442=2|1028=Y|18216=L18004|528=G|582=1|10553=matt.duffey+dts@tradingtechnologies.com|18220=19|18221=DTS|454=4|455=ESU6|456=98|455=ES Sep16|456=97|455=ESU6:FV|456=5|455=1905|456=8|10=057|

Recv: 8=FIX.4.2|9=00686|35=8|49=DUFFEYDCUAT|56=DUFFEYDCUAT|34=15|50=MDUFFEY|142=US,IL|52=20160830-15:46:13.501|129=MDuffey|37=e7e70daa-6356-436f-9b0d-1918b975f0b6|198=64372645927|526=1472410472|527=643726459272016083033|10011=2|453=2|448=123|452=14|447=D|448=GU9999|452=83|17=64295:M:124256TN0001517|20=0|150=2|18=2|39=2|1=mduffey|55=ES|48=10230388223789838760|167=FUT|200=201612|541=20161201|205=1|207=CME|100=XCME|15=USD|18211=M|54=1|38=1|40=2|44=-720|59=0|32=1|31=217210|151=0|14=1|6=0|75=20160830|60=20160830-15:46:13.485|77=O|442=2|1028=Y|18216=L18004|528=G|582=1|10553=matt.duffey+dts@tradingtechnologies.com|18220=19|18221=DTS|454=4|455=ESZ6|456=98|455=ES Dec16|456=97|455=ESZ6:FV|456=5|455=50361|456=8|10=068|