A Straight-Through-processing (STP) trading platform provides a fully electronic and seamless solution to all substantially aspects of the trading cycle for fixed income instruments and other financial instruments. In an exemplary embodiment, all participants to a trade transaction have access to computer software that facilitates trade order management, trade order generation, trade execution (including electronic axes), trade allocation, allocation acknowledgement, trade confirmation, and finally acquisition of settlement instructions. In said exemplary embodiment, the STP trading platform includes computer software modules including at least an account management module and an electronic trading module to handle the various stages of executing a trade, confirming the trade, and facilitating settlement of the trade.
|
19. A method of validating a plurality of settlement instruction sets stored on an account database, the method comprising:
comparing information stored in the plurality of settlement instruction sets with a first information database;
determining whether an error in one or more of the settlement instruction sets exists; and
reporting the error to the appropriate party.
32. A system for effecting straight-through-processing of trades executed between a customer and a dealer, the system comprising:
a trade execution system including one or more computer systems capable of generating a trade order and executing a block trade between the customer and the dealer based on the trade order wherein the trade order includes a pre-allocation of customer accounts;
an account database for storing one or more account information records that are accessible by the trade execution system, the account information records being associated with one or more settlement instruction sets; and
wherein the trade execution system is operative with programming to:
store a block trade record including details of the block trade executed on the trade execution system;
generate an allocated trade record associated with the block trade record for each pre-allocation of customer accounts;
receive an indication that the allocated trade records are confirmed;
enrich the allocated trade records by incorporating one of the settlement instruction sets into each of the allocated trade records; and
transmit each of the enriched allocated trade records to an appropriate clearing institution.
18. An electronic trading system for effecting and clearing trades between customers and dealers comprising:
a processing system including one or more servers capable of communication via a network;
an account database capable of communication with the processing system via the network, the account database configured to store account information for each of the customers, each of the sub-accounts being mapped to a corresponding set of settlement instructions; and
a trade history database for storing details of trades effected and cleared on the electronic trading system;
wherein the processing system is operative with a trade execution module to process trades between a customer and a dealer, and wherein the processing system is further operative with an account management module to permit customers to make sub-account allocations of the trades, the processing system generating one or more trade tickets for each sub-account allocation and, in response to an acceptance indication received from a dealer, enriching the trade tickets with settlement instructions stored in the account database, the processing system generating an electronic confirmation in accordance with government regulations and presenting the electronic confirmation to the customer and dealer.
1. A system for effecting straight-through-processing of trades executed between a customer and a dealer, the system comprising:
a trade execution system including one or more computer systems capable of generating a trade order and executing a block trade between the customer and the dealer based on the trade order wherein the trade order includes a pre-allocation of customer accounts, the trade execution system in communication with one or more customer computer systems and dealer computer systems having software operable thereon for permitting communication of trading data through the trade execution system;
an account database for storing one or more account information records that are accessible by the trade execution system, the account information records being associated with one or more settlement instruction sets; and
wherein the trade execution system is operative with programming to:
store a block trade record including details of the block trade executed by the customer and the dealer;
generate an allocated trade record for each of the account allocations received from the customer computer system, each of the allocated trade records being associated with the block trade record;
receive an indication from the dealer computer system that the allocated trade records are confirmed;
enrich the allocated trade records by incorporating one of the settlement instruction sets into each of the allocated trade records; and
transmit each of the enriched allocated trade records to an appropriate clearing institution.
2. The system of
3. The system of
4. The system of
5. The system of
6. The system of
7. The system of
8. The system of
receive customer-initiated trade inquiries including pre-allocation of sub-accounts directed to one or more dealers;
transmit the customer-initiated trade inquiries to the dealer computer system of the one or more dealers;
receive a trade price from at least one of the dealer computer systems;
transmit the trade price to the customer computer system;
receive from the customer computer system an indication that the trade price is accepted; and
execute a block trade at the accepted trade price.
10. The system of
receive dealer-initiated trade inquiries, including at least the type of financial instruments to be traded, the price, and settlement details, directed to one or more customers;
transmit the dealer-initiated trade inquiries to the customer computer system of the one or more customers;
receive from at least one of the customer computer systems an indication that the trade price is accepted; and
execute a block trade at the accepted trade price.
11. The system of
12. The system of
13. The system of
14. The system of
15. The system of
receive block trade details corresponding to a trade executed by the customer and dealer.
22. The method of
23. The method of
24. The method of
initiating an axe generation module;
inputting axe details into an interface provided by the axe generation module;
generating an electronic axe trade ticket wherein the axe trade ticket is actionable by the customers for a quantity up to a total axe quantity or only for the total axe quantity;
transmitting the electronic axe trade ticket to the one or more selected customers;
receiving an indication from at least one of the selected customers that the axe details in the electronic axe are acceptable.
25. The method of
26. The method of
27. The method of
28. The method of
receiving the indication that the axe details in the electronic axe are acceptable;
executing an axe trade based on the axe details;
receiving an allocation from the customer for the axe trade;
generating electronic trade tickets for each allocation of the axe trade;
enriching the electronic trade tickets with settlement instructions; and
generating an electronic confirmation.
30. The method of
detecting a first indicia of the trade; and
accessing the appropriate account information record and determining the appropriate settlement instruction set using the first indicia.
31. The method of
detecting a second indicia of the trade if the appropriate settlement instruction set cannot be determined using the first indicia; and
accessing the appropriate account information record and determining the appropriate settlement instruction set using the first indicia and the second indicia.
|
|||||||||||||||||||||||||||||
This application claims priority to U.S. Provisional Application Ser. No. 60/457,845, filed on Mar. 25, 2003, the entire disclosure of which is incorporated herein by reference.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention relates generally to electronic trading methods and systems and, more particularly, to electronic trading methods and systems that provide straight-through processing.
2. Description of Related Art
Fixed income instruments, such as treasuries, mortgages, commercial paper offerings, corporate and government bonds, and the like, traditionally have been traded using an inefficient, error-prone manual process. Recently, the market for fixed income instruments has undergone a certain degree of automation. While such automation represents an improvement to the manual process, many of the problems and inefficiencies associated with the traditional, manual process still exist.
To summarize the manual process, a customer desiring to buy or sell a fixed income instrument first would make an inquiry, or a request for a quote, to a dealer that is willing to buy and sell such as principal. The customer may be any person or entity desiring to trade but generally refers to buy-side institutions, such as investment funds, institutional investors, money market funds, and mortgage brokers to name a few. The dealer generally is any person or entity that is registered with the Securities and Exchange Commission (SEC) or an equivalent non-U.S. regulator to deal (i.e., to make a market for) financial instruments for its own account (at its bid price) or sell from its own account (at its ask or offer price). In the past, to initiate the manual trading process, a customer would make an inquiry, for example, via the telephone or facsimile transmission. Frequently, the customer would make an inquiry to several dealers with which the customer has a relationship before identifying a dealer willing to trade in the desired instrument. Because the manual process required the customer to telephone each of the dealers individually, the process of requesting price quotes could take several minutes during which time the market may have moved against the customer. Once the customer identified an acceptable dealer the customer and dealer would verbally agree to the negotiated price for the desired fixed income instrument and execute the trade.
Upon verbal agreement, both the customer and dealer would manually write the trade details on a trade ticket. A trade ticket typically comprised several layers of carbon paper, such that at least one layer could be passed to the back office personnel responsible for confirming trades. These processes are prone to error due to the manual nature of the recordation process. In this case, the trade details may be electronically transmitted to back office systems operated by personnel responsible for confirming trades.
Executing the trade, however, is only part of the trade cycle. Back office functions, such as confirmation, allocation and settlement, were also performed manually. Rule 10b-10 under the Securities Exchange Act of 1934 (“Rule 10b-10”) and equivalent non-U.S. rules relating to confirmation and clearance of trades require that a dealer provide certain written disclosures to a customer immediately after the completion of a transaction to confirm the trade. In order to create the Rule 10b-10 confirmation, the dealer would manually extract the details of the trade, such as those passed on the trade ticket, and create a paper confirmation—an inefficient process prone to potential human error.
As for allocation, the customer, if trading on behalf of several client accounts, would have to transmit allocation instructions to the dealer regarding the financial instruments being bought or sold to any of the number of different sub-accounts. More specifically, a customer entering into a large block trade on behalf of several accounts would provide allocation instructions to the dealer, for example, via the telephone or via facsimile. Again, this manual process was open to human error, not only in providing and recording the proper instructions, but also in propagating the correct instructions to the other back office personnel responsible for other functions, such as confirmation and settlement.
In order to settle allocated trades, a customer would deliver settlement instructions (e.g., Central Securities Depository (CSD) settlement data, including the CSD address, swift codes, ABA number, account number and account name) to a dealer via facsimile or telephone. The dealer would manually input this information into their internal systems to generate the confirmation and to facilitate clearance and settlement of the securities traded. Following the customer's approval of the information, the dealer would provide the trade details and settlement instructions to the relevant clearing agency to effect settlement of the trade. Similar to the trade execution phase, there was no direct link between customers, dealers, and clearing institutions to exchange trade details and settlement instructions during the settlement process. Thus, the manual trading and settlement process was prone to errors and often took several days to complete.
The traditional manual process recently has given way to electronic trading systems as mentioned above. In general, although the electronic trading systems have several advantages over the manual process, such electronic trading systems have focused on the discreet parts of the trading cycle and, consequently, suffer from a lack of compatibility and interoperability. Furthermore, existing electronic trading systems, in large part, simply automate the manual process and thereby perpetuate the inefficiencies of the manual process and fail to provide needed new functionality. As discussed below, because existing electronic trading systems lack compatibility across the various stages of the trade cycle and fail to automate key post-trade functions, existing systems have failed to eliminate significant sources of error and inefficiencies.
More specifically, because electronic trading systems are directed to discreet parts of the trading cycle, such systems do not adequately provide a means to achieve straight-through processing (STP) of trades, namely, to execute block trades, allocate block trades to sub-accounts, confirm the trade, details, allocations and settlement instructions, and settle the trades based on such information. Absent custom-built communication interfaces, a system directed to one aspect of the trade cycle typically cannot automatically pass recoded information to a system directed to another aspect of the trade cycle. Thus, the information must be manually duplicated and re-entered at various points during the trading cycle.
For example, even where a dealer uses an electronic trading system to effectuate a trade, the dealer must manually input details of the trade into a separate back office system in order to generate confirmations and facilitate the settlement process. As a result, the post-trade confirmation and settlement process remains open to possible human error, even where electronic trading systems are used. Moreover, typical electronic post-trade allocation confirmation systems are often incompatible with electronic settlement instruction databases and systems that provide trade details regarding trades executed in non-electronic formats, such as via telephone, thereby forcing dealers to maintain redundant systems. Although an improvement to traditional manual processes, unnecessary duplication of records and potential delays with delivery of trade details, allocations, confirmations and settlement instructions and in the settlement of trades still exist.
Similarly, although many market participants have begun using electronic back office trade management systems, such systems are typically incompatible with front office electronic trade execution systems. Thus, even if a trade is executed electronically, the trade details must be manually input into the various back office systems. In short, the electronic trade allocation and settlement of fixed-income instruments remains a fractured process that is subject to inefficiencies and errors and prevents efficient straight-through-processing of trades.
Furthermore, efficiencies provided by existing electronic trading systems are typically limited to only a portion of a dealer's or customer's trading volume. Dealers frequently enter into trades via more than one electronic system and over the phone. These electronic systems, while providing increased efficiency for trades conducted on each system, are incompatible with each other and with manual processes, making it impossible to recognize a benefit of one system across all phases of the trading cycle. Indeed, such disparate systems can add to the complexity and inefficiency of management of a customer's or dealer's entire trading volume.
The inefficiencies of existing electronic systems are further exacerbated due to the lack of uniformity across market participants. Because trades must be accepted and confirmed at least by the two parties to the trade (and sometimes third and fourth parties), and because different parties often utilize incompatible systems, there is presently no system available that can process trades from generation to execution to allocation to confirmation and finally to settlement to achieve true straight-through processing of trades.
In addition to incompatibility among electronic trading systems limiting their effectiveness, existing electronic trading systems simply have automated the traditional, manual process without changing the general trading-cycle paradigm and without adding new features to enhance the usability or efficiency of the systems. As such, the existing electronic trading systems have many of the inherent inefficiencies as the manual trading.
Thus, a need exists for a system and method for effecting straight-through processing of trades and, more particularly, for a system and method for enabling electronic execution of trades, an electronic allocation and acceptance system that is integrated with a standing settlement instructions database, such that settlement instructions can be propagated throughout the trading cycle to reduce the possibility of costly and time consuming error inherent in the tradition manual process.
Furthermore, there is a need for a system and method for generating electronic trade confirmations that conform to regulatory standards to permit the virtually seamless execution, allocation, acceptance, confirmation and settlement of trades.
Moreover, because most existing fixed-income electronic trading systems merely implement the traditional customer inquiry-based and inventory-based trading paradigms, such electronic trading systems do not provide a means for permitting dealers to initiate trading by transmitting executable, firm trade offers. In the industry, a message from a dealer to a customer regarding a trade is commonly referred to as an “axe.” Presently, dealer axes are communicated to customers via telephone or some other electronic based messaging system, such as through Bloomberg L.P.'s BLOOMBERG PROFESSIONAL® service, electronic mail, or an electronic indication of interest (IOI system). These systems, however, are inefficient for the transmission of axes for several reasons. Such systems do not permit the transmission of executable axes that are actionable by one or more customers to execute a trade. Thus, a need exists for trading systems and methods that provide increased liquidity and, more particularly, that allow dealers an improved means for initiating trades.
Various embodiments of the present invention satisfy the foregoing, as well as other needs. More specifically, such embodiments generally relate to an electronic trading platform that provides straight-through processing (STP) of various financial instruments, including, but not limited to, liquid fixed-income instruments. The STP trading platform (e.g., systems and methods) described herein overcomes the shortcomings of present trading systems and methods for the trading, allocation, confirmation and settlement of fixed income instruments.
In an exemplary embodiment of the present invention, the STP trading platform has the ability to execute trades, dynamically allocate trades according to customer instructions, confirm the trade details and allocations and provide accurate settlement instructions for the trades using a centralized database of standing settlement instructions.
The STP trading platform also is capable of generating electronic confirmations to facilitate confirmation and settlement of trades. Further, the STP trading platform is capable of leveraging it unique position as a centralized trading, allocation confirm the trade details and allocations and settlement platform to provide customers and dealers with advanced reporting of various industry and trade data. As will be appreciated by those skilled in the art, the STP trading platform permits participants to initiate trade inquires, execute trades, allocate trades to sub-accounts, confirm the trade details and allocations and electronically confirm trades, so as to eliminate the need to manually input and re-input trade data in multiple systems designed to handle only one aspect of the trading cycle. Moreover, by maintaining a centralized database of standing settlement instructions, the described STP trading platform reduces the possibility of trade failures due to inaccuracies in the provisions of settlement instructions between customers and dealers. Thus, the standardized and integrated approach of the STP trading platform both streamlines and comprehensively improves the trading process. Due to integration of such functionality, the trading platform also provides an electronic, paperless solution for the entire trading cycle, including trade order generation, trade execution, trade allocation, allocation and trade detail acknowledgement, electronic trade confirmation, and access to standing settlement instructions to facilitate settlement of trades.
Certain embodiments described herein further satisfy the needs of the dealers to initiate binding electronic trade inquiries (or electronic axes). The binding electronic axe functionality of such embodiments adds an additional layer of liquidity for dealers who traditionally could only initiate actionable trades via the Interdealer Broker market, which is comprised solely of other dealers and is conducted in an anonymous manner (as compared to the dealer-to-customer fully disclosed model). Thus, by permitting dealers to initiate trade inquiries in an efficient and binding manner, the dealer has access to an additional layer of market liquidity, while its customer base is afforded the opportunity to see real-time, firm market prices—information a composite pricing matrix can only approximate.
In an exemplary embodiment, the STP trading platform comprises one or more software applications operative on a server system, along with data storage devices and communication devices, to achieve straight-through processing of the entire trading cycle.
Participants to a transaction have access to computer software that facilitates trade order management, trade order generation, trade execution (including electronic axes), trade allocation, allocation and trade details acknowledgement, trade confirmation, and finally acquisition of settlement instructions. In the exemplary embodiment presently being described, the STP trading platform includes computer software modules including at least an account management module, an electronic trading module, and a back office management module. The operation and functionality of these modules is discussed below.
Thus, as is evident from the above-description, the STP trading platform integrates various software modules and communication links to process the originating execution, allocation, acknowledgement of allocation, and trade details electronic confirmation, and enriching details with settlement instructions of trades. Additional features and advantageous of the system are described further below.
In an exemplary embodiment, as shown in
The Trading Cycle
A summary of the trading cycle will now be described. The typical trading cycle begins with traders for customers accessing indicative market pricing feeds, although, as described below, trades can be initiated through an internal order management system. Indicative market pricing feeds or composite price matrices, such as those shown and described herein, generally receive near real-time indicative pricing data from dealers. The price data is then input into a software algorithm to generate the composite price screen. The operation of the composite price algorithm is not critical to the present invention and, therefore, specifics of the algorithm are not discussed. The composite price screens are generated by the software algorithm operative of the STP trading platform servers (shown in
With reference to
In general, the STP trading platform 100 operates according to an inquiry-based trading environment. Thus, typically, a customer desiring to buy or sell financial instruments makes an electronic inquiry of one or more dealers for prices at which the instruments can be bought or sold. Because multiple dealers may be competing against one another, this type of inquiry is sometimes referred to as competitive auction-based inquiry. In other instances, for example, in the case of commercial paper offerings (CPOs), the STP trading platform 100 may be configured to operate according to an inventory-based trading environment in which dealers post inventories of various financial instruments from which customers can make purchases.
In the exemplary embodiment being described, dealers interact with a dealer-side software client 270 operative on the dealer system 260. Operating in connection with the electronic trading module 160 of the STP trading platform 100, an electronic trading component 275 of the dealer-side software client 270 permits dealers to receive trade inquiries from customers, create axes, manage the provision of market prices to customers in response to the inquiries through the STP trading platform 100, execute trades, receive customer allocations, confirm trade details and allocation instructions, generate confirmations, and perform other back office tasks.
Traders for the selected dealers receive inquiries through the STP trading platform 100 into the electronic trading component 275. The electronic trading component 275 operates to display customer-initiated inquiries on a graphical interface that provides dealers with the ability to input the requested bid/ask prices into an electronic trade ticket and transmit the prices to the customer. Dealers must typically present both bids and offers to customers so that customers can select to trade either side of a transaction. For instance, the dealer must provide bids that represent the price at which the dealer is willing to purchase a particular financial instrument from customers. Similarly, the dealer must post offers (or ask prices), which are the price at which the dealers are willing to sell particular financial instruments to customers. Moreover, according to known trading rules, dealers must make the prices they post firm for several seconds and, thus, the dealers will post prices “on the wire” for several seconds. If the customer selects a particular dealer's price while there is “on the wire” time remaining, then the dealer must honor the firm price and the transaction will automatically be accepted. A trade performed after the “on the wire” time has expired may be accepted or rejected at the dealer's sole discretion. Prior to a trade being performed after the “on the wire” time has expired, the dealer may refresh its trade price and reset the “on-the-wire” time.
Through a trade ticket interface (shown and described below) displayed by the dealer-side electronic trading component 275, dealers can provide market prices in response to customer inquiries and set specific “on the wire” time periods. Upon creation of a dealer price offer, an electronic message is created and an identifier is mapped to the dealer price offer so that a record of the offer can be stored in the trade history database 115 of the STP trading platform 100. The live market dealer price and “on the wire” time period is transmitted through the electronic trading module 160 of the STP trading platform 100 to the customer's computer 200 and displayed by the customer-side electronic trading component 215. Thus, the customer can see the selected dealers' prices, along with a countdown of “on the wire” time. Through the customer-side electronic trading component 215, the customer can “hit” a bid or “lift” an offer to initiate the purchase or sale, as applicable, of the selected financial product. This functionality is performed electronically, as described further below.
The STP trading platform 100 may also be configured to process trades executed on systems other than through the electronic trading module 160, such as trades executed via telephone or by an alternate electronic trading system. Trade details from alternate systems are electronically imported into the STP trading platform 100 so as to provide the straight-through-processing functionality described herein for trades executed using these alternate methods. Trade data regarding transactions effected on other systems is imported by dealers into the STP trading platform 100 using application programming interfaces (APIs) that link the two systems and through data transfer using standardized (e.g., FIX format) or customized formats, as described further below.
Further, in the exemplary embodiment, the STP trading platform 100 permits dealers to initiate trade inquiries using the dealer-side electronic trading component 215. Such dealer-generated trade inquiries are referred to as electronic axes. A dealer using axe generation functionality can input the material terms of an offer to trade a particular instrument. Unlike present systems that permit only non-executable messages, the dealer can set an “on the wire” time during which the trade will be accepted by a selected customer or group of customers at the dealer's terms. Once an electronic axe is created, the dealer can communicate the electronic axe using the STP trading platform 100 to one or more selected customers. If a customer accepts a dealer electronic axe, the trade is executed in the same manner as customer initiated inquiries.
After a transaction is effected through the electronic trading module 160 of the STP trading platform 100, or through an alternate electronic trading system or via telephone and imported into the STP trading platform 100, the customer may make any necessary account allocations to block trades. The functionality to allocate block trades to the customer's sub-accounts is provided through integration of the electronic trading module 160, along with the customer-side electronic trading component 215, and the account management module 120 and associated account management database 110. The account management module 120 includes, at least in part, an account management database 110 for the storage and maintenance of account and sub-account information for each of the customers' client's accounts. By selecting the “breakdown” functionality provided by the electronic trading module 160 and customer-side electronic trading component 215, the customer's account information can be retrieved from the account management database 110. A breakdown interface provided by the customer-side electronic trading component 215 is populated by account information retrieved from the account management database 10, which includes at least a sub-account database. Thus, through integration of the electronic trading module 160 and the account management module 120, the customer is provided functionality to selectively allocate the block trade to one or more sub-accounts. Once block trades are allocated, the customer-side electronic trading component 215 of the electronic trading module 160 can generate an allocation ticket for each allocation of the block trade. Thus, in essence, each allocation is treated for the purposes of allocation acknowledgement, electronic confirmation and settlement as a separate allocation ticket. Each allocation ticket contains an identifier that permits the electronic trading module 160 to store a data record for each allocation ticket in the trade history database 115. The allocation ticket also may contain an identifier linking it to the original block trade executed between the parties.
The electronic trading module 160 of the STP trading platform 100, through integration with the account management module 120, also has the functionality to permit the allocation of trades through the use of integrated inter-systems or order management systems of the customer. As will be discussed in greater detail below, the STP trading platform can be, and preferably is, communicatively linked to the internal systems of customers and dealers. As an example, many customers operate order management systems (“OMS”) (shown in
At this point, the trade details, which may include a summary of the block trade and the account information for the allocation, if applicable, may be enriched through interaction with the account management database of the STP trading platform 100. In the exemplary embodiment, the account management database 110 stores standing settlement instructions pertaining to each of the customer accounts. Thus, during the process of transmitting the trade details and allocations, if any, to the dealer-side computers 260, the electronic trading module 160 accesses the account management database 115 to retrieve the standing settlement instructions for each designated account of the trade, and adds the instructions to the trade details.
It should also be understood that the STP trading platform 100 is designed to record and store in the trade history database 115 a historical record of all transactions executed, including a historical audit trail of all phases of the trade cycle, to thereby facilitate problem resolution should any issues or disputes arise.
The confirmation process may also be performed on the STP trading platform 100. According to the exemplary embodiment, the STP trading platform 100 provides dealers with the ability to have confirmations electronically generated and transmitted to customers through the STP trading platform 100 in a manner that would satisfy the requirements of applicable government regulations, such as SEC Rule 10b-10. For transactions effected through the STP trading platform 100, the transaction information contained in the confirmation is based on the terms of the transaction that have been agreed to between the customer and the dealer over the STP trading platform 100.
Upon electronic receipt of the trade details, including any allocations and the associated settlement instructions, dealers can confirm that the trade details and the records of the customers are accurate. If the dealer determines that the details of the customer's allocations are accurate, then the dealer can acknowledge the allocation via the STP trading platform 100. The STP trading platform 100 then dynamically generates an electronic confirmation in accordance with applicable government regulations, for example, SEC Rule 10b-10, to facilitate the electronic confirmation of trades. As discussed above, the STP trading platform 100 is also preferably adapted to handle the processing and confirmation of trades executed either via telephone or via an alternate trading system.
For trades made on alternate trading systems, such as dealer trade management system 279 or via telephone, the confirmation is based on transaction information that is electronically imported into the STP trading platform 100 by the dealer and affirmed by the applicable customer. In each case, the affirmation reflects any allocation among sub-accounts that has been made by the customer and accepted by the dealer.
Further, in the exemplary embodiment, both the customers and dealers are provided access through a back office management module 140 of the STP trading platform 100 to a master trade blotter interface, as well as various other summary interfaces. On the customer-side, the summary interface preferably displays trade information on a dealer-by-dealer basis. The summary information preferably includes the number of trades, the number of trades cancelled or corrected, the number of block trades allocated or unallocated, the number of tickets generated, the number of trades confirmed or unconfirmed, and the number of trades for which there are errors. This summary interface allows back office personnel to quickly and efficiently determine whether any executed trades have outstanding issues that require attention. Similarly, the dealer-side has access to summary trade information on a customer-by-customer basis.
System Architecture
In an exemplary embodiment, as shown in
In the exemplary embodiment, the client-side software application components 210, such as the customer-side electronic trading and back office management components 215, 220 and dealer-side electronic trading and back-office management components 275, 280 are preferably “thin-clients”. With respect to client/server applications, the term “thin-client” generally refers to a software client designed to be relatively small so that the bulk of the data processing occurs on the server. In the exemplary embodiment of the STP trading platform 100, the customer and dealer electronic trading and back office management components 215, 220 and 275, 280, respectively, are relatively small software applications capable of generating graphical user interface templates on the customer and dealer computers, such as the exemplary graphical user interface templates shown in
Generally speaking, the electronic trading module 160 is operative on the STP trading platform servers 105 to communicate with and provide functionality to the dealer-side and customer-side electronic trading components, which generate and display graphical user interfaces that are populated by information communicated from dealers (e.g., live market pricing data) and retrieved from the account management database 110 (e.g., account information and settlement instructions), as described further below.
The account management module 120 is also preferably a server-side software application operative on the STP trading platform servers 105 and accessible by customer and dealer computers 200, 260 via a communications network 50, such as the Internet. In the exemplary embodiment, the account management module 120 is database management software programmed with graphical interfaces to provide a web-based program that can display information retrieved from the account management database 110 via the Internet and create, update, modify or delete, as applicable, account records including settlement instructions. Via known communications networks, customers and dealers can access their accounts through the account management module 120 of the STP trading platform 100. Through integration of the STP trading platform modules 120, 140, 160, the account management database 110 is also accessible by the electronic trading module 160 so as to permit the electronic trading module 160 to retrieve information from the account management database 110, when necessary.
Customer and dealer computers 200, 260 are any type of personal or network computer such as an IBM-compatible computer running an Intel chipset and having an operating system, such as Microsoft® Windows® NT, 2000, XP, and the like, and, preferably, running a browser program such as Microsoft® Internet Explorer or Netscape Navigator®. It is also within the scope of the present invention that computers 200, 260 may be handheld or table computing devices, such as a personal digital assistant (PDA), pocket PC, and tablet PC, or the like. Customer computers 200, 260 have access to a communications network via a modem or broadband connection to permit data communication between the participants and the STP trading platform 100.
Various input and output devices are preferably provided with the customer and dealer computers 200, 260 including, by way of non-limiting example, a display (e.g., cathode ray tube (CRT), liquid crystal display (LCD), etc.), and an input device (e.g., a keyboard, mouse, touch pad, or light pen). The customer and dealer computers 200, 260 would also preferably include a storage device such as, for example, a magnetic disk drive and magnetic disk, a CD-ROM drive and CD-ROM, DVD, or other equivalent device. The specific hardware combination/configuration is not crucial to the instant invention, and may vary as a matter of design choice within the functional parameters disclosed herein. Users of the STP trading platform 100 typically interact with the GUI's displayed by the software modules by “clicking” on numbers or graphics (e.g., buttons) that are displayed on the GUI's. Persons of skill will understand that the present invention is not limited to clicking with a computer mouse, but includes use of any other device for indicating an action with graphics-based software, such as a touch pad, light pen, touch sensitive display screen and the like.
The STP trading platform servers 105 may be computer servers of any type known in the industry, but capable of handling the flow of data on a substantially real-time basis. Moreover, persons of skill will recognize that multiple servers in a server farm arrangement may be utilized to handle the bandwidth and processing requirements of a particular arrangement of the present invention.
Trade history databases 115 and account management databases 110 are controlled by the software modules 120, 140, 160 to retrieve data, when necessary. The storage devices themselves may be any mass storage devices capable of storing large amounts of data in an organized fashion, such as known data storage devices including, but not limited to hard disks, tape drivers, optical disks and the like.
Communication between the customer-side, dealer-side and the STP trading platform 100 may be accomplished via electronic messaging using the Extensible Mark-up Language (“XML”) or Financial Information Exchange (“FIX”) format. In order for customer-side and dealer-side computers 200, 260 to communicate with the STP trading platform 100, an API is provided to enable users to establish connections to the STP trading platform 100, authenticate their systems, and exchange messages using, for example, the XML-based messaging protocol. By way of non-limiting example, Table I that follows illustrates exemplary messages that may be used during the flow of the trading cycle.
TABLE I
EXEMPLARY MESSAGES
Message Type
Fields
Components
PlaceOrder
OurOrderRef
Alphanumeric ID code
YourOrderRef
Alphanumeric ID code
OldOrderRef <required if Type = correct>
Alphanumeric ID code
TransactTime <time stamp for order>
YYYYMMDD:HH:MM
Type
+new
+correct
Order
+side
+buy
+sell
+Quantity = non-negative integer
+Instrument (see Table II)
+Settlement (see Table II)
+StipulationList
+AllocationList (if breakdown provided)
+Account ID
+Quantity = non-negative integer
+ClearingLoc (if non-US)
+ClearingLoc (if non-US)
OrderList
+OrderLegRq (if swap)
+side
+buy
+sell
+Quantity = non-negative integer
+SwapType
+Instrument (see Table II)
+Settlement (see Table II)
+StipulationList
+AllocationList (if breakdown provided)
+Account ID
+Quantity = non-negative integer
+ClearingLoc (if non-US)
+ClearingLoc (if non-US)
OrderType
+auction
+customer price
Price <if OrderType=customer price>
+type
+percent
+yield
+YieldType (maturity)
+value
+discount
+premium
+spread
+value
+NormalValue
Capacity
+agent
+principal
Trader <email address of trader>
String text
Allocate
OurOrderRef
Alphanumeric ID code
YourOrderRef
Alphanumeric ID code
Type
+new
+correct
TransactTime <time stamp for order>
YYYYMMDD:HH:MM
OurAllocationRef
Alphanumeric ID code
OldAllocationRef <required if Type = correct>
Alphanumeric ID code
ExecutionNotificationRef <system ID>
Alphanumeric ID code
Trade
+side
+buy
+sell
+Quantity = non-negative integer
+Instrument (see Table II)
+Settlement (see Table II)
+Price (see above)
+Dealer (BIC)
+TradeDate (YYYYMMDD)
AllocationList
+AllocationList
+Account ID
+Quantity = non-negative integer
+ClearingLoc (if non-US)
Booking
NotificationRef
Notification
OurOrderRef
Alphanumeric ID code
YourOrderRef
Alphanumeric ID code
Type
+new
+correct
TransactTime <time stamp for order>
YYYYMMDD:HH:MM
YourAllocationRef
Alphanumeric ID code
Status
+BookingStatus
+Affirmed (y/n)
+UnknownAccount (y/n)
+MissingInstructions (y/n)
+Canceled (y/n)
+Other (string)
Trade
+TradeBk
+side
+buy
+sell
+Quantity = non-negative integer
+Instrument (see Table II)
+Settlement (see Table II)
+StipulationList
+Account ID
+ClearingLoc (if non-US)
+Price (see above)
+PrincipalAmount
+AccruedInterest
+NetMoney
+Dealer (BIC)
+Market (BIC)
+TradeDate (YYYYMMDD)
TABLE II
EXEMPLARY COMPONENT CLASSES
Type
Fields
Components
Instrument
SecurityID
+SecurityIDType
+CUSIP
+ISIN
+Private
+Code (string)
Description (string)
n/a
Currency
+ISO-4217 values
AmortizableInstrument <<implementation class>>
+Product
+MORTGAGE
+Security
+MBS
+PFAND
+Issuer (string)
+Country (ISO-3166 values)
+Coupon
+Issued (YYYYMMDD)
+Maturity (YYYYMMDD)
+Factor
CouponInstrument <<implementation class>>
+Product
+GOVERNMENT
+AGENCY
+CORPORATE
+Security
+CORP
+EUCORP
+EUSOV
+EUSUPRA
+FAC
+SUPRA
+TCAL
+TINT
+TPRN
+UST
+Issuer (string)
+Country (ISO-3166 values)
+Coupon
+Issued (YYYYMMDD)
+Maturity (YYYYMMDD)
+WhenIssued (Boolean)
DiscountInstrument <<implementation class>>
+Product
+GOVERNMENT
+AGENCY
+MONEYMARKET
+Security
+CP
+EUCP
+FADN
+USTB
+Issuer (string)
+Country (ISO-3166 values)
+Coupon
+Issued (YYYYMMDD)
+Maturity (YYYYMMDD)
+WhenIssued (Boolean)
FutureInstrument <<implementation class>>
+Product
+MORTGAGE
+Security
+TBA
+Issuer (string)
+Country (ISO-3166 values)
+Contract (YYYYMMDD)
Settlement
SettlementType
+Cash
+Regular
+NextDay
+T2
+T3
+T4
+T5
+WhenIssued
+Future
Date
YYYYMMDD
With respect to the exchange of messages between the customer-side, dealer-side, and STP trading platform 100, persons of skill in the art will recognize and understand the various message types being communicated across the system in light of the discussion of trade execution, allocation, confirmation, and settlement on the STP trading platform 100 in connection with the various screen shots and data flow diagrams. Persons of skill will also recognize that the particular structure of the messages and the preferred use of XML messaging is not necessary and alternate methods of messaging may be utilized.
Persons of skill in the art will further recognize that the exemplary system architecture shown and described herein may be modified in various manners so as to achieve the functionality set forth herein. Moreover, the particular layout or look and feel of the GUI's depicted in
System Functionality
The above described account management, electronic trading, and back office modules 120, 140, 160 are configured to operate and the customer and dealer electronic trading and back-office management clients 215, 220 and 275, 280, respectively, on the trading platform servers 105 and databases 110, 115 act cooperatively to provide a solution for various aspects of the typical trading cycle. An exemplary embodiment of customer and dealer interaction with the STP trading platform 100 is described below in connection with
1. Account Management
Prior to initiating a trade, a customer may access the account management module 120 of the STP trading platform 100 so as to input information to create, maintain, and update sub-accounts for allocation of block trades and to enter standing settlement instructions to facilitate electronic settlement of executed trades in accordance with an exemplary embodiment of the present invention. The STP trading platform 100 is operative with the account management database 110 to act as a centralized account management database for customers, dealers, custodians, and agent bank accounts and sub-accounts, and to store standing settlement instructions for said customers, custodians, and agent banks.
In the exemplary embodiment, the account management module 120 is operative to create a web-based environment through which users can access settlement and account data, and manage standing settlement instructions. The account management module 120 also preferably performs account validation, as described further below.
For example, according to the recently enacted the U.S.A. PATRIOT ACT (the “United and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act”), accounts in the United States must have a Tax ID number. The account management module 120, therefore, requires a Tax ID number to be entered for any account created in the United States.
Moreover, to accomplish field level validation, the account management module 120 is programmed to ensure that particular fields require particular types of information. For example, with reference to
In an exemplary embodiment, the account management database 110 also stores standing settlement instructions using a standardized and field level validated data structure. With reference again to
As a result of the standardization and validation performed by the account management module 120 in the creation and input of accounts, customers and dealers have access to an accurate and centralized depository of account and sub-account information and associated settlement instructions. When a customer updates, creates anew, or modifies an account or settlement instruction, the changes will be almost immediately available to all participants that the customer has enabled to view such settlement instructions, thereby streamlining the process of updating account information and eliminating the need for duplicative systems and processes. Moreover, because the selected participants have access to the same information, errors can be detected and corrected more efficiently. As will be described further below, integration of the account management module 120 and database with the electronic trading module 160, and back office management module 140 provides the functionality for straight-through-processing of trades throughout the entire trading cycle.
In an alternate embodiment as shown in
In the exemplary embodiment, the settlement instruction templates are divided into two sections: settlement instructions detail fields entered by users (upper portion of settlement instructions screen), and settlement template/model attributes defined by the user in the settlement profile/template master (lower portion of settlement instructions screen). The settlement template/model attributes (lower portion of settlement instructions) indicates the settlement instruction general criteria (market/country, depository/PSET, and security/cash type) counterparties can utilize to search for desired settlement instructions. The account management module 120 automatically populates this information (based on user settlement profile/template master settings) at the bottom of every settlement instruction.
With reference to
With reference to
2. Trade Execution—Customer Initiated Inquiries
With reference now to
TABLE III
EXEMPLARY NEW ORDER MESSAGES
Message
FIX
Type
Fields
Tag
New
ClOrderID <customer assigned order ID>
11
Order
TransactTime <time stamp for order>
60
HandlInst <Required by FIX protocol>
21
TimeInForce
59
Symbol <FIXED>
55
Side <buy/sell>
54
OrderQty <par value order size>
38
SecurityID <CUSIP/ISIN>
48
IDSource <CUSIP=1, ISIN=4>
22
Product <high level security class code; e.g.,
6613
Gov't Treasuries = GOVERNMENT
Gov't Agencies = AGENCY
Mortgage-Backed = MORTGAGE
Corporate Bonds = CORPORATE>
SecurityType <security classification; e.g.,
6609
CORP = Corporate Bonds
CP = Commercial Paper
MBS = Mortgage-Backed Securities
TBA = TBA Mortgages
UST = US Treasury Note/Bond
CouponRate <percentage>
223
MaturityDate <YYYYMMDD>
6637
IssueDate <YYYYMMDD>
6620
ContractSettlmntMonth <used for TBAs>
6689
Currency <currency code, default = USD>
15
SettlementType
63
FutSettDate <YYYYMMDD>
64
Account <account ID>
1
ClearingFirm <required for non-US issues>
439
NoAllocs <indicates # of allocation groups>
78
AllocAccount <Account ID for allocation>
79
AllocQty <allocation amount>
80
AllocClearingFirm <overrides “ClearingFirm”>
6638
OrdType <auction or customer bid/offer>
40
Price <required for customer bid/offer>
44
OrderCapacity <agency/principal>
47
TraderID <email address of trader>
6606
Persons of skill will recognize that other fields may be utilized as appropriate for the trade type (e.g., swaps) or particular security being traded. In addition, other fields defined by the FIX protocol may be utilized as a matter of design choice.
It will also be evident from the above table that a customer may pre-allocate trades on the system or through its internal OMS and include such allocations in the new order message to the databases. If the customer chooses to create allocations after a block trade is entered, then an allocation message is created. Table IV shows an exemplary message for transmitting post-trade allocations using the FIX protocol:
TABLE IV
EXEMPLARY ALLOCATION MESSAGE
Message
FIX
Type
Fields
Tag
Allocation
AllocID <customer generated ID>
70
AllocTransType <new, replacement, cancel>
71
TransactTime <date and time of trade>
60
NoOrders <number of orders combined for
73
allocation>
ClOrdID <Order ID assigned to trade>
11
NoExecs <number of executions combined for
124
allocation>
LastQty <size of referenced execution>
32
ExecID <ID assigned to execution>
17
LastPx <price of referenced execution>
31
Symbol <FIXED>
55
Side <buy/sell>
54
OrderQty <par value order size>
38
SecurityID <CUSIP/ISIN>
48
IDSource <CUSIP=1, ISIN=4>
22
Product <high level security class code; e.g.,
6613
Gov't Treasuries = GOVERNMENT
Gov't Agencies = AGENCY
Mortgage-Backed = MORTGAGE
Corporate Bonds = CORPORATE>
SecurityType <security classification; e.g.,
6609
CORP = Corporate Bonds
CP = Commercial Paper
MBS = Mortgage-Backed Securities
TBA = TBA Mortgages
UST = US Treasury Note/Bond
CouponRate <percentage>
223
MaturityDate <YYYYMMDD>
6637
IssueDate <YYYYMMDD>
6620
ContractSettlmntMonth <used for TBAs>
6689
Currency <currency code, default = USD>
15
SettlementTyp
63
FutSettDate <YYYYMMDD>
64
AvgPx <average price at which accumulated
6
executions took place, percentage>
Trade Date <the trade date as per FIX
75
specification>
NoAllocs <indicates # of allocation groups>
78
AllocAccount <Account ID for allocation>
79
AllocQty <allocation amount>
80
ExecBroker <counterpart to trade, BIC>
76
AllocClearingFirm <overrides “ClearingFirm”>
6638
The exemplary flow of
Upon receipt of the customer's allocations, if any, the dealer-side software client 270 confirms the details of the block trade and allocations and retrieves standing settlement instructions from the account management database 110, and may, but not necessarily, generate an electronic confirmation of the trade. Throughout the process outlined in
During the trading process, the STP trading platform 100 permits customers to submit trade inquiries to multiple dealers simultaneously. In this case, for example, the “Order Type” field of the “New Trade Order” message would be set to auction. As discussed above, in the exemplary embodiment, customers can submit requests to purchase from financial instrument inventories, such as commercial paper offering (CPO) and corporate bond inventories. All dealers receiving an inquiry and willing to trade the specific instrument for the transmitted quantity will message the customers with a firm quotation to buy or sell by filling out a trade ticket displayed on the dealer-side computers 260. The customer reviews the quote and determines to accept or reject the quote or allow the quote to lapse. A transaction is completed only if both the customer and dealer accept the quote.
With further reference to
In the exemplary enrichment is accomplished through a mapping of information contained in the block or allocated trade, as the case may be, and account information stored in the account management database 110. For example, an exemplary mapping may comprise the following associations:
TRADE DETAILS
ACCOUNT INFO.
Issue Country
Settling Country
Product Key
Security Type Major
Security Type
Security Type Minor
Company Name
Organization Code
Clearing Type
BIC
Account Id
Account Short Name
Using these associations, the STP trading platform 100 can determine the appropriate settlement instruction set for the block or allocated trade. By way of further example a particular account may have one or more settlement instruction groups dependent on various parameters of the trade, as set forth above. Based on the trade details, the STP trading system 100 will pull the appropriate settlement instruction groups associated with the appropriate account profile. The appropriate settlement instruction group is then selected based on further details in the trade.
With reference now to
On the interface 700 shown in
Using an input device, such as a mouse, the customer can select a particular OTR treasury coupon to trade. To most efficiently permit the customer to create a trade inquiry, the customer-side electronic trading component 215 (e.g., the software client operative on the customer's computer) is configured so as to permit the user to click directly on a selected instrument and launch a trade inquiry creation interface 800, as shown in
With reference now to
Assuming that the customer does not wish to flip the transaction or create a switch/swap transaction, and the customer has completed customizing the transaction to his/her requirements, the customer can submit the inquiry to the selected dealers. Upon submission of the inquiry, the customer is provided with a trade execution interface. The trade execution interface 900 in the exemplary embodiment shown in
In the exemplary embodiment presently being described, the dealer interacts with a trade execution interface similar to trade execution interface 900 through the dealer-side component 275 of the electronic trading module 160 configured to permit the dealer to update prices for the customer-selected instrument substantially in real-time. This process can be performed manually by a trader using such interfaces or dynamically through integration with the dealer's internal trade management system 290, as shown in
Although not visible in
3. Trade Execution—Dealer Initiated Electronic Axes
As discussed in the background section of the present application, a common shortcoming in known electronic trading systems is the inability for dealers to quickly respond to cancelled trade inquiries or generate liquidity by initiating an actionable trade inquiry the first instance. In the past, a trader at a dealer would telephone a particular customer to determine whether the customer was interested at trading a particular financial instrument at a particular level. More recently, electronic messaging systems, such as the BLOOMBERG PROFESSIONAL® service, permit traders to communicate electronically. Electronic mail systems, such as Microsoft® Outlook, can also be used to transmit such messages. However, such systems utilize traditional electronic messaging standards and proprietary input devices. Moreover, such systems are not integrated into trade execution engines-and therefore, traders must use alternate means to execute a trade. These messages also are non-executable and require the receiving customer(s) to telephone the dealer sending the message to execute a trade.
The electronic trading module 160 seeks to overcome this shortcoming by providing functionality for dealer initiated trade inquiries (also commonly referred to as an “axe”). Although dealers may initiate a trade inquiry or axe at anytime, the opportunity for an axe often arises in one of two situations. In one situation, the customer may have terminated a customer initiated trade inquiry and the dealer may wish to convey a better price level for the selected instrument. At this point, a dealer can transmit an electronic axe to the customer with an improved bid/offer from the customer's perspective. As will be described in greater detail below, the customer can hit the bid or lift the offer in the electronic axe and execute a trade at the axe price. In other instances, a dealer may require liquidity in a certain instrument and can communicate an electronic axe to one or more customers, rather that waiting for the termination of customer initiated trade inquiries. The electronic axe of the present invention, thus, adds an additional layer of liquidity to the market not traditionally present. Ordinarily, if a dealer needed to trade a particular financial instrument, for example, to create a flat position in the instrument, the dealer would have had only two options: (1) dealer could trade the instrument on the Interdealer Broker Market, or (2) make a hedging trade. Thus, the ability to use a dealer's customer base to make necessary or desired trades adds a valuable third layer of liquidity.
An exemplary embodiment of an electronic axe system operative in connection with the above-described STP trading platform 100 will now be described in connection with
In a first scenario, after a customer-initiated trade inquiry is transmitted to one or more dealers and cancelled by the customer, as described above, the dealer is notified of the cancelled trade. One manner of notification is for the dealer to be notified via a change in the trade state field 1005 of the trade blotter screen 1000, as shown in
Initiating the axe functionality launches an electronic axe trade ticket 1200, as shown in
After creation of the electronic dealer axe, the dealer-side electronic trading component 275 provides the dealer with several options for communicating the axe to one or more customers. In a first scenario, the dealer can simply transmit the electronic axe and the customer will be presented with an electronic axe message, as further described below. In a second scenario, the dealer can load the electronic axe into an electronic axe blotter for transmission at a later time to one or more selected customers or preset groups of customers. In a third scenario, the dealer can select multiple customers or groups of customers for immediate transmission of the electronic axe. This feature is also described in further detail below.
Upon completion of the electronic axe ticket by the dealer, the electronic axe ticket is transmitted through the STP trading platform 100 to the one or more selected customers. The customer-side electronic trading client 215 provides several ways in which the customer is notified of receipt of an electronic dealer axe. In a first exemplary embodiment, a message area 1310 on the client-side trading interface 1300, such as on the composite price screens, is used to list incoming electronic axes. In this case, the electronic dealer axe is displayed as a line item 1315 containing the information pertinent to the trade inquiry. The customer, upon seeing the electronic axe message, can click the electronic axe message to launch an electronic customer axe trade ticket 1400 as shown in
In a second embodiment, shown in
As depicted in
As with other trades, if the customer accepts the trade in the electronic axe ticket 1600 while “on the wire” time remains, the electronic axe trade will be accepted as indicated in the customer negotiation screen 1700 of
Moreover, it is preferred that the electronic axe ticket 1600 that is displayed to the customer be highlighted with a bright color and be conspicuously marked as a dealer axe. Also, it is preferred that the axe ticket 1600 include a field for previous quote made by the dealer to the customer in response to the customer initiated trade inquiry. By issuing the electronic axe ticket to the customer in this manner, the customer will be able to more easily discern the value inherent in the dealer axe.
In an alternate embodiment, the dealer axe functionality may be utilized even if a customer-initiated inquiry did not trigger a cancelled trade. In this scenario, the dealer axe may be directed to a single customer or multiple customers. For example, the dealer may select to send the electronic axe to all of the dealer's customers or one or more groups of customers. An advantage of the electronic axe functionality provided by the present invention is that it provides dealers with a mechanism for conveying binding and timely positions to its customers, while giving dealers another outlet for initiating trades to create liquidity.
With reference to
With reference now to
As described above, upon activation by the dealer, the information input into the axe list screen is transmitted to the STP trading platform 100 and the electronic trading module 160 uses the dealer information to generate an electronic axe message. The axe message is then communicated to the selected customers and displayed in several different manners, as described above. Transmission of the electronic axe data and electronic axe message is performed according to known electronic communication protocols such as TCP/IP. Preferably, the electronic axe data and electronic axe messages are formatted in XML so as to facilitate transmission between the dealer and the STP trading platform 100 and the systems 260 customer systems 200. The electronic axe message that is transmitted to the customer system 200 preferably includes a dealer name, an indication of whether the dealer is a buyer or a seller, the instrument type, the amount, and the on-the-wire time limit. The purpose of formatting the electronic axe message in this manner is to convey all of the material terms of the electronic axe and its binding nature to the customer.
With reference now to
With reference to
In step 22f, the dealer can upload the swap axe into its swap axe list by clicking the “add” button. In the swap axe list screen 2000, the swap axe is preferably shown as two list items so that the dealer can view both the buy-side and sell-side of the swap axe. If the dealer modified the yield spread during creation of the swap axe, then the trading module automatically calculates the buy and sell prices using the dealer modified axe yield spread. On the swap axe list screen 2000, in step 22g, the dealer then enters the “on the wire” time, identifies target customers, and, if desired, modify the settlement date. In step 22h, the dealer confirms the swap axe by clicking a confirmation button—in this example the “C” button. In step 22i, the swap axe is transmitted to the selected customers in the same manner as described above in connection with all electronic data communicated through the STP trading platform. The swap axe, as described above, is displayed to the selected customer in various manners including, but not limited to a pop-up notification window, a line item or an axe execution screen.
a. Axe Alerts
In certain situations, a customer may be interested in trading certain instruments or may desire to be specially notified if an electronic axe is received from a dealer or concerning a particular instrument. In such instances, according to an exemplary embodiment, the customer through operation of the electronic trading module 160 of the STP trading platform 100 and the customer-side electronic trading client 215 is provided with functionality to set alerts. Using the customer-side electronic trading client 215, the customer can link certain actions to be triggered by selected events. By way of example, a customer can choose to have a pop-up message launched if a certain price on a certain security from the composite price data is met or if an electronic axe on that security is received. Thus, whereas the customer may be receiving electronic axes as list items by default, an electronic axe on a selected security will trigger an alert in the form of a pop-up message. The message may be of the type described in connection with
b. Axe Monitor
Throughout a given trading day a customer may receive several electronic axes or swap axes. Similarly, a dealer may create and transmit several electronic axes during the trading day. To aid customers and dealers in managing the receipt or transmission of electronic axes, the STP trading platform is further configured to record received and transmitted axes and provide an electronic axe management interface or electronic axe monitor.
An exemplary electronic axe monitor 2300 interface is shown in
Similarly, the dealer electronic axe monitor (not shown) presents a view of a dealer's axes from the dealer perspective. Thus, in lieu of listing which dealer an axe was received from, the axe monitor will display the customer or group of customers to which the axe was transmitted.
4. Trade Execution—Alternate Systems and Phone Trades
The STP trading platform 100 is also preferably configured to process trades executed on systems other than the electronic trading module of the STP trading platform 100, such as trades executed via telephone or by an alternate electronic trading system. In these cases, trade details from alternate systems can be electronically imported into the STP trading platform 100 via electronic messaging using an API. Once the trade data is imported into the trade history database of the STP trading platform 100, STP functionality, as described herein, can be provided for trades executed on alternate systems or via the telephone. In the exemplary embodiment, the STP trading platform 100 are be communicatively linked to a dealer's internal systems or trade management systems to import trade details. The trade details are delivered to the customer via STP trading platform 100 in the “DONE” state. If the trade details are accepted or “checked-out” by the customer, the state will change to “ACC”, and thereafter trade details are then treated similarly as trades completed via the electronic trading module of the STP trading platform 100. Such trades may then be allocated and electronically confirmed via the STP trading platform 100, as described further below.
With reference now to
Additionally, a phone trade pop-up message 2400, as shown in
Phone trades that are accepted by the customer may be allocated, confirmed, and enriched with settlement instructions in the same manner as other trades handled by the STP trading platform 100.
5. Trade Acceptance, Allocation, and Confirmation
At each stage of a trade effected on the STP trading platform 100, or via alternate methods (e.g., phone trades) the trade is assigned a state that can be monitored by customers and dealers. An exemplary set of state codes is shown in Table V below.
TABLE V
EXEMPLARY STATE CODES
State Codes
Explanation
DONE
Imported block trade details form phone trade or
alternate trading system.
ACC
Block trade is accepted by customer, but not
allocated.
REJ
Block trade not accepted by customer.
END
Inquiry made, but no trade executed.
ALLOC
Block trade allocated to sub-accounts, but not
confirmed by dealer.
CONF
Dealer confirms all allocations, but does not
send ETC.
DLRCONF
Dealer confirms all allocations and sends ETC
to customer.
CONFP
Dealer confirms some, but not all of the
allocations. No ETC transmitted.
AFFM
Customer affirms trade details in ETC.
ETCREJ
Customer rejects ETC or chooses to amend
allocations.
ERR
Dealer cannot confirm trade details.
a. No ETC
An exemplary trade acceptance and allocation process where an electronic trade confirmation is not utilized will now be described in connection with the exemplary states listed above in Table V and the flow of
At this point, because the details of all trades and trade inquiries are stored in the trade history database 115, the customer can view a trade detail screen 2500, which provides the particulars of the accepted transaction and the rejected dealer quotes or ended inquiries, as shown in
Further, the customer can choose to view a breakdown screen, as shown in
To further facilitate post-trade allocation breakdown of a block trade, a drop down menu of available clearing firms (e.g., DTCC, Euroclear, Swift, Crest, etc.) will be auto-populated based upon the trade details, including account information, security and quantity.
With reference to
The allocation message transmission is preferably accomplished through the generation of an electronic message that is communicated to the dealer as described above. Persons of skill will recognize that the electronic allocation message and other electronic messages that are discussed herein as being transmitted between the customer and dealer through the STP trading platform 100 may be formatted in any known communication format, but are preferably formatted using a standardized message format, such as XML or FIX, as detailed above. XML stands for “Extensible Markup Language,” that enables the definition, transmission, validation, and interpretation of data between applications. Similarly, FIX stands for “Financial Information Exchange” protocol, which is a standardized message format typically used to describe “real-time” security transactions. In either instance, or using any other standardized format known or heretofore developed, the STP trading platform 100 can transmit the trade details directly to dealers in a standardized format. By interfacing with an application program interface (API) exposed to all participants, or at a minimum exposed only to the dealers, participants can interface with the STP trading platform 100 to receive transaction details, along with settlement instructions, as described further below, in a standardized format that can be manipulated by the recipient participant to work with the participants internal trade management system.
For example, if a dealer uses an internal trade management system that employs a proprietary database format for storing trade details, the dealer may still achieve straight-through-processing of trades by interfacing with the exposed API of the STP trading platform. The dealer would then receive trade details in a standardized format that could be automatically translated to the dealer's proprietary format for use with the dealer's internal systems.
Moreover, when the customer transmits the allocation to the dealer, the STP trading platform 100 preferably dynamically enriches the transaction details with the customer's standing settlement instructions for the particular sub-accounts allocated by the customer as previously described. These settlement instructions preferably include a dealer identification code, commonly referred to as a BIA code, that is specific to the dealer for the particular sub-account identified by the allocation. Further, upon allocation, a separate allocation ticket is generated for each account. The allocation tickets include an identifier of the base block trade and are, thus, mapped to such block trade data file.
In order to facilitate STP integration with customer and dealer internal systems, the back office management module 140 of the STP trading platform 100 may generate a “booking report” message that can be used to confirm each of the allocations in a particular trade. Table VI shows an exemplary booking report message using the FIX protocol:
TABLE VI
EXEMPLARY BOOKING REPORT MESSAGE
Message
FIX
Type
Fields
Tag
Booking
BookingID <unique system generated ID>
6641
Report
BookingTransType <new, replacement, cancel>
6642
AllocID <system generated ID>
70
RefAllocID <customer generated ID>
72
NoOrders <number of orders combined for
73
allocation>
OrderID <dealer assigned order ID>
37
SecondaryOrderID <system assigned ID>
198
ClOrdID <Order ID assigned to trade>
11
Symbol <FIXED>
55
Side <buy/sell>
54
SecurityID <CUSIP/ISIN>
48
IDSource <CUSIP=1, ISIN=4>
22
Product <high level security class code; e.g.,
6613
Gov't Treasuries = GOVERNMENT
Gov't Agencies = AGENCY
Mortgage-Backed = MORTGAGE
Corporate Bonds = CORPORATE>
SecurityType <security classification; e.g.,
6609
CORP = Corporate Bonds
CP = Commercial Paper
MBS = Mortgage-Backed Securities
TBA = TBA Mortgages
UST = US Treasury Note/Bond
CouponRate <percentage>
223
MaturityDate <YYYYMMDD>
6637
IssueDate <YYYYMMDD>
6620
Currency <currency code, default = USD>
15
FutSettDate <YYYYMMDD>
64
Qty <total size of trade allocated>
53
AvgPx <average price at which accumulated
6
executions took place, percentage>
Trade Date <the trade date as per FIX
75
specification>
TransactTime <date and time of execution>
60
Account <customer defined sub-account #>
1
GrossTradeAmt <principal amount of trade>
381
Net Money <net proceeds of trade>
118
ExecBroker <counterparty to trade, BIC>
76
Further, the STP trading platform 100 may provide an automatic download feature in which all accepted trades performed by any trader at either a customer or dealer are consolidated into a single flat file. This consolidated file may be imported into the customer's or dealer's in-house systems to automatically update back office systems.
By way of non-limiting example, in operation, the first trade of each day creates a new file for the trading day. Subsequent trades will be posted to the same file throughout the day. An exemplary naming convention is as follows: TWTRDCCYYMMDDF.TXT, where TWTRD denotes that this is the company's trades, CCYYMMDD is the century, year, month, and day and F denotes the format. As an example, the file name for trades executed on Jan. 4, 2004 in comma-delimited format is TWTRD20040104C.TXT. This file may be uploaded to in-house systems at any time.
The actual file format may be either: (1) text file format that may be interfaced to other systems, or (2) delimited format for spreadsheets. An example of the fields and information of such a file is shown below in Table VII:
TABLE VII
Max length in
Description
Columns
Format
Notes
fixed format
Trade Type
1-8
Character
Currently this field may contain one of three
8 characters
values:
(1) “USGOV” for U.S. Government
Securities, U.S. Agency-issued securities,
U.S. TBA Mortgage securities and Euro
Sovereign Debt securities.
(2) “USTSWAP for Treasury Swaps.
(3) “OUTRIGHT” for Commercial Paper.
Product Group
10-17
Character
(1) “TRSY” for U.S. Treasury securities.
8 characters
(2) “AGCY” for U.S. Agency-issued
securities.
(3) “EUGV” for Euro Sovereign Debt
securities.
(4) “MBS” for U.S. TBA Mortgage
securities.
(5) “CP” for U.S. Commercial Paper.
Trade Date
19-28
CCYY/MM/DD
Century, year, month and day format.
5 characters
10 characters
Trade Number 30-34 Numeric The trade
number is unique per product per dealer.
Dealer
36-41
Character
ABN—ABN AMRO
6 characters
BARC—Barclays Capital
BEAR—Bear Stearns
BNPP—BNP Paribas
COMZ—Commerzbank
CSFB—Credit Suisse First Boston
DB—Deutsche Banc Alex Brown
DRKW—Dresdner Kleinwort Wasserstein
GSCO—Goldman Sachs
GCM—Greenwich Capital Mkts
HSBC—HSBC
JPM—JP Morgan Chase
LEH—Lehman Brothers
MER—Merrill Lynch
MS—Morgan Stanley
SSB—Salomon Smith Barney
SG—Societe Generale
UBSW—UBS Warburg
Trade State
43-52
“Accepted”, “Cancel”, “Cancel-mod” or
10 characters
“Cancel-brk”
CUSIP
54-65
Character
CUSIP number
12 characters
Security
67-91
Character
Security description
25 characters
Settlement Date
93-102
CCYY/MM/DD
Century, year, month and day format.
10 characters
Account
104-123
Character
Trade or breakdown account name, (may be
20 characters
empty)
Trade Time
125-132
HH:MM:SS Trade, Correction, Cancellation
8 characters
or Breakdown time (The time the trade was
done, or further modified.)
Buy/Sell
134-139
Character
“BUY”, “SELL”
6 characters
Quantity
141-152
Numeric
Max 12 digits, Quantity is number of bonds.
12 characters
1000 = 1 million par value
Price (decimal)
154-169
Numeric
Max 16 digits
16 characters
Discount Rate
171-186
Numeric
Max 16 digits
16 characters
Yield
188-203
Numeric
Max 16 digits
16 characters
Principal Amount
205-222
Numeric
Max 18 digits
18 characters
Total Payment
224-241
Numeric
Max 18 digits
18 characters
Accrued Interest
243-260
Numeric
Max 18 digits
18 characters
Per Bond
Accrued Interest
262-279
Numeric
Max 18 digits
18 characters
Amount
Breakdown
281-285
Numeric
When a trade is broken down, it will be
5 characters
Number
assigned a unique number by the system.
This is the Breakdown Number. All
breakdowns will also have in the Trade
Number field the trade number of original
(i.e. parent) trade. All parent trades or single
ticket trades will have zero in the
Breakdown Number field.
Customer Name
287-306
Character
Customer name
20 characters
Branch Name
308-327
Character
Branch name
20 characters
ISIN
329-344
Character
For Product Group “EUGV” it will contain
16 characters
the ISIN otherwise it will be blank.
Clearing Code
346-361
Character
Clearing Code details if appropriate
16 characters
Coupon
363-369
Numeric
Max 7 digits
7 characters
Maturity date
371-380
CCYY/MM/DD
Security maturity date
10 characters
Security type
382-391
Character
U.S. Treasury securities:
10 characters
“REGBILL”, “WIABILL”, “WIBBILL”,
“REGNOTE”, “WIANOTE”, “WIBNOTE”
“STRIPPRIN” or “STRIPPINT”
U.S. Agency-issued securities:
“WIAFNMA”, “WIBFNMA”,
“REGFNMA”,
“WIAFHLMC”,
WIBFHLMC”, “REGFHLMC”,
“WIAFHLB”, “WIBFHLB”, “REGFHLB”,
“WIASUPRA”, “WIBSUPRA”,
“REGSUPRA”
U.S. TBA Mortgage securities:
“TBAFNMA”, TBAFHLMCG” or
“TBAGNMA1”
U.S. Commercial Paper:
“CP”
Euro Sovereign Debt securities:
“REGBGB”, “REGBTNS”, “REGBTPS”,
“REGDBR”, “REGBKO”, “REGFRTR”,
“REGIRISH”, “REGNETHR”, “REGOBL”,
“REGPGB”, “REGRAGB”, “REGRFGB”,
“REGSPGB”, “REGTHA”, or “REGOLO”
Pfandbriefe:
“DEPFAN”, “ESPFAN” or “FRPFAN”
STIP
393-456
Character
STIP, if applicable
64 characters
Time sent
458-465
HH:MM:SS
Trade sending time. When a trade is broken
8 characters
down, it will be assigned original (i.e.
parent) trade sending time.
Time zone
467-474
Character
Time zone implied by “Trade time” and
8 characters
“Time sent” fields.
“EST”—Eastern Standard Time,
“EDT”—Eastern Daylight Time,
“GMT”—Greenwich Mean Time,
“BST”—British Standard Time
Customer notes
476-603
Character
Notes entered on trade ticket, if any.
128 characters
Customer tracking
605-636
Character
To be implemented at a later date. Customer
32 characters
number
enters info on ticket, which will persist
through the trade.
Issuer Acronym
608-639
Character
CP Issuer Acronym Info
32 characters
Customer location
641-644
Character
Linked to Account Management Module
4 characters
Dealer Location
646-649
Character
Linked to Account Management Module
4 characters
Currency
651-653
Character
USD, GBP or EUR
3 characters
Regulatory type
655-662
Character
Character CP Issue Regulatory type:
8 characters
“3(a)2”, “3(a)3”, “3(a)4”, “4(2)”, “144A”,
“3(c)7”
By way of summary, and as further described below, the enriched trade details may also populate an electronic confirmation form standardized as required by government regulation, such as SEC Rule 10b-10. Dealers may also be provided functionality to manually add additional disclosures to the electronic confirms, as desired. Persons of skill will recognize that additional dealer disclosures can be automatically inserted into the standardized confirm form. With reference again to
Thus, in an exemplary embodiment depicted in
In cases were no electronic trade confirmation is to be utilized, the settlement instructions received with the trade details are used by the dealer to settle the trade through the appropriate clearing agency. By eliminating the need for the customer's back office personnel to have to provide the dealer's back office with allocations and settlement instructions via fax or telephone, as is presently done, the chance for human error is significantly reduced. Moreover, the need for the customer's back office personnel to have to key the allocations and settlement instructions into a fax transmission is eliminated, as is the need for the dealer's back office personnel to re-key the allocations and settlement instructions in their internal systems. Thus, redundant systems can be eliminated, and the trading process simplified.
If the dealer cannot confirm any of the allocations made by the customer, then the dealer rejects the allocations and the trade is assigned the “ERR” state. Dealers may reject allocated trades under several circumstances, including but not limited to (i) the allocated trade details not matching the details of the block trade and (ii) the dealer not having the proper account data. Table VIII lists various conditions that can lead to a trade rejection.
TABLE VIII
EXEMPLARY TRADE REJECTION CODES
Rejection
Codes
Explanation
0001
Trade not recognized
0002
Incorrect “Bought” or “Sold” indicator
0003
Incorrect security
0004
Incorrect price
0005
Incorrect price currency
0006
Incorrect commission
0007
Incorrect interest
0008
Incorrect trade date
0009
Incorrect trade time
0010
Incorrect dealing capacity
0011
Incorrect settlement date
0012
Narrative not understood
0013
Trading conditions not understood
0014
Incorrect fund ID or fund name
0015
Incorrect quantity
0016
Incorrect settlement instructions
0017
Incorrect (initial charges) amount, rate or currency
0018
Incorrect charges
0019
Incorrect settlement currency
0020
Incorrect exchange rate
0021
Incorrect trade net cost
0022
Duplicate trade
0023
Incorrect tax
0099
Dealer specific rejection comment.
In some instances the dealer may be able to confirm some of the allocations, but not all of the allocations. In this case, the block trade is assigned the “CONFP” state and a message is transmitted to the customer. Upon receipt of a message including a CONFP state, the customer can either (i) cancel and reissue new allocations or (ii) cancel or correct the block trade. If new allocations are made, then an allocation message with the state “ALLOC” is transmitted to the dealer and the process begins again until the trade is either confirmed or cancelled altogether.
b. Electronic Confirmation/Clearance
Furthermore, according to the exemplary data flow of
TABLE IX
EXEMPLARY ETC FIELDS
STP Trading
Dealer
Platform
Fields
Supplied
Supplied
Trade time
TH
Trade date
TH
Price
TH
Nominal/Quantity
TH
Principle/Gross amount
X
Accrued
X
Net
X
Acted as: Principal/Agent/
X
Agency Cross
Dealer legal entity
X
Buy/Sell
TH
Settlement date
TH
Number of days accrued
TH
Settlement currency
TH
Security code
TH
Security code type (e.g.,
TH
CUSIP, ISIN, SEDOL)
Security description
TH
Client name
TH
Confirmation reference number
TH
Trading conditions
X
Dealer disclaimer
AM
Dealer address
AM
Customer address
AM
Dealer telephone number
AM
Callable debt disclaimer (may be
AM
part of Dealer disclaimer above)
Asset backed disclaimer (may be
AM
part of Dealer disclaimer above)
Comment field
X
Alternative security code
AM
Exchange rate
X
Standing Settlement Instructions
AM
(SSI) from account management
system.
TH = Retrieved from trade history database 115
AM = Retrieved from account management database 110
The exemplary confirmation system of the present invention preferably follows the following data flow as shown in
After receiving the trade details of an accepted block trade, a customer would review the details and may include any trade allocation instructions (e.g., instructions to allocate the trade among sub-accounts, as described above), in step 31d. The STP trading platform 100 assigns the “ALLOC” state and transmits each allocation ticket created by the STP trading platform 100 as a result of the customer's allocations to the dealer. A record of the allocations is also stored by the trade history database 115. At this point, each allocation ticket may be enriched with settlement instructions electronically accessed from the account management database 110 of the STP trading platform 100.
Next, in step 31e, the dealer reviews the allocation tickets and processes the trade details for each sub-account set forth in the allocation. The dealer may then acknowledge that it has processed and accepted each allocation ticket in step 31g. In the event that an allocation is not processed by the dealer (e.g., a sub-account has not been mapped to the dealer's internal system), as in step 31h, the dealer can only confirm certain of the allocations and the trade will be assigned the “CONFP” partial confirmation state and an error message will be transmitted over the STP trading platform 100 to the customer with specific instructions explaining why the specific allocation ticket could not be processed. If the dealer rejects all of the allocations, as in step 31f, the trade will be returned to the customer and assigned the “ERR” state.
After all of the allocation tickets are processed and confirmed by the dealer, the STP trading platform 100 may generate an ETC, in step 31j. At this point, the allocated trade is assigned the “CONF” state. Each ETC will preferably include all the information required to be disclosed under relevant government laws, rules, or regulations, if applicable, such as by way of example SEC Rule 10b-10. In addition, the ETCs would provide dealers the ability to include any additional disclosures that they may wish to provide, which are specific to the dealer. The ETC may also indicate that the customer should contact the dealer with whom it effected a transaction with any questions. Any such communication following delivery of the ETC would preferably occur directly between the dealer and the customer, although the dealer and the customer may elect to use electronic messaging facilities provided by the STP trading platform 100. Persons of skill in the relevant art will recognize that although it is preferred that the ETC conform to applicable government laws, rules, or regulations, the ETC of the present invention may be utilized in jurisdictions where not such applicable government laws, rules, or regulations exist. In such cases, the ETC may still be used to electronically confirm trades in a binding fashion through use of master trading agreements and the like.
In operation, the ETC is populated by the STP trading platform 100 using the enriched trade details and allocations stored in the trade history database 115 and the settlement instructions retrieved from the account management database 110 to preferably provide a standardized electronic confirmation as required by government regulation. (e.g., SEC Rule 10b-10). Persons of skill will recognize that additional dealer disclosures can be automatically inserted or manually input into the standardized ETC form. Once the ETC is generated on the dealer-side, through transmission of the ETC through the STP trading platform 100, the customer receives and can review and electronically confirm the trade details 3205 through the STP trading platform 100 by indicating an acceptance of the ETC—for example, by clicking a “affirm” button 3210 on an exemplary ETC 3200 as shown in
Each of the customer and dealer would have the ability to view, download, and/or print their ETCs through the STP trading platform 100, and may establish default procedures pursuant to which such ETCs are downloaded and/or printed automatically. ETCs would also preferably be stored electronically by the STP trading platform 100 in the trade history database 115, although this feature is not required.
The STP trading platform 100 may also enable the customer (or a custodian or designated third party on behalf of the customer) to accept the trade details and settlement instructions in a number of different ways. First, the customer may use the back office management tools provided by the STP trading platform 100 to receive the trade details and the related settlement instructions from the dealer and manually compare the information it receives against its internal records. If the customer agrees that the information it received from the dealer matches with the information in its database, the customer will transmit an indication that the customer affirms the trade details and the settlement instructions via the STP trading platform 100 to the dealer.
Alternatively, the STP trading platform 100 may provide functionality to enable customers to electronically affirm trade details and settlement instructions in order to electronically match trade data submitted by dealers and customers. In such instances, the electronic confirmation would be based on the matched trade data and other information provided. In one exemplary embodiment, the STP trading platform 100 records the trade details on behalf of the customer as trades are effected via the electronic trading module 160 of the STP trading platform 100, as described above. In a second exemplary embodiment, trade information is made available to the STP trading platform 100 through an API that interacts with the customer's internal trade processing systems and/or order management systems, as also described above.
The trade details and settlement instructions provided by the customer are then electronically matched by the STP trading platform 100 to trade details and settlement instructions provided by the dealer on the STP trading platform 100. If the trade details and settlement instructions received from the dealer match the information provided or made available to the STP trading platform 100 by the customer, the STP trading platform 100 will electronically and automatically affirm the trade on behalf of the customer.
The STP trading platform 100 may also transmit the affirmed trade confirmation (in accordance with the applicable self-regulatory organization rules) directly to a depository, such as the Depository Trust & Clearing Corporation (“DTCC”) or a settlement agent for settlement of the trade.
Back Office Management Tools
According to an exemplary embodiment, as shown in
In the exemplary embodiment, the functionality of the master blotter, shown in
The back office management module 140 also provides a summary interface on which dealers and counterparts can view summary information related to their trades. Like the functionality of the master blotter, the functionality of the trade summary interface, shown in
Settlement Instruction Validation
With reference to
By way of non-limiting example, on one level, the settlement instruction validation system 180 compares settlement instructions to databases such as the SWIFT BIC, the Euroclear code, and other like directories comprising codes for various entities and securities involved in the settlement process. Furthermore, the settlement instruction validation system 180 may perform character-based validation. In this example, the settlement instruction validation system 180 compares known standards for certain fields with the actual stored fields. For example, it is known that Bank Routing Number (or ABA number) must have 8-digits. The settlement instruction validation system 180 would detect an ABA number field with less than 8-digits. Errors can be reported in a summary validation report that may be issued daily, weekly, monthly, or on some other time basis as a matter of design choice. The reports would identify errors in stored settlement instructions and permit correction to avoid settlement failures.
Performance Reports
In the exemplary embodiment, as illustrated in
Moreover, as shown in
These reports may be provided on a periodic basis (e.g., daily, weekly, or monthly) and in varying degrees of detail. Moreover, in a preferred embodiment, customers and dealers would have access to web-based accounts so as to access performance reports as desired. In such an embodiment, the performance reports are preferably dynamically updated in substantial real time such that recent trades, allocations, and confirmations are available to customers and dealers.
Thus, while there have been shown and described fundamental novel features of the invention as applied to the exemplary embodiments thereof, it will be understood that omissions and substitutions and changes in the form and details of the disclosed invention may be made by those skilled in the art without departing from the spirit of the invention. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.
| Patent | Priority | Assignee | Title |
| 10692135, | Jan 07 2003 | JPMORGAN CHASE BANK, N.A. | System and method for process scheduling |
| 7634438, | Dec 23 2004 | REFINITIV US ORGANIZATION LLC | Dynamic account mapping system for computerized asset trading |
| 7698187, | Oct 28 2005 | LIFFE Administration and Management | System and method for simultaneous trading of options |
| 7756777, | Mar 25 2003 | Tradeweb Markets LLC | Method and system for administering prime brokerage |
| 8280800, | Mar 31 2005 | Credigy Technologies, Inc. | System and method for an exchange of financial instruments |
| 8416801, | Sep 08 2005 | CME GROUP INC | Distribution of data to multiple recipients |
| 8504667, | Sep 08 2005 | EBS Group Limited | Distribution of data to multiple recipients |
| 8626641, | Mar 15 2013 | Merk Investments LLC | Deliverable commodity investment vehicle |
| 8682777, | Feb 02 2009 | MarketAxess Holdings, Inc. | Methods and systems for computer-based trading enhanced with market and historical data displayed on live screen |
| Patent | Priority | Assignee | Title |
| 4674044, | Jan 30 1985 | Bank of America Corporation | Automated securities trading system |
| 4750135, | May 01 1986 | Reuters Limited | Method for dynamically creating a receiver definable local trading instrument displayable record from a remotely transmitted trading instrument common data stream |
| 5003473, | Oct 24 1988 | GENEVA BRANCH OF REUTERS TRANSACTION SERVICE LTD | Trading ticket output system |
| 5077665, | May 25 1989 | REUTERS TRANSACTIONS SERVICES LIMITED | Distributed matching system |
| 5136501, | May 26 1989 | REUTERS TRANSACTION SERVICES LIMITED | Anonymous matching system |
| 5168446, | May 23 1989 | MONEYLINE TELERATE | System for conducting and processing spot commodity transactions |
| 5195031, | Oct 24 1988 | REUTERS LIMITED, 85 FLEET STREET LONDON EC4P, A CORP OF ENGLAND; REUTERS LIMITED, 85 FLEET ST , LONDON EC4P, A CORP OF ENGLAND | Trading system for providing real time context sensitive trading messages based on conversation analysis |
| 5270922, | Jun 29 1984 | Bank of America Corporation | System for distributing, processing and displaying financial information |
| 5297032, | Feb 01 1991 | Bank of America Corporation | Securities trading workstation |
| 5497317, | Dec 28 1993 | Omgeo LLC | Device and method for improving the speed and reliability of security trade settlements |
| 5502637, | Jun 15 1994 | Thomson Reuters Global Resources Unlimited Company | Investment research delivery system |
| 5727165, | Dec 17 1990 | Reuters Limited | Offer matching system having timed match acknowledgment |
| 5774880, | Jun 10 1992 | CFPH L L C | Fixed income portfolio index processor |
| 5826243, | Jan 03 1994 | FAULEY, ROBYNNE A; MNUCHIN , UNITED STATES SECRETARY OF THE TREASURY, STEVE; IANCU, UNDER SECRETARY OF COMMERCE FOR INTELLECTUAL, PROPERTY AND DIRECTOR OF THE U S T P O , ANDREI; ROSENBLUM, OREGON ATTORNEY GENERAL, ELLEN | Integrated system for controlling master account and nested subaccount(s) |
| 5857176, | Jun 10 1992 | CFPH L L C | Fixed income portfolio data processor |
| 5905974, | Dec 13 1996 | CANTOR FITZGERALD, L P CFLP ; CFPH, L L C CFPH | Automated auction protocol processor |
| 5924082, | Aug 17 1994 | Geneva Branch of Reuters Transaction Services Limited | Negotiated matching system |
| 5924083, | May 29 1996 | REUTERS TRANSACTION SERVICES LIMITED | Distributed matching system for displaying a book of credit filtered bids and offers |
| 5927031, | Apr 07 1998 | Stabilizer frame for corner siding and method | |
| 5940809, | Aug 19 1996 | Bank of America Corporation | Securities brokerage-asset management system |
| 5946667, | Apr 06 1994 | MORGAN STANLEY SERVICES GROUP INC | Data processing system and method for financial debt instruments |
| 5987432, | Jun 29 1994 | Reuters, Ltd. | Fault-tolerant central ticker plant system for distributing financial market data |
| 6006206, | Sep 08 1997 | Thomson Reuters Global Resources Unlimited Company | Data health monitor for financial information communications networks |
| 6016482, | Jan 11 1996 | Bank of America Corporation | Enhanced collateralized funding processor |
| 6092056, | Apr 06 1994 | MORGAN STANLEY SERVICES GROUP INC | Data processing system and method for financial debt instruments |
| 6105005, | Sep 15 1997 | Bank of America Corporation | System for enhanced financial trading support |
| 6173270, | Sep 01 1992 | Bank of America Corporation | Stock option control and exercise system |
| 6260025, | May 29 1996 | Geneva Branch of Reuters Transaction Services Ltd. | Distributed matching system for displaying a book of credit filtered bids and offers |
| 6269346, | Sep 01 1992 | Bank of America Corporation | Stock option control and exercise system |
| 6317727, | Oct 14 1997 | GFINET, INC | Systems, methods and computer program products for monitoring credit risks in electronic trading systems |
| 6317751, | Sep 28 1998 | Bank of America Corporation | Compliance archival data process and system |
| 6393409, | Oct 31 1997 | MORGAN STANLEY SERVICES GROUP INC | Computer method and apparatus for optimizing portfolios of multiple participants |
| 6421653, | Oct 14 1997 | GFINET, INC | Systems, methods and computer program products for electronic trading of financial instruments |
| 6462758, | Feb 09 1998 | REFINITIV US ORGANIZATION LLC | Display method for time-ordered dynamic lists of data |
| 6505175, | Oct 06 1999 | GOLDMAN SACHS & CO LLC | Order centric tracking system |
| 6519574, | Dec 12 1995 | Thomson Reuters Global Resources Unlimited Company | Electronic trading system featuring arbitrage and third-party credit opportunities |
| 6560580, | Dec 13 1996 | CANTOR FITZGERALD, L P ; CFPH, LLC | Automated auction protocol processor |
| 6587840, | Sep 08 1997 | Thomson Reuters Global Resources Unlimited Company | Data health monitor for financial information communications networks |
| 6606637, | Aug 01 2000 | REFINITIV US ORGANIZATION LLC | System and method for unified data access of financial data |
| 20010051908, | |||
| 20020002530, | |||
| 20020004777, | |||
| 20020016761, | |||
| 20020026400, | |||
| 20020046149, | |||
| 20020046151, | |||
| 20020046156, | |||
| 20020049661, | |||
| 20020055901, | |||
| 20020082967, | |||
| 20020099651, | |||
| 20020116317, | |||
| 20020143694, | |||
| 20020156719, | |||
| 20020169704, | |||
| 20020184142, | |||
| 20030046095, | |||
| 20030055774, | |||
| 20030061069, | |||
| 20030088509, | |||
| 20030093360, | |||
| 20030115131, | |||
| 20030139997, | |||
| 20030149646, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Mar 25 2004 | Tradeweb Markets LLC | (assignment on the face of the patent) | / | |||
| Mar 25 2004 | TOFFEY, JAMES WORDEN | TRADEWEB GROUP L L C | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014489 | /0679 | |
| Jul 29 2004 | TRADEWEB GROUP LLC | THOMSON TRADEWEB LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 020672 | /0117 | |
| Mar 17 2008 | THOMSON TRADEWEB LLC | Tradeweb Markets LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 020695 | /0295 | |
| Oct 29 2010 | Tradeweb Markets LLC | THOMSON REUTERS MARKETS LLC | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 044962 | /0001 | |
| Oct 29 2010 | THOMSON REUTERS MARKETS LLC | THOMSON REUTERS MARKETS LLC | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 044962 | /0001 | |
| Mar 09 2018 | THOMSON REUTERS MARKETS LLC | Thomson Reuters Global Resources Unlimited Company | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 045204 | /0660 | |
| Oct 01 2018 | THOMSON REUTERS GRC INC | DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT | SECURITY AGREEMENT | 047187 | /0316 | |
| Oct 01 2018 | THOMSON REUTERS GRC INC | BANK OF AMERICA, N A , AS COLLATERAL AGENT | SECURITY AGREEMENT | 047185 | /0215 | |
| Nov 26 2018 | Thomson Reuters Global Resources Unlimited Company | THOMSON REUTERS GRC INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 047909 | /0874 | |
| Dec 01 2018 | THOMSON REUTERS GRC INC | THOMSON REUTERS GRC LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 048553 | /0148 | |
| Jan 24 2019 | THOMSON REUTERS GRC LLC | Tradeweb Markets LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 048200 | /0469 | |
| Feb 13 2019 | DEUTSCHE BANK TRUST COMPANY AMERICAS, AS NOTES COLLATERAL AGENT | THOMSON REUTERS GRC , LLC FORMERLY KNOWN AS THOMSON REUTERS GRC , INC | RELEASE OF SECURITY INTEREST IN CERTAIN PATENTS PREVIOUSLY RECORDED AT REEL FRAME 047187 0316 | 048479 | /0489 | |
| Feb 13 2019 | BANK OF AMERICA, N A | THOMSON REUTERS GRC LLC FORMERLY KNOWN AS THOMSON REUTERS GRC , INC | PARTIAL RELEASE OF SECURITY INTEREST | 048464 | /0833 | |
| Feb 28 2019 | THOMSON REUTERS GRC LLC | REFINITIV US ORGANIZATION LLC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 048676 | /0110 | |
| Apr 08 2019 | Tradeweb Markets LLC | CITIBANK, N A | SECURITY AGREEMENT | 048825 | /0531 | |
| Apr 08 2019 | BONDDESK GROUP LLC | CITIBANK, N A | SECURITY AGREEMENT | 048825 | /0531 | |
| May 31 2019 | REFINITIV US ORGANIZATION LLC FORMERLY KNOWN AS THOMSON REUTERS GRC LLC | Tradeweb Markets LLC | CONFIRMATION OF CHANGE OF NAME STATUS IN U S PATENTS 7,433,842 AND 7,734,518 | 049391 | /0192 | |
| Nov 21 2023 | CITIBANK, N A , AS COLLATERAL AGENT | Tradeweb Markets LLC | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 065636 | /0358 | |
| Nov 21 2023 | CITIBANK, N A , AS COLLATERAL AGENT | BONDDESK GROUP LLC | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 065636 | /0358 |
| Date | Maintenance Fee Events |
| Mar 21 2012 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Mar 07 2016 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| May 25 2020 | REM: Maintenance Fee Reminder Mailed. |
| Nov 09 2020 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| Oct 07 2011 | 4 years fee payment window open |
| Apr 07 2012 | 6 months grace period start (w surcharge) |
| Oct 07 2012 | patent expiry (for year 4) |
| Oct 07 2014 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Oct 07 2015 | 8 years fee payment window open |
| Apr 07 2016 | 6 months grace period start (w surcharge) |
| Oct 07 2016 | patent expiry (for year 8) |
| Oct 07 2018 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Oct 07 2019 | 12 years fee payment window open |
| Apr 07 2020 | 6 months grace period start (w surcharge) |
| Oct 07 2020 | patent expiry (for year 12) |
| Oct 07 2022 | 2 years to revive unintentionally abandoned end. (for year 12) |