JP6810574B2 - Trading equipment, trading programs and trading methods - Google Patents

Description

The present invention relates to a trading device, a trading program and a trading method.

An online trading system is used in which an investor's computer and a financial instruments business operator's computer are connected by a communication line so that the investor can trade financial instruments online. An index value calculation device that supports an investor's judgment by calculating an index related to a transaction of a financial product from moment to moment and displaying it on an investor's computer has been proposed (Patent Document 1).

Japanese Unexamined Patent Publication No. 2014-102589

In financial instruments trading, such as foreign exchange margin trading, options trading or futures trading, investors deposit collateral margins into financial instruments traders before trading. Investors need to maintain sufficient margin for the total contracted amount of positions they hold.

When an investor acquires a new position for margin trading, the required margin increases according to the contracted amount of the acquired position. In order to avoid running out of margin at the same time as the contract, it is desirable to calculate the required margin after the contract and confirm that there is sufficient margin before placing the order.

An ordering method that is not always executed may be used, such as limit ordering in which a desired price is specified. When multiple such orders are placed in parallel, it is necessary to improve the operational efficiency of the margin when simply determining whether or not there is sufficient margin on the premise that all orders are executed. Is difficult.

On one side, the purpose is to provide a trading device or the like that enables investors who place multiple new orders in parallel, which are not always executed, to improve the efficiency of margin management.

The trading device acquires the contracted estimated price and transaction amount for each new order in a group containing multiple new orders for Forex Margin Trading that can trade foreign currencies with an amount equal to or greater than the collateralized effective margin. The group information acquisition unit, the order margin calculation unit that calculates the order margin for each of the new orders based on the expected contract price and the transaction amount acquired by the group information acquisition unit, and the order margin calculation unit Based on the order margin selection unit that selects the highest order margin among the calculated order margins, the order margin selected by the order margin selection unit, and the valid margin, the group is assigned. It is provided with a margin determination unit for determining excess or deficiency of the effective margin for the included new order.

On one side, it is possible for an investor who places a plurality of new orders in parallel, which are not always executed, to provide a trading device or the like that can improve the investment efficiency of margin.

It is explanatory drawing which shows the structure of a trading system. It is explanatory drawing which shows the record layout of the rate DB. It is explanatory drawing which shows the record layout of Delta TDB. It is explanatory drawing which shows the record layout of HLDB. It is explanatory drawing which shows the record layout of the investor information DB. It is explanatory drawing which shows the record layout of the order DB. It is explanatory drawing which shows the record layout of the order DB. It is explanatory drawing which shows the record layout of a position DB. It is explanatory drawing which shows the input screen example of an investor client. It is explanatory drawing explaining a new order by a delta order. It is explanatory drawing explaining the settlement order by a relative trigger trail order. It is explanatory drawing which shows the record layout of the order DB. It is explanatory drawing which shows the record layout of the order DB. It is a flowchart which shows the processing flow of the program of the rate recording server. It is a flowchart which shows the process flow of the program of an investor server. It is a flowchart which shows the processing flow of an order acceptance subroutine. It is a flowchart which shows the processing flow of the margin confirmation subroutine. It is a flowchart which shows the process flow of order margin update subroutine. It is a flowchart which shows the processing flow of the total order margin calculation subroutine. It is a flowchart which shows the processing flow of a position acquisition subroutine. It is a flowchart which shows the processing flow of the subroutine of delta determination. It is a flowchart which shows the processing flow of a position settlement subroutine. It is a flowchart which shows the processing flow of the stop trigger determination subroutine. It is a flowchart which shows the process flow of a relative trigger trail determination subroutine. It is explanatory drawing which shows the record layout of the order | order DB of Embodiment 2. It is a flowchart which shows the process flow of the position acquisition subroutine of Embodiment 2. It is a flowchart which shows the process flow of the position acquisition subroutine of Embodiment 3. It is a functional block diagram which shows the operation of the trading apparatus of Embodiment 4. It is explanatory drawing which shows the structure of the trading system of Embodiment 5.

[Embodiment 1]
FIG. 1 is an explanatory diagram showing a configuration of a trading system 10. The trading system 10 is a system used when trading financial products whose prices fluctuate from moment to moment. In the present embodiment, the trading system 10 used when conducting foreign exchange margin trading will be described as an example. The same system can be used for stock trading, futures trading, etc.

The trading system 10 includes an investor server 11, a rate recording server 21, an investor client 31, a financial institution server 32, and a network connecting them to each other.

The investor client 31 is an information processing device such as a personal computer, a tablet, or a smartphone that an investor uses for online transactions. The description of the hardware configuration of the investor client 31 will be omitted.

The financial institution server 32 is an information processing device used by banks and the like participating in the interbank market. The financial institution server 32 presents the market price of the exchange rate via the network at a frequency of about 10 to 100 times per second. The description of the hardware configuration of the financial institution server 32 will be omitted.

In the interbank market, each market participant presents the market price and conducts a transaction. Participants in the interbank market are limited to large banks with high creditworthiness and trading large amounts of foreign currency. On the other hand, foreign exchange margin trading is conducted at an exchange rate based on the market price formed in the interbank market.

The investor server 11 is an information processing device managed and operated by a financial instruments business operator. The investor server 11 is an information processing device that processes transactions of financial products received online from the investor client 31. In the present embodiment, the financial instruments business operator uses one investor server 11 for each investor who is a customer. The investor server 11 is an example of the trading device of the present embodiment.

The rate recording server 21 is an information processing device managed and operated by a financial instruments business operator. The rate recording server 21 is an information processing device that records and processes the market price presented by the financial institution server 32 and provides it to the investor server 11.

The investor server 11 includes a CPU (Central Processing Unit) 12, a main storage device 13, an auxiliary storage device 14, a communication unit 15, and a bus.

The CPU 12 is an arithmetic control device that executes a program according to the present invention. As the CPU 12, one or more CPUs, a multi-core CPU, or the like is used. The CPU 12 is connected to each part of the hardware constituting the investor server 11 via a bus.

The main storage device 13 is a storage device such as a SRAM (Static Random Access Memory), a DRAM (Dynamic Random Access Memory), and a flash memory. The main storage device 13 temporarily stores information necessary during the processing performed by the CPU 12 and the program being executed by the CPU 12.

The auxiliary storage device 14 is a storage device such as a SRAM, a flash memory, a hard disk, or a magnetic tape. The auxiliary storage device 14 stores a program to be executed by the CPU 12, an investor information DB (Database) 51, an order DB 52, an order DB 53, a position DB 54, and various data necessary for executing the program. The communication unit 15 is an interface for communicating between the investor server 11 and the network.

The investor server 11 of the present embodiment is an information device such as a general-purpose personal computer and a large-scale computer. Further, the investor server 11 of the present embodiment may be a virtual machine operating on a large-scale computer. The investor information DB 51, the order DB 52, the order DB 53, and the position DB 54 may be stored in a large-capacity storage device or the like installed outside the investor server 11.

The rate recording server 21 includes a rate recording CPU 22, a main storage device 23, an auxiliary storage device 24, a communication unit 25, and a bus.

The rate recording CPU 22 is an arithmetic control device that executes a program according to the present invention. As the rate recording CPU 22, one or more CPUs, a multi-core CPU, or the like is used. The rate recording CPU 22 is connected to each part of the hardware constituting the rate recording 21 via a bus.

The main storage device 23 is a storage device for SRAM, DRAM, flash memory, and the like. The main storage device 23 temporarily stores information necessary during the process performed by the rate recording CPU 22 and the program being executed by the rate recording CPU 22.

The auxiliary storage device 24 is a storage device such as a SRAM, a flash memory, a hard disk, or a magnetic tape. The auxiliary storage device 24 stores a program to be executed by the rate recording CPU 22, a rate DB41, an HDDB43, a delta TDB42, and various data necessary for executing the program. The communication unit 25 is an interface for communicating between the rate recording server 21 and the network.

The rate recording server 21 of the present embodiment is an information device such as a general-purpose personal computer or a large-scale computer. Further, the rate recording server 21 of the present embodiment may be a virtual machine operating on a large computer. The rate DB 41, HLDB 43, and delta TDB 42 may be stored in a large-capacity storage device or the like installed outside the rate recording server 21.

FIG. 2 is an explanatory diagram showing a record layout of the rate DB 41. The rate DB 41 is a DB that associates the market price of the selling price and the buying price for each currency pair with the time stamp. The rate DB 41 has a currency pair field, a sell rate field, a buy rate field, and a time stamp field.

In the currency pair field, the combination of two currencies for foreign exchange trading is recorded. For example, "USD / JPY" indicates a combination of US dollars and Japanese yen. Similarly, "EUR" stands for Euro, "GBP" stands for British Pound, and "AUD" stands for Australian Dollar.

In the sell rate field, the market price when an investor purchases the front currency in the back currency among the currency pairs recorded in the currency pair field is recorded. In the buy rate field, the market price of the currency pair recorded in the currency pair field when the investor sells the front currency in the rear currency is recorded.

In the time stamp field, the date and time when the market price was recorded in the rate DB 41 is recorded. The first half of the time stamp field indicates the date, and the second half indicates the time. The three digits after the decimal point of the time indicate the time in milliseconds. The rate DB 41 has one field for a set of currency pairs.

A specific example will be described. The first line of the rate DB41 shown in FIG. 2 is a rate of 100.096 yen per dollar for investors who want to sell the US dollar, and a rate of 100.104 yen per dollar for investors who want to buy the US dollar. Indicates that each was presented at the date and time indicated on the time stamp.

The rate recording CPU 22 updates the record of the corresponding currency pair each time it receives the market price presented by the financial institution server 32. That is, the latest market price at that time is recorded in the rate DB 41. The rate recording server 21 may receive the market price presented by one financial institution server 32 and record it in the rate DB 41, or may receive the market price presented by a plurality of financial institution servers 32 and record the market price in the rate DB 41. You may record in.

The rate recording server 21 may record the exchange rate presented by another financial instrument business operator in the rate DB 41. Further, the rate recording server 21 may record the market price determined by its own exchange dealer based on the market price of the interbank market.

FIG. 3 is an explanatory diagram showing a record layout of the delta TDB 42. The delta TDB 42 is a DB that associates the number with the determination time width ΔT. The delta TDB 42 has a number field and a ΔT field. In the number field, numbers are recorded sequentially from 1. The determination time width ΔT is recorded in the ΔT field. The delta TDB42 has one record for one number. The delta TDB 42 is a DB used when creating the HDDB 43 described below.

FIG. 4 is an explanatory diagram showing a record layout of the HLDB43. The HLDB43 is a DB that associates the time stamp, the market price at that time, with the past minimum market price L and the maximum market price H within the determination time width ΔT. The HLDB43 has a currency pair field, a trading field, a time stamp field, a market price field, a ΔT = 10 second field, and a ΔT = 30 second field. The ΔT = 10 second field and the ΔT = 30 second field have an L field and an H field, respectively. The HLDB43 is a DB used when placing a delta order described later.

In the currency pair field, the combination of two currencies for foreign exchange trading is recorded. In the buy / sell field, the distinction between "sell" and "buy" is recorded. A time stamp is recorded in the time stamp field. The market price field records the market price for foreign exchange transactions recorded in the currency pair field and the trading field.

In the L field of the ΔT = 10 second field, the cheapest market price in the past 10 seconds from the time of the time stamp is recorded. In the H field of the ΔT = 10 second field, the highest market price in the past 10 seconds from the time of the time stamp is recorded. In the L field of the ΔT = 30 second field, the cheapest market price in the past 30 seconds from the time of the time stamp is recorded. In the H field of the ΔT = 30 second field, the highest market price in the past 30 seconds from the time of the time stamp is recorded.

Although description is omitted in FIG. 4 except for the ΔT = 10-second field and the ΔT = 30-second field, the HLDB43 has a determination time width ΔT recorded in the ΔT field of the delta TDB42 described with reference to FIG. Has a corresponding field. Each field has an L field and an H field as well as a ΔT = 10 second field. The HLDB43 has one record for one time stamp.

A specific example will be described. The highest market price for the past 10 seconds from the time stamp of the second record from the top of FIG. 4 is "2016/09/05 10:00: 00.05" is 100.200 yen. The market price at the time when the time stamp of the third record from the top is "2016/09/05 10:00: 00.040" is 100.280 yen. Therefore, the highest market price for the past 10 seconds from the time of this record is 100.280 yen, and "100.280" is recorded in the H field of the ΔT = 10 second field.

FIG. 5 is an explanatory diagram showing a record layout of the investor information DB 51. The investor information DB 51 is a DB in which the investor server 11 records information about an investor who processes a transaction. The investor information DB 51 has an item field and a content field. In the item field, item names such as "investor ID (IDentification)", "name", and "margin" are recorded. In the content field, the content corresponding to each item is recorded. Margin will be described later.

FIG. 6 is an explanatory diagram showing a record layout of the order DB 52. The order DB 52 is a DB that associates the order number, the content of the order, and the order status of the foreign exchange transaction ordered from the financial instruments business operator.

The order DB 52 includes an order number field, a currency pair field, an order type field, a transaction type field, an execution condition field, an order price field, a trigger value field, a trigger width field, a trail width field, a ΔP field, a ΔT field, and a transaction amount field. It has a due date field, an order status field, an order margin field, a parent order number field and a margin group field.

The order number field records an order number that is uniquely assigned to each order. In the currency pair field, the currency pair ordered is recorded. In the order type field, which type of order is "new", "settlement profit settlement", or "settlement stop" is recorded. “New” means an order in which an investor acquires a new position. "Settlement profit settlement" means an order in which a position held by an investor is settled by counter-trading and the profit is settled. "Settlement stop" means a stop order in which the position held by the investor is settled by counter-trading and the loss is cut off.

In the transaction type field, whether the order is "sell" or "buy" is recorded. "Sell" means a sell order, and "buy" means a buy order. In the execution condition field, the type of judgment condition for executing the order is recorded. "Delta", "relative trigger trail" and "trail" will be described later.

“Limit” means to execute if the conditions are more favorable to the investor than the price recorded in the order price field described later. For example, in the case of a buy order, it is executed when the market price is lower than the order price. In the case of a sell order, it is executed when the market price is higher than the order price.

“Stop price” means to execute if the conditions are more disadvantageous to the investor than the price recorded in the order price field described later. For example, in the case of a buy order, it is executed when the market price is higher than the order price. In the case of a sell order, it is executed when the market price is lower than the order price.

The order price field records the order price specified by the investor. If a "-" is recorded in the order price field, it means that the price is undecided.

In the trigger value field, the trigger width field, the trail width field, the ΔP field and the ΔT field, the parameters when the execution conditions are “delta”, “relative trigger trail” and “trail” are recorded. Details of each parameter will be described later.

The transaction amount field records the transaction amount ordered by the customer. The transaction amount is shown using the currency shown on the left side of the currency pair. Specifically, order number 101 indicates an order of $ 1000 in US dollars.

The expiration date of the order is recorded in the expiration field. "GTC" is an abbreviation for Good Till Cancel and means an order that is valid indefinitely. The order status field records the status of the order. "Ordering" indicates an order to be filled when the conditions specified by the investor and the market price are met. "Waiting" indicates an order that becomes valid when the related order is filled. In the order status field, "established" indicating that the order has been executed, "cancelled" indicating that the order has been canceled, and the like are also recorded.

The order margin field records the order margin required for placing a new order. The order margin will be described later. When placing a settlement order, an order margin is not required, so "-" is recorded.

The parent order number field records the order number of the associated new order. For example, since the order number 101 is a new order, there is no parent order. Therefore, "-" is recorded in the parent order number field. Since the order number 102 and the order number 103 are settlement orders of the order number 101, "101" is recorded in the parent order number field.

In the margin group field, the number of the margin group that treats the order margin as one group is recorded. The margin group will be described later. When placing a settlement order, an order margin is not required, so "-" is recorded.

FIG. 7 is an explanatory diagram showing a record layout of the order DB 53. The order DB 53 is a DB that associates the order number, the content of the order, and the order status of the foreign exchange transaction to be executed when the conditions specified by the investor and the market price are matched.

The order DB 53 includes an order number field, a currency pair field, an order type field, a transaction type field, an execution condition field, an order price field, a trigger value field, a trigger width field, a trail width field, a ΔP field, a ΔT field, and a transaction amount field. It has a deadline field, an order margin field, a parent order number field and a margin group field. Since the data recorded in each field is the same as the order DB 52 described with reference to FIG. 6, the description thereof will be omitted.

FIG. 8 is an explanatory diagram showing a record layout of the position DB 54. The position DB 54 is a DB that associates the order number of the position held by the investor, the content of the position, and the number of the related order. The position DB 54 has an order number field, a currency pair field, a transaction type field, a contract price field, a transaction amount field, a contract date and time field, and a settlement order number field. The settlement order number field has a profit taking field and a stop field.

The order number field records an order number that is uniquely assigned to each order. In the currency pair field, the currency pair ordered is recorded. In the transaction type field, whether the position is "sell" or "buy" is recorded. "Sell" means a position taken by a sell order, and "buy" means a position taken by a buy order.

In the contract price field, the contract price at the time of taking a position is recorded. The transaction amount of the position is recorded in the transaction amount field. The date and time when the position was executed is recorded in the execution date and time field. The order number of the profit taking order is recorded in the profit taking field. The order number of the stop order is recorded in the stop field.

Here, the margin and the order margin will be described. Margin indicates the amount of money that an investor has pledged as collateral to a financial instruments business operator. In Forex Margin Trading, investors can take a sell or buy position in a foreign currency that is higher than the margin, with the margin as collateral. Investors obtain profit or loss according to exchange fluctuations by closing the positions they hold by counter-trading.

In the following explanation, the amount obtained by subtracting the profit / loss when the position held by the investor is marked to market from the margin deposited by the investor is referred to as the effective margin. The effective margin is the amount equivalent to the margin that remains in the hands of the investor when all the positions held are settled at the market price.

Similarly, the amount obtained by adding a predetermined margin rate to the price at the time of acquiring the position held by the investor is called the required margin. Investors need to maintain a valid margin above the required margin. If the effective margin is less than the required margin, the financial instruments business operator forcibly closes the position held by the investor, so-called loss cut. Loss cuts can prevent investors from incurring losses beyond the margin they have deposited.

When an investor acquires a new position, the required margin increases according to the acquisition price. If the effective margin is less than the required margin after the increase, a loss cut may occur immediately after the position is acquired and the investor may suffer a loss.

In order to avoid such losses, when placing a new order, it is desirable to confirm whether the investor's effective margin in the case of execution is sufficient. In the present embodiment, the CPU 12 calculates the order margin for each new order based on the equation (1) and records it in the order margin field of the order DB 52.
Margin for order = Expected contract price x Transaction amount x Margin rate ‥‥‥ (1)
The order margin is the amount of margin required that increases when a new order is executed at the exchange rate of the estimated execution price.

When a new order is received from an investor, the CPU 12 calculates an order margin for the new order. The CPU 12 calculates a total order margin, which is the total amount of order margins for unfilled orders including new orders received. The CPU 12 accepts a new order when the effective margin is equal to or greater than the sum of the total order margin and the required margin. The CPU 12 does not accept a new order if the effective margin is less than the sum of the total order margin and the required margin.

However, investors may make investments assuming multiple scenarios. For example, if you assume both a scenario where the yen strengthens and a scenario where the yen weakens, and you place a new order based on each scenario, the order evidence for the scenario that did not come true. Money is not used.

In the present embodiment, new orders are divided into margin groups according to the margin groups recorded in the margin group fields of the order DB 52 and the order DB 53. For the order margin of a new order belonging to one margin group, the order margin of one new order having the highest order margin in the margin group is used. If any one new order in the margin group is filled, the other new order in the same margin group and the corresponding settlement order are cancelled. That is, multiple new orders within one margin group share the order margin.

The margin group can provide a trading device or the like that can improve the operational efficiency of margin when a plurality of scenarios are assumed and a plurality of scenarios are performed in parallel for each scenario.

As described above, the CPU 12 can prevent a new order in which the required margin exceeds the effective margin immediately after the execution and a loss cut is likely to occur.

The CPU 12 can use the market price at the date and time when the order from the investor is received as the expected contract price of the formula (1). The CPU 12 can also extract the latest record from the HDDB43 described with reference to FIG. 4 and use the value recorded in the H field of any determination time width ΔT for the estimated contract price. By doing so, the required margin that increases when the contract is actually executed greatly exceeds the order margin calculated based on the equation (1), and the possibility of loss cut can be reduced.

The CPU 12 can use a value obtained by adding a predetermined safety factor to the market price at the date and time when the order from the investor is received as the expected contract price in the formula (1). Any numerical value of 1 or more can be used for the safety factor. By doing so, it is possible to reduce the possibility of loss cut when an investor orders and executes a currency pair whose market price fluctuates sharply.

The CPU 12 may change the safety factor depending on the investment performance of the investor, the conditions such as the assets held, the currency pair to be ordered, the situation of the foreign exchange market, and the like.

FIG. 9 is an explanatory diagram showing an example of an input screen of the investor client 31. The investor client 31 displays the input screen shown in FIG. 9 on the display based on the information received from the investor server 11 via the network. The investor client 31 receives input by the investor via an input device such as a touch panel, a keyboard, or a mouse, and transmits the input to the investor server 11 via the network. The security of communication between the investor server 11 and the investor client 31 is ensured by an encryption technology such as SSL (Secure Sockets Layer).

The input screen includes a currency pair field 61, an amount field 62, a new field 63, a settlement field 64, and an establishment repetition field 65. The new column 63 includes a new type column 631 and a new order column 632. The settlement column 64 includes a settlement type column 641, a profit-taking order column 642, and a stop order column 643. In FIG. 9, the selected item is shown by being surrounded by a double line.

The CPU 12 accepts a currency pair traded by an investor via the currency pair column 61. The CPU 12 receives the amount of money traded by the investor via the amount column 62. The CPU 12 accepts whether the new order is "sell" or "buy" via the new type column 631. The CPU 12 displays a state in which the opposite transaction of the order received in the new type column 631 is selected in the settlement type column 641.

The CPU 12 accepts execution conditions and parameters of a new order via the new order field 632. The CPU 12 accepts execution conditions and parameters of the profit taking order via the profit taking order column 642. The CPU 12 accepts the execution conditions and parameters of the stop order via the stop order column 643.

The CPU 12 accepts whether or not to repeat the same order again after the settlement order is filled through the establishment repetition column 65. In FIG. 9, "Off" means that the order is not repeated. "PL + Repeat" means that an order with the same conditions is repeated when a profit is generated when a settlement order is executed, and no repetition is performed when a profit is not generated.

FIG. 10 is an explanatory diagram illustrating a new order by a delta order. The vertical axis shows the market price. The horizontal axis shows time. Black circles indicate the market price at each time. The delta order will be described with reference to FIG.

It is empirically known that the market price fluctuates irregularly in the short term, but in the long term, it often fluctuates periodically by repeating the uptrend market and the downtrend market. It is also empirically known that, among trend markets, so-called range markets, in which market prices fluctuate within a narrow price range, often occur.

Investors make investments by predicting how market prices will fluctuate. In particular, the buy position taken at the timing of transition from the range market to the uptrend market is settled at the end of the uptrend market, and the sell position taken at the timing of transition from the range market to the downtrend market is closed at the end of the uptrend market. Investors can profit efficiently by making payments from time to time.

In FIG. 10, the current time is indicated by t _A. The market price at time t _A is A. The start time of the time T of the determination time width ΔT is the time t _{S, and the} end time is the time t _E. Here, the time t _E is a time stamp immediately before the time t _A. The lowest market price L and the highest market price H within the time from time t _S to time t _E are indicated by symbols H and L in FIG.

The time t _E in the time stamp field of one of the record of HLDB43 described using Figure 4, market field price E at time t _E to the market price field, the lowest market price L to L field, the best in the H field The market price H is recorded respectively.

When the market price enters the upward trend market, as shown in FIG. 10, the difference between the market price A and the minimum market price L is the product of the unit judgment price width ΔP and the judgment time width ΔT. It will be larger than the width. The CPU 12 determines that the conditions for the delta order are satisfied, and executes the execution. Here, the unit determination price width ΔP and the determination time width ΔT are parameters related to the delta order.

The delta orders described above are briefly summarized. The determination time width ΔT is a parameter indicating the time width for determining whether or not the market price has entered the uptrend market or the downtrend market. The unit determination price range ΔP is a parameter indicating the price range per unit time for determining whether or not the market price has entered the uptrend market or the downtrend market.

In the present embodiment, the market price of the CPU 12 rises when the difference between the market price A and the minimum market price L exceeds the determination price range, which is the product of the unit determination price width ΔP and the determination time width ΔT. It is used as an indicator that the market has entered the trend market. Similarly, the CPU 12 enters the downward trend market when the difference between the highest market price H and the market price A exceeds the judgment price range which is the product of the unit judgment price width ΔP and the judgment time width ΔT. It is used as an index to indicate that.

As shown in FIG. 10, the CPU 12 takes a buy position at price A at time t _A immediately after the market price enters the upward trend market, and settles at market price B at time t _B when the market price rises sufficiently. By doing so, a profit corresponding to the difference between the price B and the price A is generated. Similarly, the CPU 12 takes a sell position immediately after the market price enters the downtrend market and setstles after the market price has fallen sufficiently, so that a profit corresponding to the difference between the sell price and the purchase price is generated.

Investors who anticipate an uptrend market will direct buy orders by delta orders. Even if the investor does not monitor the transition of the market price in real time, the CPU 12 automatically takes an advantageous position when an uptrend market occurs. If the forecast is wrong and the uptrend market does not occur, the CPU 12 does not perform the process of taking a buy position, so that it is possible to avoid the occurrence of a loss.

Investors who anticipate a downtrend market will direct sell orders by delta orders. Even if the investor does not monitor the transition of the market price in real time, the CPU 12 automatically takes an advantageous position when a downtrend market occurs. If the forecast is wrong and the downtrend market does not occur, the CPU 12 does not perform the process of taking a sell position, so that it is possible to avoid the occurrence of a loss.

The CPU 12 may accept inputs of the unit determination price width ΔP and the determination time width ΔT based on the minimum price range unit pips. If you are an investor dealing with various exchange pairs, it may be easier to grasp the price movement of foreign exchange by using pips.

The CPU 12 may accept the input of the determination price range instead of the unit determination price range ΔP. It is possible to meet the demands of investors who want to consider the judgment time width ΔT and the judgment price width separately.

The CPU 12 may accept the unit determination price range ΔP as a relative value to the market price. For example, it can be set as 5% of the market price at the time of order entry, the highest market price H, the lowest market price L, or the average value of the highest market price H and the lowest market price L.

FIG. 11 is an explanatory diagram illustrating a settlement order by a relative trigger trail order. The vertical axis shows the market price. The horizontal axis shows time. Black circles indicate the market price at each time. A relative trigger trail order will be described with reference to FIG.

The trail order is an ordering method that automatically corrects the price of the stop order in real time according to the increase or decrease of the market price, and is used for the stop order. In the relative trigger trail order, the initial value of the trail order is relatively determined.

The case where the buy position is taken at the market price A at the time t _A will be described as an example. Here the buy position can be taken using the delta order described with reference to FIG. In addition, a buy position may be taken by a limit order or a market order that has been widely used in the past.

The CPU 12 sets the trigger price Trig of the relative trigger trail order by adding the trigger width ΔTg of the profit-taking order to the market price A which is the buy position price. The CPU 12 sets the stop order price as the price S1 obtained by subtracting the trail width ΔS of the stop order from the market price A which is the buy position price. The stop order price is a stop order for executing a stop order in which the held position is settled by counter-trading and the loss is cut off.

The CPU 12 sequentially acquires the market price. Since the price S2 obtained by subtracting the trail width ΔS of the stop order from the market price P23 at the time t23 is higher than the price S1, the CPU 12 changes the stop order price to the price S2. Similarly, since the price S3 obtained by subtracting the trail width ΔS of the stop order from the market price P24 at the time t24 is higher than the price S2, the CPU 12 changes the stop order price to the price S3 at the time t24.

At time t25, the CPU 12 determines that the market price P25 exceeds the trigger price Trig. The CPU 12 sets the trail price as the price M1 obtained by subtracting the trail width ΔR of the profit-taking order from the market price P25. The trail price is the price at which a stop order is placed to settle the held position by counter-trading and confirm the profit. Further, at time t25, the CPU 12 cancels the stop order.

Since the price M2 obtained by subtracting the trail width ΔR from the market price P26 at time t26 is higher than the trail price M1, the CPU 12 sets the price M2 to the trail price. Since the market price B at time t _B is equal to or less than the trail price M2, the CPU 12 executes a profit taking order.

The relative trigger trail orders described above are briefly summarized. The trigger width ΔTg of the profit-taking order is a parameter that determines the trail starting price of the relative trigger trail order. The trail width ΔR of the profit-taking order is a parameter that determines the fluctuation amount of the stop price of the relative trigger trail order.

In the present embodiment, the CPU 12 relatively sets the trigger price for starting the trail of the trail price with respect to the acquisition price of the position. Even if the price of the position is not fixed until it is filled, as in the delta order described with reference to FIG. 10, the CPU 12 takes profit after market price fluctuations in the level and direction expected by the investor. Start the trail of the order.

In FIG. 11, a case where a buy position is taken and a sell settlement is performed has been described as an example. Similarly, even when taking a sell position and making a buy settlement, the CPU 12 can execute a relative trigger trail order.

In foreign exchange trading, so-called slippage may occur in which the order price and the contract price are different even for limit orders due to network time lag. By using the relative trigger trail order, the CPU 12 can determine the trigger price to start the trail of the profit taking order based on the contract price of the position even when slippage occurs.

FIG. 12 is an explanatory diagram showing a record layout of the order DB 52. FIG. 13 is an explanatory diagram showing a record layout of the order DB 53. The outline of the process performed by the CPU 12 will be described with reference to FIGS. 6 to 13. Further, each parameter recorded in the trigger value field, the trigger width field, the trail width field, the ΔP field, and the ΔT field of the order DB 52 and the order DB 53 will be described.

FIG. 6 shows an order DB 52 in a state in which three new orders acquired by the CPU 12 and each settlement order are recorded via the screen described with reference to FIG. Order number 101 is a new buy order using a delta order, order number 102 is a settlement profit taking order using a relative trigger trail order, and order number 103 is a settlement stop order using a trail order. Order number 104 is a new sell order using a delta order, order number 105 is a settlement profit taking order using a relative trigger trail order, and order number 106 is a settlement stop order using a trail order. Order number 107 is a new buy order using a limit order, order number 108 is a settlement profit taking order using a limit order, and order number 106 is a settlement stop order using a stop order.

Since the order number 101 and the order number 104 are delta orders, the order prices are undecided. Therefore, "-" is recorded in the order price field. The unit determination price width ΔP and the determination time width ΔT, which are the parameters of the delta order described with reference to FIG. 10, are recorded in the ΔP field and the ΔT field, respectively. Since no trigger value, trigger width and trail width parameters are specified, "-" is recorded in these fields.

The order prices of order number 102 and order number 105 are undecided. Therefore, "-" is recorded in the order price field. The trigger width ΔTg and the trail width ΔR, which are the parameters of the relative trigger trail order described with reference to FIG. 11, are recorded in the trigger width field and the trail width field, respectively. Since the trigger value, the unit determination price width ΔP, and the determination time width ΔT are not specified, “−” is recorded in these fields.

The order prices of order numbers 103 and 106 are also undecided. Therefore, "-" is recorded in the order price field. The trail width ΔS, which is a parameter of the trail order described with reference to FIG. 11, is recorded in the trail width field. Since the trigger value, the trigger width, the unit determination price width ΔP, and the determination time width ΔT are not specified, “−” is recorded in these fields.

Since order numbers 107 to 109 are limit orders and stop orders, the prices are recorded in the order price field. Since the trigger value, the trigger width, the trail width, the unit determination price width ΔP, and the determination time width ΔT are not specified, “−” is recorded in these fields.

"Ordering" is recorded in the order status fields of the new orders, order number 101, order number 104 and order number 107. Since the new order has not been filled, the order status field of the settlement order associated with each new order is recorded as "waiting".

The CPU 12 extracts a record in which "ordering" is recorded in the order status field with reference to the order DB 52 described with reference to FIG. 6, and collates it with the order DB 53 using the order number field as a key. If the record extracted from the order DB 52 includes a record that is not recorded in the order DB 53, the CPU 12 copies the corresponding record to the order DB 53. FIG. 7 shows an order DB 53 in a state where copying is completed.

The CPU 12 determines whether or not each record recorded in the order DB 53 can be executed based on the execution conditions, each parameter, and the market price. If it is determined that the contract is not possible, the market price is reacquired and the determination of the contractability is repeated. For a record in which the order price is not recorded in the order price field, the CPU 12 determines whether or not the contract can be executed after determining that the execution conditions and the conditions indicated by the parameters are satisfied.

If it is determined that the contract is possible, the order DB 53 executes the contract with the trading partner according to a predetermined trading protocol. Since the trading protocol for financial instruments has been used conventionally, the description thereof will be omitted.

The CPU 12 performs processing on a plurality of records recorded in the order DB 53 in parallel.

FIG. 12 shows the order DB 52 after the order number 101 is executed. The CPU 12 records "contract" in the order status field of the record of the order number 101. The CPU 12 searches the parent order number field of the order DB 52 and extracts the order number 102 and the order number 103, which are settlement orders corresponding to the order number 101. The CPU 12 records "ordering" in the order status field of the record of the order number 102 and the order number 103.

The CPU 12 deletes the record corresponding to the executed order number 101 from the order DB 53 described with reference to FIG. 7. The CPU 12 extracts a record in which "ordering" is recorded in the order status field with reference to the order DB 52 described with reference to FIG. 12, and collates it with the order DB 53 using the order number field as a key. Of the records extracted from the order DB 52, the order number 102 and the order number 103 are not recorded in the order DB 53. Therefore, the CPU 12 copies the records corresponding to the order number 102 and the order number 103 to the order DB 53.

The CPU 12 records a value obtained by adding the trigger width ΔTg to the contract price of the position in the trigger value field of the record of the order number 102 which is a relative trigger trail order. The CPU 12 records a value obtained by adding the trail width ΔS to the contract price of the position in the order price field of the record of the order number 103 which is a trail order. FIG. 13 shows an order DB 53 in a state where the above processing is completed.

The CPU 12 determines whether or not to execute the contract based on the execution conditions, the parameters, and the market price for each record including the record added to the order DB 53.

FIG. 14 is a flowchart showing a processing flow of the program of the rate recording server 21. A flow of processing in which the rate recording CPU 22 of the present embodiment generates the HLDB 43 will be described with reference to FIG.

The rate recording CPU 22 acquires the market price presented by the financial institution server 32 via the network (step S501). The rate recording CPU 22 creates a new record in the HDD B43 described with reference to FIG. 4 and records the time stamp and the market price in their respective fields (step S502).

The rate recording CPU 22 sets the counter I to the initial value 1 (step S503). The rate recording CPU 22 extracts a record whose number field matches the counter I from the delta TDB 42 described with reference to FIG. 3, and acquires the determination time width ΔT recorded in the ΔT field (step S504).

The rate recording CPU 22 refers to the time stamp field and the market price field of the HDD B43 to extract the highest value H of the market price within the time of the latest determination time width ΔT (step S505). The rate recording CPU 22 refers to the time stamp field and the market price field of the HDD B43 to extract the lowest value L of the market price within the time of the latest determination time width ΔT (step S506). The rate recording CPU 22 records the lowest value L in the L field and the highest value H in the H field corresponding to the determination time width ΔT of the record created in step S502 (step S507).

The rate recording CPU 22 determines whether or not the processing of all the records of the delta TDB 42 has been completed (step S508). If it is determined that the process has not been completed (NO in step S508), the rate recording CPU 22 returns to step S504. When it is determined that the program has been completed (YES in step S508), the rate recording CPU 22 determines whether or not to terminate the program (step S509). Here, the case where the program is determined to be terminated is the case where the instruction to terminate the program is received from the financial instruments business operator.

If it is determined that the process does not end (NO in step S509), the rate recording CPU 22 returns to step S501. If it is determined to end (YES in step S509), the rate recording CPU 22 ends the process.

FIG. 15 is a flowchart showing a processing flow of the program of the investor server 11. The flow of processing performed by the CPU 12 will be described with reference to FIG. Note that FIG. 15 shows a program that performs a series of processing of accepting a new order, acquiring a position, and making a settlement. The CPU 12 executes a number of programs corresponding to new orders in parallel.

The CPU 12 activates the order acceptance subroutine (step S521). The order acceptance subroutine is a subroutine that accepts an order from the investor client 31 via the network. The processing flow of the order acceptance subroutine will be described later.

The CPU 12 activates the margin confirmation subroutine (step S523). The margin confirmation subroutine is a subroutine that confirms whether or not the margin is sufficient. The processing flow of the margin confirmation subroutine will be described later.

The CPU 12 determines whether or not the margin is sufficient based on the processing result of the margin confirmation subroutine (step S524). When it is determined that the margin is sufficient (YES in step S524), the CPU 12 activates the position acquisition subroutine (step S525). The position acquisition subroutine is a subroutine that performs a process of acquiring a new position based on the order received in step S521. The processing flow of the position acquisition subroutine will be described later.

The CPU 12 updates the order DB 52 based on the processing result of step S525 (step S526). Specifically, when a contract is executed, "contract" is recorded in the order status field of the order record of the executed new order, and "ordering" is recorded in the order status field of the order record of the corresponding settlement order. If the position acquisition subroutine is terminated without execution due to reasons such as the expiration of the deadline recorded in the deadline field, "Cancel" is recorded in the order status field of the unfilled new order and the corresponding settlement order. ..

The CPU 12 updates the order DB 53 based on the processing result of step S525 (step S527). Specifically, the CPU 12 deletes the order record processed in step S526. Further, the CPU 12 copies the record related to the settlement order corresponding to the settled new order from the order DB 52 to the order DB 53.

The CPU 12 determines whether or not the position acquired in step S525 exists (step S528). If it is determined that it exists (YES in step S528), the CPU 12 activates the position settlement subroutine (step S529). The position settlement subroutine is a subroutine that performs processing to settle the held position. The processing flow of the position settlement subroutine will be described later.

The CPU 12 updates the order DB 52 based on the processing result of step S529 (step S530). Specifically, "contract" is recorded in the order status field of the order record of the executed settlement order, and "cancellation" is recorded in the order status field of the order record of the unfilled settlement order.

The CPU 12 updates the order DB 53 (step S531). Specifically, the order record processed in step S529 is deleted. When it is determined that the position acquired in step S525 does not exist (NO in step S528) and after the end of step S531, the CPU 12 ends the process.

When it is determined that the margin is insufficient (NO in step S524), the CPU 12 indicates to the investor client 31 via the network that the margin is insufficient (step S535). The CPU 12 deletes the record related to the order received in step S521 from the order DB 52 and the order DB 53 (step S536). The CPU 12 then ends the process.

FIG. 16 is a flowchart showing a processing flow of the order acceptance subroutine. The order acceptance subroutine is a subroutine that accepts an order from the investor client 31 via the network. The processing flow of the order acceptance subroutine will be described with reference to FIG.

The CPU 12 transmits information necessary for displaying an input screen to the CPU of the investor client 31 via the network. The CPU of the investor client 31 displays the input screen described with reference to FIG. 9 on the display unit of the investor client 31. In the following description, the processing by the CPU of the investor client 31 is omitted, and the description is described as "the CPU 12 displays the input screen on the investor client 31" (step S551).

The CPU 12 accepts the input of the foreign exchange margin trading order via the input screen (step S552). The CPU 12 determines whether or not there is an error in the entered order (step S553). An error occurs, for example, when the limit price of a new buy order is higher than the market price.

If it is determined that there is an error (YES in step S553), the CPU 12 displays the content of the error on the investor client 31 (step S554), and returns to step S551. When it is determined that there is no error (NO in step S553), the CPU 12 assigns an order number to the order for which the input is accepted (step S555).

The CPU 12 records the order contents received in step S552 in the order DB 52 (step S556). The CPU 12 records a new order in the order DB 53 among the order contents received in step S552 (step S557). After that, the CPU 12 ends the process.

FIG. 17 is a flowchart showing a processing flow of the margin confirmation subroutine. The margin confirmation subroutine is a subroutine that confirms whether or not the margin is sufficient. The processing flow of the margin confirmation subroutine will be described with reference to FIG.

The CPU 12 acquires the market price of each foreign exchange from the rate DB 41 (step S571). The CPU 12 may acquire the market price directly from the financial institution server 32 via the network.

The CPU 12 sets the variable “total profit / loss” to the initial value 0 (step S572). The CPU 12 sets the counter I to the initial value 1 (step S573). The CPU 12 extracts the I-th position record from the position DB 54 and calculates the market value profit / loss based on the equation (2) (step S574).
Market value = (market price-contract price) x transaction amount ‥‥‥ (2)
Here, the market price is the price at which the held position is settled by the opposite transaction.

The CPU 12 adds the market value calculated in step S574 to the variable “total profit / loss” (step S575). The CPU 12 determines whether or not the processing of all the positions recorded in the position DB 54 has been completed (step S576). If it is determined that the process has not been completed (NO in step S576), the CPU 12 adds 1 to the counter I (step S577). The CPU 12 returns to step S574.

When it is determined that the processing of all positions has been completed (YES in step S576), the CPU 12 calculates the effective margin based on the equation (3) (step S581).
Effective Margin = Margin + Market Value Gain / Loss (3)

The CPU 12 activates a subroutine for updating the order margin (step S582). The order margin update subroutine is a subroutine that updates the data recorded in the order margin field of the order DB 53 based on the market price. The processing flow of the subroutine for updating the order margin will be described later.

The CPU 12 activates a subroutine for calculating the total order margin (step S583). The subroutine for calculating the total order margin is a subroutine for calculating the total order margin, which is the sum of the order margins for new orders. The processing flow of the subroutine for calculating the total order margin will be described later.

The CPU 12 calculates the required margin by multiplying the total contract price, which is the sum of the contract prices recorded in the contract price field of the position DB 54, by a predetermined margin rate (step S584). Margin requirement is the margin required to maintain the position held. The margin rate is a value specified in a contract between a financial instruments business operator and an investor, and is, for example, 4%.

The CPU 12 determines whether or not the effective margin is equal to or greater than the sum of the required margin and the total order margin (step S585). If it is determined that the effective margin is equal to or greater than the sum of the required margin and the total order margin (YES in step S585), the CPU 12 determines that "the margin is sufficient" and the main storage device 13 or the auxiliary storage device. Store in 14 (step S586). The CPU 12 then ends the process.

If it is determined that the effective margin is less than the sum of the required margin and the total order margin (NO in step S585), the CPU 12 determines that "the margin is insufficient" and the main storage device 13 or the auxiliary storage. Store in the device 14 (step S587). The CPU 12 then ends the process.

FIG. 18 is a flowchart showing a processing flow of the order margin update subroutine. The order margin update subroutine is a subroutine that updates the data recorded in the order margin field of the order DB 53 based on the market price. A flow of processing of the subroutine for updating the order margin will be described with reference to FIG.

The CPU 12 acquires the market price of each foreign exchange from the rate DB 41 (step S601). The CPU 12 sets the counter I to the initial value 1 (step S602). The CPU 12 acquires the I-th order record from the order DB 53 (step S603). The CPU 12 refers to the order type field of the acquired order record and determines whether or not the order record is a new order (step S604).

When it is determined that the order record is a new order (YES in step S604), the CPU 12 determines whether or not the order margin is fixed by referring to the execution condition field (step S605). Specifically, when the execution condition is "limit price" or "stop price", the order margin is fixed. If the execution condition is such that the order price fluctuates according to the market price such as "Delta", the order margin is not fixed.

If it is determined that the order margin has not been determined (NO in step S605), the CPU 12 calculates a new order margin based on the equation (1) (step S606). The CPU 12 updates the order margin field of the order DB 53 with the order margin calculated in step S606 (step S607).

When it is determined that the order record is not a new order (NO in step S604), when it is determined that the order margin is fixed (YES in step S605), and after the end of step S607, the CPU 12 performs all of the order DB 53. It is determined whether or not the processing of the record of is completed (step S608).

If it is determined that the process has not been completed (NO in step S608), the CPU 12 adds 1 to the counter I (step S609). The CPU 12 returns to step S603. If it is determined that the process is completed (YES in step S608), the CPU 12 ends the process.

Note that the CPU 12 may omit step S601 and use the market price acquired by the calling program in this subroutine as well. By omitting the process of acquiring the market price, it is possible to speed up the process of the subroutine for updating the order margin.

Further, the CPU 12 may acquire the market price between step S605 and step S606. By acquiring the market price immediately before calculating the order margin, the latest market price can be reflected in the order margin.

FIG. 19 is a flowchart showing a processing flow of the total order margin calculation subroutine. The subroutine for calculating the total order margin is a subroutine for calculating the total order margin, which is the sum of the order margins for new orders. A flow of processing of the subroutine for calculating the total order margin will be described with reference to FIG.

The CPU 12 sets the variable "total order margin" to the initial value 0 (step S921). The CPU 12 sets the variable G (J) to the initial value 0 (step S922). Where J is an integer from 1 to the number of margin groups. The variable G (J) is a variable temporarily used to extract the maximum value of the order margin of the Jth group.

The CPU 12 sets the counter I to the initial value 1 (step S923). The CPU 12 acquires the I-th order record from the order DB 53 (step S924). The CPU 12 refers to the order type field of the acquired order record and determines whether or not the order record is a new order (step S925).

If it is determined that the order record is a new order (YES in step S925), the CPU 12 refers to the margin group field of the acquired order record and determines whether or not the margin group is set (YES). Step S926). For example, when "-" is recorded in the margin group field, the CPU 12 determines that the margin group is not set.

If it is determined that the margin group has not been set (YES in step S926), the CPU 12 adds the order margin recorded in the order margin field to the variable "total order margin" (step S927).

If it is determined that the margin group has been set (NO in step S926), the CPU 12 sets the variable J to the margin group recorded in the margin group field (step S931). The CPU 12 determines whether or not the variable G (J) for extracting the maximum margin of the Jth group is equal to or less than the order margin recorded in the order margin field of the record acquired in step S924 (step). S932). When it is determined that G (J) is less than the order margin (YES in step S932), the CPU 12 substitutes the order margin into the variable G (J) (step S933).

When it is determined that it is not an order record for a new order (NO in step S925), after the end of step S927, when it is determined that G (J) is equal to or greater than the order margin (NO in step S932), and after the end of step S933. , The CPU 12 determines whether or not the processing of all the records in the order DB 53 is completed (step S934).

If it is determined that the process has not been completed (NO in step S934), the CPU 12 adds 1 to the counter I (step S935). The CPU 12 returns to step S924. As described above, by repeating the processes from step S924 to step S933, the maximum value of the order margin for the new order of the Jth group is set in the variable G (J).

When it is determined that the processing of all the records in the order DB 53 is completed (YES in step S934), the CPU 12 sets the counter K to 1 (step S941).

The CPU 12 adds the maximum value G (K) of the order margin for new orders in the Kth group to the variable “total order margin” (step S942). The CPU 12 determines whether or not the processing of all margin groups has been completed (step S943).

If it is determined that the process has not been completed (NO in step S943), the CPU 12 adds 1 to the counter K (step S944). The CPU 12 returns to step S942. If it is determined that the process is completed (YES in step S943), the CPU 12 ends the process.

FIG. 20 is a flowchart showing the processing flow of the position acquisition subroutine. The position acquisition subroutine is a subroutine that performs a process of acquiring a new position based on the order received in step S521. The processing flow of the position acquisition subroutine will be described with reference to FIG. In the present embodiment, the execution condition of the new order acquired in step S521 is either a delta order, a limit order, or a market order.

The CPU 12 determines whether or not the execution condition of the new order acquired in step S521 is a delta order (step S641). When it is determined that the order is delta (YES in step S641), the CPU 12 activates the subroutine for delta determination (step S642). The delta determination subroutine is a subroutine that determines whether or not the market price has shifted to an uptrend or a downtrend beyond a predetermined fluctuation range. The processing flow of the delta judgment subroutine will be described later.

The CPU 12 determines whether or not the processing result of the delta determination subroutine is ON (step S643). If it is determined that it is not ON (NO in step S643), the CPU 12 determines whether or not to end the processing of the delta order (step S644). For example, when the deadline recorded in the deadline field of the order DB 53 has passed, when an instruction to cancel the order is obtained from the investor client 31, or when the investor's trading account is lost due to insufficient margin balance, etc. The CPU 12 determines that the processing of the delta order is completed.

If it is determined that the process does not end (NO in step S644), the CPU 12 returns to step S642.

If it is determined that the order is not a delta order (NO in step S641), the CPU 12 determines whether or not the execution condition of the new order acquired in step S521 is a limit order (step S651). When it is determined that the order is not a limit order (NO in step S651) and when it is determined that the processing result of the delta determination subroutine is ON (YES in step S643), the CPU 12 processes the market execution to execute the execution at the market price. (Step S645).

If it is determined that the order is a limit order (YES in step S651), the CPU 12 acquires the foreign exchange market price from the rate DB 41 (step S652). The CPU 12 may acquire the market price directly from the financial institution server 32 via the network.

The CPU 12 compares the order price recorded in the order price field of the order record with the market price, and determines whether or not the limit order can be completed (step S653). Specifically, in the case of a buy order, the CPU 12 determines that a limit order can be established when the market price is lower than the order price. In the case of a sell order, the CPU 12 determines that the limit order can be completed when the market price is higher than the order price.

When it is determined that the establishment is not possible (NO in step S653), the CPU 12 determines whether or not to end the processing of the limit order (step S654). For example, when the deadline recorded in the deadline field of the order DB 53 has passed, when an instruction to cancel the order is obtained from the investor client 31, or when the investor's trading account is lost due to insufficient margin balance, etc. The CPU 12 determines that the limit order processing is completed. If it is determined that the limit order process is not completed (NO in step S654), the CPU 12 returns to step S652.

When it is determined that the limit order can be established (YES in step S653), the CPU 12 performs the execution process by the limit order (step S655).

After the end of step S645 or step S655, the CPU 12 refers to the margin group field of the order record for the filled new order and determines whether or not the margin group is recorded (step S951). If it is determined that the margin group has been recorded (YES in step S951), the CPU 12 cancels another order belonging to the same margin group (step S952).

Specifically, the CPU 12 searches the order DB 53 using the margin group field as a key, extracts records of the same margin group, and deletes them from the order DB 53. The CPU 12 searches the order DB 52 using the margin group field as a key, extracts records of the same margin group, and records "cancelled" in the order status field. Further, the CPU 12 also records "cancelled" in the order status field of the settlement order corresponding to the new order in which "cancelled" is recorded.

When it is determined that the margin group is not recorded (NO in step S951) and after the end of step S952, the CPU 12 determines the order number, currency pair, transaction type, contract price, transaction amount, and contract of the order executed in the position DB 54. Record the date and time and the number of the settlement order (step S656). The CPU 12 uses the executed order number as a key to search the parent order number field of the order DB 52 to extract the order number of the settlement order, the profit-taking order, and the stop order.

When it is determined to end the processing of the delta order (YES in step S644), when it is determined to end the processing of the limit order (YES in step S654), and after the end of step S656, the CPU 12 ends the processing.

FIG. 21 is a flowchart showing a processing flow of the delta determination subroutine. The delta determination subroutine is a subroutine that determines whether or not the market price has shifted to an uptrend or a downtrend beyond a predetermined fluctuation range. The processing flow of the delta determination subroutine will be described with reference to FIG.

The CPU 12 acquires the latest HL record from the HLDB43 using the currency pair to be ordered as a key (step S671). The CPU 12 acquires a rate record from the rate DB 41 using the currency pair to be ordered as a key (step S672).

The CPU 12 determines whether or not the time stamps recorded in the time stamp fields of the HL record acquired in step S671 and the rate record acquired in step S672 match each other (step S673). If it is determined that they match (YES in step S673), the CPU 12 acquires the HL record immediately before the HLDB43 (step S674).

When it is determined that the time stamps do not match (NO in step S673) and after the end of step S674, the CPU 12 determines whether or not the order being processed is a buy order (step S675).

When it is determined that the order is a buy (YES in step S675), the CPU 12 determines the relationship between the market price, the past trend, and the condition at the time of ordering based on the equation (4) (step S676).
Market price −L ≧ ΔP × ΔT ‥‥‥ (4)
The market price is the price recorded in the buy rate field of the rate record acquired in step S672.
ΔP is the unit determination price range ΔP, which is a parameter of the delta order.
ΔT is the determination time width ΔT, which is a parameter of the delta order.
L is the price recorded in the L field corresponding to the determination time width ΔT of the order condition of the HL record acquired in step S671, and indicates the lowest price within the period of the determination time width ΔT.

When it is determined that the equation (4) is true (YES in step S676), the CPU 12 determines that the processing result is ON and stores it in the main storage device 13 or the auxiliary storage device 14 (step S677). The CPU 12 then ends the process.

When it is determined that the equation (4) is false (NO in step S676), the CPU 12 determines that the processing result is "OFF" and stores it in the main storage device 13 or the auxiliary storage device 14 (step S678). ). The CPU 12 then ends the process.

When it is determined that the order is not a buy order (NO in step S675), the CPU 12 determines the relationship between the market price, the past trend, and the condition at the time of ordering based on the equation (5) (step S681).
H-Market price ≧ ΔP × ΔT ‥‥‥ (5)
The market price is the price recorded in the selling rate field of the rate record acquired in step S672.
ΔP is the unit determination price range ΔP, which is a parameter of the delta order.
ΔT is the determination time width ΔT, which is a parameter of the delta order.
H is the price recorded in the H field corresponding to the determination time width ΔT of the order condition of the HL record acquired in step S671, and indicates the highest price within the period of the determination time width ΔT.

When it is determined that the equation (5) is true (YES in step S681), the CPU 12 determines that the processing result is ON and stores it in the main storage device 13 or the auxiliary storage device 14 (step S682). The CPU 12 then ends the process.

When it is determined that the equation (5) is false (NO in step S681), the CPU 12 determines that the processing result is "OFF" and stores it in the main storage device 13 or the auxiliary storage device 14 (step S683). ). The CPU 12 then ends the process.

FIG. 22 is a flowchart showing the processing flow of the position settlement subroutine. The position settlement subroutine is a subroutine that performs processing to settle the held position. The processing flow of the position settlement subroutine will be described with reference to FIG. In the present embodiment, the execution condition of the settlement profit settlement order acquired in step S521 is the relative trigger trail order or the limit order, and the execution condition of the settlement stop order is the trail order.

The CPU 12 determines whether or not the settlement profit determination condition of the new order acquired in step S521 is a relative trigger trail order (step S701). If it is determined that the order is a relative trigger trail order (YES in step S701), the CPU 12 acquires the foreign exchange market price from the rate DB 41 (step S702).

The CPU 12 determines whether or not the profit taking trigger for starting the trail of the profit taking order is ON (step S703). Specifically, in the case of a buy order, when the market price acquired in step S702 satisfies the equations (6) and (7), the CPU 12 determines that the profit taking trigger is ON.
Market price> Trigger price Trig ‥‥‥ (6)
Trigger price Trig = Contract price at the time of new order + ΔTg ‥‥‥ (7)
ΔTg is the trigger width ΔTg, which is a parameter of the relative trigger trail order.

Similarly, in the case of a sell order, when the market price acquired in step S702 satisfies the equations (8) and (9), the CPU 12 determines that the profit taking trigger is ON.
Market price <Trigger price Trig ‥‥‥ (8)
Trigger price Trig = Contract price at the time of new order-ΔTg ‥‥‥ (9)

When it is determined that the profit determination trigger is ON (YES in step S703), the CPU 12 activates the subroutine of the relative trigger trail determination (step S704). The relative trigger trail determination subroutine is a subroutine that determines that the condition of the relative trigger trail is satisfied while trailing the stop price according to the market price. The processing flow of the subroutine for determining the relative trigger trail will be described later. The CPU 12 performs stop price execution based on the condition determined by the subroutine of the relative trigger trail determination (step S705).

When it is determined that the profit determination trigger is not ON (NO in step S703), the CPU 12 activates the stop trigger determination subroutine (step S711). The stop trigger determination subroutine is a subroutine that determines whether or not to perform loss cut by a settlement stop order. The processing flow of the stop trigger determination subroutine will be described later.

The CPU 12 determines whether or not the processing result of the stop trigger determination subroutine is "stop" (step S712). If it is determined that it is not "stop" (NO in step S712), the CPU 12 returns to step S702. If it is determined to be "stop" (YES in step S712), the CPU 12 performs a market execution process for executing the contract at the market price (step S713).

If it is determined that the order is not a relative trigger trail order (NO in step S701), the CPU 12 acquires the foreign exchange market price from the rate DB 41 (step S721). The CPU 12 determines whether or not the limit order of the settlement profit settlement order can be established (step S722). When it is determined that the establishment is possible (YES in step S722), the CPU 12 executes the limit execution based on the execution condition of the settlement profit settlement order (step S723).

When it is determined that the limit order cannot be fulfilled (NO in step S722), the CPU 12 activates the stop trigger determination subroutine (step S724). The subroutine for determining the stop trigger is the same subroutine as the subroutine started in step S711.

The CPU 12 determines whether or not the processing result of the stop trigger determination subroutine is "stop" (step S725). If it is determined that it is not a "stop" (NO in step S725), the CPU 12 returns to step S721. If it is determined to be "stop" (YES in step S725), the CPU 12 performs a market execution process for executing the contract at the market price (step S726).

After the end of step S705, step S713, step S723 or step S726, the CPU 12 deletes the record relating to the new order settled from the position DB 54 (step S731). After that, the CPU 12 ends the process.

FIG. 23 is a flowchart showing the processing flow of the stop trigger determination subroutine. The stop trigger determination subroutine is a subroutine that determines whether or not to perform loss cut by a settlement stop order. The processing flow of the stop trigger determination subroutine will be described with reference to FIG. 23.

The CPU 12 determines whether or not the order to be determined is a sell order (step S752). If it is determined that the order is a sell (YES in step S752), the CPU 12 acquires the foreign exchange market price from the rate DB 41 (step S753).

The CPU 12 determines whether or not the market price is equal to or less than the trigger value of the stop order (step S754). When it is determined that the value is not equal to or less than the trigger value of the stop order (NO in step S754), the CPU 12 determines whether or not the relationship between the market price and the trigger value satisfies the equation (10) (step S755).
Market price −ΔS> Trigger value ‥‥‥ (10)
ΔS is the trail width ΔS of the stop order.

When it is determined that the equation (10) is true (YES in step S755), the CPU 12 changes the trigger value to the value on the left side of the equation (10) (step S756). By the process of step S756, the CPU 12 changes the stop order price of the sell order, that is, trails, following the rise in the market price.

When it is determined that the equation (10) is not true (NO in step S755) and after the end of step S756, the CPU 12 determines that the processing result is "continuation" and causes the main storage device 13 or the auxiliary storage device 14 to determine. Store (step S757). The CPU 12 then ends the process.

If it is determined that the order is not a sell order (NO in step S752), the CPU 12 acquires the foreign exchange market price from the rate DB 41 (step S761).

The CPU 12 determines whether or not the market price is equal to or higher than the trigger value of the stop order (step S762). When it is determined that the value is not equal to or greater than the trigger value of the stop order (NO in step S762), the CPU 12 determines whether or not the relationship between the market price and the trigger value satisfies the equation (11) (step S763).
Market price + ΔS> Trigger value ‥‥‥ (11)
ΔS is the trail width ΔS of the stop order.

When it is determined that the equation (11) is true (YES in step S763), the CPU 12 changes the trigger value to the value on the left side of the equation (10) (step S764). By the process of step S764, the CPU 12 changes the stop order price of the buy order, that is, trails, following the decline in the market price.

When it is determined that the equation (11) is not true (NO in step S763) and after the end of step S764, the CPU 12 determines that the processing result is "continuation" and causes the main storage device 13 or the auxiliary storage device 14 to determine. Store (step S765). The CPU 12 then ends the process.

When it is determined in the sell order that the market price is equal to or less than the trigger value of the stop order (YES in step S754), and when it is determined in the buy order that the market price is equal to or greater than the trigger value of the stop order (YES in step S762). ), The CPU 12 determines that the processing result is "stop" and stores it in the main storage device 13 or the auxiliary storage device 14 (step S771). The CPU 12 then ends the process.

FIG. 24 is a flowchart showing the processing flow of the relative trigger trail determination subroutine. The relative trigger trail determination subroutine is a subroutine that determines that the condition of the relative trigger trail is satisfied while trailing the stop price according to the market price. The processing flow of the subroutine of the relative trigger trail determination will be described with reference to FIG.

The CPU 12 determines whether or not the order to be determined is a sell order (step S791). When it is determined that the order is a sell (YES in step S791), the CPU 12 sets the order price to a value obtained by subtracting the trail width ΔR of the profit-taking order from the market price (step S792). Here, the order price is the stop order price.

The CPU 12 acquires the foreign exchange market price from the rate DB 41 (step S793). The CPU 12 determines whether or not the value obtained by subtracting the trail width ΔR of the profit-taking order from the market price is equal to or greater than the order price (step S794). If it is determined that the above is not the case (NO in step S794), the CPU 12 returns to step S792.

When it is determined that the above is the case (YES in step S794), the CPU 12 determines whether or not the market price is equal to or less than the order price (step S795). If it is determined that the above is not the case (NO in step S795), the CPU 12 returns to step S793.

When it is determined that the order is not a sell order (NO in step S791), the CPU 12 sets the order price to a value obtained by adding the trail width ΔR of the profit-taking order to the market price (step S796). Here, the order price is the stop order price.

The CPU 12 acquires the foreign exchange market price from the rate DB 41 (step S797). The CPU 12 determines whether or not the value obtained by adding the trail width ΔR of the profit-taking order to the market price is equal to or less than the order price (step S798). If it is determined that the above is not the case (NO in step S798), the CPU 12 returns to step S796.

When it is determined that the following is true (YES in step S798), the CPU 12 determines whether or not the market price is equal to or higher than the order price (step S799). If it is determined that the above is not the case (NO in step S799), the CPU 12 returns to step S797.

If it is determined in the sell order that the market price is less than or equal to the order price (YES in step S795), and if it is determined in the buy order that the market price is greater than or equal to the order price (YES in step S799), the CPU 12 processes. finish.

The CPU 12 may accept only new orders. For example, in the case of an investor who wants to hold a long-term holding and an investor who wants to confirm the market price in real time and settle a market order, only the position acquisition can be left to the trading device of this embodiment. Similarly, the CPU 12 may only accept settlement orders for positions already held.

According to this embodiment, by using a margin group in which a plurality of new orders share an order margin, it is possible to provide a trading device or the like capable of improving the operational efficiency of the margin.

According to the present embodiment, it is possible to realize a trading device that automatically takes an advantageous position at the initial stage of the trend market by placing a new order by the delta order described with reference to FIG.

According to the present embodiment, a trading device is realized in which a settlement order is placed by the relative trigger trail order described with reference to FIG. 11 and the position is automatically settled under favorable conditions immediately after the peak of the trend market is detected. be able to.

According to this embodiment, it is possible to realize a trading device capable of processing not only delta orders but also new orders by limit orders or market orders that have been conventionally used. Further, it is possible to realize a trading device capable of realizing a trading device capable of processing a settlement profit settlement order by a limit order in addition to a relative trigger trail order. It is possible to realize a trading device capable of executing an execution condition of a new order and an execution condition of a settlement order in any combination.

[Embodiment 2]
The present embodiment relates to a trading device that prevents another order from being executed when one new order belonging to the same margin group is executed. The description of the parts common to the first embodiment will be omitted.

FIG. 25 is an explanatory diagram showing a record layout of the order DB 53 of the second embodiment. The order DB 53 of the present embodiment includes an order number field, a currency pair field, an order type field, a transaction type field, an execution condition field, an order price field, a trigger value field, a trigger width field, a trail width field, a ΔP field, and a ΔT field. It has a transaction amount field, a deadline field, an order margin field, a parent order number field, a margin group field and a flag field. Since the data recorded in each field except the flag field is the same as that in the first embodiment, the description thereof will be omitted.

In the flag field, a flag indicating that there is a new order with a close execution in the group is recorded. That is, in FIG. 25, since the margin group 1 includes new orders with close executions, “ON” is recorded in the flag fields of the records of order number 101 and order number 104. "-" Is recorded in the flag field of other records.

After determining that the contract is possible, the CPU 12 refers to the flag field and does not perform the contract if it is recorded as "ON". On the other hand, if "-" is recorded, "ON" is recorded in the flag field of another new order record of the same margin group, and then the execution is performed. As described above, it is possible to provide a trading device that prevents a plurality of new orders belonging to the same margin group from being executed based on a plurality of programs operating in parallel.

FIG. 26 is a flowchart showing a processing flow of the position acquisition subroutine of the second embodiment. The subroutine shown in FIG. 26 is a subroutine used in place of the position acquisition subroutine described with reference to FIG.

Since steps S641 to S644 and steps S651 to S654 are the same as those in FIG. 20, the description thereof will be omitted. When it is determined that the order is not a limit order (NO in step S651) and when it is determined that the processing result of the delta determination subroutine is ON (YES in step S643), the CPU 12 determines that the flag field of the order record related to the order being processed. (Step S961), it is determined whether or not "ON" is recorded with reference to.

When it is determined that "ON" is recorded (YES in step S961), the CPU 12 ends the process. When it is determined that "ON" is not recorded (NO in step S961), the CPU 12 searches the order DB 53 using the margin field as a key, extracts new orders belonging to the same margin group, and sets the flag field. “ON” is recorded (step S962). The CPU 12 performs a market execution process for executing a contract at a market price (step S645).

When it is determined that the limit order can be completed (YES in step S653), the CPU 12 refers to the flag field of the order record related to the order being processed and determines whether or not "ON" is recorded (YES). Step S966).

When it is determined that "ON" is recorded (YES in step S966), the CPU 12 ends the process. When it is determined that "ON" is not recorded (NO in step S966), the CPU 12 searches the order DB 53 using the margin field as a key, extracts new orders belonging to the same margin group, and sets the flag field. “ON” is recorded (step S967). The CPU 12 processes the execution by the limit order (step S655).

The processing after the completion of step S644, step S645, step S654, and step S655 is the same as that in FIG. 20, and thus the description thereof will be omitted.

According to this embodiment, it is possible to provide a trading device that prevents a plurality of new orders belonging to the same margin group from being executed based on a plurality of programs operating in parallel.

If it is determined in step S961 or step S966 that "ON" is recorded in the flag field, the CPU 12 may adjust the priority with the program processing another new order immediately before the execution. Specifically, the CPU 12 stops the execution of new orders with low priority and executes new orders with high priority based on the size of the order number, the predetermined priority obtained from the investor client 31, and the like. Is also good.

[Embodiment 3]
The present embodiment relates to a trading device that confirms margin immediately before a contract. The description of the parts common to the first embodiment will be omitted.

FIG. 27 is a flowchart showing a processing flow of the position acquisition subroutine of the third embodiment. The subroutine shown in FIG. 27 is a subroutine used in place of the position acquisition subroutine described with reference to FIG.

Since steps S641 to S644 and steps S651 to S654 are the same as those in FIG. 20, description thereof will be omitted. When it is determined that the order is not a limit order (NO in step S651) and when it is determined that the processing result of the delta determination subroutine is ON (YES in step S643), the CPU 12 uses the margin described with reference to FIG. Invokes a confirmation subroutine (step S971).

The CPU 12 determines whether or not the margin is sufficient based on the processing result of the margin confirmation subroutine (step S972). When it is determined that the margin is sufficient (YES in step S972), the CPU 12 performs a market execution process for executing the contract at the market price (step S645). If it is determined that the margin is insufficient (NO in step S972), the CPU 12 ends the process.

When it is determined that the limit order can be completed (YES in step S653), the CPU 12 activates the margin confirmation subroutine described with reference to FIG. 17 (step S976).

The CPU 12 determines whether or not the margin is sufficient based on the processing result of the margin confirmation subroutine (step S977). When it is determined that the margin is sufficient (YES in step S977), the CPU 12 processes the execution by the limit order (step S655). If it is determined that the margin is insufficient (NO in step S977), the CPU 12 ends the process.

The processing after the completion of step S644, step S645, step S654, and step S655 is the same as that in FIG. 20, and thus the description thereof will be omitted.

According to the present embodiment, by confirming the margin immediately before the contract, it is possible to provide a trading device that prevents the investor from suffering a loss due to a loss cut immediately after the contract.

[Embodiment 4]
FIG. 28 is a functional block diagram showing the operation of the trading device according to the fourth embodiment. The investor server 11, which is an example of the trading device of the present embodiment, operates as follows based on the control by the CPU 12.

The investor server 11 includes a group information acquisition unit 91, an order margin calculation unit 92, an order margin selection unit 93, and a margin determination unit 94. The group information acquisition unit 91 sets the expected contract price and transaction amount for each new order in the group including a plurality of new orders for foreign exchange margin trading that can trade foreign currency with an amount equal to or more than the effective margin as collateral. To get. The order margin selection unit 92 calculates the order margin for each new order based on the expected contract price and the transaction amount acquired by the group information acquisition unit 91. The order margin selection unit 93 selects the highest order margin among the order margins calculated by the order margin calculation unit. The margin determination unit 94 determines the excess or deficiency of the effective margin for a new order included in the group based on the order margin selected by the order margin selection unit 93 and the effective margin.

[Embodiment 5]
The fifth embodiment relates to a mode in which the trading apparatus of the present embodiment is realized by operating a general-purpose computer and a program 71 in combination. FIG. 29 is an explanatory diagram showing the configuration of the trading system 10 of the fifth embodiment. The configuration of the present embodiment will be described with reference to FIG. 29. The description of the parts common to the first embodiment will be omitted.

In the trading system 10 of the present embodiment, the trading system 10 includes an investor machine 74, a rate recording machine 75, an investor client 31, a financial institution server 32, and a network connecting them to each other.

The investor machine 74 and the rate recording machine 75 managed and operated by the financial instruments business operator are general-purpose personal computers, information devices such as large-scale computers, and the like. Further, the investor machine 74 and the rate recording machine 75 of the present embodiment may be virtual machines operating on a large-scale computer.

The investor machine 74 includes a CPU 12, a main storage device 13, an auxiliary storage device 14, a communication unit 15, a reading unit 16, and a bus. The rate recording machine 75 includes a rate recording CPU 22, a main storage device 23, an auxiliary storage device 24, a communication unit 25, and a bus.

The program 71 is recorded on the portable recording medium 72. The CPU 12 reads the program 71 via the reading unit 16 and stores it in the auxiliary storage device 14. Further, the CPU 12 may read the program 71 stored in the semiconductor memory 73 such as the flash memory mounted in the investor machine 74. Further, the CPU 12 may download the program 71 from the communication unit 15 and another server computer (not shown) connected via the network and store the program 71 in the auxiliary storage device 14.

The portion of the program 71 executed by the investor machine 74 is installed as a control program of the investor machine 74, loaded into the main storage device 13 and executed. As a result, the investor machine 74 functions as the investor server 11 described above.

Further, the portion of the program 71 executed by the rate recording machine 75 is installed as a control program of the rate recording machine 75 via the network, and is loaded and executed in the main storage device 23. As a result, the rate recording machine 75 functions as the rate recording server 21 described above.

The technical features (constituent requirements) described in each embodiment can be combined with each other, and by combining them, a new technical feature can be formed.
The embodiments disclosed this time should be considered as exemplary in all respects and not restrictive. The scope of the present invention is indicated by the scope of claims, not the above-mentioned meaning, and is intended to include all modifications within the meaning and scope equivalent to the scope of claims.

10 Trading system 11 Investor server (trading device)
12 CPU
13 Main storage device 14 Auxiliary storage device 15 Communication unit 16 Reading unit 21 Rate recording server 22 Rate recording CPU
23 Main storage device 24 Auxiliary storage device 25 Communication unit 31 Investor client 32 Financial institution server 41 Rate DB
42 Delta TDB
43 HLDB
51 Investor Information DB
52 Order DB
53 Ordering DB
54 Position DB
61 Currency pair column 62 Amount column 63 New column 631 New type column 632 New order column 64 Payment column 641 Payment type column 642 Profit taking order column 643 Stop order column 65 Repeat column 71 Program 72 Portable recording medium 73 Semiconductor memory 74 Investor Machine 75 Rate Recording Machine 91 Group Information Acquisition Department 92 Order Margin Calculation Department 93 Order Margin Selection Department 94 Margin Judgment Department

Claims (8)

Group Information Acquisition Department that acquires the expected contract price and transaction amount for each new order in a group that includes multiple new orders for foreign exchange margin trading that can trade foreign currency with an amount equal to or greater than the effective margin as collateral. When,
An order margin calculation unit that calculates an order margin for each of the new orders based on the expected contract price and transaction amount acquired by the group information acquisition unit.
Of the order margin calculated by the order margin calculation unit, the order margin selection unit that selects the highest order margin and the order margin selection unit
A trading device including an order margin selected by the order margin selection unit and a margin determination unit for determining excess or deficiency of the effective margin for a new order included in the group based on the effective margin. .. The trading apparatus according to claim 1, further comprising a canceling unit for canceling another new order included in the group when one of the new orders included in the group is filled. The trading device according to claim 2, wherein the cancellation unit cancels a new order included in the group when the margin determination unit determines that the effective margin is insufficient. Equipped with a market price acquisition department that sequentially acquires the market prices of financial products
The trading apparatus according to any one of claims 1 to 3, wherein the contracted estimated price is the market price of each new order acquired by the market price acquisition unit. It is provided with a contract determination unit that determines whether or not the new order can be executed based on the market price acquired by the market price acquisition unit.
The execution determination unit does not determine whether or not the other new orders included in the group can be executed when it is determined that one of the new orders included in the group can be executed. Trading equipment. Equipped with a margin acquisition department to acquire the margin required to maintain the position held
In the margin determination unit, when the sum of the required margin acquired by the required margin acquisition unit and the order margin selected by the order margin selection unit for each of the groups exceeds the effective margin. The trading device according to any one of claims 1 to 5, wherein it is determined that the effective margin is insufficient. Obtain the expected contract price and transaction amount for each new order in a group that includes multiple new orders for Forex Margin Trading that can trade foreign currency with an amount equal to or greater than the effective margin as collateral.
The order margin for each of the new orders is calculated based on the expected contract price and the transaction amount.
Select the highest order margin from the above order margins,
A trading program that causes a computer to execute a process of determining excess or deficiency of the valid margin for a new order included in the group based on the selected order margin and the valid margin. Obtain the expected contract price and transaction amount for each new order in a group that includes multiple new orders for Forex Margin Trading that can trade foreign currency with an amount equal to or greater than the effective margin as collateral.
The order margin for each of the new orders is calculated based on the expected contract price and the transaction amount.
Select the highest order margin from the above order margins,
A trading method in which a computer is made to execute a process of determining excess or deficiency of the effective margin for a new order included in the group based on the selected order margin and the effective margin.

Images