Untitled record
12 claims: 7 independent, 5 dependent
- 1CONCLUSIES 1. Handelssysteem voor het uitvoeren van een financiële transactie , omvattende • een of meer handelsmachines met een of meer engines die ieder zijn ingericht voor het automatisch genereren van een financiële transactie en het verzenden van een financiële transactie-instructie naar ten minste één elektronische exchange via een ingangscommunicatielijn van de elektronische exchange en het ontvangen van een bevestigingssignaal van de ten minste ene elektronische exchange na voltooiing van de financiële transactie via een uitgangscommunicatielijn van de elektronische exchange, • een monitorsysteem dat voor iedere engine een bijbehorende monitorinstantie omvat, waarbij elke handelsmachine is ingericht als een computersysteem met een processor en geheugen welk geheugen voor implementatie van elke engine enginesoftware en engineparameterwaarden heeft opgeslagen voor het automatisch besturen van een financiële transactie, en waarbij het monitorsysteem eveneens is ingericht als een computersysteem met een monitorsysteemprocessor en een monitorsysteemgeheugen met monitorsoftware, die het een gebruiker mogelijk maakt iedere monitor-instantie te creëren, waarbij elke monitor-instantie een kopie omvat van de enginesoftware en engineparameterwaarden van de bijbehorende engine, en de monitorsoftware het tijdens bedrijf de monitorsysteemprocessor mogelijk maakt om:• een gebruiker veranderingen te laten aanbrengen in de voor de monitorinstantie opgeslagen kopieën van de enginesoftware en engineparameterwaarden en • aldus verkregen geactualiseerde enginesoftware en engineparameterwaarden te laden op de bijbehorende engine en waarbij iedere enginesoftware het de processor van de handelsmachine mogelijk maakt om: • de geactualiseerde enginesoftware en engineparameterwaarden, na ontvangst daarvan, automatisch te gebruiken voor het besturen van de financiële transactie.
- 2Handelssysteem volgens conclusie 1, waarin de enginesoftware is gebaseerd op object-georiënteerde programmatuur, en de kopieën van de enginesoftware schaduwobjecten daarvan omvatten die zelf geen financiële transactie kunnen besturen.
- 3Handelssysteem volgens conclusie 2, waarbij elke engine en het monitorsysteem zijn ingericht voor het uitwisselen en opslaan van data in de vorm van XML data.
- 4Handelssysteem volgens conclusie 1, 2 of 3, waarbij ten minste één engine één of meer sub-engines heeft voor het uitvoeren van één of meer taken namens de ene engine en het monitorsysteem daartoe per sub-engine voor de bijbehorende monitor-instantie een sub-monitor-instantie heeft.
- 5Handelssysteem volgens conclusie 4, waarbij de sub-engines van een engine op aparte processoren draaien en de plaatsen van de aparte processoren waarop de subengines draaien zo worden gekozen dat de totale afstand tussen de door de engine bestuurde elektronische exchange en deze aparte processoren plus de afstand tussen deze aparte processoren en een processor waarop de engine draait zo klein mogelijk is.
- 6Handelssysteem volgens een van de conclusies 1-5, waarbij iedere engine één of meer extra ingangsmodules heeft die kunnen worden aangesloten op een dedicated communicatielijn, bijvoorbeeld een glasvezelkabel, voor het ontvangen van financiële gegevens en de processor van de handelsmachine is ingericht voor het gebruiken daarvan bij het initiëren van de financiële transactie.
- 7Handelssysteem volgens één van de conclusies 1-6, waarbij iedere engine zodanig is ingericht dat een financiële transactie binnen 1 ms kan plaatsvinden.
- 8Handelssysteem volgens één van de conclusies 1-7, waarbij tenminste één handelssysteem met meerdere elektronische exchanges is verbonden voor het besturen van een financiële transactie.
- 9Handelssysteem volgens één van de conclusies 1-8, waarbij het monitorsysteem verder is ingericht voor het genereren van signaleringsdata voor een gebruiker op basis van geanalyseerde data.
- 10Handelssysteem volgens één van de conclusies 1-9, waarbij tenminste één engine verder is ingericht voor het splitsen van orderdata in een eerste transactie en tweede transactie, en het versturen van de tweede transactie nadat bevestiging van uitvoering 5 van de eerste transactie is ontvangen van de bijbehorende elektronische exchange.
- 11Werkwijze voor het uitvoeren van een financiële transactie op een handelssysteem zoals gedefinieerd in een van de voorgaande conclusies, welke werkwijze omvat:• het door een gebruiker veranderingen laten aanbrengen in de op de monitor instantie opgeslagen kopieën van de enginesoftware en engineparameterwaarden, • het laden van aldus verkregen geactualiseerde enginesoftware en engineparameterwaarden op de bijbehorende engine, en • het door de bijbehorende engine automatisch gebruiken van de geactualiseerde enginesoftware en engineparameterwaarden, na ontvangst daarvan, voor het besturen van de financiële transactie.
- 12Computerleesbaar medium voorzien van daarop opgeslagen, door een 20 computersysteem uitvoerbare instructies, die het computersysteem, wanneer de opgeslagen instructies worden ingeladen, het computersysteem de functionaliteit verlenen van de werkwijze volgens conclusie 11.
Independent claims12
112 paragraphs in 1 section, as filed
Distributed trading system
FIELD OF THE INVENTION
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 plurality of '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 does not provide 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 of which is adapted to automatically generate a financial transaction and send a financial transaction instruction to at least one electronic exchange via an input communication line of the electronic exchange and receive a confirmation signal of the at least one electronic exchange after completion of the financial transaction via an output communication line of the electronic exchange, • a monitoring system that includes an associated monitor instance for each engine, each trading machine being set up as a computer system with a processor and memory that stores memory for implementation of each engine engine software and engine parameter values 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 allows the monitoring system processor during operation to:
• having 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 allows the processor of the trading machine to:
• automatically use the updated engine software and engine parameter values, after receiving them, to manage the financial transaction.
In a further aspect, the present invention relates to a method for performing 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 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, upon receipt, for controlling the financial transaction.
In a further aspect, the present invention relates to a computer-readable medium provided with instructions stored 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.
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
FIG. 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. As an example, and the common thread throughout this story, the Nokia share is taken. 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 various reasons this does not always have to be the case: suppose in both Finland and Germany there is a bid 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 items at € 10.01. In table form:
<td></td><td></td><td>€ 10.01</td><td>500</td>
<td>1000</td><td>€ 10.00</td><td></td><td></td>
<td>500</td><td>€ 9.99</td><td></td><td></td>
<td>500</td><td>€ 9.98</td><td></td><td></td>
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:
<td></td><td></td><td>€ 10.01</td><td>500</td>
<td></td><td></td><td>€ 9.99</td><td>500</td>
<td>500</td><td>€ 9.98</td><td></td><td></td>
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 in Germany:
<img file="NL2004104C_D0001.tif" />
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.
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 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.
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.
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 fair. 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 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 conducted in the present trading system can be represented as:
new market price (1) -> evaluation relative to theoretical price (2) -> any 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 an electronic exchange, to evaluation relative to theoretical price, is largely determined by the geographical location of an electronic exchange that is present on the stock exchange 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.
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. Usually VNC 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 Nokia's last rate, 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 of trading machines l (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), i.e. software modules, can run.
Each trading machine 1 (i) is arranged as close as possible to one or more associated 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 can 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 trading machine 1 (i) for executing a transaction indicated by the engine 3 (i) via an input communication line 5i (i, j) and transmits a attachment to this engine 3 (i) via an output communication line 5<sub>0</sub>(i, j) if 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 1 (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 each 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, which can make crucial data available for initiating or not initiating 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, 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).
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 (i, j) 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 1 (i) will only belong to one electronic exchange 4 (i, j). 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 to complete 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 1 (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) of this group then receive instructions for a transaction and only this engine 3 (i) will receive a confirmation. be sent upon completion.
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 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.
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 includes 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 include more components as shown in FIG. 3.
The direct compounds 5i (i, j) and 5<sub>0</sub>(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 placing the trading machine 1 (i) always as close as possible to the respective electronic exchange 4 (i, j), with a direct connection 5i (i, j) / 5<sub>0</sub>(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) is 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 electronic exchange 4 (i, j) monitoring system 2. 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 as short as possible to be. 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 5i (i, j) and output communication line 5<sub>0</sub>(i, j) is preferably as short as possible.
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) which 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 (1). 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 (1). The time required for these communication lines 9 (i, j) and 11 to send 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 from 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 / 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 monitor system 2 is further adapted to generate signaling data for a trader based on 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 authorities 2 (i) of the monitoring system 2 can further be arranged 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), to enter it without further delay in the electronic exchange 4 (i, j).
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) across several independent, parallel-operating sub-engines that run on separate processors, for example. Each sub-engine is driven 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 within the monitoring system 2 a sub-monitor instance is created for each sub-engine that is 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 possible to keep communication times as short as possible.
An example of an engine 3 (i) will now be discussed in more detail.
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 in a uniform way for the most part, 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 shown • Connectors 31, 31 ', 31 ”, • Account ACCT 34 • Order router ORD-ROUTE 36 • Price Feed PFEED 32 • Price Check P-CHECK 23 • Contract CONT 21 • 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; (i, j), 5<sub>0</sub>(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 which are 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 can be requested from the electronic exchanges 4 (i, j), as well as via connectors 31 ”from other databases 10. 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, 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 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, i.e. a connector 31" which is connected via a communication line 11 to a database 10 of a Bloomberg computer system. Within Bloomberg, the symbol for Nokia in Finland is 'N0K1V FH Equity'. Suppose there is a connector 31 ”for Bloomberg called 'BLMBRG'. A Contract 21 'Nokia Finland' can be made in the relevant engine 3 (i), which can be linked to a BloombergSpec 35 with NOKl 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.
If 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 (1) first performs Price Checks 23 (i) on it. For example, if a new price deviates too much from the previous one, the processor of engine 3 (1) may decide to declare it invalid and skip it, or to deactivate the Strategies it uses to buy or sell. If the Price Check 23 (i) succeeds, the processor of engine 3 (i) first updates all Theocomputations 24 (theoretical calculations) of related products, as well as then 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 two-sided 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 purchase and sales orders must necessarily be updated. Submitting, changing and deleting orders on the exchange is done by means of an Order Router 36. Orders are always executed on an Account 34, and this is also the object on which position changes are submitted.
As an example, an arbitration between Nokia Finland and Nokia Germany is discussed here. A source for the prizes is for example the database 10 at Bloomberg, and it is possible to send orders to an electronic exchange 4 (il, j 1) on the stock exchange 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). Using 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 engines 3 (il), 3 (12). These can be identical, but also different.
In addition, with the two respective monitoring authorities 2 (il), 2 (i2) the user creates two Contracts 21, one with the name Nokia Finland 'and one with the name Nokia
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 'NOK1V FH Equity' and 'NOA3 (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, using monitor 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 (from 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 use this opportunity in the future. . To this end, he creates a DualListingTheo, using a software from monitor authority 2 (il) for Nokia Finland within monitor system 2, ie a special form of Theo computation 24. As a result, the theoretical price of Nokia Finland equals 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 draws up a Strategy 25 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 an opportunity (eg the market bid price is higher than the theoretical offer price), the respective Strategies send 25 orders via, respectively, the FinlandConnector 31 and GermanyConnector 31. To this end, allows the operator to the respective monitor involved bodies 2 (il), a Finland Order Router 36, and an Finland Account 34 (the specification of the account to which shares need to be lifted deposited) for Finland connector 31. Similarly, the han makes delaar with monitor instance 2 (i2) a Germany Order router 36 and a Germany Account 34 for the Germany connector 31. Upon 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 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 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' and contract 21 'Nokia Finland'. The Finland order router 36 will then see that an ID 60 is associated with this and send this information to the Finland Connector 31. This information is then used by the Finland Connector 31 to inform the Finnish electronic exchange 4 (i, j) that a purchase order is coming for ID 60.
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. This information is then used by the Germany connector 31 to inform the German electronic exchange 4 (i, j) that a sales order is coming for id 52. If both orders are executed properly and with the aforementioned number of items, the user just earned € 5.
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 are checked by means of the PriceChecks 23 that 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 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 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 has to be set before the trading application can do its job: Connectors 31, Specs 35, Contracts 21, Theocomputations 24, PriceChecks 23, Strategies 25, Accounts 34 and Order routers 36 must be 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 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 big 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 at that exchange (electronic exchange 4 (i, j) to which the engine 3 (1) 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, the monitoring system 2, the trading machine 1 (i) and the electronic exchanges 4 (i, j) in the sense of computer systems are mentioned. 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 implementing the respective functionalities. Alternatively, functionality of an element 2, 1 (i), 4 (i, j) 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 Programmable Read Only Memory (EEPROM) 49 and Random Access Memory (RAM) 51. Not all of these memory types need necessarily 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, 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 instance relate to 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 those skilled in the art.
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 may be implemented as a stand-alone system or as a number of processors operating in parallel, each of which is arranged to perform 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 engines 3 (i) running on the trading machines 1 (i) comprise the following components:
• Connector C 31 • Price Feed PFEED 32 • Account ACCT 34 • Specs SPEC 35 and • Order router ORD-ROUTE 36 • Contract CONT 21 • Tradables TRADS 22 • Price Check P-CHECK 23 • 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 that allows a trader to make "offline" changes to the copy of the software / parameter values of the associated engine 3 (i), after which the monitor instances 2 (i) transfer the updated software / parameter values to the load the relevant engine (s). Upon receipt, the relevant engine 3 (i) will use the updated software / parameter values for controlling the automatic financial transaction on the associated electronic exchange 4 (i, j).
Due to 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), 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 (1) 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 way, to have an overview of the orders in the market, an overview of the transactions made and to have an alert 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 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 launching it 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 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. This makes those new objects also available in, for example, the automatic trading application. Often they are not used there, but in some cases it opens up new possibilities.
12 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12
Every citation, both waysCites: the store holds 4 of 5
| Document | Relation | Office | Category | Cited during | Relevant claims |
|---|---|---|---|---|---|
| EP0803808A2 | Cites | European Patent Office (EPO) | A | Search report | 1-12 |
| US2003130985A1 | Cites | United States of America | Y | Search report | 1-12 |
| US2006206407A1 | Cites | United States of America | A | Search report | 1-12 |
| US2008033865A1 | Cites | United States of America | AD | Search report | 1-12 |
| DETICA: "Algorithmic trading: Can you meet the need for speed ?", 31 December 2008 (2008-12-31), pages 1 - 8, XP002597898, Retrieved from the Internet <URL:http://www.detica.com/index.php?option=com_assetmanager&Itemid=125&task=assetdownload&id=7&Artid=505> [retrieved on 20100506] | Non-patent | – | – | Search report | – |
2 priority claims, no other members on record
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 2004104 | Netherlands (Kingdom of the) | A | |
| NL20102004104 | – | – | – |
2 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Pledge establishedRC | RC | |
| Assignments of patentsSD | SD |
Numbers
- Publication
- 2004104
- Publication, DOCDB
- 2004104
- Publication, EPODOC
- NL2004104C
- Application
- 2004104
- Application, DOCDB
- 2004104
- Application, EPODOC
- NL20102004104
Titles2
- English
- DISTRIBUTED TRADE SYSTEM.
- Dutch
- GEDISTRIBUEERD HANDELSSYSTEEM.
Classification
- CPC, 1
- G06Q40/04
- IPC, 1
- G06Q40 00
