Intrusive access to the risk control gateway platform system of heterogeneous counters

Abstract

The present invention discloses a risk control gateway platform system for intrusive access to heterogeneous counters, which can connect to futures trading counter systems with different interfaces of different manufacturers at a relatively low cost. The technical solution is as follows: the risk control gateway platform system simulates the standard protocol of the exchange, adopts the method of simulating and encapsulating the API of each futures trading counter system, and connects to heterogeneous counters through the simulated API. Intrusive means that when connecting to the futures trading counter, the native API header file structure of the corresponding counter system is referenced, and a simulated API is generated through appropriate modification for the trading customers to replace the original API. At the same time, the customer actually connects to the futures front-end service provided in the risk control gateway platform system of the present invention, which is forwarded to the corresponding futures trading counter system after the risk control check, that is, the risk control gateway platform system of the present invention invades the transaction link.

Description

Technical Field

[0001] The present invention relates to an access technology for a counter system in the financial industry, and in particular to a risk control gateway platform system for intrusive access to heterogeneous counters. Background Art

[0002] With the strengthening of the mixed operation trend in the financial market and the rapid development of innovative businesses, the business capacity of securities companies has increased rapidly, among which many cross-market arbitrage transactions and diversified asset allocation business needs have emerged, which have put forward more requirements for cross-market transactions and unified risk control. More and more securities companies have begun to purchase multiple counter systems to meet the trading needs of different teams, but the existing risk control systems on the market cannot collect data from heterogeneous counter systems of different manufacturers at multiple trading entrances at the same time. In particular, the futures counter systems on the market currently lack unified and open interface standards, which increases the difficulty of unified risk control across the futures and spot markets.

[0003] The existing risk control system model can no longer meet the unified risk control scenario of the cross-futures and spot markets under the new situation. Securities companies are in urgent need of an independent risk control system that can connect to multiple different investment management systems upstream, while supporting the connection to multiple heterogeneous futures trading counter systems and the Shanghai and Shenzhen Stock Exchanges downstream. The Shanghai and Shenzhen Stock Exchanges have adopted public protocols and interface standards, so there are no major technical difficulties in connection; however, the futures trading counter system faces the problem of different interfaces from different manufacturers.

[0004] Therefore, how to connect futures trading counter systems with different interfaces from different manufacturers is a problem that needs to be solved at present. Summary of the invention

[0005] A brief summary of one or more aspects is given below to provide a basic understanding of these aspects. This summary is not an exhaustive overview of all conceived aspects, and is neither intended to identify the key or critical elements of all aspects nor to define the scope of any or all aspects. Its only purpose is to give some concepts of one or more aspects in a simplified form as a prelude to a more detailed description that will be given later.

[0006] The purpose of the present invention is to solve the above problems and provide a risk control gateway platform system for intrusive access to heterogeneous counters, which can connect to futures trading counter systems with different interfaces from different manufacturers at a lower cost.

[0007] The technical solution of the present invention is as follows: The present invention discloses a risk control gateway platform system for intrusive access to heterogeneous counters, the system includes at least one risk control center, each of which includes a transaction forwarding module, a market information receiving module, a risk control service module, a data entry module, a data exit module, a database server, and a system management module, wherein:

[0008] The transaction forwarding module is used to send the collected orders of the brokerage trading counter system to the risk control service module, and send the orders checked by the risk control service module to the exchange, and the return information of the exchange is sent to the risk control service module through the transaction forwarding module after being collected. Among them, when the transaction forwarding module provides a simulation API when connecting to futures trading, the customer trading program calls the simulation API to send the transaction request data to the transaction forwarding module, and then the transaction forwarding module sends it to the risk control service module for risk control inspection, and determines whether to send it to the futures counter system or return the wrong order according to the risk control inspection result;

[0009] The market receiving module is used to connect to the market source, receive real-time market data of the entire market, process the data and then push it to the risk control service module;

[0010] The data entry module reads the basic data required by the risk control service module to process business from the database server and sends the read basic data to the risk control service module;

[0011] The data disposal module stores the process data that needs to be disposed of during the business processing of the risk control service module in the database server;

[0012] Database server, to complete the persistent storage of data;

[0013] System management module, used for system maintenance and operation management;

[0014] The risk control service module is used for the calculation and verification of risk control indicators.

[0015] According to an embodiment of the risk control gateway platform system for intrusive access to heterogeneous counters of the present invention, the multiple risk control centers include the Shanghai Stock Exchange Risk Control Center, the Shenzhen Stock Exchange Risk Control Center, and the Futures Risk Control Center.

[0016] According to an embodiment of the risk control gateway platform system for intrusive access to heterogeneous counters of the present invention, the risk control service module includes a transaction data subscription thread, a market data receiving thread, a risk control core thread, and a data publishing thread, wherein:

[0017] The market data receiving thread receives the real-time market data sent by the market receiving module, maintains a market snapshot in the memory, and records the latest market slice data for use in the subsequent calculation of indicators for new orders;

[0018] The transaction data subscription thread receives data input from the data entry module of this risk control center or other risk control centers, queues the input data, and outputs it to the serialized request data stream, where the risk control core thread performs risk control business processing on the request data stream;

[0019] The risk control core thread calculates and checks multiple risk control indicators in sequence for the orders in the request data stream, and writes the calculation and check results into the result data stream;

[0020] The data publishing thread sends the result data stream to the data output module of this risk control center or the risk control service module of other risk control centers.

[0021] According to an embodiment of the risk control gateway platform system for intrusive access to heterogeneous counters of the present invention, the risk control core thread uses a complex event processing engine to process real-time calculations of risk control indicators, and uses an in-memory database to maintain data sequences including orders and transactions.

[0022] According to an embodiment of the risk control gateway platform system for intrusive access to heterogeneous counters of the present invention, the data received by the transaction data subscription thread includes: real-time transaction data, initial / real-time on-site data, and synchronization data of other risk control centers.

[0023] According to an embodiment of the risk control gateway platform system for intrusive access to heterogeneous counters of the present invention, the simulation API is further configured as follows:

[0024] The SDK provided by the risk control gateway platform system recompiles the program so that the futures counter address originally called by the user is configured into the simulated service address provided by the futures front-end of the risk control gateway platform system. The user's service request is sent to the corresponding futures front-end service through the simulated API. The futures front-end service converts the structure data of the received user service request into a unified structure defined in the data model of the risk control gateway platform system and sends it to the risk control service module. After completing the risk control check, the risk control service module returns the inspection result to the futures front-end service. The futures front-end service then calls the native API of the futures counter system to interact with the futures counter system.

[0025] According to one embodiment of the risk control gateway platform system for intrusive access to heterogeneous counters of the present invention, for the CTP counter system, the risk control gateway platform system provides customers with a simulation API that imitates the CTP API, so that customers only need to replace the dynamic library file of the original API to connect to the futures pre-service of the risk control gateway platform.

[0026] According to an embodiment of the risk control gateway platform system for intrusive access to heterogeneous counters of the present invention, for the Pegasus counter system, for each connection of the customer's trading program, a corresponding session connection with the Pegasus counter system is established in the counter system docking unit of the transaction forwarding module, and the transaction forwarding module completes the collection and forwarding of the order declaration data of the customer's trading program on the pair of sessions established by the counter system docking unit.

[0027] Compared with the prior art, the present invention has the following beneficial effects: the risk control gateway platform system of the present invention for intrusive access to heterogeneous counters simulates the standard protocol of the exchange, adopts the method of simulating and encapsulating the API of each futures trading counter system, and connects to the heterogeneous counter through the simulated API. Intrusive means that when connecting to the futures trading counter, the native API header file structure of the corresponding counter system is referenced, and a simulated API is generated through appropriate modification for the trading customers to replace the original API. At the same time, the customer actually connects to the futures front-end service provided in the risk control gateway platform system of the present invention, which is forwarded to the corresponding futures trading counter system after the risk control check, that is, the risk control gateway platform system of the present invention invades the transaction link. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The above features and advantages of the present invention can be better understood after reading the detailed description of the embodiments of the present disclosure in conjunction with the following drawings. In the drawings, the components are not necessarily drawn to scale, and components with similar related properties or features may have the same or similar reference numerals.

[0029] Figure 1 A schematic diagram showing the overall system environment of the risk control gateway platform system between the exchange and the futures trading counter system.

[0030] Figure 2 A schematic diagram showing the architecture model of the risk control gateway platform system adopting a decentralized asynchronous risk control.

[0031] Figure 3 The internal thread logic diagram of the risk control service module in the risk control gateway platform system is shown.

[0032] Figure 4 It shows the data flow diagram of CTP counter orders entrusted by investors after they access the risk control gateway platform system.

[0033] Figure 5 A schematic diagram showing external docking of a transaction forwarding module of a CTP counter system is shown.

[0034] Figure 6 A schematic diagram showing external docking of a transaction forwarding module of a futures trading counter system is shown.

[0035] Figure 7 It shows a schematic diagram of the message forwarding flow between modules and systems when investors perform query and order operations through the CTP-like API. DETAILED DESCRIPTION

[0036] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. Note that the aspects described below in conjunction with the accompanying drawings and specific embodiments are only exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0037] like Figure 1 As shown, the risk control gateway platform system of the present invention is located at the final exit of the transaction order, that is, between the securities trading counter system and the stock exchange, or between the futures order and the futures trading counter system. The risk control gateway platform system performs unified risk control across systems and markets for all transaction entrustment data. At present, there are mainly methods such as simulating exchange standard protocols, providing warehouse API interfaces, and providing simulated API docking with heterogeneous counters.

[0038] For the method of providing simulated API to connect heterogeneous counters, the heterogeneous counters refer to the need to connect to multiple different counter systems (such as different securities trading counter systems, different futures trading counter systems, etc.), that is, the architecture, data structure, and standards used by the counter systems to be connected are different. Figure 1 They are uniformly marked as other futures over-the-counter systems.

[0039] like Figure 2 As shown, the embodiment of the risk control gateway platform system of the present invention adopts a sub-center asynchronous risk control architecture mode, with a total of three risk control centers: Shanghai Stock Exchange Risk Control Center, Shenzhen Stock Exchange Risk Control Center, and Futures Risk Control Center, which are used to directly connect to the Shanghai Stock Exchange, Shenzhen Stock Exchange, and various futures companies' counter systems.

[0040] Each risk control center includes a transaction forwarding module, a market receiving module, a risk control service module, a data entry module, a data exit module, a database server, and a system management module. The transaction forwarding module of each risk control center is used to connect with the risk control service module of the risk control center, send the collected orders of the brokerage trading counter system to the risk control service module for risk control inspection, and send the orders that have been inspected by the risk control service module to the exchange. In addition, the return information of the exchange will be sent to the risk control service module in real time through the transaction forwarding module after collection, and participate in the calculation of risk control indicators. Among them, when the transaction forwarding module provides a simulation API when docking futures trading, the customer trading program calls the simulation API to send the transaction request data to the transaction forwarding module, and then the transaction forwarding module sends it to the risk control service module for risk control inspection, and determines whether to send it to the futures counter system or return the wrong order according to the risk control inspection results.

[0041] The market information receiving module is used to connect to the market information source, receive real-time market information of the entire market, process the data, and then push it to the risk control service module.

[0042] The data entry module reads the basic data required by the risk control service module to process business stored on the database server, and sends the read basic data to the risk control service module.

[0043] The data disposal module completes the storage of process data that needs to be disposed of by the risk control service module during business processing to the database server.

[0044] The database server, usually an Oracle database, completes the storage of data.

[0045] The system management module is a management platform of the BS architecture provided by the risk control gateway platform system, on which the daily operation and maintenance of the system is completed.

[0046] The risk control service module is used for the calculation and verification of risk control indicators.

[0047] The collection methods and docking solutions of each exchange are different. The Shanghai and Shenzhen Stock Exchanges have public standard protocol interfaces, and the standardized protocols can be directly used to seamlessly connect to the counter systems of various securities companies. However, the futures trading counter systems are all connected to the APIs of various suppliers, and there is no unified standard. Considering the actual situation of the mainstream futures trading counters in the current market, the risk control gateway platform system of this embodiment adopts an intrusive heterogeneous counter docking solution that simulates and encapsulates the APIs of various suppliers.

[0048] Specifically, investors still use the original API interface method and structure to connect transactions, and only need to recompile the program with the SDK (software development kit, which contains the necessary information for using the API) provided by the risk control gateway platform system. The futures counter address originally called by the user is configured as the simulated service address provided by the futures front-end (i.e., the futures trading part of the transaction forwarding service module corresponding to the futures transaction) of the risk control gateway platform system. The user's service request is sent to the corresponding futures front-end service through the simulated API. The futures front-end service converts the received structure data into a unified structure in the data model defined by the risk control gateway platform system and sends it to the risk control service module. After completing the risk control check, the risk control service module returns the inspection results to the futures front-end service, and the futures front-end service calls the native API of the counter system to interact with the futures counter system.

[0049] Figure 3 It reflects the internal thread logic of the risk control service module in the risk control gateway platform system. Figure 3 As shown, the thread logic of each risk control center is basically the same, and the main difference lies in the implementation of the transaction forwarding module.

[0050] like Figure 3 As shown in the figure, the risk control service module mainly includes transaction data subscription thread, market data receiving thread, risk control core thread, and data publishing thread, among which:

[0051] The market data receiving thread is responsible for receiving the real-time market data sent by the market receiving module, maintaining a market snapshot in the memory, and recording the latest market slice data for use in calculating relevant indicators for subsequent new orders.

[0052] The transaction data subscription thread is responsible for receiving input data from other modules (such as data input from the data entry module of this risk control center or other risk control centers), queuing the input data of multiple modules, and outputting it to the serialized request data stream. The risk control core thread performs risk control business processing on the request data stream.

[0053] The data received by the transaction data subscription thread includes:

[0054] Real-time transaction data: sent by each transaction forwarding module of the center, including order information reported by the brokerage counter system, order confirmation returned by the exchange, and order transaction information;

[0055] Initial / real-time data: sent by the data entry module, including the initial basic data maintained in the database server when the system is just started, such as securities information, rate information, fund products, shareholder codes, risk control indicators, etc.;

[0056] Synchronous data from other risk control centers: sent by the risk control service modules of other risk control centers, including order information that has passed inspection in other centers, exchange confirmation and transaction information in other centers. These data will be used in the calculation of cross-market risk control indicators. For example, for position cost control, it is necessary to calculate the securities positions of Shanghai and Shenzhen stock exchanges under comprehensive fund products; while for futures and spot matching control, it is necessary to calculate and compare the stock index futures contract positions of China Financial Futures Exchange and the securities positions of Shanghai and Shenzhen stock indexes.

[0057] The core risk control thread is responsible for calculating and checking various risk control indicators in turn for the orders in the request data stream, and writing the results into the result data stream, which is eventually sent to other related modules (such as the data exit module of this risk control center, or the risk control service module of other risk control centers) by the data publishing thread. This thread uses a complex event processing engine to process the real-time calculation of various indicators, and uses an in-memory database to maintain data sequences such as orders and transactions.

[0058] like Figure 4As shown, investors of CTP counter (Comprehensive Transaction Platform, a chairman system) (CTP counter is a type of futures counter system with the highest market share in the futures market, and is a type of futures trading counter system) call the futures front-end service urgent_ctp (i.e., transaction forwarding module) of the CTP counter through the simulation API of the present invention. The futures front-end service urgent_ctp converts the data sent by the CTP counter and synchronizes it to the risk control service module Urkernel for inspection to obtain the risk control inspection result. After receiving the risk control inspection result, the futures front-end service urgent_ctp decides to return or forward the entrustment request to the CTP counter.

[0059] Figure 5 and Figure 6 The main access schemes of the risk control gateway system of the present invention are shown respectively, wherein Figure 5 It is an external connection for the transaction forwarding module of the CTP counter system. Figure 6 It is an external docking for the transaction forwarding module of the Pegasus counter system. Both Pegasus and CTP counters belong to futures counter systems. Since the Pegasus system is an internal system, the docking directly adopts the native API method, while the CTP counter adopts the simulated API method because it is a third-party manufacturer. The present invention focuses on explaining the method of docking with the CTP counter.

[0060] Because each futures exchange has strict requirements and restrictions on the access to the trading system, and only provides API as an access method, it is very difficult for the risk control gateway platform system to realize proxy forwarding between the futures trading system and the futures counter system. In view of this, the present invention uses the futures counter system and its API interface to realize the collection and transfer of futures trading data.

[0061] like Figure 5 and Figure 6 As shown in the figure, the transaction forwarding module of the risk control gateway system is located between the customer trading program and the futures counter system, and does not directly interact with the trading systems of the four futures exchanges (China Financial Futures Exchange, Shanghai Futures Exchange, Zhengzhou Commodity Exchange, and Dalian Commodity Exchange):

[0062] (1) Figure 5 As shown, for the CTP counter system, the risk control gateway platform system of the present invention provides customers with a simulated API that imitates the CTP API. Customers only need to replace the dynamic library file of the original API (the CTP counter system provides dynamic library files for customers to call related interfaces) to connect to the futures pre-service of the risk control gateway platform (the futures pre-service of the risk control gateway platform is Figure 5 and Figure 7The transaction forwarding module of the CTP counter system) does not need to make code changes. The present invention refers to the native API header file structure of the corresponding counter system and generates a simulated API by appropriate modification. For each connection of the customer transaction program, a CTP API instance with the CTP counter system is correspondingly established, and the transaction forwarding module completes the collection and forwarding of the order declaration data of the customer transaction program on the session in the customer docking unit (the customer docking unit is used to dock the customer transaction program). Among them, the order declaration data of the customer trading program is sent to the risk control service module for risk control inspection through the customer docking unit in the transaction forwarding module after collection. After receiving the checked order, the transaction forwarding module forwards it to the CTP counter system through the native CTP API corresponding to the counter system docking unit (the counter system docking unit is used to dock with the CTP counter system); the return data returned by the CTP counter system is sent to the risk control service module through the counter system docking unit of the transaction forwarding module to participate in the risk control calculation after collection, and will also be returned to the customer trading program through the corresponding customer docking unit session; non-transaction messages, such as heartbeat packets, logins, query requests, query responses and other messages, are directly transmitted through the session, that is, the uplink packet is not processed after receiving, and is transmitted from the customer trading program to the futures counter system; the downlink response message is transmitted from the futures counter system to the customer trading program.

[0063] (2) The risk control gateway platform system can achieve Figure 6 The data agent of the Pegasus counter system is forwarded. Customers use the API of the Pegasus counter system to connect to the risk control futures front (the risk control futures front refers to Figure 2 The transaction forwarding module in the counter system does not require any changes. For each connection of the customer's transaction program, a corresponding session connection with the Pegasus counter system is established in the counter system docking unit. The transaction forwarding module completes the collection and forwarding of the order declaration data of the customer's transaction program on this pair of sessions in the counter system docking unit.

[0064] In particular, the abnormal risk control orders of the futures risk control center are converted into the wrong order format of the counter system within the transaction forwarding module and sent to the customer's trading program.

[0065] Figure 7 It shows the forwarding flow of messages between modules and systems when investors use the CTP-like API to query and place orders.

[0066] For query messages, the client trading program simulates the API call query interface and sends the query request to the futures front-end service (i.e., transaction forwarding module) of the risk control gateway platform system. The query request is transparently forwarded and then forwarded to the counter system. Similarly, the query result is returned to the futures front-end service (i.e., transaction forwarding module) and then directly forwarded to the client trading program.

[0067] The client's trading program initiates an order request by simulating an API call to the order interface. After the request reaches the futures front-end service (i.e., the transaction forwarding module), it will first be sent to the risk control core (i.e., the risk control service module) for indicator calculation and inspection. If the inspection fails, the error information will be directly returned to the client. The client can adjust the order based on the error information and reissue the request. If the risk control check passes, it will be returned to the futures front-end service (i.e., the transaction forwarding module), and the futures front-end service will forward the request to the CTP counter system by calling the native API of CTP. After the order return returned by the counter system reaches the futures front-end service, the futures front-end service will forward the return information to the client and also send it to the risk control core (i.e., the risk control service module).

[0068] Although the above methods are illustrated and described as a series of actions for simplicity of explanation, it should be understood and appreciated that these methods are not limited by the order of the actions, because according to one or more embodiments, some actions may occur in a different order and / or concurrently with other actions from those illustrated and described herein or not illustrated and described herein but understandable to those skilled in the art.

[0069] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. The technician may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as resulting in a departure from the scope of the present invention.

[0070] The various illustrative logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in cooperation with a DSP core, or any other such configuration.

[0071] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read and write information from / to the storage medium. In an alternative, a storage medium may be integrated into a processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and the storage medium may reside in a user terminal as discrete components.

[0072] In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented as a computer program product in software, each function may be stored on or transmitted by a computer-readable medium as one or more instructions or codes. Computer-readable media include both computer storage media and communication media, including any medium that facilitates the transfer of a computer program from one place to another. Storage media may be any available medium that can be accessed by a computer. As an example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Any connection is also properly referred to as a computer-readable medium. For example, if the software is transmitted from a website, a server, or other remote source using a coaxial cable, a fiber optic cable, a twisted pair, a digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of the medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, wherein disk often reproduces data magnetically, while disc reproduces data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0073] The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but should be granted the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A risk control gateway platform system for intrusive access to heterogeneous counters, characterized in that: The system includes at least one risk control center, each of which includes a transaction forwarding module, a market information receiving module, a risk control service module, a data upload module, a data download module, a database server, and a system management module, wherein: The transaction forwarding module is used to send the collected orders of the brokerage trading counter system to the risk control service module, and send the orders checked by the risk control service module to the exchange, and the return information of the exchange is sent to the risk control service module through the transaction forwarding module after being collected. Among them, when the transaction forwarding module provides a simulation API when connecting to futures trading, the customer trading program calls the simulation API to send the transaction request data to the transaction forwarding module, and then the transaction forwarding module sends it to the risk control service module for risk control inspection, and determines whether to send it to the futures counter system or return the wrong order according to the risk control inspection result; The market receiving module is used to connect to the market source, receive real-time market data of the entire market, process the data and then push it to the risk control service module; The data entry module reads the basic data required by the risk control service module to process business from the database server and sends the read basic data to the risk control service module; The data disposal module stores the process data that needs to be disposed of during the business processing of the risk control service module in the database server; Database server, to complete the persistent storage of data; System management module, used for system maintenance and operation management; Risk control service module, used for calculation and verification of risk control indicators; Among them, the simulation API is further configured as: The SDK provided by the risk control gateway platform system recompiles the program so that the futures counter address originally called by the user is configured into the simulated service address provided by the futures front-end of the risk control gateway platform system. The user's service request is sent to the corresponding futures front-end service through the simulated API. The futures front-end service converts the structure data of the received user service request into a unified structure defined in the data model of the risk control gateway platform system and sends it to the risk control service module. After completing the risk control check, the risk control service module returns the inspection result to the futures front-end service. The futures front-end service then calls the native API of the futures counter system to interact with the futures counter system.

2. The risk control gateway platform system for intrusive access to heterogeneous counters according to claim 1 is characterized in that: Multiple risk control centers include the Shanghai Stock Exchange Risk Control Center, Shenzhen Stock Exchange Risk Control Center, and Futures Risk Control Center.

3. The risk control gateway platform system for intrusive access to heterogeneous counters according to claim 1 is characterized in that: The risk control service module includes transaction data subscription thread, market data receiving thread, risk control core thread, and data publishing thread, among which: The market data receiving thread receives the real-time market data sent by the market receiving module, maintains a market snapshot in the memory, and records the latest market slice data for use in the subsequent calculation of indicators for new orders; The transaction data subscription thread receives data input from the data entry module of this risk control center or other risk control centers, queues the input data, and outputs it to the serialized request data stream, where the risk control core thread performs risk control business processing on the request data stream; The risk control core thread calculates and checks multiple risk control indicators in sequence for the orders in the request data stream, and writes the calculation and check results into the result data stream; The data publishing thread sends the result data stream to the data output module of this risk control center or the risk control service module of other risk control centers.

4. The risk control gateway platform system for intrusive access to heterogeneous counters according to claim 3 is characterized in that: The core thread of risk control uses a complex event processing engine to handle the real-time calculation of risk control indicators, and adopts an in-memory database to maintain data sequences including orders and transactions.

5. The risk control gateway platform system for intrusive access to heterogeneous counters according to claim 3 is characterized in that: The data received by the transaction data subscription thread includes: real-time transaction data, initial / real-time trading data, and synchronization data from other risk control centers.

6. The risk control gateway platform system for intrusive access to heterogeneous counters according to claim 1 is characterized in that: For the CTP counter system, the risk control gateway platform system provides customers with a simulated API that imitates the CTP API, so that customers only need to replace the dynamic library file of the original API to connect to the futures pre-service of the risk control gateway platform.

7. The risk control gateway platform system for intrusive access to heterogeneous counters according to claim 1 is characterized in that: For the Pegasus counter system, for each connection of the customer's trading program, a corresponding session connection with the Pegasus counter system is established in the counter system docking unit of the transaction forwarding module. The transaction forwarding module completes the collection and forwarding of the order declaration data of the customer's trading program on the pair of sessions established by the counter system docking unit.

Images