PUBLIC COMMENT PERIOD – IIROC Client Identification Proposal

One of the functions of the Investment Industry Regulatory Organization of Canada (IIROC) is to conduct real-time market surveillance to ensure that trading is carried out in accordance with securities trading rules. To facilitate this task, IIROC requires each market to provide real-time market transaction data to its market surveillance system – otherwise referred to as a “market regulation feed”. To help accommodate this requirement, IIROC has developed the FIX Market Regulation Feed – FIX Specification. The specification is being used by the markets to update and configure their respective FIX engines.

IIROC in consultation with the Canadian Markets and FPL chose FIX Version 5.0 SP2 with Extension Packs (now called FIX Latest) for the market regulation feed. Since May 2009, a number of FIX Extension Packs (EP101, EP104, EP164) were created and ratified by the FIX Global Technical Committee to accommodate IIROC’s market surveillance feed requirements.

On April 18, 2019, IIROC issued Rules Notice 19-0071 – Amendments Respecting Client Identifiers (https://www.osc.gov.on.ca/documents/en/Marketplaces/iiroc_20190418_notice-amendments-respecting-client-identifiers.pdf). This resulted in a small number of new requirements addressed by this extension proposal. The requirements addressed in this proposal relate to counterparty information (account, algorithm, order origination) as well as additional types of order originations and accounts.

Please post feedback, comments, and questions as replies to this discussion thread.

A link to the proposal can be found at: https://www.fixtrading.org/packages/fix-protocol-ga-iiroc-client-identification-proposal/

The initial public comment period ended on February 19, 2020. Due to the changes made by the FIX Global Technical Committee, a second public comment period has now started and ends on March 6, 2020.

Usage of OrderOrigination(1724) to indicate routing arrangements does not work as it is not mutually exclusive with all other values, specifically not with FDE and OEO, the two new values proposed. The existence of a routing arrangement needs to be conveyed separately.

Please could the community recommend how adding an AccountType(581) of Multiple client order (MC) differs from setting an OrderAttributeType(2594) to 0 (Aggregated Order)?
For example how should an international client send this type of order from Europe to a Canadian broker?

We have been advised that a “BrokerNumber” is required with a description of “An exchange assigned three digit public number identifying member firm”. If agreed this is a requirement please can the recommendation be added to the document. Our expectation is this would be a part rule/id source combination.

It has been recommended that 1031 may require four additional values “DEA, RA, OEO and FDE”. If agreed please could these be added to the proposal.

@robdodson, the public comments for this document will be reviewed in tomorrow’s FIX Global Technical Committee. Note that the document is not to define rules for a specific market, including the definition of fields and valid values in cases where there is more than one option in FIX. This is left to the Canadian authorities, i.e. IIROC and the market places. The Gap Analysis document seeks to close perceived gaps in the FIX Protocol and is not intended as a recommended practice document.

The distinction between 581=TBD (MC) and 2594=0 is a valid question. The aggregation of orders does not imply that they are from different clients. Tag 581 focusses on the account to which trades resulting from orders are to be booked. Tag 2594 focusses on characteristics of an order regardless of its execution.

Usage of CustOrderHandlingInst(1031) for DEA, RA, OEO and FDE was discussed when the Gap Analysis was submitted a few weeks ago. However, tag 1031 was not deemed appropriate as it is to be used for handling instructions for the execution of an order. The origination of an order or the existence of a routing arrangement or execution-only service does not influence the matching engine of the marketplace. Hence the choice was made for OrderOrigination(1724) with the new caveat that the routing arrangement is not mutually exclusive with other values.

Please note that there has been an update of the document (see link above) based on the discussion at the FIX Global Technical Committee on February 20, 2020. It is now in public review for another week until March 6, 2020.