Frequently Asked Questions 
08/03/2017 
 
 

I. Setting up a PG

 1.      Are there any pre-requisites of using Participant Gateway (PG)?

          CCASS/3 Terminal (C3T) utilizes an Internet Explorer (IE) 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.

 

2.      Does a move to PG require the replacement of C3T? Is it recommended to use a combination of the two services and if so, why?

          Since only settlement related functions can be accessed through PG mode, Participants need to use C3T to support their daily functions such as nominee services etc. Therefore, PG users still need to install C3T.

 

3.      What is the minimum requirement for any PC being used to support the PG connection? How does this compare with the requirement for C3T?

          The Production PG Server is supplied by HKEX while Participants need to prepare their own PC for PG development and end-to-end test. The reference PC requirement for the PG is available via HKEX website, Section 7 of Introduction to PG (http://www.hkex.com.hk/eng/market/clr/secclr/ccass3/pg_doc/documents/pg_package_section_1.pdf). However, the requirement of the PSS is subject to the Participants’ application.

 

4.      What are the costs for the adoption of PG?

         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 Section 5 and 6 of Introduction of PG. (http://www.hkex.com.hk/eng/market/clr/secclr/ccass3/pg_doc/documents/pg_package_section_1.pdf)

 

5.      Can PG be installed on non-Windows platform?

          No. PG can only be run on Windows platform as supplied by HKEX.

 

6.      Since the hardware and software is maintained by HKEX, what administration rights on PG Server do Participants have?

          Participants do not have administration rights on PG Server. However, HKEX will obtain Participant’s consensus before making any change on the PG Server.

 

7.      Do we need separate installation of PG to support each CCASS Participant ID?

          Technically, it is possible to use one PG to support more than one Participant.  However, in practice, it will require manual operation to log on/off from/to various Participant IDs. This may not be an ideal operational model especially when Participants need to handle critical matters. Alternatively, you can install separate PG to support each of the Participants.

 

8.      What is the benefit of installing more than one PG?    

         Participants may need to install 2 PGs for resilience purpose. Both PGs can operate simultaneously.

 

9.      Can 2 PSS connect to 1 PG?

          No. A PG can only be connected to one PSS.

 


II. Technical Infrastructure & Performance

 10.    PG communicates with CCASS/3 via Hypertext Transfer Protocol (HTTP) protocol over Secure Sockets Layer (SSL)

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.

 

11.    Is there any third party software/application running on the PG Server supplied by HKEX/CCASS?

          Yes, apart from the Windows Operating System, IBM Director and Symantec Endpoint Protection are the third party software running on the PG Server. HKEX is the owner of Symantec Endpoint Protection and IBM Director client software.

 

12.    Is this third party software maintained by HKEX/CCASS or another HK local third party vendor?

          As stipulated in the Standard Terms and Conditions of PG, HKEX will provide or procure to provide maintenance services for the PG for these third party software. The maintenance services in respect of the PG (other than the PG Software) shall be provided so long as maintenance services in respect of the PG (other than the PG Software) are provided to HKEX by the relevant manufacturer/supplier(s).

 

13.    Can the third party vendor login the PG remotely?

          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

 

14.    Refers to the third party software, what is the deployment method of this software on PG Server? How many software releases are there expected in a year?

          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.

 

15.    How would a Participants capacity requirements affect the technical set up of PG (in terms of number of PG and line bandwidth)?

          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.

 

16.    Is there any platform restriction for PSS or any recommendation for PSS platform?

          As long as there is a Java Runtime Environment (JRE) in the PSS platform, PG-API libraries supplied by HKEX will be able to run. Participants should use their targeted PSS platform and JRE version in the PG end-to-end test to ensure its compatibility.

 

17.    Will the PG-API support multiple opened connections to the same PG (i.e. supports multi-threading)?

          Yes. PG is designed to accept multiple transactions from PSS. It is the Participant’s decision in application design whether or not to implement multithreading in PSS application. HKEX would provide sample codes for implementing multithreading in PSS application. A PSS thread is blocked until a response is returned from CCASS/3 (via PG).

 

18.    Will the message be lost when it is successfully sent out from PG to CCASS/3?

          PG should be able to route your message to CCASS/3 unless there is network problem between PG and CCASS/3. In case PSS is not sure whether the message is processed by CCASS/3 (e.g. PSS received a time-out instead of a successful return code), PSS should perform enquiry function to check if the submitted message was executed.

 

19.    What would be the possible reasons if we fail to send out messages to CCASS/3 via PG?

          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.

 

20.    How can we increase the transaction throughput of PG?

          The maximum PSS connection to each PG is 6, each each connection on average supports 12 pairs of input and output messages per minute (excluding file upload and report download). PSS can make the maximum number of connections supported by PG in order to obtain the highest throughput. Installing one more PG is one way of increasing the overall throughput. Alternatively, using file transfer to upload a batch of instructions will increase the overall throughput.

 

21.    If dual PGs configurations are used, which components (PG or PSS) are required to perform load balancing of transactions sent to CCASS/3?

          PSS should perform the load balancing in case of dual PGs configurations. (Load balancing is not necessary for single PG configuration.)

 

22.    Can we run multiple PG instance on the same PG machine & SDNet line?

          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.

 

23.    What is the maximum throughput of a file based input (both via PG and direct to CCASS/3)?

          Currently for SI, ATI, STI and ISI file transfer, each file allows 7002 records at maximum, including 1 header and 1 trailer record. As for the lead time on transmitting and processing the file in PG, please refer to Section 8.7 of “CCASS/3 Messaging Specifications for Participant Supplied System (PSS) Part 1” (http://www.hkex.com.hk/eng/market/clr/secclr/ccass3/pg_doc/Documents/CCASS3MsgSpecPart1.PDF) for illustration.

 

24.    PSS communicates to the PG Server using socket over TCP/IP (using the PG-API provided by HKEX)

             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.

 

25.    Which system initiates the communication? Is the message sent by HKEX/CCASS (push) or PG Server (pull) the data from HKEX/CCASS?

          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.

 

26.    Would the PG-API messaging be transactional? (Say supporting JMS)

          JMS will not be used. All transactions via PG are supported by PG-API.

 


III. Security

 

27.    What is the security setup recommended for PG installation (e.g. firewall)?

          Connection between PG and CCASS/3 is within a closed network (via SDNet). Appropriate security measures will be in-place (e.g., disallowing Participant A accessing Participant B connection point). As for connection between PG and PSS, Participants can choose to implement secured (e.g., SSL) or normal connections provided by PG-API.

          Should extra security measure be required, Participants can consider installing a firewall between PG and PSS.

 

28.    Are the user IDs and user authentication residing on the PG Server?

          For PG logon to CCASS/3, the authentication is performed in CCASS/3. For PSS logon PG, the user ID and authentication is performed in PG with encryption.

 

29.    How does the authentication work with the smartcard and smartcard reader?

          A smartcard reader should be installed to each PG Server.  PG should logon to CCASS/3 before performing any transaction.  To logon, Participant should insert the smartcard into the smartcard reader and input his user password.  If the password is correct, CCASS/3 will retrieve and authenticate the certificate stored in the smartcard. Upon successful authentication, PG is logged onto CCASS/3 successfully. In case of fail logon after 3 attempts, the smartcard password will be revoked, then the Delegate Administrator (DA) of the Participant should reset the password via C3T.

 

30.    How often will the smartcard authentication process take place in a PG operation?

          The authentication via smartcard is required when Participants perform logon to CCASS/3 by entering the password.  Moreover, the smartcard authentication (or re-entering of password) is required to enable the Administrator Main Window after it is "locked" due to the smartcard was removed from the reader.

 

 

31.    Apart from logging on to CCASS/3, is there any other role of the smartcard?  Will there be one smartcard for one site, or one per user?

          The PG smartcard can be used to logon CCASS/3 as well as to perform the PG Administration functions. A PG smartcard can be used on any PG of the same Participants. Participants should apply PG smartcards according to their operation need.

 

32.    Are there any audit logs or reports on the PG Server?

          Audit logs are available on PG Server.

 

33.    Do the audit logs on PG Server contain any customer name or customer telephone number or details?

          The audit logs records PG events such as PG startup, password validation status, login session status and PG messages for problem diagnosis or audit trail purposes. Access to audit logs is restricted and HKEX will not access them without Participants’ consent. There is no such field as customer name or telephone number in the PG message. However, Participants should pay attention that if they input such information in “Remark” fields, they will be logged.

 


IV. Subscription to Participant Gateway (PG)

 

34.    Should Participants work with their application developer (or software house) to design and develop PSS based on their requirements?

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

 

35.    Is there any certification to use PSS? Is it being certified at Participant level or at software vendor level?

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

 

36.    How would testing be organized for a potential PG user? Is advance notice required to access the testing environment? What sort of testing environment needs to be configured?

          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.

 

37.    What is the timeline for PG migration to PG?

          It normally takes around 4 months for acquiring PG service. This excludes the PSS development timeline.

 

38.    Does CCASS/3 have an authorized vendor(s) to assist in the infrastructure cable layout (SDNet) and able to provide consultancy services to Participant’s infrastructure team?

          Yes, PCCW is the sole provider.


V. Operations

 

39.    Are all C3T functions being supported by PG?

          No, PG only supports a subset of functions offered in C3T.  For list of functions supported by PG, please refer to Section 8.2 - Summary of PSS Business Transactions to Message Mapping of “CCASS/3 Messaging Specifications for Participant Supplied System (PSS) Part 1” (http://www.hkex.com.hk/eng/market/clr/secclr/ccass3/pg_doc/Documents/CCASS3MsgSpecPart1.PDF)

 

40.    What is PG operating hour?  Is it different to those for C3T?

          CCASS/3 functions available via PG will follow C3T function time schedule as specified in Section 7.2 of CCASS Terminal User Guide for Participants: http://www.hkex.com.hk/eng/market/clr/secclr/ccass3/parttug/documents/sect7_2.pdf.

          PG Server serves as the message routing conduit between your PSS and CCASS/3 backend. Production PG Server would be located at Participants’ office premises and your operation team should make sure that the PG Server is signed on / off from CCASS/3 when necessary. In general, we suggest PG Server to perform smart card sign on/off on a weekly basis, while PSS should perform daily logon to CCASS through PG-API before submitting transactions.

 

41.    Is it required to physically login and logout to PG machine on local console?

          Physical logon/logoff has to be done on PG console. Alternatively, PG Participants may use remote Keyboard, Video & Mouse (KVM) technology to help manage PG remotely, at the cost of Participants. Physical logon/logoff can be done on weekly basis.

 

42.    How do Participants remotely monitor the connection status between PG and CCASS/3 (e.g. any heartbeat check)?

          Connection status between PG and CCASS/3 will be reflected on the Administrator Main Windows.

 

43.    What is the business continuity plan in case of unavailability of PG?

          Participants shall have their own business continuity plans in place. For reference, PG users may use C3T as contingency measures. CCASS Participants may use the HKSCC’s back-up centre facilities to perform the CCASS/3 functions in the event that their C3T breaks down.

 

44.    Is there any support to Participants for PSS disaster arrangement?

         No. PSS is Participants own back office system. Participant needs to arrange the backup on PSS. However, as for PG, Participants can install standby PG at their back up site. Besides, Participants may use C3T for business continuity in case of PSS failure.

 


VI. Business Functions & Messages

 

45.    Where can we get the information about message specifications and templates (including upload file and report data download file formats) from CCASS/3?

          The format of the upload files and report data download files is not identical to those to be uploaded / downloaded via C3T.  Please refer to message specifications and templates under the section “CCASS/3 Participant Gateway (PG)” on the HKEX website:         http://www.hkex.com.hk/eng/market/clr/secclr/ccass3/pg_doc/pgindex.htm.

 

46.    Do the Output Messages from the CCASS/3 to PG use standard ISO messages as well?

          Yes. Apart from the ISO 15022 messages, there are CCASS/3 user-defined messages that are designed with reference to ISO message format.

 

47.    Will Participants receive real-time acknowledgement after sending a transaction to CCASS/3 through PG?

          Yes.  Participants will receive an acknowledgement indicating whether their transaction request was successfully received.

 

48.    Can we query CNS settlement status via PG and if so, how?

          Yes, CNS settlement status can be queried through ‘Enquire Settlement Activity’ (MC555) via PG.

 

49.    For SI transactions, why confirmation messages (e.g., MT544, MT546) are not used?

          In CCASS/3, confirmation messages are supported via enquiry modes instead of a direct confirmation approach as MT544, MT546. Hence, MT544 and MT546 are not used and Participants need to send an enquiry message (MT556 or MT557) to get the SI status.

 

50.    If we manually upload a SI file via C3T, can we use MC556 or MC557 to enquire?

          Yes, you can use MC556 or MC557 to enquire if the file upload is successful and it does not get rejected at CCASS/3 host (after validation run).

 

51.    If one of the records in the SI upload file (via C3T) is rejected by CCASS/3, will we be able to get this (reject/success) information in the PG reply message?

          No, PG users cannot receive the rejection through the reply message. Instead, PG users should check the SI Batch Input Control Report for the status of individual record in the SI file. This report can be downloaded via Report Download function in C3T or PG (MC901, MC902).

 

52.    After a SI/ISI upload file is being uploaded via PG, how would the file be processed in CCASS/3?

          In fact, CCASS/3 handles various upload files in different ways. In the case of SI/ISI, the SI/ISI upload file will be validated and processed by CCASS/3 on a real time basis after a PG sends a SI/ISI upload file. When the SI/ISI upload file processing is completed and the SI/ISI Batch Input Control Report is available, CCASS/3 will send a notification message to PG if the PG users have subscribed the notification message. Other upload files will be handled as scheduled jobs.

 

53.    What is the page size of SI general enquiry? And how are the SI records related to the MC557?

          Currently, the page size is defined as 10, i.e. for each MC557 enquiry message, a maximum of 10 SI records will be returned in MC558. For example, if there are 120 SI records, 12 MC557 message should be submitted and 12 MC558 will be returned containing a total of 120 SI records. In each MC558, there is an indicator showing if more records are available, such that PSS can determine if it should submit MC557 again.

 

54.    For Cancel SI and Revoke Matched SI messages, do they require both ‘SI input number’ and ‘timestamp’ as the key matching criteria?

          Yes, both fields are required. Both SI input number and timestamp can be retrieved through Enquiry SI (Single) (MC556).

 

55.    Is it possible to utilize the real-time intra-day delivery of settlement instructions (including cancellations) to CCASS/3 and also to receive realtime settlement and status updates on each transaction?

          Currently, there are messages MT540-543 for settlement instruction maintenance, e.g. “Input SI” and “Cancel SI”. Since the communication protocol between PG and CCASS/3 is a request-response model, it is not feasible to push any real time settlement and status update. So PG users need to proactively send a SI enquiry instead, or to download the settlement reports via PG to extract the status of the settlement instructions.

 

56.    Can we download the online report list via PG?

          Participants can retrieve the report list via “Enquire Report Master/Availability List” (MC913) in PG if they are available on C3T.