Patent Publication Number: US-11042263-B1

Title: Graphical user interface to track dynamic data

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation application of U.S. application Ser. No. 15/815,329, filed Nov. 16, 2017, which claims priority to U.S. Provisional Patent Application Ser. No. 62/424,239, filed Nov. 18, 2016, which are hereby incorporated by reference in their entirety. 
    
    
     TECHNICAL FIELD 
     The present invention relates to graphical user interfaces and, more particularly, to systems and methods for monitoring multiple transactions via a centralized and specifically designed graphical user interface. 
     BACKGROUND 
     User interfaces for securities syndicate issuer applications have been historically very data driven. Conventional and existing user interfaces display securities syndicate data using columns and/or rows of data and text. Security syndicate issuers typically monitor transactions as they are occurring. High-pressure environments, where time is of the essence, causes the visual representations of the data to be essential on a transaction or offering day. 
       FIG. 1  illustrates a conventional graphical user interface with tabular data.  FIG. 1  illustrates an exemplary graphical user interface display (GUI)  100  of an Industrial Development Board in a city, such as Indianapolis, Ind. GUI  100  displays the amount of the bonds in each maturity as well as the orders received in a tabular form. A lead manager or an issuer acting as a user, for example, may indicate to the system or request to categorize the data by case, priority, total member, non-retail or other desired category. The user may then have to view additional details in each category and extract the underlying data. 
     For example, as illustrated in  FIG. 1 , different maturities are presented in rows. Under Series 2016A (in section  120 ), the GUI  100  presents a maturity date of December 2035 on the first line. Further, more information is presented within the row of that maturity. For example, GUI  100  only lists the amount of bonds and the coupon rate (e.g., for the December 2035 maturity, 27,635 bonds have been sold with a coupon rate of 5). This data is tabular and time consuming to digest for a manager or an issuer. Issuers are often required to assess an overall status of a portfolio in a very short period of time (e.g., three to five second test where the issuer has to assess a portfolio in three to five seconds). Given the amount and complexity of transaction data presented in GUI  100 , it is nearly impossible to visually analyze a portfolio when the data is presented using conventional methods. 
     Furthermore, modern users of electronic devices access their electronic devices for larger durations and with smaller screens. For example, social media has caused users of various systems to access their devices and webpages for hours at a time on portable electronic devices. Security syndicate issuers may similarly use their electronic devices, such as cell phones and laptops, for longer viewing periods. Conventional user interfaces that display all data in a tabular form may become difficult and inefficient to use because tabular data is more challenging to view on smaller screens. 
     SUMMARY 
     For the aforementioned reasons, there is a desire to graphically present the information in real time in an easy-to-digest form so that syndicate issuers and/or managers can view the data live in an efficient manner consistent with demands of the financial transaction trading industry. 
     In an embodiment, a method of displaying a graphical user interface on an electronic device comprises displaying, by a server, in a first section of the graphical user interface, a plurality of inter-actable graphical components representing a plurality of bond maturities, wherein each selectable bond maturity graphical component represents a bond maturity from the plurality of bond maturities, wherein each selectable graphical component displays a maturity date associated with the bond maturity, and is displayed graphically on a bar where a height of the bar indicates an order dollar value of the bond maturity, wherein the bar comprises a line where a height of the bar above the line indicates a total number of dollars that are available in a par amount for the bond maturity and an area above the line indicates an amount that the bond maturity is oversubscribed; displaying, by the server, in a second section of the graphical user interface, a list of recent orders presented in real time, wherein the list of recent orders comprises a plurality of orders received by the server, wherein the list of recent orders further comprises a maturity date, a size of the order, and a name of a purchaser associated with each order within the plurality of orders; and displaying, by the server, in a third section of the graphical user interface, a summary comprising a total monetary value corresponding to the plurality of orders, a time remaining indicator, and a graphical indicator of a short fill percentage, mid fill percentage and long fill percentage. 
     In another embodiment, a computer system comprises a server comprising a processor and a non-transitory computer readable medium comprising a set of instructions that are configured to be executed by the processor to display a graphical user interface on an electronic device, wherein the set of instructions comprises a first instruction to instruct a first module of the server to display, in a first section of the graphical user interface, a plurality of selectable graphical components representing a plurality of maturity bonds, wherein each selectable graphical component represents a maturity bond from the plurality of maturity bonds, wherein each selectable bond maturity graphical component displays a maturity date associated with the maturity bond, and is displayed graphically on a bar where a height of the bar indicates an order dollar value of the bond maturity, and wherein the bar comprises a line where a height of the bar above the line indicates a total number of dollars that are available in a par amount for the maturity bond and an area above the line indicates an amount that the maturity bond is oversubscribed; wherein the set of instructions further comprises a second instruction to instruct a second module of the server to display, in a second section of the graphical user interface, a list of recent orders presented in real time, wherein the list of recent orders comprises a plurality of orders received, wherein the list of recent orders further comprises a maturity date, a size of the order, and a name of a purchaser associated with each order within the plurality of orders; and wherein the set of instructions further comprises a third instruction to instruct a third module of the server to display, in a third section of the graphical user interface, a summary comprising a total monetary value corresponding to the plurality of orders, a time remaining indicator, and a graphical indicator of a short fill percentage, mid fill percentage and long fill percentage. 
     In yet another embodiment, a computer system comprises an electronic device configured to display a graphical user interface; a server in communication with the electronic device, wherein the server is configured to display, in a first section of the graphical user interface, a plurality of selectable bond maturities components representing a plurality of bond maturities, wherein each selectable bond maturity graphical component represents a bond maturity from the plurality of bond maturities, wherein each selectable bond maturity graphical component displays a maturity date associated with the bond maturity, and is displayed graphically on a bar where a height of the bar indicates an order dollar value of the bond maturity, wherein the bar comprises a line where a height of the bar above the line indicates a total number of dollars that are available in a par amount for the bond maturity and an area above the line indicates an amount that the bond maturity is oversubscribed; display, in a second section of the graphical user interface, a list of recent orders presented in real time, wherein the list of recent orders comprises a plurality of orders received by the server, wherein the list of recent orders further comprises a maturity date, a size of the order, and a name of a purchaser associated with each order within the plurality of orders; and display, in a third section of the graphical user interface, a summary comprising a total monetary value corresponding to the plurality of orders, a time remaining indicator, and a graphical indicator of a short fill percentage, mid fill percentage and long fill percentage. 
     It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings constitute a part of this specification and illustrate an embodiment of the invention and together with the specification, explain the invention. 
         FIG. 1  illustrates a conventional graphical user interface displaying transaction data, according to an embodiment. 
         FIG. 2  illustrates an exemplary embodiment of a trading system for bond trading, according to an embodiment. 
         FIG. 3  illustrates an exemplary embodiment of fixed income pricing system (FIPS), according to an embodiment. 
         FIG. 4  illustrates a transaction monitoring computer system, according to an embodiment. 
         FIG. 5  illustrates exemplary steps performed when monitoring the flow of transactions during a security syndicate offering, according to an embodiment. 
         FIG. 6  illustrates exemplary steps performed when monitoring the flow of transactions during a security syndicate offering, according to an embodiment. 
         FIG. 7  illustrates a graphical user interface displaying syndicate offering data, according to an embodiment. 
         FIG. 8  illustrates a graphical user interface displaying syndicate offering data, according to an embodiment. 
         FIG. 9  illustrates a graphical user interface displaying syndicate offering data, according to an embodiment. 
         FIG. 10  illustrates a graphical user interface displaying syndicate offering data, according to an embodiment. 
         FIG. 11  illustrates a graphical user interface displaying syndicate offering data, according to an embodiment. 
         FIG. 12  illustrates multiple graphical user interfaces displaying syndicate offering data using a client&#39;s customized graphical user interface, according to an embodiment. 
         FIG. 13  illustrates a graphical user interface displaying syndicate offering data in a tabular form, according to an embodiment. 
         FIG. 14  illustrates a graphical user interface displaying syndicate offering data and additional economic data, according to an embodiment. 
         FIG. 15  illustrates a pop up graphical user interface component displaying manager profiles, according to an embodiment. 
         FIG. 16  illustrates a graphical user interface displaying syndicate offering data and geographic analysis of the order, according to an embodiment. 
         FIG. 17  illustrates a graphical user interface displaying customized syndicate offering data, according to an embodiment. 
         FIG. 18  illustrates a graphical user interface component that displays the orders received, according to an embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     There are various types of security syndicate offerings conducted in the securities market. One type of security syndicate offering, for example, involves the sale of municipal bonds. During a security syndicate offering of municipal bonds, various transactions are conducted to solicit bids for, and facilitate the sale of the municipal bonds. These transactions can be very complex and time-consuming because the security syndicate offering can be valued at, for example, over one billion Dollars and may include multiple interconnected offerings and deals. Furthermore, processing the security syndicate offering requires interaction between a large number of participants. In general, the participants consist of the syndicate group, financial institutions, underwriters, etc. The syndicate group typically pool their resources to share the underwriting liability for a given security syndicate offering by a security issuer. 
     A security syndicate offering can include, for example, four general transaction periods, namely communication, pricing, order, and allotment. During the communication period, information regarding the details of the security syndicate offering, for example, is communicated to all members of the syndicate. Once the information has been received, the syndicate members make a commitment to purchase a portion of the transaction value. The pricing period represents, for example, the time it takes to negotiate or otherwise arrive at the terms for purchasing the security syndicates. For example, the terms can include the interest rates, maturities, etc. The order period begins after the pricing. During the order period, the syndicate members use their sales forces to contact financial institutions, asset managers, individual investors, etc. to solicit orders for the sale of the security syndicates. Finally, there is the allotment period, wherein a syndicate manager makes a decision as to which orders will be filled (e.g., processed). This is necessary because there are times when the syndicate members receive more orders than the value of the security syndicate offering. 
     Transactions conducted during the security syndicate offering can have various degrees of importance to both syndicate and non-syndicate members. One such party (or member) is the security syndicate issuer. The issuer is the person, entity, municipality, etc. offering the security syndicates for sale. The issuer is particularly interested in the order period. The order period can provide an indication of how the security syndicates are selling. This will allow the issuer to know if the security syndicates were appropriately priced and whether the syndicate members will be able to complete the sale of the security syndicate offering. 
     Traditionally, the issuer would periodically contact a lead syndicate member (e.g., a senior manager) and request an update on the number of bonds that have been sold. Availability of a senior manager depends on the type of security syndicate offering. In a negotiated bond offering, for example, there is only one senior manager responsible for overseeing the entire deal. In a competitive bond offering, multiple senior managers can share responsibility for overseeing the deal. 
     The frequency with which the issuer contacts the senior manager depends, in part, on the particular issuer. For example, one issuer may contact the senior manager two or three times throughout the day, while another issuer may contact the senior manager every hour or even more frequently. Another factor affecting the issuer is the speed at which the bonds are being sold. For example, the same issuer may contact a senior manager more frequently if the bonds do not appear to be selling quickly. In competitive deals, the issuer may contact multiple, or all, senior managers to determine status information on the deal. 
     The process of contacting a senior manager (or multiple senior managers) can be very time-consuming and tedious. For example, the senior manager must be prepared to provide updated information regarding sale of the bonds. Since the information may be changing dynamically, the senior manager must also devote time to tabulating the information. Consequently, resources will not be available to market and solicit the sale of bonds. 
     Various electronic systems currently exist for trading bonds and managing transactions associated with bond trading. For example, U.S. Pat. No. 5,915,209 (the &#39;209 patent) to Lawrence, incorporated herein by reference in its entirety, discloses a computer-implemented bond trading system. The system attempts to facilitate a private auction of bids between a central brokers&#39; broker and multiple prospective bidders and to maintain a reference database of accurate bond lot descriptions. 
     Reference will now be made to the exemplary embodiments illustrated in the drawings, and specific language will be used here to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Alterations and further modifications of the inventive features illustrated here, and additional applications of the principles of the inventions as illustrated here, which would occur to a person skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the invention. 
     The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention. 
       FIG. 2  is an exemplary embodiment of a system for bond trading. As illustrated in  FIG. 2 , a software-enabled, computer-implemented municipal bond trading system  210  is provided for use by SEC-registered municipal bond brokers firms to serve the community of SEC-registered securities brokerage firms who deal with the public, such as selling traders  214  and buying traders  212 , for executing transactions in unlisted securities, especially municipal bonds, without disclosing the seller to the prospective buyer. The municipal bond trading system  210  enables a broker who deploys it to perform a centralized market-making function in a manner providing many of the advantages of a live exchange such as the New York Stock Exchange, without, in preferred embodiments, requiring an exchange license. Although the municipal bond trading system  210  is shown in  FIG. 2  as occupying a central function between sellers such as selling trader  214  and buying traders  212 , the municipal bond trading system  210  can include components running at the premises (e.g., a software component executing on computing devices) of buying traders  212  and at the premises (e.g., a software component executing on computing devices) of selling traders  214  to integrate both sellers and prospective buyers into a coherent market-making system. 
     A job lot  216  comprises a list of one or more bond lots, each of which is a bid wanted, offering or a dollar bond quote. “For sale” is an industry phrase that means that a seller has accepted a bid at a level reasonably close to the lot&#39;s value and will execute on the bid. A selling trader  214 , who may be an owning institution or individual but is preferably an SEC-registered securities broker dealer, transmits one or more job lots  216  of bonds for sale to the municipal bond trading system  210  maintained by a broker, who functions as a “market-maker,” at any time convenient to the selling trader  214 . Transmission of job lots  216  to the municipal bond trading system  210  can be electronically effected in a file that can be directly processed by the municipal bond trading system  210  via confidential e-mail, as are communications from the market maker to the seller, over data lines  215 . The seller can be computer-linked to the municipal bond trading system  210  on a LAN or a WAN. 
     After appropriate central processing employing the municipal bond trading system  210 , bid wanted forms are circulated to buying traders  212  in order to solicit bids  218 . Bids  218  are received from one or more buying traders  212  and transmitted to the seller by any suitable means, such as electronic transmission to the seller&#39;s computer device. If the selling trader  214  accepts the bid  218 , the brokers&#39; broker marks the lot “for sale” and completes the execution, preferably with the assistance of the municipal bond trading system  210 , and then transmits customary buy and sell tickets to the selling trader  214  for their internal processing. If traders are utilizing the system on their workstations, they will execute a “buy” utilizing the program while the broker executes a “sell.” 
     The municipal bond trading system  210  can be operated as an exchange, providing a direct transaction between a selling trader  214  and a buying trader  212 , conducted through the intermediary of the municipal bond trading system  210 . The double step required in conducting a buy-sell transaction with both the selling trader  214  and the buying trader  212 , could be eliminated. The municipal bond trading system  210  may also receive bid wanted forms in electronic form, without vocal communication, and system-select the best bid for entry and referral to the selling trader  214  for acceptance, which electronic non-vocal automated trading procedure currently requires an exchange license. The municipal bond trading system  210  can be tailored to transmit information of the transaction to the trader&#39;s in-house processing system for proper record-keeping and accounting and to maintain an inventory of bond lots in position for the trader. 
     The municipal bond trading system  210  herein facilitates fulfillment of this requirement by enabling rapid distribution of job lots  216  to a wide base of customers, selling traders, and by providing quick and efficient means for evaluating, collating and transmitting even a large number of bids  218  to the seller for further action. Before a trade is executed, a municipal bond lot must be identified with a Central Unified Security Identification Process number, herein referred to as “CUSIP (trademark)” issue identification number. CUSIP is a registered trademark of the American Bankers Association (“ABA”). The bond lot must also have an authentic description and a par value, usually some thousands of dollars, describing the size of the lot. Unlisted bond descriptions are subject to change at any time. For example, bond ratings are continually changed by rating agencies, and a bond may be called in for repayment on as little as thirty days&#39; notice. Ratings and calls are an essential part of the description of a security and can dramatically affect the character of the investment. It is accordingly highly desirable to include such changes of description in each bid wanted form before distributing it, which presents a problem. 
     To provide contemporaneous descriptions rapidly, in a manner suitable for processing lots in volume, a security master database  224  is provided, wherein bond descriptions are stored cumulatively, whenever the municipal bond trading system  210  encounters them, to be available for future use. The security master database  224  can be primed or supplemented with preferred lists of bond descriptions and has no particular limits, but it is much smaller than the reference database  222 , thus enabling a faster search and access capability. For municipal bond trading, the reference database  222  is preferably the KIS database. 
     Once prepared, the bid wanted form  226  is distributed to the buying traders  212  to enable them to bid in a timely manner. Bids are first solicited, and if necessary, collected centrally, and then evaluated to determine the high bidder. Following this process, a compilation of bids is transmitted to the selling trader  214  for action. These steps are accomplished in a silent auction, conducted electronically or on paper without the necessity of voiced person-to-person communication modes, such as telephone calls. In this silent auction, each bid wanted is provided with a bidding deadline and is broadcast to reach multiple buying traders  212  prior to that bidding deadline. Buying traders  212  wishing to bid on the lot offered are required to return a completed bid wanted form  228  to the municipal bond trading system  210  prior to the deadline if the bid is to be considered. Bidding closes when the deadline passes. After acceptance of a high bid by the selling trader  214  and the completion of any closing formalities, a bought-from ticket  234  is system-prepared and transmitted to the buyer for their records and processing, preferably electronically. 
     Buying traders  212  are linked to the municipal bond trading system  210  over a computer network so that bidding deadline alerts can be overlaid, or otherwise displayed on a buying trader&#39;s screen at various times throughout the auction process to advise of the approaching commencement of an auction on a particular lot, to warn of expiration of the time limit, and to provide interim advisories as the auction proceeds. Such alerts are preferably displayed on a system-wide basis on all selected and operational networked screens including those of brokers working with other applications on-screen at the time. If desired, bidding trader modules of the municipal bond trading system  210  can include switches or filters permitting the user to choose which alerts should be flashed on-screen or which should be allowed to interrupt other applications. 
     An on-screen bidding advisory message requires action by the buying trader  212  to remove it, such as pressing a particular key, and the advisory may include options, for example, “Display bid wanted form?”, if the form is not already on-screen. The system utilizes electronic transmissions of bid wanted forms  226  to a specified group of buying traders  212  who can receive the bid wanted form  226  electronically. This method of transmission is also suitable for distributing bid wanted forms  226  to any individual buying trader  212 . In preparing job lots  216  for electronically broadcasting, the municipal bond trading system  210  organizes all active job lots  216  in a queue so that the broker can designate, or “tag,” selected lots for electronic transmission. The system sorts the tagged lots for electronic transmission by auction time, and transmits them at predetermined interval before the auction commences. 
     The bid wanted form  226  contains the full particulars of each bid wanted lot, including its CUSIP (trademark) number and description, state of origin, maturity, par amount, and coupon values (yield and concession particulars, net yields, and dollar, gross and net dollar price) if appropriate. For use in an electronic marketing system, the form preferably also includes blank online forms to be completed by a bidding trader with bid particulars, yield, dollar or other amount, as appropriate, and bidder identifiers, including the name of the bidding trader. Yields and other calculable values can of course be system-calculated and automatically posted from base data. A buying trader  212  can quickly write minimal bid information on a hard copy of such a bid wanted form  226 , sign it, and electronically transmit it back to the market-maker, who receives a signed bid with full and accurate lot particulars complying with regulatory requirements and which does not need to be checked, verified or completed. 
     U.S. Pat. No. 5,809,483 issued to Broka et al., incorporated herein by reference, discloses an on-line transaction processing system for bond trading. The system allows for monitoring of information regarding debt securities and reporting trades in the debt securities market.  FIG. 3  is a reproduction of an exemplary embodiment of fixed income pricing system (FIPS) as disclosed in the &#39;483 patent. 
     As shown in  FIG. 3 , the FIPS processing system  300  includes business functions layer  310 , infrastructure layer  320 , and platforms layer  360 . Business functions layer  310  provides the basic services accessed by users and includes the following services: trade reports  311 , market services control  312 , quotes  313 , issues  314 , news  315 , participants &amp; users  316 , and statistics  317 . 
     Infrastructure layer  320  includes the communication mechanisms and other tools that allow the various FIPS processes to work together. Infrastructure layer  320  includes workstation services module  321 , network services module  330 , and host services module  340 . Workstation services module  321  includes those services required to use a workstation and include user interface management  322 , information model  323 , host connection  324 , broadcast receiver  425 , message handling  326 , logging  327 , and utilities  328 . 
     Network services module  330  includes those services that provide access to the entire network. These include routing  331 , message transfer  332 , and filtering  333 . Host services module  340  includes those services provided for the FIPS host and include: security service  341 , beginning-of-day &amp; end-of-day  342 , message handling  343 , communication service  344 , broadcast service  345 , timer  346 , logging  347 , message naming  348 , bond quotation dissemination system (BDQS)  349 , computer-to-computer interface (CTCI)  350 , and standard &amp; poor&#39;s (S&amp;P) data loading  351 . 
     During most system interactions, one of the services in infrastructure layer  320  will interact with one of the functions in business functions layer  310 . For example, the security service  341  works with the participant &amp; user  316  to authorize and authenticate users when they log on. Different services in infrastructure layer  320  may also communicate with each other. For example, the broadcast service  345  works with the communication service  344  to send messages to multiple platforms including PC/Windows  461  and Sun/Unix  462 . Business functions layer  310  can have relationships with each other as well. For example, FIPS system administrators may use market service control  312  with the trade reports  311  to restrict a user&#39;s ability to generate trade reports. 
     The previously described features are beneficial for addressing specific problems in the financial market. For example,  FIG. 3  addresses problems associated with monitoring debt security information and reporting trades in the debt securities market. Embodiments allow an issuer to view (on a computing device) the progress of sales of security syndicates or access information conventionally available only from a senior manager. 
     The detailed descriptions that follow may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are the means used by those skilled in the art to efficiently convey the substance of their work to others skilled in the art. 
     Referring now to  FIG. 4 , a transaction monitoring computer system  400  is shown for monitoring the flow of transactions during a security syndicate offering. The transaction monitoring computer system  400  (or issuer monitor) includes a security syndicate transaction computer system  410 , an issuer computer system  414 , and a senior manager computer system  418 . The senior manager computer system is in network connection with the other computing systems and devices, such as syndicate members  426 , sales manager computer device  420 , and sales computer devices  430 . The security syndicate transaction computer system  410  contains a plurality of subsystems, such as the illustrated webserver  412  and the processing subsystems  422   a - 422   n  (collectively  422 ). The webserver  412  may be a server configured to generate different graphical user interfaces and display them on different computing devices described herein. The processing subsystems  422  may process information pertaining to all transactions performed during the security syndicate offering (e.g., collect, analyze, and store all transaction data pertinent to the security syndicate offerings). 
     In an embodiment, the webserver  412  and the processing subsystems  422  each comprise a processor and a non-transitory computer readable medium comprising a set of instructions that are configured to be executed by each processor to display the graphical user interfaces described below ( FIGS. 7-18 ). Each instruction within the set of instructions may command and cause a different module of the webserver  412  or processing subsystems  422  to display a particular section or container of the graphical user interfaces described below. For example, a first instruction may instruct (e.g., command or cause) a first module of the webserver  412  to query pertinent data from the processing subsystems  422  and display a first section of a graphical user interface (e.g., GUI component  770  described in  FIG. 7 ); and a second instruction may instruct a second module of the webserver  412  to query pertinent data from the processing subsystems  422  and display a second section of the graphical user interface (e.g., GUI component  780  described in  FIG. 7 ). Although described herein as separate modules, it is intended that these modules can be configured as at least one module. 
     The processing subsystems  422  and the webserver  412  may be database servers comprising a processor capable of performing the various tasks and processes described herein. Non-limiting examples of the processing subsystems  422  and the webserver  412  may include a server, desktop, laptop, tablet, and the like. The processing subsystems  422  and the webserver  412  may comprise any number of computer-networking components (e.g., network interface card) that facilitate inter-device communications via the communication network  421 . One having skill in the art would appreciate that there may be any number of distinct computing devices functioning as the processing subsystems  422  or the webserver  412  in a distributed computing environment. The webserver  412  may host an online service, such as cloud-computing application service, or any other service that provide customer-facing web-based applications that collect transaction data through web-based client interactions over one or more networks such as the communication network  424 . Simply put, the processing subsystems  422  may collect and analyze transaction data and the webserver  412  may generate and display or display different graphical user interfaces on different computing devices described herein. Even though  FIG. 4  illustrates the processing subsystems  422  and the webserver  412  as separate computing features, in some embodiment, they may be functionally combined together. In other words, the security syndicate transaction computer system  410  may only comprise one server that performs as both the processing subsystems  422  and the webserver  412 . The security syndicate transaction computer system  410  can also include a computer (not shown) functioning as a server for interacting with both internal and external subsystems. In operation, the security syndicate transaction computer system  410  is a computing system (comprising multiple servers, computers, and databases) that monitors the security syndicate offering and generates multiple graphical user interfaces (described below) and display/render them on computing devise described within  FIG. 4 . 
     As used herein, a security syndicate refers to financial securities (or other financial instruments) offered for sale, and subsequently sold to buyers. A security syndicate offering refers to any procedure during which the security syndicates are offered for sale to generate funds and/or revenue. The financial instruments include, but are not limited to, municipal bonds, short-term bonds, long-term bonds, stocks, etc. 
     The issuer computer system  414  and senior manager computer system  418  comprise at least one computer system such as issuer&#39;s computer  416  (operated by an issuer) and senior manager computer  420  (operated by a senior manager) and a local database to store transaction data. The issuer computer system  414  and senior manager computer system  418  may comprise multiple computers operated by multiple issuers and managers; these computers are not all shown for clarity. The issuer&#39;s computer  416  and senior manager computer  420  may execute predetermined program commands for interfacing with the security syndicate transaction computer system  410  for participating in the security syndicate offering. Issuer&#39;s computer  416 , syndicate members  426   a - 426   n , sales desk computer  428 , sales computer device  430 , and senior manager computer  420  may be any electronic device suitable for displaying graphical user interfaces for a user, such as a workstation, desktop computer, laptop computer, smart phone, tablet computer, smart watch, or the like. The issuer computer system  414  and senior manager computer system  418  access the security syndicate transaction computer system  410  over the communication network  424  such as, for example, the Internet to access the graphical user interfaces provided by the security syndicate transaction computer system  410 . It should be noted, however, that various other networks could be used including, but not limited to, direct-dial closed networks, private local area networks (LANs), wide area networks (WAN), etc. 
     During the security syndicate offering, the issuer computer system  414  offers one or more security syndicates for sale. This offer can be presented in various forms, including an electronic message communicated to the security syndicate transaction computer system  410 . The electronic message would contain all the necessary information for processing the security syndicate offering and subsequently selling the security syndicates (e.g., financial instruments). The information may be stored on the processing subsystems  422  where it can be restrictively accessed by the senior manager computer system  418 . The webserver  412  can control the restrictive access, for example, by means of a username and password that uniquely identifies the senior manager computer system  418 . Thus, it is possible for the transaction monitoring computer system  400  to support multiple senior manager computer systems and multiple issuer computer systems simultaneously interacting with the security syndicate transaction computer system  410 . Each senior manager computer system  418  and/or issuer computer system  414  would be restricted to viewing security syndicate offerings of which they are a part, thus addressing privacy and/or security concerns. 
     The senior manager computer system  418  is part of a syndicate group containing various entities. However, the senior manager computer system  418  is responsible for managing transactions that ultimately lead to the sale of the security syndicates. Consequently, the senior manager computer system  418  may be the only entity in the syndicate group that can access the security syndicate transaction computer system  410 . As previously indicated, the syndicate group includes a plurality of syndicate members  426   a - 426   n  (collectively  426 ) that share liability for the security syndicate offering. The syndicate group can also include a sales desk computer  428  operated by the senior manager&#39;s staff for soliciting sale of the security syndicates from the security syndicate offerings. Likewise, the syndicate members  426  can include their own sales divisions  430   a - 430   n  (collectively  430 ) that solicit sale of the security syndicates from various institutions and/or investors. The syndicate members  426  can optionally solicit sales from the institutions directly without the use of a sales desk computer  428 . 
     During the security syndicate offering, all data relating to the order and/or sale of the security syndicates are transmitted to the senior manager computer system  418 . This information is subsequently transmitted from the senior manager computer system  418  across the communication network  424  (e.g., the Internet) to the security syndicate transaction computer system  410 . The senior manager computer system  418  is also capable of transmitting information regarding the security syndicate offering to the syndicate members  426  (e.g., computer device associated with each syndicate member). 
     The issuer computer system  414  communicates with the security syndicate transaction computer system  410  in order to monitor transactions being conducted during their particular security syndicate offerings. As previously stated, the senior manager computer system  418  transmits data corresponding to such transactions to the security syndicate transaction computer system  410 . Accordingly, this information is accessible by the issuer computer system  414  in order to monitor the security syndicate offering. The data corresponding to the transactions is preferably displayed on the issuer&#39;s computer  416  and automatically updated in real time. For example, every time the senior manager computer system  418  transmits information to the security syndicate transaction computer system  410  regarding a transaction, that data would be automatically transmitted to the issuer&#39;s computer  416  to update the records. Alternatively, the issuer computer system  414  can manually select to update information regarding the security syndicate offering. Such a procedure would cause the issuer&#39;s computer  416  to transmit a message to the security syndicate transaction computer system  410 , and access the most recently uploaded data using variety of the graphical user interfaces provided by the security syndicate transaction computer system  410 . 
     According to one embodiment, the issuer&#39;s computer  416  can be configured to correlate data received from the security syndicate transaction computer system  410  and generate reports that represent the progress of transactions during the security syndicate offering. The reports can be in various forms including, for example, tables, graphs, etc. In addition, the issuer&#39;s computer  416  can be optionally configured to process the data received from the security syndicate transaction computer system  410  and identify certain trends such as a reduction in the rate of orders being submitted, an increase in the rate of orders being submitted, a change in the relative distribution of orders being received, etc. The trends can be generally considered as indicators of the progress of the security syndicate offering. Based on these identified trends, the issuer computer system  414  can optionally contact the senior manager computer system  418  in order to incorporate changes designed to achieve predetermined results. For example, if an identified trend shows that the number of orders being received, or the rate at which orders are being received is going down, the issuer computer system  414  may wish to contact the senior manager computer system  418  to discuss a change in pricing that would make the security syndicates more attractive to buyers and/or investors. For example, if the security syndicates are municipal bonds, the issuer computer system  414  might suggest a reduction in the interest rate and/or a change in the maturity structure of the bonds. In essence, the issuer computer system  414  will attempt to identify negative trends (using the graphical user interfaces described below) in the sale of the security syndicates, and take appropriate steps to correct those trends. Similarly, if the issuer computer system  414  determines the rate of sale of the security syndicates to be too high, the issuer computer system  414  may contact the senior manager computer system  418  and, for example, increase the interest rate of the bonds. 
     In operation, the webserver  412  may be in communication with all the computing entities described herein in order to provide the latest and most accurate transaction information to all the parties. The webserver  412  may query the latest data from the processing subsystems  422  and generate a variety of graphical user interfaces (e.g.,  FIG. 7 - FIG. 11 ) displayed on computing devices operated by the parties described herein (e.g., issuer&#39;s computer  416 ). For example, the processing subsystems  422  may collect and analyze transaction prices from the issuer computer system  414  and display different graphical user interfaces on computing devices operated by the senior managers, syndicate members, and sales members. Upon receiving any modification data (e.g., a bid, order, counter offer, and the like) the processing subsystems  422  may then modify the transaction data and the webserver  412  may display a new graphical user interface (or update the same GUI in real time) using the updated transaction data and display said data on the issuer computer  416 . The webserver  412  may continuously update the graphical user interfaces displayed on computing devices operated by different parties. In this way, all parties described herein may have access to the latest and most accurate transaction data displayed on a specifically designed easy-to-digest graphical user interface. The webserver  412  is also configured to provide raw data (presented in tabular form) upon the issuer&#39;s request. 
     The processing subsystems  422  are also configured to collect and store all transaction data in a local or remote database. The processing subsystems  422  may monitor all transaction modifications (price modifications by the issuer computing system  414 , bids received from the sales computing devices  430  or syndicate member  426 , and communications between all the parties described herein). The processing subsystems  422  may generate a deal dataset for each deal (e.g., syndicate offering) and store the above-mentioned data as metadata within the deal dataset. The processing subsystems  422  may also store additional data, such as an economic calendar including market conditions, price tickers, geographic location of the bidders and buyers, and the like within the above-mentioned dataset. In this way, a party with access to a deal dataset (e.g., a deal snapshot) is able to review a thorough history of the deal from the beginning (e.g., when the issuer indicates the initial price) to the end (e.g., when the syndicate offering is terminated and maturities are sold). 
     Referring to  FIG. 5 , a flowchart is illustrated for displaying exemplary steps performed when monitoring the flow of transactions during a security syndicate offering. During the security syndicate offering, the senior manager computer system  418  principally interacts with the security syndicate transaction computer system  410  and the syndicate members  426 . However, the issuer computer system  414  also has an ability to monitor the transactions being conducted, as will be described further herein below. While the below described steps are in a particular sequence, it is possible to alter the sequence of steps and/or perform some or many of the steps in parallel. Further, the specific exemplary steps/systems described herein are described in connection with an issuer syndicate financial transaction. However, embodiments may easily be adapted to a variety of financial transactions, as necessary. At step  510 , the issuer computer system  414  accesses the security syndicate transaction computer system  410 . As previously stated, this step can be performed using the issuer&#39;s computer  416  to contact the security syndicate transaction system subsystems via the communication network  424 . Upon contacting the security syndicate transaction computer system  410 , the issuer computer system  414  can optionally be requested to supply a username and password that uniquely identifies the issuer computer system  414  and restricts the information accessible by the user. 
     At step  512 , the current security syndicate offerings available from the issuer computer system  414  are displayed on the issuer&#39;s computer  416 . Depending on the particular issuer computer system  414 , there may be one or more security syndicate offerings available at any given time. According to one embodiment, the security syndicate offerings can be presented in the form of a calendar menu displaying one or more security syndicate offerings available from the issuer system  114 . The calendar menu can also display general information regarding each security syndicate offering, such as the value, closing date, and a brief description. At step  514 , the issuer computer system  414  selects a particular security syndicate offering to monitor. Depending on the particular computer software being used by the issuer computer system  414 , the security syndicate offering can be selected, for example, using a graphical input/selection device such as a mouse or stylus, or by entering a predetermined keystroke or command using the keyboard. 
     At step  516 , the issuer&#39;s computer  416  displays deal information corresponding to the selected security syndicate offering. The deal information can include, for example, the closing date, financial structure, rating, etc. for the selected deal. At step  518 , it is determined whether an expiration time has been reached. The expiration time corresponds to the time at which the security syndicates are no longer available for sale. If the expiration time has been reached, then the selected security syndicate offering is identified as being closed (step  520 ), and control passes to block  3 . If the expiration time has not been reached, then the deal information on the issuer&#39;s computer  416  (the graphical user interface displayed on the issuer&#39;s computer  416 ) is updated. 
     At step  524 , data received for the deal information is correlated. Correlation of the received data can vary depending on the particular security syndicate offering and issuer computer system  414 . In essence, the issuer computer system  414  is free to dictate the type of information that they seek while monitoring transactions. Thus, one issuer may desire that the correlated data quickly provide an indication of the number of security syndicates being sold. Another issuer may require that the correlated data quickly provide an indication of the rate at which the security syndicates are being sold. Yet still another issuer may require that the correlated data quickly identify the geographic distribution for sales of the security syndicates. 
     At step  526 , the issuer computer system  414  decides if a report should be generated. If no report is desired at the time, then control passes to block  2 . If, however, the issuer system  414  would like to prepare a report, then control passes to step  528  where the report is generated. The reports can also vary depending on the particular issuer&#39;s requirements, and are primarily intended to present information that will assist the issuer computer system  414  in following and understanding the progress of transactions during the security syndicate offering. For example, one embodiment provides for reports that present a graphical analysis of the correlated data. Thus, the report can optionally correspond to the manner in which the data is correlated. At this point, control can return to step  518  where it is again determined if the expiration time has been reached. 
     According to one embodiment, after generating the reports at step  528 , control passes to step  530 . At step  530 , the issuer computer system  414  and/or issuer&#39;s computer  416  identifies trends in the report generated. As previously indicated, the trends can be considered as indicators of the progress of the security syndicate offering. Depending on the particular trend identified, the issuer computer system  414  may optionally contact the senior manager computer system  418  at step  532 . At step  534 , the senior manager computer system  418  can adjust various values in the security syndicate offering to make the security syndicates either more attractive or less attractive to potential buyers. These adjustments in values are made based, at least in part, on information and/or permission received from the issuer computer system  414 . After the values have been adjusted, control returns to step  518 . It should be noted, however, that the senior manager may independently adjust these values without contacting the issuer, depending on the particular security syndicate offering and the relationship with the issuer. 
     Referring to  FIG. 6 , if the issuer computer system  414  did not request a report at step  526 , then control would now pass to step  536  (from control block  2 ). At step  536 , it is determined whether a second expiration time has been reached. The second expiration time corresponds generally to a time frame during which orders for the security syndicates will be accepted. This often referred to as the order period. If the second expiration time has not been reached, then control passes to block  1 . Block  1  returns control to step  522  and the process continues as previously discussed. 
     If the second expiration time has been reached, then at step  538 , it is determined whether the current transaction value is greater than the security syndicate offering value. The transaction value corresponds to the monetary value of the security syndicates that have successfully been sold. The security syndicate offering value corresponds to the total monetary value of the security syndicate offering. Referring additionally to  FIG. 5 , if it was determined at step  518  that the expiration time had been reached, then the deal would be closed and control would have passed to block  3 . As shown in  FIG. 6 , block  3  directs control to step  538 . If the transaction value is not greater than the security syndicate offering value, then control passes to step  540 . 
     At step  540 , information is transmitted to the issuer&#39;s computer  416  so that the issuer computer system  414  may view a display of residual deal information. The residual deal information will generally correspond to security syndicates, or the amount of the security syndicates, that have not been sold after the security syndicate offering is closed. Control then passes to step  542 . In addition, if the transaction value was determined to be greater than the security syndicate offering value, then control would also have passed to step  542 . At step  542 , information is transmitted to the issuer&#39;s computer  416  so that additional deal information can be displayed to the issuer computer system  414 . The additional deal information corresponds to allotment information for the sale of the security syndicates. The additional deal information can include, for example, the names of the financial institutions that are purchasing the security syndicates and the value of the purchases. 
     At step  544 , it is determined if a third expiration time has been reached. The third expiration time generally corresponds to the end of an allotment period for allotting the security syndicates to various institutions and/or investors. If the third expiration time has been reached, then the security syndicate offering is closed (step  546 ). If the third expiration time has not been reached, then control passes to step  548 . At step  548 , data is transmitted to the issuer&#39;s computer  416  to update the additional deal information. At step  550 , the issuer computer system  414  and/or issuer&#39;s computer  416  correlate the additional deal information. At step  552 , the issuer computer system  414  determines if a report should be generated. If a report should be generated, then control passes to step  554 . Otherwise, if a report will not be generated, then control passes to step  544  where it is again determined if the third expiration time has been reached. Once the report has been generated at step  554 , the process can either end, or optionally return to step  544 . 
     As previously discussed, data can be transmitted to the issuer&#39;s computer  416  for purposes of updating the deal information and the additional deal information, either automatically or manually. For example, automatic updating would occur by the security syndicate transaction computer system  410  transmitting the updated data to the issuer&#39;s computer  416  every time the senior manager computer system  418  transmits transaction data to the security syndicate transaction computer system  410 . Alternatively, the issuer computer system  414  can select a refresh button on the computer display to manually request transmission of updated data from the security syndicate transaction computer system  410 . 
     The system described herein (sometimes referred to as “book running system) can be used to control the flow of information between syndicate members  426  during security syndicate offering. The book running system provides the senior manager computer system  418  with at least some of the tools necessary to configure, manage, and process the security syndicate offering. Thus, the book running system would provide the senior manager computer system  418  with an ability to collect and enter data pertaining to the syndicate group and the security syndicate offering. Once the data has entered, the embodiments may be used by the issuer computer system  414  to monitor the flow of transactions. In some embodiments, a user such as an issuer may be connected via their mobile phone or a computer to the systems described in  FIGS. 2-4 , which displays for them the active issuance of bonds and other financial instruments at different maturity bonds. 
       FIG. 7  illustrates a graphical user interface displaying syndicate offering data, according to an embodiment. The illustrated graphical user interface (GUI)  700  may be presented on an issuer&#39;s electronic device such as a computer, tablet computer, smart phone, or the like. The GUI  700  may include a recent orders tab that illustrates the recently ordered maturity bonds (not shown), a summary tab that illustrates all the maturity bonds (not shown), a top managers and accounts tab that illustrates the top managers associated with a subset of maturity bonds (interactive hyperlink  720 ), and an overview section ( 710 ). 
     The overview section  710  (illustrated in GUI  700 ) may include the illustrated vertical bar charts with a line illustrated within the chart. Each vertical bar (for example vertical bar  740 ) may represent a maturity such as a maturity for a specific year and month. The height of the bar may represent a dollar amount for that maturity. For example, the vertical bar  740  represents the total dollar amount for a particular maturity for December 2035. The line in the bar (e.g., line  750 ) represents the total number of dollars that are available in the par amount for the maturity. Therefore, the area filling the bar chart above the line indicates the amount that a maturity is oversubscribed. The number  760  (illustrated on the top of each vertical bar) may indicate how much each maturity is oversubscribed. GUI  700  is configured to illustrate any transaction data regarding any security syndicate and is not limited to maturity bonds. 
     “Oversubscribed” is a term used for situations in which a new security issue, such as a stock or bond, is underpriced or in great demand by investors. When a new security issue is oversubscribed, the parties offering the security (e.g., issuers) can adjust the price or offer more securities to reflect the higher-than-anticipated demand. For example, the number  760  indicates 2.0×, and number  761  indicates 1.7×; the number  760  indicates that the December 2035 maturity bond is oversubscribed by two times and the number  761  indicates that December 2042 maturity bond is overs subscribed by a factor of 1.7 times. Typically, an oversubscribed maturity bond offering indicates that the bond is in high demand, and therefore, a price increase by the issuer may be justified. A negative number (e.g., undersubscribed number of −1.0) indicates that the demand is less than the offered amount; therefore, a price decrease may be needed. The GUI  700  allows the parties involved in bond trading (particularly the issuers) to easily and quickly determine whether to increase or decrease the price for a particular bond with specific maturity dates. 
     The GUI  700  also provides different lens options (illustrated at the top of the GUI  700  as different toggles), which when clicked by the user, may display or modify the GUI  700  to display a specific category of maturity bonds. For example, the user may click on retail (interactive hyperlink  730 ) or managers (interactive hyperlink  720 ). When a user clicks on retail (interactive hyperlink  730 ), several columns may be grouped into one and their accumulated data reflected based on a specific retailer. Selecting manager (interactive hyperlink  720 ) may allow a user to see all data sorted based on their respective sales manager (e.g., what maturity bonds are being sold and how they are performing under that manager). Clicking on manager (interactive hyperlink  720 ) may also allow the user to further select a manager and view all maturity bonds related to that manager (e.g., all maturity bonds under the particular manager&#39;s management or bids approved by the manager). Utilizing this feature, users can quickly gage each manager&#39;s performance. Similarly, clicking on retail (interactive hyperlink  730 ) allows the user to narrow the bonds displayed by a particular retailer and gage that particular retailer&#39;s performance. 
     GUI component  770  may include recent orders that were placed or processed. GUI component  770  may be dynamically updated in real time (e.g., as the orders are received and/or processed). Therefore, the most recent order may be presented on the top or the bottom of the recent orders list. For example, order  771  indicates that Fund A has placed an order for 3,535 orders of a December 2022 bond. Order  772  illustrates an order for 3,375 orders for a December 2021 bond by the same Fund A. Clicking the option “View All” (interactive hyperlink  773 ) presents a pop up of all the orders. Similarly, “View All” may take the user to another screen with a complete list of all the orders, which may be customized, sorted, and filtered by a variety of factors, such as amount, ordering entity, time of order, and the like. The user may utilize the GUI component  770  to track individual orders as they are received (e.g., received by the security syndicate transaction computer system). The users are also able to sort the orders by geographic location (e.g., zip code associated with the orders). For example, the GUI  700  may display a map and indicate all the orders received in a user-friendly manner (e.g., heat map or color coded). The webserver may be dynamically display and continuously update the GUI component  770  in order to illustrate the latest order data. Utilizing the data displayed in the GUI component  770 , users may quickly be able to see order size, maturity, geographic data, investor name and the manager that has approved the order another example of displaying orders is described in  FIG. 18 . 
       FIG. 16  illustrates a graphical user interface displaying syndicate offering data and geographic analysis of the orders, according to an embodiment. As described above, in addition to displaying the maturity bond data, the webserver  412  may also display geographical and order analysis. For example, GUI  1600  illustrates that, in some embodiments, the webserver  412  may display the maturity bond data (GUI component  1610 ) as described in  FIG. 7 , latest order data (GUI component  1620 ) as described in  FIG. 7 , geographical analysis (GUI component  1630 ), and granular order data (GUI component  1640 ). The GUI component  1630  may display a heat map of order locations (e.g., location from which the orders have been received). A heat map is a representation of data in the form of a map or diagram in which data values are represented as colors. For example, as illustrated by the GUI component  1630 , when more orders are received from a geographic location, that geographic location is displayed using darker colors. The location analyzed may be limited to a specific state (e.g., as illustrated by the GUI component  1630 ) or illustrate a nationwide study of all orders received. 
     The GUI component  1640  is a pie chart that represents a granular analysis of all the orders received. A pie chart is a type of graph in which a circle is divided into sectors that each represents a proportion of the whole. For example, the pie chart illustrated in GUI component  1640  illustrates different sectors that represent different type of investors who have placed orders for maturity bonds illustrated in GUI component  1610 . The colors used in the pie chart may match the color used to illustrate the orders in GUI component  1610 . In some embodiments, a user may export the GUI  1600  (e.g., save and transmit all the data) to another electronic device. For example, an issuer may save a snapshot of the GUI  1600  (e.g., image or a file comprising metadata that represents all the information represented in GUI  1600 ). The snapshot file may be shared with other computing devices and transmitted over a network (e.g., Internet). 
     The summary tab (GUI component  780 ) may include a countdown clock, the total orders that have been received, percentage indicators for short, mid, and long-term bonds, and a total order fill indicator. Another illustration of the summary tab is presented in  FIG. 8 . In GUI component  780 , an indicator of the total orders (in dollars or any other specified currency) is displayed. In the example illustrated in  FIG. 8 , for example, $232,345 of orders have been placed (GUI component  781 ) with an oversubscription factor of %140 or 1.4× (GUI component  782 ) when four hours, forty-three minutes and twenty seconds remain before the end of issuance (GUI component  783 ). Further, the GUI component  784  presents orders that are filled (e.g., processed). In this example, the GUI component  780  displays $162,140 ( 784 ) with a remaining balance of $7,205 (GUI component  785 ) and a fill rate indicator  786  that states 96% (e.g., 96% of the order have been processed/filled). The short, mid and long maturity bonds may be categorized and indexed showing what percentage of the orders are in each category (e.g., fill rate indicators  787 - 789 ). 
     As described herein the terms short, mid, and long refer to a relative time for which the maturity bond matures. For example, if a maturity bond matures in five years, the maturity bond may be considered a short because a client may have selected all bonds maturing within the next ten years to be considered “short.” These time thresholds may be predetermined or received from the client (e.g., issuer&#39;s computer described in  FIG. 4 ). Displaying the short, mid, and long fill indicators can be useful during the day of a transaction or the day of issuance as issuers may proactively and quickly see which groups are low or high where live pricing may be altered. For example, if short-term maturity bonds (e.g., 0-10 years) are 20% and long term are 80%, an issuer may lower prices of short term and/or raise prices of long term in order to balance orders. Fill rate indicators (e.g., fill rate indicators  787 - 789 ) may be updated in real time to accurately and quickly indicate above-mentioned fill rates and indicate the overall deal progress across the entire curve or by sections (e.g., they may be customized and filtered by the user to show only a desired cross sections of orders). 
     Referring back to  FIG. 7 , GUI  700  may also include a GUI component  790 . GUI component  790  may display the top managers and accounts and may track aggregate investor and syndicate member participation on a particular deal. For example, GUI component  790  may display the largest participant on top or arranged vertically by size (or any other method customized by the user). Another exemplary illustration of the top managers and top accounts tab is presented in  FIG. 9 . In GUI component  790 , users may generate reports to get a thorough breakdown of orders by either syndicate member or investors across priority types, syndicate member types or investor types. As shown in  FIG. 9 , the top accounts of Asset Manager A, Asset Manager B, XYZ Capital, etc., may be presented sequentially. For example, as illustrated, Asset Manager A is listed as having 53,000 orders and Asset Manager B as 37,500 orders. Similarly, number of maturity bonds may be displayed and used to organize the display order. In this way, issuers are able to see who is ordering the most and by how much. 
     Further, clicking on the names or rows of each asset manager displayed in GUI component  790  may bring a pop up GUI component or display of the account profile for that manager or account. The profile may include the holdings data for that manager/account. For example, the types of investments the manager has under management may be displayed. Similarly, contact information may be displayed including telephone number, work address, email address, geographic location, and URL. Finally, the type of money being managed may be displayed such as bond fund, hedge fund, etc. Clicking on the manager&#39;s name may include how their portfolios are broken down such as how many bond funds, how many mutual funds and how much managed account money is being received. The insurance type may be displayed with options such as whether new property or casualty are part of the assets in the account. 
     Referring now to  FIG. 15 , an example of a pop up GUI component displaying manager profiles is illustrated. By clicking on XYZ capital displayed on GUI component  790 , pop up GUI component  1510  may be displayed. Pop up GUI component  1500  may comprise the name of the XYZ Capital, currency in which XYZ Capital trades, and a location associated with the XYZ Capital in GUI component  1510 . GUI component  1520  may display total assets and an overview of the XYZ Capital&#39;s financial portfolio. Furthermore, GUI component  1530  may display an order summary of the XYZ Capital (e.g., amount and number of orders and other pertinent order information). GUI  700  may display the pop up GUI component  1500  in a separate page (displayed on a separate graphical user interface or a webpage) or display the pop up  1500  as a top layer displaying alongside the GUI  700 . 
     Referring back to  FIG. 7 , GUI  700  may also include a GUI component  791  that is configured to display market data as customized by the user, such as a price ticker, S&amp;P 500, Dow, Oil, Gold, or Muni ticker or index, current market news (e.g., financial news), and the like. For example, the user may customize the GUI component  791  to display a stock price ticker. A stock ticker is a report of the price for certain securities, updated continuously throughout the trading session by the various stock exchanges. A “tick” is any change in price, whether that movement is up or down. In some embodiments (as described in  FIG. 14 ) by selecting GUI component  791 , GUI  700  may display a pop up comprising additional and relevant economic data. 
       FIG. 14  illustrates a graphical user interface displaying syndicate offering data and additional economic data, according to an embodiment. In some embodiments, the webserver  412  may display economic data in addition to the maturity bond data. For example, upon a user engaging with a selectable GUI component (such as GUI component  791  described above), the webserver  412  may display a pop up window (such as pop up  1410 ) or a sliding GUI component comprising customizable economic data. Pop up  1410  may include S&amp;P 500, Dow, Oil, Gold, or Muni ticker, United States Treasury Yield Rates (UST), Municipal Market Data (MMD) timelines, and an economic calendar (e.g., a calendar used by traders for the purpose of tracking the occurrence of market-moving events). The user may customize the economic data viewed. For example, the user may customize the pop up  1410  to display S&amp;P 500 price ticker instead of a gold price quotes. The user may also customize the color, font, and display location of the pop up  1410  or any economic data displayed. 
       FIG. 10  illustrates another embodiment of the graphical user interface displayed for different parties described in  FIG. 4 . Some embodiments may include order control where a user may select various lenses to view an order book (e.g., portfolio of all the security syndicates) across tranches, including a general overview by priority type, retail categories and manager type. A user may click on any maturity bond displayed on GUI  1000  (e.g., selectable bar  1010 ) to retrieve further detail of the tranche and its orders. This feature is further described below. In some embodiments, a user may search for or select from a dropdown menu (e.g., menu  1020 ) any investor or syndicate member and view all their orders. For example, when the user clicks on the menu  1020 , GUI  1000  may generate and display the pop up  1021  that comprises different accounts and different managers). Once the user clicks on any of the managers or accounts, the GUI  1000  may display a new interface that only displays order information filtered by the selected manager or account. Similarly, the user may directly search for a particular manager or account using the search engine  1030 . A user may also view maturity bonds by series, coupon, or any other attributes that the user deems fit and combine into a single maturity at the click of a button. 
       FIG. 11  illustrates another embodiment of the graphical user interface displayed for different parties described in  FIG. 4 . When a user clicks one of the bar charts or maturity bond displayed on the GUI  1100  (e.g., selectable bar  1110 ), GUI  1100  may display more granular data regarding that bond or order. In the example illustrated in  FIG. 11 , the bar chart  1110  has been clicked by the user. In response, GUI  1100  populates and displays GUI component  1120  (In the portion of the user interface below the selectable bar chart  1110  (or any other portion of the GUI  1100  as customized by the user). GUI component  1120  may be a pop up window or as a separate portion of the same window that displays data relevant to selectable bar  1110 . In the example illustrated in  FIG. 11 , the information displayed in GUI component  1120  is the series, the number of orders, the coupon rate, insurance information, the yield/price of the maturity, the amount of subscription, and the par value. A skilled artisan will appreciate that the information displayed in the pop up may be customized by the user or may be automatically generated based on the user&#39;s preferences or user&#39;s role. Further, the bar chart is zoomed in (e.g., is displayed using a larger font and a scale) with the dollar values that are easier to see for the par value and current subscription. GUI  1100  may also include order information for the maturity represented by selectable bar chart  1110 . For example, GUI component  1130  lists order #2 for Manager Bank A and Account Asset Manager A to be at $40,000 (million). Similarly, order #13 at the bottom of the list is displayed as $1,000 (million) for Account Company B with Bank A again as the Manager. As described above, a user can easily peruse detailed information associated with different maturities. The user may also be able to glance (e.g., during a three to five second test) and see that the December 2019 maturity is two times over, the December 2021 maturity is 4.3 times over and the December 2031 maturity is two times over. 
       FIG. 12  illustrates multiple graphical user interfaces displaying syndicate offering data using a client&#39;s customized graphical user interface, according to an embodiment. In some embodiments, the webserver  412  may also have access to one or more databases or pre-stored web-based interfaces, such as webpages, comprising a number of preconfigured sub-interfaces or containers, dynamically populated from the transaction data analyzed. The webpages may be operated by a client (e.g., issuer computer system) and may contain proprietary code, such as HTML or PHP, presenting a variety of private content not known to the webserver  412  (e.g., GUI component  1230 ). These webpages may contain additional code for containers, where the container code may be modified to display customized content. In order to preserve the common “look-and-feel” of the client website and in order to create a better user experience, the webserver  412  may access the container code and display any of the graphical user interfaces described above within the client website/webpage. 
     For example, instead of displaying separate graphical user interfaces on computer devices of an issuer Entity XYZ, the webserver  412  may query container code for the webpage  1200  (operated by the issuer entity XYZ and viewable only to XYZ employees) and populate the sub-interfaces  1210  and  1220  of the webpage  1200  with the appropriate data. The webserver  412  may display any of the above-mentioned graphical user interfaces while the webpage display is configured to maintain the website&#39;s common aesthetic (e.g., other features displayed by the issuer entity XYZ, such as GUI component  1230 ). One skilled in the art will appreciate that the issuing company XYZ may be able to customize the font, size, color, coordinates and other attributes of the sub-interfaces  1210  and  1220 . 
       FIG. 13  illustrates a graphical user interface displaying syndicate offering data in a tabular form, according to an embodiment. In some embodiments, the webserver  412  may provide raw data (maturity bond data presented in tabular form) upon the issuer&#39;s request. For example, a selectable GUI component may be presented to the user and, upon the user engaging the selectable GUI component, a graphical user interface (such as GUI  1300 ) may display raw data corresponding to the maturity bonds displayed in a tabular form. Row  1310  may display the maturity date, series indicator, coupon percentage amount, maturity bond amount, break down of different retailers (e.g., NJ retailer, national retailer, total retailer), overall balance and whether the maturity bond is oversubscribed. 
     The processing subsystems  422  may also store additional data, such as an economic calendar including market conditions, price tickers, geographic location of the bidders and buyers, and the like within the above-mentioned dataset. In this way, a party with access to a deal dataset (e.g., a deal snapshot) is able to review a thorough history of the deal from the beginning (e.g., when the issuer indicates the initial price) to the end (e.g., when the syndicate offering is terminated and maturities are sold). 
     As illustrated by  FIG. 17 , users may customize the display of maturity bonds using various methods. For example, in GUI  1700 , different maturity bonds are displayed. Each maturity bond (e.g., maturity bond  1711 ) displays the maturity date and is color coded (based on the legend  1720 ) to illustrate the orders received from different geographic locations. By customizing the GUI  1700 , the user may only view the orders received from New Jersey and compare the order received from New Jersey with the orders received nationwide. In some embodiments, if a particular maturity bond is oversubscribed (e.g., maturity bond  1711 ), different colors representing the orders may exceed the bounds of the maturity bond  1711 . On the other hand, if the maturity bond is undersubscribed (e.g., maturity bond  1712 ), the color representing different orders may be shown in proportion to the undersubscription ratio. In other words, maturity bond  1712  is 50% undersubscribed; therefore, the graphical representation of the maturity bond  1712  represent a half-empty bar chart. 
       FIG. 18  illustrates a GUI component that efficiently displays the orders, according to an embodiment. As described above, different GUI components may display orders. For example, GUI component  770  (described in  FIG. 7 ) may display recent orders that were placed or processed and may sort the orders based on time received, managers associated with the order, or the amount of the order. In another non-limiting embodiment, GUI component  1800  may dynamically display the orders based on the performance of the associated maturity bond. For example, GUI component  1800  may display that Bank  1  has placed an order for $5000 on maturity bond Fund A. Additionally, a performance indicator  1810  may be displayed that allows the user to quickly gage the performance of Fund A. Performance indicator  1810  may comprise a subscription rate indicator  1820  that graphically illustrates whether Fund A is oversubscribed or under subscribed. The subscription rate indicator may comprise a fill bar that is filled in accordance to a subscription percentage. For example, when a maturity bond is fully-subscribed, the subscription rate indicator is shown as filled (e.g., subscription indicator  1830 ) and when a maturity bond is half subscribed, the subscription rate indicator is half-filled. Performance indicator  1810  may also illustrate an order process rate for each maturity bond. For example, when 0% of the orders for a maturity bond have been processed, the subscription rate indicator may appear on the left of the performance indicator (e.g., subscription rate indicator  1820  being displayed on the left side of the performance indicator  1810 ) and when 100% of the orders for a maturity bond have been processed, the subscription rate indicator may appear on the right side of the performance indicator (e.g., subscription rate indicator  1840  being displayed on the right side of the performance indicator  1850 ). One skilled in the art will appreciate that other methods may be used to illustrate the performance of each maturity bond, such as color coding the performance indicator. 
     Embodiments implemented in computer software may be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc. 
     The actual software code or specialized control hardware used to implement these systems and methods is not limiting of the invention. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description herein. 
     When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media may comprise Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product. 
     The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein. 
     While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.