An institutional sub-account system

Abstract

The present invention discloses an institutional sub-account system, which does not need to implement business functions separately, and can directly reuse the system architecture of supporting institutional sub-accounts for counter business processing, thereby ensuring the integrity and consistency of functions and reducing the cost of subsequent maintenance. The technical solution is as follows: the sub-account system is separated from the open counter system and has a flexible deployment method. For institutional users, it is not necessary to deploy the counter in their own environment, and they can choose to connect to the terminal only for transactions. The system of the present invention does not implement business processing separately, but adopts the business processing dynamic library in the counter system to reduce the cost of maintaining the business processing logic. When the business is updated, only the business processing dynamic library needs to be updated.

Description

Technical Field

[0001] The present invention relates to an account system, and in particular to an institutional sub-account system applied in the field of financial derivatives. Background Art

[0002] In recent years, with the expansion of financial derivatives and the spread of financial knowledge, more and more institutional accounts and proprietary accounts have also participated in financial derivatives transactions. Due to the regulations of the exchange, a legal person can only open one account at the exchange. However, an institutional account or a proprietary account is often operated by many traders, and it is necessary to distinguish sub-accounts operated by different traders in an institutional account. At the same time, for risk control, the administrator also needs to monitor the total account, team level and sub-account level (two-level sub-accounts), and needs to monitor the funds and positions of the sub-accounts separately, and remind when the loss of the day exceeds the threshold. The risk control administrator also needs to be able to force liquidation of sub-accounts.

[0003] At present, there are systems to meet the needs of sub-accounts, such as Figure 1 As shown in the figure, the existing system realizes the separation of accounts and funds at the user level. Each trader uses the user code of the sub-account to perform trading operations. The core will find the corresponding user code of the upper management at all levels according to the user code, perform corresponding fund operations on the user code of the sub-account and the user code of the upper management at all levels, and then send the corresponding instructions to the exchange to trade with the account code opened by the institution in the exchange.

[0004] The existing system has its own sub-account processing in the open counter, so it is not suitable for most individual users, and it is directly modified in the original module of the open counter, which is equivalent to re-implementing the business processing in the bank version. Therefore, if there are new businesses or modifications to the original businesses, business modifications need to be made in both the open counter and the bank version, which will increase business maintenance costs, and there is no guarantee that there are no missing functions or omissions, and that the business functions of the two versions are completely consistent. 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 an institutional sub-account system that does not need to implement business functions separately and can directly reuse the system architecture that supports institutional sub-accounts for developing counter business processing, thereby ensuring the integrity and consistency of functions and reducing subsequent maintenance costs.

[0007] The technical solution of the present invention is as follows: The present invention discloses an institutional sub-account system, which includes a quotation process module, a core processing process module, and a front process module, wherein:

[0008] The front-end process module provides the institutional client with the TCP port address for accessing the institutional sub-account system, receives requests from the institutional client and forwards these requests to the core processing module, and receives the response information after request processing sent from the core processing process module and replies to the institutional client;

[0009] The core processing module is used to complete the funds and positions processing of sub-accounts and their parent accounts;

[0010] The quotation process module is connected to the front-end process module of the development counter system. When it receives the transaction request sent by the core processing process module of the institutional sub-account system, it establishes the connection between the institutional sub-account system and the open counter system, logs in with the user code in the transaction request, sends the corresponding transaction request to the open counter system, and transmits the feedback of the open counter system to the core processing process module.

[0011] According to an embodiment of the institution sub-account system of the present invention, the core processing process module of the institution sub-account system directly calls the business processing dynamic library in the core processing process module of the open counter system to perform business processing.

[0012] According to an embodiment of the institutional sub-account system of the present invention, when the core business of funds and position processing changes, the business processing dynamic library in the open counter system is updated without changing the core processing process module of the institutional sub-account system.

[0013] According to an embodiment of the institution sub-account system of the present invention, when the number of levels of the institution sub-account increases, the core processing process module of the institution sub-account system increases the number of times the business processing dynamic library is called.

[0014] According to one embodiment of the institutional sub-account system of the present invention, the hierarchical correspondence of the sub-accounts is saved in the core processing process module of the institutional sub-account system, and one account includes corresponding investor codes, user codes, and transaction codes, wherein the transaction code of the institution is jointly operated by the primary account, and the funds and positions of the primary account are the summary of the funds and positions of the primary account. One primary account contains multiple secondary sub-accounts, and the multiple secondary sub-accounts respectively have their own funds and positions, which are summarized into the funds and positions of the primary account. The investor codes, user codes, and transaction codes corresponding to the secondary sub-accounts are virtual.

[0015] According to an embodiment of the institutional sub-account system of the present invention, the core processing module configures the processing process of the sub-account transaction as follows:

[0016] The core processing module obtains the user code, investor code, and transaction code of the institution's sub-account itself, as well as the user code, investor code, and transaction code of all upper-level accounts of the institution's sub-account, according to the hierarchical correspondence of the institution's sub-accounts;

[0017] For the sub-account of the institution and all its associated upper-level accounts, the business processing dynamic library in each account is called through the open counter system to process funds and positions, so that the fund changes caused by the trading operations of the lower-level trader accounts can be reflected in the upper-level accounts at the same time;

[0018] When the fund processing of the institutional sub-account and its upper-level account is completed, the operation information of the upper-level account is sent to the quotation process module. The operation information of the institutional sub-account is only stored in the core processing process module of the institutional sub-account system;

[0019] When the core processing module receives the response to the transaction request transmitted by the quotation process module from the open counter system, it performs fund and position operations on the sub-accounts at all levels.

[0020] According to one embodiment of the institutional sub-account system of the present invention, the deployment method of the institutional sub-account system and the independent open counter system includes any one of the following three methods: the first is to deploy the institutional sub-account system and the open counter system simultaneously inside the bank, the second is to deploy the institutional sub-account system and the open counter system simultaneously inside the futures company, and the third is to deploy the open counter system in the futures company and the institutional sub-account system inside the bank.

[0021] According to one embodiment of the institutional sub-account system of the present invention, a plurality of quotation processes are further provided in the quotation process module for connecting financial business counters including securities counters, options counters, and main counters, and a plurality of business dynamic libraries are correspondingly provided in the corresponding core processing process module for processing the business operations of the corresponding counters.

[0022] Compared with the prior art, the present invention has the following beneficial effects: while realizing the needs of institutional accounts and risk control administrators for sub-accounts, the system of the present invention reduces the coupling between sub-account functions and counter channel functions, making the sub-account functions relatively independent and compatible with the original system of the open counter, while supporting the use of institutional users and individual users.

[0023] Specifically, the system of the present invention has the following innovative features:

[0024] (1) Separation of sub-account system from open counter system: Separation of sub-account system from open counter channel system provides a more flexible deployment method. For institutional users, they do not need to deploy counters in their own environment and can choose to only connect to the terminal for trading.

[0025] (2) Do not implement business processing separately, but use business processing dynamic library: Do not rewrite business processing, but directly use business processing dynamic library, which reduces the cost of maintaining business processing logic. When the business is updated, only the business processing dynamic library needs to be updated. At the same time, the present invention has high scalability. If the number of sub-account levels increases in the future, it only needs to increase the number of calls to the business processing dynamic library. In addition, it can also be easily expanded to use other business processing libraries. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] 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.

[0027] Figure 1 The schematic diagram of the architecture of the existing account system and counter system is shown.

[0028] Figure 2 A schematic diagram of the architecture of an embodiment of the institution sub-account system of the present invention is shown.

[0029] Figure 3 A schematic diagram showing an example of a hierarchical structure of transaction encodings.

[0030] Figure 4 A schematic diagram showing the relationship between investor codes, user codes, and transaction codes in an open counter account.

[0031] Figure 5 A schematic diagram showing an example of an account hierarchy of secondary sub-accounts.

[0032] Figure 6 A schematic diagram showing the flow of trading operations for sub-accounts.

[0033] Figure 7 A schematic diagram showing an example of how the institutional sub-account system of the present invention is deployed within a bank and a futures company.

[0034] Figure 8 A schematic diagram of the architecture showing the scalability of the institutional sub-account system of the present invention. DETAILED DESCRIPTION

[0035] 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.

[0036] Figure 2 The structure of an embodiment of the institutional sub-account system of the present invention is shown. Figure 2 The institutional sub-account system of this embodiment includes: an offer (exmanager) process module, a core processing (uskernel) process module, and a front (usfront) process module. An independent external system connected to the institutional sub-account, the development counter system, includes an offer process module, a core processing process module, a queue machine module, and a front process module. The queue machine module sorts the messages sent and sends them to the core processing process module in a unified order.

[0037] The front-end process module in the institutional sub-account system is a process module that interacts directly with the client. The front-end process module provides the institutional client with the TCP port address for accessing the institutional sub-account system. The institutional client uses the API provided by the institutional sub-account system to establish a connection with the institutional sub-account system to log in, place orders, and perform other trading operations. The front-end process module receives requests sent by the client (i.e., requests for login, order placement, or other trading operations) and forwards these requests to the core processing module. It also receives the request processing feedback information sent from the core processing process module and replies it to the client.

[0038] The core processing module is used to complete the funds and position processing of sub-accounts and their parent accounts.

[0039] Since the processing of fund holdings is consistent with the processing of the core processing process module in the open counter, the business processing of fund holdings is not implemented again in the core processing process module of the institutional sub-account system, but the business processing dynamic library libtrade.so in the core processing process module of the open counter system is directly called for business processing, so as to ensure that the business processing logic in the institutional sub-account system is consistent with the open counter system, and at the same time save the secondary maintenance of the core business code. When there are changes in core businesses such as fund and position processing, only the libtrade.so library in the open counter system needs to be updated, and no changes need to be made to the core processing process module of the sub-account system. At the same time, the present invention also has high scalability. If the number of sub-account levels increases later, only the number of calls to the business processing dynamic library needs to be increased, and no modification needs to be made to the specific business logic.

[0040] In the institutional sub-account system, each level of sub-account needs to control funds and positions separately, and their profits and losses need to be counted separately in order to calculate the trader's personal performance and the department's performance.

[0041] Figure 3 Depicts an example of a hierarchical structure of transaction codes. The transaction codes of an institution are jointly operated by first-level accounts (department accounts, team accounts, or upper-level trader users, etc.), and the funds and positions of first-level accounts are the summary of the funds and positions of first-level accounts. A first-level account also contains many second-level sub-accounts (traders), and these second-level sub-accounts have their own funds and positions, which are summarized into the funds and positions of the first-level account.

[0042] The hierarchical correspondence of sub-accounts is saved in the core processing module. In the open counter system, an account will have a corresponding investor code InvestorID, user code UserID, and transaction code ClientID. Figure 4 For individual users, their transaction codes, investor codes and user codes are all real, and the transaction codes can be reported to the exchange for trading. However, for sub-accounts, user codes, investor codes and transaction codes of the corresponding levels will be virtualized. The account hierarchy structure of the secondary sub-account is shown in Figure 5 . Assuming that the current demand for sub-accounts only reaches the second-level sub-accounts at most, the second-level sub-accounts only have the top-level transaction code, that is, the transaction code opened in the name of the company is real in the exchange and can be traded. The user code, investor code, and transaction code of other sub-accounts are virtual for the counter and only exist in the user relationship of the sub-account system.

[0043] When a sub-account performs a transaction, the processing process is as follows Figure 6As shown. The core processing module obtains the user code, investor code, and transaction code of the sub-account itself, as well as the user code, investor code, and transaction code of all upper-level accounts of the sub-account according to the hierarchical correspondence of the sub-accounts (assuming that there are at most secondary sub-accounts at present, a maximum of three accounts will be obtained). For these three accounts, the business processing dynamic library libtrade.so in these three accounts is called by the open counter system to process funds and positions, so that the fund changes caused by the trading operations of the lower-level trader accounts are reflected in the upper-level accounts at the same time. When the fund processing of the sub-account and its upper-level accounts is completed, the operation information of the top-level account is sent to the offer process module, and the operation information of the sub-account is only saved in the core processing module of the institutional sub-account system. When the core processing module receives the feedback of the transaction request from the offer process module from the open counter system, it performs fund and position operations on the obtained sub-accounts at all levels. In addition, by subscribing to the fund and position change messages sent by the core processing process module, the bypass approval and risk control can obtain the current funds and positions of sub-accounts at all levels for approval or risk control.

[0044] The quotation process module in the institutional sub-account system is different from the quotation process module in the open counter (the quotation process module in the open counter system is connected to the front-end process module of the exchange). The quotation process module in the institutional sub-account system is connected to the front-end process module of the open counter system. In the quotation process module of the institutional sub-account system, when receiving a transaction request sent by the core processing process module in the institutional sub-account system, an API instance of the open counter system is created, the connection between the institutional sub-account system and the open counter system is established, and then the user code in the request is used to log in and send the corresponding transaction request to the open counter system. Since the user level sent by the quotation process module in the institutional sub-account system to the front-end process module of the open counter system is the upper user, the account information of the upper user exists in the open counter system, and the request of the upper user is processed in the open counter system and sent to the exchange. The quotation process module of the institutional sub-account system also processes the feedback of the open counter system for the request and sends it to the core processing process module in the institutional sub-account system. Through the above operations, a sub-account request is processed through the institutional sub-account system, open counter system, and exchange system, and the sub-account's fund position information, the institutional account's fund position information, and the institutional transaction code's fund position information are maintained.

[0045] Figure 7 Shows examples of how the institutional sub-account system is deployed within a bank and a futures company. Figure 7 Since the institutional sub-account system is a system independent of the open counter system, the deployment method can be Figure 7There are three deployment methods shown. The first method is to deploy the institutional sub-account system and the open counter system simultaneously inside the bank, the second method is to deploy the institutional sub-account system and the open counter system simultaneously inside the futures company, and the third method is to deploy the open counter system in the futures company and the institutional sub-account system in the bank. When institutional users are customers, they do not need to deploy the open counter system in their own environment, and choose the second or third deployment method; when institutional customers are members, they choose the first deployment method and deploy the open counter system and the institutional sub-account system in their own environment. From the above, it can be seen that the institutional sub-account system separated from the open counter system of the present invention can meet the needs of the bank as a member and as a customer at the same time, which is lacking in the existing open counter system.

[0046] Since the business processing is not implemented in the core processing process module of the institutional sub-account system of the present invention, but the business processing dynamic library in the open counter system is directly called, this adds great flexibility to the institutional sub-account system. By loading different business processing dynamic libraries, different businesses can be processed. Multiple quotation processes can be set in the quotation process module of the institutional sub-account system, connecting securities counters, options counters, main counters, etc. The architecture diagram is shown in Figure 8 , and it can be easily expanded to other counters in the future. For different businesses such as securities business, options business, futures business, and gold exchange business, the business processing can be extracted into dynamic libraries just like the business dynamic library libtrade.so of the main counter. In the core processing process module, only different business dynamic libraries need to be called to realize different businesses.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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. An institutional sub-account system, characterized in that: The system includes a quotation process module, a core processing process module, and a front-end process module, among which: The front-end process module provides the institutional client with the TCP port address for accessing the institutional sub-account system, receives requests from the institutional client and forwards these requests to the core processing module, and receives the response information after request processing sent from the core processing process module and replies to the institutional client; The core processing module is used to complete the funds and positions processing of sub-accounts and their parent accounts; The quotation process module is connected to the front-end process module of the development counter system. When receiving the transaction request sent by the core processing process module of the institutional sub-account system, it establishes the connection between the institutional sub-account system and the open counter system, logs in with the user code in the transaction request, sends the corresponding transaction request to the open counter system, and transmits the feedback of the transaction request from the open counter system to the core processing process module; Among them, the hierarchical correspondence of sub-accounts is saved in the core processing module of the institutional sub-account system. An account includes the corresponding investor code, user code, and transaction code. The transaction code of the institution is jointly operated by the first-level account. The funds and positions of the first-level account are the summary of the funds and positions of the first-level account. A first-level account contains multiple second-level sub-accounts. The multiple second-level sub-accounts have their own funds and positions, which are summarized into the funds and positions of the first-level account. The investor code, user code, and transaction code corresponding to the second-level sub-account are virtual; The core processing module is configured to process sub-account transactions as follows: The core processing module obtains the user code, investor code, and transaction code of the institution's sub-account itself, as well as the user code, investor code, and transaction code of all upper-level accounts of the institution's sub-account, according to the hierarchical correspondence of the institution's sub-accounts; For the sub-account of the institution and all its associated upper-level accounts, the business processing dynamic library in each account is called through the open counter system to process funds and positions, so that the fund changes caused by the trading operations of the lower-level trader accounts can be reflected in the upper-level accounts at the same time; When the fund processing of the institutional sub-account and its upper-level account is completed, the operation information of the upper-level account is sent to the quotation process module. The operation information of the institutional sub-account is only stored in the core processing process module of the institutional sub-account system; When the core processing module receives the response to the transaction request transmitted by the quotation process module from the open counter system, it performs fund and position operations on the sub-accounts at all levels.

2. The institutional sub-account system according to claim 1, characterized in that: The core processing process module of the institutional sub-account system directly calls the business processing dynamic library in the core processing process module of the open counter system to perform business processing.

3. The institutional sub-account system according to claim 2, characterized in that: When there are changes in the core business of fund and position processing, the business processing dynamic library in the open counter system is updated without changing the core processing process module of the institutional sub-account system.

4. The institutional sub-account system according to claim 2, characterized in that: When the number of levels of institutional sub-accounts increases, the core processing module of the institutional sub-account system increases the number of calls to the business processing dynamic library.

5. The institutional sub-account system according to claim 1, characterized in that: The deployment methods of the institutional sub-account system and the independent open counter system include any of the following three methods: the first is to deploy the institutional sub-account system and the open counter system simultaneously within the bank, the second is to deploy the institutional sub-account system and the open counter system simultaneously within the futures company, and the third is to deploy the open counter system in the futures company and the institutional sub-account system within the bank.

6. The institutional sub-account system according to claim 1, characterized in that: Multiple quotation processes are further set in the quotation process module for connecting financial business counters including securities counters, options counters, and main counters. Multiple business dynamic libraries are set in the corresponding core processing process module to handle the business operations of the corresponding counters.

Images