Participant Gateway

CCASS/3 Terminal (C3T) utilizes an Edge browser to connect to CCASS/3. The PG Server, provided by HKEX, is deployed to the Participant site and is responsible for connecting to CCASS/3. However the Participants must procure the necessary hardware, software, communication interface, and security device to access CCASS/3 via PG.  Participants need to develop a Participant Supplied System (PSS) and the interface between their PG/PSS and CCASS/3 based on the Application Program Interface (API) protocol and message standard provided by HKEX.  Participants are also required to perform interface test with HKEX to certify their PG access.

For connectivity of PG to CCASS/3, for development environment, PG Participant is required to subscribe a development SDNet link for testing purpose in initial commissioning and for subsequent maintenance; for production environment, Participants can either choose to share C3T link or subscribe a separate link for PG, depending on the projected transaction volume.

Participants who want to install PG would need to bear the one-time set up cost and recurrent cost.  One-time set up costs include the purchase of hardware and software, commissioning, smartcard, and PSS development.  Recurrent costs include PG maintenance fee, monthly  fee of SDNet development link, and the potential maintenance costs relating to the upgrade of PSS and testing on the PG interface due to modifications in business operations or CCASS/3 functions.

The current fee schedule for PG is set out in CCASS Participant Gateway – Fee which is available in Client Connect (https://connect.hkex.com.hk/)

a)   How is the access to PG controlled?

PSS must be successfully authenticated by PG Server in order to gain the access. Authentication against User ID, password (MD5 hashed) and IP address is done during PSS logon to PG. The PG connects to CCASS/3 using a smartcard and password. Participant must type in the password and perform a logon on before the PSS can login to the PG Server.

b)   What is the message protocol to be used to connect with PG? How security issues or concerns may be dealt with?

The PG communicates with CCASS/3 via HTTP protocol over SSL and the PSS communicates to the PG Server using socket over TCP/IP (using the PG-API provided by HKEX). Participants can choose either secured connection (SSL) or normal connection for the connections between PG and PSS.

The PG connects to CCASS/3 using a smartcard and password. Participant must type in the password and perform a logon before the PSS can login to the PG Server.  The PG follows the same security level as C3T.

c)   Do we need to have SSL certificate key exchange? Could HKEX clarify on SSL portion?

A smartcard issued by HKEX is required to operate PG. Upon user successfully logon PG with the smartcard, SSL session will be established between PG and CCASS/3. This part is done by PG.

d)   How is communication between Participants and HKEX conducted via PG?

It is conducted on a request-response basis, i.e. PSS needs to submit a request (input message), and then CCASS/3 response to the request (output message) accordingly. It follows that if a Participant wants to change or cancel an instruction already accepted by CCASS/3, it needs to first send an input message for enquiry of the time stamp of the instruction by specifying the instruction number. CCASS/3 will respond by locating the instruction based on the instruction number specified and return the details of the instruction, including the time stamp via output message. Participant need to send another input message again to make changes/cancel the instruction.

Yes, this may be required but not a usual practice. Normally it would be HKEX to login remotely for the following purposes:

-     obtain system logs for problem diagnosis

-     PG software or third party software upgrade

-     virus definition update

For the initial deployment, they are bundled with the delivery of the PG Server to the Participant. For subsequent software maintenance, they may be done remotely by HKEX/third party vendor, or done at Participant’s site, depending on the complexity of the maintenance.

For the frequency of the maintenance, it will depend on the software life cycle of the third party software.

For virus definition update, it will be performed remotely by HKEX monthly, without Participant intervention. 

For PG software release, it depends on whether there is any urgent enhancement on PG Server and whether the business enhancement in CCASS/3 will impact PG. The later one will be at most 2 to 3 times a year.

Participants can choose a single PG or dual PG configuration. The network bandwidth requirement depends on the data volume of the online messages, file upload and report data file download. Participants can calculate their required bandwidth according to their message volume and the message lengths as specified in the PSS Messaging Specifications.

The minimum bandwidth for a single PG or dual PG configuration is 128K or 256K respectively.

There are two possibilities:

i.    PG Server is closed. Your PSS application should not be able to logon PG in this case.

ii.   Problems encountered on the network connection between PG and CCASS/3.

For technical enquiries, please contact CCASS Technical Hotline at 2211- 6606. For general enquiries, please contact CCASS Hotline at 2979-7111.

No, multiple PG instances cannot be run on the same PG machine. For SDNet line it can be shared by multiple PGs if the bandwidth subscribed can support the estimated transaction volume. Participants may also consider subscribing two PGs for resilience purpose and at the same time configure them to be active-active to increase the overall throughput.

a)   Must PG (PC/Server) be in the same LAN as the PSS Server? Any specific socket must be granted access?

      PG Server supports TCP/IP which can be located in different LAN segment as the PSS Server. Make sure the normal and secure port is available if there is any firewall in between.

      HKEX has assigned the following port numbers between PSS and PG:

•     Secure connection: 4433 for synchronous and 4434 for asynchronous transactions.

•     Normal connection: 8080 for synchronous and 8081 for asynchronous transactions.

b)   Can we assume that any communication between PSS and PG are securely handled by PG-API call? Does this include the encryption of password into MD5 Hashed (encryption algorithm)?

      Secured connection (SSL) can be setup between PSS and PG, with which communication between PSS and PG is secured. Password will be encrypted using MD5.

For PG logon to CCASS/3, the initiation is from PG Server to CCASS/3. For broadcast message polling, PSS should be the initiating party to subscribe to asynchronous and broadcast messages. Then PG Server will poll CCASS/3 for asynchronous and broadcast message, when there are messages, PG will callback PSS.

For subsequent transactions, the initiation should be PSS. PSS sends request messages to PG via PG-API, and then PG-CCASS/3 will reply message to PSS when the PG-API returns.

Yes. HKEX will provide necessary technical information for the Participants (or software house) to design and develop PSS based on their requirements.

Yes. Certification to PSS is required at Participant level. HKEX will also certify PSS in the perspective of CCASS/3 communication.

There are several testing requirements before the Participants admit for PG:

•  Readiness of PSS:        It is assumed that Participants already completed the relevant unit tests on the PSS.

•  PG Simulator Test:       HKEX will provide a PG simulator (a program) for Participants to test their PSS.

•  PG End to End Test:    The test will be conducted with PG connection to CCASS/3 testing environment. Participants will need to prepare a Windows-based PC as the PG Server (with software provided by HKEX), and a testing C3T for the result verification.

•  PG Connectivity Test:  The test is to ensure the production connectivity between PG and CCASS/3 upon PG deployment at the Participant site.

 The testing arrangements and schedule needs to be confirmed between HKEX and the Participant.