Imported from previous forum
Hi,
we provide an OMS to both buy-side and sell-side clients. We generated our own ExecID(tag 17) and TransactTime(tag 60) when we match buyside to sellside and that is what is publish out onto fix.
some of our buy side firms want to also provide their own ExecID and TransactTime fields. We want to use SecondaryExecID(527) for client contributed ExecID.
What are ya’ll recommendations as the best field to use for the secondary TransactTime that clients want to contribute ? if indeed there is anything to use. We might have to do custom fields.
thanks
What version of FIX are you using?
Hi,
we provide an OMS to both buy-side and sell-side clients. We generated
our own ExecID(tag 17) and TransactTime(tag 60) when we match buyside to
sellside and that is what is publish out onto fix.some of our buy side firms want to also provide their own ExecID and
TransactTime fields. We want to use SecondaryExecID(527) for client
contributed ExecID.What are ya’ll recommendations as the best field to use for the
secondary TransactTime that clients want to contribute ? if indeed there
is anything to use. We might have to do custom fields.thanks
We are on our own bastardized 4.1 but we can add any from other versions that might have this.
What version of FIX are you using?
Hi,
we provide an OMS to both buy-side and sell-side clients. We generated
our own ExecID(tag 17) and TransactTime(tag 60) when we match buyside
to sellside and that is what is publish out onto fix.
some of our buy side firms want to also provide their own ExecID and
TransactTime fields. We want to use SecondaryExecID(527) for client
contributed ExecID.What are ya’ll recommendations as the best field to use for the
secondary TransactTime that clients want to contribute ? if indeed
there is anything to use. We might have to do custom fields.thanks
Later versions of FIX have a TrdRegTimestamps component block that would work.
http://www.fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/body_49485048.html
But it might just be easier to use custom tag :
5164 SecondaryTransactTime
Time of execution at the exchange level when TransactTime is already used by the broker order management system.
We are on our own bastardized 4.1 but we can add any from other versions
that might have this.What version of FIX are you using?
Hi,
we provide an OMS to both buy-side and sell-side clients. We
generated our own ExecID(tag 17) and TransactTime(tag 60) when we
match buyside to sellside and that is what is publish out onto fix.
some of our buy side firms want to also provide their own ExecID
and TransactTime fields. We want to use SecondaryExecID(527) for
client contributed ExecID.What are ya’ll recommendations as the best field to use for the
secondary TransactTime that clients want to contribute ? if indeed
there is anything to use. We might have to do custom fields.thanks
I wonder why SecondaryTransactTime never made it into the spec - maybe because of the TrdRegTimestamps block. Although the TrdRegTimestamps was added specifically to address regulatory timestamps required for computerized trade reconstruction as mandated by the CFTC for US markets.
Later versions of FIX have a TrdRegTimestamps component block that would
work.
http://www.fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/body_49485048.htmlBut it might just be easier to use custom tag :
5164 SecondaryTransactTime Time of execution at the exchange level when
TransactTime is already used by the broker order management system.We are on our own bastardized 4.1 but we can add any from other
versions that might have this.What version of FIX are you using?
Hi,
we provide an OMS to both buy-side and sell-side clients. We
generated our own ExecID(tag 17) and TransactTime(tag 60) when we
match buyside to sellside and that is what is publish out onto
fix. some of our buy side firms want to also provide their own
ExecID and TransactTime fields. We want to use
SecondaryExecID(527) for client contributed ExecID.What are ya’ll recommendations as the best field to use for the
secondary TransactTime that clients want to contribute ? if indeed
there is anything to use. We might have to do custom fields.thanks
Thanks Jim.
I think a custom tag is more descriptive of the intent in our case.
Later versions of FIX have a TrdRegTimestamps component block that would
work.
http://www.fixprotocol.org/FIXimate3.0/en/FIX.5.0SP2/body_49485048.htmlBut it might just be easier to use custom tag :
5164 SecondaryTransactTime Time of execution at the exchange level when
TransactTime is already used by the broker order management system.We are on our own bastardized 4.1 but we can add any from other
versions that might have this.What version of FIX are you using?
Hi,
we provide an OMS to both buy-side and sell-side clients. We
generated our own ExecID(tag 17) and TransactTime(tag 60) when we
match buyside to sellside and that is what is publish out onto
fix. some of our buy side firms want to also provide their own
ExecID and TransactTime fields. We want to use
SecondaryExecID(527) for client contributed ExecID.What are ya’ll recommendations as the best field to use for the
secondary TransactTime that clients want to contribute ? if indeed
there is anything to use. We might have to do custom fields.thanks
I would like to continue this forum:
So, what is the recommendation if it needs a secondary transaction time in an ER?
(i.e. use 5164 SecondaryTransactTime, or TrdRegTimestamps, or ??)
@robertlau standard fields/components are always preferred, i.e. the recommendation is to use TrdRegTimestamps. TrdRegTimestampType(770) does not allow user-defined values. However, there are a large number of standard values by now.
Where exactly is the timestamp taken by the buy-side? Are we talking about an ExecutionReport(35=8) received by the buy-side from the sell-side and being converted into an ExecutionReport(35=8) sent by the buy-side to its client?
Note that ExecID(17) and TransactTime(60) are relative, i.e. they pertain to the two counterparties sending/receiving a given ExecutionReport(35=8). Towards the client, the buy-side would use ExecID(17) TransactTime(60) for their “own” execution identifier and timestamp and then need separate fields to convey the same data elements related to a third party, e.g. the sell-side or exchange.
@robertlau My question is what’s the intent or purpose of a secondary transact time? How are you interpreting or using the value in the field, what does it mean to you and parties facing you?
The TrdRegTimestamp component is primarily use to capture discrete timestamps in the various points of the transaction lifecycle for regulatory reasons. The definition of the different TrdRegTimestampType values are quite specific and should not be ambiguous.
Thanks.
Assume we are a routing system. I am thinking the flow:
Client ↔ Our Routing System ↔ Execution Venue (i.e. a matching engine)
- Client sends NewSingleOrder to Our Routing System.
- (a) Our Routing System replies Pending New ER to the client, with TransactTime = Local server time in out Our Routing System; (b) Our Routing System forwards the NewSingleOrder to Execution Venue.
- Execution Venue replies New ER to Our Routing System, with Server time in Execution Venue.
- Our Routing System will reply New ER to the client. In this New ER, I am thinking we need to put down the processing/received time in Our Routing System. So, this New ER to client will carry: (a) Server time in Execution Venue - using field TransactTime; (b) Processing/received time in Our Routing System - using a field like “Secondary Transaction Time”. (or it is better to use “Secondary Transaction Time” to store Server time in Execution Venue?)
Also, in the New ER to client, the ExecID will be generated by Our Routing System, not by the Execution Venue
My original query is what field should be used for this “Secondary Transaction Time”
(P.S. as also from my previous post, in Step 2 (The Pending New) and 4 (The New), Since these two messages are generated in two venues, and therefore, due to clock unsync-ed, the TransactTime might not be in sequence).