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 a system which may be used to facilitate transactions on an exchange .
• BACKGROUND OF THE INVENTION There are many types of exchange on which members communicate to transact business. For example, members of financial exchanges may trade money or an equivalent in exchange for an instrument or commodity.
• Other types of trading exchanges include the many electronic business-to-business exchanges and business-to-consumer exchanges for trading goods and services.
• Such business-to- business exchanges typically adopt either a vertical or a horizontal structure. Vertical exchanges are based on specific industry sectors, e.g. aerospace, automotive or chemicals. An example of a vertical business-to-business exchange is GMtradexchange.com on which parts for the automotive industry are traded. Horizontal business-to-business exchanges are organized around the products and services provided which typically span more than a single industry sector.
• An example of a horizontal business-to-business exchange is MR0.COM which provides a market place for materials, repair and operations goods and services.
• Exchanges of the above general types are used by members.
• the term "member” used herein refers to a party having access to an exchange in order to transact business on it.
• exchange used herein 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 traditional stock exchanges and alternative trading systems
• EPNs electronic crossing networks
• brokers 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” .
• the U.S. market for equity securities has experienced dramatic growth. This growth is evidenced by the trading volumes in the NASDAQ, NYSE and AMEX markets, as well as trading volume in the so-called Third Market: The average daily volume of securities traded in the NASDAQ increased from 225.0 million shares in December 1992 to 867.1 million shares in December 1999. The average daily volume of securities traded on the NYSE increased from 222.2 million shares in December 1992 to 692.8 million shares in December 1998.
• Order flow is the volume of buy and sell orders received by a broker-dealer. Increased order flow provides market makers with a greater number of trades and increased trading profit opportunities. To succeed, these broker-dealers require sophisticated trading methodologies, computerized trading systems, and risk management practices that can handle increased order flow while maintaining low costs per trade. They also need personnel with the requisite expertise to deliver superior trade executions and customer service. For example, people who need to buy/sell securities for investment purposes, i.e., Investors, issue their orders to buy/sell securities to a financial advisor/intermediary who is authorized to carry out securities dealings, e . g. a broker or bank.
• the broker then fulfils the Investor's order generally in one of two ways: (a) If the broker has access to an exchange where the securities are transacted, the fulfilling broker goes into that market and executes the order. This action is the Domestic activity. The broker then delivers the proceeds to the investor. This is the "traditional" stock-brokering activity, which has been taking place for the last 70-100 years; (b) If the broker does not have access to an exchange where the securities are transacted, typically the case for small or medium-sized brokers when asked to obtain foreign securities, the broker communicates with another broker who is a member and that broker executes the order. In this case the first broker is a customer of the second broker. In this case the second broker delivers the proceeds to the first broker, who then in turn delivers the proceeds to the investor.
• logistical barriers currently make cross-border securities transactions difficult, error-prone and expensive.
• 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 party not having access to the exchange, the method comprising: receiving at a first interface of a processing system at least one information item of an electronic transaction proposal from an originating party; 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 settlement criteria to be accepted by the originating party and the fulfilling member; and receiving from each of the originating party and the fulfilling member an indication of acceptance of the settlement criteria generated by the processing system.
• the step of receiving the at least one information item of the electronic transaction proposal comprises receiving an information item indicating what is to be transacted.
• the step of receiving the at least one information item of the electronic transaction proposal may also comprise receiving an information item identifying a designated fulfilling member to perform the transaction.
• the settlement criteria generated by the processing system may be based on settlement information received from the originating party and the fulfilling member.
• the settlement criteria generated by the processing system may also be based on stored settlement information accessible by the processing system.
• the settlement information received from each of the originating party and the fulfilling member includes an indication of acceptance of the settlement criteria generated by the processing system.
• the processing system can generate settlement instructions to be issued on behalf of the originating party and the fulfilling member.
• settlement instructions are generated responsive to said indications of acceptance of the settlement criteria.
• a fulfilling member can request a modification to at least part of an electronic transaction proposal from an originating party.
• the step of receiving the at least one information item of the electronic transaction proposal may comprise receiving information items relating to a proposed transaction selected from one or more of the following: a transaction type indicator; a quantity indicator; a price condition; and timing information.
• the timing information can indicate a proposed transaction date and/or a proposed settlement date.
• the step of receiving the at least one information item of the electronic transaction proposal may comprise receiving information items relating to the proposed transaction from the originating member in two or more sub-steps. For example, an originating party may provide a first information item in a first sub-step and the processor system can supply a further relevant information item responsive thereto.
• the processing system can supply a plurality of further relevant information items from which the originating party can select.
• an originating member provides a first information item indicating what is to be transacted in a first sub-step and the processing system prompts the originating party to select from further information items representing exchange options in a further sub-step.
• the processing system can convert at least a portion of an electronic transaction proposal from a first format appropriate to the originating party into a second format appropriate to the fulfilling member. For example, the processing system converts a transactional term in a first language appropriate to the originating party into a second language appropriate to the fulfilling member.
• the processing system may convert a price indication in a first currency appropriate to the originating party into a corresponding price indication in a second currency appropriate to the fulfilling member.
• the processing system can convert a first security identifier appropriate to the originating party into a second security identifier appropriate to the fulfilling member.
• the first format is selected by the originating party.
• the second format is selected by the fulfilling member.
• the processing system can also transfer an information item between the first interface and the second interface without altering the format of the information item.
• preferred embodiments of the processing system can generate a predetermined signal to alert a member of a change in status of a proposed transaction.
• the fulfilling member also functions as an originating party by submitting transaction proposals for execution on a further exchange.
• the originating member also functions as a fulfilling member by performing a transaction on a further exchange.
• 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 party not having access to the exchange comprising: a first processing system interface adapted to receive one or more information items of an electronic transaction proposal from an originating party; 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 settlement criteria to be accepted by the originating party and the fulfilling member, and wherein the processing system is arranged to receive first and second information items indicating acceptance of the settlement criteria by each of the originating party 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 party 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 party; 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 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 party not having access to the exchange comprising: receiving at a first interface of a processing system an information item of an electronic transaction proposal from an originating party, said information item being in a first form appropriate for the originating party; converting said information item of the electronic transaction proposal from the first form into a second form appropriate to a fulfilling member ; and transmitting the information item in the second form from a second interface of the processing system to a 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 party not having access to the exchange, the system comprising: a first processing system interface adapted to receive an information item of an electronic transaction proposal from an originating party, said information item being in a first form appropriate to the originating party; a processing system operable to convert the information item of the electronic transaction proposal from the first form into a second form appropriate to a fulfilling member; and a second processing system interface adapted to transmit the information item in the second form to 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 party; 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 settlement criteria to be accepted by said originating party and said fulfilling member; and a further routine for receiving first and second indications of acceptance of said settlement criteria from said originating party and said fulfilling member.
• a transaction being performed by a fulfilling member having access to an exchange on behalf of an originating party 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 party; 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 settlement criteria to be agreed by each of said originating party and said fulfilling member and for receiving first and second indications of agreement from said originating party 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 party not having access to the exchange, the method comprising: receiving at least one information item of a transaction proposal from an originating party; transmitting at least one information item of the transaction proposal to a fulfilling member; generating settlement criteria to be accepted by the originating party and the fulfilling member; and receiving indications of acceptance of the settlement criteria from each of said originating party and said fulfilling member.
• the method includes generating first and second settlement instructions on behalf of said originating party and said fulfilling member responsive to receipt of said indications of acceptance.
• a 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 party not having access to the exchange
• the system comprising: means for receiving a transaction proposal from an originating party; means for transmitting a transaction proposal to a fulfilling member; means for receiving accepted settlement particulars from said originating party and said fulfilling member; means for generating first and second settlement instructions on behalf of said originating member and said fulfilling member responsive to receipt of said accepted settlement particulars; and means for issuing said first and second settlement instructions.
• 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 party not having access to the exchange, the method comprising: receiving an information item of a transaction proposal from an originating party, said information item being in a first form appropriate for the originating party; converting said information item of the transaction proposal from the first form into a second form appropriate to a fulfilling member; and transmitting the information item in the second form to a fulfilling member.
• a 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 party not having access to the exchange; the method comprising: means for receiving an information item of a transaction proposal from an originating party, said information item being in a first form appropriate to the originating party; means for converting said information item of the transaction proposal from the first form into a second form appropriate to a fulfilling member; and means for transmitting the information item in the second form to a fulfilling member.
• a transaction being performed by a fulfilling member having access to an exchange on behalf of an originating party not having access to the exchange
• the program code comprising: a first set of instructions for receiving an information item of a transaction proposal from an originating party, said information item being in a first form appropriate for the originating party; a second set of instructions for converting said information item of the transaction proposal from the first form into a second form appropriate to a fulfilling member; and a third set of instructions for transferring the information item in the second form to a 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 an information item of a transaction proposal from an originating party, said information item being in a first form appropriate for the originating party; a second routine for converting said information item of the transaction proposal from the first form into a second form appropriate to a fulfilling member; and a third routine for transmitting the information item in the second form to a 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 broker.
• the order is in a format appropriate to the originating broker.
• the order is converted into in a format appropriate to the fulfilling broker and transmitted to the fulfilling broker 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.
• FMs Executing Members
• OMs Optimizing Members
• 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 5 is a flow chart illustrating connection and display update processes 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 flow chart illustrating execution reporting processes of the computer system of Figure 4
• FIGURE 9 is a flow chart
• the financial industry is beset with terminology that varies with jurisdiction.
• the broker-to-broker system is an entirely novel arrangement within the financial industry, i.e. it is not a bank, brokerage, exchange, advisor, or any other kind of conventional financial related entity, it is vital that clarity of purpose, role and responsibility of the components, systems and entities within the broker-to-broker system be maintained at all times.
• Originating Party/Member The originating party/member is the entity on the broker-to-broker system's network that originates orders into the network.
• the originating party may be any institution appropriately regulated to place orders with a fulfilling member on behalf of themselves or third parties.
• the originating member is called thus because this entity can be a member of an exchange who starts the process off by entering an order into the system, i.e. it originates the order. It is assumed that typically orders entered into the broker-to-broker system network have been entered because the originating member has been requested by a customer to purchase/sell securities. Strictly speaking however, there is no requirement for the originating member to enter only their customer's requests, in addition some members may conduct extensive "own-account" /proprietary trading using the broker-to-broker system's network to send orders for execution. In examples in this document the originating party/member is designated as Party A.
• the fulfilling member is the entity on the broker-to-broker system's network which receives orders from the originating member and then executes against those orders, i.e. the order is the desire to do something and fulfillment is the satisfying of that desire.
• 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.
• Party B the fulfilling member is designated as Party B.
• Member Members are customers (users) of the broker-to-broker system having access to one exchange or another and are usually brokers acting as transacting agents for investors. When referring to the clients of the broker-to-broker system's member's the term Investor will be used implying the eventual beneficiary of the proceeds of transactions.
• investors have no contractual or any other kind of relationship with the broker-to-broker system; an investor's relationship legal or otherwise exists between the investor and their financial advisor (s) .
• 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 preferred communications system.
• the broker-to- broker computer 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 ministerial 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 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. It is particularly advantageous 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. Once an order is accepted, 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.
• 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 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: Netscape Navigator 4.5, Microsoft Internet Explorer 4; HTML 4: JavaScript; JAVA; 128 Bit SSL.
• the application core may be built using the following standards: Netscape Commerce or Apache Server; CGI with Perl and C/C++ 504; Java servelets; Java servelet pages; application server (e.g. WebLogic) ; SUN Solaris or Linux Operating System; Oracle Database; Tellurian Secure Sockets.
• the target technical environment at the originating/fulfilling member end terminal will thus be Netscape Navigator 4.5 or Microsoft Internet Explorer 4.01, higher versions may be used.
• 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. That is, items like colors, and language preference, frame sizes and positions can be safely stored in cookies, but items such as security identifiers, default fulfilling members and default execution venue are preferably not be stored since knowledge of these could be used to interpret an originating member's transaction history.
• 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.
• FIG. 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 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 OMS database 435 and the SMS database 445 are connected by a database link 452.
• 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 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.
• 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 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.
• Once 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.
• 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: State of Order; OM FM
• 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.
• 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.
• 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.
• the system can perform certain data conversion or translation services of a clerical or ministerial 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. 5 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 .
• 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 20 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.
• 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; 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) .
• Further frames allow originating members to 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: • enter orders for transmission to the selected fulfilling members; • request to cancel his/her orders; • request to modify attributes of his/her orders ; • respond to requests to cancel initiated by the fulfilling member; • respond to requests to modify initiated by the fulfilling member; • request to sign off his/her orders i.e.
• 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.
• SID security identifier
• the OM 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 graphic 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; 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. (Even when the order is for their own-account, i.e.
• 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. T for thousands, M for millions, H for hundreds.
• 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 OM 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 FM; free format message area viewable by the OM only; trade date; settlement date; capacity the OM 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.
• 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.
• a message containing the details of the originating member's order is sent to the order management system server 430.
• the order processing software 436 of the order management system server 430 then stores the details of the order in the OMS database 435 (see step 618) .
• 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 will 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.
• 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.
• 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; free form message area.
• Other frames 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; When an order is transmitted to the fulfilling member, an alert mechanism, visual and audible, prompts the fulfilling member that there is an order to be dealt with.
• 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.
• 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.
• 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.
• 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.
• 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: identity of the fulfilling member; 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; 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) .
• 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 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 (see step 804).
• 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 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.
• Step 810 the order has been fully executed by the fulfilling member
• the fulfilling member can execute the remainder later. If the fulfilling member executes the remainder of the order later (see step 812), the process from step 800 is followed to report completion of order to the originating member. In cases where the fulfilling member does not execute the remainder of the order that day, the order status is preserved until the next suitable day.
• Figure 9 is a flow chart illustrating how settlement instructions are generated and issued by the broker-to-broker computer system. Either party can initiate the settlement procedure, however in this example the procedure is initiated by the fulfilling member.
• the fulfilling member selects the executed order for which he wishes to initiate settlement proceedings by clicking on it.
• the fulfilling member's screen prompts him/her to "request sign-off" (see step 902).
• a fulfilling member selects the request sign-off button, he/she is prompted to enter settlement information, including data identifying the settlement account of the fulfilling member (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) .
• 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 the calculated settlement criteria of the originating member to the end terminal 400 where the originating member can review and either accept or reject them (see step 920) .
• 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 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.
• 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) .
• settlement instructions are generated and associated with a given medium that identifies how the message will be sent to the clearing agent.
• 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. (SWIFT is an international standard recognized by banks for sending messages to make payments of cash and securities.)
• SWIFT is an international standard recognized by banks for sending messages to make payments of cash and securities.
• criteria and criteria acceptance messages may also be routed between the originating member, the fulfilling member via indirect routes. For example, 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.
• 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. In this preferred embodiment, settlement instructions are issued to the settlement agent of the originating member and the settlement agent of the fulfilling member at the same time.
• 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-F File based interface
• BIAPI-I Interactive interface.
• 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 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.
• 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: Netscape Navigator, Microsoft Internet Explorer - for Web browsers HTML 4, DHTML, SSL, JavaScript - for Web front- end programming Netscape, Apache - 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.
• 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) .
• Figures 12 and 13 illustrate alternative access networks BINET and SELNET which may be used by originating and fulfilling members, respectively, to connect to the embodiment of Figure 10. Referring to FIG.
• the originating member interface OMIF 202 may replaced with an access network BINET connecting the originating member with the broker-to-broker processing system 200 and providing him/her with the ability to interact with other customers.
• the access network BINET comprises: an end terminal 1230 through which the originating member interacts with broker-to-broker processing system 200; a computer-to-computer applications programmer interface, BINET-API, which the originating member may use to interface his/her systems directly into the broker-to-broker system network so as to eliminate rekeying of data.
• BINET- API can be made available, for example, as an interactive interface, BIAPI-I, or as a file/batch interface, BIAPI-F; a secure, encrypted, hi-speed, reliable and guaranteed QOS TCP/IP network connection, BICON, which links BINET sessions at the originating member location into the broker-to-broker system.
• the fulfilling member interface may be replaced by an access network SELNET connecting fulfilling members to the broker-to-broker processing system.
• SELNET-API can be used by the fulfilling member to interface his/her systems directly into the broker-to-broker system 200.
• SELNET-API is available as an interactive interface, or as a file/batch interface; a secure, encrypted, hi-speed, reliable and guaranteed QOS TCP/IP network connection, which links SELNET sessions at the fulfilling member's location into the broker-to- broker system.
• BIWEB/SELWEB operate on BINET and SELNET, respectively, and comprise two major parts, the front-end or GUI which the fulfilling members interact with, and the application core which processes the data entered by the members .
• the front-end may be built using the following standards : Netscape Navigator 4.5., Microsoft Internet Explorer 4.01; HTML 4 + JavaScript; JAVA; 128 Bit SSL.
• the application core may be built using the following standards: Netscape Commerce or Apache Server; CGI with Perl and C/C++; Java servelets; Java Servelet Pages; Application Server; SUN Solaris or Linux Operating System; Oracle Database; Tellurian Secure Sockets.
• a target technical environment at the fulfilling member may be Netscape Navigator 4.5 or Microsoft Internet Explorer 4.01, higher versions may be used.
• 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 broker-to-broker system can be severely restricted if not eliminated so as to minimize any security risk, e.g.
• BIWEB and SELWEB may be constructed so that its operating "footprint" on the user's machine 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 .
• One target machine environment may be a Pentium 233 MHz personal computer running the Microsoft Windows NT operating system.
• BIWEB and SELWEB will be used at many sites, and very often where the level of technical support is minimal or self-help is the norm, BIWEB and SELWEB must not require the installation of any components from disk/CDROM etc. at the customer's premises.
• every fulfilling member will need to use a physical security token unique to each individual at the fulfilling member's premises, such as SecurlD from RSA Dynamics, to identify themselves to the system.
• This token (s) and operating guide will be delivered to the fulfilling member using secure courier facilities. Once in possession of the token, all that will be required of the user will be to start up their web browser and navigate to the BIWEB or SELWEB URL.
• the access network (referred to herein as BICON) is the physical infrastructure that connects the originating members 1230 with the broker-to-broker processing system 200.
• BICON comprises secure digital communications links between individual members and the broker-to-broker processing system 200.
• BICON is a Virtual Private Digital Network, VPDN which is a physically secure, and information secure, guaranteed quality service, QOS, data communications network.
• VPDN Virtual Private Digital Network
• Such networks can be installed between the originating member's location and the nearest broker- to-broker point-of-presence .
• the contract for installation and operation is between the originating member and broker-to-broker systems.
• BICON comprises the internet. Access to BICON may be controlled through the use of firewall 1210, 1215 and RSA Dynamics SecurlD with Radius database technology 1200, 1205 which provides physical access token technology.
• every individual at each originating member who may use BINET has an individual logon identity, and must be in possession of his/her unique SecurelD token.
• the use of generic IDs or broker-wide IDs may be contractually prohibited by a broker-to- broker network operator in its agreements with customers. All data packets sent over BICON may be encrypted using 128 bit SSL technology so as to ensure complete privacy and confidentiality of the information.
• BICON is available in several different physical implementations depending on the volume and response characteristics required by the originating member.
• originating members may most probably use dial-up connections in the less well developed countries where order volume will be small, and the telecommunications infrastructure is not developed and/or slow to respond. For more demanding light usage, i.e. 2 BIWEB sessions, a 56/64Kbit ISDN dial-up session should suffice.
• ISDN or high bit rate digital interfaces for dial-up connections may be seen as the preferable alternative to analogue dial-up where the telecommunications infrastructure allows and/or the break-even point between dial-up and fixed line economics has not been reached.
• BINET BIAPI
• SELCON is the physical networking infrastructure that connects the fulfilling members with the broker- to-broker system processing core.
• SELCON is a Virtual Private Digital Network, VPDN 1320.
• SELCON is a physically secure, and information secure, guaranteed quality service, QOS, data communications network.
• SELCON is installed between the fulfilling member's location and the nearest the broker-to- broker system POP (point of presence) .
• POP point of presence
• SELCON comprises the internet. Access to SELCON may be controlled through the use of RSA Dynamics SecurlD 1300, 1305 which provides physical access token technology. Every individual at each fulfilling member who will use SELNET, must have an individual logon identity, and must be in possession of his/her unique SecurelD token.
• SELCON may be contractually prohibited by the broker-to-broker network operator in its agreements with the broker- to-broker system's customers. All data packets sent over SELCON may be encrypted using 128 bit SSL technology so as to ensure complete privacy and confidentiality of the information. SELCON is available in several different physical implementations depending on the volume and response characteristics required by the fulfilling member. In addition if and when broker-to-broker ' s customers use the value-added features of the broker- to-broker service, e.g. interactive voice messaging, they will need to upgrade the communications bandwidth to minimize adverse impact to the transaction components. A major consideration in the implementation of SELCON is to minimize propagation or latency delays . For occasional or light usage, i.e.
• a 56K V90 modem dial-up session should suffice.
• Dial-up connections may be used almost always to initially connect the broker-to- broker system 's customers into SELNET, whilst higher capacity is being installed.
• fulfilling members will most probably use dial-up connections in the less well developed countries where order volume will be small, and the telecommunications infrastructure is not developed and/or slow to respond.
• a 56/64Kbit ISDN dial-up session should suffice.
• ISDN or other high bit rate digital dial-up connections will be seen as the preferable alternative to analogue dial-up where the telecommunications infrastructure allows and/or the break-even point between dial-up and fixed line economics has not been reached.
• improved response times, and where on-line times cross the classic break-even point between dial-up and fixed-line, fixed or leased lines will need to be installed.
• the minimum fixed- line speed available for the broker-to-broker system may be 64Kbits/second. Higher speeds will need to be installed in proportion to the number of concurrent the broker-to-broker system sessions in use at the fulfilling member's location, and the response times which they wish to achieve.
• 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.
• TYPE OF ENTITY 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.
• TRANSACTION FEES 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.
• TRANSACTION SEQUENCING 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-tobroker 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 .
• BEST EXECUTION In most jurisdictions 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. (Ideally 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.
• SELECTING THE FULFILLING BROKERS 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.
• 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.
• PREFERRED SETTLEMENT ARRANGEMENTS 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 trade confirmations or advisories to either or both parties to the transaction.
• Such 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 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.
• ORDER PRE-REQUISITES 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 . elper . B2BConstants ; import com. sapien .helper . Self ; import com. sapient .helper . StatusReturn;
• LastActionBrokerld is set theOrderDetailElements. setLastActionBrokerld(theSelf .getBrokerld () ) ;
• OrderGTEIFO OrderGTEIFO
• OrderDetailElements theOrderDetailElements
• This method is used to withdraw a pending request. It firstly calls the WithdrawRequest on the Orderlnterface. If this call is successful, this method will then access the the OrderBean and call the WithdrawRequest method which will clear the request fields and recalculate the order status.
• OrderPK myorderRe erencePK new OrderPK(myOrderReferenceNumber) ;
• LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf . getBrokerld ( ) ) ;
• C CD ⁇ param StatusReturn This object is used to pass CA status data from method to method to indicate success or failure of certain processes.
• m jaram Self This object contains the Userld and Brokerld of the
• OrderDetailElements will contain all the order data c* that has been entered by the
• LastActionBrokerld is set theOrderDetailElements . setLastActionBro erld(theSelf.getBrokerld() ) ;
• AuditLogPr throw new LoggedException ( "CreateException caught : " +ex) ;
• OrderPK myorderReferencePK new OrderPK (myOrderReferenceNumber) ;
• LastActionBrokerld is set theOrderDetailElements . setLastActionBrokerld (theSelf . getBrokerld ( ) ) ;
• OrderDetailElements will contain all the order data that has been entered by the user as well as enriched information from the GTE such
• OrderPK myorderReferencePK new OrderPK (myOrderReferenceNumber) ;
• LastActionBrokerld is set theOrderDetailElements . setLastActionBrokerld (theSelf . getBrokerld ( ) ) ;
• LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf . getBrokerld ( ) ) ;
• 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.
• ⁇ param Self contains the Userld and Brokerld of the person who has logged into the system.
• CA OrderPK myorderReferencePK new OrderPK(myOrderReferenceNumber) ;
• LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf .getBrokerld () ) ; m try ⁇
• This object contains the Userld and Brokerld of the person who has logged into the system.
• This method is used to request a modification of an accepted order.
• CA OrderPK myorderReferencePK new OrderPK (myOrderReferenceNumber) ;
• I- OrderPK myorderReferencePK new OrderPK(myOrderReferenceNumber) ;
• LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld(theSelf .getBrokerld0 ) ; try ⁇
• OrderRequestElements will oj * contain all the order ' data
• LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf . getBrokerld () ) ;
• AuditLogProxy ( ) ) . logAction (theSelf . getBrokerld () ,Action. REJECT_REQUEST_MODIFY_ORDER, null , theOrderRequestElements . get
• OrderDetailElements will contain all the order data that has been entered by the m user as well as enriched
• LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf .getBrokerld () ) ;
• This method is used to accept sign off of an order.
• the acceptance of signoff is sent to the orderlnterface.
• This method in turn passes this signoff acceptance on to the GTE. It does this by calling the
• CA * ⁇ param Self This object contains the m * Userld and Brokerld of the
• OrderDetailElements will m * contain all the order data ro * that has been entered by the ⁇ > * user as well as enriched information from the GTE such as the order number, ⁇ exception none ⁇ return void
• OrderPK myOrderReferencePK new OrderPK (myOrderReferenceNumber) ;
• LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld (theSelf .getBrokerld () ) ,-
• CA * This method is used to reject sign off of an order. The rejection of
• LastActionBrokerld is set theOrderRequestElements . setLastActionBrokerld(theSelf .getBrokerld 0 ) ;
• I * 3 m O rderDetailElements object that contains all the order details. The details m * that are required can then be extracted from this.
• 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
• import com. sapient . order . OrderPK import com. sapient .order -OrderDetailElements; import com. sapient . interfaces .OrderGTEIF; import com . sapient . order . OrderExecutionElements ; import com. sapient. execution. ExecutionHome; import com. sapient .execution. ExecutionPK; import com. sapient .execution. Execution; import com. sapient, framework, ejb. common.HomeFactory; import com. sapient, framework, ejb. common.HomeFactoryException; import com. sapient. framework. logging. Logger;
• CA m /* m Enters a fill against the associated order.
• the order interface is called with all the required information for an execution.
• the associated order has an execution element set with all the user-entered details.
• CA new OrderGTEIF 0
• requestCancelExecution (myOrderExecutionElement) ; m , m try ⁇
• Enumeration executions executionHome. findByOrderld (orderld) ;
• OrderHome orderHome (OrderHome) HomeFactory.findHome ("com. sapient. order. OrderHome”) ;
• Order order orderHome. findByPrimaryKey(new OrderPK(anOrderld) ) ;
• OrderDetailElements details order.getOrderDetails () ;
• OrderHome orderHome (OrderHome)HomeFactory.findHome ("com. sapient.order.OrderHome”) ;
• Order order orderHome .findByPrimaryKey(new OrderPK(anOrderld) ) ;
• OrderDetailElements details order.getOrderDetails 0 ; myOrderExecutionElemen . setRequestReference (details .getRequestReference 0 ) ;

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)
• Multi Processors (AREA)

Priority Applications (6)

Applications Claiming Priority (2)

Publications (2)

Family

ID=22616450

Family Applications (1)

Country Status (3)

Cited By (1)

• 2000
  • 2000-10-31 EP EP00972993A patent/EP1242904A1/de not_active Withdrawn
  • 2000-10-31 WO PCT/GB2000/004180 patent/WO2001042949A2/en active Application Filing
  • 2000-10-31 AU AU11550/01A patent/AU1155001A/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events