Frequently Asked Questions 
The FAQ will be updated periodically and is subject to change.
Part 1 : OCG in General
Part 2 : Fees and Charges
Part 3 : Backup Arrangements
Part 4 : Technical Details
Part 5 : On-boarding Arrangements
Part 6 : Network Arrangements


Part 1. OCG in General
1.1 What is OCG?
OCG stands for Orion Central Gateway, which is a new market access platform to support secured connections between the Broker Supplied Systems (BSS) of Exchange Participants (EPs) and HKEX's securities market trading system (currently AMS/3.8 and Orion Trading System in the future) .
1.2 What are the benefits of using OCG?
Among the many benefits that OCG brings to all stakeholders, HKEX believes the following are the most significant:
1. Elimination of OG hardware devices
2. Consolidation of SDNet/2 circuits
3. Decoupling of trading and market data
4. High capacity sessions with up to 250 throttles per OCG session
5. Low latency and high resilience
6. Drop Copy service
7. Cancel on Disconnect service
For more details, please click here for the OCG Information Paper.
1.3 What is an OCG session?
An OCG session means a connection to the OCG for communication between a BSS and the OCG.
1.4 Is it mandatory to use OCG? Can EPs continue to use OG after the rollout of OCG?

OG will not be supported and will be retired two years after the launch of OCG, i.e. June 2016.  In order to save EPs’ system development and testing effort, OG will not be upgraded for any AMS changes which are planned to take effect after June 2016 (including the announced Volatility Control Mechanism (VCM) and Closing Auction Session (CAS)).  For EPs still using OG, they are reminded to migrate to OCG as soon as practicable.  EPs not planning to migrate to OCG will be notified individually to de-install their OGs in due course.  New EPs are required to subscribe to OCG.

1.5 Does OCG impact existing users of AMS terminals, Multi-Workstation Systems (MWS), and Order Routing System (ORS)?
The migration of MWS to NSTD was completed in Q1 2015 and the migration of AMS terminals to NSTD will be completed by Q3 2015.  There will not be a replacement for ORS from HKEX. Related EPs are advised to consult their Proprietary Network System (PNS) vendors to migrate to other BSS/OCG solutions.  For details of NSTD, please refer to NSTD project corner at
1.6 Given OCG does not support AMS terminals, Multi-Workstation Systems (MWS), and Order Routing System (ORS), what is the migration plan for these devices?
Please refer to Question 1.5.
1.7 Will market data (including reference data such as bid/ask quotations, broker queues, and closing price) and market status be disseminated through OCG?
No. To allow better utilization of network bandwidth and remove duplication of market data for EPs with multiple OGs, OCG does not disseminate any market data or market status. Securities market data and market status will be disseminated through HKEX Orion Market Data Platform - Securities Market (OMD-C).
1.8 Do EPs have to subscribe market data and market status directly from OMD-C or can EPs subscribe from Information Vendors?
EPs can subscribe market data and market status from OMD-C or Information Vendors.
1.9 Can an EP enroll both OMD-C and OCG in one application and conduct certification test in one go?
For the convenience of EPs, the enrollment for OCG and OMD-C will be done at the same time. However, the certification tests for OCG and OMD-C will be conducted separately.
1.10 What is Cancel on Disconnect (COD)?
COD is an optional OCG feature and can be applied by EPs to individual OCG sessions. If enabled, the OCG will automatically cancel outstanding orders originated from the applied session upon specific session disconnection scenarios (such as network disconnection). The cancellations are made on a best effort basis.
1.11 What is Drop Copy Service?
The Drop Copy service is a real-time read-only data service designed to facilitate monitoring of trade and order activities. An EP can choose to receive trades only or trades and orders details in one or more drop copy sessions. Data provided in trades-only drop copy service is similar to the existing Central Trade Feed (CTF).
1.12 Does the Drop Copy service only include orders and trades done through OCG?
No. The Drop Copy service includes trades only or trades and orders done through all input devices of an EP, as long as all of its broker numbers are assigned to the drop copy session.
1.13 Being a General Clearing Participant (GCP) to provide third party clearing services to other EPs, can we receive all our clients’ trade details through a single drop copy session?
No. An OCG drop copy session can only receive real-time data of one single EP. Application to drop copy sessions should be made by respective EPs.
1.14 Will HKEX notify BSS vendors about details of OCG?
Yes. HKEX held a series of OCG and OMD-C technical seminars in December 2012 for IT staffs of EPs and BSS vendors.
1.15 Currently, an EP can relinquish its dealing desk or in respect of each Stock Exchange Trading Right held apply  for either 1) an additional AMS terminal or 2) an increase in the throughput rate of 0.25 throttles into its assigned Open Gateway. Can an EP choose to assign the increase in the throughput rate to an OCG session?
Yes. Upon the rollout of OCG, in addition to the 2 options mentioned above, EP can also choose to relinquish its dealing desk or in respect of each Stock Exchange Trading Right held apply for an increase in the throughput rate of 1 throttle into a designated OCG session.
Part 2 : Fees and Charges
2.1 What are the fees and charges for OCG sessions?

Each OCG session has a one-time administration charge of $20,000. This charge will be waived for each OCG session if there is a corresponding reduction of one or more trading device(s) used for the same purpose (i.e. normal trading / market making / backup) at the same time.
In addition, a monthly session fee for trading, market making or backup is charged per below:

2.2 Will there be changes to throttle fees?

There is no change to one-time or monthly throttle fee for Trading and Market Making.  Backup Throttle fee will not apply to OCG Backup Session but will still apply to Backup OG.

Throttle Fees Schedule

I. Each standard Central Gateway throttle rate acquired from the Exchange will be charged at HK$50,000.

II. In addition, a monthly fee for an increase of throughput rate of an OCG Session will be charged as below:

2.3 Will EPs need to pay more in using OCG than using OG?

No. EPs using OCG are expected to have savings due to consolidation of SDNet/2 circuits, elimination of OG hardware and backup throttle charges, and savings in hosting and human costs associated with OG and its maintenance.

Example 1: EP has 1 OG, migrates to 1 low capacity OCG Session


Example 2: EP has 2 OGs, migrates to 2 low capacity OCG Sessions

2.4 Since OCG does not provide market data, will there be any waiver on licence and connection fees for OMD-C connection?
EPs who connect to OMD-C directly to get market data for internal use will need to enter into the Market Data End-User Licence Agreement with HKEX Information Services Limited (HKEX-IS). Under the Market Data End-User Licence Agreement, 2 OMD-C Securities Standard (SS) connections with fee waiver on End-User Licence Fees and Connection Fees will be offered to each EP using OCG. 
2.5 Will there be any monthly Information Service fees exemption for the BSS terminals/workstations connected to OCG?
Similar to OG, BSS terminals/workstations connected to OCG and sourced market data from OMD-C Securities Standard (SS) are subject to the monthly Individual User Fees (which is stipulated pursuant to the Market Data End-User Licence Agreement and is equivalent to the monthly Information Service fee currently applied to BSS terminals/workstations connecting to OGs). The number of BSS terminals/workstations entitled for the exemption of the monthly Individual User Fees shall continue to be two BSS terminals/workstations for each Stock Exchange Trading Right held by the Exchange Participant with OCG irrespective of their market data sourced from OG or OMD-C SS.  In addition, with effect from 1 January 2014, each Exchange Participant would be entitled to additional ten free market data display terminals which are applicable to BSS terminals/workstations, MWS workstations or terminals subscribed directly from HKEX or from other HKEX licensed information vendors. 
Part 3 : Backup Arrangements
3.1 What is a backup OCG session?
The purpose of a backup OCG session is to allow an EP to connect from one of its backup BSS to AMS in the event that its production BSS encounters a problem. OCG will run in High-Availability (HA) mode regardless of whether an EP subscribes to backup OCG session(s) or not.
3.2 Can an EP use OG and OCG in parallel for market access purpose?
OCG has been implemented in June 2014, and it can run in parallel with HKEX’s existing market access infrastructure, including OG, until further notice.
Part 4 : Technical Details
4.1 What is the difference between the FIX and Binary protocol? What is HKEX's recommendation on choosing the protocol?
OCG supports both FIX and Binary protocols. From a trading perspective, they are equivalent in functionalities. Binary protocol is designed for customers seeking maximum machine efficiency, while FIX protocol caters for those adopting the industry standard messaging format.  EPs can choose the preferred message protocol based on their business needs.
4.2 What is the new bandwidth requirement for OCG and OMD-C?

The bandwidth requirement for OCG sessions is listed as below:


• Drop Copy session can include orders and trades from the OCG sessions and non-OCG devices (i.e. Terminals, OG/MWS or OG/BSS devices)
• Number of throttle for each 1st terminal and 2nd terminal is counted as 1

For the sharing of 10Mbps circuit of OCG and OMD-C Securities Standard session, the bandwidth requirement allocation is listed as below:


4.3 Can OCG and OMD-C share the same SDNet/2 or HKEX Service Network (HSN) circuits?
Yes. OCG and OMD-C can share the same SDNet/2 or HSN circuits.  EP has to ensure sufficient bandwidth is subscribed to meet its business needs.
4.4 If an EP establishes multiple OCG sessions from one BSS server location, is it possible to use one pair of SDNet/2 circuits for that particular location? What is the arrangement if the EP uses HSN?
Yes. An EP can use one pair of SDNet/2 circuits for each location to connect its BSS(s) to OCG.
If the EP uses HSN, the BSS servers would be located in HKEX Data Center and only one pair of HSN circuits is needed to connect to OCG.
4.5 If an EP establishes multiple OCG sessions from multiple BSS server locations, is it possible to use one pair of SDNet/2?
In general, one pair of SDNet/2 circuits is needed for each location to connect its BSS(s) to OCG.
4.6 Does OCG support cross trading device order cancellation?
Yes. For example, an EP can perform cross trading device order cancellation through an operating OCG session on orders which were input from the faulty trading devices such as a terminal, MWS, OG/BSS or OCG/BSS, or vice versa.
4.7 Can an EP connect multiple production BSS to 1 OCG session?
No. Only one BSS can connect to one OCG session at a time.
4.8 How many broker numbers can be assigned to 1 OCG session?
An EP is allowed to have up to 80 broker numbers assigned to all of its AMS/3 and CSC trading devices. As such, the maximum number of broker numbers that can be assigned to one OCG session is 80.
4.9 How does the throttling mechanism work in OCG?

Throttle window is a one-second period that begins at the boundary of an actual clock second.  One Standard Throttle provides the throughput of 2 Messages per second (MPS). All in-bound messages such as order submission, quote, trade report, etc. are collectively referred to as messages. Messages exceeding the entitled limit will be rejected by OCG.
Note: OCG will synchronize its system clock with GPS. 

For example:
• Throttle is 4 (i.e. 8 messages per second)
• BSS sends 12 messages within 1 second (10:23:36 - 10:23:37)
• The first 8 messages will be accepted while the last 4 messages will be rejected immediately

BSS should therefore implement a flow control logic to send their messages according to their entitled throttles to minimize the occurrence of rejections.  However, BSS Users are reminded that rejection of message is still possible due to a misalignment of throttle time windows between their BSS and OCG. Therefore, BSS is also necessary to implement a message re-submission mechanism in case of rejection due to throttle violation or other events such as network delay or other unexpected events.     

BSS Users are also requested to note that if there is a severe violation of the entitled throttle limit, the corresponding OCG session will be dropped. Therefore, it is recommended that BSS should minimize the occurrence of message rejections by adopting below approaches:

1) Implementing a proper flow control and re-submission mechanism. To minimize the occurrence of rejections due to exceeding the throttle limit, BSS should only send the number of messages less than or equal to the entitled throttle limit. In the example above, the BSS should control that no more than 8 messages could be sent to OCG in a single throttle window. Any additional messages should be queued in the BSS and be sent in the next throttle window.
2) Synchronizing BSS system clock with GPS. If there is a misalignment of system clock between BSS and OCG, messages considered to be sent in two different throttle windows could be counted as being in the same throttle window in OCG. For example, the entitled throttle limit is 4, and the BSS sends 8 messages in the first window and 1 message in the next window. However, if all 9 messages arrive at OCG in the same throttle window based on OCG system clock, the last message will be rejected. Therefore, it is recommended BSS synchronizes its system clock with GPS to reduce the chance of rejection due to throttle window misalignment, and please note that some exceptional cases such as network delay variance may also cause message arrived at misaligned throttle time window and result in rejection.
4.10 How to interpret the Bitmap Fixed Length and Bitmap Variable Length for Binary protocol?

The Bitmap Fixed Length and Bitmap Variable Length are used to provide a presence map to indicate the availability of fields within the message. Each bit in the presence map will represent a field and the sequence in which the fields should be included into the message will be based on the bit position.

Take Bitmap Fixed Length field (which has 32 bytes) as an example:

The presence map will store starting from byte 0, and then byte 1, byte 2, ..., byte 31, where byte 0 is the first byte of the memory block of the Bitmap Fixed Length field.

Suppose the following fields are present for a message:

Then, Bitmap Fixed Length field is presented as:

In Language C/C++, if it wants to check if Order ID is present, the corresponding sample source code could be:

4.11 Are some samples available for data type Alphanumeric Variable Length, especially for showing how to store the empty/blank value?

Example 1:

If the Alphanumeric Variable Length field has value of “Y”, the memory block will be stored as:

Note 1:

In this example, the length of value is 2 instead of 1. It is because the length will take into account the null terminator.

Example 2:

If the Alphanumeric Variable Length field is empty/blank, the memory block will be stored as:

4.12 How to respond to a Test Request message from OCG?
The Test Request message will be sent by OCG when it detects inactivity for a period longer than 3 heartbeat intervals. OCG expects there will be a proper Heartbeat message returned from the client with the Test Request ID. Otherwise, the session will be disconnected. If Cancel-On-Disconnect (COD) is subscribed, it will be triggered. Please note that any other message will not be considered as a proper response to a Test Request message.
4.13 There is no Trade Match ID in the Execution Report for the auto-matched trade cancellation, how to identify the original trade to be cancelled?
Each Execution Report has a unique Execution ID as reference. The Execution Report for auto-matched trade cancelled by Exchange provides the Execution ID of the original trade – (ExecRefID(19) for FIX protocol or Reference Execution ID for Binary Protocol) to identify the original trade.
4.14 How to specify the Security ID in the business message?
For HK Security ID less than 5 digits, it should be provided as string without leading zero (e.g., HKEX stock code should be specified as 388, rather than 00388).
4.15 How to specify the Market Segment in the business message?
Market Segment ID should be specified in the business message without trailing spaces. For example of Mass Cancel, if orders are to be cancelled for GEM (or ETS) market, the Market Segment ID should be “GEM” rather than “GEM<space>”.
Part 5 : On-boarding Arrangements
5.1 What is the timeline of on-boarding activities of the initial rollout of OCG?
The initial rollout of OCG has completed in June 2014.
5.2 What is the on-boarding arrangement after the initial rollout?
EP can choose to migrate to OCG by joining the scheduled batch rollout.  EP should discuss with its BSS vendors and decide the best timing to migrate to OCG based on the arrangement suitable to individual EP.  EP should complete the applicable Conformance Tests (e.g. simulator test, end to end test, rollout test) to ensure the system readiness before rollout of each BSS that connects to OCG.
5.3 Can BSS vendors perform Conformance Tests on behalf of their clients?
Conformance Tests can be done by vendors on the same version of the BSS solution on behalf of all its clients. Conformance declarations must be done by individual EP.
5.4 Will there be a MMOCG for the market makers or liquidity providers similar to the current MMOG?
One OCG session can serve as either normal trading or marketing making ("MM") purpose. OCG supports MM sessions with the arrangement similar to MMOGs. 
5.5 Is there any restriction on migrating throttles from OG to OCG in phase approach?
EPs can migrate throttles from OG to OCG according to their business need during the transitional period and reallocate their throttles among different OCG sessions which serve for normal trading purposes. Similar to current arrangement for OG, EPs have to inform HKEX at least 3 trading days before the effective date of the migration / reallocation.
Part 6 : Network Arrangements
6.1 How can EPs connect their BSS servers to the SDNet/2 routers?
An EP should provide two network switch ports with auto negotiation setting and two UTP cables to connect the SDNet/2 routers and the network switches. The network switches must provide a single VLAN (Layer 2) for the two SDNet/2 routers in order to support HSRP/VRRP communications between the routers themselves. The BSS servers should be connected to the network switches on the same VLAN.
6.2 How can an EP connect the network switches and SDNet/2 routers to support both OCG and OMD-C sessions on the same SDNet/2 circuits?

An EP should provide four network switch ports with auto negotiation setting and four UTP cables to connect the SDNet/2 routers and the network switches. The network switches must provide two separated VLANs for connecting different router interfaces; one VLAN for OCG and the other for OMD-C. EPs have to ensure the circuit bandwidth is sufficient to meet their business needs.

6.3 Can EPs share both OCG and OMD-C on the same pair of HSN circuits?
Yes. OCG and OMD-C can be run on the same pair of HSN circuits. The two applications will be assigned to different VLAN segments.
6.4 After completion of the end-to-end test, can EP migrate the SDNet/2 cirucits from Development to Production platforms without changing the IP addresses?
Yes. EP subnets and gateway IP addresses of the SDNet/2 circuits can be retained.