Imported from previous forum
I’m looking pass the details of the current position from a post-trade system to a trading platform. The message I am planning to use for this is the Position Report (AP) message in unsolicited form. I need to also pass information on the reason that the position is being updated (eg: Trade, liquidations, position change, exercise, settlement)- in other words the position equivalent of the ExecType. While there is a PosTransType (709) field it seems to be designed to capture a range of transactions that the position owner can carry out on the position (as opposed to all updates that can take place on the position) and is therefore linked to the PositionMaintanence messages.
Does anybody have any thoughts on this, or any knowledge of existing practices that have addressed the same need?
PositionReport is intended as a snapshot of the current position whereas The PositionMaintenanceReport is intended to reflect the result of a position transaction. The transaction could be solicited by the owner of the position but it can also be triggered by a different event. In this case there is no PosReqID (710) but there will always be a PosTransType (709) and a PosMaintAction (712) to tell the recipient why he is receiving the report on the position and what he needs to do to update the position information he has locally. PosMaintStatus (722) is required and refers to a request but you could use 3=Completed for unsolicited updates versus 0=Accepted/2=Rejected when responding to a request from the position owner (if you support requests at all).
I’m looking pass the details of the current position from a post-trade system to a trading platform. The message I am planning to use for this is the Position Report (AP) message in unsolicited form. I need to also pass information on the reason that the position is being updated (eg: Trade, liquidations, position change, exercise, settlement)- in other words the position equivalent of the ExecType. While there is a PosTransType (709) field it seems to be designed to capture a range of transactions that the position owner can carry out on the position (as opposed to all updates that can take place on the position) and is therefore linked to the PositionMaintanence messages.
Does anybody have any thoughts on this, or any knowledge of existing practices that have addressed the same need?
Thanks Hanno, it sounds like you are saying the PositionMaintenanceReport is a better choice in this situation.
Due to some technical differences in position keeping in the two systems, I’m also evaluating whether the change in position can be sent in delta form (i.e. communicate the quantity reduced/increased of the position, rather than giving the final quantity). Can certain PosTypes be interpreted as delta values as opposed to final values? (eg: a postype of PA - adjustment qty?)
PositionReport is intended as a snapshot of the current position whereas The PositionMaintenanceReport is intended to reflect the result of a position transaction. The transaction could be solicited by the owner of the position but it can also be triggered by a different event. In this case there is no PosReqID (710) but there will always be a PosTransType (709) and a PosMaintAction (712) to tell the recipient why he is receiving the report on the position and what he needs to do to update the position information he has locally. PosMaintStatus (722) is required and refers to a request but you could use 3=Completed for unsolicited updates versus 0=Accepted/2=Rejected when responding to a request from the position owner (if you support requests at all).
I’m looking pass the details of the current position from a post-trade system to a trading platform. The message I am planning to use for this is the Position Report (AP) message in unsolicited form. I need to also pass information on the reason that the position is being updated (eg: Trade, liquidations, position change, exercise, settlement)- in other words the position equivalent of the ExecType. While there is a PosTransType (709) field it seems to be designed to capture a range of transactions that the position owner can carry out on the position (as opposed to all updates that can take place on the position) and is therefore linked to the PositionMaintanence messages.
Does anybody have any thoughts on this, or any knowledge of existing practices that have addressed the same need?
Yes, PosType PA is about adjustment of long/short due to a single transaction in the context of PosTransTyp (709). But also other types could be delta values if you document the behaviour in your Rules of Engagement. This is less convenient for the user and should be avoided. But I do see the issue with (legacy) systems not being able to provide a running total and only being able to send delta values.
For example, EX (Exercise Qty) could be expected as a delta from the user requesting it (PMRequest) and could be sent as a delta on (unsolicited) PMReports going out. The user then has to add the quantities of PosType=EX on multiple PMRs for a position to calculate the total quantity currently exercised.
Thanks Hanno, it sounds like you are saying the PositionMaintenanceReport is a better choice in this situation.
Due to some technical differences in position keeping in the two systems, I’m also evaluating whether the change in position can be sent in delta form (i.e. communicate the quantity reduced/increased of the position, rather than giving the final quantity). Can certain PosTypes be interpreted as delta values as opposed to final values? (eg: a postype of PA - adjustment qty?)
PositionReport is intended as a snapshot of the current position whereas The PositionMaintenanceReport is intended to reflect the result of a position transaction. The transaction could be solicited by the owner of the position but it can also be triggered by a different event. In this case there is no PosReqID (710) but there will always be a PosTransType (709) and a PosMaintAction (712) to tell the recipient why he is receiving the report on the position and what he needs to do to update the position information he has locally. PosMaintStatus (722) is required and refers to a request but you could use 3=Completed for unsolicited updates versus 0=Accepted/2=Rejected when responding to a request from the position owner (if you support requests at all).
I’m looking pass the details of the current position from a post-trade system to a trading platform. The message I am planning to use for this is the Position Report (AP) message in unsolicited form. I need to also pass information on the reason that the position is being updated (eg: Trade, liquidations, position change, exercise, settlement)- in other words the position equivalent of the ExecType. While there is a PosTransType (709) field it seems to be designed to capture a range of transactions that the position owner can carry out on the position (as opposed to all updates that can take place on the position) and is therefore linked to the PositionMaintanence messages.
Does anybody have any thoughts on this, or any knowledge of existing practices that have addressed the same need?