WO2016207981A1 - 証券取引管理システム - Google Patents

証券取引管理システム Download PDF

Info

Publication number
WO2016207981A1
WO2016207981A1 PCT/JP2015/068073 JP2015068073W WO2016207981A1 WO 2016207981 A1 WO2016207981 A1 WO 2016207981A1 JP 2015068073 W JP2015068073 W JP 2015068073W WO 2016207981 A1 WO2016207981 A1 WO 2016207981A1
Authority
WO
WIPO (PCT)
Prior art keywords
order
information processing
participant
sell
processing system
Prior art date
Application number
PCT/JP2015/068073
Other languages
English (en)
French (fr)
Inventor
角田　充弘
英昭 大坪
秀之助 梶本
吉央 橋本
田中　隆博
侑一郎 下鍜冶
Original Assignee
株式会社野村総合研究所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社野村総合研究所 filed Critical 株式会社野村総合研究所
Priority to JP2017524319A priority Critical patent/JPWO2016207981A1/ja
Priority to CA3026273A priority patent/CA3026273C/en
Priority to PCT/JP2015/068073 priority patent/WO2016207981A1/ja
Publication of WO2016207981A1 publication Critical patent/WO2016207981A1/ja
Priority to US15/852,771 priority patent/US20180122011A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the present invention relates to the technology of securities trading, and more particularly to a technology that is effective when applied to a stock transaction management system that supports dark pool trading.
  • a securities company receives an order for a large number of securities transactions from an asset management company (buy-side) such as an institutional investor and carries out an actual transaction via a market or the like.
  • asset management company buy-side
  • a so-called dark pool service in which trading is performed by matching an investor's buy and sell orders in an information processing system in a sellside, for example, in order to avoid an influence on a deal price by selling and selling large items in a market.
  • the anonymity of order information such as the information and price of the trade participants and the order volume is secured, and improvement of the contract rate and the contract unit price etc. can be expected, the operation plan etc. for buying and selling individual stocks in the fund
  • the use is expanding for institutional investors who want to keep secrets.
  • Patent Document 1 adopts a method of simultaneously transmitting new order information to both the in-house transaction system and the external transaction market system. It describes a mechanism that can reduce the time loss associated with deciding whether to send an order to an internal dark pool or a stock exchange.
  • Patent Document 2 regularly performs matching processing of trading order data at predetermined intervals on the basis of matching logic corresponding to an algorithmic transaction group having plural types of algorithmic transaction types. By doing this, it is described that the order conditions in the dark pool environment improve the execution rate of complicated algorithm orders.
  • each buy-side can trade while securing anonymity of order information.
  • it is difficult to realize a more advanced and expanded mechanism that enhances the fluidity such as cooperation with dark pools provided by other sell-sides, and realization of dark pools in which a plurality of sell-sides participate.
  • matching is performed based on the order actually placed to complete the transaction.
  • future potential orders that the buy-side has as an operation plan can not be matched, and as a result, trading will be performed under conditions that are not necessarily optimal with respect to the trading timing and execution destination. The case is also happening.
  • an object of the present invention is to enable the realization of a dark pool in which a plurality of sell-sides cooperate or a dark pool in which a plurality of sell-sides participate, and further enables stock transaction management that enables matching even for buy-side potential orders. To provide a system.
  • a securities transaction management system is a securities transaction management system for managing securities transactions conducted by Sellside upon receipt of an order from a counterparty, and is a buy-side or a participant who participates in securities transactions.
  • One or more information processing systems including an order management system that manages orders with the other party at the sell side, and information of each participant's IOI (Indication of Interest) acquired from each information processing system in a database And recording a potential order pool system for matching buy and sell among orders included in each of the IOIs.
  • IOI Information of Interest
  • FIG. 1 is a diagram showing an outline of a configuration example of a stock transaction management system according to a first embodiment of the present invention.
  • the stock transaction management system 1 has a configuration in which information processing systems of a plurality of buy-side systems 300, a plurality of cell-side systems 200, and a potential order pool system 100 are connected to a network 10 such as the Internet.
  • the buy-side system 300 is an information processing system including an order management system and the like possessed by each buy-side 30 (operation company and the like)
  • the sell-side system 200 is an information processing system including an order management system and the like possessed by each sell-side 20 (a securities company and the like). It is a system.
  • the potential order pool system 100 is an information processing system operated and managed by a neutral operator independent of each buy side 30 and each sell side 20, and an IOI (Indication, "potential order” from each buy side 30 and each sell side 20) of Interest: Acquire and store information on “display of transaction intention” and match “sell and buy” to complete the transaction “potential order pool (hereinafter sometimes abbreviated as“ POP ”)” service as an ASP Application Service Provider) has a function provided as a service. The contents of the POP service will be described later.
  • each sell side 20 accesses the own cell side system 200 using the Web browser (not shown) of the cell side terminal 21 which is an information processing terminal used by the self, and performs work as the sell side 20. Data may be exchanged by directly accessing the POP system 100.
  • the person in charge of each buy-side 30, etc. accesses the company's buy-side system 300 using the Web browser (not shown) of the buy-side terminal 31 which is an information processing terminal used by itself and performs business as the buy-side 30. . Data may be exchanged by directly accessing the POP system 100.
  • Each of the POP system 100, the cell-side system 200, and the buy-side system 300 is implemented by, for example, one or more server devices or a virtual server built on a cloud computing service. From the point of view of providing a POP service by centrally storing IOI information including “potential order” from buy side 30 and sell side 20, for example, each system is operated by the same IT company on a common system infrastructure ⁇ It is desirable to be monitored, but it is not necessarily limited to this.
  • the sell-side system 200 includes, for example, a sell-side OMS 210, which is an order management system (OMS) on the sell-side 20 side, and a back system 220, which is a back office system.
  • the sell-side OMS 210 also has a function of executing online purchase and sale orders for the exchange system 40 such as the Tokyo Stock Exchange via the network 10 or the like.
  • the buy-side system 300 includes, for example, a buy-side OMS 310 which is an order management system on the buy-side 30 side and a back system 320 which is a back office system.
  • the POP system 100 has data stores such as a potential order pool (POP) database (DB) 121, a buy-side master DB 122, a cell-side master DB 123, and a setting DB 124, which are implemented by, for example, a database or file table.
  • POP potential order pool
  • cell-side master DB 123 cell-side master DB 123
  • a setting DB 124 which are implemented by, for example, a database or file table.
  • Each unit such as a matching processing unit 110 implemented as software having a function of providing a POP service to each buy side 30 and each cell side 20 may be included.
  • the POPDB 121 is a table for holding information of IOI including “potential order” acquired from the cell-side system 200 (or the cell-side terminal 21) or the buy-side system 300 (or the buy-side terminal 31).
  • information of IOI including “potential order” acquired from the cell-side system 200 (or the cell-side terminal 21) or the buy-side system 300 (or the buy-side terminal 31).
  • data that can be shared such as information for which an approval for disclosure has been obtained between the buy side 30 and the sell side 20 may be held.
  • the buy-side master DB 122 and the cell-side master DB 123 are tables that respectively hold master information on the buy-side 30 and the cell-side 20 that can access the POP system 100 and receive provision of the POP service. It may include account information about the user.
  • the setting DB 124 is a table for holding various setting information on operations and processes in the POP system 100. Specific setting information may be held for each of the sell side 20 and the buy side 30.
  • the matching processing unit 110 has a function of acquiring IOI information including “potential order” from each buy-side 30 and each sell-side 20 as a POP service, accumulating, matching sales and buying by a method to be described later, and establishing a transaction. Have. It may have a function to relay and mediate the notification concerning the establishment of the transaction, and the ordering / ordering / subscription process between the buy side 30 and the sell side 20 thereafter.
  • FIG. 2 is a diagram showing an outline of an example of the POP service in the present embodiment.
  • the potential order pool (POP) 120 schematically shows a conceptual dark pool realized by the POPDB 121 of the POP system 100, the matching processing unit 110, and the like.
  • an IOI may be issued to search for a counterparty as useful reference information for closing the transaction.
  • the IOI includes information about the order to be executed, and conditions such as desired or available conditions. Therefore, by using this, it is possible to efficiently match and complete a transaction that has the intention of execution on the day.
  • information of such potential order is also acquired from the buy side 30 as an IOI to form the POP 120, and is made a target of matching as a transaction on that day.
  • each sell-side 20 to issue an IOI to the POP 120 operated and managed by such a neutral enterprise, cooperation of dark pools of a plurality of sell-sides 20 becomes possible, and transparency in dark pool service is realized. It is possible to secure gender, fairness and fairness.
  • the buyside A (30a), the buyside B (30b), the sellside A (20a), and the sellside B (20b) participate in the POP 120, and information of IOI including potential order (in the figure) It shows a state where the IOI 32a, 32b and the IOI 22a, 22b are shown in the respective tables.
  • the POP system 100 acquires IOI information from the buy-side 30 and the sell-side 20 by communication or file transmission / reception, for example, with FIX (Financial Information eXchange) protocol, and stores it in the POPDB 121. I do.
  • FIX Joint Information eXchange
  • the matching algorithm and the like are not particularly limited, and known methods can be used as appropriate.
  • the unit price for matching may be, for example, the previous day closing price of the exchange or the midday closing price. Further, the matching is not limited to between the buy side 30 and the sell side 20, and as described later, it is also possible to match between the buy side 30 and the sell side 20 with each other.
  • the information on the transaction details of the other party notified to the buyside 30 and sellside 20 of the target when the matching is established is anonymous in principle, but, for example, in the case of the other party registered in advance as a supplier in the setting DB 124 or the like. The information on the other party may be disclosed.
  • FIG. 3 is a diagram schematically showing an example of matching between buy side 30 and sell side 20 in POP 120 in the present embodiment.
  • the example of FIG. 3 shows that the buy and sell match for the brand “ ⁇ ” in the IOI 32 a issued by the buy side A (30 a) and the IOI 22 a issued by the sell side A (20 a).
  • information on ordering is transmitted from the buy side system 300 of the buy side A (30 a) to the cell side system 200 of the cell side A (20 a) by a message of the FIX protocol.
  • the sell side A (20a) execution of the order to the exchange system 40 is performed based on the order information.
  • Data relating to a contract is sent to the buy side A (30a) by, for example, exchange of files via the POP system 100 or the like.
  • FIG. 4 is a sequence diagram outlining an example of matching processing between the buy side 30 and the sell side 20 in the POP 120 according to the present embodiment.
  • buy-side 30 i.e., buy-side system 300 or buy-side terminal 31.
  • sell-side 20 i.e., sell-side system 200 or cell-side terminal 21. the same applies hereinafter
  • POP 120 i.e., POP system 100. apply
  • the IOI information is registered by the message or file of the FIX protocol (S01).
  • the POP 120 performs matching at a predetermined timing (S02), and notifies the buyside 30 and the sellside 20 to that effect for the matched transaction (S03).
  • the buy side 30 and the sell side 20 notified of the matching result respectively notify the POP 120 of a response of Ack (acceptance) or Rej (reject) to the matched contents (S04).
  • the POP 120 when any response is Ack, the transaction is determined to be established (S05), and the buy side 30 and the sell side 20 are notified that the transaction has been established (S06). Thereafter, as execution of the established transaction, an order is placed from the buy side 30 to the sell side 20 by the message of the FIX protocol (S07), and the contents of the execution executed in the sell side 20 are notified to the buy side 30 (S08) ).
  • FIG. 5 is a diagram schematically illustrating an example of matching between buy sides 30 in the POP 120 according to the present embodiment. As described above, in the present embodiment, it is possible to match the IOI between the buy sides 30. The example of FIG. 5 shows that the buy and sell match for the brand “ ⁇ ” in the IOI 32 a issued by the buy side A (30 a) and the IOI 32 b issued by the buy side B (30 b).
  • both buy-sides 30 individually perform order processing on predetermined sell-sides 20 each having a deal contract.
  • the buy side A (30a) indicates a case in which an order is placed on the sell side A and the buy side B (30 b) on the sell side B (20 b).
  • the information on the sell side 20 of the ordering party of the buy side 30 of the matched counterpart is added by the buy side system 300 or the POP 120 as the information on the broker (sell side 20) of the cross trading partner.
  • the information on the sell side B (20b) which is the order recipient of the matched buyside B (30b) is added.
  • the sell side 20 which has received the order information can confirm the information of the sell side 20 which is the counterpart of the cross trade, and execute the cross trade with the sell side 20 to the exchange system 40. it can.
  • the notification of the agreement data from each cell side 20 is the same as the example shown in FIG.
  • FIG. 6 is a sequence diagram outlining an example of the matching process between the buy side 30 in the POP 120 in the present embodiment.
  • each buyside 30 (two in the example of FIG. 6, the buyside A (30a) and the buyside B (30b)) registers IOI information in the POP 120 (S11).
  • the POP 120 performs matching at a predetermined timing (S12), and notifies the buy side A (30 a) and the buy side B (30 b) of the matching transaction to that effect (S13).
  • the buy side A (30 a) and the buy side B (30 b) notified of the matching result respectively select a broker (sell side 20) to execute the transaction, and respond Ack (Acknowledgement) or Rej (Reject) to the POP 120
  • the notification is made (S14).
  • the broker here is, for example, a sellside 20 where each buyside 30 has a trading contract.
  • Information on the target cell side 20 may be registered in advance in the setting DB 124 of the POP system 100 as a default value, and a broker may be automatically selected.
  • the POP 120 that receives the broker designation notifies the buy side A (30 a) and the buy side B (30 b) that the transaction is in progress (S15), and each sell side 20 designated as a broker (FIG. 6)
  • a request for cross transaction is made to the cell side A (20a) and the cell side B (20b) (S16).
  • the request includes information related to a cross trade, information on each buyside 30, broker information on a cross partner, and the like.
  • the sell side A (20a) and the sell side B (20 b) that received the cross transaction request respectively notify the POP 120 of a response of Ack (acceptance) or Rej (deny) (S17).
  • the POP 120 determines that the transaction is concluded when all the responses are Ack (S18), and notifies the buyside A (30a) and the buyside B (30b) that the transaction is established (S19).
  • an order is placed from the buy side A (30 a) and the buy side B (30 b) to the cell side A (20 a) and the cell side B (20 b) respectively by messages of the FIX protocol (S20).
  • the contents of the agreement are notified to buyside A (30a) and buyside B (30b) respectively (S22) ).
  • the information required for the cross transaction (S21) may be added to the information at the time of ordering (S20), or the information passed at the time of the cross transaction request (S16) may be used.
  • FIG. 7 is a diagram schematically showing another example of matching between buy sides 30 in the POP 120 according to the present embodiment.
  • commissions are referred to a plurality of sellsides 20 having a deal contract with both buysides 30, and the lowest It shows the case where the sell-side 20 presenting the fee is determined as the supplier. That is, the sell side 20 of the supplier is determined by the “competition fee”.
  • the sell side 20 of the supplier is determined by the “competition fee”.
  • FIG. 8 is a sequence diagram outlining another example of the matching process between buy side 30 in POP 120 in the present embodiment. Similar to the example of FIG. 6 described above, each buyside 30 (two in the example of FIG. 7, the buyside A (30a) and the buyside B (30b)) registers IOI information in the POP 120 (S31) . The POP 120 performs matching at a predetermined timing (S32), and notifies the buy side A (30 a) and the buy side B (30 b) of the matching transaction to that effect (S33).
  • the buy side A (30 a) and the buy side B (30 b) notified of the matching result each notify the POP 120 designating that the broker (sell side 20) to be traded is to be selected based on the commission inquiry (S34) ).
  • the POP 120 that receives the inquiry request notifies the buy side A (30 a) and the buy side B (30 b) that the transaction is in progress (S35), and the sell side 20 (see FIG. In the example of 7, request for commission is made to the sell side A (20a) and the sell side B (20 b) (S36).
  • the inquiry includes information relating to the brand, quantity, and buy and sell buy sides 30 involved in the transaction.
  • the value of BP may be input or set on the cell-side system 200 side each time, or may be registered in advance in the cell-side system 200 or the setting DB 124 of the POP system 100 for each buy-side 30 in advance.
  • it is selected in the sell-side 20 not to participate in the “commission commission” it is also possible to reply to that effect. If there is no response for a certain period of time, it may be automatically treated as non-participation.
  • the list of the conditions presented from each sellside 20 is a buyside A (30a) and a buyside B (30b) To notify (S38).
  • the candidate of the supplier is the sell side 20 with the lowest BP of the fee (the sell side 20 with the earliest time of the condition presentation (step S37) among the same BP), and the buy side 20 is the supplier for the condition.
  • it is determined as (1) that is notified to the POP 120 (S39).
  • the POP 120 that receives the decision notification from each buy side 20 notifies the sell side 20 (the sell side A (20 a in the example of FIG. 8) determined as the ordering party of the transaction establishment (S40), and the other sell side 20 (FIG. 8)
  • the sell side B (20b) is notified of the transaction failure (S41).
  • the buy side 30 can trade on the condition of the favorable fee. Also, the sell-side 20 can participate in a large-order commission competition, and can obtain an opportunity for consignment sale.
  • FIG. 9 is a diagram schematically showing another example of matching between buy side 30 and sell side 20 in POP 120 in the present embodiment.
  • FIG. 9 shows the case of placing an order.
  • the information related to the order is transmitted from the buy side system 300 of the buy side A (30 a) to the cell side system 200 of the cell side B (20 b) by a message of the FIX protocol.
  • the information of the sell-side 20 (the sell-side 20A (20a) in the example of FIG. 9) of the matched counterpart is added by the buy-side system 300 or the POP 120. Therefore, in the sell side B (20 b) that has received the order information, it is possible to confirm the information of the sell side A (20 a) which is the counterpart of the cross trade, and the cross trade with the sell side A (20 a) Can be enforced against
  • FIG. 10 is a sequence diagram outlining an example of matching processing between the buy side 30 and the sell side 20 in the POP 120 according to the present embodiment. Similar to the example of FIG. 4 described above, the buy side 30 and the cell side A (20a) first register IOI information in the POP 120 using a message or file of the FIX protocol (S51). The POP 120 performs matching at a predetermined timing (S52), and notifies the target buyside 30 and the sellside A (20a) of the matching transaction (S53).
  • the buy side 30 that has received the notification of the matching result selects a broker (sell side 20) to conduct a transaction, and designates an Ack (Accept) or Rej (Reject) response to the POP 120 (S54).
  • the broker here is, for example, the sell side 20 (the sell side B (20 b) in the example of FIG. 10).
  • Information on the target cell side 20 may be registered in advance in the setting DB 124 of the POP system 100 as a default value, and a broker may be automatically selected.
  • the cell side A (20a) that has received the notification of the matching result notifies the POP 120 of a response of Ack (acceptance) or Rej (reject) to the matched content (S55).
  • the POP 120 receives an Ack with a broker specification from the buy side 30 and an Ack response from the cell side A (20 a), it makes a cross trade request to the cell side B (20 b) specified as a broker ( S56).
  • the request includes information related to the cross trade, information on the buy side 30, broker information on the cross partner, and the like.
  • the sell side B (20b) that has received the cross transaction request sends a response of Ack (acceptance) or Rej (deny) to the POP 120 (S57).
  • the POP 120 receives the response of Ack, it determines that the transaction has been established (S58), and notifies the buy side 30 and the sell side A (20a) that the transaction has been established (S59).
  • an order is placed from the buy side 30 to the sell side 20 by the message of the FIX protocol (S60), and execution of the cross trade is performed between the sell side A (20a) and the sell side B (20 b).
  • the contents of the agreement are notified to the buy side 30 (S62).
  • the information required for the cross transaction may be added to the information at the time of ordering (S60), or was passed when the cross transaction request (S56) Information may be used.
  • one POPDB 121 is used in the POP system 100 operated and managed by a business operator neutral to the buy side 30 and the sell side 20.
  • the IOI information including the above-mentioned potential order of the buy side 30 and the IOI information of one or more cell sides 20 are accumulated and matched.
  • cooperation of the dark pools of a plurality of sell sides 20 becomes possible, and the buy side 30 can achieve establishment of a transaction under suitable conditions in a wider range.
  • the potential order of the buy-side 30 is also acquired as IOI information, and by performing matching as a target of matching, it is possible to execute at a timing that is a more suitable condition for transactions scheduled to be distributed over a fixed period in the future. It becomes possible.
  • the case where the buy side 30 does not designate the sell side 20 (executing broker) of the execution target hardly occurs normally. Also in the case where matching between the buy side 30 and the sell side 20 in (4) is performed, for example, even if there is no deal contract between the matched buy side 30 and the sell side 20, for example, It is considered natural that a sell-side 20 (executing broker) with a deal contract is designated.
  • FIG. 11 is a sequence diagram outlining an example of matching processing between participants in the POP 120 according to the present embodiment.
  • the process flow is shown for the case of designating an execution broker after matching among the above (A) participants. Basically, it is the same as the processing of matching between the buy sides 30 (cross transaction specifying an execution destination) shown in FIG. May be omitted.
  • the participants in the transaction with the POP 120 are not the buy-side 30 but two of the participants 50 (participant A (50a) and participant B (50b) in the example of FIG. One). Participant 50 may be either buyside 30 or sellside 20.
  • each participant 50 register IOI information in the POP 120 (S71).
  • the POP 120 performs matching at a predetermined timing (S72), and notifies the participant A (50a) and the participant B (50b) of the matching transaction (S73).
  • the processing up to here is the case where the execution broker is specified after matching between the participants shown in the example of FIG. 11 (A) and the processing fee competition for the execution broker after matching between the participants (B) described later. It is common to the case determined by
  • the participant A (50a) and the participant B (50b) that have received the notification of the matching result each select a broker (Sellside 20) to execute the transaction, and Ack (Accept) or Rej A response of (rejection) is notified to the POP 120 (S74).
  • the broker is the sell side 20 in which the buy side 30 has a transaction contract, as described above.
  • the sell side 20 itself is generally the execution target.
  • the participant A (50a) designates the sellside A (20a) as the execution broker
  • the participant B (50b) designates the sellside B (20b).
  • these execution brokers may be the same sell-side 20 in some cases.
  • the POP 120 that receives the broker designation notifies the participants A (50a) and B (50b) that the transaction is in progress (S75), and each sellside 20 (FIG.
  • cross request is made to the cell side A (20a) and the cell side B (20b) (S76).
  • the request includes information related to a cross trade, information on each buyside 30, broker information on a cross partner, and the like.
  • the seller A (50a) designated by the participant A (50a) is requested to make a cross trade for the transaction of the participant A (50a), while the participant B (50b) A request for cross trade is made to the sell side B (20b) designated by the above in relation to the trade of the participant B (50b).
  • the sell side A (20a) and the sell side B (20 b) that received the cross transaction request respectively notify the POP 120 of an Ack (acceptance) or Rej (reject) response (S77).
  • Ack acceptance
  • Rej reject
  • FIG. 12 is a sequence diagram outlining another example of matching processing between participants in the POP 120 according to the present embodiment.
  • the flow of processing is shown for the case where the execution broker is determined by the fee competition after matching between the above (B) participants. Basically, it is the same as the process of matching (fee inquiry) between the buy-sides 30 shown in FIG. 8 in the above-mentioned first embodiment shown in FIG. is there. Further, as described above, the processing of steps S91 to S93 in the example of FIG. 12 is the same as steps S71 to S73 in the example of FIG.
  • the participant A (50a) that has received the notification of the matching result selects the sellside A (20a) as the broker (sellside 20) to execute the transaction, as in the example of FIG.
  • a response of (Accept) or Rej (Reject) is notified to the POP 120 (S94).
  • Participant B (50b) that has received the notification of the matching result is different from the example in FIG. 11, and Ack (Agreement) or Rej which specified that the broker (Sellside 20) to conduct the transaction is selected by commission inquiry.
  • a response of (rejection) is notified to the POP 120 (S94).
  • FIG. 12 shows the case where only the participant B (50b) which is one of the participants 50 designates the fee competition, both of the participant A (50a) and the participant B (50b) The same applies when a fee competition is designated.
  • the POP 120 that receives the designation of commission for commission (and broker designation) notifies Participant A (50a) and Participant B (50b) that the transaction is in progress (S95) and also designates the broker If it is determined that a cross transaction is requested to each designated sell side 20 (in the example of FIG. 12, the sell side A (20 a) designated by the participant A (50 a)) (S96).
  • the sell side A (20a) that has received the cross transaction request sends a response of Ack (acceptance) or Rej (deny) to the POP 120 (S97).
  • the POP 120 requests the sell side 20 (in the example of FIG. 12, the sell side A (20 a) and the sell side B (20 b)) to make a commission inquiry based on the designation of the commission inquiry (S98).
  • the inquiry includes information relating to a trade, a brand, a quantity, and a participant 50 for sale and purchase (in the example of FIG. 12, the participant B (50b) who has specified an inquiry for a fee).
  • the sell side A (20a) and the sell side B (20 b) that received the request for inquiry respectively set the BP of the fee as the condition presentation, and notify the POP 120 of the response of Ack (acceptance) or Rej (deny) (S99).
  • each sell side 20 shall receive conditions of both and shall present conditions about each.
  • the list of the conditions presented from each sell-side 20 is In the example of FIG. 12, notification is given to the participant B (50b) (S100). Similar to the example of FIG. 8, the candidate of the ordering party is the sell side 20 with the lowest BP of the fee (in the case of the same BP, the sell side 20 with the earliest condition presentation time (step S99)). On the other hand, when each participant 50 decides as the ordering party, the fact is notified to the POP 120 (S101).
  • the POP 120 notified of the decision from each participant 50 notifies the sell-side 20 (the sell-side A (20 a in the example of FIG. 12) determined as the ordering party (S102 in the example of FIG. 12) that the transaction has been completed (S102).
  • the sell side B (20b) is notified of the transaction failure (S103).
  • each participant 50 is notified that the transaction has been established (S104).
  • the executing broker designated by participant A (50a) and the sell side 20 of the ordering party determined as a result of the commission inquiry by the designation of participant B (50b) are the same sellside A (20a). ). Therefore, both Participant A (50a) and Participant B (50b) place an order to Sellside A (20a) (S105), and execute cross trade from Sellside A (20a) via exchange system 40. Is performed (S106), the notice of agreement is notified to the participant A (50a) and the participant B (50b) (S107).
  • the present invention is not limited to the above-mentioned embodiment, and can be variously changed in the range which does not deviate from the summary. It goes without saying.
  • the above embodiments have been described in detail in order to explain the present invention in an easy-to-understand manner, and are not necessarily limited to those having all the described configurations.
  • part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. .
  • the present invention is applicable to a stock transaction management system that supports operations related to transaction ordering and contract processing.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

複数のセルサイドが提供するダークプールの連携、もしくは複数のセルサイドが参加するダークプールの実現を可能とし、さらにバイサイドの潜在的な注文についてもマッチングを可能とする証券取引管理システムを提供する。代表的な実施の形態によれば、証券取引に参加する参加者となるバイサイドもしくはセルサイドにおいて相手方との間の注文を管理する注文管理システムを含む１つ以上の情報処理システムと、各情報処理システムから取得した、各参加者のＩＯＩ（Indication of Interest）の情報をデータベースに記録し、各ＩＯＩに含まれる注文の間で売り買いをマッチングさせるポテンシャルオーダープールシステムとを有する。

Description

証券取引管理システム
　本発明は、証券取引の技術に関し、特に、ダークプールを利用した取引を支援する証券取引管理システムに適用して有効な技術に関するものである。
　証券会社（セルサイド）では、機関投資家などの資産運用会社（バイサイド）からの大口の有価証券取引の注文を受けて、市場等を介して実際の取引を行っている。近年では、例えば、大口の売買を市場で行うことによる取引価格への影響の回避などのため、セルサイド内の情報処理システムにおいて投資家の売買注文をマッチングさせて取引を行うといういわゆるダークプールのサービスも行われている。ここでは、取引参加者の情報や価格、注文量などの注文情報の匿名性が確保されるとともに、約定率や約定単価の改善などが期待できることから、ファンドにおける個別銘柄の売買に係る運用計画等を秘匿したい機関投資家などを対象に利用が拡大している。
　ダークプールに関する技術としては、例えば、特開２０１０－２２４７１０号公報（特許文献１）には、新規注文情報を社内取引システムと外部の取引市場システムの双方に対して同時に送信する方式をとることで、社内ダークプールと証券取引所のいずれに注文を回送すべきかの判断に伴う時間的な損失を低減可能とする仕組みが記載されている。
　また、特開２０１３－１３０９３６号公報（特許文献２）には、複数種類のアルゴリズム取引のタイプを有するアルゴリズム取引群に対応したマッチングロジックに基づいて売買注文データ同士のマッチング処理を所定間隔で定期的に行うことで、ダークプール環境下での注文条件が複雑化したアルゴリズム注文の約定率を向上させる仕組みが記載されている。
特開２０１０－２２４７１０号公報 特開２０１３－１３０９３６号公報
　従来技術では、各セルサイドが提供するダークプールにおいて各バイサイドが注文情報の匿名性を確保しつつ取引を行うことができる。しかしながら、例えば、他のセルサイドが提供するダークプールとの連携や、複数のセルサイドが参加するダークプールの実現といった流動性を高める、より高度かつ拡張された仕組みについては実現が困難である。
　また、従来技術では、実際に行なわれた注文に基づいてマッチングを行い、取引を成立させることは行われている。しかしながら、例えば、バイサイドが運用計画として持っている将来の潜在的な注文についてはマッチングの対象にできないため、結果的に取引タイミングや執行先について必ずしも最適とはいえない条件で取引を行うことになる場合も生じている。
　そこで本発明の目的は、複数のセルサイドが提供するダークプールの連携、もしくは複数のセルサイドが参加するダークプールの実現を可能とし、さらにバイサイドの潜在的な注文についてもマッチングを可能とする証券取引管理システムを提供することにある。
　本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
　本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
　本発明の代表的な実施の形態による証券取引管理システムは、相手方からの注文を受けてセルサイドが行う証券取引を管理する証券取引管理システムであって、証券取引に参加する参加者となるバイサイドもしくはセルサイドにおいて相手方との間の注文を管理する注文管理システムを含む１つ以上の情報処理システムと、前記各情報処理システムから取得した、前記各参加者のＩＯＩ（Indication of Interest）の情報をデータベースに記録し、前記各ＩＯＩに含まれる注文の間で売り買いをマッチングさせるポテンシャルオーダープールシステムと、を有するものである。
　本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
　すなわち、本発明の代表的な実施の形態によれば、複数のセルサイドが提供するダークプールの連携、もしくは複数のセルサイドが参加するダークプールの実現が可能となり、さらにバイサイドの潜在的な注文についてもマッチングを可能とすることが可能となる。
本発明の実施の形態１である証券取引管理システムの構成例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰサービスの例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイドとセルサイドとの間のマッチングの例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイドとセルサイドとの間のマッチング処理の例について概要を示したシーケンス図である。 本発明の実施の形態１におけるＰＯＰでのバイサイド間のマッチングの例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイド間のマッチング処理の例について概要を示したシーケンス図である。 本発明の実施の形態１におけるＰＯＰでのバイサイド間のマッチングの他の例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイド間のマッチング処理の他の例について概要を示したシーケンス図である。 本発明の実施の形態１におけるＰＯＰでのバイサイドセルサイドとの間のマッチングの他の例について概要を示した図である。 本発明の実施の形態１におけるＰＯＰでのバイサイドとセルサイドとの間のマッチング処理の例について概要を示したシーケンス図である。 本発明の実施の形態２におけるＰＯＰでの参加者間のマッチング処理の例について概要を示したシーケンス図である。 本発明の実施の形態２におけるＰＯＰでの参加者間のマッチング処理の他の例について概要を示したシーケンス図である。
　以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
　（実施の形態１）
　＜システム構成＞
　図１は、本発明の実施の形態１である証券取引管理システムの構成例について概要を示した図である。証券取引管理システム１は、複数のバイサイドシステム３００、複数のセルサイドシステム２００、およびポテンシャルオーダープールシステム１００の各情報処理システムがインターネット等のネットワーク１０に接続された構成を有する。バイサイドシステム３００は、各バイサイド３０（運用会社等）が有する注文管理システム等を含む情報処理システムであり、セルサイドシステム２００は、各セルサイド２０（証券会社等）が有する注文管理システム等を含む情報処理システムである。
　ポテンシャルオーダープールシステム１００は、各バイサイド３０や各セルサイド２０とは独立した中立の事業者により運用管理される情報処理システムであり、各バイサイド３０や各セルサイド２０から「ポテンシャルオーダー」を含むＩＯＩ（Indication of Interest：「取引意思の表示」）の情報を取得して蓄積し、売り買いをマッチングして取引を成立させる「ポテンシャルオーダープール（以下では「ＰＯＰ」と略記する場合がある）」サービスをＡＳＰ（Application Service Provider）サービス等として提供する機能を有する。ＰＯＰサービスの内容については後述する。
　各セルサイド２０の担当者等は、自身が使用する情報処理端末であるセルサイド端末２１の図示しないＷｅｂブラウザ等を利用して自社のセルサイドシステム２００にアクセスし、セルサイド２０としての業務を行う。直接ＰＯＰシステム１００にアクセスしてデータの授受等を行ってもよい。同様に、各バイサイド３０の担当者等は、自身が使用する情報処理端末であるバイサイド端末３１の図示しないＷｅｂブラウザ等を利用して自社のバイサイドシステム３００にアクセスし、バイサイド３０としての業務を行う。直接ＰＯＰシステム１００にアクセスしてデータの授受等を行ってもよい。
　ＰＯＰシステム１００、セルサイドシステム２００、およびバイサイドシステム３００の各システムは、それぞれが例えば１つ以上のサーバ機器やクラウドコンピューティングサービス上で構築された仮想サーバなどにより実装される。バイサイド３０およびセルサイド２０からの「ポテンシャルオーダー」を含むＩＯＩの情報を一元的に蓄積してＰＯＰサービスを提供するという観点からは、例えば、各システムは同じＩＴ事業者により共通のシステム基盤上で運用・監視されているのが望ましいが、必ずしもこれに限られない。
　セルサイドシステム２００は、例えば、セルサイド２０側の注文管理システム（ＯＭＳ：Order Management System）であるセルサイドＯＭＳ２１０、およびバックオフィスシステムであるバックシステム２２０を有する。セルサイドＯＭＳ２１０は、東京証券取引所などの取引所システム４０に対してネットワーク１０等を介してオンラインで売買注文の執行を行う機能も有している。また、バイサイドシステム３００は、例えば、バイサイド３０側の注文管理システムであるバイサイドＯＭＳ３１０、およびバックオフィスシステムであるバックシステム３２０を有する。
　ＰＯＰシステム１００は、例えば、データベースやファイルテーブルなどにより実装されるポテンシャルオーダープール（ＰＯＰ）データベース（ＤＢ）１２１、バイサイドマスタＤＢ１２２、セルサイドマスタＤＢ１２３、および設定ＤＢ１２４などの各データストアを有する。各バイサイド３０および各セルサイド２０に対してＰＯＰサービスを提供する機能を有するソフトウェアとして実装されたマッチング処理部１１０などの各部を有していてもよい。
　ＰＯＰＤＢ１２１は、セルサイドシステム２００（もしくはセルサイド端末２１）やバイサイドシステム３００（もしくはバイサイド端末３１）から取得した「ポテンシャルオーダー」を含むＩＯＩの情報を保持するテーブルである。これ以外にも、注文処理に用いられる各種情報のうち、例えば、バイサイド３０とセルサイド２０との間で開示についての承諾が得られたものなど、共有が可能なデータを保持するものとしてもよい。
　バイサイドマスタＤＢ１２２およびセルサイドマスタＤＢ１２３は、それぞれ、ＰＯＰシステム１００にアクセスしてＰＯＰサービスの提供を受けることができるバイサイド３０およびセルサイド２０についてのマスタ情報を保持するテーブルである。ユーザについてのアカウント情報を含んでいてもよい。設定ＤＢ１２４は、ＰＯＰシステム１００における動作や処理等についての各種設定情報を保持するテーブルである。セルサイド２０やバイサイド３０毎に固有の設定情報を保持するようにしてもよい。
　マッチング処理部１１０は、ＰＯＰサービスとして、各バイサイド３０や各セルサイド２０からの「ポテンシャルオーダー」を含むＩＯＩの情報を取得、蓄積し、後述するような手法により売り買いをマッチングして取引を成立させる機能を有する。取引成立に係る通知や、その後のバイサイド３０やセルサイド２０の間での受発注、約定の処理を中継、仲介する機能を有していてもよい。
　＜ポテンシャルオーダープール（ＰＯＰ）サービス＞
　図２は、本実施の形態におけるＰＯＰサービスの例について概要を示した図である。ポテンシャルオーダープール（ＰＯＰ）１２０は、ＰＯＰシステム１００のＰＯＰＤＢ１２１およびマッチング処理部１１０等により実現される概念上のダークプールを模式的に示したものである。
　投資家と証券会社との間の取引では、取引を成立させるための有用な参照情報として、ＩＯＩを出して取引相手を探すことが行われる場合がある。この場合、ＩＯＩには、実行する予定の注文についての内容や、希望するもしくは対応が可能な条件などの情報が含まれる。したがって、これを用いることにより、当日に実行の意思を有している取引については効率的にマッチングして成立させることが可能である。
　一方で、例えば機関投資家（バイサイド３０）については、必ずしも当日実行することまでは予定していないものの、近い将来には実行することが確実に予定されている取引（以下ではこれを「ポテンシャルオーダー」と記載する）を有している場合がある。例えば、一定期間の運用計画に沿って売買時期を決めている場合や、大口の売買について市場への影響を回避するために複数回に分散して売買する場合などがある。いずれの場合でも、近い将来にどのような売買が行われるか、という情報は、バイサイド３０としては本来秘匿すべき情報であり開示されないのが通常である。
　しかしながら、これらのポテンシャルオーダーについても、将来の予定の日に必ず実行するという類のものではなく、例えば、対象の銘柄について当日に特定のセルサイド２０（ブローカー）が特に有利な条件でＩＯＩを出しており、このタイミングで売買することが有効であると判断される場合には、予定に関わらずに当日に売買を行うなどの柔軟な対応がとられる。従来は、このような判断は、例えばバイサイド３０のトレーダーなどの人手の判断によりもたらされていた。
　そこで、ダークプールにおける情報の秘匿性を活かし、本実施の形態では、このようなポテンシャルオーダーの情報についてもＩＯＩとしてバイサイド３０から取得してＰＯＰ１２０を形成し、当日の取引としてマッチングの対象とする。
　上述したように、例えば、バイサイドシステム３０とＰＯＰシステム１００が同じ中立の事業者により運用管理されている場合は、元々バイサイドシステム３０において管理されていたポテンシャルオーダーの情報が、実質上は同じ事業者によって参照範囲が拡張されるだけに留まるといえ、開示に対する心理的・物理的障害は少ない。また、このような中立の事業者が運用管理するＰＯＰ１２０に対して各セルサイド２０がＩＯＩを出す構成とすることで、複数のセルサイド２０のダークプールの連携が可能となるとともに、ダークプールサービスにおける透明性、公正・公平性を担保することができる。
　図２の例では、ＰＯＰ１２０に対してバイサイドＡ（３０ａ）、バイサイドＢ（３０ｂ）、およびセルサイドＡ（２０ａ）、セルサイドＢ（２０ｂ）が参加して、ポテンシャルオーダーを含むＩＯＩの情報（図中ではＩＯＩ３２ａ、３２ｂ、およびＩＯＩ２２ａ、２２ｂの各表で示す）を登録した状態を示している。ＰＯＰシステム１００は、バイサイド３０およびセルサイド２０から、例えばＦＩＸ（Financial Information eXchange）プロトコルでの通信もしくはファイルの送受信によってＩＯＩ情報を取得してＰＯＰＤＢ１２１に蓄積し、マッチング処理部１１０によりＩＯＩ間で売り買いのマッチングを行う。マッチングのアルゴリズム等については特に限定されず、公知の手法を適宜用いることができる。
　なお、マッチングの際の約定単価は、例えば、取引所の前日終値や当日仲値とすることができる。また、マッチングは、バイサイド３０とセルサイド２０との間だけに限らず、後述するように、バイサイド３０同士やセルサイド２０同士でマッチングすることも可能である。マッチングが成立した際に対象のバイサイド３０やセルサイド２０に通知される相手方の取引内容の情報は原則として匿名であるが、例えば、設定ＤＢ１２４などに予め取引先として登録されている相手の場合には、当該相手方の情報を開示するようにしてもよい。
　＜（１）バイサイド－セルサイド間のマッチング＞
　図３は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０とセルサイド２０との間のマッチングの例について概要を示した図である。図３の例では、バイサイドＡ（３０ａ）が出したＩＯＩ３２ａと、セルサイドＡ（２０ａ）が出したＩＯＩ２２ａにおいて、銘柄“△△”について売り買いがマッチしたことを示している。
　この場合、例えば、発注に係る情報は、ＦＩＸプロトコルのメッセージによってバイサイドＡ（３０ａ）のバイサイドシステム３００からセルサイドＡ（２０ａ）のセルサイドシステム２００に対して送信される。セルサイドＡ（２０ａ）では、発注情報に基づいて取引所システム４０に対する注文の執行が行われる。約定に係るデータは、例えば、ＰＯＰシステム１００を介したファイルの授受等によりバイサイドＡ（３０ａ）に送付される。
　図４は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０とセルサイド２０との間のマッチング処理の例について概要を示したシーケンス図である。まず、バイサイド３０（すなわちバイサイドシステム３００もしくはバイサイド端末３１。以下同様。）およびセルサイド２０（すなわちセルサイドシステム２００もしくはセルサイド端末２１。以下同様。）は、ＰＯＰ１２０（すなわちＰＯＰシステム１００。以下同様。）に対して、ＦＩＸプロトコルのメッセージもしくはファイルによりＩＯＩ情報を登録する（Ｓ０１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ０２）、マッチした取引については、対象のバイサイド３０とセルサイド２０に対してそれぞれその旨を通知する（Ｓ０３）。
　マッチング結果の通知を受けたバイサイド３０およびセルサイド２０では、それぞれ、マッチした内容に対してＡｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ０４）。ＰＯＰ１２０では、いずれの応答もＡｃｋであった場合に取引成立と判定し（Ｓ０５）、バイサイド３０およびセルサイド２０に対して取引が成立した旨を通知する（Ｓ０６）。その後、成立した取引の実行として、バイサイド３０からＦＩＸプロトコルのメッセージによりセルサイド２０に対して発注が行われ（Ｓ０７）、セルサイド２０において執行した結果の約定内容がバイサイド３０に対して通知される（Ｓ０８）。
　＜（２）バイサイド間のマッチング（執行先指定）＞
　図５は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０間のマッチングの例について概要を示した図である。上述したように、本実施の形態では、バイサイド３０同士でＩＯＩをマッチングさせることができる。図５の例では、バイサイドＡ（３０ａ）が出したＩＯＩ３２ａと、バイサイドＢ（３０ｂ）が出したＩＯＩ３２ｂにおいて、銘柄“△△”について売り買いがマッチしたことを示している。
　この場合、双方のバイサイド３０は、それぞれが取引契約を有する所定のセルサイド２０に対して個別に発注処理を行う。図５の例では、バイサイドＡ（３０ａ）はセルサイドＡに、バイサイドＢ（３０ｂ）はセルサイドＢ（２０ｂ）に対して発注を行った場合を示している。発注情報には、バイサイドシステム３００もしくはＰＯＰ１２０により、マッチした相手方のバイサイド３０の発注先のセルサイド２０の情報がクロス取引先のブローカー（セルサイド２０）の情報として付加される。例えば、バイサイドＡ（３０ａ）からの発注情報には、マッチした相手方のバイサイドＢ（３０ｂ）の発注先であるセルサイドＢ（２０ｂ）の情報が付加される。
　これにより、発注情報を受け取ったセルサイド２０では、クロス取引の相手方となるセルサイド２０の情報を確認することができ、当該セルサイド２０との間のクロス取引を取引所システム４０に対して執行することができる。なお、各セルサイド２０からの約定データの通知については上述の図３の例と同様であるため説明は省略する。
　図６は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０間のマッチング処理の例について概要を示したシーケンス図である。まず、各バイサイド３０（図６の例ではバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）の２つ）は、ＰＯＰ１２０に対してＩＯＩ情報を登録する（Ｓ１１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ１２）、マッチした取引について、バイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対してその旨をそれぞれ通知する（Ｓ１３）。
　マッチング結果の通知を受けたバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）では、それぞれ、取引執行を行うブローカー（セルサイド２０）を選択して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ１４）。上述したように、ここでのブローカーは、例えば、各バイサイド３０が取引契約を有するセルサイド２０である。対象のセルサイド２０の情報を予めＰＯＰシステム１００の設定ＤＢ１２４にデフォルト値として登録しておき、自動的にブローカーが選択されるようにしてもよい。
　ブローカー指定を受けたＰＯＰ１２０では、取引が仕掛中となった旨をバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対して通知する（Ｓ１５）とともに、ブローカーとして指定された各セルサイド２０（図６の例ではセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ））に対してクロス取引の依頼を行う（Ｓ１６）。依頼には、クロス取引に係る銘柄、各バイサイド３０の情報、クロス相手のブローカーの情報などが含まれる。
　クロス取引依頼を受けたセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）では、それぞれ、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ１７）。ＰＯＰ１２０では、いずれの応答もＡｃｋであった場合に取引成立と判定し（Ｓ１８）、バイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対して取引が成立した旨を通知する（Ｓ１９）。
　その後、成立した取引の実行として、バイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）からそれぞれＦＩＸプロトコルのメッセージによりセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）に対して発注が行われ（Ｓ２０）、セルサイドＡ（２０ａ）とセルサイドＢ（２０ｂ）との間でクロス取引の執行が行われた後（Ｓ２１）、約定内容がバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対してそれぞれ通知される（Ｓ２２）。クロス取引（Ｓ２１）に必要となる情報は、発注（Ｓ２０）の際の情報に付加してもよいし、クロス取引依頼（Ｓ１６）の際に渡された情報を用いるようにしてもよい。
　なお、上述の例ではバイサイド３０同士のマッチングの場合を示したが、セルサイド２０同士のマッチングの場合も同様である。
　＜（３）バイサイド間のマッチング（手数料引き合い）＞
　図７は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０間のマッチングの他の例について概要を示した図である。図７の例では、上述の図５に示したのと同様なバイサイド３０間でのマッチングの後、双方のバイサイド３０と取引契約のある複数のセルサイド２０に対して手数料の引き合いを行い、最も低い手数料を提示したセルサイド２０を発注先として決定する場合を示している。すなわち「手数料コンペ」によって発注先のセルサイド２０を決定する。図７の例では、セルサイドＡ（２０ａ）、セルサイドＢ（２０ｂ）、およびセルサイドＣ（２０ｃ）に手数料の引き合いを行い、最も低い「１ＢＰ（＝０．０１％）」という手数料を提示したセルサイドＡ（２０ａ）を自動的に発注先と決定している。
　図８は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０間のマッチング処理の他の例について概要を示したシーケンス図である。上述の図６の例と同様に、まず、各バイサイド３０（図７の例ではバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）の２つ）は、ＰＯＰ１２０に対してＩＯＩ情報を登録する（Ｓ３１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ３２）、マッチした取引について、バイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対してその旨をそれぞれ通知する（Ｓ３３）。
　マッチング結果の通知を受けたバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）では、それぞれ、取引を行うブローカー（セルサイド２０）を手数料の引き合いにより選択する旨を指定してＰＯＰ１２０に対して通知する（Ｓ３４）。引き合い要求を受けたＰＯＰ１２０では、取引が仕掛中となった旨をバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対して通知する（Ｓ３５）とともに、各バイサイド３０が取引契約を有するセルサイド２０（図７の例ではセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ））に対して手数料の引き合いを依頼する（Ｓ３６）。引き合いには、取引に係る銘柄、数量、売りと買いの各バイサイド３０の情報などが含まれる。
　引き合いの依頼を受けたセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）では、それぞれ、条件提示として手数料のＢＰを設定して応答する（Ｓ３７）。ＢＰの値は、都度セルサイドシステム２００側で入力や設定を行ってもよいし、セルサイドシステム２００やＰＯＰシステム１００の設定ＤＢ１２４などにバイサイド３０毎に予め登録しておいてもよい。セルサイド２０において「手数料コンペ」に不参加とする選択をした場合にその旨を応答することも可能である。一定時間応答がない場合に自動的に不参加として取り扱うようにしてもよい。
　ＰＯＰ１２０では、対象の全てのセルサイド２０から条件が提示された場合、もしくは所定の時間が経過した場合に、各セルサイド２０から提示された条件のリストをバイサイドＡ（３０ａ）およびバイサイドＢ（３０ｂ）に対して通知する（Ｓ３８）。発注先の候補は、手数料のＢＰが最も低いセルサイド２０（ＢＰが同じ場合はその中で条件提示（ステップＳ３７）の時刻が最も早いセルサイド２０）となり、その条件に対して各バイサイド２０が発注先として決定する場合には、その旨をＰＯＰ１２０に通知する（Ｓ３９）。各バイサイド２０から決定通知を受けたＰＯＰ１２０は、発注先として決定されたセルサイド２０（図８の例ではセルサイドＡ（２０ａ））には取引成立を通知し（Ｓ４０）、他のセルサイド２０（図８の例ではセルサイドＢ（２０ｂ））には取引不成立を通知する（Ｓ４１）。
　以上の処理により、バイサイド３０は、有利な手数料の条件で取引を行うことができる。また、セルサイド２０は、大口注文の手数料コンペに参加することができ、委託売買の機会を得ることができる。
　＜（４）バイサイド－セルサイド間のマッチング（執行先指定）＞
　図９は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０とセルサイド２０との間のマッチングの他の例について概要を示した図である。図９の例では、上述の図３に示したのと同様なバイサイドＡ（３０ａ）とセルサイドＡ（２０ａ）との間のマッチングの結果、マッチしたセルサイドＡ（２０ａ）とは別のセルサイドＢ（２０ｂ）に対して発注を行う場合を示している。
　この場合、発注に係る情報は、ＦＩＸプロトコルのメッセージによってバイサイドＡ（３０ａ）のバイサイドシステム３００から、セルサイドＢ（２０ｂ）のセルサイドシステム２００に対して送信される。発注情報には、バイサイドシステム３００もしくはＰＯＰ１２０により、マッチした相手方のセルサイド２０（図９の例ではセルサイド２０Ａ（２０ａ））の情報が付加される。したがって、発注情報を受け取ったセルサイドＢ（２０ｂ）では、クロス取引の相手方となるセルサイドＡ（２０ａ）の情報を確認することができ、セルサイドＡ（２０ａ）との間のクロス取引を取引所システム４０に対して執行することができる。
　図１０は、本実施の形態におけるＰＯＰ１２０でのバイサイド３０とセルサイド２０との間のマッチング処理の例について概要を示したシーケンス図である。上述した図４の例と同様に、まず、バイサイド３０およびセルサイドＡ（２０ａ）は、ＰＯＰ１２０に対して、ＦＩＸプロトコルのメッセージもしくはファイルによりＩＯＩ情報を登録する（Ｓ５１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ５２）、マッチした取引について、対象のバイサイド３０とセルサイドＡ（２０ａ）に対してそれぞれその旨を通知する（Ｓ５３）。
　マッチング結果の通知を受けたバイサイド３０では、取引を行うブローカー（セルサイド２０）を選択して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して指定する（Ｓ５４）。上述したように、ここでのブローカーは、例えば、セルサイド２０（図１０の例ではセルサイドＢ（２０ｂ））である。対象のセルサイド２０の情報を予めＰＯＰシステム１００の設定ＤＢ１２４にデフォルト値として登録しておき、自動的にブローカーが選択されるようにしてもよい。
　また、マッチング結果の通知を受けたセルサイドＡ（２０ａ）では、マッチした内容に対してＡｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ５５）。ＰＯＰ１２０では、バイサイド３０からのブローカーの指定を伴うＡｃｋと、セルサイドＡ（２０ａ）からＡｃｋの応答を受けた場合に、ブローカーとして指定されたセルサイドＢ（２０ｂ）に対してクロス取引の依頼を行う（Ｓ５６）。依頼には、クロス取引に係る銘柄、バイサイド３０の情報、クロス相手のブローカーの情報などが含まれる。
　クロス取引依頼を受けたセルサイドＢ（２０ｂ）では、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ５７）。ＰＯＰ１２０では、Ａｃｋの応答を受けた場合に取引成立と判定し（Ｓ５８）、バイサイド３０およびセルサイドＡ（２０ａ）に対して取引が成立した旨を通知する（Ｓ５９）。その後、成立した取引の実行として、バイサイド３０からＦＩＸプロトコルのメッセージによりセルサイド２０に対して発注が行われ（Ｓ６０）、セルサイドＡ（２０ａ）とセルサイドＢ（２０ｂ）との間でクロス取引の執行が行われた後（Ｓ６１）、約定内容がバイサイド３０に対して通知される（Ｓ６２）。
　上述の図６の例と同様に、クロス取引（Ｓ６１）に必要となる情報は、発注（Ｓ６０）の際の情報に付加してもよいし、クロス取引依頼（Ｓ５６）の際に渡された情報を用いるようにしてもよい。
　以上に説明したように、本発明の実施の形態１である証券取引管理システム１によれば、バイサイド３０およびセルサイド２０に対して中立の事業者が運用管理するＰＯＰシステム１００において、ＰＯＰＤＢ１２１に１つ以上のバイサイド３０のポテンシャルオーダーも含むＩＯＩ情報と、１つ以上のセルサイド２０のＩＯＩ情報とを蓄積してマッチングさせる。これにより、複数のセルサイド２０のダークプールの連携が可能となり、バイサイド３０はより幅広い範囲で好適な条件での取引の成立を図ることが可能となる。また、透明性、公正・公平性を担保したダークプールサービスを提供することが可能となる。
　また、バイサイド３０のポテンシャルオーダーについてもＩＯＩ情報として取得し、マッチングの対象とすることで、将来の一定期間にわたって分散して行われる予定の取引について、より好適な条件となるタイミングで実行することが可能となる。
　（実施の形態２）
　上述の実施の形態１では、ＰＯＰ１２０での取引について、バイサイド３０が参加者になる場合とセルサイド２０が参加者になる場合とを区別し、考え得るパターンとして、（１）バイサイド３０とセルサイド２０との間のマッチング、（２）バイサイド３０間でのマッチング（執行先を指定したクロス取引）、（３）バイサイド３０間でのマッチング（手数料引き合い）、および（４）バイサイド３０とセルサイド２０との間のマッチング（執行先を指定）、という４つのパターンについて処理の内容を説明した。
　一方、証券取引管理システム１として実装する上で、実務での実態や慣行等を考慮すると、ＰＯＰ１２０でのマッチングの時点において通常はマッチングの相手方がバイサイド３０となるのかセルサイド２０となるのかは不明であるため、参加者がバイサイド３０であるのかセルサイド２０であるのかにより処理フローを区別することが困難な場合も生じる。
　また、例えば、（１）のバイサイド３０とセルサイド２０との間のマッチングが行われるケースにおいて、バイサイド３０が執行先のセルサイド２０（執行ブローカー）を指定しないケースは通常では生じ難い。また、（４）のバイサイド３０とセルサイド２０との間のマッチングが行われるケースにおいても同様に、例えば、マッチングされたバイサイド３０とセルサイド２０との間に仮に取引契約がない場合であっても、取引契約のあるセルサイド２０（執行ブローカー）が指定されるのが自然であると考えられる。
　したがって、実務上は、ＰＯＰ１２０での取引の相手方についてバイサイド３０かセルサイド２０かを区別せず、（Ａ）参加者間でマッチングした後に執行先のセルサイド２０（執行ブローカー）を指定するケース、および（Ｂ）参加者間でマッチングした後に執行先のセルサイド２０（執行ブローカー）を手数料コンペにより決定するケース、の２つのパターンを実装することで足りるものと考えられる。
　図１１は、本実施の形態におけるＰＯＰ１２０での参加者間のマッチング処理の例について概要を示したシーケンス図である。ここでは、上記の（Ａ）参加者間でマッチングした後に執行ブローカーを指定するケースについての処理の流れを示している。基本的には上述の実施の形態１で図６に示した（２）バイサイド３０間でのマッチング（執行先を指定したクロス取引）の処理と同様であるため、重複する内容についての再度の説明は省略する場合がある。図１１の例では、図６の例と異なり、ＰＯＰ１２０での取引への参加者がバイサイド３０ではなく参加者５０（図１１の例では参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）の２つ）となっている。参加者５０は、バイサイド３０もしくはセルサイド２０のいずれであってもよい。
　まず、各参加者５０（図１１の例では参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）の２つ）は、ＰＯＰ１２０に対してＩＯＩ情報を登録する（Ｓ７１）。ＰＯＰ１２０では所定のタイミングでマッチングを行い（Ｓ７２）、マッチした取引について、参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対してその旨をそれぞれ通知する（Ｓ７３）。なお、ここまでの処理は、図１１の例に示した（Ａ）参加者間でマッチングした後に執行ブローカーを指定するケースと、後述する（Ｂ）参加者間でマッチングした後に執行ブローカーを手数料コンペにより決定するケースとで共通である。
　図１１の例では、マッチング結果の通知を受けた参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）では、それぞれ、取引執行を行うブローカー（セルサイド２０）を選択して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ７４）。ここでのブローカーは、例えば、参加者５０がバイサイド３０である場合は、上述したように、当該バイサイド３０が取引契約を有するセルサイド２０である。また、参加者５０がセルサイド２０である場合は、通常は、当該セルサイド２０自身が執行先とされる。図１１の例では、参加者Ａ（５０ａ）は執行ブローカーとしてセルサイドＡ（２０ａ）指定し、参加者Ｂ（５０ｂ）はセルサイドＢ（２０ｂ）を指定したことを示している。なお、これらの執行ブローカーが同一のセルサイド２０となる場合もある。
　ブローカー指定を受けたＰＯＰ１２０では、取引が仕掛中となった旨を参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対して通知する（Ｓ７５）とともに、ブローカーとして指定された各セルサイド２０（図１１の例ではセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ））に対してクロス取引の依頼を行う（Ｓ７６）。依頼には、クロス取引に係る銘柄、各バイサイド３０の情報、クロス相手のブローカーの情報などが含まれる。図１１の例では、参加者Ａ（５０ａ）により指定されたセルサイドＡ（２０ａ）には、参加者Ａ（５０ａ）の取引についてのクロス取引の依頼が行われ、一方、参加者Ｂ（５０ｂ）により指定されたセルサイドＢ（２０ｂ）には、参加者Ｂ（５０ｂ）の取引についてのクロス取引の依頼が行われる。
　クロス取引依頼を受けたセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）では、それぞれ、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ７７）。ＰＯＰ１２０では、いずれの応答もＡｃｋであった場合に取引成立と判定し（Ｓ７８）、参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対して取引が成立した旨を通知する（Ｓ７９）。
　その後、成立した取引の実行として、参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）からＦＩＸプロトコルのメッセージによりそれぞれの執行ブローカーであるセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）に対して発注が行われる（Ｓ８０）。セルサイドＡ（２０ａ）とセルサイドＢ（２０ｂ）との間で取引所システム４０を介してクロス取引の執行が行われた後（Ｓ８１）、約定内容が参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対してそれぞれ通知される（Ｓ８２）。
　図１２は、本実施の形態におけるＰＯＰ１２０での参加者間のマッチング処理の他の例について概要を示したシーケンス図である。ここでは、上記の（Ｂ）参加者間でマッチングした後に執行ブローカーを手数料コンペにより決定するケースについての処理の流れを示している。基本的には上述の実施の形態１で図８に示した（３）バイサイド３０間でのマッチング（手数料引き合い）の処理と同様であるため、重複する内容についての再度の説明は省略する場合がある。また、上述したように、図１２の例におけるステップＳ９１～Ｓ９３までの処理は、図１１の例におけるステップＳ７１～Ｓ７３と共通である。
　図１２の例では、マッチング結果の通知を受けた参加者Ａ（５０ａ）は、図１１の例と同様に、取引執行を行うブローカー（セルサイド２０）としてセルサイドＡ（２０ａ）を選択して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知している（Ｓ９４）。一方で、マッチング結果の通知を受けた参加者Ｂ（５０ｂ）は、図１１の例と異なり、取引を行うブローカー（セルサイド２０）を手数料の引き合いにより選択する旨を指定したＡｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ９４）。図１２の例では、参加者５０の一方である参加者Ｂ（５０ｂ）のみが手数料コンペを指定した場合を示しているが、参加者Ａ（５０ａ）、参加者Ｂ（５０ｂ）のいずれもが手数料コンペを指定した場合も同様である。
　手数料の引き合いの指定（およびブローカー指定）を受けたＰＯＰ１２０では、取引が仕掛中となった旨を参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）に対して通知する（Ｓ９５）とともに、ブローカー指定がされている場合には、指定された各セルサイド２０（図１２の例では参加者Ａ（５０ａ）により指定されたセルサイドＡ（２０ａ））に対してクロス取引の依頼を行う（Ｓ９６）。クロス取引依頼を受けたセルサイドＡ（２０ａ）では、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ９７）。
　また、ＰＯＰ１２０は、手数料の引き合いの指定に基づいて、各セルサイド２０（図１２の例ではセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ））に対して手数料の引き合いを依頼する（Ｓ９８）。引き合いには、取引に係る銘柄、数量、売りと買いの参加者５０（図１２の例では手数料の引き合いを指定した参加者Ｂ（５０ｂ））の情報などが含まれる。引き合いの依頼を受けたセルサイドＡ（２０ａ）およびセルサイドＢ（２０ｂ）では、それぞれ、条件提示として手数料のＢＰを設定して、Ａｃｋ（承諾）もしくはＲｅｊ（拒否）の応答をＰＯＰ１２０に対して通知する（Ｓ９９）。なお、参加者５０のいずれもが手数料の引き合いを指定した場合、各セルサイド２０は双方の引き合いを受けてそれぞれについて条件提示するものとする。
　ＰＯＰ１２０では、対象の全てのセルサイド２０から条件が提示された場合、もしくは所定の時間が経過した場合に、各セルサイド２０から提示された条件のリストを、手数料の引き合いを指定した各参加者５０（図１２の例では参加者Ｂ（５０ｂ））に対して通知する（Ｓ１００）。図８の例と同様に、発注先の候補は、手数料のＢＰが最も低いセルサイド２０（ＢＰが同じ場合はその中で条件提示（ステップＳ９９）の時刻が最も早いセルサイド２０）となり、その条件に対して各参加者５０が発注先として決定する場合には、その旨をＰＯＰ１２０に通知する（Ｓ１０１）。
　各参加者５０から決定通知を受けたＰＯＰ１２０は、発注先として決定されたセルサイド２０（図１２の例ではセルサイドＡ（２０ａ））には取引成立を通知し（Ｓ１０２）、他のセルサイド２０（図１２の例ではセルサイドＢ（２０ｂ））には取引不成立を通知する（Ｓ１０３）。また、各参加者５０にも取引が成立した旨を通知する（Ｓ１０４）。
　なお、図１２の例では、参加者Ａ（５０ａ）が指定した執行ブローカーと、参加者Ｂ（５０ｂ）の指定による手数料の引き合いの結果決定した発注先のセルサイド２０とが、同じセルサイドＡ（２０ａ）である。したがって、参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）の双方がセルサイドＡ（２０ａ）に対して発注を行い（Ｓ１０５）、セルサイドＡ（２０ａ）より取引所システム４０を介してクロス取引の執行が行われた後（Ｓ１０６）、約定通知が参加者Ａ（５０ａ）および参加者Ｂ（５０ｂ）にそれぞれ通知される（Ｓ１０７）。
　以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　本発明は、取引の受発注や約定処理に係る業務を支援する証券取引管理システムに利用可能である。
１…証券取引管理システム、
１０…ネットワーク、２０…セルサイド、２０ａ…セルサイドＡ、２０ｂ…セルサイドＢ、２０ｃ…セルサイドＣ、２１…セルサイド端末、２２ａ、ｂ…ＩＯＩ、
３０…バイサイド、３０ａ…バイサイドＡ、３０ｂ…バイサイドＢ、３１…バイサイド端末、３２ａ、ｂ…ＩＯＩ、４０…取引所システム、５０ａ…参加者Ａ、５０ｂ…参加者Ｂ、
１００…ポテンシャルオーダープールシステム、１１０…マッチング処理部、１２０…ポテンシャルオーダープール、１２１…ポテンシャルオーダープールＤＢ、１２２…バイサイドマスタＤＢ、１２３…セルサイドマスタＤＢ、１２４…設定ＤＢ、
２００…セルサイドシステム、２１０…セルサイドＯＭＳ、２２０…バックシステム、
３００…バイサイドシステム、３１０…バイサイドＯＭＳ、３２０…バックシステム

Claims (8)

  1. 　相手方からの注文を受けてセルサイドが行う証券取引を管理する証券取引管理システムであって、
    　証券取引に参加する参加者となるバイサイドもしくはセルサイドにおいて相手方との間の注文を管理する注文管理システムを含む１つ以上の情報処理システムと、
    　前記各情報処理システムから取得した、前記各参加者のＩＯＩ（Indication of Interest）の情報をデータベースに記録し、前記各ＩＯＩに含まれる注文の間で売り買いをマッチングさせるポテンシャルオーダープールシステムと、を有する、証券取引管理システム。
  2. 　請求項１に記載の証券取引管理システムにおいて、
    　前記参加者の前記ＩＯＩには、前記参加者が将来実行する予定の注文であるポテンシャルオーダーの情報を含む、証券取引管理システム。
  3. 　請求項１に記載の証券取引管理システムにおいて、
    　前記ポテンシャルオーダープールシステムは、前記参加者であるバイサイドのＩＯＩに含まれる注文と、前記参加者であるセルサイドのＩＯＩに含まれる注文との間で売り買いをマッチングさせる、証券取引管理システム。
  4. 　請求項１に記載の証券取引管理システムにおいて、
    　前記ポテンシャルオーダープールシステムは、前記参加者である第１のバイサイドのＩＯＩに含まれる注文と、前記参加者である第２のバイサイドのＩＯＩに含まれる注文との間で売り買いをマッチングさせる、証券取引管理システム。
  5. 　請求項１に記載の証券取引管理システムにおいて、
    　前記ポテンシャルオーダープールシステムは、前記参加者である第１のセルサイドのＩＯＩに含まれる注文と、前記参加者である第２のセルサイドのＩＯＩに含まれる注文との間で売り買いをマッチングさせる、証券取引管理システム。
  6. 　請求項１に記載の証券取引管理システムにおいて、
    　前記ポテンシャルオーダープールシステムは、第１の参加者と第２の参加者との間でマッチングされた注文につき、前記第１の参加者により指定された執行先のセルサイドにおける第１の情報処理システム、および前記第２の参加者により指定された執行先のセルサイドにおける第２の情報処理システムに対して、前記注文に係るクロス取引の実行依頼を通知し、前記第１の情報処理システムおよび前記第２の情報処理システムの双方から承諾の通知を受領した場合に、前記注文に係る取引が成立した旨を前記第１の参加者における第３の情報処理システム、および前記第２の参加者における第４の情報処理システムに通知し、
    　前記第３の情報処理システムは、前記第１の情報処理システムに対して前記注文の発注を行い、
    　前記第４の情報処理システムは、前記第２の情報処理システムに対して前記注文の発注を行い、
    　前記第１の情報処理システムと、前記第２の情報処理システムとの間で前記注文に係るクロス取引を実行する、証券取引管理システム。
  7. 　請求項１に記載の証券取引管理システムにおいて、
    　前記ポテンシャルオーダープールシステムは、第１の参加者と第２の参加者との間でマッチングされた注文につき、前記第１の参加者により指定された執行先のセルサイドにおける第１の情報処理システムに対して、前記注文に係るクロス取引の実行依頼を通知し、前記第２の参加者により指定された手数料の引き合いにつき、前記参加者である前記各セルサイドにおける前記情報処理システムに対して手数料の引き合いを行い、最も有利な手数料を提示した前記セルサイドを発注先として決定し、前記第１の情報処理システムから前記クロス取引に係る承諾の通知を受領した場合に、前記注文に係る取引が成立した旨を前記第１の参加者における第３の情報処理システム、および前記第２の参加者における第４の情報処理システムと、手数料の引き合いを行った前記各セルサイドにおける前記情報処理システムに通知し、
    　前記第３の情報処理システムは、前記第１の情報処理システムに対して前記注文の発注を行い、
    　前記第４の情報処理システムは、発注先として決定された前記セルサイドにおける第２の情報処理システムに対して前記注文の発注を行い、
    　前記第１の情報処理システムと、前記第２の情報処理システムとの間で前記注文に係るクロス取引を実行する、証券取引管理システム。
  8. 　請求項１に記載の証券取引管理システムにおいて、
    　前記ポテンシャルオーダープールシステムは、第１の参加者と第２の参加者との間でマッチングされた注文につき、前記第１の参加者および前記第２の参加者により指定された手数料の引き合いにつき、それぞれ、前記参加者である前記各セルサイドにおける前記情報処理システムに対して手数料の引き合いを行い、各引き合いに対して最も有利な手数料を提示した前記セルサイドをそれぞれ第１の発注先および第２の発注先として決定し、前記注文に係る取引が成立した旨を前記第１の参加者における第１の情報処理システム、および前記第２の参加者における第２の情報処理システムと、手数料の引き合いを行った前記各セルサイドにおける前記情報処理システムに通知し、
    　前記第１の情報処理システムは、前記第１の発注先として決定された前記セルサイドにおける第３の情報処理システムに対して前記注文の発注を行い、
    　前記第２の情報処理システムは、前記第２の発注先として決定された前記セルサイドにおける第４の情報処理システムに対して前記注文の発注を行い、
    　前記第３の情報処理システムと、前記第４の情報処理システムとの間で前記注文に係るクロス取引を実行する、証券取引管理システム。
PCT/JP2015/068073 2015-06-23 2015-06-23 証券取引管理システム WO2016207981A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2017524319A JPWO2016207981A1 (ja) 2015-06-23 2015-06-23 証券取引管理システム
CA3026273A CA3026273C (en) 2015-06-23 2015-06-23 Securities transaction management system
PCT/JP2015/068073 WO2016207981A1 (ja) 2015-06-23 2015-06-23 証券取引管理システム
US15/852,771 US20180122011A1 (en) 2015-06-23 2017-12-22 Securities trading management system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/068073 WO2016207981A1 (ja) 2015-06-23 2015-06-23 証券取引管理システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/852,771 Continuation US20180122011A1 (en) 2015-06-23 2017-12-22 Securities trading management system

Publications (1)

Publication Number Publication Date
WO2016207981A1 true WO2016207981A1 (ja) 2016-12-29

Family

ID=57584907

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/068073 WO2016207981A1 (ja) 2015-06-23 2015-06-23 証券取引管理システム

Country Status (4)

Country Link
US (1) US20180122011A1 (ja)
JP (1) JPWO2016207981A1 (ja)
CA (1) CA3026273C (ja)
WO (1) WO2016207981A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210233168A1 (en) * 2020-01-29 2021-07-29 Jpmorgan Chase Bank, N.A. Method and system for processing orders on an electronic trading platform

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009277242A (ja) * 2002-12-17 2009-11-26 Masanobu Nishimaki 金融商品等交換取引プログラムを記録した記憶媒体、金融商品等交換取引システム及び商品交換取引方法
JP2010182311A (ja) * 2009-02-09 2010-08-19 Instinet Inc コンピュータ取引を行う方法およびシステム
JP2011065307A (ja) * 2009-09-16 2011-03-31 Hitachi Solutions Ltd 従業員持株会事務代行業務における単元株自動振替システム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040030624A1 (en) * 2000-07-24 2004-02-12 Ip Strategy Incorporated Storage medium storing a disintermediated financial transaction program, disintermediated financial transaction system and disintermediated financial transaction method
US11017410B2 (en) * 2006-12-30 2021-05-25 Cfph, Llc Methods and systems for managing and trading using a shared order book as internal exchange

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009277242A (ja) * 2002-12-17 2009-11-26 Masanobu Nishimaki 金融商品等交換取引プログラムを記録した記憶媒体、金融商品等交換取引システム及び商品交換取引方法
JP2010182311A (ja) * 2009-02-09 2010-08-19 Instinet Inc コンピュータ取引を行う方法およびシステム
JP2011065307A (ja) * 2009-09-16 2011-03-31 Hitachi Solutions Ltd 従業員持株会事務代行業務における単元株自動振替システム

Also Published As

Publication number Publication date
JPWO2016207981A1 (ja) 2018-02-22
CA3026273C (en) 2023-09-12
US20180122011A1 (en) 2018-05-03
CA3026273A1 (en) 2016-12-29

Similar Documents

Publication Publication Date Title
US8359260B2 (en) Trade execution methods and systems
US7574398B1 (en) Platform for market programs and trading programs
US8396790B2 (en) System and method for financing commercial transactions
US20060136318A1 (en) Automated system for routing orders for financial instruments
JP2005530281A (ja) 多数の契約相手が関与する金融取引を管理し、それに関するデータを処理するための方法及び装置
WO2010077376A1 (en) Trading system
US8285633B2 (en) System and method for direct client access for management of securities transactions
KR102582653B1 (ko) 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
US20190130507A1 (en) Systems and Methods for Monetizing Intellectual Property
US9928551B2 (en) Computer-implemented system and method for clearing a derivative trade involving multiple trading exchanges
JP2020170360A (ja) 情報取引プログラム及び情報処理装置
US8364554B2 (en) Method, system and computer program product for processing cooperative transactions
WO2016207981A1 (ja) 証券取引管理システム
US10453137B1 (en) Interacting anonymously in a network market
US10198768B2 (en) Order message flow routing engine and method
US7813991B1 (en) Automated trading negotiation protocols
KR20230086168A (ko) 수산물 유통 플랫폼의 거래명세서 생성시스템 및 생성방법
JP4205898B2 (ja) 外国為替取引システム
KR100774261B1 (ko) 보상 처리가 가능한 전자상거래 중개 시스템
CN109035008A (zh) 交易信息处理方法及交易系统
JP2005018287A (ja) 株式売買注文発注システム及び株式売買注文の発注方法
US20150356677A1 (en) Private fund exchange system
KR101482712B1 (ko) 국제간 투자 중개 시스템 및 이를 이용한 국제간 투자 중개 방법
JP2001283042A (ja) コンピュータオークションシステム
US20220237722A1 (en) Anonymous price and progressive display execution apparatus, system and method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15896303

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017524319

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15896303

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3026273

Country of ref document: CA