Securities & Futures Commission of Hong Kong

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 hksfcdatastandards_isd@sfc.hk. Suggestions and feedback may also be addressed to the working group at sfcdatastandards_wg@sfc.hk.

 

General

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:

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.

Q4:

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.

Q5:

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.

Q6:

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

A:

Under section 3(1)(a) of the Securities and Futures (Keeping of Records) Rules, all intermediaries are required to keep trading and other data 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, 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.

Q7:

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.

Q8:

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.

Q9:

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?

A:

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?

No, 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 an In-Scope Broker. 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.

Q10:

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 1 of the FAQs).

Scope

Q11:

Are swap orders in scope?

A:

The over-the-counter component of swap trades is not in scope, 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.

Q12:

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:

For ease of reference, we often refer to client orders but for all intents and purposes, the Data Standards also apply to self-initiated orders.

Q13:

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.

Q14:

Is market making in scope?

A:

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.

Q15:

Are trades in a dual-listed SEHK stock outside Hong Kong in scope?

A:

No, only SEHK-listed equities are in scope.

Q16:

Are trades under Mainland-Hong Kong Stock Connect in scope?

A:

No. Northbound trades are not in scope because the trades do not involve SEHK-listed equities. Southbound trades are also not in scope because these orders are not routed through or executed by brokers in Hong Kong.

Multiple Entity Scenarios

Q17:

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 2 of the FAQs.

Q18:

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 2 of the FAQs.

Q19:

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 1.3 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 2 of the FAQs.

Q20:

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 2 of the FAQs.

Q21:

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 2 of the FAQs.

The Data Standards Event Methodology

Q22:

Why do the Data Standards record events as single actions rather than splitting them into separate accept or reject events, which are more likely to match the messages at the system levels?

A:

The Data Standards have been designed to model business workflows rather than to replicate system messages. Recording events as single actions limits the amount of data to be produced and reduces the amount of technical overhead needed for validation.

Q23:

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. 

Q24:

How are Split events different from Order New events? Why use Split events rather than represent 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.

Q25:

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.

Q26:

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.

Q27:

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 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.

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

Q28:

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.

Q29:

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.

Others

Q30:

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.

Q31:

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 which symbology is to be used. It only requires that symbols be used consistently across all the datasets submitted to the SFC. In-Scope Brokers may perform some post-processing or conversion to achieve this.

Q32:

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.   

Q33:

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.

Data Submission

Q34:

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.

Q35:

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.

Q36:

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 Broker if any data quality issues are identified in their submissions.

4.4023 s