Data Standards for Order Life Cycles

These Frequently Asked Questions (FAQs) are intended to provide additional guidance on the expectations set forth in the Technical Specifications for the Data Standards and help In-Scope Brokers ensure compliance.

Important Notes

These FAQs should be read together with the Technical Specifications, specifically, for definitions of the terms used. They will be updated to provide additional guidance as needed.

Questions may be directed to sfcdatastandards_isd@sfc.hk

Submission of data

Q1 :

Are In-Scope Brokers required to submit trading data in compliance with the Data Standards on a real-time or regular basis?

A:

No, the Data Standards only prescribe the minimum content and presentation format of trading-related data to be submitted by In-Scope Brokers to the SFC upon request.

Q2 : Are In-Scope Brokers expected to submit data in compliance with the Data Standards to the SFC or only to the Intermediaries Supervision Department?

A:

In-Scope Brokers are expected to submit data in compliance with the Data Standards to the SFC upon its request for discharging its functions under the Securities and Futures Ordinance (SFO), whether this request is made by the Intermediaries Supervision Department or otherwise. However, data to be submitted in the Data Standards format should not be confused with information requested under section 181 of the SFO, which is required to be in a format specified in the section 181 letters.

Q3 : The SFC expects In-Scope Brokers to submit data on a timely basis upon request. What will be regarded as timely?

A:

In-Scope Brokers are generally expected to submit the data within a few working days. This should allow adequate time to present the data in the required format.

Q4 : When an In-Scope Broker is requested to submit trading data in compliance with the Data Standards, can it be requested to provide any additional information as well?

A:

Yes, the SFC may make ad hoc requests for additional information, for example, in the course of conducting an inspection under section 180 of the SFO. Additional information that may be requested includes information on client details, securities borrowing and lending records and holding of stock positions.

Q5 : When an In-Scope Broker is requested to submit data for a selected review period, say, July to September inclusive, how should it report multi-day (eg, GTC/GTD) orders that (i) were placed on 29 June but only got filled after 1 July; or (ii) were placed on 29 September but only got filled after 30 September?

A:

The In-Scope Broker should report all the events taking place throughout the entire life cycle of these multi-day orders, even if some events happen before or after the selected review period, so that the order life cycle during that period can be complete.

Q6 : How are In-Scope Brokers expected to submit their data to the SFC?

A:

Data would generally be submitted via WINGS, the SFC’s proprietary data submission portal.     

Detailed arrangements will be communicated to brokers when we make a request.

Q7 : Do submitted data files need to be encrypted?

A:

If data files are submitted via WINGS, no separate encryption is needed. For other submission methods, In-Scope Brokers would be expected to put in place adequate data protection measures including encryption to protect data files against unauthorised access throughout the submission process.

Q8 : Is the SFC going to provide any validation tools or operate a centralised validation system so that In-Scope Brokers can verify the data before submission?

A:

Typical data quality errors such as incorrect data types would be identified and rejected by WINGS. Therefore, we see no imminent need to provide validation tools or a centralised validation system. In-Scope Brokers can refer to the validation guidelines in the Technical Specifications to develop their own internal validation models. The SFC will inform the In-Scope Brokers if any data quality issues are identified in their submissions.

For additional information, the Level 1 data validation is primarily meant to check if the data files submitted by an In-Scope Broker can meet the prescribed format of the Data Standards. Any exception identified will require data rectification and resubmission by an In-Scope Broker.

The Level 2 data validation will check if the correlation of the events and the underlying data is logical and reasonable, eg, an EXEC event should only exist after an ONEW event for the same LOID. However, it is noted that exceptions identified in this validation process could be justifiable.

Scope

Q9 : What are In-Scope Products?

A:

These are generally limited to equities (ie, shares) listed on the SEHK. The only exception is shares that are traded in the grey market before their formal listing on the premise that these trades will ultimately be executed on the SEHK.

For the avoidance of doubt, the following trading related activities are out of scope:

(a)   trades of dual-listed SEHK stock outside Hong Kong;

(b)   trades under the Mainland-Hong Kong Stock Connect because Northbound trades do not involve SEHK-listed equities when the orders for Southbound trades are not routed through or executed by brokers in Hong Kong;

(c)   the over-the-counter component of swap trades (but the underlying stock hedge of the swap trade involving SEHK-listed equities is in scope, whether this occurs on SEHK or other execution venues including internal crossings, alternative liquidity providers and execution brokers); and

(d)   the conversion process of convertible bonds to shares. For the avoidance of doubt, the subsequent sell trade(s) of the converted shares is in-scope.

Furthermore, only the hedge leg of market making activities involving SEHK-listed equities is in scope, whether this occurs on SEHK or other execution venues including internal crossings, alternative liquidity providers and execution brokers.

Q10 : Do the Data Standards only capture client orders? How about orders initiated by an In-Scope Broker itself for principal trading and hedging purposes?

A:

Orders initiated by an In-Scope Broker itself for principal trading and hedging purposes are also captured. Under paragraph 35 of the Data Standards, a principal client (“PROP”) will typically be a business unit within an In-Scope Broker or a group company, such as a client facilitation or proprietary trading desk. Essentially we expect all orders from group companies to be principal in nature unless they are placed on behalf of underlying clients. Furthermore, client-initiated trades (eg, a swap to hedge a position arising from a client trade) are proprietary (ie, for the broker’s own hedging purposes). When the Data Standards do not dictate how In-Scope Brokers store data in their own formats, it should be noted that client-initiated trades (eg, a swap to hedge a position arising from a client trade) should be given lower execution priority than agency trades.

Q11 : It is common for the material terms of orders to change in varying degrees as they go through several layers and processes internally, including pass-through events, message enrichment and internal routing from one book to another. Will these need to be captured under the Data Standards?

A:

No, because the Data Standards adopt an event-based methodology which only captures all client-side (including instructions from the client) and execution-side (including all splitting and routing to an execution venue) events. It does not capture what happens in-between or so-called ‘intermediate’ order statuses.

For the avoidance of doubt,

(a)   all the executions relating to a single parent order, albeit involving multiple systems, including orders placed through HKEX provided terminal (ie, NSTD) which are not automatically linked to an In-Scope Broker’s order management system, should be recorded under the same LOID; and

(b)   When internal book fill/position transfers are out of scope, this can be subject to exception, for example, where a principal order is partly filled from the exchange and partly filled internally via book fill/position transfer. Then in the interest of simplicity and transparency, it will be acceptable for the In-Scope Broker to report the full order life cycle to the SFC.

Q12 : If In-Scope Broker A was only formed sometime during a certain calendar year due to the merger of Broker A1 and Broker A2 (neither of which fell within the definition of “In-Scope Brokers” in the preceding year), would Brokers A1 and A2 be expected to comply with the Data Standards for transactions conducted prior to the merger? Similarly, if In-Scope Broker B was split into Broker B1 and Broker B2 sometime during a certain calendar year and Brokers B1 and B2 would no longer fall within the definition of “In-Scope Brokers”, would Brokers B1 and B2 be expected to comply with the Data Standards for transactions conducted after the split?

A:

We only expect brokers that are in existence as at 31 December of a given year to compare their annual trading turnover against that year’s total market trading volume for the purpose of determining whether they are In-Scope Brokers. Although the general principle is that once a broker has fallen within the definition of “In-Scope Broker”, it will be expected to comply with the Data Standards even if its turnover has subsequently fallen below 2%, this will not apply to In-Scope Brokers which have effectively ceased to exist due to corporate restructuring.

Q13 : How are registered institutions affected by the Data Standards?

A:

Registered institutions are not expected to comply with the Data Standards. However, if they pass their orders to an In-Scope Broker:

(a)   Where the In-Scope Broker has visibility as to which order comes from which of the registered institution’s clients, then the In-Scope Broker should start the order life cycle upon receipt of the order from the registered institution and report the registered institution’s client as its client for this order; but

(b)   Where the In-Scope Broker does not have visibility as to the registered institution’s client, the In-Scope Broker should start the order life cycle upon receipt of the order from the registered institution and report the registered institution as its client for this order.

Q14 : Are In-scope Brokers only required to provide the latest data record in the reference data dictionary files for the sample period?

A:

No, the reference data dictionary files should include the required information at the start date of the sample period and all subsequent changes made on or before the end date of the period. For example, if the name of a client changed during the sample period, the reference data dictionary files should contain two records for the same client (by the same clientID) – one record showing the original name and the other showing the new name with the date of modification.

Multiple Entity Scenarios

Q15 : If an In-Scope Broker only executes client orders but books these trades out to an overseas affiliated broker, will the overseas affiliated broker be in scope?    

A:

The overseas affiliated broker will not be in scope. The Data Standards are not concerned with the subsequent booking of trades. The order life cycle from a Data Standards perspective ends at the time of final execution or cancellation with confirmed execution price and quantity (or allocation, in the case of aggregated orders).

The above and other scenarios are summarised in Appendix 1 of the FAQs.

Q16 : If In-Scope Broker C only routes orders for execution to a third party In-Scope Broker D on an omnibus basis (ie, In-Scope Broker D does not have visibility as to which order is from which client of In-Scope Broker C), how would the SFC expect the order life cycles to be reported?

A:

Both In-Scope Brokers are expected to report only the part of the order life cycles within their respective trading systems.

 For the avoidance of doubt, the client reported by In-Scope Broker C will be its client who originated the order instruction, whereas the client reported by In-Scope Broker D will be In-Scope Broker C.

The above and other scenarios are summarised in Appendix 1 of the FAQs.

Q17 : Where an In-Scope Broker receives orders from an affiliated broker (ie, the client-facing entity), how would the SFC expect the order life cycles to be reported?

A:

(a)   If the affiliated broker is a registered institution in Hong Kong, please see the answer to Question 13 above.

(b)   If the affiliated broker is a licensed corporation in Hong Kong, we will make our data requests to both companies and expect a submission from them on a group basis, tracing an order from the time it is initially received from the underlying client by the client-facing entity, using the same logical order identifier for ease of identification throughout the life cycle. For the avoidance of doubt, the two brokers can work the order in a single workflow within the same technical infrastructure or in separate workflows within different technical infrastructures.

(c)   If the affiliated broker is overseas,

(i)   Where the In-Scope Broker has visibility as to which order is from which client of that overseas affiliated broker (eg, where they share the same global client master database), the order life cycle should start when the In-Scope Broker receives the order from the overseas affiliated broker and the client reported for the order will be the client of the overseas affiliated broker.

(ii)   Where the In-Scope Broker does not have visibility as to the client of the overseas affiliated broker, the client being reported will be the overseas affiliated broker and the order life cycle will start when the order is received from the overseas affiliated broker

The above and other scenarios are summarised in Appendix 1 of the FAQs.

Q18 : Where an In-Scope Broker receives orders directly from a client of an affiliated broker, how would the SFC expect the order life cycles to be reported?

A:

The reporting in this case will be the same as where the affiliated broker’s client is the In-Scope Broker’s own client, ie, the order life cycle would start when the In-Scope Broker receives the order from the affiliated broker’s client, who will be the client reported by the In-Scope Broker.

The above and other scenarios are summarised in Appendix 1 of the FAQs.

Q19 : Where an In-Scope Broker receives orders from an affiliated asset manager licensed by the SFC, how would the SFC expect the order life cycles to be reported?

A:

Typically, asset managers only inform their brokers of the allocation at day-end. As such, we do not expect the In-Scope Broker to know which order is placed for which fund or which discretionary account upon receipt of an order. Hence, the In-Scope Broker should start the order life cycle upon receipt of the order from the asset manager and report the asset manager as the client.

The above and other scenarios are summarised in Appendix 1 of the FAQs.

The Data Standards Event Methodology

Q20 : How should post market hours trades be reported?

A:

These should be treated as T+1 trade for reporting purposes.

Q21 : Are In-Scope Brokers expected to capture client orders upon receiving or accepting a Financial Information Exchange Protocol (FIX) message?

A:

In-Scope Brokers are not expected to capture orders which have been rejected by FIX or due to formatting or technical reasons. The order life cycle should start only when a new order ticket is created in the system although the order may still be rejected later due to business logic, such as pre-trade risk checks

Q22 : Can an In-Scope Broker use its own Order ID?

A:

Yes, provided that the format of Order ID in each trading system is the same and the Order ID is unique to each order.

Q23 : Can an executed (completed) order be reported as OMOD (ie, increasing the order quantity) as and when another order is placed for the same stock under the same order ID by the client later?

A:

No, the life cycle of the original order should end upon full execution. The latter order should be considered as a different parent order. Even if the In-Scope Broker wishes to use the same order ID, the other order has to be reported under a different LOID for the purpose of complying with the Data Standards.

Q24 : A client placed an order which was executed and reported with one single LOID. A few days later, it was necessary to amend the execution to correct an error. How should this be reported?

A:

Two OSUMs should be created respectively under the same LOID for the parent order executed on the trade day and the subsequent amendment made on the execution correction day.

Q25 : Brokers may have trading scenarios that are not covered in the Technical Specifications. Can the SFC provide more guidance in this respect?

A:

We have analysed the more common trading scenarios and how they may result in different order flows and we set out how these flows may be presented in the Data Standards format. Please refer to the Illustrative Use Cases Supplement (Appendix 2 of the FAQs).

Q26 : There are many order types defined under FIX but the Data Standards only refer to MKT and LMT. It is not obvious how MarketOnClose/OnClose orders should be classified?

A:

These should be classified as MKT and supplemented by the fields of “orderInst”, “algoStrategyID” etc. In-Scope Brokers should consider supplementing order types with fields to better explain the nature of that order.

Q27 : If a system allows users to place inactive orders (eg, conditional orders) and later change them to active orders by submitting them to an execution venue, how will such events be captured using Order New and Order Modify events?

A:

Unless otherwise specifically requested by the SFC, an ‘inactive’ order would not form part of an order life cycle. It only becomes an Order New event when it becomes ‘active’. An Order Modify event is inappropriate and should be used only where there is already a corresponding Order New event.

Q28 : Is the reporting of Logical Order ID case sensitive?

A:

Yes, the reporting of all ID related fields such as logicalOrderID, clientID, userID is case sensitive. For example, logicalOrderID “1A01” and “1a01” represent two different orders.

Q29 : Are solicited orders from non-actionable IOIs in-scope?

A:

All orders received by the In-Scope Brokers are in scope, including solicited and unsolicited calls, irrespective of whether the solicited orders stem from non-actionable IOIs or otherwise. For additional information, the "solicitationType" field should be used to indicate if an order, either agency or principal, is a result of IOI generated by the In-Scope Broker.

Q30 : Who would be reported as the initiator of a modification or cancellation, the In-Scope Broker itself or the client?

A:

This depends on the circumstances. For example, the client will be the initiator where

(a)   the client places, modifies or cancels an order electronically, eg, by sending a FIX message; or

(b)   the personnel handling the order indicate via the trading system’s user interface that the order has been modified or cancelled by the client.

The In-Scope Broker will be the initiator where the broker’s system automatically cancels an outstanding order in scenarios such as market close.

Q31 : How should data be presented in the case of a Split Modify or Split Cancel request which is pending in the system and has not yet been routed to any execution venue? How should the data be presented after these requests are routed to the execution venue?

A:

It is not required to record an event in a ‘pending’ state. Only the last status of an event should be recorded with eventResponseType indicating the nature of the event, and the eventRespDateTime indicating the time of the event.   

Q32 : Is an OSUM expected at the end of each day of a multi-day order even when no event has occurred during a particular day?

A:

Yes. OSUM should always be prepared at the end of each day.

Q33 : How are Split events different from Order New events? Why are Split events used rather than representing child orders as new orders?

A:

Split events differ from Order New events as Split events denote an inherent relationship to a parent order. Split event types (Split New, Split Modify and Split Cancel) contain different fields from Order event types (Order New, Order Modify, Order Cancel). When a large parent order is split into, for example, five child orders, representation using only Order events would result in six Order New events. An additional field would need to be added to show these five orders were actually children of the first order. Therefore, it is clearer and more efficient to use Split events.

Q34 : How are mass cancellations expected to be captured?

A:

Mass cancellations, whether initiated by a broker or an exchange, should ultimately result in the cancellation of all pending orders in the trading system. Thus every affected order or split event should have a corresponding cancel event using either Order Cancel or Split Cancel events. Furthermore, In-Scope Brokers can make use of the massCancelled field within the Order Cancel and Split Cancel events in cases of mass cancellation.

Q35 : When would an event need to be timestamped?

A:

Each Order event and Split event would have two timestamps, namely

(a)   the eventDateTime for the initiation (ie, when the order ticket is first created by the system); and

(b)   the eventRespDateTime for the acknowledgement (ie, when the order is accepted by the system) or rejection of the order. 

The purpose of having these two timestamps is to better account for potential time lapses due to incidents such as system outages or the inherent order processing latency in trading systems.

However, each Execution event would only have the eventDateTime timestamp to record the order execution time.

Others

Q36 : In respect of trades executed on SEHK, how much difference between the timestamp recorded in the In-Scope Brokers’ systems and in the SEHK systems will be tolerated? 

A:

Whether the timestamp differences are acceptable will be assessed on a case-by-case basis. Generally, this is not expected to be a problem if the In-Scope Brokers can provide justifications for any differences.

Q37 : Must all orders in a dataset use the same symbology? Is it possible that different applications use different symbols throughout the order’s life cycle, and different clients may use different symbology in their orders?

A:

The Data Standards do not prescribe the symbology to be used. It only requires that symbols are used consistently across all the datasets submitted to the SFC. In-Scope Brokers may perform some post-processing or conversion to achieve this.

Q38 : Why is the securityType field a material term of an order? Shouldn’t securityID alone be enough?

A:

It is appropriate to record both fields to avoid potential confusion, for example, where the same stock codes can be reused over time.

Q39 : Trading algorithm parameters are unique to each firm. How do the Data Standards propose to standardise the recording of trading algorithm parameters?

A:

The Data Standards do not prescribe how trading algorithm parameters should be recorded. In-Scope Brokers are free to record trading algorithm parameters in their preferred way.

Q40 : How often do you expect to update the Technical Specifications?

A:

The Technical Specifications have been developed in close collaboration with industry participants and their feedback has been thoroughly incorporated. As such, we do not foresee the need for frequent updates. However, we will keep in view whether the scope should be extended to cover other products and trading activities.

Q41 : What are the implications if In-Scope Brokers are unable to comply with the Data Standards by the due implementation dates?

A:

All intermediaries are required to keep trading and other data under section 3(1)(a) of the Securities and Futures (Keeping of Records) Rules that are sufficient to explain and reflect the operation of their businesses.

For the avoidance of doubt, compliance with the Data Standards does not fall within the scope of auditor’s opinion required under section 4(1)(f)(1) of the Securities and Futures (Accounts and Audit) Rules.

Based on our extensive engagement with licensed securities brokers likely to be affected when we rolled out the Data Standards, we can reasonably expect In-Scope Brokers to be capable of implementing the necessary system changes within 15 months.

In-Scope Brokers are encouraged to inform their case officers at the SFC if they foresee any difficulties or delays in implementing the changes.

Q42 : Would the SFC consider getting The Stock Exchange of Hong Kong Limited (SEHK) to report on the execution side of the order flow so that In-Scope Brokers only need to cover the initial receipt and subsequent modifications of an order instruction?

A:

The key objective of the Data Standards is to provide full traceability of an order throughout its life cycle using a unique logical order identifier. It is necessary to see each order to its final execution (on the SEHK or otherwise) or cancellation.

Q43 : Will the trading data we submit be shared with any other regulators or law enforcement agencies?

A:

The trading data we receive will be subject to the secrecy provisions set out in section 378 of the SFO.

Last update: 6 May 2021

We use cookies to improve the website performance and user experience. If you continue to use this website, you are agreeing to their uses. Learn more about our privacy policy.