Comment Text:
With respect to Appendix C to Part 17 - Data Elements here are my comments...
* Row 5 (Message Transmit Datetime) In the definition change the word "created" to "sent" or "transmitted". "Created" is not clear.
* Row 13 (Commodity Clearing Code) Keep the name "commodity code". It is more clear than "commodity clearing code". In the definition change the word "clearinghouse-assigned" to "exchange". Row 12 uses the word "exchange" and it should be used here too. The commodity code is assigned by the exchange, so this more clear.
* Row 34 (Contract Bought) In the definition remove all allocations/giveups. Allocations are NOT contracts bought. The inclusion of allocations will result in an inaccurate measurement of contracts bought. The same contracts can be allocated multiple times across the same day and even multiple days causing double-counting.
* Row 35 (Contract Sold) In the definition remove all allocations/giveups. Allocations are NOT contracts sold. The inclusion of allocations will result in an inaccurate measurement of contracts sold. The same contracts can be allocated multiple times across the same day and even multiple days causing double-counting.
* Add the following four rows to capture allocations/giveups
1) Name: Long Post-trade Allocations Sent/Offset
Definition: the long contracts allocated (gross) sent/offset
2) Name: Long Post-trade Allocations Received/Onset
Definition: the long contracts allocations (gross) received/onset
3) Name: Short Post-trade Allocations Sent/Offset
Definition: the short contracts allocated (gross) sent/offset
4) Name: Short Post-trade Allocations Received/Onset
Definition: the short contracts allocated (gross) received/onset
* Add a row to record the count of transferred delivery notices.
1) Name: Delivery Notices Transferred
Definition: Delivery notices transferred (gross)
* Add a row to indicate when a record has been corrected.
With respect to submitting error corrections or deletions here are my comments...
Positive confirmation of what the data was before and after the change makes it clear what the change was. This should happen.
Deletions should not be allowed. It appears that the proposed rule treats data/records deleted as no longer part of the government record. Submissions submitted and received should not be deleted. If deletions are allowed that opens the door to spoofing/gaming the data by entering false information to provide data at one point in time and then changing it later. This potential should not be allowed. Also it is important for Market Surveillance to know that certain parties are repeatedly changing their submissions. This is an indication that something is not right.
With regards to section I.C entitled "Shortcomings of the Regulation 17.00(g) Record Format", I offer the following comments...
It seems that much of the text dedicated to explain why this rule change is necessary misses the point. The result of the bulk of the changes are new data elements, changed data elements, changed correction/deletion procedures and changed delegated authority. This is accomplished through a change that affects all reporters, the shifting to an xml-based format from a fixed-column format. When I read the text of the rule I see less critical details being emphasized.
As a matter of clarification to the first point, while the current 80 character format may have had it origins in the Cobol language, it is not specific to the Cobol Language. The 80 character fixed-column data format can be processed by most any computer. Decoding the format now is no different than it was decades ago.
As a matter of clarification to the second point, it is inaccurate to say that the current 80 character format has "grown" error prone. The standard has not changed, so it could not have "grown". The standard collects the same data in the same manner as it always has. Similarly it is inaccurate to say that the 17.00(g) format does not support automated data checks and therefore requires manual checking. The data provided in the submission could be checked by automated means in the same manner that a human could manually check the data.
As a matter of clarification to the third point, the data being in the 17.00G format does not make it more or less difficult to query. The submitted data is processed into various database tables at the CFTC, which is just normal.
As a matter of clarification to the fourth point, it is inaccurate to say that the existing record format no longer meets its purpose because it did not have all the fields necessary to capture all aspects of a few particular option products. The current format was may never have been designed to capture all aspects of options. It was only ever capable of distinguishing between options by put/call, exercise type, and strike price. While more fields dedicated to product description would allow market surveillance a more granular view of options and generally be a good addition, this does not mean the original format was not fulfilling its intended goal. The number of binary and bounded options is very small.
In summary, while I support the goal of increasing the granularity of the reporting, the reasons stated in section I.C do not accurately describe the current situation. The changes within this NOPR are primarily focused on the content of data being required, the process of correcting the data, and who has delegated authority with respect to the rule. The change from a column-based format to an XML-based format is certainly a change that effects the reporting firms greatly, but will not ultimately impact the government analyst end-users since the data they use will be in database tables or separate applications.
I appreciate the opportunity to make this public statement. I value my civic duty.
Best Regards,
Martha
