TWI836300B - System and method for financial commodity transaction - Google Patents

Abstract

The present invention discloses a system and a method for financial commodity transaction. The method comprises the following steps: sequentially receiving a plurality of customer orders, associated with a plurality of customer accounts, by a distribution module; maintaining a task list, having a first customer order and a second customer order sequentially recorded in a receiving order; determining the status of a plurality of risk control modules; examining the first customer order by a first risk control module when the status of the first risk control module is available; determining whether the second customer order and the first customer order correspond to the same customer account by the distribution module; postponing the second customer order until the first customer order is completed by the first risk control module when the second customer order and the first customer order correspond to the same customer account.

Description

Financial product trading system and method

The present invention relates to a financial product trading system and method, and more particularly to a financial product trading system and method capable of multi-tasking client orders.

Generally speaking, when trading securities or futures, customers need to open a personal account at the business office of a securities firm or futures merchant and put a certain amount of money into the personal account before they can start trading. For example, if the first customer wants to buy or sell a specified commodity, the first customer needs to submit a customer order first, and then the risk control module of the securities firm or futures dealer needs to check the remaining amount in the first customer's personal account. Whether it is enough to buy or sell the specified commodity. When the customer order is verified and passed by the risk control module, the risk control module will generate a corresponding transaction order and request the exchange host to conduct the transaction. Then, the exchange host will report the transaction results to the risk control module, so that the risk control module can update the first customer's information, such as the first customer's holdings and the remaining amount in his personal account.

Those with ordinary knowledge in the relevant technical field can understand that if the risk control module only serves the first customer, then when the risk control module sequentially processes multiple customer orders of the first customer, the first customer will not feel the transaction. Delay occurs. However, if the risk control module wants to serve multiple customer orders from multiple customers at the same time, such as multiple customer orders from the first customer, the second customer, and the third customer, both the second customer and the third customer need to Wait for the risk control module to complete the transaction order for the first customer. In other words, when the risk control module is checking the customer orders of the first customer, it cannot check the customer orders of other customers at the same time. Therefore, the more customers the risk control module serves, the longer the average waiting time of customers should be. . In theory, providing each customer with a corresponding risk control module can solve the problem of waiting for other people's orders, but the cost is very expensive and unrealistic. Accordingly, the industry needs a new financial product trading system and method that does not require high costs and can also reduce the time customers spend waiting for other people's orders.

The invention provides a financial product trading system that can dynamically allocate multiple customer orders to different risk control modules, thereby reducing the time customers spend waiting for other people's orders.

The present invention proposes a financial product trading system, which is electrically connected between a acquiring host and an exchange host. The acquiring host provides multiple customer orders associated with multiple customer accounts, and each customer order corresponds to one of the multiple customer accounts. The financial product trading system includes multiple risk control modules and allocation modules. The multiple risk control modules are electrically connected to the exchange host. The allocation module is electrically connected to the acquiring host and the multiple risk control modules, respectively, to receive the multiple customer orders and maintain a task list, and the task list records the multiple customer orders in the order of receipt. The allocation module determines whether the consecutive first customer order and the second customer order in the multiple customer orders are dependent, and determines the usage status of the multiple risk control modules. The allocation module allocates the first customer order to one of the risk control modules whose use status is idle among the multiple risk control modules, and when the first customer order is dependent on the second customer order, the allocation module postpones the second customer order until the risk control module that receives the first customer order has checked the first customer order.

In some embodiments, when the first customer order and the second customer order are not dependent, the allocation module can allocate the second customer order to one of the risk control modules whose use status is free. In addition, when the first customer order and the second customer order are not dependent, the allocation module can also store the second customer order in the order buffer, and one of the risk control modules whose use status is free among the multiple risk control modules obtains the second customer order from the order buffer. When the allocation module postpones the second customer order, the allocation module can continue to determine whether the consecutive second customer order and the third customer order are dependent.

In some embodiments, each customer order is checked by one of the plurality of risk control modules. When one of the customer orders passes the check, the risk control module of the customer order is checked and the corresponding output transaction is Single to exchange host. Here, the plurality of risk control modules can be further coupled to a synchronization module, and the synchronization module is used to synchronize the inspection process of each risk control module with the plurality of risk control modules. In addition, the allocation module can determine whether the first customer's order and the second customer's order correspond to the same customer account. When the first customer's order and the second customer's order correspond to the same customer account, then the first customer's order corresponds to the same customer account. The order and the second customer order can be considered to be dependent.

The invention provides a financial product trading method that can dynamically allocate multiple customer orders to different risk control modules, thereby reducing the time customers spend waiting for other people's orders.

The present invention proposes a financial commodity trading method, which is used in a financial commodity trading system. The financial commodity trading system includes multiple risk control modules. The financial commodity trading method includes the following steps. First, a distribution module sequentially receives multiple customer orders associated with multiple customer accounts. Then, the distribution module maintains a task list, and the task list records the consecutive first customer order and the second customer order in the multiple customer orders according to the order of receipt by the distribution module. Then, the distribution module determines the usage status of the multiple risk control modules. When the usage status of the first risk control module among the multiple risk control modules is idle, the first risk control module checks the first customer order. Next, the allocation module determines whether the second customer order corresponds to the same customer account as the first customer order. If the second customer order corresponds to the same customer account as the first customer order, the allocation module postpones the second customer order until the first risk control module has checked the first customer order.

In some embodiments, when the second customer order does not correspond to the same customer account as the first customer order, the allocation module may allocate the second customer order to one of the risk control modules whose use status is idle among the multiple risk control modules. In addition, when the second customer order does not correspond to the same customer account as the first customer order, the allocation module may store the second customer order in the order temporary storage area, and then one of the risk control modules whose use status is idle among the risk control modules may obtain the second customer order from the order temporary storage area.

To sum up, the financial product trading system and method proposed by the present invention incorporate an allocation module. The allocation module can selectively allocate multiple customer orders to different risks based on the dependencies between the multiple customer orders. Control modules to reduce the time customers wait for orders from others.

The following will further disclose the features, purpose and function of the present invention. However, what is described below is only an embodiment of the present invention and should not be used to limit the scope of the present invention. That is, any equivalent changes and modifications made within the scope of the patent application of the present invention will still be the gist of the present invention and will not deviate from the spirit and scope of the present invention, so they should be regarded as further embodiments of the present invention.

Please refer to FIG. 1, which is a functional block diagram of a financial product trading system according to an embodiment of the present invention. As shown in FIG. 1, the financial product trading system 1 of the present embodiment is electrically connected between an acquiring host 2 and an exchange host 3, and the financial product trading system 1 can be used in some financial transactions, such as buying or selling securities or futures. Here, the acquiring host 2 can be set up in the business office of each securities firm, and the securities firm can provide software or user interface to the customer, so that the customer can use the software or user interface to give the order to the acquiring host 2. The exchange host 3 is the location where the financial products are actually traded, and can usually be set up in an exchange managed by a public department, and this embodiment is not limited. As can be seen from the above, the financial product trading system 1 needs to cooperate with the acquiring host 2 and the exchange host 3, and the purpose is to ensure the stable operation between the acquiring host 2 and the exchange host 3. Since financial product transactions are mostly online transactions, although FIG. 2 shows that there is a solid line connection between the trading system 1, the acquiring host 2 and the exchange host 3, this embodiment does not limit the connection method of the financial product trading system 1, the acquiring host 2 and the exchange host 3, for example, this embodiment does not limit whether there is a physical transmission cable connecting each component.

The financial product trading system 1 includes a risk control module 10 (first risk control module), a risk control module 12 (second risk control module), an allocation module 14 and a synchronization module 16 . The risk control module 10 and the risk control module 12 are electrically connected to the allocation module 14 and the exchange host 3 respectively, and the allocation module 14 is not only electrically connected to the risk control module 10 and the risk control module 12, but is also electrically connected. Acquiring host 2. In one example, the acquiring host 2 will receive multiple customer orders from multiple customer accounts, and then will sort and transfer the multiple customer orders to the allocation module 14 . Although FIG. 2 shows that the allocation module 14 corresponds to two risk control modules (the risk control module 10 and the risk control module 12 ), this embodiment does not limit the number of risk control modules corresponding to the allocation module 14 . Here, the risk control module 10 and the risk control module 12 may have the same specifications. In practice, the risk control module 10 and the risk control module 12 should maintain the same data, such as the customer's review process or financial product files. This embodiment demonstrates that the synchronization module 16 is used between the risk control module 10 and the risk control module 12 to complete the synchronization of the above transaction process or financial product files, but it is not limited to this. For example, it is possible for the risk control module 10 and the risk control module 12 to directly exchange data without the need for an additional synchronization module 16 .

In a practical example, the distribution module 14 may receive multiple customer orders from the acquiring host 2 and maintain a task list. The content of the task list may be the customer orders received in sequence from the acquiring host 2. Here, the task list may be as shown in Table 1 below. The task list records six customer orders, and the numbers of these six customer orders may be generated by the distribution module 14 according to the order of receipt. No. Customer Account 01 A 02 A 03 B 04 B 05 B 06 C Table I

It can be seen from Table 1 that the customer orders numbered 01 and 02 are issued by customer account A (the first customer account), and the customer orders numbered 03, 04 and 05 are issued by customer account B (the second customer account). That is to say, customer orders numbered 01 and 02 are associated with customer account A, customer orders numbered 03, 04, and 05 are associated with customer account B, and customer orders numbered 06 are associated with customer account C. This embodiment does not limit the content of the customer order. For example, the customer order may also include instructions indicating the type of transaction and the financial product to be traded. In addition, this embodiment does not limit the number of customer accounts. Table 1 is only for convenience of example. In fact, the number of customer accounts allocated to the module 14 can be more than two.

In addition, the allocation module 14 can also determine the usage status of all risk control modules at any time, such as the usage status of risk control module 10 and risk control module 12. Assuming that risk control module 10 and risk control module 12 are both in an idle state at the beginning, the allocation module 14 can first allocate the customer order numbered 01 to one of the idle risk control modules, such as risk control module 10. At this time, the risk control module 10 can start to check the content of the customer order and perform subsequent operations (such as placing a transaction order to the exchange host 3). Since the customer order numbered 01 has been allocated, the allocation module 14 defaults to processing the customer order numbered 02 in sequence.

In practice, when processing each customer order, the allocation module 14 will check whether the current customer order is dependent on the previous customer order. Taking the allocation module 14 processing the customer order number 02 as an example, the allocation module 14 will check the customer account corresponding to the customer order number 01, such as customer account A. Next, the allocation module 14 will check the customer account corresponding to the customer order number 02, for example, it is still customer account A. At this time, the allocation module 14 will determine that the customer order numbered 01 and the customer order number 02 are dependent, so the allocation module 14 will first postpone the customer order numbered 02, and skip the customer order numbered 02 Order to process customer order number 03. One of the reasons is that the customer order numbered 01 is a transaction required by customer account A. It needs to wait for the risk control module 10 to pass the verification (for example, placing a transaction order to the exchange host 3) before the latest order of customer account A can be calculated. Information (such as margin amount, etc.). In practice, if the customer order number 02, which is also customer account A, is assigned, for example, to risk control module 12, then risk control module 12 still needs to wait for risk control module 10 to update the latest information of customer account A. , so there is no need to process the customer order number 02 immediately. In other words, the purpose of postponing the customer order numbered 02 is to prevent the risk control module 10 and the risk control module 12 from using the data of customer account A at the same point in time, resulting in margin calculation errors or other transaction risks. Based on the above, this embodiment allows the allocation module 14 to skip the customer order numbered 02 to process the next customer order, so as to prevent other risk control modules from waiting needlessly.

After the allocation module 14 determines that the customer order No. 02 needs to be postponed, the allocation module 14 will continue to check the customer account numbers corresponding to the customer order No. 02 and the customer order No. 03. At this time, since the customer order order numbered 03 corresponds to customer account B, it is determined that the customer order order numbered 02 and the customer order order numbered 03 are not dependent. In one example, because the risk control module 10 is processing customer order number 01, the allocation module 14 can determine that the usage status of the risk control module 10 is busy. On the contrary, another risk control module 12 has not been assigned a customer order (no customer order is being processed), and the allocation module 14 can determine that the usage status of the risk control module 12 is idle. Here, the allocation module 14 can allocate the next customer order numbered 03 to the risk control module 12 . It is worth mentioning that, assuming that the risk control module 10 has completed checking the customer order number 01 at this time (for example, placing a transaction order to the exchange host 3), then the allocation module 14 will reprocess the delayed number. 02 customer order. In the above situation, since the risk control module 12 is processing the customer order number 03, the allocation module 14 will determine that the usage status of the risk control module 10 is idle and the usage status of the risk control module 12 is busy, and thereby allocate Module 14 will assign customer order number 02 to risk control module 10.

Similar to the above example, since both customer orders No. 04 and No. 05 correspond to customer account B, the allocation module 14 can determine that there is a dependency between customer orders No. 03 and No. 04, and there is also a dependency between customer orders No. 04 and No. 05. Accordingly, when customer orders No. 03 have been allocated to the risk control module 12, and the risk control module 12 has not yet completed the review of customer orders No. 03, the allocation module 14 will postpone the processing of the next customer orders No. 04 and No. 05. In one example, the allocation module 14 will then determine whether there is a dependency between customer orders No. 05 and No. 06. Because the customer order number 06 and the customer order number 05 correspond to different customer accounts, the allocation module 14 can determine that the two are not dependent on each other, and thus can select the currently idle risk control module to allocate the customer order number 06.

Following the above example, assume that the risk control module 10 has a customer order numbered 02 that is still being processed, and the risk control module 12 also has a customer order numbered 03 that is still being processed. At this time, if the financial product trading system 1 also includes other risk control modules (the third risk control module), the allocation module 14 can allocate the customer order numbered 06 to the other risk control modules. If the financial product trading system 1 only has the risk control module 10 and the risk control module 12, the allocation module 14 will suspend the allocation number 06 and subsequent customer orders because the usage status of all risk control modules is busy.

In an example, assume that the risk control module 10 checks that the customer order No. 01 is passed and places a transaction order to the exchange host 3. After completing the transaction specified in the transaction order, the exchange host 3 generates a return message based on the transaction results. The return message can be directly transmitted from the exchange host 3 to the allocation module 14, and then the allocation module 14 transmits it to the risk control module 10 and the risk control module 12 for those whose usage status is idle. In practice, the allocation module 14 can add the report messages to the task form according to the order in which the report messages are received, and then the allocation module 14 adds the report messages according to the usage status of the risk control module 10 or the risk control module 12 Allocate idle ones to the risk control module 10 or the risk control module 12 . That is to say, the task form in this embodiment does not necessarily only contain customer orders, but may also contain report messages or other messages.

In the above example, the allocation module 14 actively allocates customer orders to multiple risk control modules, but this embodiment is not limited to this. For example, the financial product trading system 1 may also have an order temporary storage area (not shown in the figure). The order temporary storage area may be in a dedicated memory block in the allocation module 14 or in the synchronization module 16 A dedicated memory block, or in any risk control module. This embodiment does not limit the physical location of the order temporary storage area. In practice, the function of the order temporary storage area is to store customer orders identified by the allocation module 14 . Taking the task form in Table 1 as an example, the allocation module 14 can add customer order numbers 01, 02, and 06 to the header of the risk control module 10 . Similarly, the allocation module 14 can add customer order numbers 03, 04, and 05 to the header of the risk control module 12 . Then, the allocation module 14 sequentially stores the customer orders numbered 01 to 06 into the order temporary storage area. In one example, when the usage status of the risk control module 10 is idle, the risk control module 10 will go to the order temporary storage area to sequentially retrieve customer orders belonging to its own header. For example, the risk control module 10 will sequentially capture customer orders numbered 01, 02, and 06. Similarly, when the usage status of the risk control module 12 is idle, the risk control module 12 will also go to the order temporary storage area to sequentially grab customer orders belonging to its own header. For example, the risk control module 12 will sequentially capture customer orders numbered 03, 04, and 05.

In order to illustrate the financial product trading method of the present invention, please refer to FIG. 1 and FIG. 2 together. FIG. 2 is a step flow chart of the financial product trading method according to an embodiment of the present invention. As shown in the figure, in step S40 , the allocation module 14 sequentially receives multiple customer orders associated with multiple customer accounts. Next, in step S41, the assignment module 14 maintains a task form (as shown in Table 1). The task form records the consecutive first customer order and the second consecutive customer order among the plurality of customer orders according to the order received by the assignment module 14. Customer orders (such as customer orders numbered 01 to 06). Next, in step S42, the allocation module 14 determines the usage status of the plurality of risk control modules (risk control module 10 and risk control module 12). In step S43, when the usage status of the risk control module 10 (the first risk control module) among the plurality of risk control modules is idle, the risk control module 10 checks the first customer order. Next, in step S44, the allocation module 14 determines whether the second customer order corresponds to the same customer account as the first customer order. In step S45, when the second customer order (for example, customer order numbered 02) and the first customer order (for example, customer order numbered 01) correspond to the same customer account (for example, both customer account A), then The allocation module 14 postpones the second customer's order until the risk control module 10 completes checking the first customer's order.

To sum up, the present invention provides that the financial product trading system and method proposed by the present invention are added with an allocation module. The allocation module can selectively allocate multiple customer orders to based on the dependencies between the multiple customer orders. Different risk control modules can reduce the time customers wait for other people's orders.

1: Financial commodity trading system 10: Risk control module 12: Risk control module 14: Allocation module 16: Synchronization module 2: Acquisition host 3: Exchange host S40~S44: Step flow

FIG. 1 is a functional block diagram of a financial product trading system according to an embodiment of the present invention.

FIG. 2 is a flowchart illustrating the steps of a financial product trading method according to an embodiment of the present invention.

S40~S45: step process

Claims (10)

A financial product trading system electrically connected between an acquiring host and an exchange host. The acquiring host provides multiple customer orders associated with multiple customer accounts, and each customer order corresponds to some customers. One of the accounts in the financial instrument trading system includes: Multiple risk control modules are electrically connected to the exchange host; and A distribution module, electrically connected to the acquiring host and the risk control modules respectively, for receiving the customer orders and maintaining a task form, which records the customer orders according to the order of receipt; The allocation module determines whether a consecutive first customer order and a second customer order among the customer orders are dependent, and determines the usage status of the risk control modules; The allocation module allocates the first customer order to one of the risk control modules whose use status is idle, and when the first customer order and the second customer order have the same Dependency, the allocation module delays the second customer order until the risk control module that receives the first customer order has completed checking the first customer order. The financial product trading system as described in claim 1, wherein when the first customer order and the second customer order are not dependent, the allocation module allocates the second customer order to the risk control modules. Use one of the risk control modules in the group that is idle. A financial instrument trading system as described in claim 2, wherein when the first customer order and the second customer order are not dependent on each other, the allocation module stores the second customer order in an order buffer, and one of the risk control modules whose use status is idle obtains the second customer order from the order buffer. A financial instrument trading system as described in claim 1, wherein each of the customer orders is checked by one of the risk control modules, and when one of the customer orders passes the check, the risk control module that checks the customer order outputs a corresponding transaction order to the exchange host. The financial product trading system of claim 1, wherein the risk control modules are further coupled to a synchronization module, and the synchronization module is used to synchronize a verification process of each risk control module with the Risk control module. The financial product trading system of claim 1, wherein the allocation module determines whether the first customer order corresponds to the same customer account as the second customer order. When the first customer order corresponds to the third customer order, If two customer orders correspond to the same customer account, then the first customer order and the second customer order are dependent. The financial product trading system as described in claim 1, wherein when the allocation module postpones the second customer order, the allocation module continues to determine whether the consecutive second customer order and a third customer order have interdependence. A financial product trading method, used in a financial product trading system. The financial product trading system includes multiple risk control modules. The financial product trading method includes: A distribution module sequentially receives multiple customer orders associated with multiple customer accounts; The allocation module maintains a task form, which records a consecutive first customer order and a second customer order among the customer orders according to the reception order of the assignment module; The allocation module determines the usage status of the risk control modules; When the usage status of a first risk control module among the risk control modules is idle, the first risk control module checks the first customer order; The allocation module determines whether the second customer order corresponds to the same customer account as the first customer order; and When the second customer order corresponds to the same customer account as the first customer order, the allocation module delays the second customer order until the first risk control module completes checking the first customer Order form. A financial instrument trading method as described in claim 8, wherein when the second customer order and the first customer order do not correspond to the same customer account, the allocation module allocates the second customer order to one of the risk control modules whose use status is idle. A financial instrument trading method as described in claim 8, wherein when the second customer order and the first customer order do not correspond to the same customer account, the allocation module stores the second customer order in an order buffer, and then one of the risk control modules with an idle status obtains the second customer order from the order buffer.