Imported from previous forum
The Global Technical Committee has reviewed and preliminarily approved the German HFT Act Extension. On 28 February 2013 the German Parliament adopted the High Frequency Trading Act (Hochfrequenzhandelsgesetz, HFT Act). The HFT Act introduces a license requirement for high frequency traders, imposes conduct of business rules and organisational requirements for algorithmic trading and specifies the definition of market abuse.
Objectives are to increase the stability and integrity of the German financial markets, to prevent market manipulation by high frequency traders and to protect long-term investors and minimise market risks.
Further information about the German High Frequency Trading Act can be found at: http://www.bafin.de/SharedDocs/Veroeffentlichungen/EN/Meldung/2013/meldung_130322_hft-gesetz_en.html
This gap analysis proposes enhancements to support the requirement to convey regulatory information on all order and quote related messages as well as on the request to maintain instruments and the ability to support a free format text field for compliance information.
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.fixtradingcommunity.org/pg/file/fplpo/read/944677/fix-protocol-ga-german-hft-act
The public comment period ends on January 30, 2014.
Fidessa welcomes FIX Protocol's public consultation on the German HFT Act Extension and the opportunity to comment this paper.
At its most general, Fidessa welcomes the notion to provide a standardised FIX tag to support the algorithmic disclosure requirements of the German High Frequency Trading Act.
The current proposal assumes that the regulatory information (RegulatoryID) can be encoded as numeric value supported by the ComplianceID(376). However, Fidessa is concerned that it is not sufficient, instead we believe that an alphanumeric is the more appropriate format. Our arguments supporting that statement are as follows.
Most importantly, we note that an alphanumeric format provides greater flexibility to all industry members because it can be used to display a numeric value, while a numeric format cannot be used to display a string. Thus, Fidessa views the preferable data format to be one that supports an alphanumeric RegulatoryID and the current proposal unduly restricts market participants without providing any real benefit.
Currently, there is no regulatory requirement by any German regulator that explicitly states the data format of the RegulatoryID. Also, there is no common data format of the RegulatoryID across different exchanges. As shown below, in a brief example, there are already different formats used by different exchange interfaces.
n XETRA, EBS, 32bit numeric field
n XETRA, Values, 31bit numeric field
n Equiduct, FIX, 20 characters text field
Fidessa does not see any benefit from the FIX Protocol imposing a numeric data format. Instead, we favour a format, that supports the industry's diversity and provides sufficient flexibility to address potential future extensions.
Best regards
Christian Voigt, Product Manager, Fidessa
The Gap Analysis shows ComplianceID(376) as a string field, i.e. it can be used for numeric and alphanumeric identifiers. This should be clarified in the business requirements which currently only talk about numeric identifiers. The FIX Trading Community notification sent out end of last week assumed the need to introduce a user-defined field ComplianceID for regulatory purposes in the 8000-8499 range to remove the the limitation of the data type integer. This has become obsolete, apologies for the confusion this may have caused. Only the new field ComplianceText defined in the Gap Analysis will be provided also as a user-defined field to support older FIX versions that cannot use tags from higher versions.