OATS v3

, ,
1

Imported from previous forum

2

[ original email was from John Prewett - jprewett@lavatrading.com ]
Is there any move afoot to standardize on tag usage for OATS v3?

3

Is there any move afoot to standardize on tag usage for OATS v3?

This is a response to the above inquiry and another posting in the ECN discussion forum (http://www.fixprotocol.org/discuss/read/c14ac231).

FPL is investigating this. If anyone would like to help out with the requirements analysis for OATS v3 as it relates to FIX please email me.

Lisa Taikitsadaporn

4

Is there any move afoot to standardize on tag usage for OATS v3?

This is a response to the above inquiry and another posting in the ECN
discussion forum (http://www.fixprotocol.org/discuss/read/c14ac231).

FPL is investigating this. If anyone would like to help out with the
requirements analysis for OATS v3 as it relates to FIX please email me.

Lisa Taikitsadaporn

We’re interested in this whole issue as we are now in the process of building a Phase III reporting system. Some standardization in this area would be great since a lot of the data we need for OATS is getting mined out of FIX messages…

5

[ original email was from John Prewett - jprewett@lavatrading.com ]
In case there are other interested parties, I am proposing that FIX Protocol Ltd create two new entities specifically for OATS v3. The first one is a new tag. The second one is either a new ExecInst(tag 18) value or a new tag. I prefer that FIX Protocol Ltd assigns tag numbers (or ExecInst values) in order to dissuade everyone who needs to convey this data from creating their own custom tags.

Name: BrokerOrderReceiveTime
Type: UTCTimeStamp
Applicable message types: NewOrderSingle; OrderCancelReplaceRequest; OrderCancelRequest
Description: OATS v3 tag indicating the time the broker first received the order from the customer.
Default: If the field is missing, it should be assumed that there was no time delay between the Broker receiving the order and entering it into the electronic system.

Name: CustomerDirectedOrder
Type: Boolean
Applicable message types: NewOrderSingle; OrderCancelReplaceRequest
Description: OATS v3 tag indicating if the customer directed this order to a specific execution venue (Y) or not (N).
Default: A default of N – customer didn’t direct this order – should be used in the case where the information is both missing and essential.
Alternative suggestion: This information could be conveyed with a new, unique value in the ExecInst (tag 18) field which might be easier for some FIX engines than a new tag.

I am currently awaiting feedback from the Americas Regional Committee concerning this proposal. Hopefully this will happen shortly given the tight deadlines for OATS v3 production implementation.

JohnP

6

[ original email was from Eric Gottesman - egottesman@jefexservices.com ]
In regards to your item #2, I have already registered a user defined tag with FPL for identifying orders which are non-directed. NonDirectedFlag (FID 9779): Non-directed order flag. Facilitates SEC reporting of non-directed orderflow. Used mainly by post-trade processing, flagging orders that are non-directed. Valid values: Y=Non-directed, N=Directed.

In regards to item #1, we have been having a number of discussions on
how to interpret the “time of receipt”. Should it be the time the FIX engine captured the order, or the time the broker’s biz logic validated/accepted the order, or use SendingTime (trust the customer’s time is correct)? The problem with OATSv3, is that it does not seem to account for small systemic latency/queues that may occur
during normal trading, i.e. customer sends order at 11:00:01 but our broker FIX engine receives it at 11:00:02, and actually process/validate the order at 11:00:04 due to a large queue of orders. My personal feeling is that since the order was not received by the broker until :04, that this is the time to report to OATS, which may cause a mismatch.
I’d be interested to hear some other thoughts on the subject.

Thanks,

Eric Gottesman
VP, Technology Development
Jefferies Execution Services

In case there are other interested parties, I am proposing that FIX
Protocol Ltd create two new entities specifically for OATS v3. The first
one is a new tag. The second one is either a new ExecInst(tag 18) value
or a new tag. I prefer that FIX Protocol Ltd assigns tag numbers (or
ExecInst values) in order to dissuade everyone who needs to convey this
data from creating their own custom tags.

1.Name: BrokerOrderReceiveTime Type: UTCTimeStamp Applicable message
types: NewOrderSingle; OrderCancelReplaceRequest; OrderCancelRequest
Description: OATS v3 tag indicating the time the broker first received
the order from the customer. Default: If the field is missing, it
should be assumed that there was no time delay between the Broker
receiving the order and entering it into the electronic system.

2.Name: CustomerDirectedOrder Type: Boolean Applicable message types:
NewOrderSingle; OrderCancelReplaceRequest Description: OATS v3 tag
indicating if the customer directed this order to a specific execution
venue (Y) or not (N). Default: A default of N – customer didn’t direct
this order – should be used in the case where the information is both
missing and essential. Alternative suggestion: This information could
be conveyed with a new, unique value in the ExecInst (tag 18) field
which might be easier for some FIX engines than a new tag.

I am currently awaiting feedback from the Americas Regional Committee
concerning this proposal. Hopefully this will happen shortly given the
tight deadlines for OATS v3 production implementation.

JohnP

7

[ original email was from John Prewett - jprewett@lavatrading.com ]
The interpretation that I was given for #1 is the time when the broker first received the order from the customer. The example given was the customer and broker playing a round of golf (sounds like a real-life example to me). The customer verbally gives the broker the order at the 12th tee. The broker uses his laptop in the clubhouse while at the 19th hole and enters the order. BrokerOrderReceiveTime would be the time when the verbal order was given on the 12th tee. It would have nothing to do with TransactTime, SendingTime etc,. I don’t think it is concerned with “small” latencies, so if the broker enters an order directly into an electronic system at the moment when a customer gives it to him, this time isn’t needed.

JohnP

In regards to your item #2, I have already registered a user defined tag with FPL for identifying orders which are non-directed. NonDirectedFlag (FID 9779): Non-directed order flag. Facilitates SEC reporting of non-directed orderflow. Used mainly by post-trade processing, flagging orders that are non-directed. Valid values: Y=Non-directed, N=Directed.

In regards to item #1, we have been having a number of discussions on
how to interpret the “time of receipt”. Should it be the time the FIX
engine captured the order, or the time the broker’s biz logic
validated/accepted the order, or use SendingTime (trust the customer’s
time is correct)? The problem with OATSv3, is that it does not seem to
account for small systemic latency/queues that may occur during normal
trading, i.e. customer sends order at 11:00:01 but our broker FIX engine
receives it at 11:00:02, and actually process/validate the order at
11:00:04 due to a large queue of orders. My personal feeling is that
since the order was not received by the broker until :04, that this is
the time to report to OATS, which may cause a mismatch. I’d be
interested to hear some other thoughts on the subject.

Thanks,

Eric Gottesman VP, Technology Development Jefferies Execution Services

8

[ original email was from John Prewett - jprewett@lavatrading.com ]
I notice from the following NASD notice that compliance with OATS v3 has been extended from the original May 8th date to the new date of July 10th.

Here is the link:
http://www.nasd.com/web/idcplg?IdcService=SS_GET_PAGE&ssDocName=NASDW_016412&ssSourceNodeId=5