JP2009009613A - Transaction system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem that with respect to one piece of order information in securities transaction, reception, confirmation of transaction condition, conclusion of the transaction and transmission of the results are executed serially, so that when orders for a certain stock are concentrated to increase the transaction, therefore, the transaction is not smoothly executed, or in some cases, causing system down. <P>SOLUTION: A transaction system is configured so as to divide a transaction including a plurality of transaction requests in predetermined units and process each transaction (including sub-application units for the processing) in parallel. The units include a brand, terminal, market, server or the like. When the division is performed, the results of the respective divided transactions (sub-transactions) are stored in a database in the predetermined units, and the results stored in the database are transferred between the sub-transactions in response to transmission and reception of a message, so that the sub-transactions are processed in parallel in sequence. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a technique for realizing a transaction of commodities including securities such as stocks. In particular, the present invention relates to a securities trading system used in an exchange called a so-called securities market, a method thereof, and a program therefor.

  Conventionally, in transactions including securities transactions, order information is received, and the order information is compared with each other, and the transaction is established depending on whether or not the transaction conditions are satisfied (Patent Document 1). More specifically, securities trading order information and transaction information input from the input device 32 are stored in the transaction storage device 34 and the contract storage device 36 via the control device 33. The order information and transaction information are transmitted to the customers 10 and 20 through the order information transmission unit 35 and displayed on the display device 12. When the transaction is established, the transaction establishment information is transmitted via the transaction establishment information transmitting unit 37, displayed on the display device 12, and a warning sound is emitted from the speaker 13. When the transaction content is confirmed, the order information and the transaction establishment information are deleted, and the customer identification information, the order information, and the transaction information are stored in the contract storage device 36.

JP 2001-297195 A

  However, in Patent Document 1, each process of reception, transaction condition confirmation, transaction establishment, and result transmission is executed serially for one order information. For this reason, in Patent Document 1, there is a problem that the transaction processing does not flow smoothly when the transaction volume increases, such as when orders of specific brands are concentrated, or the system is down in some cases.

  Therefore, in the present invention, a so-called transaction (a plurality of transaction requests) is divided into predetermined units, and each processing (including sub-operation units for processing) is executed in parallel processing. Further, the present invention includes those that guarantee the order when such division is performed. For example, storing the progress of the process in the database for each process and step is included. The predetermined unit includes a brand, a terminal, a market, a server, and the like.

  More specifically, in a securities trading system that is connected to a plurality of trading terminals that issue securities trading orders and executes the trading of the orders, the order acceptance processing is performed, and the orders for which the acceptance processing is completed are stored in the requirement database. A plurality of accepting means for transmitting to the transaction terminal that the order acceptance has been completed, each accepting means for determining the order processing to be processed based on the transaction terminal, and each to be processed Among a plurality of registration processing means whose brands are determined in advance, out of the orders for which the reception process is completed, the order of the brand to be processed by the registration processing means is read from the requirement database, and the requirement is set as a transactionable state. A registration processing means for registering in the database, and reading out the registered order from the requirement database, and confirming that the readout order has been registered A plurality of registration notifying means for notifying the pulling terminal, each of which an order to be notified is determined based on the transaction terminal; If there is an order to be fulfilled, a fulfillment process is performed and registered in the requirement database as a fulfilled order. A plurality of execution notification means for reading a completed order and notifying the transaction terminal that the read order has been completed, and an execution notification means for determining the order to be notified by each transaction terminal based on the transaction terminal The registration processing means and the contract processing means of one of the plurality of brand registration processing means and the plurality of contract processing means are processed by Should stocks are securities trading system, characterized in that it is set so as not overlap. Further, the present invention includes each device (server) and method constituting this system, and a program for realizing this.

Further, the present invention includes the following configurations.
In order for the correspondence relationship between each transaction terminal and the group to be obtained, this includes adding the paired information at the reception device and using it. Here, the information to be paired includes information for identifying each brand and information indicating a correspondence relationship between the brand groups.

  According to the present invention, it is possible to perform parallel processing in each process including a sub-business unit, and it is possible to further enhance the expandability of the system.

  Embodiments of the present invention will be described with reference to the drawings. Although this embodiment will be described by taking an example of securities (stock) transactions, the present invention is not limited to this.

  First, transaction division processing, which is the basic content of the present embodiment, will be described with reference to FIG. As shown in FIG. 6, a transaction is divided into sub-business units, which are executed in parallel in the sub-business units as shown in the lower part of FIG. 6, thereby realizing (pseudo) parallel processing such as pipeline processing. . For each sub-task, the order reception process, transaction process, order notification process, etc. shown in the upper part of FIG. 6 are examples.

  Next, the outline (concept) of the present embodiment will be described with reference to FIGS. As a premise of the processing of the present embodiment, it is necessary to guarantee the order of transaction processing for each brand, and to manage order reception and reception / contract notification for each terminal. This is as shown in FIG. Based on the above assumption, the terminal and the brand are assumed to be processing units of each processing as shown in FIG.

In addition, in this premise, the cause of process waiting includes waiting time between processes with different processing units (for example, order reception to transaction processing control 1).
Next, the concept of waiting between processes with different processing units will be described with reference to FIG. As an example of processing with different processing units, transaction processing control 1 from order reception will be described as an example. Since the order receiving process needs to be a terminal unit and the transaction process control 1 needs to be a brand unit process, the following process is executed.
Order reception: Checks whether the corresponding terminal is receiving an order so that a plurality of processes do not simultaneously process from the same terminal. The number of processes (processing multiplicity) for each terminal group can be set.
Transaction processing control 1: The number of processes for each brand group is set to 1, and serial processing is performed for each brand group.

  With this control, order acceptance is assured for each terminal, and transaction processing control 1 is assured for each brand.

  As shown in FIG. 13, the order acceptance and the transaction processing control 1 are different in terminal, brand and processing unit, respectively. Therefore, waiting occurs in the following cases.

As shown in FIG. 14, a case where an order is made for the same brand C (brand group 1) from the terminal A and the terminal B will be described. Since the transaction processing control 1 needs to serially process for each brand, for example, when the order of the terminal A arrives early with respect to the transaction processing control 1 and the order of the terminal B arrives later, Until the order transaction processing control 1 is completed, the order processing from the terminal B waits. In this way, a wait occurs when the transaction processing control 1 is taken out from the message queue (MQ). The waiting time is that the arrival of an order from the terminal follows a Poisson distribution, and the processing time and process utilization rate of the transaction processing control 1 And the number of windows (1 in the above example) using queue theory. When calculating the response time, this wait time is taken into account for evaluation. This content will be described as a second embodiment with reference to FIGS.

  Next, FIG. 1 shows a system configuration diagram according to the present embodiment. Each computer is connected to each other via a network. Each computer has a processing device such as a memory, a storage device including a hard disk, and a CPU, and the processing device executes information processing according to a program stored in the storage device. As shown in FIG. 1, the system in the present embodiment includes a transaction terminal 1, a reception device 2, a transaction processing device 3, a contract processing device 4, and a storage device group 5 in which information related to transactions is stored. Each of these structural requirements is composed of a plurality of components. (1) Transaction terminal 1 may be a group of a plurality of transaction terminals. (2) In addition, acceptance device 2, transaction processing device 3. The contract processing device 4 is configured as an integrated server device as hardware, and each may be configured as software having the function. In the case of (2), the reception device 2 and the transaction processing device 3 may be integrated, and the transaction processing device 3 and the contract processing device 4 may be integrated. In the present embodiment, as shown in FIG. 2, an example in which the contract processing device 4 and the transaction processing device 3 are integrated will be described. 1 and 2, each receiving device 2 (21, 22) is associated with each group of transaction terminals (such as a securities company). In addition, each transaction processing device 3 and each contract processing device 4 (or processing devices 31 and 32 in which these are integrated) are associated with each brand to be processed, and processing for transaction requests of this correspondence relationship Execute. This correspondence may be included in software instead of the device, that is, hardware. Furthermore, this correspondence may be changed dynamically based on conditions such as the transaction volume. In other words, when a certain number (volume) of transaction requests from a group or a certain brand is (increased), a given device (for example, the same type of device with the least number of transaction requests, computer resources) You may make it perform the process of the group (or brand). In addition, in the same type of device, it is detected whether the relationship between transaction requests (or the amount of calculation associated therewith) satisfies a certain relationship (difference is greater than a threshold or a predetermined relationship such as 1:10). Thus, changing the correspondence (changing a device with a small number of transaction requests to a device with a large number of transaction requests) is also included in the present embodiment.

Hereinafter, the processing content of this Embodiment is demonstrated.
First, the transaction processing procedure according to the first embodiment of the present invention will be described with reference to FIG. In step 101, the accepting devices 21 and 22 execute an order accepting process for accepting an order from the corresponding transaction processing device. Here, the accepting device 21 receives a transaction request including information identifying the specified brand, the type of sale, the desired amount, the number of shares, and the requester (transaction terminal (group)) from the transaction processing device. In order to receive a corresponding transaction request, transaction terminals (groups) physically corresponding to each other may be connected as shown in the figure, or a corresponding reception device is identified from the transaction terminal, and the identified reception device You may make it transmit a transaction request to address. Further, filtering processing may be performed on the reception device side so as to receive only the corresponding transaction terminal (group).

  In the same step 101, the input message, that is, the transaction request is checked. This check is to determine whether or not the reception has been successful depending on the failure occurrence state on the communication path.

  The receiving apparatus 2 includes the following processing in step 101 in the present embodiment. First, information for identifying a requester included in a transaction request as a premise is information for specifying a transaction terminal. Here, the accepting device 2 searches the terminal-terminal group identification table for information identifying the terminal group corresponding to this information as a key. Then, the retrieved information is included in the transaction request and subsequent processing is executed. In addition, it is also possible to search for information for identifying a brand group from the brand-brand group identification table shown in FIG. 7 using one of the trading machines as a key, and to include the retrieved information in the transaction request. It is included in the embodiment. The information newly added in this way is used when specifying a group (or brand, end of column) in each process or the like.

  Then, the process proceeds to step 102, and each of the accepting devices transmits the check result of step 101 to the transaction terminal that transmitted the transaction request. If it is determined that it has been received normally, a normal acceptance response is transmitted to the transaction terminal. Then, the received transaction request is stored in the requirement DB 51. In this case, the transaction status is stored in association with each transaction request. Here, information indicating “reception” is stored. Furthermore, you may store in requirement DB corresponding to every "trade brand" included in a transaction request. For example, the transaction request for the “a” brand is stored in the requirement DB 51-a. The requirement DB is stored in the storage device group 51. Each requirement DB 51 (51-a, 51-b) may be physically stored in the same medium.

  Next, in step 103, each of the transaction apparatuses 31 and 32 (using a transaction processing program) extracts a transaction request of “brand” corresponding to itself from the requirement DB 51 whose transaction status is “accepted”. This extraction is realized by sending the transfer queue to the processing devices 31 and 32 corresponding to each “trade brand” in conjunction with the registration in the requirement DB 51 (when a certain number of the same brands are registered). May be. Further, the processing devices 31 and 32 may search the requirement DB 51 corresponding to themselves at a predetermined timing including every predetermined time for a transaction request of “acceptance”, or may be registered from the accepting device. The requirement DB may be searched by using the information to be shown as a trigger. Further, this trigger may be executed by detecting that the number of transaction requests for the same “brand” has reached a certain number. The registration in the requirement DB may be registered in the requirement DB for each “brand” (the same applies hereinafter).

  And the transaction processing which puts the extracted transaction request on what is called a board is performed. That is, the transaction state is changed. Details of this processing will be described later with reference to FIGS. When this process is executed, the requirement DB transaction status is registered to be changed from “reception” to “transaction”.

  Next, in step 104, each of the transaction apparatuses 31 and 32 adds an order acceptance number for identifying the transaction request to the transaction request and stores it in the requirement DB. Then, using this registration or time, the number of registrations, etc. as a trigger, each accepting device receives a transaction request indicating that it is a “transaction terminal (group)” corresponding to itself from the requirement DB and the transaction status indicates “transaction”. The order acceptance number is notified to the transaction terminal that has extracted and transmitted the transaction request.

  Next, in step 105, each of the transaction devices 31 and 32 (using the contract processing program) extracts a transaction request of “brand” corresponding to itself from the requirement DB 51 with the transaction status “transaction”. . This extraction may be performed by the same process as in step 103. Then, “contract processing” is executed for the extracted transaction request. That is, it is detected whether there is a transaction request corresponding to the extracted transaction request (indicating that the buying and selling is the opposite, corresponding to the price and the number of shares). Since this process is normally performed, detailed description thereof is omitted.

  Next, proceeding to step 106, each of the transaction processing devices 31 and 32 executes (using a contract processing program) whether or not the contract is established by the contract processing in step 105 (whether the corresponding transaction request has been detected). The result is stored in the requirement DB in association with the corresponding transaction request, and if a contract is established, the process proceeds to step 107, and if no agreement is established, the process proceeds to step 108. In step 106, when the contract is established, “transaction” in the requirement DB is changed to “contract”, and when the agreement is not established, “transaction” is changed to “uncommitted”.

  Next, in step 107, using this registration or time, the number of registrations, and the like as a trigger, each receiving device is a “transaction terminal (group)” corresponding to itself from the requirement DB, and the transaction status is “contract”. Is extracted, and a contract notification including a contract number for specifying the contract is transmitted to the transaction terminal that transmitted the transaction request. Then, the process proceeds to Step 107.

  Next, in step 108, each of the transaction devices 31 and 32 (using a transaction processing program) creates and transmits external output information to be transmitted to a market system (not shown) or the like. Here, as described above, transaction requests for “brands” corresponding to themselves are extracted as “contract” or “uncommitted”, and this processing is executed for these.

  Next, details of steps 101 to 103 (particularly 103) will be described with reference to FIGS. First, an example of a case where normal processing can be performed will be described with reference to FIG.

  First, details of steps 101 and 102 will be described. Steps 101 and 102 (that is, the detailed processing described below) are executed in units of “groups”. This is as described above.

  In step 1011, the transmitted transaction request is received, and in step 1012, the input message, that is, the transaction request is checked as described above. This check is to determine whether or not the reception has been successful depending on the failure occurrence state on the communication path. If it is determined that it is not normal, the process proceeds to step 1021, and if it is determined that it is normal, the process proceeds to step 1022.

  In step 1021, an error (notifying that it has not been received normally) is notified to the transmitting transaction terminal. In step 1022, registration is performed for the received transaction request and the requirement DB provided for each “brand”. That is, it registers in requirement DB corresponding to the "brand" of the received transaction request. At this time, “reception” is changed to “transaction” and registered.

  Next, in step 1023, the fact that the reception has been normally performed is transmitted to the transaction terminal. In step 1024, a transfer queue (MQ) is generated and used as a processing trigger in the transaction apparatus 31 or the like. Here, it may be generated for each “brand”. As described above, the generation of this transfer queue (or notification to the processing device) is the predetermined timing including every fixed time, and registration in the requirement DB in the receiving device (including a certain number of transaction requests for the same “brand”). May be detected and executed.

  Next, details of step 103 will be described. Note that step 103 (that is, the following detailed processing) is executed in units of “brand”. This is as described above. In step 1031, transaction information of “brand” corresponding to itself is extracted from the requirement DB. In step 1032, confirmation processing is performed to check whether each item of the extracted transaction request is missing, or whether the quantity corresponds to the number of issues.

  If it is determined in step 1033 that there is an error (that is, it is determined to be incorrect), the process proceeds to step 1034 to perform error processing. That is, a notification of an error is executed to the transaction terminal.

  If it is determined to be normal, the process proceeds to step 1035. In step 1035, “plate registration processing” is performed. As an aspect of the board registration process, a flag indicating that the transaction is possible is included in the requirement DB. Further, registration in the order reception / plate DB is also included in one aspect of the present embodiment. Further, a combination of these may be used.

  Next, in step 1036, the fact that the board registration process has been executed is registered in the corresponding “brand” requirement DB. Then, the process proceeds to step 1037, and a notification to the effect that the order has been successfully received is executed to the transaction terminal. In step 1039, as in step 1024, a transfer queue (MQ) is generated and used as a processing trigger in the transaction apparatus 31 or the like. Here, it may be generated for each “brand”. As described above, the generation of this transfer queue (or notification to the processing device) is the predetermined timing including every fixed time, and registration in the requirement DB in the receiving device (including a certain number of transaction requests for the same “brand”). May be detected and executed.

  Next, the processing in the case of abnormal termination will be described using FIG. 5 (in the case of abnormal termination in the middle of step 103). Basically, the same processing as in FIG. 4 is executed. If an abnormal end is detected, the processing request is re-executed. Specifically, it is realized by reading from the requirement DB the same data as the transaction request that ended abnormally.

  Note that, as described above, a plurality of types of requirement DBs such as each brand and each group may be prepared. In this case, control is performed so as to change the transaction status of the other requirement DBs so that the information is consistent with each other, triggered by a change in the processing status (such as “reception” to “transaction” of a requirement DB).

Moreover, as a database group, you may provide the database for performing cooperation of each process in FIG. The requirement DB and these include the following.
Requirement DB: Database requirement DB for storing data for transaction linkage of infrastructure APP (reception → transaction): DB for data linkage between “reception processing → transaction processing”
Requirement DB (transaction → contract): Data linkage DB between “transaction processing → contract processing”
Requirement DB (contract → transaction): DB for data linkage between “contract processing → transaction processing”
Requirement DB (transaction → reception): DB for data linkage between “transaction processing → reception processing”
Business DB: A database required for business.
Order reception / board DB: Stores the results of the transaction processing device. Order history DB: Stores the results of the execution processing device. Note that, according to the embodiment of the present invention described above, by (simulated) parallel processing such as pipeline processing. Throughput can also be improved.

  By adopting the above-described embodiment (distributed processing by grouping), the amount of transactions (calculations) is increased by vertical expansion of each processing device (transaction processing device 3, contract processing device 4). Can also be supported. In addition, the accepting device 2 can cope with an increase in the amount of transactions (calculation) by horizontal expansion by adding (increasing) processing devices (CPU). In addition, in this invention, it is not limited to such an extension, For example, it is good also considering each transaction apparatus as what is called vertical extension, and a reception apparatus being horizontal extension. In addition, each may be a vertical extension and a horizontal extension.

  Next, a second embodiment of the present invention will be described with reference to FIGS.

  In the second embodiment, calculation of response time when the distributed processing in the above embodiment is performed will be described. That is, when distributed processing is performed as in the first embodiment, the response time for each transaction request cannot be calculated immediately. This is because, as shown in FIGS. 10 and 11, since each sub-business process is not executed by one apparatus, it is difficult to calculate the execution time of the whole business process. Note that the response time indicates the time from the start time of the order reception process to the end time of the reception notification process or the contract notification process as shown in FIG.

  Therefore, in the present embodiment, control is performed so that a plurality of processing devices distributes sub-executions that are distributed and are combined as one order reception notification task and are generated as task response information. That is, among the sub-tasks, the start time of the first sub-task and the end time of the last sub-task are recorded, and the difference between them is calculated as the response time. When recording time, information for identifying a transaction (acceptance NO) is recorded in association with it.

  Further, as shown in FIG. 8, the start time of each sub-task and the end time in the last sub-task may be recorded. In this case, it is possible to calculate the response time of the sub-work (including a plurality of sub-work) by extracting the necessary sub-work based on the designation. More specifically, the following processing is executed. The sub service start time and the reception number of order reception are registered in the DB. Also in the subsequent processing, the sub work start time and the reception number are registered in the DB. In the sub-operation “reception notification processing” corresponding to the end of one order reception notification operation, the sub-operation start time and the reception number are registered in the DB in addition to the sub-operation end time after the response to the transaction terminal. Using the receipt number corresponding to one order reception notification job as a key, the response of the order reception notification job is based on the difference between the start time of the first sub-operation “Order reception” and the end time of the last sub-operation “Reception notification processing”. Calculate time.

It is a system configuration figure (1) in this embodiment. It is a system configuration figure (2) in this embodiment. It is a flowchart which shows the content of the process in this Embodiment. It is a flowchart (normal) which shows the detailed process of steps 101-103 in FIG. It is a flowchart (abnormal end) which shows the detailed process of steps 101-103 in FIG. It is a figure for demonstrating the basic processing content of this Embodiment. It is a figure which shows the table which recorded the correspondence of the brand-brand group of this Embodiment. It is a figure which shows the concept of response information. It is a figure which shows the time image of response information. It is a figure which shows the response information object process according to terminal. It is a figure which shows the response information object process according to brand. It is a figure which shows the way of thinking of waiting in embodiment (the 1). It is a figure which shows the way of thinking of waiting in embodiment (the 2). It is a figure which shows the way of thinking of waiting in embodiment (the 3).

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Transaction terminal, 2 ... Reception apparatus, 3 ... Transaction processing apparatus, 4 ... Contract processing apparatus

Claims (10)

A securities trading system connected to a plurality of trading terminals for issuing securities trading orders and executing the trading of the orders, a plurality of receiving devices each of which orders to be processed are determined based on the trading terminals; In a securities trading method using a securities trading system composed of a plurality of transaction processing devices in which issues to be processed are determined in advance and a plurality of contract processing devices in which issues to be processed are determined in advance,
The accepting device performs an accepting process for an order to be processed by the accepting device, registers the order for which the accepting process has been completed in the requirement database associated with the brand of the order, and indicates that the order has been registered. 1 message is sent to the transaction processing device defined as the processing subject of the order brand, and a notification indicating that the acceptance of the order is completed is sent to the transaction terminal,
When the transaction processing apparatus receives the first message, the order of the brand to be processed by the transaction processing apparatus among the orders for which the reception process has been completed is obtained from the requirement database associated with the brand of the order. A contract processing defined as a processing target for the receiving device and the brand of the order, which is registered in the requirement database as a state that can be read and traded, and a second message indicating that the order is registered as a state that can be traded To the device,
When the receiving device receives the second message, it reads out an order to be processed by the receiving device from orders registered as a transactionable state from the requirement database associated with the brand of the order. To notify the transaction terminal that the registered order has been registered,
When the contract processing device receives the second message, there is an order in which a transaction is established with an order registered as a state that can be traded in the requirement database associated with the issue to be processed by the contract processing device. If the establishment process is completed, it is registered in the requirement database as an established order, and a third message indicating that the order has been registered as an established order is sent to the accepting device,
When the receiving device receives the third message, it reads out an order to be processed by the receiving device from orders registered as established orders from the requirement database associated with the brand of the order. , Notify the transaction terminal that the read order has been executed,
The securities transaction method characterized in that a brand to be processed by one of the plurality of transaction processing devices and the plurality of contract processing devices and a brand to be processed by the contract processing device are set so as not to overlap. In the securities trading method according to claim 1,
The first to third messages are transmitted and received by a message queue. In the securities trading method according to claim 1 or 2,
The accepting device is:
From the trading terminal, an order including identification information for identifying the specified brand, buying and selling, desired amount, number of shares and the trading terminal is received,
Determine whether the received order was successfully received,
A securities trading method characterized in that, when it is determined that the information has been successfully received, a transaction status indicating that reception processing is completed is registered in the requirement database in association with the order. In the securities transaction method according to claim 3,
The transaction processing apparatus
From the requirement database, out of the orders associated with the transaction status indicating that the acceptance process has been completed, an order in which the specified brand included in the order matches the brand to be processed by the transaction processing device is extracted.
Determine if the extracted order format is correct,
When it is determined that the transaction status is correct, the securities transaction method is characterized in that the transaction status is updated to information indicating that the transaction status is available. In the securities transaction method according to claim 4,
The contract processing device includes:
From the requirement database, out of the orders associated with the transaction status indicating that the transaction is possible, an order in which the specified brand included in the order matches the brand to be processed by the contract processing device is extracted.
Determining whether there is an order in the requirement database that represents another reverse of the trade included in the extracted order and that corresponds to the desired amount and the number of shares;
If the corresponding order exists, update the transaction status of the corresponding order and the extracted order to information indicating that the contract has been established,
When the corresponding order does not exist, the stock transaction method is characterized in that the transaction status of the extracted order is updated to information indicating that a contract has not been established. A securities trading system connected to a plurality of trading terminals for issuing securities trading orders and executing the trading of the orders, a plurality of receiving devices each of which orders to be processed are determined based on the trading terminals; In a securities trading system composed of a plurality of transaction processing devices in which the brands to be processed are predetermined and a plurality of contract processing devices in which the brands to be processed are predetermined,
The accepting device performs an accepting process for an order to be processed by the accepting device, registers the order for which the accepting process has been completed in the requirement database associated with the brand of the order, and indicates that the order has been registered. 1 message is sent to the transaction processing device defined as the processing subject of the order brand, and a notification indicating that the acceptance of the order is completed is sent to the transaction terminal,
When the transaction processing apparatus receives the first message, the order of the brand to be processed by the transaction processing apparatus among the orders for which the reception process has been completed is obtained from the requirement database associated with the brand of the order. A contract processing defined as a processing target for the receiving device and the brand of the order, which is registered in the requirement database as a state that can be read and traded, and a second message indicating that the order is registered as a state that can be traded To the device,
When the receiving device receives the second message, it reads out an order to be processed by the receiving device from orders registered as a transactionable state from the requirement database associated with the brand of the order. To notify the transaction terminal that the registered order has been registered,
When the contract processing device receives the second message, there is an order in which a transaction is established with an order registered as a state that can be traded in the requirement database associated with the issue to be processed by the contract processing device. If the establishment process is completed, it is registered in the requirement database as an established order, and a third message indicating that the order has been registered as an established order is sent to the accepting device,
When the receiving device receives the third message, it reads out an order to be processed by the receiving device from orders registered as established orders from the requirement database associated with the brand of the order. , Notify the transaction terminal that the read order has been executed,
The securities transaction system, wherein a brand to be processed by one of the plurality of transaction processing devices and the plurality of contract processing devices and the contract processing device is set so as not to overlap. In the securities trading system according to claim 6,
The securities trading system, wherein the first to third messages are transmitted and received by a message queue. In the securities trading system according to claim 6 or 7,
The accepting device is:
From the trading terminal, an order including identification information for identifying the specified brand, buying and selling, desired amount, number of shares and the trading terminal is received,
Determine whether the received order was successfully received,
When it is determined that the information has been received normally, a transaction status indicating that the acceptance process is completed is registered in the requirement database in association with the order. In the securities trading system according to claim 8,
The transaction processing apparatus
From the requirement database, out of the orders associated with the transaction status indicating that the acceptance process has been completed, an order in which the specified brand included in the order matches the brand to be processed by the transaction processing device is extracted.
Determine if the extracted order format is correct,
When it is determined that the transaction status is correct, the securities transaction system updates the transaction status to information indicating that the transaction is possible. In the securities trading system according to claim 9,
The contract processing device includes:
From the requirement database, out of the orders associated with the transaction status indicating that the transaction is possible, an order in which the specified brand included in the order matches the brand to be processed by the contract processing device is extracted.
Determining whether there is an order in the requirement database that represents another reverse of the trade included in the extracted order and that corresponds to the desired amount and the number of shares;
If the corresponding order exists, update the transaction status of the corresponding order and the extracted order to information indicating that the contract has been established,
When the corresponding order does not exist, the stock transaction system is characterized in that the transaction status of the extracted order is updated to information indicating that a contract has not been established.

Images