NL2004104C2 - DISTRIBUTED TRADE SYSTEM. - Google Patents

Description

Field of the Invention Distributed Trading System

The present invention relates to a trading system for trading in financial instruments, such as shares on different stock exchange floors.

State of the art

United States Patent US-A-2008/0033865 discloses an electronic trading system on which an auto-arbitration process is performed. A multiplicity of 10 "trader" terminals is connected to a computer via a computer network. The computer is designed to automatically detect and even execute arbitrage opportunities based on data received from the "trader" terminals (bid and ask prices for a financial instrument) (if a trader has allowed this in advance). This document offers no further details with regard to mutual locations of parts of the system, speed of the connections between them or the conversion of data.

Summary of the invention

The present invention seeks to provide an improved trading system for performing arbitration, thereby improving the reliability and robustness of the trading system. The aforementioned trading system uses extensive computer networks, whereby a trader's computer is sometimes connected to the final "stock exchange" terminals via many other computers in the network. This entails delays in the exchange of data, whereby the delays are also not predictable.

According to the present invention, a trading system is provided for executing a financial transaction, comprising: one or more trading machines with one or more engines each arranged to automatically generate a financial transaction and to send a financial transaction instruction to at least one electronic exchange via an input communication line from the electronic exchange and receiving a confirmation signal from the at least one electronic exchange after completion of the financial transaction via an output communication line from the electronic exchange, • a monitoring system that has an associated monitor for each engine -including instance, wherein each trading machine is arranged as a computer system with a processor and memory, which memory for implementation of each engine engine software and engine parameter values has been stored for automatically controlling a financial transaction, and wherein the monitoring system is also arranged as a computer system with a monitoring system processor and a monitoring system memory with monitoring software, which allows a user to create each monitoring instance, wherein each monitoring instance comprises a copy of the engine software and engine parameter values of the associated engine, and the monitoring software enables the monitoring system processor during operation to: • have a user make changes to the copies of the engine software and engine parameter values stored for the monitor instance and • load updated engine software and engine parameter values thus obtained on the associated engine 20 and each engine software enabling the trading machine's processor to: • automatically use the updated engine software and engine parameter values to control the financial transaction upon receipt thereof.

25

In a further aspect, the present invention relates to a method for executing a financial transaction on a trading system as defined above, which method comprises: • having a user make changes to the copies of the engine software stored on the monitor instance and engine parameter values, • loading updated engine software and engine parameter values thus obtained onto the associated engine, and 3 • the associated engine's automatic use of the updated engine software and engine parameter values, after receipt, for controlling the financial transaction.

In a further aspect, the present invention relates to a computer-readable medium provided with instructions executable thereon by a computer system which, when the stored instructions are loaded, confer on the computer system the functionality of the method according to one of the embodiments of the present invention .

10

Brief description of the drawings

The present invention will now be discussed in more detail with reference to a number of exemplary embodiments, with reference to the accompanying drawings, in which

FIG. 1 shows a schematic representation of a trading system according to an embodiment of the present invention;

FIG. 2 shows a schematic representation of functional components in the trading system of FIG. 1 and 20. 3 shows an example of a computer system.

Detailed description of exemplary embodiments

The present invention relates to a number of embodiments of a trading system for trading in a financial instrument, such as a share. An arbitrator (who can use such a trading system) is someone who makes use of inefficiencies in the (financial) markets. By comparing prices of products in the market with your own theoretical prices, profitable transactions can be concluded. The Nokia share is taken as an example and the common thread throughout this story. The share is traded on both the Finnish and German stock exchanges. Because it is the same share, the price of this share must in principle be the same on both exchanges. But for several reasons this does not always have to be the case: suppose in both Finland and Germany there is a bid 4 for 500 pieces at € 9.98, a bid for 500 pieces at € 9.99, a bid for 1000 at € 10.00, and an offer (offered) of 500 pieces at € 10.01. In table form: € 10.01 [5ÖÖ 1000 € 10.00 1ÖÖ € 9.99 1ÖÖ € 9.98 5 Suppose further that a party in Finland wants to sell 2000 items at 9.99. Then there is traded for 1000 pieces at 10.00, 500 at 9.99 and the remainder (500) becomes the new sacrifice. In other words: in Finland there is now a bid of 500 out of 9.98 and 500 pieces are now being offered out of 9.99. Graphic: € 10.01 | ~ 5ÖÖ € 9.99 5ÖÖ 1ÖÖ € 9.98

The interesting thing now is that in Germany the market is still € 10.00 at € 10.01. 10 In other words: in Finland you can buy at € 9.99 and immediately sell it in Germany for € 10.00. Suppose that this is done, then for 500 pieces, then the market is then in Germany: € 10.01 | ~ 5ÖÖ ~ 5ÖÖ € 10.00 and in Finland: € 10.01 | ~ 5ÖÖ 1ÖÖ € 9.98 15

Now arbitration is no longer possible. This shows that when there is "free money", this situation will generally only last for a short time; the market corrects itself.

Meanwhile, 1 cent is earned per share, so 5 euros. Even though there is now a 20 long position in Finland (a positive number of shares held) and a short position in it

Germany (there are pieces borrowed, as it were), that penny is earned no matter what the market does. If Nokia rises, it will do so in both Germany and Finland.

5

In other words, what is earned from the rise in Germany is lost from the rise in Finland.

The theoretical prices are often based on the market prices of correlated, other products. Normally, all differences in prices of the 5 products that are correlated with each other are automatically arbitrated; after all, there is risk-free money. With the rise of electronic commerce, the time periods in which the differences exist have become increasingly shorter. As a result, arbitrators must look for ever faster ways to see, interpret, and utilize differences.

10 In addition to the search for more speed, there is also a desire to be able to scan more markets. This yields more products that may be eligible for arbitration. Because one stock exchange is not the other, connecting to multiple markets is an interesting problem, especially when those connections have to come together at a central location.

15 A third challenge is the fact that arbitrage is not entirely risk-free: because there are always multiple transactions per affair, there is a risk that one of those transactions cannot go through. Because the inefficiencies are becoming smaller and shorter, this problem is also getting bigger. It may therefore be that when an opportunity is seen for, say 1000, there are only 250 left by the time the order arrives at the stock exchange 20. The order for the remaining 750 items will then in fact remain at a good price at that time. It may be that a few moments later this order would be a bad transaction during execution.

In the present invention, a distributed normalized trading system is proposed. This is a concept that offers a great speed to the fairs, and also makes all fairs look the same for the user. The risk can also be limited by innovative strategies within this trading system.

The arbitration process carried out in the present trading system can be represented as: new market price (1) -> evaluation of the theoretical price (2) -> any 30 orders arrive on the stock exchange (3).

This process must be kept as short as possible (in time). Each component has its own reasons for possible slowness. In trading systems known so far, the following observations apply: Step (1) from new market price, which comes from a 6 electronic exchange, to evaluation compared to theoretical price, is largely determined by the geographical location of an electronic exchange that is present at the fair compared to the machine where the evaluation takes place. The time (2) required for evaluation is determined by the speed of the hardware and the efficiency of the software with which the evaluation takes place. The time that is subsequently required (3) until a possible order arrives at the electronic exchange is again largely determined by the distance.

A large part of the time that the process takes up is therefore determined by the location of the exhibition relative to that of the machine where the evaluation takes place.

10 It is possible to reduce that distance by choosing the location of the machine close to the electronic exchange. This is then typical in a data center. However, the data centers are not suitable for placing persons (traders). A previously used solution is then to copy all the graphic data from the screen to a place where traders can sit. Generally, VNC 15 software (virtual network computing) is used to achieve this. However, there are some disadvantages: the response time is very high and a lot of bandwidth is used on the network. This is because VNC copies the screen as a collection of pixels.

In an embodiment of the present invention, this problem is solved by using a proprietary communication protocol. Objects are passed on in this communication protocol. So instead of the picture "€ 10.00" (consisting of many pixels), the number € 10.00 is passed on. This fits in principle in a small number of bytes, and moreover it is possible to assign meaning to it. For example, we could say "€ 10.00" is the last 25 price of Nokia, which is much more difficult with a picture.

FIG. 1 shows an example of an arrangement according to the invention with which the speed of receiving data from exchanges, the processing thereof and subsequently instructing this exchange or another exchange can be kept as high as possible.

Generally speaking, the system comprises trading machines 1 (i) (i = 1, 2, ..., I). Each of these trading machines are computer devices on which one or more engines 3 (i) (i = 1, 2, ... .1), that is, software modules, can run.

Each trading machine 1 (i) is arranged as close as possible to one or more associated 7 electronic exchanges 4 (i, j) (j = 1, 2, ... J). Every electronic exchange 4 (i, j) is an entity in itself. In practice there are several cities in the world that have one or more such electronic exchanges. London and Paris, for example, have more than one. They are therefore at different locations that may be far away from each other. In each city where one or more such electronic exchanges 4 (i, j) are located, there is one trading machine 1 (i). The parameter "i" therefore indicates that the relevant electronic exchanges 4 (i, j) and trading machine 1 (i) are located in the same city.

Each electronic exchange 4 (i, j) receives instructions from an engine 3 (i) within 10 trading machine 1 (i) for executing a transaction indicated by the engine 3 (i) via an input communication line 5i (ij) and sends a confirmation to this engine 3 (i) via an output communication line 50 (i, j) when the transaction has been executed.

An engine 3 (i) will generally be arranged to be able to initiate and handle a certain number of transactions. It is possible to install multiple engines within a trading machine l (i) so that the load per engine does not rise too high. The number of engines running on a trading machine at a specific time depends on the maximum length of time that the initiation and processing of a certain transaction can take.

Each electronic exchange 4 (i, j) also has a group of direct communication lines 9 (i, j), one of which is always connected to trading machine 1 (i), such that each trading machine 1 (i) is connected to every electronic exchange 4 (i, j) via such a communication line 9 (i, j). Via these communication lines 9 (i, j) only data is sent, but no transaction instructions and confirmations. The system shown may also include one or more databases 10, such as

Bloomberg, who can make crucial data available for whether or not to initiate a transaction by an engine 3 (i). These databases 10 can send this data to the engines 3 (i) via communication lines 11.

The system further comprises a monitoring system 2 which can be arranged at any location 30, for example in Amsterdam at a great distance from most trading machines 1 (i). The monitoring system 2 comprises as many monitor instances (2i) as there are engines 3 (i). Each engine 3 (i) is connected one-on-one to one monitor instance 2 (i) via a connection 7 (i).

8

The engines 3 (i) are programmed to process information received independently via the communication lines 9 (i, j) and to convert it into a transaction instruction according to predetermined rules. If an engine 3 (i) decides to initiate a transaction for an electronic exchange 4 (i, j), this engine 3 (i) generates the necessary transaction data for this and sends it via the input communication line 5i (ij) to the relevant electronic exchange 4 (i, j). Each monitoring instance 2 (i) is arranged to set the software and associated parameters on the associated engine 3 (i), such as entered "offline" by an operator of the monitoring system 2. The monitoring system 2 is not involved in (parts of) of) the evaluation process and therefore the distance between the trading machines 1 (i) on which the engines 3 (i) run and monitoring system 2 is no longer relevant.

In many cases a trading machine l (i) will only belong to one electronic exchange 4 (ij). Each trading machine 1 (i) will then be arranged as close as possible to an electronic exchange 4 (i, j) as physically as possible in order to keep the total time required for processing a transaction as short as possible. As said: sometimes there is a group of electronic exchanges 4 (i, j) relatively close to each other (for example in London and Paris), and it is faster to have this group of electronic exchanges 4 (i, j) with one trading machine l (i) to connect. Only from an engine 3 (i) running within this trading machine 1 (i) will each of the electronic exchanges 4 (i, j) 20 of this group then receive instructions for a transaction and only to this engine 3 (i) will a confirmation of completion will be sent.

Each engine 3 (i) is preferably arranged to store data in a uniform data format, for example XML, and to convert its transaction instructions into a data format used by the relevant electronic exchange 4 (i j).

Conversely, each engine 3 (i) can convert the confirmation signal of a completed transaction such as received from an electronic exchange 4 (i, j) into that uniform data format and then store it.

Each electronic exchange 4 (i, j) is a computer device. An electronic exchange 4 (i, j) thus comprises a computer device with software (software) and peripheral equipment such as screens, input terminals, printers, etc. An example of such a computer device is described below with reference to Figs. 3 discussed.

9

The monitoring system 2 and the database 10 are also a computer device that can be implemented as shown in FIG. 3.

Each trading machine 1 (i) is also a computer device. In its simplest form, this comprises a processor, a memory and units for communicating with other installations. However, the trading machine 1 (i) can also comprise several processors to make the processing of data as fast as possible. The memory contains the necessary software / data to perform the required functionality. If desired, a trading machine 1 (i) may also comprise more components as shown in FIG. 3.

The direct connections 5 (i, j) and 50 (i, j) between the trading machines 1 (i) and the associated electronic exchanges 4 (i, j) are, preferably, implemented with techniques that guarantee the fastest possible data communication. . At the moment that would happen with fiber optic techniques, but the invention is not limited thereto. Any faster (future) technology can be used for this.

According to the present invention the problem of the response time is partly solved by always placing the trading machine 1 (i) as close as possible to the respective electronic exchange 4 (i, j), with a direct connection 5i (i, j) / 50 (i, j) in between. If there are several electronic exchanges 4 (i, j) that must receive their transaction instructions from one and the same trading machine 1 (i), a position for this trading machine 1 (i) that is as close as possible to all these electronic exchanges 4 (i, j) are located.

The functionality with regard to the automatic handling of the transaction is placed in the engine 3 (i), while the rest of the functionality, for example the maintenance of the software in the engine 3 (i), is carried out with the aid of remote software of 25 monitor system 2. located in the electronic exchange 4 (i, j). The communication time between the electronic exchange 4 (i, j) and the associated engine 3 (i), as well as the processing of all data in the engine 3 (i) must be so short to be possible. The time required by engines 3 (i) for processing received data and converting it into a transaction instruction is preferably shorter than 1 ms.

Each input communication line 5 (i, j) and output communication line 50 (i, j) is preferably as short as possible.

10

The communication between the engines 3 (i) and the monitoring system 2 may take longer, in other words is not time-critical. The latter also applies to the processing time in the monitoring system 2.

Another time-critical path concerns the communication links 9 (i, j) that are located between the electronic exchanges 4 (i, j) and all trading machines 1 (i) over which no transaction instructions and transaction confirmations are sent, as well as the communication lines 11 between the databases 10 and the trading machines 1 (i). Along these communication lines 9 (i, j) and 11, information is sent that is crucial for the generation of a new transaction by the engines 3 (i). The time 10 that these communication lines 9 (i, j) and 11 need for sending the information must be as short as possible. That is why they are preferably implemented with specially designed fast connections, such as a fully rented connection based on fiber optic technology.

In accordance with the invention, each monitoring instance 2 (i) of the monitoring system 2 comprises a copy of all software / data of the one-on-one associated engine 3 (i). As a result, the trader operating the monitor instance 2 (i) can make "offline" changes to software and / or parameter values of parameters used in engine 3 (i) when running the software. In practice, the software will be object-oriented. A monitor instance 2 (i) associated with an engine 3 (i) will then have shadow objects that are one-to-one copies of the objects present on the associated engine 3 (i). However, the monitor instances 2 (i) do not include a semantic for initiating transactions and sending transaction instructions to an electronic exchange 4 (i, j). With the shadow objects, a trader can only change data. After completion of changes in such data and at the instruction of the trader, the processor of the monitoring system 2 sends the changed software / parameter values to the relevant trading machine 1 (i) which will adjust the associated engine 3 (i). This process of sending changes can take place immediately after completion. This can take place via a connection 7 (i) which is always open. In this sense, "offline" does not necessarily refer to a situation in which the connection 7 (i) is not established until the data is available, but to the situation that the adjustment of the software / parameter values is not directly in the engine 3 (i) takes place itself, but in the shadow objects. The relevant engine 3 (i) can then use the updated software / 11 parameter values to initiate a new transaction from its position close to the relevant electronic exchange 4 (i, j) using the new software / parameter values as quickly as possible. The relevant functionality of the engines 3 (i) will be explained in more detail below.

In a further embodiment of the present invention, each of the monitor instances 2 (i) of the monitoring system 2 is further adapted to generate signaling data for a trader on the basis of the analyzed data. For example, a trader can be informed of potentially interesting trading opportunities via a screen that is part of the monitoring system 2.

The monitoring instances 2 (i) of the monitoring system 2 can further be adapted to prepare order data for the electronic exchanges 4 (i, j) on the basis of data evaluated by a trader himself. The engine 3 (i) is then adapted to convert the order data from the associated monitor instance 2 (i) into converted order data specifically for the relevant electronic exchange 4 (i, j), in order to enter it without further delay in the electronic exchange 4 (ij).

The evaluation process within engines 3 (i) (see the description with reference to Fig. 2 below) can be further accelerated by faster hardware or specially developed more efficient program code. However, what is even more helpful is the division of the tasks of an engine 3 (i) over several independent, parallel-operating sub-engines that run on separate processors, for example. Each sub-engine is controlled by the relevant engine 3 (i) to perform a sub-task. The configuration of the engines 3 (i) and its possible sub-engines is determined by the operator of the monitoring system 2. He also ensures that a sub-monitor instance is created within the monitoring system 2 for each sub-engine and controlled by the relevant monitoring authority 2 (i). Because the different sub-engines of the engine 3 (i) can communicate with each other in this embodiment, additional efficiency is achieved. The locations of the processors on which the sub-engines run are preferably chosen such that the total distance between the exchanges 4 (i, j) and these processors plus the distance between these processors and the processor on which the engine 3 (i) runs is as small as possible to keep communication times as short as possible.

An example of an engine 3 (i) will now be discussed in more detail.

12

Stock exchanges and products traded there can be very different, but they have certain common denominators. By separating these from more specific parts, and placing them in different layers, a flexible system can be created that can be controlled for the most part in a uniform way, and where the really specific differences can be hidden. In particular, for a trading system according to an embodiment of the present invention, the following functional software components can be identified, which are interrelated in the schematic representation of FIG. 2 are displayed • Connectors 31, 31 ', 31 ”, 10 • Account AC CT 34 • Order router ORD-ROUTE 36 • Price Feed PFEED 32 • Price Check P-CHECK 23 • Contract CONT 21 15 • Tradables TRADS 22 • Theocomputation TH- COMP 24 • Strategy STRAT 25 • Specifications SPEC 35

These software components 21-36 are preferably object-oriented and together form the engine 3 (i). The engine 3 (i) is as described above in communication with the electronic exchange 4 (i, j) via communication links 5; (ij), 50 (i, j) for handling a transaction. This is done via the connector 31. However, the engine 3 (i) can also communicate with other electronic exchanges 4 (i, j) via communication links 9 (i, j) which are connected to a respective connector 31 or databases 10 via communication line 11. connected to respective connector 31 ".

The connector 31 is a specific implementation of a connection to an electronic exchange 4 (i, j) and solves the problem of communication from and to that electronic exchange 4 (i, j). When prices are sent by the electronic exchange 4 (i, j), they are received by the connector 31. The connector 31 also takes care of the communication for orders and quotes to the electronic exchange 4 (i, j). In addition, via the connector 31 "specifications of products (contract specifications 33), and position overviews from the electronic exchanges 4 (ij), as well as 13 via connectors 31" from other databases 10 can be requested. All this information (prices, positions, specifications and orders or quotes) always relates to a Contract 21.

A Contract 21 is an abstract concept that is linked to a product, 5 for example a financial instrument. For example, we can talk about the Nokia share in Finland as a Contract, but there are several ways to request information about this share. Information may be available via a database 10 of a computer system from Bloomberg, Reuters or an (other) electronic exchange 4 (i, j). Such Bloomberg, Reuters or electronic 10 exchanges databases 10 can then be associated one to one with a connector 31731 ”. The translation of Contract 21 into specific connector 31 is done by means of a Spec 35, which is explained below. An example of a Spec 35 is as follows.

As an example, an engine 3 (i) with a Bloomberg connector 31 "is discussed below, that is, a connector 31" which is connected via a communication line 11 to a database 10 of a Bloomberg computer system. Within

Bloomberg is the symbol for Nokia in Finland TSfOKl V FH Equity. Suppose there is a connector 31 ”for Bloomberg called 'BLMBRG'. A Contract 21 'Nokia Finland' can be created in the relevant engine 3 (i), which can be linked to a BloombergSpec 35 with TSfOK1 V FH Equit 'and' BMLBRG 'attributes. In this way it is possible to receive prizes for 'Nokia Finland', and where they actually come from is then abstracted. Note that a BloombergSpec 35 is a special form of a Spec 35, where the precise information is able to translate Bloomberg prices into normalized prices.

A Contract 21 is a special and simplest form of a Tradable 22.

A Tradable 22 is a collective name for a product type. Tradables 22 can be composed of other Tradables 22. An example is a basket of shares, but also the inverse of a currency pair is an example of a Tradable 22, when, for example, only prices are available for the euro / dollar, and one needs has to the dollar / euro prices.

When the processor of the engine 3 (i) has sent prices via the Connector 31 and Spec 35 to the Tradable 22, then the processor of the engine 3 (i) first performs Price Checks 23 (i) on it. For example, if a new price deviates too much from the previous one, the engine of engine 3 (i) may decide to declare it invalid and skip 14, or deactivate the Strategies 25 it uses to buy or sell. If the Price Check 23 (i) succeeds, then the processor of engine 3 (i) first updates all Theocomputations 24 (theoretical calculations) of related products, as well as the Strategies 25 of the Tradable 22 itself, and related products. Every Tradable 22 has exactly one Theo computation 24, which contains the theoretical price of the Tradable 22. If the theoretical value of a Tradable A depends on Tradable B, the Theocomputation 24 of A must be updated when B has a new price. If a Tradable 22 has a new theoretical value, then the corresponding Strategies 25 must be evaluated. Such a Strategy 25 can, for example, be quoting: delivering a bilateral market for a product. Both a buy and sell order is placed on the market around the theoretical price. When the theoretical price changes, the buy and sell orders must necessarily be updated. Submitting, changing and removing orders on the exchange is done by means of an Order Router 36.

15 Orders are always executed on an Account 34, and this is also the object on which position changes are transmitted.

As an example, an arbitration between Nokia Finland and Nokia Germany is discussed here. A source for the prizes is, for example, the Bloomberg database 10, and it is possible to send orders to an electronic exchange 4 (il, jl) on the stock exchange 20 in Finland and an electronic exchange 4 (i2, j2) on the stock exchange in Germany. An engine 3 (il), 3 (i2) is associated with each of these two electronic exchanges 4 (il, j1), 4 (i2, j2).

Copies of the software / parameter values that run on this pair of engines 3 (il), 3 (i2) are available on two monitor instances 2 (il), 2 (i2). With the help of software from the two monitor instances 2 (il), 2 (i2), the user then creates two Connectors 31, one for the respective engine 3 (il), 3 (i2): • FinlandConnector • GermanyConnector

The trader also creates a Bloomberg connector 31 ”with these two monitor instances 2 (il), 2 (i2) for both 30 engines 3 (il), 3 (i2). These can be identical, but also different.

In addition, the user creates two Contracts 21 with the two respective monitoring authorities 2 (il), 2 (i2), one with the name Nokia Finland and one with the name Nokia 15

Germany, respectively for a Finland engine 3 (il) listed at the electronic exchange 4 (il, jl) of the stock exchange in Finland and a Germany engine 3 (i2) listed at the electronic exchange 4 (i2, j2) of the stock exchange is in Germany. The way in which Nokia Finland and Nokia Germany can be uniquely identified is based on the symbol names TSfOKIV FH Equity 'and TSfOA3 (i) GY Equity' respectively. There are BloombergSpecs 35 for the engine 3 (il), 3 (i2) in which that can be entered by the trader. Furthermore, there is a FinlandSpec 35 in which the trader must enter an id (60 in this case), and there is a Germany Spec 35 in which the trader must enter a different identifier (52). Furthermore, with the help of monitoring system 2, the trader creates a BloombergPricefeed 32 for the engine 3 (i) which is connected to the Bloomberg connector 31 ”.

Suppose the Bloomberg database 10 sends a price update for a market from € 10.00 to € 10.01 to the engine 3 (i) for NOA3 (i) GY Equity. The BloombergPricefeed 32 then receives this update and checks whether it has a Spec 35 for the NOA3 (i) GY Equity symbol. That is the case, and the associated Contract 21 appears to be Nokia Germany. The BloombergPricefeed 32 now puts the bid for Nokia Germany at € 10.00 and the offer at € 10.01.

Suppose that at that time the Contract 21 for Nokia Finland in Finland engine 3 (il) registered a bid price of € 9.98 and a offer price of € 9.99 in the same way.

All this data from the BloombergPricefeed 32 and the Contract 21 for Nokia Finland is sent to the monitor of the monitoring system 2. The trader sees on his screen (of the monitoring system 2) that there is a chance of a financially favorable transaction, and assuming that this will happen more often, he starts working to automatically and in the future use this chance. benefits. To this end, he creates a DualListingTheo, i.e. a special form of Theo computation 24, for Nokia Finland within monitor system 2 for Nokia Finland, which makes the theoretical price of Nokia Finland equal to the market price of Nokia Germany. The theoretical prices are updated with every (market) price update, so that subsequently the strategies can be implemented for the Contract 21 that has a changed market price, and for the Contracts 21 that have a changed theoretical price. To this end, the trader creates a Strategy 25 16 for the contracts 21 for the Finland engine 3 (il) and Germany engine 3 (i2). Both Strategies 25 are then loaded into, respectively, the Finland engine 3 (il) and the Germany engine 3 (i2). This Strategy 25 compares the market bid price with the theoretical offer price and the market offer price with the theoretical bid price. If there is a chance (eg the market bid price is higher than the theoretical offer price) then the 5 respective Strategies send 25 orders via, respectively, the FinlandConnector 31 and

GermanyConnector 31. To this end, the trader creates a Finland order router 36 and a Finland Account 34 (the specification of the account into which the shares are to be deposited or raised) for the Finland connector 31 at the respective monitor institutions 2 (il). trader with monitoring body 2 (i2) a Germany Order router 36 and a Germany Account 34 for the Germany connector 31. After completion, these are loaded in the respective engines 3 (il), 3 (i2).

In an example, the BloombergPricefeed 32 has just placed the bid for Nokia Germany at € 10.00 and the offer at € 10.01. The theoretical price for Nokia Finland will then be € 10.00 to € 10.01. The Strategy 25 for Nokia Finland in Finland 15 engine 3 (i) sees that the theoretical bid price (€ 10.00) is larger than the market price and will decide on a purchase order for Nokia Finland, so will the Strategy 25 in Germany for engine 3 (i) ) decide on a sales order for Nokia Germany. The Finland order router 36 is therefore instructed by the relevant Strategy 25 to purchase Nokia Finland. This then searches for a Spec 35 with 'FinlandConnector' 20 31 and contract 21 Nokia Finland '. The Finland order router 36 will then see that an ID 60 is linked to this and send this information to the Finland connector 31. Subsequently, this information is used by the Finland connector 31 to inform the Finnish electronic exchange 4 (i, j) that there is a purchase order arrives for id 60.

25 Similarly, within Germany engine 3 (i2) of the relevant Strategy 25, the Germany order router 36 receives the order to sell Nokia Germany. This then searches within Germany engine 3 (i2) for a Spec 35 with 'Germany Connector' 31 and contract 21 Nokia Germany. The Germany order router 36 will then see that an ID 52 is linked to this and send this information to the Germany connector 31. Subsequently, this information is used by the Germany connector 31 to inform the German electronic exchange 4 (i, j) that there is a sales order arrives for id 52. If both orders are executed correctly and with the aforementioned number of items, the user has just earned € 5.

17

Sometimes incorrect prices are passed on by electronic exchanges 4 (i j) or databases 10 such as those of Bloomberg. For example, it can be stated that the Nokia Finland offer price is 0. This would cause the application to buy at 0, while of course this is nonsense. To protect against this, prices 5 are checked by means of the PriceChecks 23 which check whether new prices fall within a meaningful bandwidth. But other checks 23 are also conceivable, such as whether the stock exchange is open at all.

The risk can be limited by sending special orders to the stock exchange, called "fll-or-kill" (FOK) or a variant thereof "immediate or cancel" (IOC). By first doing the “difficult” side of the arbitration (the illiquid product), with an IOC or FOK order, three possible scenarios arise: • The order is fully executed. Now the "easy" side of the arbitration can be done.

• The order is not executed at all. Nothing needs to be done now. The order disappears from the order book.

• The order is only partially executed, and the remainder is deleted. The easy side of the arbitration is done proportionally.

To implement this, the engine 3 (i) is arranged in an embodiment for splitting the order data into a first transaction (the uncertain part) and a second transaction (the certain part), and for sending the second transaction after confirmation of execution of the first transaction has been received from the corresponding electronic exchange 4 (i, j).

Sending orders to an electronic exchange 4 (i, j), retrieving 25 prices and product data is always accompanied by the setting of many configuration parameters. In addition, there is a big difference between fully autonomously operating computer systems and trading applications where traders can enter orders manually, and trading applications whose sole purpose is to provide an overview of the transactions made and current positions. Described by all components with reference to FIG. 2, it can be ensured that the configuration overhead is kept to a minimum. This can be achieved by making the software available as objects in a library with which applications can be built. This also means that the software can present itself in many forms and 18 embodiments: as an autonomous trade application, a monitor, an order-entry tool and order or trade book.

From the example given above it will be clear that quite a lot must be set before the trading application can do its job: there must be 5 Connectors 31, Specs 35, Contracts 21, Theocomputations 24, PriceChecks 23, Strategies 25, Accounts 34 and Order routers 36 created, and possibly even more. The trader will be able to do all this on monitor system 2 without disturbing the engines 3 (i). In many cases, however, the trader will also want to submit orders manually. Because the collection of objects can be reused, it is not so much a specific trade application that is created, but rather a framework within which trade applications can be built. The automatic and distributed trade application has already been discussed as an embodiment. However, it is also possible to build an application based on the same framework for manually placing orders. After all, in this application it is important to see prices and to be able to place 15 orders. Because the same rules apply to receiving prizes and sending out orders as in the automatic trading application, there is no reason not to reuse these objects ("the framework"). In fact, this has a major advantage: if the operator / trader decides to trade on a new exchange, then the connector 31 for that exchange only needs to be programmed once. The trader has the ability to trade automatically and manually on that exchange (electronic exchange 4 (i, j) to which the engine 3 (i) is connected). The same applies to a different class of applications: that where an overview is shown of all transactions made, or of all active orders. All this can be built on the aforementioned framework.

In one embodiment, the configurations used with the various functional components 21-25 and 31-36 are stored as an XML file. With the structure of XML very coherent objects can be described. Exchange with other types of applications is also easy with XML files.

In the embodiments described here, reference is made to the monitoring system 2, the trading machine 1 (i) and the electronic exchanges 4 (i, j) in the sense of computer systems. Each of these computer systems can derive its own functionality from computer-executable instructions that are loaded into a program memory. The computer systems can be separate computer systems, each with one or more processors, memory units, and input and output equipment, such as monitors, keyboards, printers, and interface equipment (e.g., network interfaces), as known to those skilled in the art, and as needed for implementation of the respective functionalities. Alternatively, functionality of an element 2, 1 (i), 4 (ij) can be distributed over one or more interconnected computer systems. The present invention can therefore also be embodied as a computer-readable medium with instructions executable thereon by a computer system, whereby the respective functionalities of each element 2, 1 (i), 4 (i, j) are obtained after loading of the instructions.

An example of such a computer system is shown in FIG. 3.

FIG. 3 shows a computer system 40 with a processor 41 for performing arithmetic operations.

The processor 41 is connected to a number of memory components including a hard disk 45, Read Only Memory (ROM) 47, Electrically Erasable 15 Programmable Read Only Memory (EEPROM) 49 and Random Access Memory (RAM) 51. Not all of these memory types necessarily have to be present to be. Moreover, they do not have to be physically placed close to the processor 41. They can also be placed at a distance therefrom.

The processor 41 is also connected to means for entering instructions, data, etc. by a user, such as a keyboard 53 (i) and a mouse 55. Other input means, such as a touch screen, a track ball and / or speech converter which are known to the person skilled in the art can also be used.

A reading unit 57 connected to the processor 41 is provided. The reading unit 57 is adapted to read data from and possibly store it on a data carrier, such as a floppy disk 59 or a CDROM 61. Other data carriers may, for example, concern memory sticks, DVDs or blu-ray discs, as is known to those skilled in the art. .

The processor 41 is also connected to a printer 63 (i) for printing output data on paper, as well as a display unit 43, for example a monitor, LCD (Liquid Crystal Display) screen, plasma screen or any other type of display unit known to the skilled person .

20

The processor 41 is connected to a communication network 67, for example the PSTN (Public Switched Telephone Network), a local area network (LAN), a wide area network (WAN = Wide Area Network), etc. output means 65. The processor 41 is adapted to communicate with other communication devices, such as other computer systems, via the network 67.

The processor 41 can be implemented as a stand-alone system or as a number of parallel operating processors, each of which is arranged to execute sub-tasks of a larger program, or as one or more main processors with various sub-processors.

Described above is a trading system with trading machines 1 (i) arranged close to respective electronic exchanges 4 (i, j) and a remote monitoring system 2 coupled to the trading machines 1 (i). The 15 engines 3 (i) running on the trading machines l (i) include the following components: • Connector C 31 • Price Feed PFEED 32 • Account ACCT 34 20 • Specs SPEC 35 and • Order router ORD-ROUTE 36 • Contract CONT 21 • Tradables TRADS 22 • Price Check P-CHECK 23 25 • Theocomputation TH-COMP 24 • Strategy STRAT 25

In the monitoring system 2, copies of the software / parameter values of the software / parameter values stored on all engines 3 (i) are stored via monitor instances 2 (i). The monitor instances 2 (i) include software 30 which allows a trader to make "offline" changes to the copy of the software / parameter values of the associated engine 3 (i), whereafter the monitor instances 2 (i) update the updated software / be able to load parameter values to the relevant engine (s). Upon receipt, the relevant engine 3 (i) will use the updated 21 software / parameter values for controlling the automatic financial transaction on the associated electronic exchange 4 (i, j).

By this arrangement, the most time-critical components of the total software in the engines 3 (i) are executed as close as possible to the electronic exchanges 4 (i, j) 5, whereby the necessary speed is obtained.

When there are many fairs, products, accounts and / or price feeds, it can be complicated to set up an engine 3 (i) in such a way that it functions optimally. Within the process of acting, automatic acting is not only important. It is also important, if desired, to be able to enter orders manually, to view the market in a visually pleasing manner, to have an overview of the orders in the market, an overview of the transactions made and to have a signaling system. for excessive trade. If the configuration of an automatic trading system could be reused for all of these described applications, this saves a lot of setup and maintenance time. Because the system 15 uses components that can be added, changed and removed remotely, a kind of chameleon is created: the application can act as an automatic trading system, and by starting it up slightly differently as one of the other applications mentioned.

An example: an engine 3 (i) is arranged to trade on Nokia Finland, using a FinlandOrder router and a FinlandConnector where the transactions made are posted to an account 34. The engine 3 (i) does not need a history of all transactions made on account 34 for that day, but could in principle get this easily because it has all the information about the associated connector 31 and account 34. However, a so-called TradeBook 25 application, which shows an overview of all transactions made on one or more accounts 34, would need that information to work. It is therefore obvious to re-use this information. In other words: the configuration of the trade application is used in the Tradebook application, but because the application is started with other parameters, it seems as if a completely different program is being started. However, it is exactly the same program code that can occur as different applications. In some cases, for an additional application form, new objects (components) must be added to the software framework. As a result, these new objects also become available in, for example, the automatic trading application. Often they are not used there, but in some cases it opens up new possibilities.

Claims (12)

A trading system for executing a financial transaction, comprising • one or more trading machines with one or more engines each arranged for automatically generating a financial transaction and sending a financial transaction instruction to at least one electronic exchange via an input communication line of the electronic exchange and receiving a confirmation signal from the at least one electronic exchange after completion of the financial transaction via an output communication line of the electronic exchange, a monitoring system comprising an associated monitor instance for each engine, each trading machine is arranged as a computer system with a processor and memory which memory for implementation of each engine has stored 15 engine software and engine parameter values for automatically controlling a financial transaction, and wherein the monitoring system is also set up addresses as a computer system with a monitoring system processor and a monitoring system memory with monitoring software, which allows a user to create each monitoring instance, each monitoring instance comprising a copy of the engine software and engine parameter values of the associated engine, and the monitoring software during company allows the monitoring system processor to: • have a user make changes to the copies of the engine software and engine parameter values stored for the monitor instance and • load updated engine software and engine parameter values thus obtained onto the associated engine and where each engine software the processor of the trading machine to: 30 «automatically use the updated engine software and engine parameter values, after receipt, to control the financial transaction. The trading system of claim 1, wherein the engine software is based on object-oriented software, and the copies of the engine software include shadow objects thereof that cannot themselves control a financial transaction. The trading system of claim 2, wherein each engine and the monitoring system are arranged for exchanging and storing data in the form of XML data. Trading system according to claim 1, 2 or 3, wherein at least one engine has one or more sub-engines for performing one or more tasks on behalf of the one engine 10 and the monitoring system therefor per sub-engine for the associated monitor instance has a sub-monitor instance. 5. Trading system according to claim 4, wherein the sub-engines of an engine run on separate processors and the locations of the separate processors on which the sub-engines run are selected such that the total distance between the electronic exchange controlled by the engine and this one separate processors plus the distance between these separate processors and a processor on which the engine runs is as small as possible. A trading system according to any of claims 1-5, wherein each engine has one or more additional input modules that can be connected to a dedicated communication line, for example a fiber optic cable, for receiving financial data and the processor of the trading machine is arranged for using it when initiating the financial transaction. A trading system according to any of claims 1-6, wherein each engine is arranged such that a financial transaction can take place within 1 ms. A trading system according to any of claims 1-7, wherein at least one trading system is connected to a plurality of electronic exchanges for controlling a financial transaction. The trading system of any one of claims 1-8, wherein the monitoring system is further adapted to generate signaling data for a user based on analyzed data. 10. A trading system according to any of claims 1-9, wherein at least one engine is further adapted to split order data into a first transaction and a second transaction, and to send the second transaction after confirmation of execution of the first transaction has been received of the associated electronic exchange. 11. Method for executing a financial transaction on a trading system as defined in any one of the preceding claims, which method comprises: having a user make changes to copies of the engine software and engine parameter values stored on the monitor instance, • loading updated engine software and engine parameter values thus obtained onto the associated engine, and • the associated engine automatically using the updated engine software and engine parameter values, after receipt, to control the financial transaction. 12. Computer-readable medium provided with instructions stored thereon, executable by a computer system, which, when the stored instructions are loaded, confer on the computer system the functionality of the method according to claim 11.