WO2006126005A2

WO2006126005A2 - Trading system order book

Info

Publication number: WO2006126005A2
Application number: PCT/GB2006/001939
Authority: WO
Inventors: Hugh Brown; John Wilson; Emlyn Scott
Original assignee: London Stock Exchange Plc; Lch.Clearnet Ltd; Man Financial Limited
Priority date: 2005-05-25
Filing date: 2006-05-25
Publication date: 2006-11-30
Also published as: GB2426602A; WO2006126005A8; GB0510695D0

Abstract

art. 17(2)(a)art. 17 (2) (a)

Description

TRADING SYSTEM ORDER BOOK

FIELD OF THE INVENTION

The present invention relates to a trading system for trading financial instruments of various types, and to the message flows and parameters required of such a system. The system is arranged to display an order book of financial instruments, to match orders and transmit messages to other systems for clearing of matched orders. The order book displays prices and amounts of financial instruments available for matching, and stores these and other parameters in an order book store.

BACKGROUND OF THE INVENTION

Trading system^'s for trading a variety of different financial instruments are now well known. Developments continue to be made to match business logic to the constraints^' of computer systems and the technical barrier that this presents. The matching of orders of a given financial instrument in known systems typically operates on price-time priority basis, that is orders are matched with other orders giving the best price available and then giving priority to those entered into the order book first. Such systems may be anonymous direct counterparty trading systems or systems in which trades are conducted via a central counterparty, such as a clearing house. In either type of known system, an order for a given type of financial instrument is matched with an.-order for the same instrument.

A known system is described in US 2001/0049649 of the type in which trades are conducted via a clearing house, which describes systems as follows. Jrades may ,be made in formal exchanges, if "fisted" or, if "unlisted" over a network commonly known as the "Over-the-Counter" ("OTC") market. In the case of formal exchanges and for some networks, an important role in trading mechanics is played by a "clearing house". Depending upon the exchange and the type of security, the exact role of the clearing system will vary. If an investor wants to make a stock purchase, his broker simply acts as an intermediary to enable the investor to buy shares from or sell to another individual through the stock exchange. When an investor contacts a broker to establish a futures position, the brokerage wires the order to the firm's trader on the floor of the futures exchange. In contrast to stock trading, which involves specialists or .market makers in each security, most futures trades in the United States occur among floor traders in the "trading pit" for each contract. Once a trader willing to accept the opposite side of a trade is located, the trade is recorded and the investor is notified. At this point, the clearing system enters the picture. Rather than having the long and short traders hold contracts with each other, the clearing house becomes the seller of the contract for the long position and the buyer of the contract for the short position. The clearing system is obligated to deliver the commodity to the long position and to pay for delivery from the short; consequently, the clearing house's position nets to zero. This arrangement makes the clearing system the trading partner of each trader, both long and short. The clearing house, bound to perform on its side of each contract, is the only party that can be hurt by the failure of any trader to observe the obligations of the futures contract. This arrangement is necessary because a futures contract calls for future performance, which cannot be as easily guaranteed as an immediate stock transaction. .

A second known system is described in US 5, 924, 083 of the type in which trades are anonymously conducted direct between counterparties. In such a system, there is no central counterparty in the form of a clearing house to guarantee trades and so credit between parties becomes an issue. That patent describes that when a broker is used to complete a transaction, although anonymity of the counterparties is preserved until just prior to the conclusion of the deal, the broker can be relied upon to prevent one party from initiating or accepting a deal with another party with whom, for one reason or another, it does not wish to trade. Removal of such human safeguards has lead to the ^■ development of automated checks and. validations in the. automated dealing systems.

US 5, 924, 083 further describes a number of such anonymous distributed matching systems. One such system is described in U.S. Pat. No. 5,077,665, . wherein a host computer maintains a host book data base including all active bids and offers in the system and distributes a subset of the host book, a keystation book, to the trader keystation. The contents of the keystation books includes an associated depth display range which is dynamically controllable by the host computer. The keystation book is also dynamically updated by transaction update broadcast messages received from the host computer. However, this system does not include any means by which credit availability between parties may be checked. SUMMARY OF THE INVENTION

We have appreciated the need for an improved trading system having the ability to handle the matching of data relating to financial instruments even where the • data relates to orders for financial instruments of different types. In particular, we have appreciated that no prior system has provided appropriate parameters, stores and message routing to handle the matching of one type of financial instrument with a different type of financial instrument.

The invention provides a trading system of the type in which orders for financial instruments may be entered into an order book and stored in an order book store, the entry of each order including an indication that each order is for a financiai instrument of one of at least two financial instrument types, the trading system including a parameter store arranged to store the indication of the financial instrument type of each order, the trading system being arranged to match and execute orders against each other of the same or different financial instrument types, and wherein the trading system is arranged to determine if two matching orders are of different financial instrument types and are capable of execution and, if so, to match and execute against each other the two orders and to route a message to cause two separate transactions to be created comprising a first transaction of a first type of financial instrument and a second transaction of a second type of financial instrument.

A system embodying the invention provides a trading system capable of storing and matching orders in financial instruments of at least two different types and executing transactions as a result, the matching occurring as though the orders were for a single type of financial instrument. The addition of a parameter store to the system allows the type of financial instrument to be stored in addition to data such as amount and price of each order. !n consequence, the embodying system is able to determine, based on a difference between parameters stored for a given pair of matching orders that a message needs to initiate creation of an order flow by which two separate transactions may be created.

It is noted that the term "match" is used in its normal sense that two orders are compatible based on a matching algorithm, which typically includes parameters for price and time. As specifically noted, the parameter of the financial instrument "type" of the order is specifically not a part of the determination of whether two orders match. In a sense the matching of orders is irrespective of financial instrument type. Two orders that match and are validated may be executed in the sense that a binding commitment to trade is created. In accordance with the invention, if two matching orders are for different "types" of instrument, the transaction is actually split into at least two transactions by the system.

Nonetheless, the two matching orders are said to be executed. The type of the financial instrument is referred to as the "financial instrument type". The system is also capable of matching instruments of the same type within the same order book. The underlying of the financial instruments may be securities such as particular shares, the type being either the shares themselves or a derivative therefrom.

The embodying system is referred to as a "combined order book" in the sense ^"that financial instruments of at least two different types are stored and displayed in a single (combined) order book. A single price and quantity is shown regardless of order type, which represents the combined volume and combined price time prioritisation. The type of the orders is not displayed and so the order book is a true combined order book because the type of the orders is not differentiated when a view of the^'order book is created.

A particular benefit of the embodying system is the ability to match orders for a security with orders for corresponding derivatives on the underlying security. The parameter store holds an indication of the type of each financial instrument, in particular whether the instrument is a derivative or an underlying security. The system is able to quickly determine how message flows should be routed based on a check of the similarity or difference of the parameters stored for each of the two matching orders.

In the embodying system in which there are two types of instrument, derivative or underlying security, the parameter may be a flag to indicate that a given order is a derivative, rather than the underlying security. The embodying system is particularly beneficial for matching an order for a contract for difference (CFD) on an underlying equity with an order for the equity itself.

The routing of the messages to create at least two separate transactions may be by a system that is integral with the order book, or separate therefrom. The routing of the message or messages to create at least two transactions may also include sending a message to one or more systems outside the trading system itself, in particular to a third party facilitator system or to a plurality of such third party facilitator systems. This allows an entity or plurality of entities to act as third party facilitators by acting as counterparty to each of the at least two transactions created each time orders relating to two different types of financial instrument are executed against one another.

The routing of the messages to create at least two transactions may also include a process to determine the underlying security of the matched orders and to route the message in accordance with the determination. This allows the system to operate for multiple financial instruments relating to multiple underlying securities and to route messages resulting from each different security or group of securities to different third party facilitator systems.

A further process may be included to selectively route the messages that create the two or more transactions to a plurality of third party systems for each underlying security traded. This allows a plurality of third party entities to operate as facilitators to trades for a given underlying security. In this arrangement, additional logic may be included in the message flow to select the appropriate third party facilitator system based on parameters such as order volume traded.

The embodiment also has facility to allow the orders of at least two financial instrument types to be displayed and matched separately on request to thereby create two or more separate order books.

In particular, there is also provided a trading system of the type in which orders for financial instruments may be entered into an order book and stored in an order book store, the entry of each order including an indication that each order is for a financial instrument of one of at least two financial instrument types, the trading system including a parameter store arranged to store the indication of the financial instrument type of each order, the trading system being arranged to display orders stored in the order book store without an indication of the financial instrument type of each order and to match and execute orders against each other of the same or different financial instrument types thereby creating a combined order book, the trading system further being arranged to logically divide the order book on request so that orders of each financial instrument type are caused to be displayed as separate order books and to permit orders of the same financial instrument type only to be matched.

This allows the combined order book to be split into two separate order books, and also to be recombined, on request of an entity such as a third party facilitator.

The invention also resides in a method and computer program as defined in the claims to which reference is directed.

BRIEF DESCRIPTION OF THE FIGURES

An embodiment of the invention in the various aspects noted above will now be described with reference to the figures in which:

Figure 1 : is a flow diagram of an existing matching process in a trading system for cash; Figure 2: is a flow diagram of an existing matching process in a trading system for CFDs;

Figure 3: is a flow diagram of an existing method for buying a CFD; Figure 4: is a flow diagram of an existing method of selling a CFD;

Figure 5: is a functional diagram of the main component parts of the system embodying the invention; Figure 6: is a representation of the display on a trader's screen in the embodying system;

Figure 7: shows the parameters entered by a trader;

Figure 8: is a schematic diagram of the hardware in the system embodying the invention;

Figure 9: shows the order validation process in the embodying system;

Figure 10A: shows the first part of the order execution process in the embodying system; ^■

Figure 1OB: shows the second part of the order execution process in the embodying system;

Figure 11 : shows how the order book may be split in the embodying system;

Figure 12: shows the message routing processes in the embodying system;

Figure 13: is an example of trades resulting from using the embodying system; and Figure 14: is a more detailed view of Figure 13. DESCRIPTION OF A PREFERRED EMBODIMENT

The embodiment of the invention is a trading system and comprises trader terminals, a network, stores for trade related data and processors for operating a matching process and generating message flows. Such components are known to the skilled person and do not need describing in depth. An example system is the SETS system operated by London Stock Exchange.

As previously explained, the embodying system addresses the problem of matching data related to orders and routing messages based on the storage of one or more additional parameters that are not known in prior systems. To achieve this at a technical level, a parameter store is provided which stores parameters on which message routing processes can operate, so as to route trade messages appropriately. A routing system is provided to act upon the parameters in the parameter store.

The embodying system is particularly beneficial to allow trades between a CFD and an underlying equity in a combined order book, but may also be used for other purposes.

The terminology in trading systems commonly used is known to the skilled person, but for the avoidance of doubt, some of the terms commonly used are explained first before describing the embodying system.

Financial instruments are any item that can be traded on a trading system and includes equities (stocks and shares), bonds, commodities, foreign exchange, derivatives such as CFDs, futures contracts and options, and any other matter that can be traded for a defined amount and price. Securities include stocks, shares, bonds and many other types of financial instrument. These are also referred to as a "cash" in contrast to derivatives in which case the security is an "underlying security".

A derivative is a form of financial instrument that is derived from an underlying matter such as a security, typically an equity, stock or share. The price of a derivative is dependent on the price of the underlying matter. Derivatives may characterised by a linear payoff in following the price of the underlying matter such as CFD and futures, or non-linear as in the case for contracts such as options. An order is a bid, offer, buy or sell instruction entered into a trading system specifying an amount and a price for a financial instrument. An order in the form of a bid or offer is sometimes referred to as a "quote" or a "visible order" as it is made publicly available in an order book. An order in the form of a buy or sell is usually simply referred to as an order. Various different types of order exist setting various parameters defining how the order may be matched, including fill/ kill and limit orders.

An order book is the listing of all orders available for trading giving the price and amount of the given financial instrument, and is stored in an order book store for retrieval and display on trader terminals.

The embodying system is particularly beneficial for handling CFDs. A CFD is an agreement between two parties to exchange in cash, at the close of the contract, the difference between the opening price and the closing price of the contract. A CFD is a mirror image or replica of the spot security, such as an equity or index upon which it is based. A CFD is a swap of cash flows, the purchaser of the CFD gains all the financial rights associated with a purchase of stock such as price movement, dividends, stock splits etc and in return for this benefit the purchaser pays a financing cost to the seller representing the overnight interest rate on the value of the purchase. Essentially this is the same as borrowing money and using it to purchasing stock. As no actual stock changes hands, there is no physical settlement requirement or currently any stamp duty (or SDRT) charge in the UK.

By way of further background, an existing matching process for cash is shown in Figure 1. A first party A enters an order at step 2 into an order book 10 and a second party B enters an order at step 4 into order book 10. If a match is determined by the system, then the central counterparty 6 (typically an exchange) creates two trades in the instrument in which the central counterparty (CCP) is on one side of each trade. At step 8 party A buys from the CCP, at step 12 the CCP sells to party A. At step 14 the CCP buys from party B and at step 16 party B sells to the CCP.

A similar process could be operated for trading CFDs as shown in Figure 2. The steps and parties are the same as described in relation to Figure 1 and so like numbers are used and the description above applies equally, but for a CFD rather than cash. However, more typically CFDs are traded through a provider as shown in Figure 3 and Figure 4.

A typical process flow through a direct access CFD provider is shown in Figure 3, in which a CFD. trader 20 would be given a view of the cash order book 10 and would place a CFD order either passively or aggressively with the CFD provider 24. The CFD provider then places a cash order on their own behalf onto the cash order book 10. The execution of the cash order from an order 22 would trigger the creation of the CFD with a CCP 6 as a counterparty. A similar process operates to sell a CFD at step 26 to a CFD provider 24, the CFD provider 24 places an order in a cash order book 10 to execute a trade with a matching order 28 through a CCP 6, as shown in Figure 4.

To offer a CFD service, the broker (provider 24) must have a stock borrowing & lending desk, run a market risk position or else outsource such activity to a white label CFD provider.

Currently, all CFD (equity swap) business is conducted over-the-counter (OTC). Other, on-exchange derivatives are traded on electronic order-books as are cash markets but no facility currently exists to match and execute orders in different instruments. The embodiment of the invention allows CFD orders to be input and executed against cash equity orders in a single combined order-book and then cleared by a central counterparty (CCP). Where a cash equity order matches against a CFD order, the CCP or a third party facilitator (TPF) is required to • manage the mismatch between the full cash payment for the equity and the margin based payment for the CFD, though they remain neutral to movements in the market price of the underlying instrument, the cash being a hedge for the CFD and vice versa. The combined order-book model requires the CCP/TPF to participate in stock borrowing/lending and managing cash flow mismatches. Additional systems, links and risk control processes are required at the

Exchange, CCP and TPF in order to allow the straight through processing of CFD vs. cash executions through a central market structure.

The system embodying the invention also allows the combined book to be split into two separate markets and recombined at will. This unique structure for the first time allows one financial instrument to trade against a different financial instrument so benefiting participants in both markets with the combined liquidity fro'm each separate market. As already explained, the system is not restricted to cash equities but applies equally well to other securities such as bonds, FX, commodities etc.

The functional components of a system embodying the invention are shown in Figure 5. The main elements are a client system 30 which will include trader terminals and a client's computer network by which traders can enter orders into the system as a whole. A broker system 40 receives orders from the client systems and initiates orders on behalf of clients. An alternative possibility is for end client systems to connect direct to an exchange system, but it is more usual for clients to operate through brokers. The broker systems 40 include an order submission process 41 which can select between two order submission paths, namely an "off' book path 42 or an "on" book path 43. The "off' book path 42 is one in which either cash vs. cash trade or a CFD vs. CFD trade is executed in known fashion. The "on" book path 43, allows CFD vs. cash orders to be matched and executed submitted via order entry system 44.

The exchange system 50 is where orders are matched and message flows routed so as to match and execute trades and pass them to a clearing system. The exchange system includes an off-book report process 51 and a CFD vs. CFD process 52. These two processes deal with non-CFD vs. cash orders and are not described further. The first sub-system that processes "on" book orders is an order validation sub-system 53. This makes a number of checks to ensure that the CFD order is a valid one that can be entered into the order book. The initial check ensures that the market segment is enabled for CFD orders, the second check is then carried out at instrument level and finally the participant broker is checked to see if the proper authorisation is in place. The order entry includes a parameter namely the financial instrument type parameter, which indicates whether the order is for a CFD or for a cash. This financial instrument type parameter is a flag, which indicates whether the order is a CFD or a cash (security) order.

An order book store 34 holds details of all orders submitted to the system in the form of an "order book" in known fashion. In addition to the order book store is a parameter store for storing the financial instrument type of each order. It is this parameter and a router sub-system that allows CFDs and corresponding equities to be matched. If orders are found to match, they are passed to a router subsystem 55 which is the component which causes two trades to be created from a single match of a CFD vε. equity and is described in detail later. Three further subsystems form part of the exchange systems: a surveillance subsystem 56; a market data feed subsystem 57 and a data warehouse subsystem 58, all described later.

Of considerable importance to the CFD vs. equity trade is a third party facilitator (TPF) system 59 which receives messages form the router subsystem 55 and operates to perform trades on behalf of a third party facilitator (TPF) entity.

Lastly, the overall system includes a central counterparty (CCP) system 60, which receives the various trades and processes them so that a CCP entity 61 (an exchange) forms the counterparty to. each trade.

A representation of the screen on a trader terminal is shown in Figure 6. The contents of the order book store forming an order book is shown on the iower half of the screen split into a buy side and a sell side. In the middle of the screen, the best bid and best offer price and amount from the order book are shown. The top half of the screen shows more detail of the particular matter being traded. In the particular example, the security being traded is a share in a company named "Shire Pharmaceutical". It is to be noted that this is a representation of a "combined order book". Although not displayed to the trader, the orders shown in the order book are actually for a mix of different financial instruments, namely the security itself (the shares in the company) and contracts for difference (derivatives derived from the shares). The trader does not need to see which orders are of the "instrument type" CFD or of the "instrument type" share, as either a CFD or a share order could match with any one of the orders in the order book, irrespective of the type. Accordingly, the parameter for the type of instrument (CFD or security) is not displayed. The type of the financial instrument is, therefore, anonymous.

The entry of an order into the system involves entering various data items, as shown in Figure 7. Av trader must enter, at a trader terminal, the security to be traded, the quantity, a buy or sell price, a limit price, a customer reference, an order type and, additionally, an instrument type parameter in the form of a CFD/cash indicator. This parameter or indicator is stored in the parameter store within the order book and may be a simple one bit flag, indicating whether the order to be submitted is for a cash (security) or CFD (derivative). The CFD/cash indicator is a new parameter not known in prior systems. The functional systems described, in relation to Figures 5 to 7, may be implemented in a variety of ways in hardware, a simple schematic example of which being shown in Figure 8. As shown, trader terminals in the form of workstations, typically PCs operating a Windows operating system, are connected to a network 3 running any standard network protocols, to which the order book and parameter store 54 and router 55 are attached or within which they are embedded. The order book may be distributed in the sense that it is formed of logically connected databases, which may be stored on more then one computer, or may be a central system, in which a single host server system, or cluster of computers, stores the information. Within the order book store is a parameter store 62 within which the parameter indicating whether the associated instrument is a CFD or a security is stored. The parameter store can take a variety of forms. It may be an additional flag within a row in a database table for each order within the order book store, or could be a separate store that is logically connected with the order book store.

The main systems within the overall system, as shown in the overview diagram of Figure 5, will now be described in greater detail with respect to Figures 9 to 12. The order validation system 53 operates the process, shown in Figure 9, to make checks that a CFD order is a valid one before entry into the order book. At a suspended participant step 70, a check is made whether the participant submitting the order is suspended from the system or not: If yes, an advisory message 72 is generated. If not, the system determines if the submitted order is for a cash or a CFD at an order type discrimination step 72. At order entry enable steps 74 and 76 a check is made that the order type is allowed on the system. If not, an advisory message is generated at message step 78. If the order type is a CFD, then a check is made that the particular instrument in question is enabled for CFD orders at instrument type check 80. If not, an advisory message is generated at step 82. A final checking step is whether the participant is enabled for the CFD order at step 84 or cash order at step 86 and, if not, a further advisory message 88 is generated. Lastly, assuming the checks are all successful, the incoming order is added to the order book, at step 90. It is noted that the various order validation checks enable what has been termed the "combined order book" to be separated into two separate order books, in the event that this is required. For example, there may be a price diversion between a cash and a CFD on the same instrument. This may be due to a corporate event and subsequent stock squeeze in the securities lending market. As a result, the exchange operating the system embodying the invention has the facility to separate out the combined order book into separate cash vs. cash and CFD vs. CFD order books. By performing the various checks shown in Figure 9, orders of a particular type may be suspended or rejected when the order book has been separated, as described.

The order execution system operates a process, as shown in Figures 1OA and 1OB. Figure 10B is a continuation of 10A, as shown by the links within the flow diagrams. The order execution process is operated within the exchange system as a combination of the order book system and the router system.

At a buy or sell checking step 100, it is determined whether the submitted order is a buy or a sell order. If the order is a sell order, then the decision process continues down the right-hand side of the diagram to step 102, to see if there are any unpriced orders on the buy side. If yes, then the next passive order in the order book is selected on price time priority at order selection step 106. If no, then a check is made on whether there are any priced orders, where the price greater than the incoming order price, at order book check 104. If there are not unpriced orders, a check is made whether there are any priced orders with the price less than or equal to the incoming order price at step 107. A determination is made as to whether the order should be retained, or rejected, as described later on Figure 10B.

It is noted at this point that the order submitted, and the subject of the order execution process, may be either a CFD or a cash and that this is not relevant to the matching process. This means that the only determining factor for matching the order is price time priority and the availability of the required amount. It is not relevant whether the order is of the same instrument type as a matching order in the order book. As a result, a business benefit is provided in that the liquidity from trades in underlying equities may be provided to the CFD market. Effectively, liquidity of the two systems is pooled.

On making a match at step 105 or 106, the trade size is determined at analysis step 108, to determine the minimum of the incoming order's remaining size and the passive order's aggregate size. At a trade price determining step 109, the execution price is determined based on the price of both orders. A check is made at step 110 that the trade price is within an allowed range. If not, the trade will not take place, at step 111 , and the instrument will be moved into a temporary paraϋβi situation at 112. if the price is within an al'owsd range, an automatic trade is created, at step 113, with a unique trade code and at step 114, the size of the passive order is reduced by the amount of the trade size.

Figure 1OB deals with the part of the execution process, which determines if a new non-matching incoming order may persist in the order book, and whether a matched order already in the order book has been filled and whether it will remain. A passive order in the order book that has been at least part matched with an incoming order is checked at step 115 and if now filled, a check is made to determine whether the order is of the Iceberg type of order. If not, the order is removed from the order book if, yes, a new order is submitted. If the passive order is not completely filled at step 115, or a new order submitted at step 118, or the order simply removed, the volume which at average price is updated, at step 119, a check made to determine if the price is in an allowed range, at step 120, and the size of the incoming order reduced by the size of the trade executed. If the incoming order has not been completely filled, as determined by step 122, then the process returns to the start to determine if there are further matches with the remainder of the incoming order. If the incoming order has been filled, the system is updated to determine the best price and aggregate volumes at step 123.

The left-hand side of Figure 10B deals with how to deal with orders that would otherwise match but are not within an allowed range, as determined at step 110, in Figure 10A. If the incoming order is a non-persisted order, as determined at step 124, then a determination is made at step 125 as to whether the order is of type "fill or kill". If yes, the order is rejected. If the incoming order is not "fill or kill", then the unfilled portion of the incoming order is rejected at step 127. The process then continues, at step 123, to determine the best in aggregate prices as before. The successful trade is sent to the participants at step 128 and trades netted for Iceberg type orders at step 129 before the order details are passed to downstream systems, which include information feeds, surveillance systems and data warehouses. It is reiterated that the execution process operates to match orders irrespective of their type and, when successful matches are found, the router system 55, shown in Figure 5, causes the matching trades to be split into trades with a third party facilitator, as the counterparty on each half of the split trade.

There are circumstances in which the combined order book functionality may need tc be suspended and orders within the combined order book split, so as to provide an order book for one type of instrument (cash) and another type of instrument (derivative) separately. In the embodying system this would mean determining which orders are CFDs and which are cash and providing a cash vs. cash and a CFD vs. CFD order book.

This facility exists so that the combined CFD/cash order book can be split into separate cash vs. cash and a CFD vs. CFD only order books. This may be required due to a squeeze in the securities lending market whereby the third, party facilitator is no longer able to manage the mis-match inherent in CFD vs. cash trades.

In such a situation, the TPF will make a request to the central counterparty that the combined book be suspended for an individual stock (the facility also exists to suspend the combined book for the whole market should there be some event such that the TPF is unable to discharge its duties). Detailed contractual arrangements will establish the exact criteria and escalation process.

o The CCP will have the power to suspend the combined book and send a message to the Exchange that it is unable to continue clearing CFD vs. cash executions and the combined book must be suspended. o The Exchange will immediately mark the instrument in question as not valid for CFD orders, effectively suspending all CFD order entry in that stock. o The Exchange will then delete afl CFD orders on the book, automatically ^■ creating messages to those participants who placed the orders informing them, o A separate dummy set of trading codes linked to the underlying instrument will be enabled on the trading system for CFD order entry only, o A notice will be sent to the market informing of the suspension of the combined book and details of the new dummy codes for the CFD only order book. o Any trades executed on the CFD only book will be translated back into the original instrument codes before onward transmission to the CCP.

The process to split the order book is shown in Figure 11 at a split initiation, at step 130, the third party facilitator indicates to the system that the combined order book is to be suspended, either in whole or for particular stocks. The central counterparty reaffirms this decision, at step 131 , and this is provided to market surveillance system 56. This provides messages to users of the system that the order book has been split and separates the order book into two separate order books by issuing an instruction to delete CFD orders from the combined order book to create a cash order book only, at step 132, and to create a temporary order book for CFD orders only, at step 133. Dummy codes are used when the order book is split in this fashion and, at step 135, dummy codes are translated - into cash instrument codes. Lastly, at step 136, the central counterparty processes orders as single instrument type executions.

The process of splitting the combined order book may also operate based on the "type" flag and simply create two separate order books by causing the system to display orders of each type separate and to only match orders with other orders of the same type. This. would be a change to the matching logic during the period that the order book is split.

The message router process is where matching orders are analysed to determine whether a third party facilitator is needed and whether execution will involve two or more trades. This functionality is provided by the router system 55, as shown in Figure 5 and is now described in more detail with reference to Figure 12. The router system sends transactions to market services and downstream processing, at step 140, and then determines whether the trade is automated or off-book, at step 141. If off-book, the trade will only be a CFD vs. CFD or cash vs. cash and so a determination simply needs to be made, at step 142, which type of instrument the trade is and is then processed as currently done for many types of instrument trades, as steps 143 and 144, and manually validated, at step 145, for passing to a central counterparty, at step 146, in known fashion. If the trade is determined, at step 141 ; to be on-book, then a check is made, at step 147, on whether the trade has CFD sides. If not, it is simply a cash transaction and is sent to the central counterparty at step 148. If the trade is determined to have ^• CFD sides, it is passed to a further checking step, 149, to determine if it is a CFD vs. CFD match or a CFD vs. cash match. This determination is made on the basis of the instrument flag stored in the parameter store as previously described. If the match is at CFD vs. CFD, then this is sent to the central counterparty, at step 150, to be handled in known fashion.

The particular difference with the combined order book system in contrast to known systems is if the automated trade is determined to be a CFD vs. cash trade, as step 149, then this is passed to a splitting step, at step 150, in which the CFD vs. cash trade is split to a CFD vs. CFD transaction with a third party facilitator, as the counterparty, and a cash vs. cash trade with the third party facilitator as a counterparty. This involves a message sent to the third party facilitator system 59 at step 151.

A summary of the trades created as a result of operation of the combined order book, execution process and post trade process, is shown in Figures 13 and 14. As shown in Figure 13, party A submits an order to buy a CFD into the order book and party B submits an order which matches this so lay cash into the same combined order book. The exchange router functionality already described causes this to be separated into a trade in which party A buys a CFD from the TPF and party B sells a cash to the TPF. Figure 14 shows the next level of detail in which the central counterparty is the counterparty to all trades, so that, in fact, party A buys a CFD from the central counterparty and the central counterparty buys a CFD from the third party facilitator. The third party's facilitator buys cash from the CCP and the CCP buys cash from the party B.

The following business advantages flow from the system embodying the invention. As previously explained, CFDs are currently traded as bilateral, OTC derivatives. This is typically, though not always, a two way process whereby a provider will write the CFD to an underlying client and then hedge the exposure with a cash equity transaction. The combined book model of the embodying system combines these two processes into a single, on-exchange transaction, which overcomes a number of problems inherent in existing model. The biggest shortcoming of the current bilateral OTC model is client's inability to transact against other end clients. They must trade bilaterally with a broker/market maker. The combined order book allows end users complete flexibility to not only find the best price whether that be with another market maker or end client trading on exchange, but also whether the counterparty wishes to transact an equity or a CFD. The counterparties to the transaction are now the CCP rather than bilateral agreements with a broker/market maker. This has the following advantages. It creates increased choice and flexibility of broker when opening and closing transactions. The CCP guarantees the transactions. The CCP nets and thus increases efficiency and lower costs. Increased anonymity as client business is not known by the market markers and the counterparty is always the CCP

The marketplace for CFDs is more regulated and safe due to the exchange regulatory environment and clearing house counterparty guarantee The current model generally requires a bilateral transaction with a market maker then the market maker to transact an equal and opposite transaction on the respective underlying exchange. There is duplication of transaction and processing as each equity transaction corporate event and price movement is passed back through the market- maker from the equity exchange and replicated into the bilateral CFD transaction with the client. The combined book combines this two-step process into one single process, which is more efficient and cost effective and quicker.

The prior art process of bilaterally trading each CFD and then replicating this into the underlying exchange means that each CFD provider has to transact in the stock borrowing market to hedge short client CFD transactions. The embodiment of the invention allows CFDs to trade with either CFDs or equities depending oh what market demand and supply is. Where a CFD matches another CFD there is no corresponding equity transaction and no necessity to transact in the stock borrowing market. This is more efficient, cost effective and reduces the risk of CFD providers (and thus clients) not being able to transact the bilateral CFD due SB&L shortcomings or shocks.

The combined model offers the following benefits. The combined book is impartial, transparent and anonymous. Flexibility in choice of broker - most importantly, OTC traded CFDs usually require the client to close the trade with the same broker which is not the case with the combined book. Efficiency and cost benefits - electronic access to a standardised product and concentrated liquidity will provide. for a much more cost effective CFD product, as will straight- through processing. Margined as opposed to fully funded positions creates balance sheet efficiencies.

By bringing CFDs on-exchange, the potential user base will expand dramatically due to regulatory and cost benefits thereby increasing volumes. It also allows brokers to offer a CFD service without having a stock borrowing and lending desk or outsource provider. It greatly reduces the costs of market making, which can be facilitated using CFD orders only in removing infrastructure costs (custody/settlement etc.). The CCP will minimise counter-party risk in CFD trades thereby reducing costs in freeing up credit lines and efficient, cross product margining. The combined book model will allow the liquidity in CFDs and cash business to feed directly into each other, improving the quality of both markets. ^' The trader will be able to enter CFD orders through their normal market access interface (those software companies that supply market access technology will have to carry out some minor reconfiguring for those clients wishing to utilise the service). All existing order types will be supported (e.g. at best, limit, fill or kill etc.) but the additional flag is used should the trader wish to enter a CFD order. This flag will be invisible to the market and the order book screen will appear as it does today (see Figure 1) with all bid and offer orders displayed in price and time priority.

The CCP (Exchange) has the ability to restrict participants' ability to enter CFD orders or cash orders, depending on the infrastructure and authorisation in place. The Exchange will be able to halt trading in CFDs by restricting order entry and then deleting all CFD orders in individual stocks, segments or the whole market as already described.

The Exchange also has the ability to split the order-books into cash vs. cash only and CFD v. CFD only if there is potential divergence between their market prices due to unusual corporate events. This is achieved by first halting trading in CFDs as described above and then opening a dummy instrument in a mirror segment where only CFD orders can be entered only.

A real-time feed is supplied into TPF systems of all 'split' cash vs. CFD trades so they have a view of the positions they amass and carry out the necessary risk management, checks and controls. The anonymity of the counterparty protected, only the details of the positions themselves are communicated.

The Key CCP Functions are risk management:

The CCP will margin equity and CFD positions intra-day and end-of-day using the same equity based margining algorithm based on a portfolio analysis approach. The same reference prices will be used for both equity and CFD margin calculations. CFD and equity positions will be merged, netted at the level of the clearing member or exchange participant and off-set for margin calculation purposes. The margin will be collected using LCH's Protected Payment System.

Cost of Carry: The cost of carry is calculated on a daily basis, incorporating the financing of a position and where appropriate a charge for borrowing stock. This process will be conducted on net positions for the first time in this market so deriving considerable financial benefit for the participants

Corporate Actions: The CCP performs all corporate actions on CFDs. Corporate actions are applied to the holder of the CFD's positions on the basis that no one (long or short) gains or loses economic value as a result of the corporate actions. These include rights issues, stock splits, special dividend, takeovers and demergers.

Dividends: When a dividend is paid by a company (i.e. goes ex-dividend) the price of the stock will typically fall by the amount of the payment. This will also occur on the price of the CFD. To compensate the buyer for the fall in the CFD price, a manufactured dividend reflecting the amount of the dividend will be paid from the seller to the buyer. The amount paid to the CFD buyer from the seller is • usually the gross dividend less the tax credit though this depends on market. In other words the buyer receives the net dividend and the seller pays the net dividend adjusted for withholding tax of the relevant tax authority. Payment is credited or debited at the end of business on x-date via the CCP.

Risk Management: A number of end of day and intra-day additional risk control systems are implemented in order to ensure smooth operation of the combined order-book and minimise risk to the integrity of the cash trade. Key variables: Individual stock volumes/exposures expressed as an absolute. Individual stock volumes/exposures expressed as a percentage of stock in issue or free capital.

The TPF Key Functions are: In the case of the cash vs. cash trade type and CFD vs. CFD trade type, the TPF has no role to play. Only in the case of a CFD vs. cash trade will the TPF have any involvement. Once the trade has been split and the TPF is counterparty to opposing trades in CFD and cash, should one fail validation at the CCP, the TPF faces the risk of market exposure.

When short equity and long CFD, the TPF will be required to borrow stock in the market in order to settle the cash sell on the settlement date. Stock borrow rates will be charged to CFD sellers, these rates will be set by the CCP (in conjunction with TPF.) Special contractual arrangements are needed to deal with the issues of stock squeezes and stock recalls. These special conditions form part of the standard terms of the exchange traded contract and the contractual terms between CCP and TPF.

When long equity and short CFD, the TPF will have paid for the stock and be receiving financing for the CFD Al! CFD positions will be netted so the TPF will have one net position per stock, greatly reducing the amount require to borrow or available to lend.

The embodiment described is a system for operating the invention. The invention also resides in the technical and business processes described and also in software for implementing these processes.

An alternative to the selective creation of two transactions if two orders are of different financial instrument types is to create two transactions for every trade, even if the matching orders are of the same financial instrument type, but to use the financial instrument type parameter to route messages and cause appropriate transactions to be created.

Claims

1. A trading system of the type in which orders for financial instruments may be entered into an order book and stored in an order book store, the entry of each order including an indication that each order is for a financial instrument of one of at least two financial instrument types, the trading system including a parameter store arranged to store the indication of the financial instrument type of each order, the trading system being arranged to match and execute orders against each other of the same or different financial instrument types, and wherein the trading system is arranged to determine if two matching orders are of different financial instrument types and are capable of execution and, if so, to match and execute against each other the two orders and to route a message to cause two separate transactions to be created comprising a first transaction of a first type of financial instrument and a second transaction of a second type of financial instrument.

2. A trading system according to claim 1, wherein the message is routed to a third party system, relating to a third party entity, the third party entity thereby being designated as a counterparty to each of the first and second transactions.

3. A trading system according to claim 2, wherein the message is selectively routed to one of a plurality of third party systems each related to a respective third party entity in dependence on the underlying security of

• the financial instruments matched.

4.- A trading system according to claim 2, wherein the message is selectively routed to one of a plurality of third party systems each related to a respective third party entity in dependence upon a grouping of the underlying security of the financial instrument matched.

5. A trading system according to claim 2, wherein for each underlying security of each financial instrument matched the message may be selectively routed to one of a plurality of third party systems.

6. A trading system according to any preceding claim, wherein the system comprises a router system arranged to route the message after a match has been determined.

7. A trading system according to any of claims 1 to 6, wherein the system comprises a router system integral with the order book store.

8. A trading system according to any preceding claim, wherein the message is also routed to a central counterparty system, related to a central counterparty entity, whereby the central counterparty entity is designated as a counterparty to transactions derived from the first and second transactions.

9. A trading system according to any preceding claim, wherein the order book store is arranged to allow the orders of at least two financial instrument types to be displayed and matched separately on request to thereby create two or more separate order books.

10. A trading system of the type in which orders for financial instruments may be entered into an order book and stored in an order book store, the entry of each order including an indication that each order is for a financial instrument of one of at least two financial instrument types, the trading . system including a parameter store arranged to store the indication of the financial instrument type of each order, the trading system being arranged to display orders stored in the order book store without an Indication of the financial instrument type of each order and to match and execute orders against each other of the same or different financial instrument types thereby creating a combined order book, the trading system further being arranged to logically divide the order book on request so that orders of each financial instrument type are caused to be displayed as separate order books and to permit orders of the same financial instrument type only to be matched.

11. A trading system according to claim 11, wherein the system is further arranged to recombine orders in different financial instrument types into a single combined order book on request.

12. A trading system according to claim 10 or 11 , wherein the order book store includes instrument codes indicating the matter of each instrument in the order book, and wherein the system is arranged to assign temporary instrument codes to one type of financial instrument when logically dividing the order book.

13. A method of operating a computer system of the type in which orders for financial instruments may be entered into an order book and stored in an order book store, comprising:

storing for each order entered in the system a parameter indicating the financial instrument type of each order, matching and executing orders against each other of the same or different financial instrument types, - determining if two matching orders are of different financial instrument types and are capable of execution based on the parameter indicating the financial instrument type of each other, matching and executing the two orders, and generating a message to cause two separate transactions to be created comprising a first transaction of a first type of financial instrument and a second transaction of a second type of financial instrument, if the matching orders are determined to be of different financial instrument types.

14. A method according to claim 13, wherein the message is routed to a third party system, relating to a third party entity, the third party entity thereby being designated as a counterparty to each of the first and second transactions.

15, A method according to claim 14, wherein the message' is selectively routed to one of a plurality of third party systems each related to a respective third party entity in dependence on the underlying security of the financial instruments matched.

16. A method according to claim 14, wherein the message is selectively routed to one of a plurality of third party systems each related to a respective third party entity in dependence upon a grouping of the underlying security of the financial instrument matched.

17. A method according to claim 14, wherein for each underlying security of each financial instrument matched the message may be selectively routed to one of a plurality of third party systems.

18. A method according to any of claims 13 to 17, wherein the message is also routed to a central counterparty system, related to a central counterparty entity, whereby the central counterparty entity is designated as a counterparty to transactions derived from the first and second transactions.

19. A method of operating a computer system of the type in which orders for financial instruments may be entered into an order book and stored in an order book store, comprising:

storing for each order entered in the system a parameter indicating the financial instrument type of each order, generating a display of orders stored in the order book store without an indication of the financial instrument type, - matching and executing orders against each other of the same or different financial instrument types, and on request, logically dividing the order book so that orders of each financial instrument type are caused to be displayed as separate order books and to permit orders of the same financial instrument type only to be matched.

20. A method according to claim 19, further comprising recombining orders in different financial types into a single combined order book on request.

21. A method according to claim 19, comprising temporarily assigning temporary instrument codes when logically dividing the order book.

22. A computer program which when executed on a computer system implements the method of any of claims 13 to 21.