How to represent partial return via Trade Capture Report

, ,
1

Imported from previous forum

2

Hi,

We are using FIXML (v5) to communicate between front and back systems.

One point we are not sure about is how to represent a partial return.

Currently thinking that this is a TradeCaptureReport with a TrdCapRptSideGrp or TrdInstrmtLegGrp for the partial amount/details.

Does that sound right - or should we be using a different message type, perhaps?

Thanks,
Chris

3

Does partial “return” mean partial fill? What is wrong with ExecutionReport, ExecType=F (Trade), OrdStatus=1 (Partially Filled)? Maybe you do send an ER to the trader and then a TCR to your back office system which is fine. Maybe an ER is sufficient yor your purposes, hard to tell w/o additional context. The TCR represents your half of the trade, i.e. TrdCapRptSideGrp would have a single entry. It seems you also use multileg instruments or why do you refer to TrdInstrmtLegGrp?

Hi,

We are using FIXML (v5) to communicate between front and back systems.

One point we are not sure about is how to represent a partial return.

Currently thinking that this is a TradeCaptureReport with a TrdCapRptSideGrp or TrdInstrmtLegGrp for the partial amount/details.

Does that sound right - or should we be using a different message type, perhaps?

Thanks,
Chris

4

Hi Hanno,

Thanks for the reply - sorry, was a bit vague - this is for Equity Finance deals (equity repos) - so there is the on/off legs to consider.

So, the partial return is possibly like a partial fill - its just on the second leg of the deal.

Thanks,
Chris

Does partial “return” mean partial fill? What is wrong with ExecutionReport, ExecType=F (Trade), OrdStatus=1 (Partially Filled)? Maybe you do send an ER to the trader and then a TCR to your back office system which is fine. Maybe an ER is sufficient yor your purposes, hard to tell w/o additional context. The TCR represents your half of the trade, i.e. TrdCapRptSideGrp would have a single entry. It seems you also use multileg instruments or why do you refer to TrdInstrmtLegGrp?

Hi,

We are using FIXML (v5) to communicate between front and back systems.

One point we are not sure about is how to represent a partial return.

Currently thinking that this is a TradeCaptureReport with a TrdCapRptSideGrp or TrdInstrmtLegGrp for the partial amount/details.

Does that sound right - or should we be using a different message type, perhaps?

Thanks,
Chris

5

Must admit I am not too familiar with equity repos but it sounds like you have multiple “legs” and only some of them get executed. FIX multilegs are intended to be atomic instruments, i.e. if they get filled, then all legs get filled. How the fill on the instrument level is broken down to the leg level is another story. But maybe you are better served with NewOrderList with a new ContingencyType (tag 1385) to link the two (or more) parts together. Just a thought.

Hi Hanno,

Thanks for the reply - sorry, was a bit vague - this is for Equity Finance deals (equity repos) - so there is the on/off legs to consider.

So, the partial return is possibly like a partial fill - its just on the second leg of the deal.

Thanks,
Chris

6

Hi Hanno,

Thanks for that - not sure it quite applies, as the returns happen later in the lifecycle, but will look into it - gives us some pointers.

Regards,
Chris

Must admit I am not too familiar with equity repos but it sounds like you have multiple “legs” and only some of them get executed. FIX multilegs are intended to be atomic instruments, i.e. if they get filled, then all legs get filled. How the fill on the instrument level is broken down to the leg level is another story. But maybe you are better served with NewOrderList with a new ContingencyType (tag 1385) to link the two (or more) parts together. Just a thought.

Hi Hanno,

Thanks for the reply - sorry, was a bit vague - this is for Equity Finance deals (equity repos) - so there is the on/off legs to consider.

So, the partial return is possibly like a partial fill - its just on the second leg of the deal.

Thanks,
Chris

7

Hi all,

A partial return is not really like a partial fill. This is very different from trading on a market. It seems that FIX is geared towards ‘outright’ trading. The difference with REPO and Equities Finance trades is that we have a life span. The trade consists of two opposite legs that occur at different times, therefore the trade ahs a lifespan between the starting leg (the on-leg) and the closing leg (the off-leg). During that time various events can happen on the trade. In this case, a partial return is a new middle leg created ‘on the fly’ to change the quantity of the trade outstanding from that point forward. It creates a new transaction and changes the quantity in the future end-leg. There simply is not an analog in outright trading. Partial returns are only one of many possible events that can happen during a trades open life. We also have re-prices, re-rates, and substitutions to deal with (just to name a few).

It looks like we will have to represent this all with custom fields unless someone can suggest anything based on that explanation above. Our use-case is unfortunatly quite different from what FIXML actually targets, but we’ve been mandated by our architecture group to use it. Quite a pickle, really.

Cheers,
Troy.

Hi Hanno,

Thanks for that - not sure it quite applies, as the returns happen later in the lifecycle, but will look into it - gives us some pointers.

Regards,
Chris

Must admit I am not too familiar with equity repos but it sounds like you have multiple “legs” and only some of them get executed. FIX multilegs are intended to be atomic instruments, i.e. if they get filled, then all legs get filled. How the fill on the instrument level is broken down to the leg level is another story. But maybe you are better served with NewOrderList with a new ContingencyType (tag 1385) to link the two (or more) parts together. Just a thought.

Hi Hanno,

Thanks for the reply - sorry, was a bit vague - this is for Equity Finance deals (equity repos) - so there is the on/off legs to consider.

So, the partial return is possibly like a partial fill - its just on the second leg of the deal.

Thanks,
Chris

8

Troy,
thanks for the background information. Maybe it is more about terminology than about gaps in FIX. Your “order” which I believe you call trade has two or more elements for which you use the term “leg” and FIX would see as a basket of more or less coupled orders. These legs “occur” which I interpret as being executed. Legs could be added during the lifetime of the order and existing legs could be changed or even cancelled. Legs can be executed during the lifetime but can this change later, based on an event, i.e. what is the concept for final states of legs or the trade as a whole?
I come back to my proposal of the NewOrderList message which allows a transactional semantic (only NewOrderSingle is missing the ListID field today) to add (NewOrderSingle), modify (OrderCancelReplaceRequest)or remove (OrderCancelRequest)legs which would be modeled as orders in the basket. The ListID stands for your trade and as legs get executed, you use ExecutionReports to convey execution results or modify previous results. ListOrderStatus allows you to track the overall trade status over its lifetime with 6=All Done when all legs are completed. Let me know if that helps in your design process.
Hanno.

Hi all,

A partial return is not really like a partial fill. This is very different from trading on a market. It seems that FIX is geared towards ‘outright’ trading. The difference with REPO and Equities Finance trades is that we have a life span. The trade consists of two opposite legs that occur at different times, therefore the trade ahs a lifespan between the starting leg (the on-leg) and the closing leg (the off-leg). During that time various events can happen on the trade. In this case, a partial return is a new middle leg created ‘on the fly’ to change the quantity of the trade outstanding from that point forward. It creates a new transaction and changes the quantity in the future end-leg. There simply is not an analog in outright trading. Partial returns are only one of many possible events that can happen during a trades open life. We also have re-prices, re-rates, and substitutions to deal with (just to name a few).

It looks like we will have to represent this all with custom fields unless someone can suggest anything based on that explanation above. Our use-case is unfortunatly quite different from what FIXML actually targets, but we’ve been mandated by our architecture group to use it. Quite a pickle, really.

Cheers,
Troy.

Hi Hanno,

Thanks for that - not sure it quite applies, as the returns happen later in the lifecycle, but will look into it - gives us some pointers.

Regards,
Chris

Must admit I am not too familiar with equity repos but it sounds like you have multiple “legs” and only some of them get executed. FIX multilegs are intended to be atomic instruments, i.e. if they get filled, then all legs get filled. How the fill on the instrument level is broken down to the leg level is another story. But maybe you are better served with NewOrderList with a new ContingencyType (tag 1385) to link the two (or more) parts together. Just a thought.

Hi Hanno,

Thanks for the reply - sorry, was a bit vague - this is for Equity Finance deals (equity repos) - so there is the on/off legs to consider.

So, the partial return is possibly like a partial fill - its just on the second leg of the deal.

Thanks,
Chris