Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
Recently, it came to our attention that the approved Reg NMS extensions had used the ExecInst value of “18” for Intermarket Sweep Orders, which may cause incompatibility with some FIX engines.
ExecInst is defined in the spec as a Multiple Value String. These are formatted as a space-delimited list of values.
What is concerning is that to date, all values have been single characters. The FIX spec doesn’t require this to be the case, but so far it has been. ExecInst values of 0-9, A-Z, and a-e have been defined. (Some gaps are missing.) So we currently have no shortage of single character values.
As it stands right now, an All or None Intermarket Sweep Order would be represented as follows:
18=G 18[SOH]
The issues that this poses could be severe, since FIX has used single character ExecInst values for all of its history. Specifically:
-
It is possible that a sending or receiving engine might see the above string, thing that there should be a space between the 1 and the 8, and refuse to send or process the message.
-
It is possible that some FIX Engine APIs might use a character field to represent single ExecInst values, which would make multi-character ExecInst values impossible, or might truncate them to one character.
-
It is possible that some FIX implementations will simply do a character scan to pick out individual ExecInst values. So the above string would register as:
G = All or None
1 = Not Held
8 = Try to scale
As opposed to G and 18.
From this standpoint, it would make sense to change the Reg NMS document to use a single character value instead of “18”.
However, at least one major stock exchange is already implementing this as written. Changing the spec now could prove to be costly.
Does anyone have any thoughts on this? Should Intermarket Sweep Orders use a single character value, or is “18” fine? Will a dual character value break existing FIX implementations?
There have been several offline emails and conversations on this subject, with some people indicating that a multi-character value of “18” would indeed break FIX engines or applications, some indicating that it would not. But since there hasn’t been any public follow-up on the topic here, I was asked to post some feedback.
From the TransactTools FIX engine perspective, it’s not a problem. We’ve been doing FIX work with Archipelago for years, so I can also say that while it’s not a problem to handle a value of 18, it’s less than ideal since the internal API deals with ExecInst values as single characters. I’ve spoken with NYSE and they also feel that their systems could accommodate this value if needed, but that single characters are preferred.
However, my understanding is that the selection of “18” as a value was not necessarily intentional. I strongly feel - and NYSE echoes this sentiment - that if this was not intentional, let’s fix it now. Whether or not engines and applications can handle it should be a secondary concern. If we as an organization made a mistake, let’s fix it.
David Rhodes
TransactTools
Recently, it came to our attention that the approved Reg NMS extensions
had used the ExecInst value of “18” for Intermarket Sweep Orders, which
may cause incompatibility with some FIX engines.ExecInst is defined in the spec as a Multiple Value String. These are
formatted as a space-delimited list of values.What is concerning is that to date, all values have been single
characters. The FIX spec doesn’t require this to be the case, but so far
it has been. ExecInst values of 0-9, A-Z, and a-e have been defined.
(Some gaps are missing.) So we currently have no shortage of single
character values.As it stands right now, an All or None Intermarket Sweep Order would be
represented as follows:18=G 18[SOH]
The issues that this poses could be severe, since FIX has used single
character ExecInst values for all of its history. Specifically:
It is possible that a sending or receiving engine might see the above
string, thing that there should be a space between the 1 and the 8,
and refuse to send or process the message.It is possible that some FIX Engine APIs might use a character field
to represent single ExecInst values, which would make multi-character
ExecInst values impossible, or might truncate them to one character.It is possible that some FIX implementations will simply do a
character scan to pick out individual ExecInst values. So the above
string would register as:G = All or None 1 = Not Held 8 = Try to scale
As opposed to G and 18.
From this standpoint, it would make sense to change the Reg NMS document
to use a single character value instead of “18”.However, at least one major stock exchange is already implementing this
as written. Changing the spec now could prove to be costly.Does anyone have any thoughts on this? Should Intermarket Sweep Orders
use a single character value, or is “18” fine? Will a dual character
value break existing FIX implementations?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
As a part of assessing the impact to existing FIX implementations of keeping “18” for the ExecInst field, we have identified a number of firms whose systems will break or otherwise be negatively impacted. Ultimately the GTC leadership has determined that keeping its error of “18” will create a considerable degree of breakage to FIX users and that this could manifest itself in different, subtle forms. We believe that it is important now to correct this error in as timely a fashion as possible.
Therefore, we have decided to assign “f” (lower case F) as the ExecInst for Intermarket Sweep Orders. This has been updated in a revised version 1.3 of the Reg NMS implementation document available here:
http://www.fixprotocol.org/documents/2064/RegNMS_Implementation_in_FIX_v1.3_GTCApproved.doc
Additionally, certain enumerations for the Sub-penny Rule listed with a temporary “TBD” value have, in this revision, been assigned real values.
In addition to the way to identify Intermarket Sweep Orders via FIX, we are looking for a method of indication of customer’s consent to utilization of the ISO exception (aka “opt out” indication). This essentially gives a broker a permission to fill a block order at a predetermined price without waiting for completion of the intermarket sweep. More details can be found in this SEC Q&A Section for the RegNMS (apologies for a long quote):
"Question 15: A broker-dealer intends to utilize the ISO exception to execute a block trade for a customer at a price inferior to one or more protected quotations. How should the block trading desk execute and report the block trade in compliance with the ISO exception? Answer: Under Rule 611(b)(6), the broker-dealer is required to route, simultaneously with execution of the block trade, an ISO to execute against the full displayed size of any protected quotation with a price superior to the block trade price. To meet this requirement, the broker-dealer will need to utilize an automated system that is capable of ascertaining current protected quotations and simultaneously routing the necessary ISOs. As part of the broker-dealer’s periodic surveillance under Rule 611(a)(2), ISOs should be compared with the protected quotations at the time of execution to affirm that the ISOs were properly routed (see Question 28 below). The Staff does not believe that it would be possible for manual routing of ISOs to comply with the requirement in Rule 611(b)(6). The extent to which a routed ISO will receive an execution at the destination trading center cannot be known at the time of routing (for example, the protected quotation may already have been executed against or cancelled prior to arrival of the ISO). As a result, a broker-dealer could face practical issues in implementing the block trade for its customer, including (1) transferring to the customer the benefit of any better prices obtained through executed ISOs, (2) handling the residual size of ISOs that did not receive a fill, and (3) reporting the block trade to the relevant SRO.12 The Staff believes that there are several ways for a broker-dealer reasonably to address these practical issues, depending on the preferences of its customers.
"If, for example, a customer consents to not receiving the benefit of any better prices obtained by the ISOs, the broker-dealer could report the block trade immediately on the routing of the ISO orders because the block trade size would not be affected by any fills of the ISOs. By giving its informed consent, the customer would, in effect, recognize that the block price was determined, at least in part, by a judgment of the extent to which the broker-dealer would receive fills of the ISOs at better prices. If, however, the broker-dealer’s customer wished to receive the benefit of any better prices obtained by the ISOs, reporting the block trade is more problematic because its ultimate size will not be known until responses are received to the ISOs (i.e., any fills will reduce the size of the block trade). If the ISOs are also marked as IOC, the Staff believes that the reporting of the block trade could await responses to the IOC/ISOs for a reasonable time (e.g., five seconds or less). At that point, the size of the block trade would be reduced to reflect any fills of the ISOs, and the block trade could be reported to the relevant SRO as an ISO execution. Importantly, however, all material terms of the block trade would need to have been finally agreed upon at the time when the ISOs were routed, subject only to adjusting the block trade size to reflect ISO fills. Under these circumstances, the Staff would consider the broker-dealer to have met the “simultaneous routing” requirement of Rule 611(b)(6). Therefore, the broker-dealer would not be required to route any additional ISOs when the block trade is reported to the relevant SRO. Further complications could arise if the broker-dealer does not receive a response within a reasonable time to all of the ISOs. To address this situation (which should not occur frequently because of the immediate response requirement for IOC orders), the customer could agree, in advance, to consider the lost IOC/ISO to be unexecuted and to include its size in the block trade at the block price. Alternatively, the block trade could be reported at a reduced size to reflect the lost IOC/ISO, pending its ultimate resolution. "
We do not believe that the current Implementation of Regulation NMS in FIX document contains such a mechanism. Is there any work done currently to introduce such opt out indication in FIX? If not, ccould we request a consideration of how it can be accomplished as a part of this Implementation document.
Regards,
Yuri Salkinder
Credit Suisse
As a part of assessing the impact to existing FIX implementations of
keeping “18” for the ExecInst field, we have identified a number of
firms whose systems will break or otherwise be negatively impacted.
Ultimately the GTC leadership has determined that keeping its error of
“18” will create a considerable degree of breakage to FIX users and
that this could manifest itself in different, subtle forms. We believe
that it is important now to correct this error in as timely a fashion
as possible.Therefore, we have decided to assign “f” (lower case F) as the ExecInst
for Intermarket Sweep Orders. This has been updated in a revised version
1.3 of the Reg NMS implementation document available here:http://www.fixprotocol.org/documents/2064/RegNMS_Implementation_in_FIX_-
v1.3_GTCApproved.docAdditionally, certain enumerations for the Sub-penny Rule listed with a
temporary “TBD” value have, in this revision, been assigned real values.
Members of the FPL Americas Committee and the Financial Information Forum met to discuss adding a value to ExecInst to indicate that a firm requests a single execution on a block trade rather than waiting for additional ISO fills.
The proposed revision to FIX 5.0 is discussed in the following document available at:
http://www.fixprotocol.org/documents/2968/Addition_to_RegNMS_Implementation_in_FIX_Proposal_v1%201.doc
Values for the tag will be assigned by the Global Technical Committee. This proposed revision will be discussed at the November 16 GTC meeting. Following approval, a value will be assigned to the Single Execution Indicator.
Please respond to this thread by Friday, November 10 if you haveany issues with the proposed change.
Regards,
Manisha Kimmel
Financial Information Forum
In addition to the way to identify Intermarket Sweep Orders via FIX, we
are looking for a method of indication of customer’s consent to
utilization of the ISO exception (aka “opt out” indication). This
essentially gives a broker a permission to fill a block order at a
predetermined price without waiting for completion of the intermarket
sweep. More details can be found in this SEC Q&A Section for the RegNMS
(apologies for a long quote):"Question 15: A broker-dealer intends to utilize the ISO exception to
execute a block trade for a customer at a price inferior to one or more
protected quotations. How should the block trading desk execute and
report the block trade in compliance with the ISO exception? Answer:
Under Rule 611(b)(6), the broker-dealer is required to route,
simultaneously with execution of the block trade, an ISO to execute
against the full displayed size of any protected quotation with a price
superior to the block trade price. To meet this requirement, the broker-
dealer will need to utilize an automated system that is capable of
ascertaining current protected quotations and simultaneously routing the
necessary ISOs. As part of the broker-dealer’s periodic surveillance
under Rule 611(a)(2), ISOs should be compared with the protected
quotations at the time of execution to affirm that the ISOs were
properly routed (see Question 28 below). The Staff does not believe that
it would be possible for manual routing of ISOs to comply with the
requirement in Rule 611(b)(6). The extent to which a routed ISO will
receive an execution at the destination trading center cannot be known
at the time of routing (for example, the protected quotation may already
have been executed against or cancelled prior to arrival of the ISO). As
a result, a broker-dealer could face practical issues in implementing
the block trade for its customer, including (1) transferring to the
customer the benefit of any better prices obtained through executed
ISOs, (2) handling the residual size of ISOs that did not receive a
fill, and (3) reporting the block trade to the relevant SRO.12 The Staff
believes that there are several ways for a broker-dealer reasonably to
address these practical issues, depending on the preferences of its
customers."If, for example, a customer consents to not receiving the benefit of
any better prices obtained by the ISOs, the broker-dealer could report
the block trade immediately on the routing of the ISO orders because the
block trade size would not be affected by any fills of the ISOs. By
giving its informed consent, the customer would, in effect, recognize
that the block price was determined, at least in part, by a judgment of
the extent to which the broker-dealer would receive fills of the ISOs at
better prices. If, however, the broker-dealer’s customer wished to
receive the benefit of any better prices obtained by the ISOs, reporting
the block trade is more problematic because its ultimate size will not
be known until responses are received to the ISOs (i.e., any fills will
reduce the size of the block trade). If the ISOs are also marked as IOC,
the Staff believes that the reporting of the block trade could await
responses to the IOC/ISOs for a reasonable time (e.g., five seconds or
less). At that point, the size of the block trade would be reduced to
reflect any fills of the ISOs, and the block trade could be reported to
the relevant SRO as an ISO execution. Importantly, however, all material
terms of the block trade would need to have been finally agreed upon at
the time when the ISOs were routed, subject only to adjusting the block
trade size to reflect ISO fills. Under these circumstances, the Staff
would consider the broker-dealer to have met the “simultaneous routing”
requirement of Rule 611(b)(6). Therefore, the broker-dealer would not be
required to route any additional ISOs when the block trade is reported
to the relevant SRO. Further complications could arise if the broker-
dealer does not receive a response within a reasonable time to all of
the ISOs. To address this situation (which should not occur frequently
because of the immediate response requirement for IOC orders), the
customer could agree, in advance, to consider the lost IOC/ISO to be
unexecuted and to include its size in the block trade at the block
price. Alternatively, the block trade could be reported at a reduced
size to reflect the lost IOC/ISO, pending its ultimate resolution. "We do not believe that the current Implementation of Regulation NMS in
FIX document contains such a mechanism. Is there any work done currently
to introduce such opt out indication in FIX? If not, ccould we request a
consideration of how it can be accomplished as a part of this
Implementation document.Regards,
Yuri Salkinder Credit Suisse
As a part of assessing the impact to existing FIX implementations of
keeping “18” for the ExecInst field, we have identified a number of
firms whose systems will break or otherwise be negatively impacted.
Ultimately the GTC leadership has determined that keeping its error of
“18” will create a considerable degree of breakage to FIX users and
that this could manifest itself in different, subtle forms. We believe
that it is important now to correct this error in as timely a fashion
as possible.Therefore, we have decided to assign “f” (lower case F) as the
ExecInst for Intermarket Sweep Orders. This has been updated in a
revised version
1.3 of the Reg NMS implementation document available here:tp://www.fixprotocol.org/documents/2064/RegNMS_Implementation_in_FIX_-
v1.3_GTCApproved.docAdditionally, certain enumerations for the Sub-penny Rule listed
with a temporary “TBD” value have, in this revision, been assigned
real values.