Markets exist in many forms. The participants consist of end users and intermediaries. The end users are for example producers and consumers, or, capital providers and investors, and the intermediaries are, for example, traders, brokers, clearers, fund managers and advisers. Markets may be domestic or global in nature and may be organised markets such as exchanges, operating with or without centralised clearing. Alternatively, the market may be a loose network of individuals or firms trading by telephone or otherwise.

In order to function, markets require a method of trading that includes deal confirmation and settlement or performance of the contracts entered into by the market participants. In some organised markets, these methods are codified within the rules and procedures of the various exchanges and clearing houses.

Other organised markets, for example foreign exchange markets, operate through service providers such as Reuters.

In organised exchange markets there are essentially three relationships- multilateral member/member; bilateral member/customer and bilateral customer/customer. A multilateral member/member relationship is one in which a member of the market has a relationship with a plurality of other market members. A bilateral member/customer relationship is one in which a member of the market has a relationship with a non-member of the market. A bilateral customer/customer relationship is one in which the parties are not part of the market.

In most cases the member/member trading relationship is either on a trading floor or a real time electronic system, both of which are expensive. There is, therefore, a need for a market operating system that allows market participents, whether or not members of an exchange, to confirm relatively quickly and cheaply the details of trades.

According to one aspect of the present invention there is provided a market operating system for confirming the details of trades already agreed between a buyer and a seller, the system comprising an electronic controller adapted to communicate via a communication network with a seller terminal and a buyer terminal, the electronic controller comprising means adapted for registering market members, a memory that includes a plurality of contract terms, the contract terms being selectively retrievable by a market member from the seller terminal, means for importing a selected term into an agreement that is to represent the agreed trade, means for storing the agreement completed by the seller, means for sending a signal to the buyer terminal to notify the buyer of the presence of the agreement, means for allowing the buyer to view the agreement entered by the seller and means for receiving a response from the buyer terminal to indicate whether or not the agreement is accepted or rejected.

When the buyer views the agreement, preferably the controller is adapted to provide a prompt requesting the buyer to indicate either acceptance or rejection of the agreement. When the buyer enters a response, this is forwarded to the controller from the buyer terminal.

Preferably, details of the agreement are automatically stored in a central database and an indication is provided in the database as to whether or not the agreement is accepted or rejected. If the agreement is accepted, the database is up-dated to show this. If the agreement is rejected, the database is likewise up- dated.

Preferably, the system further comprises means for selecting a customised list of the contract terms for presentation to a particular market member at the seller terminal, the contract terms in the customised list being each selectively retrievable by the particular market member from the seller terminal. The customised list may include the details of counter parties with whom the market member is authorised to trade. The customised list may include the details of brokers with whom the market member is allowed to trade. Preferably, a plurality of customised lists is provided.

Preferably, each member is allocated a unique member number. Preferably, the contract terms that are usable by a particular member are stored together with the unique member number. Preferably, the controller is adapted to search the stored contract terms to select those terms that are stored together with a particular unique member number and use the results of the search to compile the customised list of contract terms. The agreements entered by the seller are preferably stored together with the unique member number.

Preferably, each market member may designate users to operate on its behalf in the market operating system. For example, the market member may be a company and the designated users may be authorised employees. Preferably, each user is allocated a unique user identification (ID) number. Additionally,

the user may have a password, for added security. Agreements entered by the seller are preferably stored with the unique member number and the unique user ID.

Preferably, in order to access the market operating system, the user has to enter his unique member number and, where appropriate, unique user ID. Preferably the controller is adapted on entry of the unique member number and, where appropriate, unique user ID, to search the database of agreements, select all those that include reference to the unique member and, where appropriate, user ID number entered by the user and present to the user a customised listing of all the agreements found. Preferably, the customised listing of all the agreements includes an indication as to the status of the trade, i. e. whether the agreement has been confirmed, i. e. accepted, or rejected.

Preferably, the controller is adapted to receive information from the seller terminal relating to the nature and price of the goods for sale in the market, which information is imported into the agreement.

Preferably, the controller is adapted to receive a signal from the buyer terminal indicative of whether or not the agreement is accepted or rejected as representing the trade previously agreed.

Preferably, an encoder is provided for encrypting the details of the agreement so that the offer is readable only by the selected buyer.

Preferably the controller is adapted to present at the seller terminal a template of the trade agreed between the seller and buyer, the details of which are to be

completed by the seller. Preferably, the template includes a menu that can be opened, thereby to allow the seller to select contract terms for incorporation into the agreement. Where customised lists are provided, preferably the menu is a listing of the customised list.

According to another aspect of the present invention there is provided a method for confirming the details of trades already agreed between a buyer and a seller, the method comprising: registering market members; storing a plurality of contract terms, the contract terms being selectively retrievable by a market member from the seller terminal; importing a selected contract term into an agreement that is to represent the agreed trade; storing the agreement completed by the seller; sending a signal to the buyer terminal to notify the buyer of the presence of the agreement, allowing the buyer to view the agreement entered by the seller, and receiving a response from the buyer terminal to indicate whether or not the agreement is accepted or rejected.

According to another aspect of the invention, there is provided a computer program for controlling communication between a seller terminal and a buyer terminal, the computer program comprising means for registering market members, means for presenting to a market member at the seller terminal a plurality of contract terms that is stored in memory, means adapted to enable selection of a desired contract term from the list using the seller terminal, means for including the selected term in an agreement, means for storing the

agreement completed by the seller, means for sending a signal to the buyer terminal to notify the buyer of the presence of the agreement and means for receiving a response from the buyer terminal to indicate whether or not the agreement is accepted or rejected.

According to yet another aspect of the invention, there is provided a data storage means containing a computer program for controlling communication between a seller terminal and a buyer terminal, the program comprising means for registering market members, means for presenting to market members at the seller terminal a list of contract terms that is stored in memory, means adapted to enable selection of a desired contract term from the list using the seller terminal, means for including the selected term in an agreement, means for storing the agreement completed by the seller, means for sending a signal to the buyer terminal to notify the buyer of the presence of the agreement and means for receiving a response from the buyer terminal to indicate whether or not the agreement is accepted or rejected.

Preferably, the computer program further comprises means for selecting a customised list of the contract terms for presentation to a particular market member at the seller terminal, the contract terms in the customised list being each selectively retrievable from the customised list by the particular market member from the seller terminal.

The customised list may include the details of counter parties with whom the market member is authorised to trade. The customised list may include the details of brokers with whom the market member is allowed to associate.

Preferably, a plurality of customised lists is provided.

Preferably, each member is allocated a unique member number. Preferably, the contract terms that are usable by a particular member are stored together with the unique member number. Preferably, the unique member number is entered by the market member. Preferably, the computer program is adapted to search the stored contract terms to select those terms that are stored together with a particular unique member number and use the results of the search to compile the customised list of contract terms.

Preferably, the computer program is adapted to present to a seller a template of an agreement into which the seller enters details of the trade that is to be confirmed. Preferably, the template has a plurality of data entry fields. Where a customised list is provided, preferably, data can be entered into at least one of the data entry fields by selection from that list.

A method of establishing an electronic market operating system for confirmaing details of pre-agreed trades, the method comprising registering a plurality of market members; providing lists of available products that are selectable by market users; providing a plurality of contract terms, and marking the contract terms so that they are selectable for incorporation into a customised list of contract terms for presentation to a particular market member at a seller terminal.

Preferably, the method further comprises presenting the contract terms in the customised list to the particular market member at the seller terminal, providing means to allow selection by the particular market member of contract terms

from the customised list and electronically importing the selected terms into a pre-determined user agreement.

According to yet another aspect of the present invention there is provided a method of gathering market information comprising establishing an electronic market operating system for confirming details of pre-agreed trades; registering market members, and storing anonymously pricing details of all trades confirmed using the market operating system.

A market operating system in which the invention is embodied will now be described by way of example only with reference to the following Figures, of which: Figure 1 shows a diagrammatic representation of the market operating system; Figure 2 is a representation of the system web page, Figure 3 is a table that shows the various interactions that take place during use of the system, and Figure 4 is a template of an agreement that is presented to a seller.

Figure 1 shows a plurality of user PCs or work stations 10 connected via a telecommunications network 11, for example the World Wide Web, to a server 12 on which is installed a generic market operating system. The market operating system includes software that enables a member of the market to confirm in a manner that is legally binding a pre-agreed sale of goods. As

standard, an offer for sale is subject to certain contractual restrictions that are specified by the seller and negotiated with the buyer. These negotiations are typically carried out by telephone. Once the terms of the sale are settled, the seller uses the market operating system to select some of the agreed terms from a menu of pre-determined available contract terms and enters other terms, such as the price, manually. When the desired terms are selected these are imported into a User Agreement. A message is then sent to notify the buyer of the presence of the agreement as defined by the seller.

When a buyer receives the message, the details of the agreement can be checked to see if they concur with what was agreed verbally. The buyer can then either accept or reject the agreement as the case may be. If an agreement is rejected the seller is notified of this via e-mail. The seller then has the option to alter and thereby make any corrections to the terms of the trade. A message including the revised details of the agreement is then forwarded to the buyer.

This process continues until the agreement is finally accepted or rejected. If an agreement is accepted the seller is notified via e-mail and a record of the transaction is saved.

Typically, the market operating system is accessible via a dedicated web site, although it could be implemented on any other suitable data communications network, for example a wide area network or a local area network. The system server should preferably be a database driven web-server and the site should preferably have the majority of the system rules embedded in standard query language statements that can be used to interact with databases stored at the site.

An example of the first page of a suitable site is shown in Figure 2. This provides links 20 to all the main site sections, including a public site that provides information on the system, together with legal information, and links to related sites. In addition, a"login"link 21 is provided to private market member sites. Also available are links to explanations of the various"clear sites"that are present. Each of these sites provides access to particular trading options. For example the site marked"Oilclear"22 is dedicated to trades relating to oil and that marked"Metalclear"23 is dedicated to trades relating to metal.

In order to use the market operating system, each user firstly has to register as a market member. To this end, the first page of the web site is provided with a registration link 24 to a registration page. Once the registration page is accessed, the user is asked to provide the system server with personal details such as name, address, contact name, telephone number, fax number and e-mail.

In addition, the member has to agree to the terms set out in a market operating system User Agreement that defines both the contract terms and a large part of the overall terms of business.

Once registered, each member is allocated a unique member number that is stored in a member_no field in a MEMBER table 3 l, as shown in Figure 3.

Stored in association with the memberno field are the following fields: Member-address-this contains the member's address, Member-name-this contains the member's name, which is typically a company name Member-contact-this contains details of the member's contact, typically an employee within the member company

Member-tel-this contains the member's telephone number, Member fax-this contains the member's fax number Membere-mail-this contains the member's e-mail number, and Member default-this contains the member's default code which sets which clearing system is automatically presented to a member on entry into the system, for example some members may wish to automatically enter the Oilclear site whilst others may prefer to enter the Metalclear site.

The memberno field is linked to all the other"member"fields, so that by selecting a particular unique member number from the MEMBER table 31, for example by double clicking on the member number, access can be gained to all of the associated data on that member, as shown in Figure 3. Access at this level is, however, generally only permitted for system administrators.

Typically market members are companies. Therefore, in order to identify traders within member companies, each individual user is additionally provided with a unique user identification (ID) number. The user ID is stored in a user id field in a USERID table 32 (see Figure 3) that lists the IDs of all users registered in the market, together with the member number of the parent company. Stored in"user_id-"fields in association with the user ID are a user password and information relating to the authorised user security level, which can be varied according to the needs of the members. Additionally stored in "user_id_"fields are the user's name, telephone number, facsimile number and e-mail number. The user nid field is linked to all the other"userid"fields, so that by selecting a particular user ID from the USERID table 32, for example by double clicking on the user ID number, access can be gained to all the

associated data on that user. As before, access at this level is, however, generally only permitted for system administrators.

In certain circumstances, users can be registered in a specific grouping. For example, as shown in Figure 3, brokers can be registered as such. To this end a broker when registering will supply his name, address, contact number and other details as before. Once this is done the broker is assigned a unique member number and a broker code, each of which is inserted into a broker code field in a BROKER table 33. Linked to the broker code field are"broker" fields that contain the broker's details, such as name, a mnemonic or three letter abbreviation representing the broker's company name, address, contact details, telephone number, fax number, and e-mail number. Of course, each broker that is registered also has an associated unique member number that is also stored in a field in the BROKER table 33. Since the broker number field is linked to all the other"broker"fields, by selecting a particular broker number from the BROKER table 33, for example by double clicking on the broker number, access can be gained to all the associated data on that broker. Access at this level is, however, generally only permitted for system administrators.

Brokers are typically not actively involved in the confirmation process but a record is kept of trades that are arranged by particular brokers.

In order to facilitate the entry of product details into the system, a product (PROD) table 34 is provided as shown in Figure 3. The PROD table 34 contains prodcode fields that include product codes for the various products that can be traded. Each prod_code field in the PROD table is linked to further"prod" fields that contain details such as a description of the product, the type of

product, the product category, ie is it a bullion market product or an LME product, the order in which the products are to be presented to members and the product date and format ie the date and how this is presented. Since the prodcode field is linked to all the other"prod"fields, by selecting a particular product code from the BROKER table 33, for example by double clicking on it, access can be gained to all the associated data on that product. As before, access at this level is, however, generally only permitted for system administrators and not for traders in the front office.

Traders typically will only do business with specific parties with whom they are acquainted. It is taken, therefore, as a basic premise that the system users will each have a customised list of specified counter-parties with whom they will deal bilaterally and register the resulting trades. Most firms will for sound commercial reasons operate rigorous credit and"due diligence"checks before opening an account with or for another firm. However, there may be legal (e. g. money laundering statutes) and regulatory (e. g. FSA Rules) imperatives requiring such precautions. This list of approved counter-parties is one of the variable terms in any trade that the user may wish to confirm. This may vary not only in relation to each of the markets but also to the specific contracts within it. Each market member or even each market user within a specified member company will have different counter parties with whom they will do business.

The details of the counter parties or buyers to whom at least one market member is prepared to sell, together with details of credit limits and other relevant information, are stored in a counter party (CPARTY) table 35.

Confirmation of trading details can only be effected between members of the

market and so every counter party must have a unique member number. This member number is stored in the membcrno field of the CPARTY table 35. If a market member wishes to establish a relationship on the market operating system with a specified counter party then that counter party is allocated a cpart code that is entered into a cpart code field in the CPARTY table 35. Linked to the cpart code field is a cpart member field, which contains the member number of the member who wishes to trade with that particular counter party Additionally linked to the cpart code field are further"cpart"fields that contain the counter party's details, such as name, a three letter mnemonic representing the counter-party name, address, contact details, telephone number, fax number, e-mail number and the credit limit agreed with seller.

In addition, the CPARTY table 35 may include an e-mailinitial field. If this is included, then when an agreement is entered into the system by a seller, an e- mail indicating the presence of the agreement is forwarded to the selected counter party. The CPARTY table 35 may also include an e-mailconfirm field. If this is present, then when an agreement is confirmed by the counter party or buyer an e-mail indicating confirmation of the agreement is forwarded to the e-mail address in the e-mail confirm field, which is typically the seller e- mail number.

Since the cpart code field is linked to all the other'cpart_"fields, by selecting a particular cpart code from the CPARTY table 33, for example by double clicking on it, access can be gained to all the associated data on that counter party. As before, access at this level is, however, generally only permitted for system administrators and not for traders in the front office.

In order to facilitate the entry of specific clauses into the agreement, a terms (TERMS) table 36 is provided as shown in Figure 3. The TERMS table 36 contains a listing of terms codes associated with the various clauses that can be selected. Each terms-code in the TERMS table 36 is linked to further details such as a description of the term and its full text.

The MEMBER, USERID, BROKER, PROD, CPARTY and TERMS tables are sources of largely static information and each is linked to a market transaction table 37, marked TRAN in Figure 3. This is the main dynamic table that stores details of all the transactions that are entered into the system by traders. Each transaction that is entered onto the system is allocated a unique transaction number that is put into a trannumber field in the TRAN table 37. The tran number field acts as a link to fields that contain further details of the trade.

As is shown in Figure 3, the TRAN table 37 contains the following further fields: Member no-this stores the unique member number of the user forwarding the message Tran code-this stores a transaction code that indicates the category that the transaction belongs to, Tranproddesc-this stores a description of the product that is being traded Tran-volume-this stores the quantity of that product Tran-start-month-this is used for storing the start date of a spread and is the month which the member sells Tran-end-month-this stores the last date of a spread and indicates the month in which the member buys

Tran-day-this stores the day on which the trade is available Tran_price-this stores the price of the trade Tran user id-this stores the unique user ID of the member making the offer Trancpartnmem-this stores the mnemonic or three digit abbreviation of the counter party name Tran_broker_code - this stores the broker code, if appropriate Trantermscode-this stores the terms code that indicates the terms selected by the user Tran price ref-this stores the price reference Tran_addendum - this stores text that is added by the seller Tran_date - this stores the date of the transaction Tran_time - this stores the time of the transaction Tran date confirm-this stores the date on which the transaction is confirmed as acceptable Tran time confirm-this stores the time at which the transaction is confirmed as acceptable Tran_reject_rems - this stores a flag to indicate that the trade has been rejected Tran spread attached-this stores an indication as to whether or not details of a spread are attached Since the trannumber field is linked to all the other "tran_" fields, by selecting a particular unique transaction number from the TRAN table 37, for example by double clicking on it, access can be gained to all the associated data on that transaction.

Additionally provided is another dynamic table, SPREAD, which contains extended information for spreads. This table is linked to the TRAN table 37 via the field that contains the indication as to whether or not details of a spread are attached. Each new spread is allocated a spread number as well as a transaction number, these numbers being identical. This allows the two tables to be tied together. The spread number is stored in a spread number field in the SPREAD table 38, as shown in Figure 3. Linked to the spreadnumber field are "spread"fields that contain details of the products that are being traded, the volume of the products, the start and end dates of the spread, the date the spread is agreed and the price of the trade.

Other dynamic tables may be provided as required to cover other trading strategies.

Once registered in the MEMBER table 31 and provided with an ID number, a trader can log onto the system and so has access to the functionality of the operating system via a menu table. Control of the facilities that an individual user has available to him/her is dictated by the settings in the menu table. Each user can act either as a buyer or as a seller.

In order to gain access to the market operating system. the user must log on by entering his unique member number, unique user ID number where appropriate and password. This causes the selection, using standard query langage, from the above-mentioned static and dynamic tables of all entries that include reference to the entered unique member number and, where appropriate, the unique user ID number. The selected entries from the static tables are listed in various customised menus that are subsequently presented to the user in a

template of an agreement that is to be completed to represent the deal that was previously transacted by telephone. The selected entries from the main dynamic table, i. e. the TRAN table 37, are included in a two customised lists.

The first list provides the user with a summary of the number of trades to which he is a party as a seller. The second list provides the user with a summary of the number of trades to which he is a party as a buyer. Trades in which the user is identified as a buyer are found by matching the login member ID to the counter party code in the CPART table and by matching the cpart nmem field in all of the records in the TRAN table against the nmem entry in the CPARTY table. A hotlink to the TRAN table 37 is provided so that by selecting a transaction from the customised list of transactions, for example by double clicking on the transaction number, the user can view in tabular form the details of the agreement.

As mentioned previously, in order to confirm a trade it is necessary for the seller to specify the terms of the agreed sale. As will be appreciated, in most relationships between a buyer and a seller in a particular market there are two contractual areas, one that is standardised and another that is variable. The standardised business relationships cover areas such as regulatory issues (eg 'know your customer"), credit terms, insolvency or failure by one of the parties to perform under the contracts traded. In the system in which the invention is embodied the standardised terms are set out in the User Agreement, to which the user must be party in order to register as a member of the market. The variable terms relate to the specific contracts into which the parties enter.

On most bilateral markets and particularly the commodity markets, it is the Seller's terms of business which apply and the process may be described as

"Seller driven". Following conclusion of a contract, therefore, it is the Seller who inputs the trade details and transmits them to the Buyer. The Buyer can either accept or reject the trade. Prior to acceptance, the Seller may amend the details as he sees fit or may delete the trade altogether.

In order to confirm a trade a user logs on to the system by entering his unique member number and where appropriate unique user ID and password. He then selects which of the clearing sites he wishes to use. Alternatively, the default in the member table 31 may be set so that the user is automatically presented with a pre-determined site. Once this is done, the trader is presented with a list of trade options that are selectable in order to construct the agreed sale. For example, were the user to enter the"Oilclear"site, the trade options presented in the menu could be"crude"or"product". Also included could be spread options such as"crude-product"or"crude-crude"or"product-product". If the user wishes to confirm a trade one of the trade options would be selected. For example if a trader has agreed to sell 15000 barrels of crude oil to counter party A, then in order to confirm the deal the user would access the"Oilclear"site and select the"crude"option.

After the trade option is selected the user is presented with a template of an offer, as shown in Figure 4, into which information defining the trade must be entered in order to confirm the agreement previously made between the traders.

The trade template includes fields for selecting and/or entering the variable terms. When the template is presented to the trader, the user and member fields 40 and 41 respectively include the name of the member and where appropriate the user name. This information is derived from the MEMBER and USERID

tables 31 and 32 respectively when the trader enters his member and user ID numbers and is automatically inserted into the template.

The template provides a plurality of fields for entering details of the trade for example a price field 42 for entering the price of the trade. Menus that allow the selection of particular features from the various static tables previously described are provided for entry of data into some of the fields. The menus are each listed by clicking on the arrows 43 shown in Figure 4. In this way, a product can, for example, be entered into the product field 44 by selecting the relevant product from a menu listing of products in the PROD table. Likewise contract terms can be entered into the terms field 45 by selecting the relevant terms from a menu listing of terms in the TERMS table. For example, the trader could select the London Metal Exchange terms for metal contracts or Shell UK Terms for the so-called"15 Day Brent"contracts.

Some of the menus list options that are specifically customised for that particular user. For example, one such menu lists the counter-parties in the CPARTY table that user can use. This menu is compiled by searching the CPARTY table for all counter parties that are listed with the user's member number and then selecting those counter parties found. Using the counter party menu in the template, the user can select the counter party or buyer with whom he has made the deal. Once this is selected it is entered into the counter party field 46. Likewise a broker can be selected from a menu listing of brokers, which is compiled by searching the BROKER table and selecting the brokers that are listed in the BROKER table that are associated with the member number that was entered at log in. Again, once this is selected it is entered into the broker field 47.

Using oil as an example the trader enters into the template the contract price, eg X dollars per barrel, contract quantity, eg X thousand barrels, contract period eg "spot"deals for immediate delivery, or a forward date or dates. Contract specification can also be defined, within which there may well be further variables such as quality (eg Brent Crude Oil, DIN specification Heating Oil), delivery location (eg North West Europe, the Gulf, the USA) and delivery terms for example on a free on board barge or a cost insurance and freight ocean- going vessel. In the case of options or swaps and more complex derivatives, further clauses such as the strike price or prices can be included. The agreement of these variable terms is in the province of the trader.

In order to re-construct the agreed trade, the user enters the variable terms, such as specific contract terms, the product that is to be traded, for example Brent Crude Oil, the volume for sale, the duration of the period for which the offer will stand, the date of the trade and the price. In addition, the seller must select from the customised menu listing that is selected from the CPARTY table, the counter party with whom agreement has been reached. The seller may, if desired, enter comments on the trade for the buyer to read.

Each of the terms selected by a seller is included in an appendix to the User Agreement. In this way, the overall agreement between the parties to the trade is defined.

Once the user has selected the relevant terms, a message is sent to the buyer in order to confirm that the terms reflect the agreed trade. This message is sent via the system server. When the message is received at the server, a unique

identification or transaction number is obtained from the TRAN table 37 for that trade and the transaction number is entered in the TRAN table 37. The transaction number is used for indexing and referencing the trade and the entry of a new transaction number indicates that a new transaction has been sent for confirmation. The message itself is stamped with the date and the time and an audit log is created indicating that an entry has been added to the TRAN table 37.

At this stage, stored in the TRAN table 37 are the member number of the user forwarding the message, which is stored as an index into the MEMBER table 31 and the user ID, which is stored as an index into the USERID table 32.

Additionally stored is the counter party code, the broker code, if appropriate, and the terms code that indicates the terms selected by the user, each of which is stored as an index into the corresponding table. Also, the date and time at which the agreement was completed are automatically entered into the TRAN table 37 date and time fields. Comments entered by the seller for the buyer to read are stored in the tranaddendum field.

If the buyer specified in the trade has the CPARTY e-mail initial property set in their record in the market CPARTY table 35 then the server is invoked to send an e-mail to the counter party's e-mail address as entered in the cpart e-mail field of the same record.

When a new trade is received, this is added to the counter-parties'list of transactions. The initial alleged sale is of course not a completed transaction and so is highlighted accordingly. When the counter-party selects the trade for review, details of it are displayed in a tabular format that includes both"accept

trade","reject trade"and"defer"options. The buyer is, however, not able to write into or alter any of the terms of the trade that were entered by the seller.

If the buyer wishes to reject the trade, he selects the"reject trade"option and a prompt is generated requesting reasons for the rejection. Once a reason has been provided, the transaction rejection flag of the transaction record in the TRAN table 37 is filled out with the reason and consequently the trade status is marked as rejected. The status of the transaction in the seller customised list of transactions is then altered to rejected, thereby notifying the seller of the rejection. Additionally, the seller may be notified by e-mail. Nothing further can be done with a rejected trade until the original seller modifies some aspect of the trade information, in which case the status is re-set to that of a normal, non-accepted trade by blanking the rejection mark.

When the seller is notified that a transaction is rejected, he can access the trade via his customised list of"seller"transactions and alter any offending terms.

The transaction is then re-entered into the system and the buyer is again notified of its presence. This process continues until the terms are accepted by the buyer.

If a trade is accepted this causes the current date and time to be entered into the date and time fields respectively in the transaction record stored in the TRAN table 37. This flags that the trade is confirmed for the purpose of future enquiries. The status of the trade will be notified to the user via the customised list of transactions that is available when the seller is logged onto the system.

The member number of the trade is also looked up in the member number of the CPART table 35 to determine if the CPART e-mail confirm flag is set. If it is,

then an e-mail is sent to the address specified in the CPART e-mail field of the counter party's record.

Once the trade has been accepted and recorded in the TRAN table 37 as such, the parties are bound by the terms of the User Agreement and those variable terms specified by the seller.

An advantage of the invention is that central registration of the deal is conclusive evidence of its existence and there is no need for further telexes, faxes or other trade confirmations. In addition the requirement for manual trade entry in accounting systems can be removed and trade re-conciliations with counter parties are facilitated.

A physical or off exchange derivative contract can therefore be confirmed and given legal status within a straight through process without the need for re- entry. It will therefore reside on the user accounting system until it is settled either being offset by another position with the same counter party or by delivery of the relevant product or cash sum.

In rejecting a trade, the Buyer may give his reasons in an accompanying text message, and it is then possible for the Seller to enter amendments if he agrees with the Buyer.

Where there is a trading dispute in relation to one of the variables of the trade such as price or date, then pursuant to the User Agreement. a Referee is appointed to set a price at which the trade will be input and registered. This in effect crystallises the position between the parties. If there remains a dispute as

to any loss resulting then it would be possible for the parties to go to the second stage, which is arbitration under the User Agreement. Arbitration is also available in relation to disputes over the performance of the contract although the parties may prefer to invoke arbitration clauses (eg the London Metal Exchange or International Petroleum Exchange clauses) The screen that the trader sees is configured to allow him to easily and intuitively input the other relevant variable contract terms set out above, which he is authorised to agree. This removes the need for certain clerical trader support functions. Finally, where a broker arranges a deal but does not act as a principal, this fact may be recognised as a further variable term and it will be possible to allow brokers to be given"read-only"access to deals in which they have been involved. This is a useful administrative tool.

A skilled person will appreciate that variations of the disclosed arrangements are possible without departing from the invention. Accordingly, the above description of a specific embodiment is made by way of example and not for the purposes of limitation. It will be clear to the skilled person that minor modifications can be made without significant changes to the operation described above.