We are designing our Trade Capture Report for OTC. We have some questions.
Question 1: When the out trade occurs, which value should we put in PartyIDSource?
When an out trade occurs, the broker makes another trade to correct it. A dealer should send a Trade Capture Report to correct it and put the out trade into a specific trading account.
Our planning format is below for your reference.
NoPartyIDS=2 PartyID=client broker branch ID or error broker branch ID PartyIDSource=C PartyRole=1-executing firm or 40-transfer to firm for error trade.
PartyID=account id PartyIDSource=3 PartyRole=5
Is PartyRole = 40 suitable for error trade? We are using FIX 4.4; PartyRole doesn’t have a value of 40. Maybe we should customize it. Are there any suggestions?
Question 2: Is there an accepted or confirmed time for the trade report?
A trade report is sent to the exchange by the broker. When the other side’s broker accepts the trade, we will record a confirmed time and return to it. We looked into the FIX protocol, but it does not have an applicable tag.
Question 3: How do we return a Trade Capture Report query?
As I understand it, a Trade Capture Report Request is used for a Trade Capture Report status query. We reply with the Trade Capture Report directly instead of another Trade Capture Ack. But the Trade Capture Report doesn’t like the Execution Report, which has ExecID(150) with the value I(Order Status). How can we know the Trade Capture Report is for Trade Capture Report Request? Could we also use ExecID(150) for it?
I appreciate your time and effort in helping me understand the issue.
We keep two timestamps in our system. One is input time, which we keep in TransactTime(60) right now when the broker sends a Trade Capture Report. The other is an accepted time by the contra broker accepting the Trade Capture Report. So maybe TrdRegTimestamp is a good choice. But do you think TrdRegTimestampType=5(broker executing) is suitable to use? There is no accepted value we can choose.
Q3.
In order to be compatible with our legacy system, we only keep an OrderID for the unique key right now. So I just think maybe we can use ExecID(150) as an Execution Report does.
The value of PartyIDSource(447) is independent of the type of transaction. It always identifies the domain of PartyID(448). The value of PartyID(448) for an actor (e.g. executing firm) does not change when the same broker corrects a previous TradeCaptureReport(35=AE).
If you want to correct the account ID provided with PartyRole(448)=5 (Investor ID), then you simply send a TCR with the new value and TradeReportTransType(487)=2 (Replace).
If you want to show the old and the new account in the same message, then you can use the PartyRoleQualifier(2376) and two party instances with PartyRole(448)=5 (Investor ID), one with PartyRoleQualifier(2376)=18 (Current) and one with PartyRoleQualifier(2376)=19 (New).
Just to confirm, does this mean that a second trade is sent to offset the impact of the previous one or does it mean that you send a modification of an existing trade? The suggestion above is for the latter case.
PartyRole(452)=40 (Transfer to firm) is not suited even though you may use values from higher versions when using FIX 4.4. It is to identify a firm where a trade is transferred to, not an account.
Whenever a single message only needs the timestamp related to the type of transaction (OTC trade accepted, OTC trade confirmed), you simply use TransactTime(60).
If your TCR needs to carry multiple timestamps, you can use the repeating group TrdRegTimestamps with TrdRegTimestampType(770) indicating the type of transaction related to the timestamp captured in TrdRegTimestamp(769). You can use TrdRegTimestampType(770)=17 (Confirmed) to capture the time when the broker confirmed the trade that the exchange sent to him.
Additionally, you can use TrdRegTimestampType(770)=2 (Time in) / TrdRegTimestampType(770)=3 (Time out) to capture the time that the exchange received/sent out the OTC trade from/to the broker. Then you can calculate, for example, the time taken by the broker to confirm (assuming clocks are synced).