Imported from previous forum
The Global Technical Committee has reviewed and preliminarily approved the SEC Short Sale Proposal. The document now enters a public comment period in which public review and feedback is encouraged. Once the Public Comment period closes, the Global Technical Governance Board will meet to review public comments before final approval.
Please post feedback, comments, and questions as replies to this discussion thread.
A link to the proposal can be found at:
http://www.fixprotocol.org/documents/5274/FIX%20Protocol%20Gap%20Analysis%20-%20SEC%20Short%20Sale%20Rules%200.3.doc
The public comment period ends on July 28, 2010.
While in general I agree with the proposal, I do disagree with a modification made to it at the GTC meeting during which it was considered.
ShortSaleRestriction is now defined as an int, and is not part of a repeating group. While the three existing enumerations that are part of the proposal today:
0 = No restrictions
1 = Security is not shortable
2 = Security not shortable below the best bid
are mutually exclusive, and could be represented by a single int, I believe the approach is not flexible for future needed expansion.
I see the need for ShortSaleRestriction as a place to list applicable regulatory restrictions that may apply to shorting an instrument, where multiple restrictions might be invoked at the same time. For example, on the last FIF/FPL Regulatory WG call, we discussed the need to flag certain “threshold securities” that historically have had delivery fails, and broker/dealers need to take extra steps, which don’t apply to other securities, to ensure that they can actually deliver the security before shorting it. This requirement was deferred, since we felt we did not want to delay the GA further. But both this short sale restriction and the #2 restriction above could be applicable to the same instrument. This cannot be addressed cleanly by the current proposal. Yes, it is possible to create more enums:
3 = Threshold security
4 = Threshold security not shortable below the best bid
But enumerating all possible permutations is not a sustainable design practice.
It follows that we need to allow expressing multiple ShortSaleRestriction enums per instrument. Originally, we proposed that a MultipleStringValue datatype be used. It is similar to what was done for OrderRestrictions (529) which contains a list of regulatory flags for an order.
Concerns have been raised that MultipleStringValue and MultipleCharValue fields are not efficient to parse. I disagree. I believe they are more efficient in bandwidth and latency than a repeating group.
In summary, I’m concerned that this proposal is limiting FPL’s ability to extend ShortSaleRestriction, preventing it from supporting existing and future regulatory initiatives.
I believe that FIX blurred the line between semantics and syntax (encoding) when introducing data types MultipleStringValue and MultipleCharValue. These data types prescribe an encoding by concatenating values separated by blanks into a single large string. Luckily, only 11 out of the almost 1700 FIX fields have one of these two data types. It seems to make even less sense when applying these to multiple values which are numbers. A more efficient encoding would be to use numbers 1,2,4,8,16,… and encode them as bits. 8 values would then fit into a single byte instead of requiring 15 bytes (“0 1 2 3 4 5 6 7 8”). Processing with bit masks should be faster than parsing a string looking for blanks. But as said before, syntax and semantics should be decoupled. If multiple values are really needed from a business perspective, the semantics should be expressed as a repeating group instead. The syntax (encoding) of a repeating group is a separate task. FAST v1.2 provides some good examples for efficient encoding. Using MultipleXXXValue data types to improve tag=value ASCII encoding seems to me to be the wrong approach nowadays, compared to a binary encoding.
I doubt that a repeating group is really needed here. The proposal adds the new field to the Instrument block. Hence, it applies to a single security and cannot be used to express that the restriction only applies to threshold securities but not to other securities. You might need another field ThresholdIndicator in the Instrument block to define this instrument to be a threshold instrument. But maybe it is better to put it into AttrGrp, a generic repeating group inside the Instrument Extension block with type/value pairs. Being a threshold security is independent from being subject to shortsale restrictions. The two elements do not need to be bundled together.
Regards,
Hanno.
While in general I agree with the proposal, I do disagree with a modification made to it at the GTC meeting during which it was considered.
ShortSaleRestriction is now defined as an int, and is not part of a repeating group. While the three existing enumerations that are part of the proposal today:
0 = No restrictions
1 = Security is not shortable
2 = Security not shortable below the best bidare mutually exclusive, and could be represented by a single int, I believe the approach is not flexible for future needed expansion.
I see the need for ShortSaleRestriction as a place to list applicable regulatory restrictions that may apply to shorting an instrument, where multiple restrictions might be invoked at the same time. For example, on the last FIF/FPL Regulatory WG call, we discussed the need to flag certain “threshold securities” that historically have had delivery fails, and broker/dealers need to take extra steps, which don’t apply to other securities, to ensure that they can actually deliver the security before shorting it. This requirement was deferred, since we felt we did not want to delay the GA further. But both this short sale restriction and the #2 restriction above could be applicable to the same instrument. This cannot be addressed cleanly by the current proposal. Yes, it is possible to create more enums:
3 = Threshold security
4 = Threshold security not shortable below the best bidBut enumerating all possible permutations is not a sustainable design practice.
It follows that we need to allow expressing multiple ShortSaleRestriction enums per instrument. Originally, we proposed that a MultipleStringValue datatype be used. It is similar to what was done for OrderRestrictions (529) which contains a list of regulatory flags for an order.
Concerns have been raised that MultipleStringValue and MultipleCharValue fields are not efficient to parse. I disagree. I believe they are more efficient in bandwidth and latency than a repeating group.
In summary, I’m concerned that this proposal is limiting FPL’s ability to extend ShortSaleRestriction, preventing it from supporting existing and future regulatory initiatives.
Hanno,
I disagree that threshold security classification is not a short sale restriction. It is a property of the instrument, designated by regulators and/or exchanges, that imposes additional restrictions on whether a short sale order should be sent or accepted. Whether the prohibition applies on all orders for the instrument, or it requires making a price check, or it requires making a check on inventory for delivery, shouldn’t matter. All are per-instrument short sale restrictions, so it seems they should all go in the same field.
Additionally, threshold security classification is just one additional rule that I know of today. We’ve not examined other markets. I think it is very likely that we will find families of rules restricting short sales on instruments, where more than one of those rules may apply to a single instrument. I’m uncomfortable limiting ourselves to one and only one short sale restriction per security.
Bitmask encoding has never been done before in the FIX spec itself. (I consider FAST external to the FIX Protocol for these purposes.) This proposal is extremely urgent, given that it is required by a regulator, so starting from scratch to flesh out a bitmask datatype doesn’t sound appealing.
Making the field a repeating group would work, but it has a drawback: as this is a regulatory change, it will almost certainly be ported backwards into older FIX versions. Adding a field from a later version is much easier for many engines than adding a repeating group of fields.
Regards,
Ryan
Ryan,
you are right that a repeating group has its drawbacks too and the proposal suggests to avoid them (and the drawbacks of MultipleXXXValue data types) by adding a simple field. There are no such drawbacks with multiple fields related to a single functional concept like short sale restrictions. Thy typical way FIX handles this is by creating a non-repeating component block, e.g. to cover various aspects of reserve orders. Components have no technical impact on tag=value encoding.
My argument about bitmasks was misunderstood. The intention is to avoid such data types in FIX as they belong to the syntax/encoding level. Any analogy has its limitations but maybe you can compare it to the SQL language and physical databases. SQL is descriptive and tells you what the result set should look like. The DB admin then has to design access paths to the underlying tables to allow the efficient and fast retrieval of the data. SQL as a language does not have elements to prescribe which index to use for a query. This is left to the query optimizer. The same should be true for FIX and its encoding, be it tag=value, FIXML or FAST which should all be semantically equivalent.
Regards,
Hanno.
Hanno,
I disagree that threshold security classification is not a short sale restriction. It is a property of the instrument, designated by regulators and/or exchanges, that imposes additional restrictions on whether a short sale order should be sent or accepted. Whether the prohibition applies on all orders for the instrument, or it requires making a price check, or it requires making a check on inventory for delivery, shouldn’t matter. All are per-instrument short sale restrictions, so it seems they should all go in the same field.
Additionally, threshold security classification is just one additional rule that I know of today. We’ve not examined other markets. I think it is very likely that we will find families of rules restricting short sales on instruments, where more than one of those rules may apply to a single instrument. I’m uncomfortable limiting ourselves to one and only one short sale restriction per security.
Bitmask encoding has never been done before in the FIX spec itself. (I consider FAST external to the FIX Protocol for these purposes.) This proposal is extremely urgent, given that it is required by a regulator, so starting from scratch to flesh out a bitmask datatype doesn’t sound appealing.
Making the field a repeating group would work, but it has a drawback: as this is a regulatory change, it will almost certainly be ported backwards into older FIX versions. Adding a field from a later version is much easier for many engines than adding a repeating group of fields.
Regards,
Ryan
Shouldn’t the enumeration, “2=Security not shortable below the best” bid, be changed to “2=Security not shortable AT OR BELOW the best bid”?
Shouldn’t the enumeration, “2=Security not shortable below the best” bid, be changed to “2=Security not shortable AT OR BELOW the best bid”?
Good catch; I think you’re right. The GA itself quotes the text of the rule in question as:
(i) Prevent the execution or display of a short sale order of a covered security at a price that is less than or equal to the current national best bid if the price of that covered security decreases by 10% or more from the covered security’s closing price as determined by the listing market for the covered security as of the end of regular trading hours on the prior day
Was it resolved that proposed new field, ShortSaleRestriction, would not have a default value?
Without a default value the field would only need to be included in a message when its value changes.
With the default value every message with an Instrument Block would need to include this field whenever a restriction is in place.
Was it resolved that proposed new field, ShortSaleRestriction, would not have a default value?
Without a default value the field would only need to be included in a message when its value changes.
With the default value every message with an Instrument Block would need to include this field whenever a restriction is in place.
The initial draft had a default of no restriction. We realized the adverse implications of this, and removed it in later drafts. I just checked the draft posted for public comment, and there is no default.