EP1290608A1 - A method and system for web based straight through processing - Google Patents

Description

A METHOD AND SYSTEM FOR WEB BASED STRAIGHT THROUGH PROCESSING

TECHNICAL FIELD This invention relates to the field of computers, telecommunications and Internet based systems. More particularly, the present invention relates to a method and system for supplying straight through processing services to the financial community with particular focus on systems to support financial asset management.

BACKGROUND ART A technical problem presently exists in the attempt to close a financial transaction, such as a security purchase for example, in one business day. Current automated systems which connect financial market players (i.e. investment managers, broker-dealers, banks, financial instrument depository organizations, and infrastructure service provider), currently require three days (T+3) to clear a transaction (that is, have the money change hands and stock ownership records changed). The underlying computer and telecommunications systems infrastructure at each of the major players is complicated by each player's accounting system (needed to provide legally required records and to support payment of the players for their efforts), by complex 'authorization & verification' protocols (between the computer systems of the various players), by many manual processes and by the legacy hardware and software in use. Such systems cannot be easily modified to accommodate a one day closing (T+l) process. As explained in more detail below, the exponential growth in the trading volumes in the U. S. stock markets in terms of shares traded and money involved (fueled in large part by the growth of the Internet, 24 hour trading capability, etc.) have created such a staggering amount of money (float) attendant to the three days clearance process, that the Securities & Exchange Commission has encouraged the creation of a one day clearance cycle (T+l) in order to minimize this float with the recommendation that this process be implemented by June 2002. This is not deemed to be a firm date but rather it is a target proposed by the SEC and various consortia of trading members. Some groups, such as the Securities Industry Association (SIA), Industry Standardization for Institutional Trade Communications (ISITC), and other industry groups have not endorsed this date but are attempting to define and build systems to be in place as soon as possible. The current T+3 clearance process may be visualized with reference to Figure 2 wherein is shown an exemplary depiction of the processes in the lifecycle of a customer buy trade of either domestic securities or corporate/municipal bonds initiated and settled in the U. S. Domestic market. The assumptions are that all trading is in block form, all securities are immobilized in the depository and all trades are for institutional clients. This Figure is taken from the Securities Industry Association (SIA) White Paper version 1.5, December 1, 1999, titled "Institutional Transaction Processing Committee" (hereinafter "SIA white paper"), which is incorporated fully herein by reference. In Figure 2 an investment manager places an order 201 with a broker-dealer who places an execution request 203 with an exchange. The exchange returns a trade order confirmation 205 to the broker-dealer who generates the Notice of Execution (NOE) and average price 207 and sends the NOE 209 to the investment manager. The investment manager matches the NOE with the original order 211 and allocates shares among client accounts 213. He then forwards the allocation details 214 to the broker-dealer directing the broker-dealer to allocate the trade among different accounts, and sends a trade notification 215 to the custodian. The investment manager then generates settlement & delivery instructions 217 and passes these 219 to the broker-dealer. The broker-dealer enriches the trade details with settlement instructions, fees, commissions, and tax 221 and generates messages to confirm the trade 223. The broker-dealer sends the trade detail message 225 to the depository who creates a confirmation 227 and sends the confirm message 229 to the investment manager. The investment manager matches the confirm data from the depository to his previous allocations 231 and assuming they match he sends an affirm message 233 back to the depository. The Depository sends affirmed confirm messages to the broker dealer 237 and to the custodian 238 and the broker-dealer completes a settlement authorization 240 and returns it 239 to the depository who executes his part of the settlement 241 and notifies the custodian of the settlement 243 and the custodian completes the settlement 245. This trade process does not indicate the magnitude of the activities performed by the Asset Manager before the trade process begins. Asset Managers perform daily activities of customer relationship management, pre-trade analysis and communications with their clients, in addition to the normal enterprise resource management tasks for their own enterprise. As indicated below, the needs of the Asset Management function are the focus of this application. Never- the-less, the context of the asset management functions includes the securities trade processing activities. The asset management activities and the pursuit of the T+l closing cycle are explained in more detail below.

Because of the enormous volume of trading activity and the number of interrelated parties involved in a trade, securities firms do not compare and clear trades among themselves. Most transactions are passed over to clearing corporations and depositories that compare and clear the trades. Clearing refers to the processing of payment instructions, and settlement refers to the actual exchange of funds and securities between parties. In the U. S., there are several clearing houses that serve various markets. Trading on the New York Stock Exchange (NYSE), Amex, NASDAQ and some regional exchanges are cleared and settled through the National Securities Clearing Corporation (NSCC); U. S. Treasuries are handled by the Government Securities Clearing Corporation (GSCC). In the options markets, the Options Clearing Corporation (OCC) clears trades for the Chicago Board Options Exchange (CBOE), as well as for the options traded on the NYSE, AMEX, and the Pacific Stock Exchange.

At the present time most of these market players need several days to handle trade/settlement activities. Much of the processing is done by overnight batch processing methods using various computer systems, and each with their own standards, formats, and methodologies. Communications are predominantly single-threaded, point-to-point with a manual focus. And some of the processes are manual processes. In the cross-border trading area there is limited automation, and the clearance process has high failure rates due to limited expertise in foreign market trading and non-dollar instrument handling. Accordingly, there is a technical problem set related to transforming this T+3 process to a T+l process for clearance of security trades.

Various attempts to address the technical problems are being made. At the global or cross-border level as well as at the country level, especially in the United States, all players in this process are focused on simplification of the communications involved. At the global level, the Global Straight Through Processing Association (GSTPA), a consortium of approximately 90 broker/dealers, investment managers, custodians, and other investment organizations, announced in December 1999 the selection of a team which comprises SWIFT™, Segalntersettle™, Technosoft™, Tata Consulting™, Depository Trust & Clearing Corporation (DTCC)™ and IBM® Corporation, to design and implement a transaction flow manager (TFM) model of a global T+l system to be operational by 2005.

The Global Straight Through Processing Association has proposed a Transaction Flow Manager (TFM) model for straight-through processing of all cross-border trades which will be a virtual hub, one that can be cloned to serve a country or region-connected to local competing systems. The TFM is being designed so that a user of a TFM in a particular country or region could connect to a TFM in another and to any other central matching service being designed, wherein concentrators and solution providers can link their services to the TFM hub. Concentrators bring a large user base to the TFM, while solution providers are front- and back-office processing agents such as Automatic Data Processing, Thomson Financial, Canada's Financial Models Co., Reuters Group Pic, and systems as are proposed by Applicant herein.

In the United States, various systems are being proposed to address some of the technical problems. One such solution is the Institutional Transaction Processing Model (ITPM) proposed in the White Paper version 1.5 of the Institutional Transaction Processing Committee (ITPC) of the SIA, dated December 1, 1999, which is fully incorporated herein by reference. At the core of the ITPM is a concept of a "virtual" real-time matching utility, based upon their belief that a single processing service will not be able to meet the needs of all market participants. Instead, they envision multiple providers working in concert with full interoperability, based upon industry-agreed upon standards, enabling the development of a virtual matching machine, and enabling industry players to choose the specific provider of their choice.

Various other trade groups are trying to design service provider systems in the specific sectors of the phases that a trade goes through, such as the Order- placement-management phase by the buy-side organizations, the trade execution phase, the post-execution phase, and for the clearance, settlement and custody phases by the custodians.

For example, another such attempted solution is ITM, or Intelligent Trade Management, which is a method for straight-through processing under which all of Thomson Financial' s post-trade communication products are marketed; it is a rival to the GSTPA' s TFM. Thomson's focus appears to be in the post-trade process. Both Thomson's ITM and the GSTPA TFM have similar features. Both call for a central matching facility to reduce the number of steps in the post-trade communications process. Thomson could be a solution provider in the U. S., allowing its Oasys Global clients to connect to the TFM and appears to prefer this approach as opposed to being a concentrator.

The SIA's T+l virtual utility model has much overlap with the TFM, but there are still some differences. These differences are generally outlined in the Appendix to the aforementioned SIA white paper. It is uncertain how these differences are to be resolved, especially by infrastructure agents such as DTCC, who is a sub-contractor to GSTPA for the development of their TFM model as well as a player in the U. S. trade processing system.

Other trade groups like the Asset Managers Forum (AMF), an independent trade group and affiliated entity of the Bond Market Association (BMA), which represents the buy-side of the securities industry on industry wide issues has recently developed a preliminary plan to get to T + 1 closing.

Buy-side firms are working to make operations simpler, cheaper and quicker, focusing their efforts on eradicating redundancies and increasing efficiencies in order to be ready for straight-through processing and T+l settlement as these initiatives become standardized across the industry. The solution thus far has been consolidation, which has begun in earnest at large buy- side firms where numerous departments have long operated systems specific to their own divisions. For example, for Newark, N.J.-based Prudential Global Asset

Management™, with more than $300 billion in managed funds, looks to cut its operating systems down from what was a prodigious 15 different platforms to a more manageable four or five.

For the fixed-income trading group, Prudential is looking at Bloomberg LP™ for long-term, domestic systems capability. Additionally, Prudential is developing an in-house system as a front-end solution to its money market trade management requirements, largely because the firm hasn't found a product out there that is extensive enough, particularly from a compliance perspective, to satisfy its needs. On the record keeping side, Prudential is working with Los Angeles-based

Integrated Data Systems™ to migrate both its in-house equity and fixed-income record keeping systems onto the IDS platform, which is called Global Information Management II™.

At Boston-based Putnam Investments™, the firm has tapped Berkeley, Calif. -based Barra ™ Inc. to develop a customized, updated version of its

TotalRisk for Asset Management™ system to enable the company's equity and fixed-income groups to manage their assets with the same software.

Nonetheless, firms like Pioneer Group™-a fund manager of between $20 billion and $30 billion in assets-are already preparing themselves by installing new systems that can take advantage of the better liquidity and the price transparency that Electronic Communication Networks (ECNs) have promised. So far Pioneer uses the Archipelago™, Instinet Fixed Income™ and Posit™networks to search for liquidity in both the bond and equity markets. One of Pioneer's planned consolidation steps includes a soon-to-be- implemented FIX engine for the firm's trade order management system supplied by Boston-based vendor Charles River Data™, which will enable Pioneer to communicate electronically and directly with its brokers.

Another Pioneer reported project involves automating communications between Pioneer and its custodian bank, Brown Brothers Harriman™, by teaming with solutions provider and middleware vendor Braid, a longtime partner of BBH. In addition, the firm is mulling ways it could automate information entry into its securities database. Previously, the firm had a manual approach to categorizing its securities by consulting with market data vendors such as Bloomberg, Reuters Group™ Pic, Factset™ or ILX Systems™, and then entering the securities into the system. By chipping away at these straight-through-processing hurdles, Pioneer is positioning itself for the arrival of 24-hour trading and T+l, and is targeting June of 2002. Many other similar companies in the securities business are struggling with similar issues.

More recently , the SIA has chosen Andersen Consulting™ (applicant of the present invention) and Capital Markets™ Co. for the next phase of its study to determine how the U. S. can move to a one day settlement cycle.

Accordingly, all players in the securities trading business acknowledge the need to reengineer the systems to get to a one day closing cycle

Specific problems of standardization and decimalization create additional technical problems. For example, Mark Fischer, a product manager at Deutsche Bank's Global Institutional Services™ division, recently pointed to one area in which there was a glaring lack of a standard-proper identification codes for brokerages. While banks and brokers have BICs (bank identification codes), brokers BICs do not reflect different accounts, resulting in a number of failed trades. The GSTPA standards group has decided that firms communicating through the TFM would be using common identification codes such as BIC, but acknowledged that the lack of proper codes for broker-dealers was an issue the group would have to tackle. While all of these efforts and endeavors attempt to solve bits of the problem, most players simply want it solved. Accordingly, there is a need in the art for a system and method for an automated real-time 24 hour trading support system which allows investment managers, broker-dealers, banks and depositories to concentrate on the activities which they do best, while using the Internet facilities to connect to a system- wide utility which can communicate to all players directly, providing the efficiencies and cost savings related to accounting functions and other back-room functions which the individual players require but do not need to process for themselves.

Another technical problem exists in that Asset Managers use numerous database driven and out-sourced systems, which tend to be oriented toward a particular financial product or service and require different access for the different systems. There is no overall view of a customer. Should a customer maintain several different accounts, the portfolio or asset manger must switch between different systems. Additionally, processing requests through the various systems is a time consuming process. The lack of a unified view of a customer means that portfolio and asset managers may miss opportunities to proactively service customers.

There is a need for a system to provide Asset Managers with the capability to become "customer-centric" and enhance their customer relationships. Providing an overview of all customer's accounts along with real-time information and communication, and reduced processing time would help them to achieve this.

There is a further need to integrate data across various applications, such that Asset Management firms can focus on providing superior customer service and investment decisions. Asset Managers currently utilizes numerous out-sourced systems. Many day-to-day operations are performed by those systems. Much business logic has been developed for asset management access to these systems, and it is not practical to rewrite this logic. However there is a need to provide unified, easy-to- learn access to this business logic, and to provide a platform for integrating and adding value to these systems.

More specifically, there is a need for an automated system to assist the Investment Managers/Asset Managers in their portfolio management tasks to efficiently communicate with their clients, to manage client relationships in an automated manner and to handle pre-trade activities efficiently. Asset managers must perform these functions while also automating the trade related functions of communication with their broker-dealers, depositories and custodians while efficiently handling their order process, NOE handling, allocation process and settlement instruction maintenance and communication, and do all of this in a manner that will seamlessly interface with various other T+l closing systems.

SUMMARY OF THE INVENTION The present invention provides a solution to the needs described above through a system and method for an applications solution provider (ASP) utility (designated WEBeSTP) which can host common applications required to assist the Investment Managers/ Asset Managers in their portfolio management tasks to efficiently communicate with their clients, to manage client relationships in an automated manner and to handle pre-trade activities efficiently. Asset managers can perform these functions while also automating the trade related functions of communication with their broker-dealers, depositories and custodians while efficiently handling their order process, NOE handling, allocation process and settlement instruction maintenance and communication, and do all of this in a manner that will seamlessly interface with various other T+l closing systems. An ASP is provided with telecommunications connection via the Internet and via a private WEBeSTP network between investment managers, broker-dealers, custodians and other parties related to a securities transaction. The WEBeSTP system provides extranet connections to outsourced/syndicated applications systems wherever available.

A method is disclosed for automated processing of securities asset management functions by using a client relationship management function for communicating with a client of an asset manager, by providing analysis data and data regarding a client's securities to assist the client in a trading decision, by receiving instructions from the client to trade a security and by automatically handling the trade and post-trade functions related thereto such that the processes required to complete the trade and post-trade transactions in one day are effected. Also disclosed is an apparatus which includes a computer system having a memory and data base storage facilities, and means for using a client relationship management function for communicating with a client of an asset manager, means for providing analysis data and data regarding a client's securities to assist the asset manager in a trading decision, and means for receiving instructions from the client to trade a security and by automatically handling the trade and post-trade functions related thereto such that the processes required to complete the trade and post-trade transactions in one day are effected.

Also disclosed is a network having a network node which comprises a security asset management server, this server node providing mechanisms to create the processes required to support a securities asset manager in managing a client's assets, to provide electronic communications to and from the client, to manage trade and post-trade functions for orders received from a client and to interface with other servers to effect the trade and post-trade transactions in one day. Similarly, a computer program stored on a computer readable medium or carrier wave is disclosed having computer code mechanisms for creating the processes required to support a securities asset manager in managing a client's assets, to provide electronic communications to and from the client, to manage trade and post-trade functions for orders received from a client and to interface with other servers to effect the trade and post-trade transactions in one day.

Still other embodiments of the present invention will become apparent to those skilled in the art from the following detailed description, wherein is shown and described only the embodiments of the invention by way of illustration of the best modes contemplated for carrying out the invention. As will be realized, the invention is capable of modification in various obvious aspects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS The features and advantages of the system and method of the present invention will be apparent from the following description in which:

Figure 1 illustrates an exemplary Internet distributed system configuration. Figure 2 illustrates a representative current message flow in a T + 3 clearance system entitled "Illustrative Institutional DVP Trade Process."

Figure 3 illustrates a high level overview of an exemplary architecture of the WEBeSTP invention.

Figure 4 illustrates a block diagram of the functional aspects of the preferred embodiment of the invention.

Figure 5 illustrates a block diagram of the preferred embodiment of a CRM server.

Figure 6 illustrates a block diagram of the preferred embodiment of a CRM server communicating with an integration server. Figure 7 illustrates a block diagram of the functional aspects of the preferred embodiment of an integration server communicating with a database server.

Figure 8 illustrates a block diagram of the functional aspects of an alternative preferred embodiment of a WEBeSTP prototype development physical network.

Figure 9 illustrates a block diagram of the functional aspects of an alternative preferred embodiment of a WEBeSTP prototype development environment.

Figure 10 illustrates a block diagram of the functional aspects of an alternative preferred embodiment of a WEBeSTP technical environment with security.

Figure 11 illustrates an exemplary client screen layout. Figure 12 illustrates a second exemplary client screen layout. Figure 13 illustrates a third exemplary client screen layout. Figure 14 illustrates a block diagram of the functional aspects of the preferred embodiment of the invention illustrating communications flows between a client and the system.

Figure 15 illustrates a block diagram of the functional aspects of the preferred embodiment of the invention illustrating an alternative New Activity Business Event communications flow.

Figure 16 illustrates a block diagram of the functional aspects of the preferred embodiment of the invention within the context of a T + 1 system.

Figure 17 illustrates a block diagram of the functional aspects of the preferred embodiment of the invention illustrating an alternative logical architectural view of the invention.

DETAILED DESCRIPTION OF THE INVENTION The present invention provides a solution to the needs described above through a system and method for an applications solution provider (ASP) utility (designated WEBeSTP) which can host common applications required to assist the Investment Managers/Asset Managers in their portfolio management tasks to efficiently communicate with their clients, to manage client relationships in an automated manner and to handle pre-trade activities efficiently. Asset managers can perform these functions while also automating the trade related functions of communication with their broker-dealers, depositories and custodians while efficiently handling their order process, NOE handling, allocation process and settlement instruction maintenance and commumcation, and do all of this in a manner that will seamlessly interface with various other T+l closing systems. An ASP is provided with telecommunications connection via the Internet and via a private WEBeSTP network between investment managers, broker-dealers, custodians and other parties related to a securities transaction. The WEBeSTP system provides extranet connections to outsourced/syndicated applications systems wherever available.

OPERATING ENVIRONMENT The environment in which the present invention is used encompasses the general computing, data processing, telecommunications including wireless communications mechanisms, Internet and various Intranet environments.

Some of the elements of a typical Internet network configuration are shown in Figure 1 , wherein a number of client machines 105, possibly in a branch office of an enterprise, are shown connected to a Gateway/hub/tunnel-server/etc. 106 which is itself connected to the Internet 107 via some Internet service provider (ISP) connection 108. Also shown are other possible clients 101, 103 similarly connected to the internet 107 via an ISP connection 104, with these units communicating to possibly a home office via an ISP connection 109 to a gateway/tunnel-server 110 which is connected 111 to various enterprise application servers 112, 113, 114 which could be connected through another hub/router 115 to various local clients 116, 117, 118. Any of these servers 112, 113, 114 could function as a WEBeSTP server of the present invention, as more fully described below. Any user situated at any of these client machines would normally have to have a proper user ID and password and in many cases a digital signature in order to participate in a securities trading system over such a network. In the preferred embodiment, as described more fully below, securities asset managers, broker-dealers, securities custodians, financial institutions, and other users may be connected to the system via any of these exemplary client machines or by personal data input/output devices not shown in this figure but well known in the art.

A "client" is a member of a class or group that uses the services of another class or group to which it is not related. In the context of a computer network, such as the Internet, a client is a process (i.e., roughly a program or task) that requests a service that is provided by another process, known as a server program. The client process uses the requested service without having to know any working details about the other server program or the server itself. In networked systems, a client process usually runs on a computer that accesses shared network resources provided by another computer running a corresponding server process. However, it should also be noted that it is possible for the client process and the server process to run on the same computer.

A "server" is typically a remote computer system that is accessible over a communications medium such as the Internet. The client process may be active in a second computer system, and communicate with the server process over a communications medium that allows multiple clients to take advantage of the information-gathering capabilities of the server. Thus, the server essentially acts as an information and processing provider for a computer network.

Although the system and method of the present invention is specifically useful for the Internet, it should be understood that client computers 101, 103, 105 and financial transaction management servers 112, 113, 114 may be connected together through one of a number of different types of networks. Such networks may include local area networks (LANs), wide area networks (WANs), and regional networks accessed over telephone lines, such as commercial information services. The client and server processes may even comprise different programs executing simultaneously on a single computer.

The client computers 101, 103, 105 can be conventional personal computers (PCs), workstations, or computer systems of any other size. Each client 101, 103, 105 typically includes one or more processors, memories, input/output devices, and a network interface, such as a conventional modem or network connection, such as an Ethernet connection. The client computer 101, 103, 105 may access transaction management servers 112, 113, 114 through network 107. The client computers 101, 103, 105 can execute web browser programs, such as the Netscape NAVIGATOR or Microsoft INTERNET EXPLORER programs, or other programs for use on a client/server based network system, to locate the web pages or records stored on financial transaction management servers, or access applications running on various processing systems. Client computers 101, 103, 105 may also be able to access, through transaction management servers, outsourced or syndicated applications residing on servers located in other remote locations that may be accessible via network 107, which may be a public network such as the Internet, or may comprise private network connections between transaction management servers and outsourced/syndicated application servers.

THE INVENTION

Methods and systems are disclosed for an automated securities asset management system which can not only provide automated assistance to the asset manager and his clients, in securities portfolio management, but also can provide a mechanism to interface with other service providers to manage the trade and post-trade functions in a manner which will conform to the T + l closing requirements. The following description is presented to enable any person skilled in the art to make and use the invention. For purposes of explanation, specific nomenclature is set forth to provide a thorough understanding of the present invention. Descriptions of specific applications are provided only as examples. Various modifications of the preferred embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

In a preferred embodiment of the present invention, client computers communicate through the network with transaction management servers using the functionality provided by the Hyper Text Transfer Protocol (HTTP), although other communications protocols, such as FTP, SNMP, TELNET, and a number of other protocols known in the art may be used. In addition, for appropriate financial transactions, standards specific to the securities and asset management industries such as FIX (Financial Information Exchange) for real time electronic messaging and data exchange for securities transactions, may be adopted as the communications protocol. In addition, initiatives by industry consortiums and organizations such as GSTPA may also be adhered to. In addition, the users at client computers 101, 103, 105 may preferably comprise parties involved and interested in the management of assets in the financial industry.

As indicated in the background section above, the mechanisms required to create a system for closing a security transaction in one day (T + 1) are many and varied. Nevertheless, a system for use by financial asset managers which can easily interface with an ultimate T+l infrastructure and which provides scalability, high availability, security and ease of use for the asset managers in servicing their customers can be specified and developed. In an exemplary embodiment the present invention (WEBeSTP) is a browser-based system whose business and data-access logic can be used by various delivery "channels" with separate presentation logic. Examples are voice response systems, kiosks, pagers, smart phones and personal digital assistants including the use of various wireless systems and protocols. These alternate channels may require separate presentation code, but the core configuration would not change. Accordingly, the descriptions of the preferred embodiments described below will focus primarily on a browser-based application, but the availability of channel independence should be kept in mind.

The logic components of an exemplary embodiment may include the following, as depicted in the exemplary diagram of Figure 3. The boxes do not necessarily represent separate hardware devices, only functional components. The exemplary system is architected such that the components can be implemented on separate or consolidated hardware devices.

Web Browser (Figure 3, box 301)

The Web browser 301 is a client-side component residing on the asset manager's computer that acts as an entry point to the WEBeSTP system. The browser makes HTTP (hypertext transfer protocol) requests to the Web server 303 for data since all processing logic resides on the server. The lowest common browsers supported by the application will be Microsoft Internet Explorer™ 4.0 and Netscape Navigator™ 4.5. Both browsers support features such as: • Client-side scripting: Supports any type of HTML-based scripting. Some common client-side scripting options are JavaScript, VBScript, and Jscript.

• DHTML: Gives authors the ability to create dynamic HTML documents that interact with the user without the burden of relying on server-side programs or complicated sets of HTML pages to achieve special effects. • Client-side Java: The HTML required to invoke a Java applet (e.g., the

"<APPLET>" tag) can be included as part of a custom Web page.

• SSL: The most common method of securing the transmission of data between a Web browser and Web server is through SSL (Secure Sockets Layer) security (not used during the prototype)

For the prototype application, client-side scripting and DHTML will be utilized. SSL and client-side Java will be implemented in future releases.

Web Server (Figure 3, box 303)

For the WEBeSTP prototype, Microsoft's Internet Information Server (IIS)™ 4.0 was chosen as the Web Server 303, with TCP/IP the protocol used to communicate with STC's e*Gate™. IIS was chosen because of it's numerous large scale implementations, ease of development, powerful caching mechanisms and integration with various third party vendors. MS IIS 4.0 also incorporates an integrated Java Virtual Machine to provide a reliable and high-performance environment for running Java components on the server with Active Server Pages.

The web server 303 receives and processes all HTTP requests from Web browsers 301. When a user makes a request for information, the web server will call an Active Server Page (ASP), which interfaces with an STC ActiveX object. This ActiveX object communicates with an STC e*Way to provide communications with STC e*Gate, the message based integration server (discussed below). After e*Gate has retrieved the appropriate information from the various back-end systems, it sends a message back to the ActiveX control on the web server, which in turn sends a message back to the Active Server Page. The ASP then dynamically creates HTML to populate a custom web page and passes this information back to the Web browser for display.

Web Server

In a preferred embodiment, the web server will have Active Server Pages which will obtain market data and news from various internet sites.

Market Data Service

Services provided on the web server 303 comprise:

ASP Templates

Application Start Services

Navigation

Event/Error Handling

Integration Server Communications

Message Header Services

Code/Decode Services Application Server (Figure 3, box 315) In a preferred embodiment, STC's e*Gate 4.0.1 will be the Application/Integration Server 315 used. This message based architecture contains various business and data access components. Below are definitions of major e*Gate components (as taken from STC documentation)

• Intelligent Queue (IQ) - A database/memory based queuing mechanism that facilitates the reliable delivery of messages within eGate. IQ's can also be the storage mechanism for maintaining "state" of requests.

• Business Object Broker (BOB) - Allows for the routing and transforming of data within eGate. BOBs are only capable of communicating with IQs.

• eWay - These will act as pure middleware to access various external applications. Clients, such as web-server request, databases, and vendor applications (ie, Siebel) can communicate directly to eWays. On the eGate side, eWays must communicate with an IQ. • Data Access and Retrieval Tool (DART) - A specialized eWay that provides communication and data access to various relational databases, including Oracle, Sybase and SQL Server.

• Collaboration - The business function of an eWay or BOB that receives and processes events. A collaboration can transform data and pass this information on to another channel.

In the WEBeSTP framework, two collaborations per eWAY (one for inbound messages, one for outbound messages) will exist. Additionally, each eWAY will have its own Intelligent Queue. This standardization will allow for modular applications that are:

Reliable

Maintainable

Structured

Timely

Efficient

The WEBeSTP framework for e*Gate will also benefit the application developer in the following ways: • Reduce the time and effort required to develop business scenarios.

• Provide developers the time to concentrate on the content of the business request instead of the more mechanical aspects.

• Provide continuity in e*Gate development and subsequent maintenance.

Architectural Services provided on the Integration Server Layer include:

• Monk Function Templates • Message Header

• Event/Error Handling

• Code/Decode Services

CRM Application (Figure 3, box 309)

Siebel™ is the Customer Relationship Management application used in the pilot embodiment of the invention. Those skilled in these arts will recognize that other equivalent code systems may be used to perform equivalent functions. Utilizing the 99.5.1 Financial Service vertical™, this feature rich product provides much out-of-box functionality for WEBeSTP' s services. The CRM application runs as a service on Windows NT™, and utilizes SQL Server 7™ as its data store. e*Gate also has established batch and event driven messaging communications components (eWays) for integration.

The Siebel Object Interfaces include: • Siebel COM Interfaces. These interfaces expose Siebel object interfaces within the Siebel application (Siebel VB), or from an external programming language (Siebel COM Data Server and Siebel Automation Server). This technology provides for external application integration within the same server. This technology will be utilized to communicate with STC e*Gate in the prototype application.

• Siebel ActiveX Interfaces. The Siebel ActiveX interfaces enable external applications to access Siebel Business Objects across a network. There are two such interfaces: Siebel ActiveX Data Control and the Siebel Application Control. The data control gives access to all non-GUI Siebel objects, whereas the application control includes access to all the Siebel

GUI objects.

• Siebel HTML Tags. Siebel tags are a set of predefined HTML tags that enable the integration of Siebel data into an enterprise Web site while enabling the Web site to keep its own branding. For the preferred embodiment application, the Siebel Thin Client™ application with Financial Service vertical will be deployed within the web browser. The Thin Client application will reside within a frame of the WEBeSTP application, with the WEBeSTP header and navigation controls directly above it.

Database

Client CRM Server Server

Browser Siebel SQL Server 7

Siebel

ActiveX Siebel Server

Thin Client I )

Siebel Database

As user's update information in the Thin Client application, events are kicked off. These events can be sent to the STC's Siebel Event Driven e*WAY. e*Gate can then capture the information that has be added/updated or deleted, and process accordingly.

Referring now to Figure 5, Integration points within Siebel and STC's eGate are defined as follows:

Scenario 1 : Information is updated within the Siebel Thin Client browser and sent to STC.

In Figure 5, Upon the exit function of a given Siebel Business Event, the Siebel application makes a call to STC's COM object 501, telling it an update has occurred. This object is managed under a proprietary STC object manager. The STC COM object passes this information 503 onto the Siebel Event Driven e*WAY The e*WAY delivers a message 505 into an Intelligent Queue on the Integration Server. A collaboration object is listening for this event, and picks up the message 507. The collaboration object makes a call to the Siebel Event Driven e*WAY 509 to request additional data on the create/update/delete. The e*WAY then calls Siebel's Data Server COM object 513 which runs under the Siebel COM object manager's process. This object has numerous exposed functions which allow for data retrieval. The Data Server COM Object retrieves data 515 from the Siebel Data Store and sends the message back 513 to the Siebel Event Drive eWAY. A collaboration is listening for this incoming event 511 and picks up the message. The collaboration then reformats the information and send a message 517 to the appropriate destination. Referring now to Figure 6, an additional scenario is described.

Scenario 2: Information is requested/updated from within STC e*Gate.

In Figure 6, A message is delivered to an IQ 601 with an event type specifying a Siebel request. A collaboration object is listening for this event 603, and picks up the message. The collaboration object makes a call 605 to the Siebel Event Driven e*WAY to request additional data on the create/update/delete. The e*WAY then calls 607 Siebel's Data Server COM object which runs under the Siebel COM object manager's process. This object has numerous exposed functions which allow for data retrieval. The Data Server COM Object retrieves data 609 from the Siebel Data Store and returns this information back 609, 607 to the Siebel Event Driven eWAY Another collaboration object is listening for this event, and picks up the message 611. The collaboration then reformats the information and send a message 613 to the appropriate destination.

Portfolio Management Application

In a preferred embodiment, WEBeSTP will leverage Bloomberg™ for Portfolio Management Services. See boxes 313, 319, 321 and 323 in Figure 3.

Database Server In a preferred embodiment, Microsoft's SQL Server 7™ with Service Pack

1™ will be the relational database management system used by WEBeSTP and Siebel. SQL Server 7 is accessible via both ODBC and OLE/DB communications protocols, allowing various clients to access the data store.

In a preferred embodiment, two databases will reside on a single SQL server build; one database used for the WEBeSTP application Fig. 3, box 325, and the other as Siebel's data store 327. It should be noted that Siebel requires a binary sorting build of SQL Server. Although this is the fastest sorting option, the entire database server is case and accent sensitive. This should be acceptable for a prototype embodiment, but may become an issue in future releases of the preferred system. The remedy for this is to have Siebel and WEBeSTP reside on separate instances of SQL Server.

The WEBeSTP database 325 will be lightly used, and more than likely will be read-only for users other than administrators. It will be used to store system configuration parameters, user profile information, and custom security tables.

Referring now to Figure 7, an integration layout of e*Gate to the database is depicted.

In Figure 7, message is delivered 701 to an IQ with an event type specifying a Database request. A collaboration object is listening 703 for this event, and picks up the message. The collaboration object makes a call 705 to the DART for ODBC e*WAY to request/send information. The e*WAY then communicates 707 with the database using ODBC, runs a query and returns data 707. Another collaboration object is listening for this event, and picks up the message 709 The collaboration then reformats the information and send 711 a message to the appropriate destination. Execution Architecture of a Preferred Embodiment.

PHYSICAL ARCHITECTURE OF A PREFERRED EMBODIMENT

Referring now to Figure 4 a depiction of a preferred embodiment of a physical architecture of the invention is shown. In Figure 4, the Application Architecture 401 section comprises the Interface layer 403 which includes a Bloomberg UI and internet browser, and an application layer 405 which comprises various applications such as Business Object brokers, Business Collaborations, Architecture collaborations, Siebel COM Components, etc. The Technical Architecture 407 section comprises a client tier 409 which can accommodate either an Internet Explorer browser version 4.0 or greater or a Netscape browser version 4.5 or greater. The Technical Architecture 407 section also comprises an Access & Presentation tier 411 (Microsoft IIS in a preferred embodiment), an Integration/middle tier 415 (STC e*Gate in a preferred embodiment), an Applications tier 417 (comprising Bloomberg Services and Siebel 99.5.1 Financial services in a preferred embodiment), a Database tier 419 (comprising a Siebel database and a WEBeSTP database in a preferred embodiment), with an Access Layer 413 (comprising STC e*Ways, ODBC and STC Dart in a preferred embodiment) which provides access to the various tiers described above.

EXECUTION ARCHITECTURE OF A PREFERRED EMBODIMENT

The purpose of the WEBeSTP Execution Architecture is to provide a consistent framework for systematic functions to be accessed by application developers. Abstraction layers will be built to shield application developers from underlying API calls to specific locations and facilities. These facilities in a preferred embodiment are described as follows.

Event Handling/Logging

Summary: Provide the ability to handle events, errors and logging in a consistent manner in the WEBeSTP environment.

Purpose:

• ensures that operational information about WEBeSTP is available in a consistent location and in a consistent format • isolates developers from having to code the complex logic required to implement this logic

• provide for future audit requirements Requirements:

• Ability to handle Technical Errors gracefully. These errors are detected and raised by the NT operating system at run-time. Technical errors indicate a problem in system hardware, system software, or data compatibility. Examples include: connection to database failed, file not found, datatype mis-match, etc.

• Ability to handle Application Errors gracefully. These errors are detected and explicitly raised by application programmers at run-time. Application errors indicate a problem with a set of user defined conditions in business logic, and not the application itself. Examples may include: data row not found on a table when it should be, data condition inappropriate for business logic at this time, etc. • Ability to generate audit events and debug events.

• Performance impact must be minimized.

• The solution should permit enabling/disabling event logging without a change to the programs.

• Volatile aspects of the solution (e.g. where events are logged) should be externalized or encapsulated to facilitate future changes.

Event logging indicators

In a preferred embodiment there should be a place to specify whether logging is enabled for every user and for all severs. This information must be readily available at runtime on all platforms.

Information in this data store should include UserlD, UserGroup, Originating Business Request, Event Type (audit, application defined error, debug, system error), originating system and Event Description. Assumptions: A standard message header will exist on all messages to provide this information.

Implementation Alternatives: Logging to a file

Logging to an NT event log facility is advantageous over logging to a file because of the following "for free" advantages that come with the former: • location transparency

• event filtering

• serialization

• log size, overwrite, and event aging management • date and time

Logging to a centralized location

All logging is done locally, in spite of the NT event logger's ability to log across systems, to minimize performance impact. This includes flat-files and database, where direct eWay communications exists. Ability to enable debug logging by subsystem

Though finer control over what is logged was considered, a decision was made to keep the solution as simple as possible, and make it more sophisticated only if necessary. Besides, experience shows that really sticky problems usually force a special system build with carefully chosen, concentrated event logging anyway.

Design Description:

Each collaboration will subscribe to an eWay (IIS, DART, Siebel, PM) to process business logic. The business function should make a determination if an event needs to be thrown (such as audit, application error and system error). The collaboration will then call the IQ-put function to post a message containing basic information to the same queue. Once the message is delivered to the queue, business processing continues.

Next, an Event Handling collaboration will take information the various STC components (such as eWays BOBs) and writes them to a centralized data store. This is done in addition to the logging done by the e*Gate application/specific e*Way.

This Event Handling Collaboration has the ability to subscribe to one, multiple or all components. Since the business collaboration is publishing an event to a queue, the event handling collaboration can be implemented in various fashions, including one collaboration for all events, a separate event for each audit, application error and system error, or a combination. Additionally, these collaborations can speak to various and multiple eWays, which provides a great deal of implementation flexibility and scalability with no disruption to the business logic.

Performance of the business process is not impacted by the event handling facility, as execution occurs within separate threads.

Error handling wrappers also exist within each Monk environment which can be used to trap system errors. Code should be created in these to put a error message in the event queue. Collaboration Wrappers:

Begin Function:

{do stuff} If stuff = "not good" then Throw (WSTP_AE_27 "A description of WEBeSTP Application Error 27")

Exit Function Catch:

WSTP_AE_27:

{write message specific to this event to event queue} Otherwise: {write generic error message to event queue}

End Function

The following function can be used for audit, application errors and system errors. Function afPubishEvent (WH, EventType as Integer, Severity as Integer, EventMessage as String)

WH is the WEBeSTP message header.

EventType is the type of event (Audit, Application Defined Error, System Error)

Severity is the severity of the event EventMessage is the message that will be written out.

For the prototype application, the following information should be logged to a flat file:

UserlD, UserGroup, Severity, Event Type, Message, Timestamp

UserlD

Usergroup Sev Type Message Timestamp

MNChand Aud Updated Cust

WEBeSTP 1 Info for MPLaros 03/20/00 12:00 GTomane AC 3 ApE Account KMoss not in database 03/20/00 12:01

SStorm 5 SyE Database WEBeSTP Union not available 03/20/00 12:02

To minimize overhead, debug events should be written using the standard logging facilities provided by eGate, which will write events directly to the logging facility of that component (eWay or BOB). The following logging facility should be used for debug purposes:

Each eGate component has its own built in logging facility. That is, each eWay and BOB has it's own log file. During development, developers can write messages out to these log files using the eGate function display. This function can be called from the collaboration rules of each component (eWay or BOB). Pseudocode:

If str_data = ^~ 1" then

Display ( "Data received was expected Else

Display ( "Data received was not expected...data was & str_data) End If The debug logging services provided by eGate are defeatable per component.

Those skilled in these arts will recognize that various issues must be considered in equivalent systems, such as:

• Will there be any issues with multiple I/O processes and one file in a production environment? Need to check re: Windows NT file handling.

• If an error occurs in the error handler, how is it handled?

• How do we implement the various options within the error handler (bubble up error, continue processing).

• How are external technical errors (errors that occur in the database and/or other applications) errors received and handled by e*Gate?

Message Framework in the Preferred Embodiment

Summary:

The preferred embodiment will provide architectural information in a consistent manner in the WEBeSTP environment. Purpose:

Provide the following services:

Extensibility - the WEBeSTP architecture must be extensible to support growing requirements. In the future, the WEBeSTP architecture may need to be enhanced to support new user communities and the corresponding transaction volumes these new users will generate. These include

• Existing product enhancements

• Modification of the existing architecture components with minimal disruption to the application • Creation of additional architecture entities

• Changes in production infrastructure (hardware, network, etc.)

Security - the WEBeSTP architecture should provide a security framework that prevents unauthorized access to sensitive data by unauthorized application users or non- WEBeSTP users that have Internet access.

Operational Maintenance - the WEBeSTP architecture should support the ability for various operations groups to institute operational changes without requiring access to either the architecture or the business objects. For example, if a user requires a change to security, no changes in either the WEBesTP architecture or application should occur - instead, the functions created should handle the user's new requirements in an autonomous fashion Requirements:

In a preferred embodiment, in addition to the 24-byte header used for HS request/reply communications, a WEBeSTP header should be included on all messages. This should include:

• UserlD

• Usergroup(with Company)

• Logging Flag • Message Source

• Timestamp (granular to the millisecond)

• Message ID/Type

• Originating Business Request

Assumptions:

Design Description:

From a performance perspective, a fixed-length header is most advantageous, while a variable-length message header provides more flexibility. As additional products are added to WEBeSTP, additional architectural header information may be needed, so a variable-length message will be used. One concern with variable-length messages is that the delimiter does not get passed within the data. Therefore, we will use vertical pipe delimited messages, with Active Server Page field validation to ensure users do not enter this into forms. XML provides additional standardization at the expense of message length. Those skilled in these arts will recognize that alternative methods of delimiting the header may be used to effect the same results. The information for the first 5 elements of the message header will come from browser "cookies". Cookies are a "general mechanism which server side connections can use to both store and retrieve information on the client side of the connection." In other words, cookies are small data files written to a client's hard drive by some Web sites when the client views them in its browser. These data files contain information the site can use to track such things as passwords, lists of pages the client visited, and the date when the client last looked at a certain page.

The logon/user profiling utilities will place this information in a cookie upon application invocation. Upon creation of each active server page, the function afCreateWH() (see below) will create the message header, while additional information, such as message id and originating business request will be added by the application developer. For non-IIS sources messages, the application developer will also need to update the message source field within their collaboration object.

Function afCreateWHO As String This function will be coded and called from an Active Server Page. Data for elements 1-4 will be retrieved from the WEBeSTP User Profile and System Parameters set in the browser cookies.

This function will return a pipe delimited string containing the WEBeSTP message header. ie: WH will contains "MNChandr|AC|3|IIS|03/24/00

21:51:30:123|130|GetCustID|" element 1 : UserlD element 2: Usergroup element 3: Logging element 4: Message Source element 5: Timestamp element 6: MessagelD/Type element 7: Originating Business Request

Elements 6-7 will be updated by the developer in another function.

Function afUpdateWH(WH, element_number, element) As String

This function will be coded and called from an Active Server Page.

This function will update or add information to the WEBeSTP header.

ie: Update the header with a new business function.

WH currently contains "MNChandr|AC|3|S|IIS|Siebel|GetCustID"

Call afUpdateWH(7, "UpdCustID")

ie: WH will contains "MNChandr|AC|3|IIS|03/24/00 :51:30:123|130|GetCustID|"

element 1 : UserlD element 2: Usergroup element 3: Logging element 4: Message Source element 5: Timestamp element 6: MessagelD/Type element 7: Originating Business Request

Elements 6-7 will be updated by the developer in another function. Updating and retrieving header information in e*Gate can be done very simply via the GUI.

Function afParse(element number, message) As String

This function will be coded and called from an Active Server Page. This function will take a pipe delimited message, and provide the user the element in the requested field. ie: WH will contains "MNChandr|AC|3|IIS|03/24/00 21:51:30:123|130|GetCustID|"

element 1: UserlD element 2: Usergroup element 3: Logging element 4: Message Source element 5: Timestamp element 6: MessagelD/Type element 7: Originating Business Request

Elements 6-7 will be updated by the developer in another function.

afParseAT(l, WH) will return "MNChandr" afParseAT(4, WH) will return "IIS"

The maximum message size within e*Gate is 4GB. Message concatenation not an expensive process within e*Gate, but is within COM objects and Active Server Pages. Those skilled in these arts will recognize that it may be possible to determine if a more elegant solution exists outside of STC. Code/Decode Services Summary: provides a code/decode facility in the WEBeSTP framework Purpose: 1) ensures that information distributed to WEBeSTP clients is delivered in an approved, consistent way

2) provides a facility for developers to modify the information delivered to WEBeSTP clients without compromising the existing code base

Requirements:

In a preferred embodiment the System Codes design should include the following:

SQL Server architecture table that includes code/decode values. Two interfaces (stored procedures) to the table that 1) accepts input a category and codes and returns decode 2) accepts category and returns all codes.

Assumptions:

The System Codes design will retrieve data from a database and populate from a named- value-pair flat file.

After the initial database retrieval, the information should be cached into memory.

The table should be refreshed in memory on a periodic basis.

Implementation Alternatives:

Use the DART e*Way to retrieve information every time, rather than use up server memory resources.

Design Description: Two functions, afGetDecode and afGetCode will retrieve data from the code/decode table.

The code/decode table will have 6 columns with the following characteristics:

The table will be keyed by Category and Code.

Data caching in e*Gate occurs for each monk environment. Therefore, if 5 e*ways with 3 collaboration objects exist, a 1MB file could take up 15MB of space in memory. In a large-scale implementation, this could use up system resources very quickly. We will need to limit the size of data to be cached.

This information will be refreshed on a periodic basis. In a preferred embodiment, this should be done on a daily basis.

This following functions will be coded and called from Active Server Pages and e*Gate.

Function afGetDecode(WH, category, code, decodel, decode2) Calls database procedure SPR_GetDecode

CREATE PROCEDURE SPR_GetDecode

SELECT CODE_DESCl_TX, CODE_DESC2_TX FROM CODE_DECODE_T

WHERE CODE_CTGY_CD = ©category AND CODE_VALUE_CD = @code

If no decode is found, function returns an error. Function afGetCodes(WH, category) as Variant

Calls database procedure SPR_GetCode

CREATE PROCEDURE SPR_GetCode

SELECT CODE_VALUE_CD FROM CODE_DECODE_T WHERE CODE_CTGY_CD = ©category

If no code is found, function returns an error.

Those skilled in these arts will recognize that precautions must be made to handle any concurrency issues with multiple users accessing cache simultaneously.

Additional Features of a Preferred Embodiment Field Formatting

Summary:

This service is used to convert fields of different data types from one format to another.

Purpose: 1) to define and enforce standard formats for messaging between architecture tiers

2) to enforce standard field formats for display

3) to assist developers by providing an easy-to-use formatting facility Requirements: The following datatypes should be supported by this service:

Numbers — Currency and Percent

Dates

Phone Numbers

Postal Codes - Domestic Postal Codes - International Design Description: afFormatData(WH, input_value, input_format, output_value, output_format):

WH represents the WEBeSTP Message Header. It will not be used at the time of this implementation, however may be in the future. input_value and output_value will be strings in all cases, but we should allow for other datatypes if possible

User Profile/Security Summary: provides a means of determining the ID of a client and designating different types of clients and user responsibilities in the WEBeSTP framework Purpose:

1) ensures that operational security is applied in consistent way on a per user/per method basis for WEBeSTP clients

2) provides the facilities for new WEBeSTP clients to be added to the system without compromising the security available to existing clients

3) isolates developers from having to code the complex logic required to implement this logic.

Requirements:

In a preferred embodiment this utility has multiple functions; they include:

1) To determine the business users role within WEBeSTP.

2) To allow application developers to enhance and customize client user interfaces dependent upon the business user and their level.

3) To provide a facility to determine user specific logging information.

The Profile Management Utility should be designed and developed such that all processing is invisible to the end user. Furthermore, the application should download a "cookie" with relevant user information that can be easily accessed by the application architecture. Lastly, to consider changes within the roles of business users, or to accommodate additions, the database should be simple and easily updateable.

This database was also designed to accommodate function level security. That is, we can verify whether a user has permission run a particular function within WEBeSTP.

Note: In an alternative embodiment, the profile management design may change to utilize LDAP (Light Directory Application Protocol) services, rather than a relational database.

Assumptions:

Each user will be associated with one or more business levels Although users may have authorization to run multiple applications, their default application will be specified according to their primary role, as defined in the user table.

Design Description:

Upon launching the Browser from the client desktop, a "login" Active Server Page is opened. The user enters their username and password, and clicks a button. Within the code of the Active Server Page, a database call is made which authenticates users by running queries against the database. afAuthenticateUser: This method runs numerous queries against the SQL server to determine the associated usergroups and tracing and information for the specific user. This method is called from the login page.

First, we determine the if the userid and password entered is correct. This is accomplished by querying the t_user table.

select chr_logging, chr_cust_type from t_user where chr_user_id = ©userid and chr_password = ©password If a row is returned, then the user's usergroup should be selected. If no rows are returned, then the user is has entered incorrect login information. A message box should be displayed stating this information or to contact the WEBeSTP system administrator.

select CHR_USEGROUP from t_user_to_usergroup where CHR USERID = ©userid

If a row is returned, then the userid, usergroup, and logging flag should be written to "cookies" on the browser. This information should remain for the life of the browser session (do not specify an expiration date). With this design, it should be noted that if any changes are made to the user's information (logging flag, password) they will need to log out of WEBeSTP in order for these changes to take effect. By downloading this information into "cookies" on the client machine, we are providing an easily accessible source of user profile information for the application architecture team. This information should be sufficient for application developers to determine client interfaces via the browser.

The login page will then open the appropriate ASP page with the main body displaying the user's default application.

Preferred Embodiment Physical Environment Development Environment

The preferred embodiment of the physical development environment comprises several servers built to handle specific pieces of functionality. The architecture is designed to be scalable for high volume. Figure 9 is a diagram of the servers that comprise an exemplary development environment: The following table details information about the workstations/servers used in the WEBeSTP environment shown in Figure 9.

Development Environment Software

The following application are installed on each server (with the exception of the Web Server)

Productivity Tools

Lotus Notes

AC Lookup

Microsoft Office (with Access)

ARTES 5.0 CMAP Writer 3.0c

Norton Anti-Virus 5.0 with latest definitions

WinZip 7.0

Visio 5.0

Publishing Tools

Fireworks

TextPad

Macromedia Flash 4 Adobe Illustrator 7

Adobe Photoshop 5.0

Macromedia Dreamweaver 3

Snaglt!

JDK 1.2.2

Internet/Communications Tools

Internet Explorer 4.01

Netscape Navigator 4.5

Microsoft Netmeeting 3 FTP Explorer

Referring now to Figure 10, a Future Release Technical Environment is depicted. In this environment, the following considerations would apply:

• WEBeSTP issued user names and passwords are used to identify and authenticate the user.

• Access control policies define what actions are permissible for a user.

• HTTPS encrypts data for transmission, providing secure communication over insecure networks.

• Firewalls provide protocol and IP filtering, which prevent unauthorized access to sensitive information and resources. In an exemplary preferred embodiment, the following additional definitions would apply, understanding that those skilled in these arts may make various modifications to accomplish equivalent results without changing the invention.

Screen Definitions

WEBeSTP Site Navigation

WEBeSTP utilizes tabs to navigate from one application to another. The different tabs descriptions and content results of navigation are listed below.

Das W>QMd Order a mmsύ YQuotes 8 Research t Are-Trade Compliance Analytics & Made mg gMigMfiBMlBM

Order Management Tab

Navigate From Condition Action Response

Client Specific Client Specific User clicks on For release 0.1 of the prototype, Dashboard Dashboard is activated Order th and no account or Management application navigates to the holding record is tab. mocked up selected.. Trade Order Management Entry screen (See section 2.3).

No fields are populated.

Client Specific User clicks on For release 0.1 of the prototype, Dashboard is activated Order the and an account or Management application holding record is tab. navigates to the mocked up Trade selected. Order Management

Entry screen (See section 2.3).

If an account is selected in the

Financial Accounts section (FA JSTJBOX) of the

Client Specific

Dashboard, the following field from the Operational

Database will be populated in the

Trade Management

Order Entry screen:

Table: ACCOUNTS Field:

• Acct_number

• First_name

• Last_name

• Job itle

• Company

• Work number

If a security is selected in the Holdings section (HLD_GROUP_BOX) of the

Client Specific

Dashboard, the following field from Siebel Database will be populated in the Trade Management Order Entry screen:

• FINCORP Account Number

• ContactFirstName

• Contact.LastName

• ContactJob Title

• Contact. Company

• Contact.Work Phone Number » FINS Holding.Symbol Order Management Tab

Navigate From Condition Action Response

CRM Contacts/My Contacts User clicks on For release 0.1 of the prototype, or Contacts/All Order the Contacts view is Management application activated with or tab. navigates to the mocked up without a contact Trade Order Management selected. Entry screen (See section 2.3). No data is populated.

Contacts/Holdings User clicks on For release 0.1 of the prototype, view is activated and Order the no account or holding Management application record is selected. tab. navigates to the mocked up

Trade Order Management

Entry screen (See section 2.3).

No data is populated.

Order Management Tab

Navigate From Condition Action Response

Contacts/Holdings User clicks on Navigates directly to the Client view is activated and Order Specific Dashboard an account or holding Management for that particular client. The record is selected. tab. selected account or holding is highlighted.

If an account is selected in the Financial Accounts section of the Contacts/Holding view, the following field from the Operational Database will be populated in the Trade Management Order Entry screen:

Table: ACCOUNTS Field:

• Acctjmimber

• First_name

• Last_name

• Job itle

• Company

• Work number

If a security is selected in the Holdings section of the of the Contacts/Holding view, the following field from the Siebel Database will be populated in the Trade Management Order Entry screen:

• FINCORP Account.Account Number

• ContactFirstName

• ContactXastName

• Contact.Job Title

• ContactCompany

• Contact. Work Phone Number » FINS Holding-Symbol

Trade Order Trade Order User clicks on Page refreshes. Management Management is Order activated. Management tab.

Referring now to Figure 11 an exemplary Relationship Manager/Portfolio Manager High Level Dashboard 1100 is depicted. This Relationship Manager/Portfolio Manager High Level Dashboard 1100 is defined as:

Screen Name: Relationship Manager Portfolio Manager High Level

Dashboard

Screen ID: CUST001 Actor(s): Relationship Manager

Portfolio Manager

The Relationship Manager/Portfolio Manager High Level Dashboard 1100 provides users with a customizable, web-based interface to CRM and Portfolio Management application system. The dashboard offers convenient access to different applications from a single page. Users can also search for specific client information and accounts for the different applications. In addition, this dashboard offers News Links, real-time market news links, industry research, and the user's activities and alerts for the day. The Relationship Manager/Portfolio Manager High Level Dashboard 1100 comprises a general toolbar 1101 and the following sections:

A. WEBeSTP RM/PM High Level Dashboard Main Tabs 1103 See above for more details on WEBeSTP Site Navigation.

B. Search and Navigation 1105

Select a Contact search allows users to filter and search for a particular contact by contact name, by company or by category. Users can select to go directly into the CRM application, Portfolio Management application, or Client specific dashboard after selecting a contact.

Control Action Response

By Company is Application searches for records containing the user selected from the input string (argument) in the Company field. CONTACT FILT ER_MENU. For each record returned, the application will return the following fields (fields should be sorted in this

User enters a order) from the Siebel Database: value in the SEARCH NAME Contact.Account widget ContactLast Name (argument). ContactFirst Name

ContactCategory (multiple values)

User clicks the Contact. Category Value (multiple values) NAME_SCH_BU ContactCategory Value Rank (order Contac TTON widget. Category Value by ContactCategory Value

Rank)

Contact.Job Title

Contact. Work Phone #

Search is executed and a new page with the results opens up with one or more records (containing the above information). See search result page in section A.l below.

By Category is Application searches for records containing the user selected from the input string (argument) in the Category field. CONTACT FILT ER_MENU. For each record returned, the application will return the following fields (fields should be sorted in this

User enters a order) from the Siebel Database: value in the SEARCHJNAME Contact. Category (multiple values) widget Contact. Category Value (multiple values) (argument). Contact. Category Value Rank (order Contact

Category Value by ContactCategory Value

User clicks the Rank) NAME_SCH_BU ContactAccount TTON widget. ContactLast Name

ContactFirst Name

Contact.Job Title

Contact. Work Phone #

Search is executed and a new page with the result opens up with one or more records (containing the above information). See Contact Search Result Page in section B.l below.

B.l. Contact Search Result Page

Select one ,η EB

APP LIST MENU "4" "► CON SRCH BUTTON

CAR Dia ram

Select an Account search allows users to select a particular type of account or product and go directly into the Portfolio Management application system. List of accounts associated with the selected type of account or product is displayed.

Note: This functionality is disabled for release 0.1 of the prototype.

CAR Diagram

C. Stock Research/Quotes Tools Tools

RES SYM RBUTTON

Research By Symbol

NEWS SYM RBUTTON W News By Symbol

STOCK__QUOTE_RBUTTON 0 Stock Quotes ^" Stock Charts STOCK_CHART_RBUTTON

SEARCH_QUOTE QUOTE_SCH_RBUTTON Symbol Lookup

SYM SCH RBUTTO

D. News Link

News Links

Finaricial Time:

Wall Street Journal

I New York Times

Forbes

Fortune

Smart Mone-v

Newsweek

Strate-s-v & Business

Institutional Investor

The Industry Standard

E. Latest Research

atest Research

ARTICLE LINKS Worldwide Appliance Server Market Will Surge Past $11 Billion in 2004 Worldwide ASP Spending Will Apptoach $8 Billion in 2004 Despite Slow Start in Q1. EMEAPC Sales Will Orow 16.4% in 2000

CAR Dia ram

F. Activities and Alert

Note: This section is optional (time permitting) for release 0.1 of the prototype.

G. Markets

Note: The information displayed in this section will auto-refresh every 30 seconds.

CAR Diagram

Control | Action Response

DOW LINK 1 Click A new window opens up with real-time

A. News

S M

^■ IPO PRICING - Viasystems prices above range - Reuters - Thu 5:10pm

• Alert: Monarch Dental Says Retains Bank of America to Explore Strategic Optio

MARKET_NEWS_LINK 5:10pm ► ^■ TEXT - FOMC minutes from Feb 1-2 meeting - Reuters - Thu5:09ρm

• Alert: Masdaci Halt Mews Dissemination Last 2 11/16 (NasdaqSC:MDDS) - Rei

^■ IPO PRICING - Silicon Labs prices at $31 - Reuters - Thu 5:08pm

^■ J&J to stop marketing he rtburn drug Prop ulsid - Reuters - Thu 5:05ρm

^■ U.S. municipals keep gaining in busy trading day - Reuters - Th :05ρm

10

The general description of an examplary Relationship Manager/Portfolio

Manager Client Specific Dashboard was described above with respoct to Figure

11. A second exemplary version of this screen is now described with respect to

15 Figure 12.

Screen Name: Relationship Manager/Portfolio Manager Client Specific Dashboard Screen ID: CUST002 Actor(s): • Relationship Manager

• Portfolio Manager

A. WEBeSTP Client Specific Dashboard Main Tabs 1203 See above for more details on WEBeSTP Site Navigation.

B. Client Profile 1205 latent Profile

C. Search and Navigation 1207

Seeabove for the detailed design of this component.

D. Stock Research and Quotes Tool 1209 Seeabove for the detailed design of this component.

E. News Links 1211

See above for the detailed design of this component.

F. Client Company Internal News 1213 COMPANY NEW

COMPANY NEWS FEED TITLE omo -nv X Internal News

News From Data Feed here

CAR Diagram

G. Activities and Alerts 1215

Seeabove section E for the widget definition and picture.

10 NOTE: ONLY Activities for this Contact/Company will appear in this frame, the rest will be filtered out.

15

H. Client Portfolio Summary 1217

CAR Diagram

Control Action Response

FA LIST BOX item Page is activated. Populates with all of the financial accounts owned by this contact/company:

• IF the specified contact is affiliated with a company, this list-box will populate with all accounts for that company (for release 0.1 - Prototype).

IF the specified contact is NOT affiliated with a company, this list-box will populate with all accounts for contact only.

The accounts information will be pulled from the Operational Database. The following columns should be included in the table in the following order (records should be sorted by the columns as shown):

Table: ACCOUNTS Field:

Acct_category

Acctjaumber

Acct_status

Start_date

Prod d

Prod_name

Custjype

Fulljtiame

Currentjbal

State

Street_address

Zipcode

Country

City

First financial account in the list is highlighted.

User click on a The selected account is highlighted. record in the list.

Control Action Response

HLD LIST BOX item Page is activated. Populates with the holdings of the financial account highlighted in the FA LISTJBOX list- box.

The holdings information will be pulled from the Siebel Database. The following columns should be included in the table in the following order (records should be sorted by the columns as shown):

FINS Holding. As Of Date FINS Holding. Security Name FINS Holding. Symbol FINS Holding. CUSIP FINS Holding. Industry FINS Holding. Intention FINS Holding. .Objective FINS Holding. Asset Class FINS Holding. Category FINS Holding. Num Shares Owned FINS Holding. Current Price FINS Holding. .Value of Shares FINS Holding. RORDate FINS Holding. .Purchase Date FINS Holding. .Cost Basis FINS Holding, .Principle FINS Holding. Yield % FINS Holding, .Coupon % FINS Holding. .Maturity Date FINS Holding, .Call Date

First holding in the list is highlighted.

Highlight a Holdings for that financial account populate the different HLD LIST BOX list box. financial account

User click on a The selected security is highlighted. record.

Another exemplary screen in the preferred embodiment is the screen for Trade Order Management which is depicted in Figure 13.

Screen Name: Relationship Manager/Portfolio Manager High Level Dashboard Screen ID: CUST003

Actor(s): Portfolio Manager

In an alternative embodiment for purposes of demonstrating the system, WEBeSTP Trade Order Management will contain a mocked up Trade Management Order Entry Screen. The pmpose of this Trade Management Order Entry Screen is to demonstrate the integration of CRM and Portfolio Management as a result of a trade transaction for the client account. The following assumptions have been made for release 0.1 of the alternative embodiment prototype:

• Only Buy orders are allowed.

• Only Market Order prices are allowed.

• Once the "Submit" button is clicked, the order is considered executed.

A. WEBeSTP Trade Order Management Main Tabs 1303

WEBeS ..-Dashboard Ctder Mantatmeπt T Quote* * Research J . Pre-Trade Compliance Analytics (l Modeling Y Portfolio Mansgem--ra

See above for more details on WEBeSTP Site Navigation. B. Client Information 1305

ACCOUNT NUMBER Account * PF5771-001-224

John Smith

CLIENT ACCT INFO CEO

ABC Financial jsttriii@abcfinancial com

(212) 522-1212

10

C. Symbol Entry and Search 1307

SYM ENTRY Symbol J

GET_QUOTE_BUTTON - Get Quote SYM LOOK LINK^^" Lookup symbol

CAR Dia ram

D. Action Items 1309

Note: For release 0.1 of the prototype, user will only be able to buy securities in this section.

Actions

BUY_RBUTTON O βuy

SELL_RBUTTON O Sell SELL_SHORT_RBUTTON O Sell Sh t

BUY_COV_RBUTTON O Buy to tro er

QUANTITY Quantity shares

CAR Dia ram

Field Name = quantity

E. Price & Distribution 1311

Note: For release 0.1 of the prototype, only Market Order price will be allowed in this section.

10

CAR Dia ram

Control Action Response allowed to select GFD for release 0.1 of the prototype.

The data will be written to the following Table and Field Name of the Operational Database:

Table = POSITIONS Field Name = trd term

GTD DATE MENU User select GTD No response. as a term. User select desire GTD_DATE_MENU is enabled. date. Selected month, day, and year is highlighted.

The data will be written to the following Table and Field Name of the Operational Database:

Table = POSITIONS Field Name = trd term dt

CLEAR BUTTON Click Deletes all data enter on the Trade Entry form.

PREVIEW BUTTON Click Verifies order entry data and navigates to the Preview Order page or establish a message if verification fails.

The following required fields are verified to ensure the correct type, length, and that they are complete (stock symbol is searched on finance.yahoo to ensure validity):

Account Number Symbol

Action item selected Quantity

Price item selected

Price amount (if required by the Price item selected) • Term

If all requirements are not met, a message box pops up notifying the user that information is incomplete or that the symbol is invalid.

Click OK on the message box to close the box.

If all requirements are met, a Preview Order page opens up replacing the Trade Order Entry screen. See Preview Order page below. Preview Order Page

Trade Stock Verification

Please verity your order information below, then click Submit.

Order Information Quote Information

Account Number: PF5771-001-224 Last Price: 131 7/8

Action: Buy Bid Price: 131 1/4

Quantity: 1000 Ask Price: 130 "PREY INFO

Symbol: TCC

Description: Telecom C&C

Order Price Type: Market

Term: Good for Day

The estimated value of this trade without commision and fees: $130,000

Submit » m& 1 i

SUBMIT BUTTON VOID BUTTON

CAR Dia ram

Trade/Order Confirmation

F. Broker/Fund 1313

Note: * This functionality is disabled for release 0.1 of the prototype.

r Select a Broker/Fund!:

Name JAPGOvfQ "► BROKER NAME MENU

ER NAME MENU

Firm Trader |lιr "► TRAD

Message Definitions

Overview

Referring now to Figure 14 a diagram illustrates the logical messaging flow identified for use in an exemplary preferred embodiment of the invention: In Figure 14 an account is created in the Siebel thin client 1401. The account is created by the Siebel application 1403 in the Siebel Database 1405 and then replicated to the Operational Database 1411, where it can be read by the custom UI 1409. A trade order is created in the Trade Entry screen 1407 (simulation of Bloomberg's Trade Management application). This trade order is written to the operation databasel411 and then replicated to the Siebel Databasel405 where it can be read by the Siebel thin client 1401. Finally, market data newsl415 is read through the custom UI 1413 from various World Wide Web sites (e.g., Yahoo! Finance).

Optional Flow (Time Permitting) — Not Shown

An activity is created in the Siebel thin client. The account is created in the Siebel Database and then replicated to the Operational Database, where it can be read by the custom UI. New Account Business Event

The New Account business event is defined as a new account being created for a specific customer within Siebel.

Publish

Siebel

The following is the message definition for the New Account business event that is published by Siebel:

Subscribe

Operational Database

The message definition is the same as the table definition in the

Operational Database - See the Physical Database Design for the Operational

Database. New Trade Business Event

The New Trade business event is defined as a new trade submitted in the

Trade Management application. For the purposes of release 0.1 of the prototype, this screen will be a mock up to simulate the Order Entry screen of the Trade Order Management application. The simulation screen will produce the Trade Management publish message defined below. Post release 0.1 of the prototype, this business event will be initiated within Bloomberg.

Publish

Trade Order Management

Subscribe

Operational Database

The message definition is the same as the table definition in the Operational Database - See the Physical Database Design for the Operational Database.

Siebel The message definition that Siebel will subscribe to will be identical to that as published by the Trade Management - Section 3.3.1.1. The Siebel Object Definition column in section 3.3.1.1 provides the mapping into the Siebel Database. In this case, the FINCORP Account Siebel object will provide a lookup to determine which account to update with the new holding (FINS Holding object): An alternative embodiment of a New Activity Business Event would be as shown in Figure 15 and as described as follows:

Publish

Siebel

The following is the message definition for the New Account business event that is published by Siebel:

Subscribe

Operational Database

The message definition that the Operational Database will subscribe to will be identical to that as published by Siebel (Section 3.5.1.1).

Market Data News Retrieval Business Event

The Market Data News Retrieval business event is defined as the retrieval of relevant financial information from various websites. These sites are as follows:

• Yahoo! Finance (finance.yahoo.com)

• IDC (www.idc.com)

Having described in detail the Asset Management portion of the system, we now step back again to view the asset management system of the present invention in the context of an overall exemplary system focused on providing a straight through processing (STP) capability by referring now to FIG. 16. In Figure 16 a functional depiction of the preferred embodiment of the integrated securities asset management system is shown. In FIG. 16 an asset management firm 1601 may comprise a client relationship manager 1603 who can communicate with the WEBeSTP system through a client browser, a portfolio manager 1605 who can also communicate with the WEBeSTP system through a client browser, and a buy-side trader 1607 who similarly may communicate with the WEBeSTP system through a client browser. Those skilled in these arts will recognize that these client browsers may take various forms and may communicate using communications lines, wireless methods, and using Personal Computers, laptop computers, or various kinds of cell phones or other personal data assistants such as Palm Pilot™ etc. In the preferred embodiment, the securities asset management related support functions include customer relationship management 1613 support functions such as mechanisms for strategic planning and research, opportunity management and account management. Also included in the preferred embodiment are asset management pre-trade 1615 functions such as portfolio management, analysis and modeling capabilities and mechanisms to provide fundamental data such as news, market data, information etc. Also included in the preferred embodiment are asset management trade related 1617 functions and interrelationships with the trade executing broker- dealer in connection with required trade functions such as order management, compliance, order routing, allocation etc. Similarly, included in the preferred embodiment are asset management post-trade related 1619 functions and interrelationships with the trade executing broker-dealer in connection with required post-trade functions such as providing the required netting and settlement instructions, monitoring the clearance and settlement activity, revising master records and accounting data and updating performance and analytic data. In addition, included in the preferred embodiment are asset management related 1611 functions for basic enterprise resource management tasks for the asset management firm itself such as payroll, employee benefits, general accounting functions etc. The preferred embodiment of the WEBeSTP system may comprise an asset management transaction server 1609 connected electronically via the Web to the Asset management firm 1601, to various broker-dealers 1606, custodians and depositories, other clients 1602, 1604 and other Securities related service providers.

Transaction management server 1609 comprises the software and hardware infrastructure necessary to manage and oversee processing of financial transactions through the entire life cycle of the transaction from end to end without manual intervention or redundant processes. Transaction management server 409 comprises a system to automate steps necessary for conducting trades within the United States, as well as across national borders and in foreign countries. Transaction management server 1609 includes functionality for the automation of data related to trade capture, confirmation, data enrichment, settlement, and custody. This functionality will oversee transactions from the pre- trade activities, through the trade itself, to managing post-trade formalities and tasks. Transaction management server 1609 will also include the software and hardware infrastructure for customer relationship management, as well as hardware and software functionality for enterprise resource management.

A second embodiment of the present invention is shown in FIG. 17. In FIG. 17, a user located at a client computer 1701 may access information located on the WEBeSTP system 1708. The user at client computer 1701 may be an investment manager or other employee of the securities industry accessing WEBeSTP 1708 through a private network 1707 or a customer 1703 or other individual accessing system 1708 through the Internet 1705. In this more advanced embodiment of the WEBeSTP system 1707, the system may comprise collaboration servers 1715, Syndication servers 1717, e-mail servers 1719, as well as the STP management servers 1721. In this advanced configuration the WEBeSTP architecture also comprises additional application servers 1713 with integration architecture 1714 to connect the application servers 1713 via an extranet 1723 to various outsourced syndicated applications 1725-1737. Having described the invention in terms of a preferred embodiment, it will be recognized by those skilled in the art that various types of general purpose computer hardware may be substituted for the configuration described above to achieve an equivalent result. Similarly, it will be appreciated that arithmetic logic circuits are configured to perform each required means in the claims for performing the various features of the WEBeSTP straight-through-processing operations in order to enable a security transaction to close in one day (T + 1). It will be apparent to those skilled in the art that modifications and variations of the preferred embodiment are possible, such as different network or mobile telephony systems may be used, different communications media such as wireless communications, as well as different types of servers with differing combinations of security closing processing functions, all of which fall within the true spirit and scope of the invention as measured by the following claims.

Claims

CLAIMSI claim:

1. A computer implemented method for automated processing of securities asset management functions comprising the steps of: using a client relationship management mechanism to provide customer related data for communicating with a client of an asset manager; providing security analysis data or data regarding a security portfolio of the client to assist the asset manager in a security trading decision; receiving instructions from the asset manager to buy or sell a designated security; electronically communicating a buy or sell order to a broker-dealer; and electronically tracking the buy or sell order through trading and post-trading processes of the security transaction.

2. The computer implemented method for automated processing of securities asset management functions of claim 1 wherein the security is an equity security.

3. The computer implemented method for automated processing of securities asset management functions of claim 1 wherein processes required to close a security transaction in one day comprise trade related functions, and post-trade related functions.

4. The computer implemented method for automated processing of securities asset management functions of claim 3 wherein the trade related functions comprise functions for order management, compliance, order routing and trade execution.

5. The computer implemented method for automated processing of securities asset management functions of claim 3 wherein the post-trade related functions comprise one or more of electronic transaction confirmation functions, trade support functions, master record keeping functions, accounting functions, and custodial interface functions.

6. The computer implemented method for automated processing of securities asset management functions of claim 1 comprising an additional step of providing one or more functions to support enterprise resource management tasks for the asset manager.

7. The computer implemented method for automated processing of securities asset management functions of claim 6 wherein the one or more functions to support enterprise resource management tasks for the asset manager comprise payroll, human relations and electronic procurement functions.

8. An apparatus for automated processing of securities asset management functions comprising: means for using a client relationship management mechanism to provide security related data for communicating with a client of an asset manager; means for providing security analysis data or data regarding a security portfolio of the client to assist the client in a security trading decision; means for receiving instructions from a client to buy or sell a designated ' security; means for electronically communicating a buy or sell order to a broker-dealer; and means for electronically tracking the buy or sell order through trading and post-trading processes of a security transaction.

9. The apparatus of claim 8 wherein the security is an equity security.

10. The apparatus of claim 8 wherein processes required to close a security transaction in one day comprise trade related functions, and post-trade related functions.

11. The apparatus of claim 10 wherein the trade related functions comprise functions for order management, compliance, order routing and trade execution.

12. The apparatus of claim 8 wherein the post-trade related functions comprise one or more of electronic transaction confirmation functions, trade support functions, master record keeping functions, accounting functions, and custodial interface functions.

13. The apparatus of claim 8 comprising an additional means for providing one or more functions to support enterprise resource management tasks for the asset manager.

14. In a network having a user node including a browser program coupled to said network, said user node providing functions in support of a security asset manager, requests for information and providing security transaction related commands on said network, a network node comprising: a security asset management server responsive to a request from said user node to provide security data related to a client or related to a client's portfolio of securities, wherein the security asset management server can provide security analysis data or data regarding a security portfolio of the client to assist the asset manager in a security trading decision; wherein the security asset management server can receive instructions from the asset manager to buy or sell a designated security, can electronically communicate a buy or sell order to a broker-dealer; and can electronically track the buy or sell order through trading and post-trading processes of the security transaction.

15. The network node of claim 14 wherein the security is an equity security.

16. The network node of claim 14 wherein processes required to close the security transaction in one day comprise trade related functions, and post-trade related functions.

17. The network node of claim 14 wherein the trade related functions comprise functions for order management, compliance, order routing and trade execution.

18. The network node of claim 14 wherein the post-trade related functions comprise one or more of electronic fransaction confirmation functions, trade support functions, master record keeping functions, accounting functions, and custodial interface functions.

19. A computer program product stored on a computed readable medium, comprising; a first computer readable program mechanism for a client relationship management mechanism to provide security related data for communicating with a client of an asset manager; a second computer readable program mechanism coupled to the first computer readable program mechanism for providing security analysis data or data regarding a security portfolio of the client to assist the client in a security trading decision; a third computer readable program mechanism for receiving instructions from a client to buy or sell a designated security; a fourth computer readable program mechanism coupled to the third computer readable program mechanism for electronically communicating a buy or sell order to a broker-dealer; and for electronically tracking the buy or sell order through trading and post- trading processes of the security transaction.

20. The computer program product of claim 19 wherein the security is an equity security.

21. The computer program product of claim 19 wherein the processes required to close the security transaction in one day comprise trade related functions, and post-trade related functions.

22. The computer program product of claim 21 wherein trade related functions comprise functions for order management, compliance, order routing and trade execution.

23. The computer program product of claim 21 wherein the post-trade related functions comprise one or more of electronic transaction confirmation functions, trade support functions, master record keeping functions, accounting functions, and custodial interface functions.