Imported from previous forum
[ original email was from Dominic Wong - dominic.wong@hkmerc.com ]
Hi there, I am looking at the usage of tag 77 (i.e. PositionEffect).
There is a valid value N = “Close But Notify On Open”, I wonder what FIX message(s) will be used to notify (1) the trading party and (2) the clearing party when the situation occurs?
Regards
The elaboration of this value is: “The trade should close an existing position – if the position is closed out and a new position (on the opposite side) is opened a notification is sent out”. Notifications about position changes should use PositionMaintenanceReports (MsgType=AM). You would use the same message for different kinds of parties you want to inform. The recipient should normally be aware of his role but maybe you address the case where a single party is trading and clearing. In this case you can use the parties block inside the message and use PartyRole=1 (Executing Firm) and PartyRole=4 (ClearingFirm) to identify the parties. The recipient can then find his own ID associated with the role in which he receives the message. The values can be identical if he clears his own trades.
The value was added back in 2007 by OMX (see GTC document http://www.fixprotocol.org/documents/3645/FIX%20Protocol%20Gap%20Analysis%20-%20OMX%20Order%20Routing%20Req’s%20ph.%20II%200.40.rar).
Regards,
Hanno.
Hi there, I am looking at the usage of tag 77 (i.e. PositionEffect).
There is a valid value N = “Close But Notify On Open”, I wonder what FIX message(s) will be used to notify (1) the trading party and (2) the clearing party when the situation occurs?
Regards
I have captured this on FIXwiki at http://fixwiki.org/fixwiki/PositionEffect/N_CloseButNotifyOnOpen
Note that GTC Gap Analysis document is only available if you are logged on to the FPL website.
Once again, thank you John for enhancing the FIXwiki which (over time) will become the key online source for additional information on FIX messages, fields and valid values.
I have captured this on FIXwiki at Welcome fixwiki.org - BlueHost.com
Note that GTC Gap Analysis document is only available if you are logged on to the FPL website.
[ original email was from Dominic Wong - dominic.wong@hkmerc.com ]
Thank you for both Hanno and John.
So, I assume PositionMaintenanceReport can be used in an unsolicited manner, i.e. not just for responding to PositionMaintenanceRequest?
Note that the FIXimate description of PositionMaintenanceReport states - The Position Maintenance Report message is sent by the holder of a position in response to a Position Maintenance Request and is used to confirm that a request has been successfully processed or rejected.
Once again, thank you John for enhancing the FIXwiki which (over time) will become the key online source for additional information on FIX messages, fields and valid values.
I have captured this on FIXwiki at Welcome fixwiki.org - BlueHost.com
Note that GTC Gap Analysis document is only available if you are logged on to the FPL website.
Hi Dominic,
The PositionMaintenanceReport message can be sent in an unsolicited manner. The PositionMaintenanceRequest can be used to “subscribe” for a stream of PositionMaintenanceReport messages.
Kind Regards,
Prateek Jain
I don’t think this is correct.
See the notes in FIXwiki for PositionMaintenanceReport - Welcome fixwiki.org - BlueHost.com
The note from Hanno back in March 2011 explicitly states that “This message should not be used as an unsolicited report on position changes which is the purpose of the PositionReport message.”.
John
Hi Dominic,
The PositionMaintenanceReport message can be sent in an unsolicited manner. The PositionMaintenanceRequest can be used to “subscribe” for a stream of PositionMaintenanceReport messages.
Kind Regards,
Prateek Jain
Thanks for catching that John. I think we need to adapt the comment in light of the extension requirements discussed during the last 12 months. The introduction of a PositionMaintenanceRequestAck as a replacement of the PositionMaintenanceReport would have too much impact on existing applications. Hence it was chosen to use the existing PositionMaintenanceReport in addition to the PositionReport to report positions in an unsolicited manner. The distinction between the two is similar to market data where you have snapshots and incrementals. PositionReport is intended as a snapshot of the entire position whereas PositionMaintenanceReport allows to convey incremental changes triggered by trades, exercises, position transfers etc. and not triggered by someone submitting a PositionMaintenanceRequest .
I think we will also need to adjust the synopsis of the PositionMaintenanceReport message in the FIX Repository which still only describes one use case, i.e. “The Position Maintenance Report message is sent by the holder of a positon in response to a Position Maintenance Request and is used to confirm that a request has been successfully processed or rejected.”. That probably should have been part of EP153.
I don’t think this is correct.
See the notes in FIXwiki for PositionMaintenanceReport - http://fixwiki.org/fixwiki/PositionMaintenanceReport
The note from Hanno back in March 2011 explicitly states that “This message should not be used as an unsolicited report on position changes which is the purpose of the PositionReport message.”.
John
Hi Dominic,
The PositionMaintenanceReport message can be sent in an unsolicited manner. The PositionMaintenanceRequest can be used to “subscribe” for a stream of PositionMaintenanceReport messages.
Kind Regards,
Prateek Jain
Thanks for the clarification Hanno. I have update FIXwiki accordingly - see http://fixwiki.org/fixwiki/PositionMaintenanceReport
Thanks for catching that John. I think we need to adapt the comment in light of the extension requirements discussed during the last 12 months. The introduction of a PositionMaintenanceRequestAck as a replacement of the PositionMaintenanceReport would have too much impact on existing applications. Hence it was chosen to use the existing PositionMaintenanceReport in addition to the PositionReport to report positions in an unsolicited manner. The distinction between the two is similar to market data where you have snapshots and incrementals. PositionReport is intended as a snapshot of the entire position whereas PositionMaintenanceReport allows to convey incremental changes triggered by trades, exercises, position transfers etc. and not triggered by someone submitting a PositionMaintenanceRequest .
I think we will also need to adjust the synopsis of the PositionMaintenanceReport message in the FIX Repository which still only describes one use case, i.e. “The Position Maintenance Report message is sent by the holder of a positon in response to a Position Maintenance Request and is used to confirm that a request has been successfully processed or rejected.”. That probably should have been part of EP153.I don’t think this is correct.
See the notes in FIXwiki for PositionMaintenanceReport - http://fixwiki.org/fixwiki/PositionMaintenanceReport
The note from Hanno back in March 2011 explicitly states that “This message should not be used as an unsolicited report on position changes which is the purpose of the PositionReport message.”.
John
Hi Dominic,
The PositionMaintenanceReport message can be sent in an unsolicited manner. The PositionMaintenanceRequest can be used to “subscribe” for a stream of PositionMaintenanceReport messages.
Kind Regards,
Prateek Jain
[ original email was from Dominic Wong - dominic.wong@hkmerc.com ]
Thanks for the further updates.
So now my understanding of the usage of PositionMaintenanceReport (PMRpt) is:
-
PositionMaintenanceRequest (PMReq) is used to subscribe to PMRpt for incremental position updates triggered by trades, position transfers, etc.
-
If a trade (TradeCaptureReport) is sent with PositionEffect = N (CloseButNotifyOnOpen), if the situation occurs, a PMRpt should be sent by the position holder to the sender of the trade, which can then be picked up by the corresponding parties specified in the PMRpt (those parties should be copied from the original trade).
Thus, for Case 2, the sender of the trade need not submit a PMReq, as the PositionEffect=N has requested for the PMRpt (notification) when the situation occurs for the trade.
Then, for Case 1, the eligible PMRpt requesters should also receive the same PMRpt that will also notify for Case 2.
Moreover, PMRpt does not contain the PositionEffect tag. So is there any tag to show whether a PMRpt is sent for PositionEffect=N or for PMreq, especially if the same party has submitted PMReq and also specified PositionEffect=N in its trades?
Is my understanding above correct?
Regards … Dominic
Thanks for the clarification Hanno. I have update FIXwiki accordingly - see Welcome fixwiki.org - BlueHost.com
Thanks for catching that John. I think we need to adapt the comment in light of the extension requirements discussed during the last 12 months. The introduction of a PositionMaintenanceRequestAck as a replacement of the PositionMaintenanceReport would have too much impact on existing applications. Hence it was chosen to use the existing PositionMaintenanceReport in addition to the PositionReport to report positions in an unsolicited manner. The distinction between the two is similar to market data where you have snapshots and incrementals. PositionReport is intended as a snapshot of the entire position whereas PositionMaintenanceReport allows to convey incremental changes triggered by trades, exercises, position transfers etc. and not triggered by someone submitting a PositionMaintenanceRequest .
I think we will also need to adjust the synopsis of the PositionMaintenanceReport message in the FIX Repository which still only describes one use case, i.e. “The Position Maintenance Report message is sent by the holder of a positon in response to a Position Maintenance Request and is used to confirm that a request has been successfully processed or rejected.”. That probably should have been part of EP153.I don’t think this is correct.
See the notes in FIXwiki for PositionMaintenanceReport - Welcome fixwiki.org - BlueHost.com
The note from Hanno back in March 2011 explicitly states that “This message should not be used as an unsolicited report on position changes which is the purpose of the PositionReport message.”.
John
Hi Dominic,
The PositionMaintenanceReport message can be sent in an unsolicited manner. The PositionMaintenanceRequest can be used to “subscribe” for a stream of PositionMaintenanceReport messages.
Kind Regards,
Prateek Jain
A position cannot have a PositionEffect, only the trades affecting the position. Extension Pack 142 (quite recent, see http://www.fixprotocol.org/specifications/EP142) has added the capability to add related trades to a Positon[Maintenance]Report. This is a repeating group with which you can reference one or more trades. The recipient can then check those trades to find out what their position effect was. The idea is only to provide a reference and not a copy of the entire trade.
Thanks for the further updates.
So now my understanding of the usage of PositionMaintenanceReport (PMRpt) is:
PositionMaintenanceRequest (PMReq) is used to subscribe to PMRpt for incremental position updates triggered by trades, position transfers, etc.
If a trade (TradeCaptureReport) is sent with PositionEffect = N (CloseButNotifyOnOpen), if the situation occurs, a PMRpt should be sent by the position holder to the sender of the trade, which can then be picked up by the corresponding parties specified in the PMRpt (those parties should be copied from the original trade).
Thus, for Case 2, the sender of the trade need not submit a PMReq, as the PositionEffect=N has requested for the PMRpt (notification) when the situation occurs for the trade.
Then, for Case 1, the eligible PMRpt requesters should also receive the same PMRpt that will also notify for Case 2.
Moreover, PMRpt does not contain the PositionEffect tag. So is there any tag to show whether a PMRpt is sent for PositionEffect=N or for PMreq, especially if the same party has submitted PMReq and also specified PositionEffect=N in its trades?
Is my understanding above correct?
Regards … Dominic
Thank you!
Thanks for the clarification Hanno. I have update FIXwiki accordingly - see http://fixwiki.org/fixwiki/PositionMaintenanceReport
Please also refer to the latest published EP (EP153, http://www.fixprotocol.org/specifications/EP153) which has made changes to ease unsolicited usage. The context of EP153 is regulatory reporting to the CFTC in the US.
Thank you for both Hanno and John.
So, I assume PositionMaintenanceReport can be used in an unsolicited manner, i.e. not just for responding to PositionMaintenanceRequest?
Note that the FIXimate description of PositionMaintenanceReport states - The Position Maintenance Report message is sent by the holder of a position in response to a Position Maintenance Request and is used to confirm that a request has been successfully processed or rejected.
Once again, thank you John for enhancing the FIXwiki which (over time) will become the key online source for additional information on FIX messages, fields and valid values.
I have captured this on FIXwiki at Welcome fixwiki.org - BlueHost.com
Note that GTC Gap Analysis document is only available if you are logged on to the FPL website.