WO2001042950A2 - Systeme de gestion d'ordres - Google Patents

Systeme de gestion d'ordres Download PDF

Info

Publication number
WO2001042950A2
WO2001042950A2 PCT/GB2000/004675 GB0004675W WO0142950A2 WO 2001042950 A2 WO2001042950 A2 WO 2001042950A2 GB 0004675 W GB0004675 W GB 0004675W WO 0142950 A2 WO0142950 A2 WO 0142950A2
Authority
WO
WIPO (PCT)
Prior art keywords
order
broker
terminal
fulfilling
transaction
Prior art date
Application number
PCT/GB2000/004675
Other languages
English (en)
Other versions
WO2001042950A8 (fr
Inventor
Charles Richard Giessen
Stuart David Mcdowell
Original Assignee
Broker-To-Broker Networks, Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/GB2000/004180 external-priority patent/WO2001042949A2/fr
Application filed by Broker-To-Broker Networks, Inc filed Critical Broker-To-Broker Networks, Inc
Priority to AU26897/01A priority Critical patent/AU2689701A/en
Publication of WO2001042950A2 publication Critical patent/WO2001042950A2/fr
Publication of WO2001042950A8 publication Critical patent/WO2001042950A8/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the present invention relates to order management systems which may be used to facilitate transactions on an exchange.
  • An example of a horizontal business-to-business exchange is MRO.COM which provides a market place for materials, repair and operations goods and services.
  • exchange refers to any type of exchange on which business can be transacted.
  • computer systems embodying the present invention can be used with any type of exchange, the exemplary embodiment described herein relates to securities trading exchanges (including traditional stock exchanges and alternative trading systems (ATSs) and electronic crossing networks (ECNs) ) .
  • ATSs stock exchanges and alternative trading systems
  • EPNs electronic crossing networks
  • Principals or agents such as stock brokers, investment banks or appropriately regulated asset managers having direct or indirect access to securities exchanges in order to buy and sell on behalf of investors are referred to herein as "brokers” .
  • broker is synonymous with the term “Member” .
  • a method of operating a computer system for managing orders for transactions on an exchange wherein an order for a transaction is placed by an originating member and performed by a fulfilling member, each member having access to a different terminal of the system, the method comprising: inputting at a first terminal at least one information item of an electronic transaction; transmitting the at least one information item from said first terminal to a processing system, said processing system being operable to route information items between said first terminal and a second terminal and to generate transaction criteria to be agreed by said originating member and said fulfilling member; receiving at said first terminal transaction criteria accepted at said second terminal; displaying at said first terminal transaction criteria accepted at said second terminal; and inputting at said first terminal an indication of acceptance of said displayed transaction criteria.
  • said indication of acceptance is transferred to the processing system and the processing system is operable to generate settlement instructions responsive to receipt of the indication of acceptance.
  • the processing system then issues settlement instructions on behalf of both the originating member and the fulfilling member.
  • the transaction criteria generated by the processing system comprises settlement information.
  • the transaction criteria generated by the processing system may comprise settlement information received from the originating member.
  • the transaction criteria generated by the processing system comprises settlement information received from the fulfilling member.
  • the transaction criteria displayed at the first terminal typically comprises one or more information items selected from: an indication of what has been transacted; executed quantity, average price; calculated average price; net proceeds, commission rate; total commission; identity of opposite party; trade date and settlement date. A plurality of information items can be transmitted successively from the first terminal to the processing system.
  • a first information item may be transmitted from the first terminal to the processing system and the processing system cause the first terminal to display a plurality of further information items.
  • an information item is converted from a first format appropriate to the first terminal into a second format appropriate to the second terminal.
  • Terminals of preferred embodiments display a list of orders. The position of an order in the list of orders depends upon the priority of the order relative to other orders. In general, the priority of an order depends on its current status; and an order in a status requiring action urgently is displayed more prominently than an order requiring action less urgently or no action at all. Preferably, the position of an order in the list of orders changes responsive to a change in status of the order.
  • the possible order status may include one or more of the following: cancel request; modification request; sign-off request; cancel fill request; rejected; placed; cancel rejected; modification rejected; sign-off rejected; cancel pending; modification pending; sign-off pending; fully filled; partially filled; pending fill; signed off; cancelled; new order; cancel fill rejected and cancel fill pending.
  • the order list can be rearranged based on numeric or alphabetical order using sort functions.
  • filter criteria can be applied to limit the number of orders appearing in the order list to orders of one or more pre-defined categories. The filter criteria available to limit the order list depend on the current order list of the connected member.
  • a terminal can display summary information including one or more of the following information items: order status; trade date; transaction type; quantity; security; country and price information.
  • Terminals may also display detailed information containing detailed information on an order, the detailed information including one or more of the following information items: order status; trade date; transaction type; quantity; security; country, price information, time and place of trade, broker, average price information, settlement currency, gross consideration; execution venue; commission rate; capacity acted in; specific instructions; audit trail information and market information.
  • Preferred embodiments may generate reports based on an instruction input by a member at an end terminal .
  • a member can define the contents of the report.
  • Computer systems embodying the present invention may be accessible to a supervisor at a control terminal .
  • a supervisor may be connected at the same time as one or more members. In such cases, the computer system determines the category of user when a new connection is established.
  • the system permits screen content viewed by a supervisor at a control terminal to substantially correspond to screen content viewed by a member at a member terminal.
  • the supervisor has access to the system in order to perform tasks selected from one or more of the following: monitor use by an originating member, monitor use by a fulfilling member; add an originating member record; add a fulfilling member record; delete an originating member record; delete a fulfilling member record; amend a record of an originating member; amend a record of a fulfilling member; and add, delete or amend records of individual users authorized to use the system on behalf of originating and fulfilling members.
  • the first terminal may be accessible to a member operating as an originating member and the step of inputting the at least one information item of a transaction includes inputting information on a transaction to be performed.
  • the first terminal may be accessible to a member operating as a fulfilling member and the step of inputting the at least one information item of a transaction includes inputting information on a transaction which has been performed.
  • a computer system for managing orders for transactions on an exchange wherein an order for a transaction is placed by an originating member and performed by a fulfilling member, each member having access to a different terminal of the system, the system comprising: a first terminal having an interface for inputting information items of an electronic transaction; a communications interface arranged to transmit information items from said first terminal to a processing system, said processing system being operable to route information items between said first terminal and a second terminal and to generate transaction criteria to be agreed by an originating member and a fulfilling member; a display unit at said first terminal adapted to display transaction criteria accepted at said second terminal; and an input device to input at said first terminal an indication of acceptance of said displayed transaction criteria.
  • a computer program comprising program code for managing orders for transactions on an exchange, wherein an order for a transaction is placed by an originating member and is performed by a fulfilling member
  • the code means comprising: a first set of instructions of providing an input interface at a first terminal, said input interface being adapted to receive information items of an electronic transaction; a second set of instructions for transmitting information items from said first terminal to a processing system, said processing system being operable to route information items between said first terminal and a second terminal and to generate transaction criteria to be agreed by an originating and a fulfilling member; a third set of instructions for displaying at said first terminal transaction criteria accepted at said second terminal; and a fourth set of instructions for receiving an indication of acceptance of said displayed transaction criteria.
  • the computer program may be recorded on a computer readable medium.
  • a method of managing orders for transactions on an exchange wherein an order for a transaction is placed by an originating member and performed by a fulfilling member, the method comprising: providing at least one information item relating to a transaction; sending said information item to a central processing system, said processing system being operable to route information items between an originating member and a fulfilling member, and to generate transaction criteria to be agreed by said originating member and said fulfilling member; completing the transaction as defined by the at least one information items; providing to a first party to the completed transaction criteria already accepted by the second party to the transaction; receiving an indication of acceptance of the transaction criteria from said first party.
  • a method of operating a computer system for monitoring an order management process wherein an order for a transaction is placed by an originating member and performed by a fulfilling member, the originating and fulfilling member each having access to different terminals of the system, the method comprising: providing a control terminal for connecting a system supervisor to the computer system; sending a user identifier from the control terminal to a processing system, responsive to receipt of which the processing system determines the user at the control terminal is authorized to monitor order management processes and generates a list of members; receiving at the control terminal a prompt to identify a member to be monitored from the list of members; inputting at the control terminal a response to the prompt identifying a member to be monitored; and displaying at the control terminal information substantially corresponding to that available at the terminal of the identified member.
  • a computer system for monitoring an order management process in which an order for a transaction is placed by an originating member and performed by a fulfilling member comprising: an input unit to receive a user identifier input by a user; a communication interface to send the user identifier to a processing system; a processing system comprising a data store holding information on authorized users, the processing system being operable to determine that a user is authorized to monitor order management processes and to generate a list of connected members; a display unit to display a prompt for the user to select a member to be monitored from a list of members and for displaying order management information substantially corresponding to that available at the terminal of the selected member.
  • a computer program comprising program code for monitoring an order management process, wherein an order for a transaction is placed by an originating member and performed by a fulfilling member, the originating and fulfilling member each having access to different terminals of the system
  • the program code comprising: a first set of instructions for connecting a system supervisor to the computer system; a second set of instructions for sending a user identifier input by user at a control terminal from the control terminal to a processing system, responsive to receipt of which the processing system determines the user at the control terminal is authorized to monitor order management processes and generates a list of connected members; a third set of instructions for receiving at the control terminal a prompt to identify a connected member to be monitored from the list of connected members; a fourth set of instructions for receiving at the control terminal a response to the prompt identifying a member to be monitored; and a fifth set of instructions for displaying at the control terminal information substantially corresponding to that viewed simultaneously by the member being monitored.
  • a method of operating a computer system to facilitate transactions on an exchange, a transaction being performed by a fulfilling member having access to the exchange on behalf of an originating member not having access to the exchange comprising: receiving at a first interface of a processing system at least one information item of an electronic transaction proposal from an originating member; transmitting at least one information item relating to the electronic transaction proposal from a second interface of the processing system to a fulfilling member; generating at the processing system transaction criteria to be accepted by the originating member and the fulfilling member; and receiving from each of the originating member and the fulfilling member an indication of acceptance of the transaction criteria generated by the processing system.
  • a computer system for facilitating transactions on an exchange, a transaction being performed by a fulfilling member having access to the exchange on behalf of an originating member not having access to the exchange, the system comprising: a first processing system interface adapted to receive one or more information items of an electronic transaction proposal from an originating member; a second processing system interface adapted to transmit one or more information items relating to the electronic transaction proposal to a fulfilling member; a processing system for routing communications including information items to and from the first and second interfaces, the processing system being operable to generate transaction criteria to be agreed by the originating member and the fulfilling member, and wherein the processing system is arranged to receive first and second information items indicating acceptance of the transaction criteria by each of the originating member and the fulfilling member.
  • a computer system for facilitating transactions on an exchange, a transaction being performed by a fulfilling member having access to the exchange on behalf of an originating member not having access to the exchange, the system comprising: a first processing system interface adapted to receive one or more information items of an electronic transaction proposal from an originating member; a second processing system interface adapted to transmit one or more information items relating to the electronic transaction proposal to a fulfilling member; at least one further processing system interface adapted to issue settlement instructions in respect of a transaction performed by the fulfilling member; and a processing system for routing communications including information items to and from the first and second interfaces, the processing system being operable to generate settlement instructions to be issued via the at least one further interface on behalf of the originating member and the fulfilling member .
  • a computer readable medium having stored therein a set of general purpose routines for facilitating transactions on exchanges, the computer readable medium comprising: a first routine for receiving at least one information item of a transaction proposal from an originating member; a second routine for transmitting at least one information item of the transaction proposal to a fulfilling member; a third routine for generating first and second transaction criteria to be accepted by said originating member and said fulfilling member; and a further routine for receiving first and second indications of acceptance of said transaction criteria from said originating member and said fulfilling member.
  • a transaction being performed by a fulfilling member having access to an exchange on behalf of an originating member not having access to the exchange
  • the program code comprising: a first set of instructions for receiving at least one information item of a transaction proposal from an originating member; a second set of instructions for transmitting at least one information item of the transaction proposal to a fulfilling member; a third set of instructions for generating transaction criteria to be agreed by each of said originating member and said fulfilling member and for receiving first and second indications of agreement from said originating member and said fulfilling member.
  • a method of facilitating transactions on an exchange a transaction being performed by a fulfilling member having access to the exchange on behalf of an originating member not having access to the exchange, the method comprising: receiving at least one information item of a transaction proposal from an originating member; transmitting at least one information item of the transaction proposal to a fulfilling member; generating transaction criteria to be accepted by the originating member and the fulfilling member; and receiving indications of acceptance of the transaction criteria from each of said originating member and said fulfilling member.
  • Preferred embodiments provide a system, method, and software for broker-to-broker trading, in which an order for a proposed transaction is received from an originating member, indicating a designated fulfilling member. The order is in a format appropriate to the originating member.
  • the order is converted into in a format appropriate to the fulfilling member and transmitted to the fulfilling member and settlement instructions are issued from a central location.
  • preferred embodiments deal with local-specific conversion and settlement issues are automatically handled, thereby increasing the efficiency of cross-border transactions, reducing transaction costs, fostering increased transparency, and increasing the volume and liquidity of international securities transactions.
  • Preferred embodiments thus provide a high value, robust messaging and transaction processing infrastructure that will enable executing-brokers ("Fulfilling Members" (FMs) ) to service orders directed to them and provide brokers placing orders (“Originating Members” (OMs) ) variable lower-cost access to securities markets and transaction services worldwide.
  • FIGURE 1 is a schematic diagram illustrating a broker-to-broker communication system embodying the present invention
  • FIGURE 2 is a schematic diagram illustrating key information flows in a system according to Figure 1
  • FIGURE 3 is a schematic diagram of an end terminal for use in the broker-to-broker system of Figure 1
  • FIGURE 4 is a schematic diagram of a computer system implementing the broker-to-broker system of Figure 1
  • FIGURE 5A is a flow chart illustrating connection and display update processes of the computer system of Figure 4
  • FIGURE 5B and 5C are flow charts illustrating a supervisory feature of the computer system of Figure 4
  • FIGURE 6 is a flow chart illustrating order placement processes of the computer system of Figure 4
  • FIGURE 7 is a flow chart illustrating order acceptance/rejection processes of the computer system of Figure 4
  • FIGURE 8 is a schematic diagram illustrating a broker-to-broker communication system embodying the present invention
  • FIGURE 2 is a schematic diagram illustrating key information flows in a system according to Figure 1
  • Originating Member is the entity on the broker-to-broker system's network that originates orders into the system and may or may not have direct access to an exchange.
  • the originating member may be any party or institution wishing to place orders with a fulfilling member on behalf of themselves or third parties.
  • the fulfilling member has the following options available to them as to how to fulfil the order or parts thereof.
  • - On Exchange i.e. by buying/selling securities from/to another exchange member.
  • the fulfilling member may or may not expose the order to the entire market depending on the rules of the market.
  • - Off Inventory i.e. by buying/selling securities from/to the fulfilling member own inventory of securities.
  • Agency Cross i.e. when the fulfilling member determines that there are two or more orders on opposite sides of each other, (i.e. one order is for a sale and another order is for a purchase of the same set of securities) , the member matches the two orders .
  • - Third party crossing network i.e.
  • Party B the fulfilling member is designated as Party B.
  • Member Members are customers of the broker- to-broker system usually having access to one exchange or another. They are usually brokers acting as transacting agents for investors. However, a user who does not have access to an exchange may also use the broker-to-broker system. Members of the broker-to-broker system may authorize a plurality of individual users to use the broker- to-broker system on their behalf and in general the term member should be construed as including these individual users (if any) .
  • the broker-to- broker system through one of its facilities management operating subsidiaries and in conjunction with its partners and agents may be selected by the member to install, configure and operate the product on behalf of and in the name of that member.
  • Order An order is an instruction from one party to another party to obtain/dispose of securities on behalf of the issuing party in return for some payment. Typically unless an order is fulfilled, no transaction will be deemed to have taken place.
  • Proceeds Proceeds are the cash monies or securities which parties to a transaction will deliver/receive at the conclusion of the transaction.
  • Settlement Settlement is the process of delivering the proceeds of a transaction into the custody of the beneficiaries of the transaction, e.g. cash into a bank account, securities into a securities account.
  • the depository may nominate, approve and supervise certain commercial organizations to provide the interface between the depository and the owners of securities - these organizations are the custodians who maintain custody of the securities on behalf of the actual owners. (Custodians may also maintain vaults where paper certificates are stored) .
  • FIG. 1 represents a schematic overview of a broker-to-broker system embodying a preferred order management system.
  • the broker-to-broker system is an order routing and settlement facilitation system, which comprises an integrated network of desktop applications through which an originating member 204 seeking fulfillment of an investor 210 's securities transaction order may enter the order for delivery to a designated fulfilling member 208 who is qualified to fulfill the order or part thereof on the basis of prevailing conditions in the fulfilling members' market 212, subject to the conditions specified by the originating member 204.
  • a broker-to-broker network arrangement comprises two secure interfaces OMIF 202 and FMIF 206 connecting originating members 204 and fulfilling members 208, respectively, to a broker- to-broker processing system 200 (having "order management" capabilities) , which processing system acts as a transaction manager tracking the status of orders.
  • Additional integrated applications generate settlement instructions, collect and report status information from other parts of the broker-to-broker system, provide access for the correction of problems of the broker-to-broker system, and perform data storage and retrieval functions.
  • Members are able to use the broker-to-broker system as originating members 204 or fulfilling members 208, or both.
  • originating members 204 and fulfilling members 208 can be connected to the broker-to-broker processing system 200 and that the interfaces 202 and 206 can be any type necessary to achieve this.
  • originating members 204 may enter information concerning a proposed transaction. If all required information is properly provided, the order is then sent to an order management system for routing and delivery to the fulfilling member 208.
  • the processing System 200 is able to perform certain data conversion or translation services of a clerical or administrative nature when a cross-border or inter-market trade calls for such services.
  • the combined order routing and settlement management features of the broker-to-broker processing system 200 afford a seamless and efficient inter-exchange order management system.
  • Conversion service features of the processing system 200 of this embodiment provide opportunities for increased efficiency of cross-border and inter-market transactions and thus contribute to broader access to securities markets worldwide, in particular because the processing system 200 offers those capabilities at lower variable costs to members who have previously been less able to fully take advantage of advanced technologies to overcome the costs and other burdens arising from the numerous additional variables associated with international securities transactions.
  • Another advantage of this embodiment is that settlement instructions are issued from a single source. Accordingly, the use of the broker-to-broker network by members may further increase the transparency of international securities markets and afford to investors through their brokers increased liquidity and efficiency in conducting securities transactions. All communications are routed through the broker-to-broker processing system 200. All communications sent to and from the broker-to-broker system may be encrypted using 128 bit SSL technology to ensure complete confidentiality.
  • a fulfilling member 208 designated by the originating member 204 will review the information for completeness and accuracy, as will be described in more detail hereinafter.
  • the fulfilling member 208 can then determine in its sole discretion whether to accept or reject the order.
  • the fulfilling member 208 will then seek to execute the order on the specified market satisfying the terms of the order.
  • the fulfilling member and the originating member communicate through the broker-to-broker system or through any other means they may choose as to the status of fulfillment of the order and any modifications thereto.
  • information concerning the transaction is sent to the originating member 204 for review.
  • the agreed transaction can then be submitted by both members to the settlement management portion of the broker-to-broker processing system 200 which generates settlement instructions, based entirely on transaction details and settlement account (and preference) information previously provided by members, for transmission to settlement agents designated exclusively by the respective members.
  • Additional functions to be performed by the broker-to-broker processing system 200 include the generation of execution reports, and similar functions as may be desired by brokers using the broker-to-broker computer system.
  • FIG. 2 schematically depicts the system flows for the broker-to-broker system, showing how an order moves through the various network elements until the proceeds are delivered to one of the broker-to-broker system's members.
  • the investor issues an order to his/her financial originating member who enters the order into an originating member interface OMIF 202.
  • the order 10 is then transmitted through the processing system 200 via an order management sub-system 16 to a fulfilling member via a fulfilling member interface FMIF 206.
  • the fulfilling member executes the order in his/her market and notifies the originating member of the results by sending a fill message 12 to the originating member via the originating member interface OMIF 202.
  • a message 14 detailing the transaction is sent to a settlement management system 20 which completes the process by issuing settlement instructions 22 according to the SWIFT protocol, or another suitable protocol, thereby ensuring that both parties deliver/receive the securities, and that monies are paid by the members to/from each other.
  • a customer service system 24 is notified by all of the other network elements of the processing system 200 of the status of the transaction so that inquiries may be easily and rapidly dealt with.
  • FIG. 3 is a block diagram illustrating a computer system 400/402 which is used as an end terminal of both the originating member and the fulfilling member in the exemplary embodiment described herein.
  • the computer system 400/402 includes general purpose units including a display unit, an input unit, processor and memory units and an output unit as will be described in more detail below.
  • Computer system 400/402 includes a bus 102 or other communication mechanism for communicating information, and a processor 104 coupled with bus 102 for processing information.
  • Computer system 400/402 also includes a main memory 106, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 102 for storing information and instructions to be executed by processor 104.
  • Main memory 106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 104.
  • Computer system 400/402 further includes a read only memory (ROM) 108 or other static storage device coupled to bus 102 for storing static information and instructions for processor 104.
  • ROM read only memory
  • a storage device 110 such as a magnetic disk or optical disk, is provided and coupled to bus 102 for storing information and instructions.
  • Computer system 400/402 may be coupled via bus 102 to a display 112, such as a cathode ray tube (CRT) , for displaying information to a computer user.
  • An input device 114 is coupled to bus 102 for communicating information and command selections to processor 104.
  • cursor control 116 such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 104 and for controlling cursor movement on display 112.
  • This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y) , that allow the device to specify positions in a plane.
  • communication with the broker-to-broker processing system is facilitated by browser software running on the computer system 400/402 by means of the processor 104 executing one or more sequences of one or more instructions contained in the main memory 106. Such instructions may be read into main memory 106 from another computer-readable medium, such as storage device 110.
  • main memory 106 causes processor 104 to perform the process steps described herein.
  • processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 106.
  • the term "computer-readable medium" as used in this context refers to any medium that participates in providing instructions to processor 104 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media.
  • Non- volatile media include, for example, optical or magnetic disks, such as storage device 110.
  • Volatile media include dynamic memory, such as main memory 106.
  • Transmission media include, for example, coaxial cables, copper wire, fiber optics and radio interfaces.
  • Transmission media can thus also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications.
  • RF radio frequency
  • IR infrared
  • Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
  • Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 104 for execution.
  • the instructions may initially be borne on a magnetic disk of a remote computer.
  • the remote computer can load the instructions into its dynamic memory and send the instructions over a communication link such as a telecommunications link with or without using a modem.
  • a modem local to computer system 400/402 can receive the data on a communication link and use an infrared transmitter to convert the data to an infrared signal.
  • An infrared detector coupled to bus 102 can receive the data carried in the infrared signal and place the data on bus 102.
  • Bus 102 carries the data to main memory 106, from which processor 104 retrieves and executes the instructions.
  • the instructions received by main memory 106 may optionally be stored on storage device 110 either before or after execution by processor 104.
  • Computer system 400/402 also includes a communication interface 118 coupled to bus 102.
  • communication interface 118 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a telecommunications line.
  • ISDN integrated services digital network
  • Communication interface 118 provides a two-way data communication coupling to a communication line 120 comprising part of the originating member interface OMIF 202 or the fulfilling member interface FMIF 206, depending on whether the computer 400/402 is an end terminal belonging to an originating member or a fulfilling member.
  • Fixed or leased telecommunications lines are used to connect the end terminals 400/402 to the broker-to-broker processing system 200.
  • the minimum fixed-line speed available for the broker-to-broker system is at present 64Kbits/second.
  • End terminals 400 of the originating and fulfilling member interfaces OMIF 202 comprise a web technologies based front -end (or graphical user interface) which the members interact with and which connects to an application core for processing the data entered by the respective member.
  • Preferred embodiments also include a computer-to-computer applications programmer interface OMIF-API so the originating member can interface his/her computer systems directly into the broker-to-broker system.
  • FMIF 206 the system which interfaces the broker-to-broker system to the fulfilling broker 208, provides him/her with the ability to interact with the broker-to-broker system and its other customers.
  • FMIF 206 comprises: a web technologies based front -end, through which the fulfilling member interacts with the broker-to- broker system and an application core.
  • Preferred embodiments also include a computer-to-computer applications programmer interface, FMIF-API, which the fulfilling member may use to interface his/her systems directly into the broker-to-broker system network so as to eliminate re-keying of data.
  • the front-end software uses the following standards: Microsoft Internet Explorer 4/5; HTML 4: JavaScript; JAVA; 128 Bit SSL.
  • the application core may be built using the following standards: Apache Server; CGI with Perl and C/C++ 504; Java servelets; Java servelet pages; application server (e.g.
  • Cookies small files stored on the user's local hard-drive, are commonly used by web based applications to store data about the user and their preferences so that when the user next logs on, the system can skip the steps required to obtain that data for the new session.
  • the use of cookies within the OMIF 202 and FMIF 206 interfaces can be severely restricted if not eliminated so as to minimize any security risk.
  • the OMIF 202 and FMIF 206 are constructed so as to require only minimal resources at the end terminals 400,402. That is, they have an operating "footprint" on the user's machine which is as lightweight or small as possible. It must not be considered the norm that users will be technically literate and that they will have high powered machines.
  • a typical end terminal might be a Pentium personal computer running the Microsoft Windows NT operating system.
  • Figure 4 illustrates the preferred architecture for the broker-to-broker processing system 200.
  • Figure 4 also shows how the end terminals of an originating member 400 and a fulfilling member 402 and a supervisor 403 are connected to the broker-to- broker processing system 200 by a secure network 404.
  • the secure network 404 comprises at least the communications lines 120 from the end terminals 400 and 404.
  • the broker-to-broker processing system 200 comprises a web server 410, an application server 420 provided with a front end database 425, an order management system (OMS) server 430 provided with an OMS database 435, and a settlement management system (SMS) server 440 provided with a SMS database 445.
  • OMS order management system
  • SMS settlement management system
  • the web server 410 is connected to a messaging server 480 and the application server 420 is connected to a security server 470.
  • the interface between the web server 410 and the application server 420 operates based on the Java RMI protocol.
  • the order management system server 430 is connected to the application server 420 via an interface defined according to the Orbix CORBA protocol.
  • the web server 410 includes a submission processor 412 and a page generator application 414.
  • the web server 410 supports a range of internet- based server technologies including, for example, hyper text mark-up language (HTML), JavaScript, extensible mark-up language (XML) , and other protocols for the definition of page content, format and functionality.
  • HTML hyper text mark-up language
  • XML extensible mark-up language
  • the web serer 410 is responsible for the storage of images (e.g.
  • the web server 410 also holds and runs software for secure socket layer management and SSL encryption information. It should be appreciated that the web server is not connected to the internet in this embodiment.
  • the messaging server 480 connected to the web server 410 manages the storage and delivery of messages (for example emails) .
  • the messaging server 480 operates according to the POP, IMAP and SMTP protocols to deliver emails to a browser application in HTML format. Access to the messaging services depends upon user authentication and the existence of an email account in the name of the user. A new user has an account set up in the messaging server 480 before he/she can use the messaging services of the broker-to-broker system.
  • the application server 420 includes a processor (not shown) , order and query data access software 422, order manager software 424 and order storage software 423.
  • the application server 420 operates hosting and data access services for the web server 410 to create pages which are implemented as Enterprise Java Beans.
  • the front end database 425 connected to the application server 420 holds records of orders 426, executions 427, requests 428 and user control information 429.
  • the application server 420 controls page generation through the web server 410 using the order manager software 420. Among other functions the application server controls and determines the look and feel of the order management software as well as determining the sequence of steps which make up the processes for data gathering, data processing and data provision by the processing system 200.
  • the security server 470 implements access and validation procedures.
  • the order management system server 430 includes a request processor 432, order publisher software 434 and an order processor 436.
  • the OMS database 435 holds records of orders 437, executions 438 and requests 439.
  • the order management system server 430 can transfer data to the front end database 425 via the order publishing software 434 and the order storage software 423. Accordingly, data held in the OMS database 435 can be replicated into the front end database 425 following an access to the OMS database 435 by the order processor 436.
  • the order management system thus maintains a representation of each order entered into the system by originating members. It records changes in the status of the orders responsive to actions taken by the originating and fulfilling members.
  • the order management system server 430 can also access the SMS database 445 via the database link 452.
  • the FIX server 490 is provided in order to implement application programmer interfaces, as will be explained in more detail hereinafter.
  • the settlement management system server 440 has a trade processor 442 capable of generating settlement instructions in the form of, for example, SWIFT format messages 443 and fax messages 444.
  • the SMS database 445 holds records of settled trades 446, stock information 447, market information 448, member information 449 and commission rate information 450.
  • the settlement management system server 440 polls the SMS database 445 at predetermined time intervals to identify transactions for which settlement instructions can be generated.
  • the SMS database 445 receives an intra-day price feed every half-past the hour, where the price given is the price of the hour (e.g. the price at 10.00am is delivered at 10.30am) .
  • the days closing prices are also fed in nightly.
  • the settlement management system server 440 need only become involved when the settlement particulars have been agreed by the parties to the transaction.
  • the application server 420 and the front end database together define an "application subsystem" of the computer system on which the core application software runs.
  • the core application software provides content to the end terminals.
  • the order management system server 430 and the OMS database 435 together define an order management sub-system which, as the name suggests, is responsible for validating each originating member order; keeping track of the status of orders; controlling, tracking, and applying conversions/translations to the order; entering the business rules associated with translations; and dispatching completed orders for settlement processing.
  • the settlement management system server 440 and the SMS database 445 can be regarded as comprising a settlement management sub-system.
  • the first action taken by the order management sub-system is to apply stringent/rigorous content validation to each order.
  • the order management sub-system can access information in the settlement management sub-system, as may be required, and provide messages and other content to the end terminals via the application server 420, front end database 425 and the web server 410.
  • an order passes the content validation checks of the order management sub-system, it is routed to the fulfilling member specified by the originating member. All interactions with orders are passed via the order management sub-system which ensures that predefined rules of business are not violated. For example, the order management sub- system will prohibit members from entering an executed quantity greater than the order quantity; it will prohibit multiple members from applying changes to the order simultaneously; it will ensure that the state rules of an order cannot be violated.
  • the order management sub-system facilitates and controls the following actions performed by either the originating member (OM) and/or the fulfilling member (FM) in respect of an order in the state specified:
  • the order management sub-system also routes any requests against an order from the originating party to the receiving party; and conversely the accept/rejection of a request is routed back to the originating party, as will be explained further hereinafter.
  • the front end software may be used at many sites, and very often where the level of technical support is minimal or self-help is the norm, it preferably does not require the installation of any components from disk/CDROM etc at the customer's premises.
  • Member information is held in the application sub-system, the order management subsystem and the settlement management subsystem. If it is desired that a new member should use the broker-to-broker system, a member record 449 is created in the settlement management system using a database access user interface.
  • the member record comprises a member identifier and correspondence details for the member.
  • Member records held in the settlement management system typically also define settlement criteria including settlement account information and an indication of preferred types of settlement instructions.
  • the user control information 429 held in the front end database 425 determines what a user sees at an end terminal 400, 402, 403.
  • the user control information store can be accessed by means of a Front End Administration Tool (FEAT) .
  • the Front End Administration Tool is a web- technologies based program which allows customer service representatives or other supervisory personnel to create, edit and delete new brokerages and users within the application subsystem.
  • the Front End Administration Tool also provides access to a login facility for system supervisors (also referred to herein as "shadow login") .
  • system supervisors also referred to herein as "shadow login" .
  • Within the user control information 429 a plurality of user records each have a user identifier which, where appropriate, corresponds to the member identifier of the corresponding member record 449 in the settlement management system.
  • the user control information 429 also holds user records for customer service representatives and other authorized supervisors of the system.
  • a user record controls the functionality available via the graphical user interface at an end terminal.
  • each user record comprises attributes which define the user category of a given user of the broker-to-broker system.
  • the attributes include an originating member (OM) , a fulfilling member (FM) or a customer services representative (CSR) .
  • a customer service representative may need to operate as all three of the above user categories such that the customer service representative can login from an end terminal 403 and observe the performance of both originating and fulfilling member operations.
  • User records of the user control information also hold user access permission information. User access permissions determine what access a user has to the broker-to-broker system.
  • Access permissions may also be limited to specific subsystems of the broker-to-broker system. That is, a customer services representative may have direct access to each of the broker-to-broker system's subsystems, whereas an originating member will be limited to use via his end terminal.
  • members and/or customer relations representatives can view an order management screen displayed on their end terminals.
  • the order management screen can display an order list and order information panels.
  • the order list 509 is displayed on the left hand side of the order management screen and comprises a summary of order details and status (see Figure 5A) .
  • the summary of order details shown on the order list 509 includes an indication of order status, trade date, type of transaction, quantity, security, country, price and client ID (not visible to customer service representatives) .
  • the right hand side of the order management screen displays an order information panel 511 containing detailed information on the order currently highlighted in the order list.
  • the contents of the order list 509 and order information panel 511 depends on whether the viewer is an originating broker, a fulfilling broker or a customer services representative.
  • the order information panel 511 has frames including information on order status, order details, audit trail information, broker information and market information.
  • users can also access a messaging facility (by clicking the message tab 513) , perform market or security look-ups and generate reports.
  • the front end software accessed via end terminals 400 of the OMIF 202 may include the following frames or capabilities: Order entry; order manager (indicating status of orders, cancel, modify, sign- off) ; intra broker-to-broker system member messaging (e-mail, interactive text messaging, e.g. ICQ, IRC, interactive voice, video messaging, e.g. net meeting) ; transaction history report generation; lookup facilities for securities information; look- up facilities to locate other members on the broker- to-broker system; look-up facilities for market information; and an interface to the broker-to- broker system on-line electronic library.
  • order entry Order entry
  • order manager indicating status of orders, cancel, modify, sign- off
  • intra broker-to-broker system member messaging e-mail, interactive text messaging, e.g. ICQ, IRC, interactive voice, video messaging, e.g. net meeting
  • transaction history report generation lookup facilities for securities information; look- up facilities to locate other members on the broker- to-broker system; look-up facilities for
  • the front end software accessed via the end terminals 402 of the FMIF 406 includes the following frames or capabilities: order acceptance; execution entry; transaction manager (status of orders, cancel, modify, cancel fill, sign off); intra broker-to-broker system customer messaging; (e-mail; interactive text messaging, e.g. ICQ, IRC; interactive voice, video messaging, e.g. net meeting;) transaction history report generation; look-up facilities for securities information; Look- up facilities to locate other members on the broker- to-broker system; look-up facilities for market information; and an interface to the broker-to- broker system on-line electronic library.
  • the system can perform certain data conversion or translation services of a clerical or administrative nature when a cross-border or inter-market trade calls for such services.
  • the conversion service options available to originating members include: retrieval from data storage and inclusion in the message of appropriate additional securities identification numbers (e.g., the system can provide the applicable ISIN number when given a particular CUSIP number for securities identified for trading in multiple jurisdictions) ; the reformatting of orders to comply with the customs, dictates or market vernacular of a particular exchange to be used by the designated fulfilling member (e.g., "market held" from a U.S.
  • appropriate additional securities identification numbers e.g., the system can provide the applicable ISIN number when given a particular CUSIP number for securities identified for trading in multiple jurisdictions
  • the reformatting of orders to comply with the customs, dictates or market vernacular of a particular exchange to be used by the designated fulfilling member e.g., "market held" from a U.S.
  • FIG. 5A is a flow chart illustrating how both originating members and fulfilling members can view relevant information (information specific to the member) on their respective end terminals 400, 402.
  • the end terminals 400, 402 are in this embodiment personal computers located at a site owned by the member.
  • the end terminals 400, 402 are provided with a browser application capable of: displaying pages of order information; generating messages; and generating reports. Originating and fulfilling members establish a connection and log-on to the broker-to-broker processing system 200 in the same way.
  • a physical security token unique to each individual at the originating member's premises such as SecurlD from RSA Dynamics, to identify themselves to the system.
  • This token and operating guide may be delivered to the member using secure courier facilities. Once in possession of the token, all that may be required of the user may be to start up their web browser and navigate to the broker-to-broker URL . If there are software components to be installed the broker-to- broker system will automatically detect that condition and carry out the necessary operations remotely.
  • the member first establishes a connection to the web server 410 of the broker-to-broker processing system 200 from an end terminal 400/402.
  • the member then enters authentication details including a user name, personal identification number PIN, and secure identity number.
  • the authentication details are passed from the web server 410 to the security server 470 via the application server 420.
  • the security server 470 can then process the authentication details (see step 504) . If the member is not authorized to use the system or has provided incorrect authentication details, a "log-in error" message is generated and sent to the member's end terminal (step 506) .
  • the security server accepts the login and the application server 420 references the user control information in the front end database 425 to establish whether the member is an originating member or a fulfilling member and what information is to be displayed on the screen of the member's end terminal (see step 508) .
  • the order manager software 424 of the application server 420 provides the information necessary for the page generator 414 of the web server 410 to display screen information specific to the member at the end terminal 402. This information is then sent to the end terminal for display to the member.
  • the information content of the member's screen is refreshed at predetermined time intervals by the application server 420 referencing the front end database 425 and re-transmitting updated information to the end terminal responsive to a request by the end terminal 400/402.
  • the system is configured such that end terminals request a screen content update at 10 second intervals. However, it will be apparent that other time intervals can be used (see step 512) . It will be apparent that at any given point in time each member sees a screen display having content defined by the relevant records in the front end database 425 as they existed at the time of the last refresh operation.
  • the content itself is defined by the current order status, while the format may be at least partly defined by member preferences.
  • Figures 5B and 5C illustrate how a customer service representative or another authorized supervisor of the system accesses functions of the broker-to-broker system via an end terminal 403.
  • the login procedure for a customer services representative is analogous to that described for a member with reference to steps 500-504 of Figure 5A.
  • the application server 420 accesses the user control information 429 the end terminal 403 of the customer services representative CSR displays an on-screen interface 505 having features for customer service users.
  • the on-screen interface allows the customer services representative access to features of the Front End Administration Tool (FEAT) .
  • On-screen buttons 507 and 517 allow access for application subsystem records of brokerages and authorized individual users to be created, amended and/or deleted.
  • An additional on-screen button 519 allows access to a feature allowing authorized users to supervise members, the shadow login feature.
  • the shadow login feature allows a customer services representative to view on-screen data accessible to a given member substantially as it would appear to the member.
  • a customer service representative who knows which user/member to shadow can click on the "shadow login" button and a prompt screen 523 is generated.
  • the prompt screen 523 contains a drop-down list of brokerages 524 and (empty) fields for user name 525, roles 526 and access permissions 527.
  • the customer service representative selects a brokerage OBLE from the drop-down list 524 (see screen 531) .
  • the user name list 525 is populated with the names of authorized users at the selected brokerage OBLE. Names of authorized users for a given brokerage are held in the user control information 429 of the front end database 425 and can thus be accessed by the application server 420.
  • the user name list is sent to the end terminal 403 via the web server 410.
  • the customer service representative selects the user to be shadowed OBLE0001 from the list as shown on screen 533.
  • the role and function fields pertaining to the selected user are populated automatically responsive to the user name selection (see step 535, Figure 5C) . This leaves a screen display corresponding to that designated by numeral 537 with all of the information fields populated.
  • the customer services representative can then submit the shadow login request to the broker-to-broker system by clicking the enter button 539.
  • the application server 420 references the user control information in the front end database 425 to determine what data would be available to the member being shadowed (see step 540) .
  • the FEAT software on the application server provides the information required by the page generator 414 of the web server 410 to display at the customer services terminal 403 a screen substantially corresponding to that accessible to the member.
  • a representation of originating member data as it would appear on a customer service representative display is designated by reference numeral 543. Data viewed on the customer service representative's screen will correspond precisely to that of the member being shadowed only if the same local filters 544 are applied.
  • the customer services representative can access all of the functional features of the order management interface available to the member being shadowed.
  • the CSR ' s Customer Service Representatives
  • shadow login features of preferred embodiments can be used to regenerate display information of members in any category whether or not they are connected at the same time.
  • the broker-to-broker system is configured such that the end terminal 403 requests a screen update at 10 second intervals. However, any other suitable time period may be used (see step 546) .
  • the order entry frame viewable by originating members enables originating members to enter an order (s) for transmission to a fulfilling member for execution.
  • Items on the order entry frame may include: originating member's investor reference code; transaction type - buy/sell indicator; security identifier; market where security is to be executed; quantity of securities to be executed; price conditions which will govern the execution; timing applicable to the order; duration applicable to the order; identity of the fulfilling member; a requested commission rate (if any) ; designation of the execution venue; payment/receive currency; free form message entry area (viewable by both originating member or fulfilling member) ; intended trade date; intended settlement date; free form text entry area (viewable by originating member only) .
  • originating members can enter: identity of the securities account into/from which securities will be delivered/removed; and identity of the cash account into/from which monies will be delivered/debited; Connected members see an orders list on the left hand side of an order management screen. Clicking on an order in the list brings up further details of the order and enables predefined actions to be taken.
  • An originating member can use his end terminal 400, for example, to:
  • brokers-to-broker system central electronic information library notes, pricing models/tolls/guidelines, audio clips, video clips, to broker-to-broker system central electronic information library; • search the electronic information library and download material; • interrogate their billing account with broker-to-broker system to obtain information such as: transaction fees outstanding to broker-to-broker system, customers' membership fees outstanding, rebates applicable, fee structure agreed with broker-to-broker system, average trader per day (TPD) for week, month, quarter; • send messages directly to other broker-to- broker system customer (s) using the secure, guaranteed network facilities; • send messages directly to the customer support system; • search the data repository for securities information; • search the data repository for member information; • obtain information about their use of broker-to-broker system's facilities such as: transaction history (by: time period, security, market, exchange, sector, geographical region) , execution quality statistics, volume weighted average price (VWAP) , i.e. the price taking into account the size of the transactions executed) , delta from
  • FIG. 6 is a flow chart illustrating how an order may be placed by a member functioning as an originating member.
  • the originating member OM enters, on his/her terminal 400, a security identifier (SID) to identify the security he/she wishes to buy or sell. If desired an originating member not wishing to use the default security classification scheme (local) can select a different classification scheme from a dro -down menu.
  • the originating member clicks the "order" button displayed at his/her terminal.
  • the market field is a view-only field, i.e. the user cannot type into this field.
  • An originating member's graphical user interface will only allow securities to be entered in those markets where the broker-to-broker system has signed up fulfilling members as customers since these are clearly the only markets where the order can be transmitted to.
  • a security identifier, SID along with the market reference code, uniquely identifies the security which the originating member wants to transact.
  • the choice of numbering agency for the SID can be the choice of the originating member. It cannot be sufficiently stressed how easy (ergonomic/user-friendly) determining/looking-up SIDs is using the front end software.
  • the broker-to-broker system will support the following SIDs /numbering agencies: CUSIP (Corp.
  • a message indicating which security is to be bought or sold is sent from the originating member to the order management system server 430 via the web server 410 and the application server 420.
  • the order management server 430 then accesses the settlement management system database 445 via the OMS database 435 and the database link 452 (see step 606) .
  • the results of the access are passed from the order management server 430 to the application server 420.
  • securities are listed on multiple exchanges in multiple jurisdictions.
  • the security listed is not a different security, i.e. possession of that security wherever purchased confers the same rights on the holder.
  • Securities such as American Depository Receipts (ADRs) , and Global Depository Receipts (GDRs) are different securities from the underlying and while they may be converted back to the original are still for the purposes of reporting etc, different, distinct securities in their own right.
  • An example of multiple listing is Reuters stock which is listed on other exchanges along with its primary listing on the London Stock Exchange. In these cases the security normally has the same ISIN. If the application server 420 cannot uniquely identify the security to be traded based on the results of the database query, a message is sent from the application server 420 to the end terminal 400 containing information on the choices of markets for trading the securities.
  • the end terminal 400 displays a choice of markets for the security intended to be traded by the originating member on the screen of the end terminal 400 (see step 608) .
  • the originating member selects from the choice of markets for trading the security by clicking the screen.
  • the originating member chooses the market he/she wishes to enter the security order on. This will set the market.
  • the requirement for the market to be set is that the broker-to-broker system needs to know to which market the order is being transmitted so that the correct validation checks may be applied, and so that the appropriate conventions and language translations may take place.
  • the order process can then continue as it would have done had the application server been able to uniquely identify the security at step 606 (see below) . If the application server 420 can uniquely identify the security selected by the originating member, the originating member is prompted on screen to input particulars of his/her order (see step 612) . At step 614, the originating member defines the order by entering specific details of the desired order. Originating members enter information concerning the proposed transaction.
  • the information includes: the number of securities; whether the order is for a purchase or sale - a buy/sell indicator; valid price conditions for the specific market and security; valid duration and timing of the order; a suggested trade date for the transaction; a suggested settlement date for the transaction; a valid designated fulfilling member; a desired execution venue; the originating member account details for settlement; a requested commission rate (if any) ; and valid authenticated identity of the issuing person at the originating member.
  • the originating member may need to keep track of orders entered so that he/she can relate them back to an order (s) which he/she may have been given by a customer. To this end an investor reference code is entered against an order.
  • this investor reference code may very well be the same as a customer account. However larger operations may have computer systems.
  • the originating member may enter an alphanumeric string which is their reference code for the order.
  • the client reference code should be used as the reference code.
  • the broker-to-broker system need not in any way interpret/alter this client reference code. The presence or otherwise of this reference code shall have no bearing on how the broker-to-broker system processes the order or its resulting fills. Note also that while this reference code will be electronically attached to the order and all resulting transactions relating to the order, only the originating member will ever view the reference code.
  • This code is not viewable by the fulfilling member.
  • the broker-to-broker system Customer Support personnel will view the reference code as a field of asterisks, i.e.**********. Even within the broker-to-broker systems it is recommended that this field be rendered non-easily readable to prevent accidental disclosure to the broker-to-broker system technical personnel. This approach helps to ensure that the confidentiality of the investor's details is maintained. The parties involved in the transaction may need to unequivocally identify an order. To this end, the system will generate a unique order reference number which is viewable by all parties, including the customer support desk.
  • This reference code field enables the originating member to put code(s) into his/her own systems so that he/she can reconcile the order and its resulting executions with his/her own systems.
  • This further reference code can be quoted to all parties to the order to unequivocally identify the order in question. For example when the originating member and the fulfilling member are discussing the order, or either party request help from the Customer Support desk, this reference code may allow all parties to rapidly identify the order in question leading to quicker resolution of the problem.
  • This reference code may be visible in human readable form to all parties on the broker-to-broker system.
  • the quantity item allows the user to specify the number of securities to be bought or sold. Short forms to speed up entry and minimize errors are provided on the OMIF, e.g.
  • the Buy/Sell indicator specifies the intended direction of the transaction, i.e. whether the order is for a security is to be bought or sold.
  • the indicator represents the direction from the perspective of the originating member, i.e. if the originating member has an order to obtain securities for his/her customer, then the indicator will show BUY. Conversely if the originating member has an order to dispose of securities on behalf of his/her customer, then the buy/sell indicator will show SELL.
  • the price conditions item allows originating members to specify the price conditions which he/she is prepared to accept when the fulfilling member executes the transaction.
  • the classic price conditions are: sell limit price - i.e. the lowest price that the originating member is prepared to accept in exchange for disposing of his/her securities; buy limit price - i.e. the highest price that the originating member is prepared to pay in exchange for obtaining the securities; sell at market - i.e. the originating member is prepared to receive whatever is the highest current prevailing price in the market; buy at market - i.e. the originating member is prepared to pay whatever is the lowest current prevailing price in the market.
  • Other items comprised in the order entry frame as viewed from an originating member's end terminal 400 include: timing applicable to the order; duration applicable to the order; identity of the designated fulfilling member; the commission rate which the fulfilling member will charge to the originating member for executing the order; designation of the execution venue; preformatted instructions to the fulfilling member indicating how the order should be traded; free format message area to the fulfilling member; free format message area viewable by the originating member only; trade date; settlement date; capacity the originating member is acting in (agency/principal) ; payment/receive currency.
  • the system enables the originating member to select among the universe of fulfilling members available for a given security or market.
  • the system need not select a fulfilling member on behalf of the originating member, or change the identity of the originating member's selected fulfilling member on an order.
  • an originating member selects a fulfilling member that does not have the capability to trade a particular security or on the particular market in the originating member's order
  • the originating member chooses a fulfilling member appropriate for that security or market before the order can be further processed.
  • the normal commission rate of the designated fulfilling broker is displayed to the originating member. In this embodiment, the normal commission rate is displayed adjacent to the fulfilling broker 1 ' identity code once the fulfilling member has been selected. If desired, the originating member can enter a different commission rate into the "requested commission" rate field of the order entry frame.
  • the originating member After entering the order details the originating member is prompted to confirm they are correct (see step 614 of Figure 6) . If all required information is properly provided, the order is then sent via the broker-to-broker system for verification and for delivery to the fulfilling member. If an originating member wishes to enter an order having details in common with a previous order, he/she copy order details from a record of the previous order. [This is achieved technically by the user clicking the "copy order" button which causes the application server 420 to retrieve the details of the selected order and pass them to the webserver 410 which places this data into a new order entry frame which is sent to the user who clicked the "cop order" button. The originating member selects the previous order from the order list displayed on his/her screen to view the order details panel.
  • the order management system server 430 can transfer the order information stored in the OMS database 435 to the front end database 425 via the order publishing software 434 and the order storage software 423 of the application server 420.
  • details of the originating member's order are stored in the front end database 525 connected to the application server 420.
  • the conversion service options available to originating members 204 include: retrieval from data storage and inclusion in the message of appropriate additional securities identification numbers (e.g., the broker-to-broker processing system 200 will be able to provide the applicable ISIN number when given a particular CUSIP number for securities identified for trading in multiple jurisdictions) ; the reformatting of orders to comply with the customs, dictates or market vernacular of a particular exchange to be used by the designated fulfilling member (e.g. "market held" from a U.S.
  • appropriate additional securities identification numbers e.g., the broker-to-broker processing system 200 will be able to provide the applicable ISIN number when given a particular CUSIP number for securities identified for trading in multiple jurisdictions
  • the reformatting of orders to comply with the customs, dictates or market vernacular of a particular exchange to be used by the designated fulfilling member e.g. "market held" from a U.S.
  • broker would be converted to "best,” the equivalent expression used by broker-dealers in Great Britain); language translation (e.g., English to French) of essential transaction terms (e.g., "buy” or "sell") and the generation and inclusion by the processing system of additional information requested by an originating member 204 that is not an element of a proposed transaction, but offers convenience to the parties, such as display of indicative-only currency conversion data.
  • the processing system 200 also offers members an option to include messages which are not be subject to any modification ("free form” messages) .
  • each originating member, and each authorized person acting on behalf of a member can choose and set the numbering agency which they wish to use to identify securities on their orders.
  • the broker-to-broker system will translate the entered SID into the SID required by the fulfilling broker (and vice versa) and other parties to the transaction.
  • securities will be identified by the broker- to-broker system financial instrument identifier (FID) .
  • the broker-to-broker system FID is a unique code generated by the broker-to-broker system's data repositories which takes into account for example multiple listings of the same security, (one of the reasons the broker-to-broker system cannot use ISIN internally) .
  • the SID entry field allows the originating member to look-up the SID code using the security's text name, or part thereof, e.g.
  • an instruction is sent to the order management server to search the SMS database security database and display a list of securities whose full name starts with British. The user then selects the required security.
  • the front end software will remember at least the last 100 SIDs submitted by an originating member, and present that list, together with the text name of the SIDs, to the user on a drop-down list for selection.
  • An originating member can cancel an order placed on the broker-to-broker network at any time before the order is accepted by a fulfilling member. The originating member can select the order to be cancelled from the order list and click on a cancel tab on the order information panel.
  • the originating member will be prompted to confirm the cancellation details before a cancellation message is sent to the order management server 430 via the web-server 410 and the application server 420.
  • An indication that the order has been cancelled is stored in the OMS database 435 and the cancelled status is recorded in the front end database 425.
  • the fulfilling member's screen is updated the order list will indicate the cancelled status of the order.
  • the order list of the issuing member will indicate a new status for the order .
  • Originating members can submit a request to modify an accepted order (i.e. orders with "pending fill”, “partially filled” and “fully filled” status) .
  • the originating member selects the order to be modified from the order list and clicks on a modify tab.
  • the broker-to-broker system generates a modification entry screen and depending on the status of the order the following details can be amended: quantity, price, venue, instructions, trade date, settlement date and commission rate.
  • the requesting member is prompted to confirm the details of the modified order.
  • the fulfilling member can: • receive and accept orders from originating members for fulfillment; • request to cancel his/her orders; • request to modify attributes of his/her orders; • respond to requests to cancel initiated by the originating member; • respond to requests to modify initiated by the originating member; • request to sign off his/her orders (i.e.
  • Figure 7 illustrates how a fulfilling member becomes aware of orders placed with him and may accept or reject them.
  • a fulfilling member may become aware of new orders placed with him when he establishes a connection to the broker-to-broker system 200 or when the screen content of the end terminal 402 is refreshed in a period after new order particulars have been transferred to the front end database 425.
  • the fulfilling member sees all new orders along with all pending orders on an orders list on the left-hand side of his screen.
  • the fulfilling member can select one and view the order particulars in detail.
  • the fulfilling member elects to view the particulars of a new order placed with him, the fulfilling member will click on the order within the order list whereby the application server 420 references the front end database 425 and the order manager software 424 supplies details of the order to the end terminal 402 via the page generator 414 in the web server 410. Fields presented on this screen are read-only except where otherwise noted.
  • the order acceptance frame enables the fulfilling member to accept an order (s) for fulfillment.
  • Items on the order acceptance frame may include: means for the fulfilling member to accept or reject the order; originating member's order reference code; transaction type - buy/sell indicator; security name; security identifier; market where security is to be executed; quantity of securities to be executed; price conditions which will govern the execution; designation of the execution venue; payment/receive currency; trade date; settlement date; and commission rate; capacity (i.e. agency or principal) ; originating member; and free form message area.
  • Another fields allow the fulfilling member to provide the identity of the securities account into/from which securities will be delivered/removed; and identity of the cash account into/from which the monies will be delivered/debited;
  • an alert mechanism visual and audible, prompts the fulfilling member that there is an order to be dealt with. Failure to respond to the alert within a pre-determined time-period may cause the order to be automatically cancelled and the originating member so notified.
  • This time-period for acknowledgement is configurable on the following basis: system wide; per market; per fulfilling member.
  • Electronic acknowledgement of the order allows the broker-to-broker system 200 to send a positive indication back to the originating member that the order has been delivered to the designated fulfilling member and is being considered for acceptance.
  • This order acknowledgement does NOT mean that the fulfilling member has agreed to fulfil the order, i.e. no contract has yet been formed between the originating member and the fulfilling member.
  • details of the order are placed onto the FMIF pending orders manager screen.
  • the order having been acknowledged all parties now "know” that the order has been seen by the fulfilling member and could be fulfilled.
  • the fulfilling member now has to accept, reject, or request modification to the order within a configurable time-period. This acceptance time- period is configurable on the following basis: system wide; per market; per fulfilling broker.
  • the Buy/Sell indicator specifies the intended direction of the transaction to the fulfilling member.
  • the Security Identifier, SID along with the market reference code, uniquely identifies the security which the fulfilling member is to transact on behalf of the originating member.
  • Automatic reformatting and conversion/translation functions of the broker-to-broker function may mean that the content of certain fields viewed by the fulfilling member is different to that input by the originating member.
  • the format and content type of the subject matter viewed at an end terminal is selected/configured by the member who uses the end terminal. For example in the case of a fulfilling member, the choice of numbering agency for the SID is primarily the choice of the fulfilling member.
  • the broker-to-broker processing system will map the originating member's SID into the form required by the fulfilling member.
  • the broker-to- broker system will support the following SIDs /numbering agencies: CUSIP, ISIN, SEDOL, LOCAL (Local Exchange Identifier) and full company name.
  • SIDs /numbering agencies CUSIP, ISIN, SEDOL, LOCAL (Local Exchange Identifier) and full company name.
  • Each fulfilling member, and each authorized person at the fulfilling member's premises, can choose and set the numbering agency which they wish to use to identify securities on the orders which they receive.
  • the broker-to-broker system will, if required, convert the originating member's SID into the SID required by the fulfilling member and other parties to the transaction. Internally, i.e. within the broker-to-broker system, securities will be identified by the broker-to-broker system FID.
  • the broker-to-broker system FID is a unique code generated by the broker-to-broker system 's data repository which takes into account for example multiple listings of the same security.
  • a security to be transacted by a fulfilling member is uniquely identified by means of the security identifier SID and the market.
  • the quantity item specifies the number of securities to be bought or sold by the fulfilling member. Where lot sizing and/or minimum order sizing applies, the FMIF front end software expresses the quantity as an absolute quantity and as a number of lots to sell/buy.
  • the price conditions item indicates the price conditions the originating member is prepared to accept when the fulfilling member executes the transaction. Examples of price conditions are: sell limit price - i.e.
  • the lowest price that the originating member is prepared to accept in exchange for disposing of his/her securities buy limit price - i.e. the highest price that the originating member is prepared to pay in exchange for obtaining the securities; sell at market - i.e. the originating member is prepared to receive whatever is the highest current prevailing price in the market; buy at market - i.e. the originating member is prepared to pay whatever is the lowest current prevailing price in the market.
  • Other items accessible to the fulfilling broker include: the commission rate which the firm will charge to the originating member for executing the order; designation of the execution venue; preformatted instructions from the originating member indicating how the order should be traded; free format message area from the originating member; identity of the originating member who routed the order; trade date; settlement date; capacity the originating member is acting in; gross consideration; payment/receive currency; transaction management; intra member messaging; interface to the broker-to-broker system electronic library.
  • the fulfilling member reviews the information for completeness and accuracy. If the need arises he can contact the originating member via a communication means of the broker-to-broker system. The fulfilling member can then determine in its sole discretion whether to accept or reject the order.
  • the fulfilling member is presented with on-screen buttons inviting him/her to accept or reject the order (see step 702) .
  • a fulfilling member rejects an order the originating member is sent an order reject message together with an indication of the reason for the rejection. That is, the fulfilling member is prompted to indicate a reason for rejecting the order and an order reject message including the reason is sent from the end terminal 402 to the order management system server 430 via the web server 410 and the application server 420 (see step 704 of Figure 7) .
  • the order record in the OMS database 435 is accessed to add an indication that the order has been rejected.
  • Step 708 An indication that the order has been rejected is then replicated to the front end database 425 via the order publisher software 434 and the order storage software 423 of the order management system server 430 and the application server 420, respectively (see step 708) .
  • the status of the order within the broker-to-broker system is thus changed to "rejected".
  • Step 710 illustrates that the originating member's screen content is changed to indicate "order rejected” instead of "order placed” next time the screen content is updated.
  • the contract is governed by the terms of the order, as specified in the fields of the order, the terms of the fulfilling members agreements with the broker-to-broker system, and is subject to the regulations of the fulfilling member's jurisdiction, e.g. the member agrees to the desired quantity, price conditions, delivery conditions and execution venue specified by the originating member.
  • an order acceptance message is sent from the end terminal 402 to the order management system server 430 (see step 712) .
  • the order processor 436 of the order management system server 430 updates the relevant order record in the OMS database 435 to indicate acceptance of the order by the fulfilling member (see step 714) .
  • An indication that the order has been accepted is then transferred from the OMS database 435 to the front end database 425 by means of the order publishing software 434 and the order storage software 423 (see step 716) .
  • the screen content of the originating member (or the fulfilling member) terminal is updated by one of the periodic references to the front end database 425, the display of the end terminal 400 (or 402) will indicate an "order pending fill" status to indicate acceptance (718) .
  • the fulfilling member will seek to execute the order according to the terms specified. No item on the order may now be altered without requesting the fulfilling member to positively accept the changes requested. In the case that the order is accepted, the fulfilling member seeks to execute the order on the specified market satisfying the terms of the order.
  • the fulfilling member and the originating member can communicate through the broker-to-broker system or through any other means they may choose as to the status of fulfillment of the order and any modifications thereto.
  • information concerning the transaction is sent to the originating member for review.
  • the agreed transaction can then be submitted by both members to the settlement management portion of the system which then generates settlement instructions, based entirely on transaction details, settlement account and preference information previously provided by members, for transmission to the settlement agents designated exclusively by the respective members.
  • Figure 8 is a flow chart illustrating how the originating member is made aware that the fulfilling member has executed an order placed with him. Referring to the step designated 800, the fulfilling member selects the order he has executed or partially executed from the list displayed on the screen of end terminal 402.
  • the application server 420 references the front end database 425 and content relevant to the order selected is supplied to the end terminal 402 via the web server 410 (see step 802) .
  • the fulfilling member can then enter execution data by clicking a fill button on the order information panel (see step 804) .
  • execution data entered by the fulfilling member includes quantity, (fill) price and optionally, date and time of execution.
  • the execution data supplied by the fulfilling member are sent to the order management system server 430 and are recorded by the order processor 436 in the OMS database 435 (see step 808) .
  • the fulfilling member is prompted to confirm the execution details.
  • the execution data are subsequently transferred to the relevant record in the front end database 425 via the order publishing software 434 and the order storage software 423 (see step 810) .
  • the "executed" status of the order is then indicated on the displays of both the originating member and the fulfilling member end terminals next time the screen content is refreshed. It will be apparent that a fulfilling member may perform a single execution or multiple smaller fills against an order. In the case of multiple smaller fills the order appears as partially executed until the total order quantity has been filled. If the order has been fully executed by the fulfilling member, either the originating member or the fulfilling member may initiate a settlement procedure (see step 810) . If on the other hand the order has been partially executed by the fulfilling member, the fulfilling member can execute the remainder later.
  • FIG. 9 is a flow chart illustrating how settlement instructions are generated and issued by the broker-to-broker computer system. Either party can request sign-off to initiate the settlement procedure, however in this example the procedure is initiated by the fulfilling member. Requests for sign-off can be submitted for any filled or partially filled orders. Referring to step 900, the fulfilling member selects the executed order for which he wishes to initiate settlement proceedings by clicking on it.
  • the order information panel on the fulfilling member's screen prompts him/her to "request sign-off" (see step 902) .
  • a fulfilling member has reviewed order details he/she can select the request sign-off button.
  • the fulfilling member is prompted to enter settlement information, including data identifying the settlement account of the fulfilling member and, optionally, adjusted average fill price (see step 904) .
  • the settlement information provided by the fulfilling member is sent from the end terminal 402 to the order management system server 430 from where it is provided to the settlement management system server 440.
  • the order management system server 430 transfers the fulfilling member's settlement information to the SMS database 445 via the OMS database 435 and the database link 452.
  • the OMS server 430 makes a database stored procedure call into the SMS database 445 passing in the details of the relevant trade, responsive to which the OMS server 430 is provided with the calculated commissions, and any local market charges, taxes or levies (see step 908) .
  • final transaction criteria including the calculated settlement criteria are sent directly to the fulfilling member terminal 402 where the fulfilling member can review them and either accept or reject them. If the fulfilling member accepts the settlement criteria, a message containing the accepted settlement particulars is sent to the order management system server 430 which generates a message changing the status at the order management system server 430.
  • Certain particulars, e.g. average prices and security settlement account information is stored in the OMS database 435.
  • the settlement information is sent to the order management system server 430 for processing based, for example, on for example average price information provided by the fulfilling member (see step 916) .
  • the order management system server accesses the SMS database 445 by means of a stored procedure call passing the trade details into the SMS database 445.
  • calculated settlement criteria relating to the originating member are supplied from the SMS database to the OMS database 435 via the database link 452 (see step 918) .
  • the order' management system server 430 transfers final transaction criteria including the calculated settlement criteria to the end terminal 400 where the originating member can review and either accept or reject them (see step 920) .
  • the settlement criteria are accepted by the originating member, a message containing the accepted particulars is sent from the end terminal 400 back to the order management system server 430 and the accepted particulars are stored in the OMS database 435 (see step 922) .
  • the front end database 425 is updated by means of the order publisher software 434 and the order storage software 423 in the usual way, after which update the screen content can reflect the new status of "signed off" .
  • the final transaction criteria presented to the parties includes the following particulars: executed quantity; average price; calculated average price; security account; indication of net proceeds; commission rate; commission; client ID/broker ID; trade date; settlement date; and settlement currency.
  • the calculated average price is the average price as calculated by the processing system based on the actual executed quantity and price.
  • the order management server creates two trade records (see step 924) .
  • a "signed-off" status means that both parties have agreed that all required actions have been performed against an order and no further activity is necessary.
  • One trade record corresponds to a buy transaction and is associated with the appropriate one of the originating or fulfilling members.
  • the other trade record corresponds to a sell transaction and is associated with the other one of the originating or fulfilling members.
  • the two trade records are stored in the SMS database 445 via the OMS database 435 and the database link 452.
  • the settlement management server 440 polls the SMS database 445 at predetermined intervals to find trade records which require processing. Having detected the trade records the SMS server 440 validates certain order attributes (e.g. security, market, market listing, trade date, price, settlement date, broker identities, commission rates and default charges) against static data held in the SMS database 445. The initiation of the settlement procedures is undertaken by the generation of agent instructions during the trade verification process. Referring to step 926, the trade processor 442 of the settlement management server 440 processes the settlement management information of that transaction to generate settlement instructions (see step 926) . In this way, generic trade instructions are generated and associated with a given medium that identifies how the message will be sent to the clearing agent.
  • certain order attributes e.g. security, market, market listing, trade date, price, settlement date, broker identities, commission rates and default charges
  • the settlement management sub- system thus derives the company's stock and cash settlement agent and the client's stock and cash settlement in order to ascertain whether the trade will be settled either against or free of payment .
  • Settlement instructions can be established and varied for a wide range of criteria such as particular markets, instrument types, individual stocks, and currencies.
  • a first settlement instruction message is sent to the settlement agent designated by the originating member and a second settlement instruction message is sent to the settlement agent designated by the fulfilling member.
  • the settlement instructions may be transmitted to settlement agents in, for example, SWIFT format messages 443 or by fax message 444.
  • criteria and criteria acceptance messages may also be routed between the originating member, the fulfilling member via indirect routes.
  • the fulfilling member's indication of acceptance may instead be sent directly to the originating member along with criteria for acceptance by him/her. Both indications of acceptance can then be returned to the processing system together.
  • the terms "to originating member/fulfilling member” and "from originating member/fulfilling member” should be construed accordingly.
  • appropriate settlement instructions are generated automatically by the settlement management part 440,445 of the broker-to-broker processing system 200 for all parties to the trade and sent to the relevant settlement agents.
  • Settlement instructions relating to agreed settlement particulars are issued from a single source and at an appropriate point in time.
  • settlement instructions are issued to the settlement agent of the originating member and the settlement agent of the fulfilling member at the same time .
  • Tables A and B summarize the different types of
  • the originating member may accept or reject the request .
  • the originating member may accept or reject this request.
  • Sign-off Indicates that the fulfilling Flag Request member has entered a request to signoff an order.
  • the originating member may accept or reject this request.
  • the originating member may accept or reject the request.
  • Rejected Indicates that an order placed High by an originating member has been rejected by the fulfilling member.
  • Placed Indicates that an order has been High placed by the originating member, but the fulfilling member has not yet accepted or rejected the order .
  • Modification Indicates that a request to High Rejected modify an order has been rejected by the fulfilling member.
  • Sign-off Indicates that a request to Medium Pending sign-off an order has been entered but not yet accepted or rejected by the fulfilling member.
  • Pending Fill Indicates that an order placed Low by an originating member has been accepted by a fulfilling member, but no fills have yet been entered.
  • New Order Indicates that a new order has Flag been placed by the originating member, which has not yet been accepted or rejected by the fulfilling member.
  • the fulfilling member may accept or reject the request .
  • the fulfilling member may accept or reject this request.
  • Sign-off Indicates that the originating Flag Request member has entered a request to sign-off an order.
  • the fulfilling member may accept or reject this request .
  • Modification Indicates that a request to High Rejected modify an order has been rejected by the originating member .
  • Sign-off Indicates that a request to High Rejected sign-off an order has been rejected by the originating member .
  • Cancel Fill Indicates that a request to High Rejected cancel a fill has been rejected by the originating member.
  • Cancel Indicates that a request to Medium Pending cancel an order has been entered but not yet accepted or rejected by the originating member.
  • Cancel Fill Indicates that a request to Medium Pending cancel a fill has been entered but not yet accepted or rejected by the originating member.
  • Pending Fill Indicates that an order placed Low by an originating member has been accepted by a fulfilling member, but no fills have yet been entered.
  • Rejected Indicates that an order placed Done by an originating member has been rejected by the fulfilling member.
  • Tables A and B illustrate order priorities for originating and fulfilling members respectively.
  • newly received orders and orders with new opposite member requests against them are flagged and are placed at the top of the order list.
  • These flagged orders are categorized as being of very high importance. No actions can take place in relation to these flagged orders until the request has been accepted or rejected by the viewing member unless the request is withdrawn by the requesting member.
  • Directly below flagged orders are newly placed orders and those orders in respect of which a request has been rejected.
  • Orders against which requests are pending are regarded as medium priority and appear below the orders of high importance. Appearing immediately below orders against which requests are pending are orders which are pending fill entries or are partially filled. These orders are categorized as low priority. Completed (signed-off) cancelled or rejected orders are placed at the bottom of the order list with the lowest priority. Orders appearing in the on-screen order lists 509 can be sorted based on any of the order information fields, e.g. trade date, direction of trade, quantity, security, country, price or client identity. The sorting criteria is passed to the web and application servers when a screen refresh is requested by the user terminal .
  • This criteria is used by a Java based sorting algorithm on the web server 410 to sort the data which is then returned to the user terminal.
  • numeric data is sorted in descending order (high to low) and alphabetic data is sorted in ascending order (A to Z) .
  • a further advantageous feature of the disclosed embodiment is an order list filter feature. That is, orders appearing in the order list 509 can be filtered such that only one or more selected categories of orders appear in the list.
  • the order list as viewed by the originating member, the fulfilling member and/or customer service representatives can be filtered based on order status, country, security, customer identity.
  • the filtering criteria is passed to the application server when a screen refresh is requested by the user terminal.
  • This criteria is used by the order and query software 422 to retrieve the matching information from the orders within the front end database 425.
  • the required filter criteria in any filter field can be selected from drop-down menus and applied immediately.
  • the list of filter criteria appearing in the drop-down menu of the respective filter fields are adjusted dynamically based on the current order list contents. That is, the filter criteria which are listed for selection by the user depend upon the complete order list accessible to that user.
  • the filter criteria available at an end terminal may differ from user to user.
  • the filter criteria available to a given user may change as the order list is updated.
  • Market information including normal opening times, identifier codes, location, special closing times, regulatory authorities and associated brokers, is extracted from the SMS database 445 and displayed to the user. Users may also view information on a selected security by selecting a classification scheme and entering a security identifier in a search field. Users are provided with the following information on the selected security: closing price; currency traded in; default market; country of registration; local ID; ISIN; SEDOL and CUSIP.
  • This embodiment can generate three types of reports automatically. The user clicks on a generate report button and selects either a "summary report", or a "detail report” or a "settlement report”. Having chosen the type of report to be generated, the user is prompted to provide report criteria to define the contents of the report.
  • the type of report selected will determine which report criteria are displayed and which can be selected for inclusion by the user.
  • the prompt screen for a summary report includes entry fields for date (or date range) , order status types to be included in the report, broker identity, order number, client identity, country and a sort by field.
  • the "sort by" fields can be used to customize the order of entries appearing in the report .
  • After the step of generating a report it can be printed at the convenience of the user.
  • the messaging facility accessible via the message tab above the order list allows members to communicate directly through the broker-to-broker system by means of electronic messages. For example, users of the email messaging system can view an in-tray containing inbound messages and a sent items list.
  • the originating member interface OMIF 202 includes an application program interface, referred to herein as BIAPI, designed to allow the broker-to-broker members to interface their systems directly into broker-to-broker system 200 eliminating and minimizing the need to key data into order entry screens, and keying data about fills, positions etc into their systems.
  • BIAPI application program interface
  • BIAPI-F The file based API, BIAPI-F, is designed to enable the widest, simplest and quickest system interconnect possibilities, whilst the interactive API, BIAPI -I, is designed to enable hi-performance, functionally rich system interconnects to be created.
  • BIAPI-F consists of text files containing comma separated, quoted tag and value records terminated by an end-of-line character. These files may be read or put from/into the file- space of the terminal 400 client, e.g.
  • BIAPI -I may be implemented as a component, which exposes methods that are then invoked by the host program.
  • BIAPI-F The functionality provided through either BIAPI-F, or BIAPI-I, will include: send orders for execution; receive fill/execution notification; receive order status; receive settled position (s) and balance (s) information; receive open positions (s) and balance (s) information; receive their account information, i.e. electronic billing from the broker-to-broker system; send settlement account (s) information to the broker-to-broker system; receive transaction history information.
  • BIAPI-I the originating members are able to carry out all of the functions available through BIAPI-F, and the following additional set of functionality: session control; log on/off; manage transactions; request cancellation; request modification; request sign-off; accept/reject cancellation requests; accept/reject modification requests; accept/reject sign-off requests; withdraw an initiated request; query the interface for order status; security lookup; request for quote; request reports/data with filter specifications; transaction history; open position (s) and balance (s) information; settled positions (s) and balance (s) information; their account information, i.e. electronic billing from the broker-to-broker system.
  • session control log on/off; manage transactions; request cancellation; request modification; request sign-off; accept/reject cancellation requests; accept/reject modification requests; accept/reject sign-off requests; withdraw an initiated request; query the interface for order status; security lookup; request for quote; request reports/data with filter specifications; transaction history; open position (s) and balance (s) information; settled positions (s) and balance
  • the API of the FMIF 206 is designed to allow the broker-to-broker system's customers to interface their systems directly into the broker-to-broker system eliminating and minimizing the need to key in order data and keying data about fills, positions etc. into the fulfilling member's trading systems.
  • SELAPI-F is designed to enable the widest, simplest and quickest system interconnect possibilities, whilst the interactive API, SELAPI -I, is designed to enable hi-performance, functionally rich system interconnects to be created .
  • PXTYPE LIMIT
  • LIMIT 10.5"
  • PAYCUR EUR
  • SELAPI -I comprises a component, which exposes methods that are then invoked by the host program.
  • SELAPI-F The functionality provided through either SELAPI-F, or SELAPI- I, will include: receive orders for execution; transmit fill/execution notification; receive settled position (s) and balance (s) information; receive open positions (s) and balance (s) information; receive their account information, i.e. electronic billing from the broker-to-broker system; send settlement account (s) information to the broker-to-broker system; receive transaction history information.
  • the fulfilling members are able to carry out all of the functions available through SELAPI-F, and the following additional set of functionality: session control; log on/off; manage transactions; request cancellation; request modification; request sign off; accept/reject cancel requests; accept/reject modification requests; accept/rejection sign off requests; withdraw an initiated request; request cancellation of fills; query the interface for order status; security lookup; respond to quote requests; request reports/data with filter specifications; transaction history; open position (s) and balance (s) information; settled positions (s) and balance (s) information; and their account information, i.e. electronic billing from the broker-to-broker system.
  • session control log on/off; manage transactions; request cancellation; request modification; request sign off; accept/reject cancel requests; accept/reject modification requests; accept/rejection sign off requests; withdraw an initiated request; request cancellation of fills; query the interface for order status; security lookup; respond to quote requests; request reports/data with filter specifications; transaction history; open position (s) and balance (s) information; settled positions (s
  • the broker-to-broker network and interfaces adhere to as many standards as possible for the following reasons: lower overall cost due to economics of mass-market production and sales; standards based technologies tend to have fewer problems/bugs, i.e. more dependable; easier to resource personnel; leverage of existing technology intellectual property; ability to stay current with and leverage technological changes; and ease of interfacing to other systems both internally and externally to the broker-to-broker network.
  • the standards chosen by the broker-to-broker system are as follows: Microsoft Internet Explorer - for Web browsers HTML 4, DHTML, SSL, JavaScript - for Web front- end programming Apache Tomcat - for Web servers BEA Systems WebLogic - for application servers C/C++, Java, Perl - for application processing engines UNIX - SOLARIS, HP/UX, LINUX - for application processing engines Windows NT - for in-house desktop technology ORACLE RDBMS - for databases SUN Microsystems, COMPAQ - for application hardware COMPAQ - for in-house desktop hardware STRATUS - for non-stop 100% dependability hardware TCP/IP - for base level networking protocols SWIFT - for payment instruction protocol FIX - for order management protocol Microsoft Office - for document creation Adobe Acrobat - for document distribution RSA Dynamics SecurlD - for authentication controls The broker-to-broker system transaction rules, legalities and processes.
  • the broker-to-broker processing system 200 includes the following characteristics: The processing system 200 does not change the sequencing of orders received from the originating member 204. There is no prioritizing of orders from any given originating member 204, nor any prioritizing of orders among originating member 204. The processing system does not generally change the sequencing of fulfillment advisories transmitted from a fulfilling member 208 back to an originating member 204. The processing system 200 enables the originating member 204 to select from a plurality of fulfilling members 208 available for a given security or market.
  • the processing system 200 does not in this example select a fulfilling member 208 on behalf of the originating member 204, or change the identity of the originating member's 204 selected fulfilling member 208 against an order.
  • the originating member 204 may be required to choose a fulfilling member 208 appropriate for that security or market before the order can be further processed by the processing system 200.
  • Originating member's 204 may be able to direct and monitor the nature of the fulfillment of their orders through various-mechanisms , initially including at least the following:
  • the originating member 204 may be able to designate and set as a default the execution venue which the fulfilling member 208 may be required to use when fulfilling the order, for example, on an exchange, off-exchange or a crossing system, for a particular security or member.
  • every executed trade reported by the fulfilling member 208 will be time stamped and marked with the best official bid and offer positioned in that market, to enable originating members 204 to compare the execution quality received against market pricing.
  • the processing system 200 may be able to generate reports of transactions conducted using the broker-to-broker system to help brokers comply with their regulatory reporting obligations.
  • Settlement of a trade between the originating member and its investor, or between the fulfilling member and the street, can be completely within the province of the member.
  • the system need not generate settlement instructions, confirmations or other forms of advisories or messages to either member's investors or counter-parties. All transactions that are initiated by communications made through the system may be executed by the members to the transaction in a market and in a manner in which they are qualified to conduct such business.
  • the system is a facility through which information relating to securities orders may be transmitted.
  • the conversion service features of the system may provide opportunities for increased efficiency of cross-border and inter-market transactions and thus contribute to broader access to securities markets worldwide, in particular because the system may offer those capabilities at lower variable costs to members who have previously been less able to fully take advantage of advanced technologies to overcome the costs and other burdens arising from the numerous additional variables associated with international securities transactions. Accordingly, the use of the system by members may further increase the transparency of international securities markets and afford to investors through their brokers increased liquidity and efficiency in conducting securities transactions.
  • a flat annual fee may be charged to originating members and, only after a certain number of transactions, an excess usage fee may be charged to originating and fulfilling members whose use of the system results in the generation of a high volume of settlement instructions. The excess usage fee is not dependent upon the completion of any securities transaction.
  • the settlement service is cost-effective and more error- free given the symmetry of data entered onto the system by the brokers conducting a transaction.
  • the excess usage fee is intended to fairly compensate the broker-to-broker network operator based on a proportional accounting for substantial usage of the system indicated by a greater than anticipated volume of transactions submitted for settlement. Accordingly, unless a system failure or error occurs, no rebate may be provided for an excess usage fee if a transaction submitted for settlement does not in fact close. Indeed, the network operator may reserve the right to charge an additional excess usage fee for further settlement processing when a failure to settle is due to member error.
  • the network operator's receipt of excess usage fees when a certain number of settlement instructions are generated would not cause the network operator to be effecting transactions in securities because the network operator has no substantive role in whether any trade is executed and submitted for settlement, and once submitted, whether the trade successfully closes.
  • the payment structure contemplated by the network operator reflects the intent for the system to be rigorously neutral as to the effectuation of transactions and to allocate among users their respective share of the costs of operating the system at the service levels demanded in a commercially rational manner.
  • the fees charged by the operator may be based on the operating overhead and the expenses of maintaining the system, plus recapture of start-up costs and a market driven profit .
  • FIG. 10 illustrates an example of a further computer system embodying the present invention.
  • BINET 1010 is a secure private network using Internet technology even though it itself need not be implemented on the Internet. Provided appropriate security measures are implemented, such as use of the public key infrastructure (PKI) , BINET may comprise the internet in some embodiments, as will be explained below.
  • PKI public key infrastructure
  • Order Management System (OMS) 1000 may be a UNIX application, written in C++, an Oracle RDBMS, and Microsoft Windows NT GUI front -end which acts as the transaction manager keeping track of orders, their status and directing the sequence of processing SELNET 1012 is a secure private network using Internet technology even though it itself need not necessarily be implemented on the Internet.
  • SMS Settlement Management System 1006
  • SMS may be a UNIX application, written in C/C++, an Oracle RDBMS, and Microsoft Windows NT GUI front-end, which controls the settlement of the proceeds of the transactions.
  • Settlement and Custody 1008 may be external agents (to the broker-to-broker system) who actually carry out the physical act of delivering/receiving cash and securities CSS
  • Customer Service System 1004 may be a UNIX and NT suite of applications which collects and reports status from other the broker-to-broker system systems, tracks the relationships with the broker-to-broker system's customers and provides access into the broker-to-broker system's systems to enable service personnel to correct problems.
  • CDR 1002, Central Data Repository may be implemented with an ORACLE RDBMS operating under HP/UX hosted on 100% non-stop STRATUS Continuum computer hardware.
  • the CDR 1002 is in this embodiment the single source from which all of the broker-to-broker system's sources static data, and into which all of the broker-to-broker system' s systems send status messages.
  • Figure 11 illustrates how an end terminal in the computer system of Figure 10 is connected to the broker-to-broker system.
  • the end terminal shown in Figure 10 is generally similar to that in Figure 3 and like reference numerals designate like features.
  • the communication interface 118 is a local area network (LAN) card to provide a data communication connection to a compatible LAN.
  • LAN local area network
  • communication interface 118 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
  • Network link 120 typically provides data communication through one or more networks to other data devices.
  • network link 120 may provide a connection through local network 122 to a host computer 124 or to data equipment operated by an Internet Service Provider (ISP) 126.
  • ISP 126 in turn provides data communication services through the worldwide packet data communication network, now commonly referred to as the "Internet" 128.
  • Local network 122 and Internet 128 both use electrical, electromagnetic or optical signals that carry digital data streams in accordance with well established protocols such as the TCP/IP protocol suite.
  • the signals through the various networks and the signals on network link 120 and through communication interface 118, which carry the digital data to and from computer system 400/402, are exemplary forms of carrier waves transporting the information.
  • Computer system 400/402 can send messages and receive data, including program code, through the communications link 120, and communication interface 118.
  • a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122 and communication interface 118.
  • downloaded instruction code provides for implementing a broker- to-broker system as described herein.
  • the received code may be executed by processor 104 as it is received, for example by using a browser application installed upon the end terminal, and/or stored in storage device 110, or other non- volatile storage for later execution.
  • computer system 400/402 may obtain application code in the form of a carrier wave.
  • any suitable end terminal device access network arrangement can be used to facilitate communication between a member and the broker-to-broker processing system 200.
  • alternative end terminals include mobile computers and personal digital assistants equipped for operation according to established communication protocols for internet based technologies, such as Wireless Application Environment WAE protocols and later equivalents.
  • Wireless links may be implemented on wireless communication systems based on techniques such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , space division multiple access (SDMA) , code divisional multiple access (CDMA) and hybrids thereof.
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • SDMA space division multiple access
  • CDMA code divisional multiple access
  • Some such systems are established and widely used, examples being AMPS and GSM, other such systems are under deployment, such as the Moble Station-Base Station Compatibility Standard for Dual -Mode Wideband Spread Spectrum Cellular System (IS95) and the Universal Mobile Telecommunications System (UMTS) .
  • IS95 Dual -Mode Wideband Spread Spectrum Cellular System
  • UMTS Universal Mobile Telecommunications System
  • preferred embodiments provide an order delivery and management facility for use by members to communicate with each other and to their respective settlement agents.
  • the system includes an integrated network of applications through which a member seeking fulfillment of a securities transaction order may enter the order into the system for routing to another designated member who is a broker qualified to fulfill the order or part thereof on the basis of prevailing conditions in the fulfilling member's market, subject to conditions specified by the originating member.
  • Nothing inherent in the system itself brings together orders or trading interests.
  • the parties using the system may be limited to originating members, fulfilling members and settlement agents. Brokers or for example, investment banks may use the system as originating or fulfilling members or both. Investors need not have access to the system other than through members.
  • Originating members using the system are charged a flat annual fee for up to a specified number of orders that result in the generation by the system of settlement instructions upon execution of a trade, based on an estimate of anticipated usage of the system by each such broker.
  • the annual fee may vary according to a specific member's discount schedule or system-wide transaction volume schedules.
  • a relatively nominal excess usage fee may be charged only if the originating member's use of the system generates a number of settlement instructions in excess of the applicable annual fee limit, in order to compensate the network operator for the additional use of the system's transmission and processing capabilities.
  • the network operator may assess excess usage fees to fulfilling members who generate more than a fixed number of settlement instructions through the system on orders sent to them through the system that they have executed.
  • Agreements between the network operator and members contracting to use the system may require that brokers have and maintain registration or qualification as broker-dealers to the extent required in the respective jurisdictions in which they conduct business, including the registration of foreign brokers whose activities in the United States or with U.S. investors require registration as broker-dealers under the Exchange Act .
  • Brokers using the system may receive no warranty or guarantee from the network operator concerning execution quality in the fulfillment of orders.
  • OMIF 202 may apply a significant amount of sensibility checking to the order, which in the limit may be as rigorous as the checks applied by broker-to-broker processing system 200, but the intent of the OMIF checks are mainly to provide the order originator with a more rapid response time.
  • a preferred broker-to-broker system enables originating members to send orders for execution to fulfilling members using a secure connection. The resulting transactions can be cleared and settled in the name of the two parties using the broker-to-broker system who are able to manage the process from end terminals.
  • the broker-to-broker system enables originating members to enter orders for transmission to the selected fulfilling members.
  • the broker-to-broker system enables fulfilling members to receive order requests from the originating members.
  • the broker-to-broker system enables fulfilling members to enter fill/execution reports for transmission back to the originating member.
  • the broker-to-broker system enables the originating member to receive fill/execution advisories/reports.
  • the broker-to-broker system enables either party to review the status of their orders.
  • the broker-to-broker system enables either party to request to modify attributes of the order.
  • the broker-to-broker system enables the originating member and fulfilling member to receive modification requests and to accept or reject the request.
  • the broker-to-broker system enables either party to request to cancel an order.
  • the broker-to-broker system enables either party to receive cancellation requests and to accept or reject the request.
  • the broker-to-broker system enables either party to sign off an order, i.e. initiate the settlement process for the fills/executions against his/her order.
  • the broker-to-broker system enables the OM and FM to receive sign off requests and to accept or reject the request.
  • the broker-to-broker system provides settlement management capability for those broker-to-broker system customers who wish to contract out that service to the broker-to-broker system.
  • broker-to-broker system will generate and control all messaging to and from the customer's elected agent bank and custodian in the name of broker-to-broker system customer.
  • the broker-to-broker system enables either party to upload material, e.g. notes, pricing models/tools/guidelines, audio clips, video clips to central electronic information library.
  • the broker-to-broker system enables either party to search the electronic information library and download material .
  • the broker-to-broker system enables either party to interrogate their billing account with broker-to-broker system to obtain information such as: transaction fees outstanding to broker-to-broker system; customer's membership fees outstanding; rebates applicable; agreed fee structure; and average TPD for week, month, quarter.
  • the broker-to-broker system enables either party to send messages directly to other broker-to- broker system customer (s) using the secure system network facilities.
  • the broker-to-broker system enables either party to obtain information about their use of broker-to-broker' s facilities such as: transaction history by: time period, security, market, exchange, sector, geographical region, execution quality statistics, VWAP, security control, authorized names, and passwords.
  • the broker-to-broker system enables either party to search for security information held within the databases of the broker-to-broker system.
  • the broker-to-broker system enables either party to search for member information held within the databases of the broker-to-broker system.
  • Preferred embodiments of the broker-to-broker system do not function as a broker, bank, clearing house, exchange, crossing network, auction room, aggregator or other place where the change of beneficial ownership of securities takes place. Other embodiments may however include one or more of the above or other functions.
  • the network provides a conduit through which orders can be transmitted for execution; described embodiments of broker-to- broker system do not provide the capability to match buyer and seller within it.
  • Broker-to-broker systems preferably never take ownership of stock, or monies in the transaction.
  • Embodiments of the broker-to-broker system thus need not have securities account (s) and shall not settle securities for its "own account.”
  • securities account s
  • the broker-to-broker system does have a bank account (s) , which exist purely for the purposes of paying for goods, services, taxes and other expenses, and for receiving payment for services rendered to its members and other income.
  • a preferred broker-to-broker system does- not take any commissions, or spreads on transactions the broker-to-broker system's only financial involvement in a transaction is the levy of a specific fees see section Transaction Fees below.
  • Preferred broker-to-broker systems charge an annual membership fee, with additional fixed fees for orders routed through the system and surcharges for settlement support .
  • the originating members are responsible for all additional fees and surcharges other than those surcharges for mistakes made by the fulfilling member.
  • Preferred embodiments of the broker-to-broker system do not change the sequencing of orders received from the originating member, i.e. there is no prioritization of orders from any given originating member, nor is there any prioritization of orders amongst originating members; ALL members and their orders are treated equally.
  • Broker-to-broker systems preferably do not change the sequencing of execution/fill advisories transmitted from the fulfilling member back to the originating member.
  • broker-to- broker system Since preferred embodiments of the broker-to- broker system seek always to be regulatory and business neutral, they do not oblige members to carry out any action which may offend or otherwise contravene the rules of their regulatory bodies or in any way influence the investment and execution decisions of its members. In particular, broker-to- broker system will not solicit orders or give financial advice and members of the system have no obligation to deal with any other member (s) . To that extent, members of the broker-to-broker system shall have no warranty or guarantee from the broker- to-broker system concerning execution quality or service obtained by members from other members.
  • the fulfilling broker of a securities exchange is under a regulatory obligation to provide "Best Execution", i.e. deliver the best price possible, to his/her customer taking into account all the factors surrounding the order, and the state of the market; specific factors commonly important to determining how to "best execute" an order are related to the size of the order compared with the normal market trading size so as to minimize market impact, the urgency with which the customer wants the order filled, e.g. the customer may be willing to pay a premium to the prevailing market price if his/her order can be filled in its entirety in one immediate action rather than having to have the order worked over the day where he/she is at risk that the price might rise/fall due to some exogenous event.
  • the broker-to-broker system provides at least two mechanisms :
  • the originating member can designate the execution venue which they require the fulfilling member to use when fulfilling the order, e.g. on exchange, off inventory, cross, best execution. In most jurisdictions the fulfilling member is released from his/her obligation to obtain "best execution" when their customer specifically demands a particular method of execution.
  • the broker-to-broker system order entry front -end allows the originating member to specify and set the default execution venue for each market and member.
  • Every fill reported back by the fulfilling member is time-stamped and the best official bid and offer as published at that time by that fulfilling member's market authority, (where available), is automatically appended to the fill advisory.
  • This information enables the originating members to compare the execution quality, which they have received from their fulfilling member vs. the pricing in the market.
  • the price stamped on the fill should take the best bid and offer available for the number of securities in the fill, e.g. if the official best bid and offer is for 1,000 shares, but the fill is for 5,000 shares then the best bid and offer are priced incorrectly.
  • This capability to more precisely price stamp the fills is available in the more transparent, more developed, and usually electronic markets which to some extent reduces the value of the price stamp to the originating member from a "best execution" perspective, since such markets are typically also more rigorously regulated.
  • the broker-to-broker system may on behalf of the parties to the transaction generate and transmit reports to the regulators of each party to the transaction. Such reports are designated in the name of the entity on whose behalf the broker-tobroker system has generated and transmitted the message.
  • Preferred embodiments of the broker-to-broker system do not prioritize amongst fulfilling members. All orders from the originating member should fully designate the identity of the desired fulfilling member.
  • the broker-to-broker system provides facilities to enable the originating member to select amongst the universe applicable for a given security/market for their desired fulfilling member and then to designate the selected fulfilling member as their default selection for all subsequent orders for that security/market until changed by the originating member. Preferred embodiments thus cannot select the fulfilling member on behalf of the originating member.
  • the broker-to-broker system described herein does not change the identity of the originating member's selected fulfilling member on an order. Where an originating member's selection of fulfilling member is invalid, the originating member is prompted to choose a valid fulfilling member before the order are further processed by the broker-to-broker system.
  • the two parties to a transaction across the broker-to-broker system network are the initiating member (in this case the member who enters an order into the system, i.e. the originating member), and the fulfilling member (in this case the member who fills the order, i.e. the fulfilling member) .
  • the legality/contract of the transaction is as follows: Let A be the originating member issuing a buy stock Let B be the fulfilling member fulfilling the buy order Then the transaction, which takes place, is: B sells stock to A and A buys stock from B Note At no time does this embodiment of the broker-to-broker system enter into the transaction, thus concepts such as riskless principal, agency, principal are completely excluded from the broker- to-broker system business, legal, and financial processes. CONFIDENTIALITY
  • elements of the broker-to-broker system do not know the identity of the entity/person on whose behalf the originating member entered the order. Any reference code attached to the order by the originating member are preserved and attached to all messages relating to that order and its subsequent executions, however embodiments of the broker-to-broker system need not translate/map that reference code or in any other way alter such reference code. It is possible that the originating member may need to attach such reference code to enable them within their systems to be able to determine the eventual beneficiary of the proceeds of the transactions.
  • the broker-to-broker system need not store or otherwise record such reference codes and need not use the presence of or omission of such reference codes for any purpose whatsoever.
  • preferred embodiments of the broker-to-broker system do not know the identity of the entity from/to which the fulfilling member bought/sold or otherwise obtained the securities in order to fulfil the originating member's order.
  • Settlement of the trade between the originating member and their customer is within the purview of the originating member. For example, the price charged to the originating member's customer, fees, quantity of shares received/delivered, date of delivery, where delivered are at the originating member's discretion.
  • the broker-to-broker system need not generate settlement instructions, confirmations or other forms of advisories, messages to the originating member's customer, unless requested to by the originating member. Settlement of the trade between the fulfilling member and the "street” is within the purview of the fulfilling member.
  • the broker-to-broker system can generate settlement instructions, confirmations or other forms of advisories, and messages to the fulfilling member's "street” counterparties.
  • the broker-to-broker system may on request and on behalf of either or both parties to the transaction generate and transmit settlement instructions, designated and in their name to their respective agent banks and custodians.
  • Party A Instructions Party A will receive Y shares of security Z Party A will deliver monies to party B calculated in general as follows: (X * Y) + (X * Y) *C% + (X * Y) *T% In related embodiments, jurisdictional rules are conventions are further catered for in the calculation method shown above to allow for the different ways in which taxes and other fees are levied in the different markets. Party A will deliver monies to the broker-to- broker system calculated as follows A fixed fee if the total number of transactions processed by PARTY A exceeds the number of transactor's budget in Party A's annual fee.
  • the fixed transaction fee is purely exemplary and may be varied according to, for example, per originating member discount schedules, per originating member rate, the broker-to-broker system system-wide per transaction volume related pricing schedules, the broker-to-broker system system-wide per transaction pricing schedules based on geography/market but in general the fee payable will in no way be calculated off or in any other way be related to the value of the security transaction itself.
  • the broker-to-broker system may on behalf of either or both parties to the transaction generate trade confirmations or advisories to either or both parties to the transaction.
  • the broker-to-broker system may generate a telex confirming to the originating member the details of the transaction prior to settlement processing so as to permit the originating member's settlement function to confirm that the transaction is as expected.
  • acknowledgements / advisories are designated in the name of the entity on whose behalf the broker-to-broker system has generated and transmitted the message.
  • acknowledgements / advisories include the text similar to the following: "The information contained within this acknowledgement and the terms and conditions applicable at the time of execution were agreed solely between you and the fulfilling / originating member named below as a result of one or more interactions across the broker-to-broker network. Any disagreement with the following should be notified immediately to the fulfilling / originating member" .
  • the broker-to-broker application need never know the "investor" details. Therefore the use of the broker-to-broker network to carry out proprietary/own account trading activities by the originating member for the benefit of the originating member itself have no significance to the way the broker-to-broker system processes or otherwise acts upon the order and any subsequent transaction resulting from that order.
  • the originating member may alter/cancel any part or all of the order.
  • any alterations/cancellations to that order become requests to alter/cancel which must be accepted by the designated fulfilling member.
  • any securities purchased/sold by the fulfilling member at the time the alteration/cancellation request was received must be received/delivered to the originating member, i.e. settlement takes place if any executions have taken place prior to the fulfilling member receiving and accepting the change request. That is, partial fills are still contractually binding.
  • broker-to-broker processing system 200 Before an order is accepted by preferred embodiments of broker-to-broker processing system 200 for onward routing to the fulfilling member, the following minimum set of conditions have to be satisfied, i.e. present on the "order form": a) The security identifier is valid b) The number of securities to purchase/sell has been specified c) The direction of the order has been specified, i.e. buy, and sell d) The price conditions on the order are valid for that specific market and that specific security, e.g. market, limit e) The duration and timing of the order are valid for the specific security and market, e.g.
  • the trade date for the transaction has been suggested g)
  • the settlement date for the transaction has been suggested h)
  • the designated fulfilling broker for the order is valid for the security and market i)
  • the commission rate to be charged by the FM has been suggested j)
  • the desired execution venue has been selected by the originating member k)
  • the originating member may select "best execution" as the venue, in which case the fulfilling member may use their discretion as to how to best fulfil the order. 1)
  • the identity of the issuing person at the originating member has been positively authenticated and is valid.
  • Helper classes import com. sapient .helper.B2BConstants; import com. sapient.helper. Self; import co . sapien .helper. StatusReturn;
  • This method is invoked when a client invokes the matching oreate ' O l_ l m * on the home interface .
  • I * contain all the order data m * that has been entered by the
  • LastActionBrokerld is set theOrderDetailElements . setLastActionBrokerld (theSelf . etBrokerld ( ) ) ;
  • OrderGTEIF ( ) OrderGTEIF ( ) ) .
  • enterOrder theOrderDetailElements) ) ;
  • This method is used to withdraw a pending request. It firstly calls the
  • OrderPK myorderReferencePK - new OrderPK(myOrderReferenceNumber) ;
  • LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf . getBrokerld () ) ;
  • ⁇ param StatusReturn This object is used to pass status data from method to m method to indicate success or co failure of certain processes.
  • m ⁇ param Self This object contains the m Userld and Brokerld of the person who 'has logged into the t o
  • OrderDetailElements will m contain all the order data that has been entered by the user as well as enriched information from the GTE such as the order number.
  • I status data from method to m m method to. indicate success or ' f ilure of certain processes .
  • LastActionBrokerld is set theOrderDetailElements . setLastActionBrokerld (theSelf . getBrokerld ( ) ) ;
  • TJ param StatusReturn This object is used to pass c status data from method to i- m method to indicate success or failure of certain processes.
  • ⁇ param Self contains the Userld and Brokerld of the person who has logged into the system.
  • OrderDetailElements will contain all the order data that has been entered by the user as well as enriched information from the GTE such as the order number.
  • OrderPK myorderReferencePK new OrderPK (myOrderReferenceNumber) ;
  • LastActionBrokerld is set theOrderDetailElements .
  • setLastActionBrokerld (theSelf .getBrokerld () ) ; // Ignoring returned request reference (new OrderGTEIF ) .
  • requestCancelUnacceptedOrder (theOrderDetailElements) ;
  • requestCancelOrder (StatusReturn theStatusReturn, Self theSelf , OrderRequestElements theOrderRequestElements) throws B2BException, RemoteException ⁇ final String thisMethod * thisClass + "requestCancelOrder : " ;
  • This method is used to accept the cancellation of an accepted order.
  • the acceptance is sent to the orderlnterface.
  • This method in turn passes this cancellation acceptance on to the GTE. It does this by calling AcceptCancelOrder ( ... ) method. If this is successful, the method acceptCancel will be called on the OrderBean.
  • Daram StatusReturn This object is used to pass status data from method to method to indicate success or failure of certain processes.
  • ⁇ param Self contains the Userld and Brokerld of the person who has logged into the system.
  • This method is used to reject the cancellation of an accepted order.
  • the rejection is sent to the orderlnterface.
  • This method in turn passes this cancellation rejection on to the GTE. It does this by calling
  • RejectModifyCancelOrderf If this is successful, the method rejectCancel will be called on the OrderBean.
  • OrderPK myorderReferencePK new OrderPK(myOrderReferenceNumber) ;
  • This method is used to request a modification of an accepted order.
  • the request is sent to the orderlnterface.
  • This method in turn passes this modification request on to the GTE. It does this by calling
  • RequestModifyOrder((7) method If this is successful, the method requestModify will be called on the OrderBean.
  • LastActionBrokerld is set theOrderRequestElements .
  • setLastActionBrokerld (theSelf .getBrokerl ) ; m ⁇ > // Ignoring returned request reference (new OrderGTEIF O ) .
  • requestModifyOrde (theOrderRequestElements) ; try ⁇
  • This method is used to accept the modification of an accepted order.
  • OrderPK myorderReferencePK new OrderPK (myOrderReferenceNumber) ;
  • LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf .getBrokerldO ) ; try ⁇
  • OrderRequestElements will contain all the order ' data m that has been entered by the co user;
  • LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf . getBrokerl () ) ;
  • OrderPK myorderReferencePK new OrderPK(myOrderReferenceNumber) ;
  • LastActionBrokerld is set theOrderReques tElements . setLastActionBrokerld (theSelf .getBrokerld O ) ;
  • OrderDetailElements will contain all the order data that has been entered by the user as well as enriched information from the GTE such as the order number.
  • OrderPK myorderReferencePK new OrderPK (myOrderReferenceNumber) ;
  • LastActionBrokerld is set t h eO rd e r R equestElements . setLastActionBrokerld (theSelf .getBrokerld O ) ;
  • This object contains the Userld and Brokerld of the person who has logged into the system.
  • OrderDetailElements will contain all the order data that has been entered by the user as well as enriched information from the GTE such as the order number.
  • the interface includes all actions that can be associated
  • the container invokes this method in response to a client-invoked W * remove request.
  • the beanjs representation is removed from the g j * container.
  • JQ * The associated order has an execution element set with all the user-entered details .
  • ArrayList array new ArrayLis () ;
  • Enumeration executions executionHome.findByOrderld (orderld) ; while (executions.hasMoreElements () ) ⁇
  • Execution execution (Execution) executions.nextElement () ; array. add(execution.get ⁇ rderExecutionElements () ) ,-
  • Order order orderHome. findByPrimaryKey (new OrderPK (anOrderld) ) ; '
  • OrderDetailElements details order. getOrderDetails () ;
  • OrderHome orderHome (OrderHome)HomeFactory.findHome ("com.sapient.order. O rder H ome” ) ;
  • Order order orderHome.findByPrimaryKey(new OrderPK(anOrderld) ) ,- '
  • OrderDetailElements details order.getOrderDetails () ,- myOrderExecutionElemen . setRequestRe erence(details . etRequestReference () ) ,-
  • OrderHome orderHome (OrderHome)HomeFactory.findHome ("com. sapient. order.OrderHome”) ;
  • CcO Order order orderHome. findByPrimaryKey(new OrderPK(orderld) ) ;
  • Execution execution executionHome . findByPrimaryKey (new ExecutionPK (myExecutionRef erence) ) ; j C2 return execution. getOrderExecutionElements () ; I- ⁇ catch (HomeFactoryException ex) ⁇ m throw new LoggedException ( "HomeFactoryException: getExecution : " + ex) ; ⁇ > ⁇ catch (FinderException ex) ⁇

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un procédé de fonctionnement d'un système informatique destiné à gérer des ordres relatifs à des transactions effectuées sur une bourse. Un membre originaire place un ordre relatif à une transaction et un membre exécuteur réalise cette transaction, chaque membre ayant accès à un terminal différent de ce système. Ce procédé consiste à entrer au niveau d'un premier terminal au moins un élément d'information d'une transaction électronique, à transmettre cet élément d'information de ce premier terminal à un système de traitement, ce système de traitement pouvant fonctionner de façon à acheminer des éléments d'information entre ce premier terminal et ce second terminal et à générer des critères de transaction soumis à l'agrément du membre originaire et du membre exécuteur, à recevoir au niveau de ce premier terminal les critères de transaction acceptés au niveau du second terminal, à afficher au niveau du premier terminal les critères de transaction acceptés au niveau du second terminal, et à entrer au niveau du premier terminal une indication d'acceptation de ces critères de transaction acceptés.
PCT/GB2000/004675 1999-12-08 2000-12-07 Systeme de gestion d'ordres WO2001042950A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU26897/01A AU2689701A (en) 1999-12-08 2000-12-07 Order management system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US16962099P 1999-12-08 1999-12-08
US60/169,620 1999-12-08
PCT/GB2000/004180 WO2001042949A2 (fr) 1999-12-08 2000-10-31 Systeme permettant de faciliter les transactions sur un central de communication
GBPCT/GB00/04180 2000-10-31

Publications (2)

Publication Number Publication Date
WO2001042950A2 true WO2001042950A2 (fr) 2001-06-14
WO2001042950A8 WO2001042950A8 (fr) 2002-02-07

Family

ID=26243701

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/GB2000/004675 WO2001042950A2 (fr) 1999-12-08 2000-12-07 Systeme de gestion d'ordres
PCT/GB2000/004763 WO2001042951A2 (fr) 1999-12-08 2000-12-08 Systeme de gestion des demandes de transaction

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/GB2000/004763 WO2001042951A2 (fr) 1999-12-08 2000-12-08 Systeme de gestion des demandes de transaction

Country Status (2)

Country Link
AU (2) AU2689701A (fr)
WO (2) WO2001042950A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022000391A1 (de) 2022-02-02 2023-08-03 Wolfgang Halang Zuordnungsgerät für Handelsaufträge

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7840477B2 (en) * 2005-06-07 2010-11-23 Bgc Partners, Inc. System and method for routing a trading order based upon quantity
US8484122B2 (en) 2005-08-04 2013-07-09 Bgc Partners, Inc. System and method for apportioning trading orders based on size of displayed quantities

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No Search *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022000391A1 (de) 2022-02-02 2023-08-03 Wolfgang Halang Zuordnungsgerät für Handelsaufträge

Also Published As

Publication number Publication date
WO2001042950A8 (fr) 2002-02-07
WO2001042951A8 (fr) 2001-12-27
WO2001042951A2 (fr) 2001-06-14
AU2689701A (en) 2001-06-18
AU2689801A (en) 2001-06-18

Similar Documents

Publication Publication Date Title
US7110969B1 (en) Methods and systems for electronic order routing (CORS)
US7379910B2 (en) Apparatus, systems and methods for transacting and managing like-kind exchanges
US6029146A (en) Method and apparatus for trading securities electronically
US20050187866A1 (en) Method and system for executing financial transactions via a communication medium
US7729972B2 (en) Methodologies and systems for trade execution and recordkeeping in a fund of hedge funds environment
US6247000B1 (en) Method and system for confirmation and settlement for financial transactions matching
US7555455B2 (en) Method and system for computer-implemented trading of new issue debt securities
US8538857B2 (en) Online trading system having real-time account opening
US20020091623A1 (en) System and methods for an electronic real estate trading environment
US20010037276A1 (en) System and methods for group retirement plan administration
US20030050879A1 (en) System and method for improved multiple real-time balancing and straight through processing of security transactions
JP2003504701A (ja) ポートフォリオ投資ガイドライン・コンプライアンス及び金融ファンド管理システム
US8666871B1 (en) System and method for handling trades by advisers turning independent
WO1998058333A1 (fr) Procede et systeme de confirmation et de reglement pour la mise en correspondance de transactions financieres
JP2002373255A (ja) 決済情報ネットワークシステム及び情報処理装置，決済情報配信方法，プログラム並びに記憶媒体
WO2001042950A2 (fr) Systeme de gestion d'ordres
EP1242904A1 (fr) Systeme permettant de faciliter les transactions sur un central de communication
US7636684B1 (en) Issuer monitor system for monitoring and/or analyzing financial transactions and method of using the same
US20120221426A1 (en) Marketplace auction system and method for purchasing meetings and events
EP1074928A2 (fr) Méthodes et systèmes pour l'acheminement d'ordres électronique
JP2004527020A (ja) オンライン金融取引を容易にする装置と方法
JP2002318916A (ja) 配信可能通知ネットワークシステム及び情報処理装置，配信可能通知方法，配信可能情報受信方法，プログラム並びに記憶媒体
JP2002318913A (ja) 決済情報ネットワークシステム及び情報処理装置，決済情報配信方法，プログラム並びに記憶媒体
JP2002373254A (ja) 配信可能通知ネットワークシステム及び情報処理装置，配信可能通知方法，プログラム並びに記憶媒体
JP2002318914A (ja) 情報エントリシステム、情報エントリ方法、情報エントリ装置及びプログラム並びに記憶媒体

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

D17 Declaration under article 17(2)a
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP