AU2001287013A1

AU2001287013A1 - Method and system for financial data aggregation, analysis and reporting

Info

Publication number: AU2001287013A1
Application number: AU2001287013A
Authority: AU
Inventors: Edward Loughran; Anish Mathai; B. Douglas Morriss
Original assignee: WITAN GROUP
Current assignee: Kinexus Corp
Priority date: 2000-09-01
Filing date: 2001-08-31
Publication date: 2002-03-13
Also published as: WO2002019229A2; WO2002019229A8; WO2002019229A9

Description

METHOD AND SYSTEM FOR FINANCIAL DATA AGGREGATION. ANALYSIS AND REPORTING

FIELD OF THE INVENTION

The present invention relates to aggregating financial data, establishing a relationship structure between the data, analyzing the aggregated financial data and reporting on the aggregated financial data and related analyses.

BACKGROUND INFORMATION

The Internet and the World Wide Web (the "Web") have become an integral means of communication within our society. Individuals, corporations, churches, political organizations and others use the Web to post their information so that interested parties may find and peruse it. Commercial entities also use the Web to provide services or vend their wares to existing and potential clients. These commercial entities provide their goods and services by mamtaining a presence on the Web through their Web sites, that contain one or more Web pages, each a window of information. One subset of commercial entities with a presence on the Web are financial service providers. Financial service providers use the Web to provide their clients with direct access to their accounts as well as certain additional services. However, most financial service providers do not aggregate data from several institutions into a single, clear presentation for their clients. Such a presentation simplifies a client's oversight of their financial assets and liabilities as well as providing more comprehensive reporting. The ability to aggregate data from several sources into a single consolidated presentation is a highly desirable service especially for busy clients or clients with complex financial holdings and dealings such as high net worth individuals and families. Whether the presentation of the aggregated data is — electronic, such as a Web page, or printed, such as a printed summary sent via traditional mail, a clear benefit exists for the client. Providing Web based presentation of such information is particularly advantageous due to the real-time or near real-time accuracy and updating of the data and the client convenience of being able to access the information at any time.

Several firms have tried to address this shortcoming in the services provided by financial service providers by marketing aggregation services. Companies such as Yodlee (yodlee.com), OnMoney (onmoney.com) and VerticalOne (verticalone.com) provide data aggregation services to both financial service providers and individual clients. These companies obtain their information from detailed screen-scraping of Web based information sources. Screen-scraping is the use of a client's login and password to access a Web site and capture the information displayed on the screen. The data is gathered from several sources, reformatted and displayed on a single Web page. The resulting Web page is displayed to an individual client either directly by the firm providing the data aggregation service (i.e., Yodlee, OnMoney or VerticalOne) or is presented through a licensed distributor Web site such as a Web site of a financial service provider. These data aggregation companies cover a diverse range of source data to be aggregated, often including non-financial information, but lack depth in their aggregation by not adequately addressing the complexity of the relationships and structure of the client data. In other words, currently existing data aggregation companies address the needs of clients with simple financial portfolios but do not address the complex needs of high net worth individuals and families. FIG. 4a illustrates one example of subscriber information retrieved from screen- scraping and the lack of relationships between and a hierarchy in the data retrieved by a data aggregation company. A subscriber 401 is the client who directly or indirectly through a licensed distributor Web site engages the services of the data aggregation company. The subscriber 401 is directly linked to his/her assets and liabilities such as a brokerage account 402, asset management account 403, money market account 404, bank accounts 405, credit card accounts 406, and frequent flyer program 407 illustrated by the example in FIG. 4a. The relationships between the subscriber, his her assets, and liabilities gathered through screen- scraping and displayed by existing data aggregation compames lack the complexity necessary to reflect the intricacies in the relationships and hierarchical structure prevalent in the financial data of high net worth individuals and families.

High net worth individuals and families often have complex interrelationships involving their financial assets and liabilities. These interrelationships involve a structure and a hierarchy between individuals, families, business associates (such as partners), investment accounts/portfolios, other financial assets, financial liabilities, trusts, companies, and beneficiaries. The previously mentioned data aggregation companies do not provide services adequately reflecting these interrelationships because they neither account for nor track these relationships. l^s°_> die screen-scraping method of obtaining data inputs is not adequate for retrieving the information needed by high net worth individuals and families. Further limiting the effectiveness of the data aggregation companies in dealing with high net worth individuals and families is the lack of value added services performed on the aggregated data. Value added services such as risk analysis that are performed for client accounts at a financial service provider are even more relevant and important for the aggregation of an individual's or family's holdings. Unfortunately, the data aggregation company do not take advantage of the data aggregation to provide the value added services that high net worth individuals and families are accustomed to for their holdings at a financial service provider. The present invention addresses and solves these problems by providing a method for aggregating financial data, building relationships and a structure among the information gathered, performing value added services and analyses on the aggregated data, and presenting, for example, high net worth individuals and families a myriad of reporting options that adequately address their needs.

SUMMARY OF THE INVENTION The present invention relates to aggregating data from multiple financial service providers, building appropriate relationships and a hierarchical structure among the aggregated data, storing the data in one or more databases, reconciling the data, performing analyses on the data, providing value added services on the data, and providing numerous reporting options to the client. Clients may interact directly with the Web site of the commercial entity operating the present invention or they can interact with the commercial entity operating the present invention through a licensed distributor's Web site, such as a financial service provider's Web site, that is seamlessly integrated with the commercial entity operating the present invention.

The present invention delivers aggregated account and product information to clients over an information network and through statements delivered through traditional mail. This is achieved through a database, such as a centralized or distributed database, consolidating client information, data aggregation, and relationship structure management. Data is aggregated from multiple sources using data feeds from the financial service providers wherever possible. Data may also be provided through direct data entry by the client or authorized agent of the client such as the financial service provider and may be entered directly by the commercial entity operating the present invention's staff when received in electronic or print format from the client or authorized agents. Screen-scraping may also be performed to obtain the necessary client financial information. Financial service providers may include, for example, financial institutions that manage or handle a clients assets and/or liabilities as well as financial information providers such as a financial news service or a financial quote provider such as a brokerage that provides current stock quotes that can be used in determining the current market value of a security. During the data aggregation process, the client financial information is organized in a hierarchy based first on the subscriber, second based on entity (also termed "participating owner"), third based on account or legal entity (legal entity is also termed "holding entity"), then by asset or liability and position. The subscriber is the client for whom the financial data is being maintained by the commercial entity operating the present invention. An entity may be, for example, an individual or legal entity for whom information is tracked. The entities may be, for example, either individuals (founder, wife, and children) who make up the family of a subscriber or legal entities (e.g., family trusts and partnership entities)r~Entities may be - linked to other entities or directly to accounts which in turn contain positions for various assets and liabilities. This structure and relationship information is determined from the client financial information or is provided by the client. The data hierarchy and the relationships impose a structure on the received data assisting in its aggregation and organization. The received client financial information is stored in a consolidation database(s) according to the data structure.

Core and value added services are performed on the aggregated client financial data. Accounting records are kept by the accounting module, compliance rules are kept and the data monitored for adherence to these rule, the relationship structure is established, maintained and updated, while various analyses are performed on the data. The analyses performed can nclude, for example, performance analysis, risk analysis, and portfolio analysis and involve a universal analysis approach versus a local approach. A universal analysis approach is one where the analysis is performed on data from multiple financial service providers (i.e., across all the client's financial service providers) and is more advantageous than a local approach where the analysis is performed only on the assets under management at a particular financial service provider. These various services and analyses may result in the generation of additional data which is stored in the results depository database(s). The reporting module uses the data in the consolidation database(s) and.the results depository database(s) to present data to the client in various ways. Clients can have different views of the data based on the scope of access they have been given.

According to an example embodiment of the present invention, a user interface such as a graphical user interface (GUI) may query the databases through the querying services. The reporting module may work with the querying services and the graphical user interface to provide the client with pre-formatted or customized data presentation. Reporting can be done online over an information network or may be done through printed statements sent via traditional mail.

A subscriber management system may also be used to track additional information about the subscriber including, in particular, information on what data the subscriber is granted permission to access. This permission-based access control is a conventional method of access control for database management systems. The permission-based access control may also be supplemented by a token-based access control and authorization system. The present invention provides clients, for example, the ability to review their aggregate holdings via easy to use statements that are globally accessible over an information network such as the Internet. Clients may see their entire relationship structure as a cohesive whole and also see their aggregated holdings within that relationship. The consolidation database of the present invention serves as the hub around which clients may view their total net worth.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a network architecture that illustrates the relationship between the Internet, a data consolidation network node, Web users, and financial service providers according to one embodiment of the present invention.

FIG. 2 is a block diagram illustrating a generalized flow of information and processing performed by the data consolidation network node according to one embodiment of the present invention.

FIG. 3 a illustrates a subscriber table in the consolidation database according to one embodiment of the present invention.

FIG. 3b illustrates an entity table in the consolidation database according to one embodiment of the present invention.

FIG. 3c illustrates an entity relationship table in the consolidation database according to one embodiment of the present invention.

FIG. 3d illustrates an account table in the consolidation database according to one embodiment of the present invention.

FIG. 3e illustrates an legal entity table in the consolidation database according to one embodiment of the present invention.

FIG. 3f is a block diagram illustrating the asset/liability table according to one embodiment of the present invention.

FIG. 3g is a block diagram illustrating the position table according to one embodiment of the present invention.

FIG. 3h is a block diagram illustrating the transactions table according to one embodiment of the present invention.

FIG. 4a illustrates one example of subscriber information retrieved from screen- scraping and the lack of relationships between and a hierarchy in the data retrieved by a data aggregation company.

FIG. 4b illustrates a subscriber as a whole with all its subordinate entities and entity relationships according to one embodiment of the present invention.

FIG. 5a is a flowchart depicting the sequence of events that take place during the process of setting up a new subscriber account according to one embodiment of the present invention.

FIG. 5b is a flowchart depicting the steps involved in the initial set-up of subscriber information according to one embodiment of the present invention.

FIG. 5c is a block diagram illustrating the steps in defining the relationship structure between the participating owners according to one embodiment of the present invention. FIG. 5d is a block diagram illustrating a sample relationship structure for a subscriber.

FIG. 6 is a block diagram illustrating how reporting view may be granted according to the defined scope of access according to one embodiment of the present invention.

DETAILED DESCRIPTION

Although the embodiments described herein utilize the Internet and the World Wide Web (the "Web"), the present invention is compatible with other types of information networks (both public and private), and thus the embodiments described herein are not intended to limit the scope of the claims appended hereto. For example, the present invention may be implemented using a private Intranet, local area network (LAN), metropolitan area network (MAN), wide area network (WAN), dedicated or direct connections, and a wireless network.

FIG. 1 is a block diagram of a network architecture that illustrates the relationship between the Internet, a data consolidation network node, clients, and financial service providers according to one embodiment of the present invention. Data consolidation network node 100 connects with financial service provider 190 network node to retrieve client data. Data consolidation network node 100 aggregates client data from the one or more databases 195 at each financial service provider 190 consolidating the retrieved information into a consolidation database(s) 170 (an example of which is shown) at the data consolidation network node 100. Relationships among the client data are established resulting in an information hierarchy based on a subscriber as the topmost entity (subscribers are discussed in more detail below). Subscriber information is generated and stored in a subscriber database(s) termed the Subscriber Management System ("SMS") (not shown in FIG. 1). The client data in the consolidation database(s) 170 is analyzed and services are performed on the data with the results being stored in a results depository database(s) 171. The SMS database and the results depository database(s) 171 may be, either together or individually, subsets of (or additional tables in) the consolidation database(s) and do not necessarily have to be separate. The data in the SMS database, the results depository database(s) 171, and the consolidation database(s) 170 at the data consolidation network node 100 are available for, inter alia, querying of data by the client, report generation, and user interface purposes.

Clients 110a- 110c communicate with data consolidation network node 100 via one or more networks such as the Internet 105. In the embodiment depicted in FIG. 1, data consolidation network node 100 is coupled to the Internet 105 via TI line 130a. Client 110a illustrates a typical narrowband Web user connected to the Internet 105 via a dial-up connection described in more detail below. Client 110b illustrates a typical broadband Web user coupled to the Internet 105 via a cable modem 112b. Client 110c illustrates corporate Web users that are coupled to the Internet 105 via TI line 130c and server 141a respectively. Corporate Web user 110c includes three network nodes 145a- 145c that share bandwidth on the local Ethernet network 142. Although FIG. 1 illustrates three clients 1 lOa-110c, it is to be understood that data consolidation network node 100 may serve any arbitrary number of clients. In the example embodiment, client 110a utilizes personal computer 11 la to navigate the Web 105 via browser software and a display device. The browser software permits navigation between various file servers connected to the Internet 105, including gateway server 150a at data consolidation network node 100. The browser software also provides functionality for the rendering of files distributed over the Internet (i.e., through plugins or ActiveX controls).

Client 110b is coupled to the Internet 105 via a broadband cable connection. In particular, personal computer 111b transmits packets via cable modem 112b to ISP 115b where the packets are routed over the Internet 105 to gateway server 150a. Packets from data consolidation network node 100 traverse a reverse path to user 110b. Similar to client 110a, client 110b utilizes browser software to navigate the Internet 105 and the Web.

Client 110c includes network nodes 145a-145c, which are coupled to the Internet 105 via local Ethernet network 142, server 141a, and TI line 130c of corporate user 110c. Network nodes 145a- 145c may communicate with data consolidation network node 100 via local Ethernet network 142, server 141a, TI line 130c, Internet 105, and TI line 130a. Similar to clients 1 lOa-l 10b, it is assumed that users at network nodes 145a-145c utilize browser software to navigate the Internet 105 and the Web.

The specific nature of clients 110a- 110c and the methods through which they are coupled to the Internet 105 depicted in FIG. 1 are merely exemplary. The present invention is compatible with any type of Internet client and/or connection (for example, broadband or narrowband). In general, it is to be understood that clients 110 may connect to the Internet

105 using any potential medium whether it be a dedicated connection such as a cable modem, TI line, DSL ("Digital Subscriber Line"), a regular dial-up POTS ("Plain Old Telephone System") connection or even a wireless connection. Clients 110a- 110c use the Web and the Internet to connect with the data consolidation network node 100.

The data consolidation network node 100 can be a node different from and separate of a financial service provider network node 190 when a separate commercial entity is implementing one embodiment of the present invention. The data consolidation network node 100 can also belong to a financial service provider either being a part of the financial service provider network node 190 or being a separate node run in conjunction with the financial service provider network node 190 according to another embodiment of the present invention. The example embodiments discussed below refers to the former situation where the data consolidation network node 100 is run by a separate commercial entity and is not part of a financial service provider network node 190.

The distinction between a data consolidation network node 100 operated by a separate commercial entity and one operated by a financial service provider differs from the previously mentioned situation where the data consolidation network node 100 is operated by a separate commercial entity but it is accessed either by a Web site presented by a licensed distributor or by a Web site presented by the separate commercial entity. In one case, the entire data consolidation network node 100 operation is discussed while the other merely references how a client 110a- 110c accesses the data consolidation network node 100.

Data Sources

FIG. 2 is a block diagram illustrating a generalized flow of information and processing performed by the data consolidation network node 100 according to one embodiment of the present invention. The present invention aggregates client data from a number of sources, e.g., financial service providers 200. For example, client bank account and loan data is retrieved from banks 201 while various annuity and life insurance information may come from insurance companies 204. Brokers and dealers 202 are another source of financial information as are investment and mutual fund managers 203.

The example financial service providers 200 mentioned are a small subset of the possible sources of information for the present invention. For this reason, a box for other financial service providers 205 is also included in the block diagram. Other financial service providers 205 may include, for example, sources covering a more diverse range of information that can help determine wealth, assets, and liabilities of the client. Such diverse sources can include administrators of trusts, real estate investment trusts (REITs), account custodians, and partnership information. The aggregated data 210 section of FIG. 2 lists other assets 215, 220 and liabilities 225 about which information is obtained from financial service providers 200. Additionally, other embodiments of the present invention may include nontraditional sources of information such as affinity programs, e.g., airline frequent flier miles.

Data Acquisition

In accordance with the example embodiment of the present invention, client data is received from sources external to the data consolidation network node 100. The data is then validated, and it is prepared for incorporation into the various components of the present invention. According to one embodiment of the present invention, the data acquisition process begins with the establishment of a relationship between an operator of the data consolidation network node 100 and a financial service provider 190 or other source of external data wherein the data structures, formats, and data acquisition protocols are specified. For example, XML (extensible Markup Language) may be used for the data exchange protocol. The data acquisition process ends, according to one embodiment of the present invention, with receiving, validating, and preparing the data in files so that it is in the appropriate format for use by the various component elements of the present invention. The first step in the data acquisition process according to one embodiment of the present invention is to establish a data acquisition relationship. A data acquisition relationship is established between the operator of the data consolidation network node 100 ("operator") and the financial service provider.or other, external data source by an agreement that the data source will provide the operator information concerning individuals' accounts associated with a subscriber. The relationship agreement may also identify the types of information to be transmitted, the format of the data, the data delivery mechanism, and the frequency of data delivery. Additionally, the agreement may also identify a point or points of contact for the resolution of problems that may arise. According to one embodiment of the present invention, the process of establishing data acquisition relationships is performed by the operator's staff after a client (e.g., a subscriber) has authorized the operator to obtain such information. For example, the process whereby a user becomes a client of the operator may include a form (either electronic or printed) granting this authorization and that, once completed, provides the necessary authorization thus beginning the data acquisition process. The operator may also identify the data elements and their formats that are needed for consolidation with the present invention data according to one embodiment of the present invention. The operator may prepare and submit to the data sources different specifications for different data file types including files for client information, account position information, transactions, and other activities according to one embodiment of the present invention. Additionally, the operator may also submit to the data sources code tables to be used with code conversion and formatting. For example, transaction codes, currency codes, country codes, bank product codes may also be code tables that are transmitted to the data source. The financial service providers or other data sources may then determine whether they can provide data to the requested specification and using the given codes. If the data source can't provide the data to the requested specification, the data source may provide the information using the formats available to the data source according to one embodiment of the present invention. The data source may provide data using the operator codes provided in the code tables sent to the data source or the data source may use their own codes. If the data source uses their own codes, the data source may also provide translation tables to convert their codes into the operator codes. If these translation tables are not provided, the operator may need to generate translation tables to assist in receiving and preparing the data from the data source.

As part of the data acquisition process, the operator and the data source may establish a schedule for_. the transmission of subscriber data and the mechanism by which the data is submitted according to one embodiment of the present invention. For example, the mechanism for data submission may include the medium used (i.e., electronic or hard copy printout), naming conventions, file locations format of-the submission (i.e., email attachment, FTP, floppy disk), and encryption keys and devices if the data is to be transferred encrypted. The frequency of transfer and the time of day of transfer are two examples of scheduling information.

One embodiment of the present invention may use data mapping and reformatting templates or scripts to convert the data from the external source into a format acceptable to the operator. For example, data mapping and transformation may involve code conversion, format conversions, and data type conversions. The data mapping schemes and reformatting scripts may be stored and maintain for use with other periodical data transmissions from the same or different external data sources. Test data may also be established, stored, and used to test the data formatting and transformation features of the system. The test data may also be stored and maintained to periodically test data mapping schemes and formatting scripts when changes are made to them.

According to one embodiment of the present invention, data may be received, downloaded, or extracted from a data source as specified in the agreement. The data once received, downloaded, or extracted using the mechanism and format in the agreement may be pre-processed in order to validate the integrity and completeness of the data prior to reformatting and restructuring the data. A temporary data store may be used to store the information validated during the pre-processing. Processing of the validated data may include the reformatting of the data according to a temple or script in order to bring the data into a similar format as the data stored by the present invention. If there are error in the processing (formatting) of the data received, the rejected records or those with errors that have occurred due to the processing may be tagged or placed in a separate data store until the problem with the data can be addressed. The problems with these records may be resolved by calling the contact person at the transmitting institution and having the data source resend updated information. Errors in the formatting of records or rows may also be resolved by filling in blank or missing data with a default data. Manual entry of the data by the operator's staff including the manual conversion of codes may also be performed. The data acquisition agreement, according to one embodiment of the present invention, may also include control measures and reconciliation methods in order to guarantee the completeness and correctness of the data. For example, control fields with certain values can be added to the data transmitted and the sum of these control fields may be checked against a control value where both the sum and the control value should be the same. If an input file from the data source does not reconcile, it may be very difficult to have the present invention data reconcile with the accounts at the data source. The acquisition of subscriber (client) data from external sources of data such as financial service providers may be performed by agreement between the data source and the operator. This agreement establishes the data feed, the manner and format by which the present invention receives the subscriber financial information.

Data Feeds v. Screen-Scraping

Once data acquisition relationships are established, data feeds may be established. One example embodiment of a data feed is the electronic transmission over the information network of a client's financial information on a daily basis (each business day) where the data feed is initiated by an automatically executed batch program at the data aggregation network node 100. Data feeds are generally electronic because of the particularly advantageous nature of receiving data in this manner; however, the data feed can be in a printed format which is then manually entered or even scanned using OCR (optical character recognition software) at the data aggregation network node 100 according to an alternative embodiment of the present invention. In one embodiment of the present invention, the way the data feed is established (e.g., TI links, dial-up, email, etc.), how the data feed may operate (e.g., frequency of data feed) and the format of the data provided may be standardized across the appropriate financial service provider nodes or may be tailored for one or all of the financial service provider nodes.

Data feeds are different from screen-scraping because they provide greater and more consistent information. This difference may be important in accurately reflecting the net worth of individuals and families, for example. Data feeds may also be necessary to properly construct the relationships and hierarchy among the client's financial information. For example, screen-scraping is limited to the information displayed on the financial service provider network node Web site and is also limited by the format in which the information is presented. Data feeds do not have this limitation because they provide a more complete set of information that is already in a format usable by the data aggregation network node 100.

Data Aggregation

Client financial data received via data feeds from multiple, financial service providers 200 may be consolidated and also organized 210. A protocol mapping process of the present invention organizes the retrieved data into the appropriate categories (such as subscriber, participating owner, legal entity) so that it can be stored in the consolidation database 230. In an advantageous embodiment of the present invention, the operator may provide a data interface to the financial service provider which includes predefined category designators for - the financial service provider to select from in determining the appropriate category of the - client data. An alternative embodiment of the present invention involves a determination made automatically by the system as to the appropriate category according to the data acquisition agreement and/or a number of parameters. In the alternative embodiment, if the data can not be automatically categorized, exceptions are stored in an exceptions queue which may be manually reviewed by the operator staff and the necessary adjustments made to the automatic data category selection routines so that this information may be automatically processed in the future. According to another embodiment of the present invention, the protocol mapping process is a manual process whereby the information is received either electronically via a data feed or in a hard copy format and the operator staff manually determine the category in which the data belongs. The protocol mapping process aggregates the data by category (if known) according to one embodiment of the present invention. One category of aggregated data is securitized assets 215 that include, among others 219, traded equity 216 such as stocks, fixed income instruments 217 such as bonds, and funds 218 such as investment management funds or mutual funds. Nonsecuritized assets 220 is another aggregation category and include, among others 224, real estate 221, private equity 222, and collectibles 223 such as art. Data regarding non-market traded assets 220, including valuation data, may be entered by the client (subscriber or participating owner) or the client's authorized agent through a data entry interface that is part of the GUI according to one embodiment of the present invention. Non-market traded asset 220 data may also be provided to the present invention provider whose staff may manually enter the data into the system according to one embodiment of the present invention. For example, the client or authorized agent may provide the data electronically, by telephone, or in printed form to the present invention provider. Liabilities 225 is the third aggregation category displayed in FIG. 2. Liabilities 225 includes, among others 229, credit lines 226, mortgages 227, and loans 228. These three categories are merely exemplary and are not intended to be exhaustive. These categories help organize how data aggregation occurs and can be used in varying degree in different.embodiments. of the present invention. The actual organization of the aggregated data occurs during the protocol mapping process which converts the retrieved client financial data into an appropriate format to be stored in the consolidation database 230. The consolidation database 230 can be one or more actual databases that contain the client financial data. The example embodiment described herein and shown in FIG. 2 refers to the consolidation database 230 as a single database. Alternate embodiments can implement the consolidation database as a distributed database or as multiple databases linked and accessed through the data aggregation network node 100.

Sequence of Events for Establishing a New Subscriber FIG. 5a is a flowchart depicting an example sequence of events that take place during the process of setting up a new subscriber account according to one embodiment of the present invention. A written agreement between the operator and the subscriber is reviewed 500. The agreement is reviewed to determine the nature and the extent of services to be provided to the subscriber. The initial set-up of the subscriber information is then performed in the system according to one embodiment of the present invention 502. The set-up of the subscriber information may be performed by, for example, the operations staff of the operator or by authorized agents according to one embodiment of the present invention.

FIG. 5b is a flowchart depicting the steps involved in the initial set-up of subscriber information according to one embodiment of the present invention. In step 550, according to one embodiment of the present invention a unique identifier for the subscriber is assigned by, for example, either the operator staff or automatically (e.g., the subscriber management system module of the present invention). In step 552, entry and validation of the subscriber identifying information such as subscriber name, address, contact information, and tax status is performed according to one embodiment of the present invention. For example, subscriber identifying information may include a subscriber name such as "the Jones family" or "Gill Bates III." In another example, the subscriber address may include one or more of the following: legal address, tax domicile, residence, mailing address, and temporary address. The contact information mentioned may, for example, include the name, telephone numbers, fax numbers, and email addresses of one more contacts for the subscriber. An example of tax status that may be included in the subscriber identifying information is a taxpayer identifier. Under certain circumstances, the subscriber or referring financial service provider may want to keep some or all of the identifying information (i.e.,.subscriber, participating owner, agent, addresses, contact information, and tax status) confidential (hidden from the data consolidation network node). For example, the subscriber may only want his/her account manager at the referring financial service provider to know the information. In this case, all the identifying information to be kept confidential may be maintained at the referring financial service provider and only the locally generated identifiers, i.e., generated by the data consolidation network node, may be used according to one embodiment of the present invention.

In step 554, the selection of a subscriber type from a list of supported subscriber types is performed according to one embodiment of the present invention. Alternative embodiments may allow custom designation and dynamic generation of subscriber types. For example, subscriber types may include individual, family, partnership, trust, s-corporation, foundation, and public institution. The selection of a subscriber type may, according to one embodiment of the present invention, trigger further prompting for additional or particular data specific to that type of subscriber. In step 556, the financial service provider referring the subscriber to the operator

(referring financial service provider) is identified according to one embodiment of the present invention. For example, a referring financial service provider may be identified by an industry standard identifier code or by financial service provide¹" name. If the subscriber interacts directly with the operator or an agent of the operator without going through a financial service provider as an intermediary for the present invention services, the referring financial service provider identification may be omitted or the operator or agent may be used as the referring financial service provider according to different embodiments of the present invention. According to one embodiment of the present invention, the referring financial service provider information is used by the present invention to monitor the subscriber- operator relationship for compliance with the terms of the agreement and for payment purposes.

In step 558, according to one embodiment of the present invention, the chart of accounts to be used by the subscriber is identified. For example, a subscriber may imtially be assigned a default chart of accounts used by the present invention, wherein the chart of accounts is the default for all new subscribers, for all subscribers of the same subscriber type, for all subscribers from the same referring financial service provider, or a combination of the aforementioned. According to one embodiment of the present invention, a customized chart of accounts specially created to meet a subscriber's specifications may be used as the initial chart of accounts assigned to the subscriber if it has been created prior to the set-up of the subscriber identifying information.

In step 560, according to one embodiment of the present invention, the asset classification scheme to be used by the subscriber is identified. For example, a subscriber may imtially be assigned a default asset classification scheme used by the present invention, wherein the asset classification scheme is the default for all new subscribers, for all subscribers of the same subscriber type, for all subscribers from the same referring financial service provider, or a combination of the aforementioned. According to one embodiment of the present invention, a customized asset classification scheme specially created to meet a subscriber's specifications may be used as the initial asset classification scheme assigned to the subscriber if it has been created prior to the set-up of the subscriber identifying information. In one embodiment of the present invention, the asset classification scheme may be different than the client data aggregation categories (discussed in the data aggregation section of this specification) that may be provided by the financial service provider to assist in the aggregation of the client data. The above mentioned steps in FIG. 5b are not mandatory and their order may change according to various embodiments of the present invention.

Returning now to FIG. 5 a, in step 504 all of the participating owners under the subscriber agreement are identified. The entry of identifying information concerning individuals and legal entities that participate in subscriber wealth, i.e., termed "participating owners", may be performed by the operations staff of the present invention provider or by authorized agents according to one embodiment of the present invention. Participating owners are added by specifying the appropriate already existing subscriber (the subscriber can be chosen from a list of existing subscribers or directly entered) and then entering and validating the basic identifying information for the participating owners according to one embodiment of the present invention. Participating owner basic identifying information may, for example, include name, social security number or tax ID, gender, date of birth, address of residence, mailing addresses, telephone and fax numbers, email addresses, and country of citizenship. The exact nature of the basic identifying information may depend on the type of entity the participating owner is according to one embodiment of the present invention. For example, a participating owner may be an individual or a legal entity such as a trust, foundation, institution, s-corporation, or partnership. If a subscriber's identity is kept confidential, as-previously discussed, the participating owner identity may also be kept confidential in the same manner by having the referring financial service provider maintain the participating owner identifying information and by having the present invention use only the locally generated identifiers (those generated by the present invention) as the participating owner basic identifying information.

In step 506, the relationship structure between the participating owners is established. According to one embodiment of the present, the relationship structure is established by providing a basic definition of the relationships between the participating owners for an existing subscriber. For example, these relationships may be familial, fiduciary, or otherwise defined amongst the participating owners. According to one embodiment of the present invention, the relationship information is provided to the operator by the client and entered into the system by the operator staff.

FIG. 5c is a block diagram illustrating the steps in defining the relationship structure between the participating owners according to one embodiment of the present invention. A relationship structure includes the individual relationships amongst the participating owners. In step 562, according to one embodiment of the present invention, the subscriber is identified. For example, the identification of the subscriber can be done through the selection of a existing subscribers from a list. In step 564, a source participating owner is selected according to one embodiment of the present invention. A source participating owner may already be defined in the system and is the participating owner for whom the relationship is specified. For example, using the entities shown in FIG. 5d, in order to define Bill as the parent of Samantha, Bill would be selected as the source participating owner. Just as a source of the relationship is chosen, a target participating owner is also selected 566 according to one embodiment of the present invention. For example, in order to define the relationship given in the example above, Bill would be defined as the source participating owner and Samantha as the target participating owner. Once both a source and target of the relationship is selected, the type of relationship may be defined 568 according to one embodiment of the present invention. A relationship type may, for example, include: familial, fiduciary, and legal. According to one embodiment of the present invention, a relationship subtype may also be selected 570 further defining the relationship. For example, a relationship subtype may include: spouse, parent, child, sibling, sponsor, and guardian. In an alternative embodiment of the present invention, no relationship subtype is used and instead the relationship type is more descriptive like the subtype previously mentioned. In the previously given example, Bill, the source participating owner, has a familial relationship of the parent relationship subtype with target participating owner Samantha. Conversely, Samantha the source participating owner has a familial relationship of the child relationship subtype with target participating owner Bill. In addition to relationship type and subtype, other relationship characteristics may also be defined 572 according to one embodiment of the present invention. Other relationship characteristics may, for example, define if there is joint or individual reporting for husband and wife in a spouse relationship. Once the aforementioned information has been defined and selected for a relationship, the process is repeated for other relationships between the participating owners for a subscriber until the entire relationship structure is defined. The aforementioned steps in FIG. 5c are not mandatory and their order may change according to various embodiments of the present invention. FIG. 5d is a block diagram illustrating a sample relationship structure for a subscriber. Bill 574 is the patriarch of the family and is married to Martha 576 both of which are the first generation in this family (denoted by Gl for Bill denoting first generation and Gl-S for Martha indicating spouse of a family member). Reporting for Bill and Martha is done jointly and therefore there is no distinction such as Gl A and GIB for each. In this example, Helen

578 is Mary's 576 sister and shown by a dashed lined relationship for sibling. The OPO refers to other participating owner. Bill 574 and Mary 576 have two children Samantha 580 and Bob 582 who are both second generation (G2) in this familial structure are reported on separately indicated by the G2A for Samantha 580 and the G2B for Bob 582. Bob 582 is married to Jessica 584 and joint reporting is done for them indicated by the G2B for both Bob

582 and Jessica 584. Jessica's 584 status as a spouse marrying into the family is denoted by the additional S designator in the G2B-S. Bob 582 and Jessica 584 have two children Theodore 586 and Judy 588 who are jointly reported on as indicated by the G3 A designator indicating joint reporting for the third generation. FIG. 5d is merely an exemplary diagram to illustrate a relationship structure and does not necessarily indicate any type of reporting or code usage (e.g., Gl, Gl-S, G2A, etc.) by the present invention.

In step 508 of FIG. 5a, the subscriber holding entities are established. Subscriber holding entities are the legal entities that participate in asset ownership. Holding entities both own assets are themselves owned by participating owners or by other holding entities. Holding entities are typically established to limit liability, to achieve specific private and family ownership goals, take advantage of tax laws, comply with regulations for certain industries or geographical areas, or for a number of business reasons. The steps necessary in establishing a holding (or. legal) entity begin, according to one embodiment of the present invention, with identifying the subscriber for which the holding entity is to exist. According to one embodiment of the present invention, the holding entity is unique within a subscriber but not necessarily across subscribers and, therefore, a unique holding entity (legal entity) ID , is generated. According to one embodiment of the present invention, the basic identifying information for the holding entity is then entered and validated. The basic identifying information may include such information as name, tax ID, addresses, phone numbers, fax numbers, email addresses, and contact information. Holding entity information is, according to one embodiment of the present invention, received from the client or authorized source and entered by the operator's staff. Next, according to one embodiment of the present invention, the holding entity type is specified. For example, a holding entity (also termed "legal entity") may be a limited liability company (LLC), a partnership, a trust, an s-corporation, a foundation, or a public institution. Holding entities are also referred to as legal entities throughout this document.

Once the holding entities have been defined, according to one embodiment of the present invention, the subscriber ownership structure may be defined in step 510 of FIG. 5a. The subscriber ownership structure is the identification of which participating owners and legal entities have ownership stakes in the other legal entities, assets, and accounts and what their specific ownership stakes are. The subscriber ownership information may be entered by the client or authorized agent directly or may be sent electronically or by hard copy to the operator, whose staff may then enter the information into the system. According to one embodiment of the present invention, the subscriber for whom the subscriber ownership structure may be entered is identified. Next, according to one embodiment of the present invention, the source which is the participating owner or legal entity that has an ownership stake in another legal entity, asset, or account is identified. Also, according to one embodiment of the present invention, the target which is the legal entity, asset or account over which ownership exists is identified. The percentage ownership that the source has in the target may be identified. For example, participating owner A (the source) may have 20% ownership of s-corporation X (the target). This process may be repeated for each ownership interest for the subscriber. These individual ownership interests makeup the subscriber ownership structure.

In step 512 of FIG. 5a, according to one embodiment of the present invention, the scope of access provided may be defined. Authorized agents (and certain accessing participating owners) acting on behalf of participating owners and holding entities of the subscriber are granted viewing rights to specific holding entities, assets, and accounts associated with a subscriber. The scope of access may be, for example, entered into the system by the operator's staff, by the subscriber, or authorized agents. According to one embodiment of the present invention, the scope of access provided is uniquely specified for each entity given access permission to the data even if the access permission granted is identical. For example, according to one embodiment of the present invention, the subscriber for which the scope of access applies may be identified. Then, a unique identifier and descriptive name for the scope of access definition may be generated. Alternative embodiments of the present invention do not require either a unique identifier, a descriptive name, or both. The authorized agent or participating owner for which the scope of access is to be defined is then identified. Next, according to one embodiment of the present invention, the selection of a holding entities, assets, and accounts for which access is to be granted may be made. In one embodiment of the present invention, groupings of holding entities, assets, and accounts may be defined and these grouping may be used in defining scope of access. An alternative embodiment of the present invention instead allows the specification of specific holding entities, accounts, and assets from those that have already been defined for the subscriber. In another embodiment of the present invention a combination of groupings and specific holding entities, accounts, and assets may be selected when defining scope of access. This process may be repeated for each scope of access to be provided. In step 514 of FIG. 5a, a chart of accounts is set-up. A chart of accounts are the bookkeeping and accounting accounts to be maintained by the accounting module according to one embodiment of the present invention. It is possible according to one embodiment of the present invention to implement a standardized account structure used by all subscribers. A more advantageous and flexible embodiment of the present invention allows subscribers to customize the chart of accounts they use in order to meet any particular reporting needs or desires they may have.

In step 516 of FIG. 5a, actual investment information is entered. All appropriate identifying information regarding the asset or liability may be entered so that it can appropriately be tracked by the system. The information is provided by the subscriber, the participating owners, authorized agents, and financial service providers either by electronic entry through a data entry interface, through a data feed, or by electronic or hard copy transmission to the operator whose staff enters the information. Non-market traded assets, such as art and real estate, may have their valuation information provided directly by an authorized agent of the subscriber. This is an advantageous method of receiving valuation information for non-market traded assets even where these assets receive periodic valuations or appraisals made by external authorized sources because these assets are difficult to value and frequently do not sell for appraised value. Non-market traded assets are added, according to one embodiment of the present invention, by identifying the subscriber, generating a unique asset ID (e.g., VIN for antique automobile or airplane, property address or plot designator for real estate, and descriptor for a piece of fine art), and providing and validating the asset identifying information. For example, asset identifying information may include asset name, description, and asset classification category, which may be a default scheme or a subscriber-defined customized scheme. Additional elements of asset identifying information may also be included and may be specific to the asset type.

In addition to non-market traded assets, subscriber account information may also be added according to one embodiment of the present invention. Accounts are groupings of assets that mimic the participating owner or holding entity accounts at the financial service providers. Information about assets can be consolidated by account, such as balances, and positions in assets or asset categories. Accounts may have a unique identifier in the present invention system that is different than the account number used by the financial service provider. If so, a mapping between the two numbers is available. Market traded assets may also be added to the investment information according to one embodiment of the present invention. Market traded assets are first be defined in the security universe, a master library of security information containing general information about the security, before being added to investments according to one embodiment of the present invention. The investment information may then only consist of the additional information necessary to detail the holding for the participating owner or holding entity. The process of adding a market traded security asset to the investment information begins, according to one embodiment of the present invention, with the first step of identifying the subscriber for whom the investment information is to be added. The account for which the asset is to be added may also be specified as well as the asset type. A valid industry standard asset identifier, such as a CUSIP or other identifier, may also be specified where available for the security. Additional tracking and accounting information may also be included. For example, cost basis information determined by averaging or by tax lot may also be included. The terms for future contracts, forward contracts, and options contracts may also be entered and validated.

In step 518 of FIG. 5a, authorized agents related to the participating owners, holding entities, or the individual assets of the participating owners are identified. For each authorized agent, a scope of access definition may also be provided as previously discussed.

In step 520, the initial holdings information are entered. Initial holdings information, for example, includes the amount of the holding, the tax basis for the holding, and other descriptive information regarding the holding. In step 522, according to one embodiment of the present invention, initial reports for all assets of each participating owner are prepared to ensure that initial data was correctly entered into the system. For example, balance sheets, holdings reports, and allocation reports may be prepared and reviewed.

Steps 524-528 are repeated as information is updated for the subscriber. In step 524, the entry of valuation information for all assets as of a particular valuation date may be made. The valuation information for market traded assets such as stocks may be obtained from market data providers such as commercial quote services while the valuation information for all non-market traded assets such as art, collectibles, & real estate may be provided by the client even if third party appraisals are available because the sale or purchase value of these types of assets often do not match the appraised value. The preparation of reports 526 is the process of establishing a new subscriber according to one embodiment of the present invention. The scope of the reporting, such as which participating owner may be included in the reports and which of their assets may be included, may be defined before the reports are prepared. For example, reports are prepared for the entire subscriber as well as for each participating owner individually. When participating owners are married, separate reports may be prepared for their jointly owned assets, their individually owned assets, and the combined assets of both spouses. According to one embodiment of the present invention, transaction data is then entered 528. For example, transactions for both market traded assets and non-market traded assets may be entered in the system (the consolidation database) and the appropriate updating of the general ledger (chart of accounts) data may be made.

Valuation information may be updated for the subscriber ownership structure 524 which in turn may result in the preparation of updated reports 526. Transaction information may continue to be entered until the valuation information is again updated. The aforementioned steps in FIG. 5 a are not mandatory and their order may change according to various embodiments of the present invention.

Periodic Processing of Subscriber Information

According to one embodiment of the present invention, receiving transactions for subscriber accounts is a step in the periodic processing performed by the present invention whereby the financial service providers provide information to the system by electronic transmission of transactions affecting subscriber accounts. For example, transactions may include trade transactions for market traded securities, cash transfers, and cancellations or changes to trade terms. Transaction related information for market traded securities is received simultaneously with the actual trade transaction to provide current reporting of holdings for this type of security according to one embodiment of the present invention. For example, this electronically transmitted transaction related information may contain all details of the transaction including the dollar amount involved, identity of the security involved, amount of the holding involved, date of the transaction, etc. The tasks involved in this step include receiving a file and checking that file for integrity according to one embodiment of the present invention. For example, all files may have control measures to assist in the determination of whether a file transmission is complete. These control measures may for example include begin-file and end-file markers, record counters, etc. Then, according to one embodiment of the present invention, the receipt of the file is acknowledged and, if the file does not pass the integrity check, a request is made for the retransmission of the file. Next, the received data is reformatted, exceptions are determined, and the data is mapped to the appropriate rows/records and attributes/fields in the database(s) of the present invention according to one embodiment of the present invention. Exceptions may for example result from a corrupt row/record structure in the received file, an attribute/field format in the received data not complying with the data rules specified, or the attribute/field value not falling within a specified domain or range. The sending financial service provider's account numbers are then mapped to the account numbers used by the present invention. Once the account numbers have been mapped, the transformed, mapped, and checked data may then be imported into and integrated with the data in the present invention databases according to one embodiment of the present invention. Also, the record of scheduled data transmissions from the financial service provider for the account(s) may be updated.

Subscriber transactions may also be recorded by the accounting module to facilitate the record keeping for the client. According to one embodiment of the present invention client data transmitted by the financial service providers is handled by the data acquisition module (not shown in FIG. 2) which may send the information to the accounting module 245 as well as Jo the consolidation database(s). For example, data received for a transaction regarding a market traded security is not only stored in the present invention database(s) by the data acquisition module but is also sent to the accounting system so that this accounting information also remains current. The process of transmitting subscriber account information from the data acquisition module to the accounting module 245 can occur when the new information is received and processed or may occur on a daily basis according to different embodiments of the present invention. The accounting module, according to one embodiment of the present invention, checks with the asset/liability table discussed below

(security universes) to determine if an asset has aheady been defined in the security universes. For example, the security universes are checked for each transaction forwarded to the accounting module by the data acquisition module. According to one embodiment of the present invention, if the security is not already defined, the transaction is placed in an exceptions queue, where further processing is delayed until a message is received from the security information management module (not shown in FIG. 2) that the necessary modifications have been made to the security universes.

Data Organization and the Consolidation Database

The data consolidation component is responsible, according to one embodiment of the present invention, for using the specifications stored in the subscriber profiles to build financial consolidation structures, populate these consolidation structures, and facilitate the review of these populated consolidation structures. Consolidation structures link sets of investment owners, such as participating owners and holding entities, with sets of owned entities, such as accounts, assets/liabilities, asset/liability types, and holding entities. These consolidation structures are populated with detailed financial data (i.e., holdings, positions, pricing, valuations, transactions, and assessments) that is used to generate customized reports that meet the viewing, drill-down, and roll-up of subscriber participating owners, subscriber holding entities, and subscriber authorized agents. The populated consolidation structures are made available for review, both by automated means and by human review, in order to ensure the completeness, consistency, and interconnectedness of the data. According to one embodiment of the present invention, the primary and largest unit of data consolidation and reporting is the subscriber with no data consolidation taking place across subscriber boundaries. A subscriber may represent an individual, a legal entity (i.e., a partnership, trust, S-corporation, foundation, or public institution), or a consolidation of one or more of each. For example, a subscriber can represent a family consolidating the information on the individual family members versus another example where a subscriber represents only an individual. A subscriber is a unique unit of data consolidation established by either an individual who enters into a contract with the commercial entity operating the present invention or is established by a client of a referring financial service provider that, as part of their client services, offers access to the commercial entity operating the present invention.

FIG. 3 a illustrates a subscriber table 300 in the consolidation database according to one embodiment of the present invention. The subscriber ID field 301 contains a unique identifier serving as the table key. The subscriber name field 302 contains the subscriber name used by the reporting module. The referring financial service provider field 303 contains a unique identifier for the institution referring the client to the commercial entity operating the present invention and is only used where a referring financial service provider exists as opposed to the situation where an individual directly contracts with the commercial entity operating the present invention. The referring financial service provider name field 304 contains the institution name, where applicable, that is used by the reporting module. The subscriber table 300 may contain additional or alternate information as may be desired by or necessary to various embodiments of the present invention. As stated previously, subscriber information may be obtained from the financial service providers and authorized agents providing services for the subscriber and/or associated participating owners. According to one embodiment of the present invention, subscriber information is obtained through data feeds established through data acquisition agreements between the operator and the data sources.

According to one embodiment of the present invention, the data consolidated for a subscriber is organized into one or more entities, a secondary and lower level of data consolidation. An entity can represent a participating owner (an individual), a legal entity (i.e., a holding entity), or an account. For example, given a subscriber representing a family, one entity may be a wife while another entity may be an investment management account partially owned by the wife. In the example discussed, the wife would be a parent entity and the investment account a child entity. An entity is also a unique data consolidation unit like a subscriber.

FIG. 3b illustrates an entity table 310 in the consolidation database according to one embodiment of the present invention. The subscriber ID field 311 contains the unique subscriber ID for the subscriber under whom this entity falls. The entity ID field 312 contains a unique entity identifier and the entity name field 313 contains the name of the entity used by the reporting module. The entity type field 314 identifies the type of entity being described. For example, the entity type field 314 can indicate that the entity is a portfolio of accounts. The entity currency field 315 indicates the base currency used by this entity. The entity table 310 may contain additional or alternate information as may be desired by or necessary to various embodiments of the present invention.

Relationships exist between the entities and are appropriately defined. In the example embodiment, relationships are used to define ownership stakes but can, in other embodiments define a broader range of relationships. According to the above example, a relationship exists between the wife entity and the investment account entity. In this relationship, the wife is the parent entity having the ownership stake in the investment account, which is the child entity in this relationship. This example is more clearly shown in FIGS. 3c and 4b. FIG. 3c illustrates an entity relationship table 320 in the consolidation database according to one embodiment of the present invention. The relationship ID field 321 contains the unique relationship identifier for a given relationship. The parent entity ID field 322 and child entity ID field 323 contain unique entity identifiers for the parent and child entity respectively. The entity ownership field 324 contains a percentage value that indicates the percentage of the child entity owned by the parent entity. The role field 325 contains a classification value for the role of the relationship. In the above example, the wife participating owner is a parent entity and the investment account is a child entity. The percentage ownership that the wife exercises over the investment account is the entity ownership value. The entity relationship table 320 may contain additional or alternate information as may be desired by or necessary to various embodiments of the present invention. FIG. 4b illustrates a subscriber as a whole with all its subordinate entities and entity relationships according to one embodiment of the present invention. The subscriber is a founder 411 of a partnership 418 and the subscriber aggregates family data for the founder's family 412-414. Some of the entities for the subscriber represent individual participating owners 411-414. The founder 411, his wife 412, his first child 413 and his second child 414 are the four participating owners shown in FIG. 4b. These four participating owners 411-414 have a parent relationship with a family trust entity 415. The relationships are shown by the lines connecting each participating owner 411-414 with the family trust entity 415. Each line also shows the percentage (the entity ownership value) of the family trust child entity 415 that each of the individual parent entity is entitled. For example, the founder 411 is entitled to 52% of the family trust 415 while the wife 412 and two children 413-414 are each entitled to

16% of the family trust. The family trust 415 itself is a parent entity having the following ownership stakes in these child entities: 100% of an asset management account 416; 100% of a custodial account 417; and 75% of a partnership 418. The partnership entity 418 is also a parent entity with the following ownership stakes in these child entities: 25% of asset management account 2; 50% of custodial account 2 419; and 75% of the brokerage account

421. As stated earlier, all the entities in FIG. 4b belong to the same subscriber. The subscriber, entity, and relationship information illustrated in FIG. 4b are stored in the consolidation database 230 in the previously described subscriber, entity, and entity relationship tables respectively according to one embodiment of the present invention. Entities can be further defined according to the entity type 314. For example, accounts and legal entities are two types of entities. FIG. 3d illustrates an account table 330 in the consolidation database according to one embodiment of the present invention. The account ID field 331 contains the unique account identifier for a client account at a financial service provider 200 or financial service provider network node 190. The entity ID field 332 contains the unique entity identifier that links the account information with the entity and relationship information in the entity 310 and the entity relationship 320 tables. Several additional fields can exist to further define the account. Of particular interest according to one embodiment of the present invention is the source system information. The source system ID field 333 contains the unique identifier for the financial service provider processing the account. The source system account ID field 334 contains the account identifier used by the source system (the financial service provider) to identify the client account. The information contained in both these source system fields 333-334 are used by the present invention to obtain and update the client's financial information. For example, this information can be used to match rows in the table with retrieved client financial information in order for the appropriate data to be updated and to prevent data redundancy (i.e., storing the same information in unnecessary additional rows of the account or entity tables). The account currency field 335 contains a value identifying the base currency used for the account. This information is used for reporting and accounting purposes. The account table 330 may contain additional or alternate information as may be desired by or necessary to various embodiments of the present invention.

Legal entities (i.e., "holding entities"), like accounts, are also a subset of entities. FIG. 3e illustrates an legal entity table 340 in the consolidation database according to one embodiment of the present invention. Each legal entity may be identified by a unique legal entity identifier 341. The legal entity table 340 contains information about the legal entity and may be linked to the entity table 310 and entity relationship table 320 by an entity ID field 342, just like the accoimt table 330 is. The legal entity name 343 and the type of legal entity 344 may also be included in this table. The legal entity type may, according to one embodiment of the present invention, be based on a legal entity classification scheme used by the present invention. This table may also contain a legal entity currency field 345 containing a value identifying the preferred currency for the legal entity. The legal entity currency field may be used to convert financial values into this currency value for reporting purposes. Additional address and residency information for the legal entity may also be included in this table according to one embodiment of the present invention. The legal entity table 340 may contain additional or alternate information as may be desired by or necessary to various embodiments of the present invention. In the example embodiment of the present invention, entity changes, such as the addition or deletion of assets or changes in ownership, that modify the original consolidation information are recorded by date and tracked according to one embodiment of the present invention. This allows a historical record of modifications to the original consolidated client financial information to be kept. The reporting module can provide the client with an accurate record of such changes. Entity changes can also result in entity annotations which are comments that are included by the reporting module with the information presented to the client. Entity changes and annotations are maintained in one or more tables of the consolidation database. The entity changes can be made, according to one embodiment of the present invention, by the operator staff after they have received information from the client or authorized source regarding a change in the entity. In an alternative embodiment, entity changes may be sent electronically by the client or authorized source to the operator where they are either electronically or manually processed.

Subscriber and entity information establishes the ownership relationships for the client financial information. The actual asset and liability information is stored in one or more additional tables and linked to the entities. These tables are discussed below following a general discussion of assets and liabilities. An asset is any item that may be owned or possessed as a right by an individual or legal entity that has an economic, commercial, or exchangeable value. For example, an asset may be stock in a corporation, real estate, a work of art, etc. A liability is any item that may owed by an individual or legal entity. For example, a loan of any type is a liability. According to one embodiment of the present invention, assets are anything that can be owned versus items that are actually owned and liabilities are the things owed rather than the actual debt. For example, a share of XYZ Corporation is an asset whether or not the client owns it and a mortgage is a liability rather the $50,000 owed on the mortgage. The actual ownership of an asset or the debt of a liability is represented by a position in the asset or liability. For example, as discussed below, a liability may be a mortgage defined in the asset/liability table while a position in the mortgage is an actual amount of mortgage debt owed which is recorded in the position table. In another example, XYZ Corporation stock is an asset that may be defined in the asset/liability table while the actual ownership of 1,000 shares of XYZ corporation stock would be a position in the asset and may be defined in the position table.

FIG. 3f is a block diagram illustrating the asset/liability table according to one embodiment of the present invention. The asset/liability table 350 or tables contains the details about each asset and liability which may be needed in addition to the classification schemes discussed below according to one embodiment of the present invention. According to one embodiment of the present invention, unique identifiers 351 are generated by the present invention to identify each asset and liability. In addition to this unique ID 351, asset/liability names 353, such as "XYZ Corporation common stock", may also be included in the consolidation database. One embodiment of the present invention includes a source system identifier 352 to identify the source financial service provider where the asset/liability originated. This source system ID 352 coupled with an attribute for asset liability code containing the unique asset/liability code used by the source system to identify the asset/liability may be used to linked the asset/liability information in the present invention with the source financial service provider according to one embodiment of the present invention. Other information about the asset/liability may also be defined in the present from the data provided during the data acquisition process. For example, maturity date 354 is the date that an asset/liability is repaid or a forward exchange contract is settled. Maturity date 354 may be empty for assets/liabilities that do not have maturity dates such as equities. Interest rate 355 is another example of a descriptive field that may contain the annual interest rate applied to the particular asset/liability. Again, interest rate 355 may be empty for assets/liabilities that do not have interest rates such as equities. Another example of a descriptive field is price factor 356 that may contain the multiplier used to turn a bond percentage price into a decimal value. Price factor 356 may also be empty for assets/liabilities that are priced on a unit basis. In addition to a unique asset/liability identifier

351 used by one embodiment of the present invention, assets may also be identified using industry standard identifiers when available such as the CUSIP 358 for traded assets in the United States and Canada, ticker symbol 357, Sedol, and Cedel (the last two are both international asset identifiers). The asset/liability tables may also take into account currency differences by tracking the asset/liability currency code 359 (the currency code of the currency in which the asset/liability is denominated), the asset/liability pricing currency (the currency paid for the asset or received for the liability), the income/expense currency 360 (the currency in which dividends and income are received or interest and payments are made). The income/expense currency 360 may fiirther be divided to differentiate dividends and interest currency from income and repayment currency though this may not be necessary. The asset/liability table 350 may contain additional or altemate information as may be desired by or necessary to various embodiments of the present invention. According to one embodiment of the present invention, assets and liabilities are classified according to a classification scheme. Asset and liability classification may be received from the financial service providers during the data acquisition stage according to one embodiment of the present invention. The financial service providers may use unique or customized classification schemes and therefore do not provide standardization across the data acquired for the subscriber. For this reason, one embodiment of the present invention provides a present invention generated universal classification scheme under which the asset/liability data received from the financial service providers is placed. For this embodiment, the data acquisition agreement between the operator and the financial service provider may provide a translation table between the classification scheme used by the financial service provider and the operator. As stated earlier, as part of the data transmitted to the operator, the financial service provider may provide the universal categories used by the present invention. If these universal categories are not provided by the financial service provider, the operator may use the translation table defined during the data acquisition agreement stage to find the appropriate category or categories for the asset/liability based on the classification used by the financial service provider. Another embodiment of the present invention has the operator's staff review the asset/liability information received and assign the appropriate universal classification or classifications. Another embodiment of the present invention, allows the universal categories to be defined by the subscriber for the subscriber data. Like the previous embodiment discussed, the data acquisition agreement may provide a translation table between the financial service provider utilized classification scheme and the subscriber-defined universal (across all financial institutions) classification scheme. Yet another embodiment of the present invention allows the classification scheme of one financial service provider to be used as the universal classification scheme for all subscribers or for a particular subscriber. For example, according to the embodiments discussed, three possible classification schemes are: 1) asset/liability type classification scheme, 2) industry classification scheme, and 3) accounting category classification scheme. The asset/liability type classification scheme uses asset/liability categories defined for the present invention. For example, the asset/liability categories for assets may include securities, mutual funds, cash, and options. In a further example, asset/liability categories for liabilities may include mortgages, personal loans, and credit cards. In addition to an asset/liability category, assets may also be categorized by an industry classification scheme using industry category codes. For example, industry categories may include biotechnology, communications, energy, consumer durables, and financial services. The classification of assets by industry is usually a customized process by the financial service providers providing the client services. Some financial service providers may use a standard value in their industry classification such as a SIC while others may use then own industry codes and categories. Assets and liabilities may also be categorized according to accounting category classification scheme using accounting categories. For example, liabilities may be categorized as open such as a credit card or overdraft protection on a checking account. In another example, liabilities may also be categorized current and noncurrent as per standard accounting practices. In one embodiment of the present invention, the classification scheme used by the referring financial service providers may also be maintained and may be linked to any additional classification scheme used by the present invention so that the original classification scheme is not lost and may be used by the reporting module, the other core services, and the value added services.

As previously stated, actual asset ownership and liability debt amount information is maintained for the client in the position data not in the asset and liability data according to one embodiment of the present invention. Each position is linked to an account (an entity), an asset or liability, and a source system such as a referring financial provider that maintains the client's position. Information maintained for each position is stored in one or more tables of the consolidation database with the tables containing all the relevant information on the asset or. liability position. For example, a position for stock in XYZ Corporation (an asset) may include information on purchase data, cost basis, position currency code, market value data, and unrealized gain loss information. Position data may contain all the information deemed necessary for thorough asset/liability tracking and reporting. Information about positions is received during the data acquisition process and position data may be part of the data acquisition agreement between a financial service provider and the operator.

FIG. 3g is a block diagram illustrating the position table according to one embodiment of the present invention. The position table 365 may contain a source system code 366 for the financial service provider where the position information originated. The source system code 366 may be used to link the data between the position table with the financial service provider during the data consolidation process where the transformed data is written into the consolidation database. Each position may be assigned a unique position identifier 367 in order to identify the position according to one embodiment of the present invention. The position ID 367 may serve as the key for the position table in the consolidation database. Account ID 368 is the present invention generated account identifier and may be used to link the position with an account. An account may be composed of one or more positions in various assets and liabilities and therefore it is advantageous to link the position with its associated account. The position table 365 may also contain a source system account ID 369 that ^an be used in conjunction with the source system code 366 to link the position data with a position for an account maintained by the financial service provider. As stated before, this information assists in the data consolidation process where the data from the financial service provider is mapped to data stored in the present invention. Each position, according to one embodiment of the present invention is a stake in an asset or liability and so an asset/liability ID 370 may also be included in the position table 365 for identification purposes. A source system asset/liability ID 371 may also be included to help map the present invention asset/liability ID to the asset/liability ID used by the source financial service provider. Other descriptive fields may be included about the position defining any necessary details. For example, units 372 is a field containing the number of units involved in this position. Another example is the price in nominal currency and position currency code 373 fields which may include the current price of the position in the currency of the position and a code identifying the currency of the position price. This information may be used with additional fields such as the price in base currency and base currency code 374 which may include the current price of the position in the base currency of the account and the code identifying the currency of the account. The price effective date 375. field may contain the date the current price was determined. Other or alternate descriptive fields concerning the position may be included in the position table or tables as deemed necessary in other embodiments of the present invention.

In addition to individual positions, information about total by position may be stored in one or more tables of the consolidation database according to one embodiment of the present invention. The total data can be for a particular asset/liability or for a classification scheme. For example, total by position data can be the total by asset/liability category on a given date such as the total in equities on August 1, 2000. In another example, total by position data can be the total by industry classification scheme on a given date such as the total in energy sector assets (stock) on August 1, 2000. Totals by position are based on aggregating information provided by the financial service providers and therefore, according to one embodiment of the present invention, this information is calculated by the present invention using the present invention's classification and is not information that is provided during the data acquisition process. Many different totals by position may be calculated for an entity such as a participating owner, legal entity or an account. For example, a total may be calculated for all market traded assets in the biotechnology industry. This total would be calculated by adding up the current position valuations for all the assets that have been classified as being biotechnology market traded assets according to the asset/liability classification scheme previously discussed. Tax information may be kept in one or more separate tables of the consolidation database, may be incorporated in the fields of other tables in the consolidation database, or may be kept in a combination of both according to one embodiment of the present invention. For example, tax information may be tracked by tax lot, a subset of a position (sub-position), with a fixed asset purchase date and cost basis from which to calculate tax liability. Tax information may include purchase dates in order to calculate long-term versus short-term gains and losses as well as cost basis for the tax lot, where a tax lot is a purchase that is grouped together for tax purposes. For example, if participating owner buys 100 shares of XYZ corporation for $61.25 on Tuesday and another 100 shares at $61.25 on Thursday, both purchases may be separate tax lots because of the date which is important capital gains calculations which affect the amount of tax paid. Tax information comes from the transaction information provided by the financial service providers according to the data acquisition agreement and may be maintained separately from the other transaction data even though some redundancy may exist.

In addition to accounts and positions, transactions may also be accounted for in the consolidation database according to one embodiment of the present invention. A transaction records the execution of a business event such as a trade, corporate action, or other activity effecting the assets or liabilities of the client. For example, buy and sell transactions for assets or borrow and repay transactions for liabilities may all be recorded and stored in one or more tables of the consolidation database. Buy transactions are the purchase or receipt of an asset while a sell transaction is the exchange or trade of an asset. Borrow transactions are the incurring of a liability (taking on debt) while a repay transaction is a partial or full repayment of the debt for the liability. In another example, purely accounting transactions that impact a client account or position may also be recorded in the consolidation database. Accounting transactions record the financial effects of a business transaction. Transactions show how an account or position has changed and for what reason. Transactions may be used not only to calculate changes in the clients financial data but also may be used by the reporting module. In one embodiment of the present invention, the type of fransaction is also recorded in the consolidation database.

FIG. 3h is a block diagram illustrating the fransactions table 380 according to one embodiment of the present invention. The source system code 381 identifies the financial service provider transmitting the transaction information to the present invention. The asset/liability code 382 identifies the asset or liability for which the transaction was performed. The entity ID 383 identifies the owner tracking the asset/liability in question. These three fields are used to link the transaction to a source financial service provider, an asset/liability aheady defined in the consolidation database, and an entity exercising some ownership over the asset/liability positions involved in the transaction. Additionally, according to one embodiment of the present invention, a unique transaction ID 384 may also be used to uniquely identify each transaction. A transaction type 385 may help identify the type of transaction that has occurred. For example, a transaction type may indicate a purchase, a sale, cash transferred in, cash transferred out, shares transferred in, share transferred out, deposits, and withdrawals. According to various embodiments of the present invention, various dates may be stored for the transaction. For example, the transaction date 386 may record when the fransaction was conducted. Other dates may include the effective date of the transaction and the settlement date for the transaction. The number of units of the asset/liability involved in the transaction 387 may also be stored in the transaction table. The status of the transaction 388 is also data that may be relevant and stored in the transaction table as well. For example, a transaction status may be executed, pending, or settled. Several price and currency figures may also be stored in the transaction table. Unit price (the price per unit on the transaction date), the transaction currency 389 (the currency for the transaction) are two examples of price and currency information that may be relevant. Other fields in the transaction table may include accrued interest nominal currency (accraed interest of the asset/liability expressed in the currency of the asset/liability), accrued interest base currency (accrued interest of the asset/liability expressed in the base currency of the account), transaction commission in fransaction currency, transaction commission in base currency, settlement amount in settlement currency, settlement amount in base currency among others. The transactions table 380 may contain additional or alternate information as may be desired by or necessary to various embodiments of the present invention.

According to one embodiment of the present invention, data concerning totals by transaction type may also be stored in one or more tables of the consolidation database. Totals may be calculated and stored by transaction type and for any given asset or liability attribute resulting in many possible combinations for the total-of calculation. For example, all sell transactions for XYZ Corporation shares during the past month could become one total by fransaction type tracked and stored by the present invention. In another example, all purchase and sell transactions for XYZ Corporation bonds during the past six months could become another total by transaction type tracked and stored by the present invention. Because of the flexibility provided in determining the scope of the total by fransaction to be tracked and stored by the present invention, the total by transactions tables may require sufficient fields to adequately specify what is being tracked as well as sufficient fields to adequately describe the calculation of the total by transaction type.

In one embodiment of the present invention, one or more additional tables may be included in the consolidation database to adequately store accounting information needed by an accounting system for the client financial data. For example, accounting information used to generate the general ledger accounts (the books) for the client can be stored in these tables. In one embodiment of the present invention, performance benchmarks can also be calculated and stored in the consolidation database in order to help the client examine the performance of his/her financial investments. The present invention may include other information necessary to provide the necessary and desired services for the clients.

Core Services

The present invention provides several core services for the client as part of the data analysis stage of processing according to one embodiment of the present invention. FIG. 2 illustrates example core services 241 in the data analysis portion 240 of the business method. Core services may include data reconciliation (not shown in FIG. 2), the reporting module 242, compliance procedures 243, relationship management 244, and an accounting module 245 each of which are discussed below.

Data Reconciliation

According to one embodiment of the present invention, two types of data reconciliation may occur, for example. During the process of retrieving and entering the client financial data into the consolidation database 230, the data and the calculations made by the financial service providers are rechecked in order to reconcile the information coming from several sources according to one embodiment of the present invention. Reconciliation can be performed to any degree from no reconciliation at all on one end of the spectrum to reconciling the data to the greatest extent possible based on the data available on the other end of the spectrum. The example embodiment performs thorough reconciliation of the data. Discrepancies are tracked and reported. The reporting of reconciliation discrepancies can be directed to either or both the client and the financial service providers from the data in conflict is received. As previously stated, according to one embodiment of the present information, information received from a financial service provider that does not reconcile is sent to an exceptions queue where the conflict is resolved before the data is added to the consolidation database. The data may be received from the financial service provider as part of the data acquisition agreement and the resolution of an exception may occur in a number of ways. For example, the operator's staff may resolve the exception by directly contacting the financial service provider. The exception may, according to another example, also be sent electronically to the financial service provider requesting that the data be rechecked and resent.

The second type of data reconciliation is the reconciliation of the data stored in the consolidation database 230 with the data maintained by the financial service providers 200. This second type of reconciliation allows the present invention to stay synchronized with the client's positions at the financial service providers so that the present invention does not misreport the client's financial situation. Reconciliation of this nature may ideally be performed real-time but may also be done as a scheduled batch process. Real-time reconciliation can be performed if, for example, the financial service provider 200 is equipped to handle it; otherwise scheduled batch processing may be one alternative used. Scheduled batch processing may include an automatically executing file that initiates the reconciliation process. The automatic execution of the file is typically performed at a set time at which time the reconciliation process initiates. Reconciled data is stored in the consolidation database according to one embodiment of the present invention. This second type of reconciliation is handled through the data feeds established as part of the data acquisition process and data acquisition agreement previously discussed according to one embodiment of the present invention. If the financial service provider is not able to adequately transmit transactions electronically, a delay in the updating may occur and thus alternative expeditious means may be sought to maintain the synchronization of the present invention data with the financial service provider data.

Reporting Module The reporting module 242 is the reporting subsystem of the present invention and allows the client to view the data in multiple configurations according to one embodiment of the present invention. Data can be presented to the client in a number of formats and presentations reflecting numerous possible combinations and aggregations. For example, a portfolio view of the information may present the client with financial data by portfolio while an asset type view may present the client with data by asset type such as equities. Other presentations of data can include an account view or an exception view of the client's financial information. Report presentations can be in fixed formats either representing a custom format developed for the reporting module or mimicking a format used by a financial service provider feeding client financial data to the present invention. Report presentations may also be in a format that can be customized by a client either on a one time basis or to be saved for future use. Tliree example formats of the many in which report presentations can be made include computer screens holding data in various configurations such as Web pages, printouts mailed to the client, and formatted email messages sent to the client. Report presentations can be provided to the client directly by the commercial entity operating the present invention or they can be reformatted to reflect the identity and/or presentation style of a licensed distributor linking the client to the commercial entity operating the present invention. The consolidation database 230 contains the additional fields and tables necessary to generate a diverse range of reporting on the client financial data and the data analysis performed by the present invention. The reporting module uses the specification captured in the subscriber information to build or define the reporting structures or views of the consolidated information pertaining to sets of investment owners (i.e., participating owners and holding entities of subscribers) and sets of owned entities (i.e., accounts, assets, asset types, and holding entities). The reporting structures or views may then be populated with detailed consolidated information from the consolidated database and the results depository database. For example, the data used to populate the reporting structures may include holdings, positions, pricing information, valuations, transactions, etc. necessary to generate customized reports that meet the aggregation, analytical, drill-down (detailed viewed), and roll-up (summarized view) for the subscriber participating owners, holding entities, and authorized agents. Information may, according to one embodiment of the present invention, be included in a report where the scope of access for the report requestor permits the information to be viewed. Reports are generated according to pre-specified and ad hoc report formats using the populated reporting information.

FIG. 6 is a block diagram illustrating how reporting views may be granted according to the defined scope of access according to one embodiment of the present invention. The information shown is for the Jones Family as the subscriber. Peter 601 and Lorraine 602 are spouses who are limited partners in the Jones Family Capital Management 608 with each spouse having a 49.95% stake. Matt 603, Susan 604, Ron 605, and Tina 606 are Peter 601 and Lorraine's 602 children. Matt 603, Susan 604, and Tina 606 each have a stake in the Jones Family Corporation 607 which in turn is a general partner owning a 0.1% stake in the Jones Family Capital Management. Ron 605 and Tina 606 also own 50% stakes in trust 2 610 while Peter owns a 60% stake and Lorraine owns a 40% stake in trust 1 609. Both trust 1 609 and trust 2 610 are shown without their underlying assets in this diagram. In addition to these holding entities, each of the participating owners (Peter, Lorraine, Matt, Susan, Ron, and Tina) have their own underlying assets 620-627. The Jones Family Capital Management 608 is shown with its underlying assets: cash 611, market traded assets 612, non-market traded assets 613, and notes receivable 614. When a participating owner or authorized agent receives reports through the GUI interface or in hard copy format, the information is limited to the scope of access granted and is also based on the view according to one embodiment of the present invention. For example, if Lorraine views reports from her participating owner point of view, she may. see her underlying assets 621, the trust 1 as a whole 609 and the Jones Family Capital Management as a whole 608. From this view of Lorraine's assets, she can drill down the information to get additional details. For example, by double clicking on the

Jones Family Capital Management aggregated information 608, Lorraine or her authorized agent may view the categories of underlying assets such as cash 611, market traded assets 612, non-market traded asset 613, and notes receivable 614. This information may again be expanded for greater detail. The scope of access authorizations may limit Lorraine from seeing assets from Peter's point of view-Peter's underlying assets 620, Peter's stake in Trust

1 609, and in Jones Family Capital Management. In another example of a view, if a participating owner who has been given the appropriate access to view the Jones Family Corporation 607 (such as Susan may have) can see the asset holdings from the Jones Family Corporation 607 point of view. In this case it will be the 0.1 % share in the Jones Family Capital Management 608.

Views are the presentation of information from the perspective of a participating owner or a holding entity and involve the grouping of the underlying assets according to one embodiment of the present invention. According to one embodiment of the present invention, assets and liabilities are categorized according to a classification scheme as previously mentioned. This classification scheme is used to present information group by category for the particular view. The categories may be the same as the asset liability classification scheme or may be a separate categorization scheme used for reporting. For example, some assets for the Jones Family Capital Management 608 may be grouped together as market fraded assets. These assets may then be listed in one category that when expanded (drilled down) show the underlying market traded assets. For example, market traded assets may be a category with $44,000,000 in assets. When the market traded assets category is expanded, the $44 million is broken down into the following ten subcategories:

Kemper 8,000,000

Putnam 10,000,000

Gameo 5,000,000

McDonald & Company 4,000,000 Band & Company 3,000,000

Old Kent Bank Stock 2,000,000

One Ounce Eagle Gold Coins 1,500,000

Templeton-EMS 2,500,000

Templeton-FES 3,500,000 Genmar Bonds 5,000,000

It is possible to fiirther expand these subcategories according to one embodiment of the present invention. The categories shown above are merely exemplary. The actual categories may derive from operator generated universal categories for all subscriber according to one embodiment of the present invention. Participating owner or subscriber designated categories may also be used according to another embodiment of the present invention. For example, a participating owner may customize the default system provided categories or may be asked to supply their own reporting category scheme. Again as stated before, the asset/liability classification scheme may be used for the reporting categories according to one embodiment of the present invention.

Compliance Compliance rules 243 are rules established by the client to govern the client's accounts. For example, a compliance rule may be that no more than 10% of the client's account is invested in high-technology stocks. Compliance rules 243 such as this are common at financial service providers but are limited to only the client's assets under management by that financial service provider. For example, if a client invests 40% of then assets with financial service provider A and 60% with B and implements a compliance rule with provider A that no more 10% of client's assets will be invested in high-technology stocks, the compliance rale may only impact the client assets under provider A's management. According to one embodiment of the present invention, a compliance rule can be implemented by the client at the data aggregation network node 100 governing all the clients assets across multiple financial service providers. The present invention, according to this one embodiment, implements a universal compliance rale that previously was not possible because compliance rales were implemented on an individual financial service provider (institutional) basis.

The example embodiment of the present invention addresses the situation where a client violates a compliance rale. For example, if the client's assets exceed the compliance rule for having a maximum of 10% of the client's assets in high-technology stocks, a forced sale may be implemented, or the client may simply be informed of the situation and asked to act. For example in this situation, the client is informed that they have violated their own compliance rales which they have created. Once the client is so informed, it remains up to the client whether to alter their compliance rales or to take action in order to bring then assets back in compliance. According to one embodiment of the present invention, the operator may be authorized to issue sell or purchase orders to the financial service providers in order to have a forced fransaction in order to bring the client's assets back into compliance with the compliance rule. A forced fransaction may be possible through a previously executed client authorization allowing the data aggregation network node to initiate transactions on the client's account(s) at the financial service provider. This may be done as part of the data acquisition agreement process.

The example embodiment of the present invention also addresses a problem with compliance rules, in particular, the lack of consistent definitions. For example, the definition of what constimtes a high-technology stock can and often does vary between financial service providers. Therefore, XYZ Corporation may be categorized a software company by financial service provider A, a high-capitalization stock company by financial service provider B, and an Internet company by financial service provider C. These distinctions make the implementation of a universal compliance rule very difficult because there may be different interpretations of whether the example 10% limit on high-technology stocks is violated. In order to address this problem, one embodiment of the present invention implements at least one additional field in the asset and liability data with a universal category definition in addition to any source financial service provider given categorizations in the same data. The universal category definition can either be client defined, selected by the client from a list of categorizations (the list of categorizations being made up of the different categorizations for the asset or liability used by the financial service providers), or defined according to a set of rules internal to the present invention. For example, this process may be done online (over an information network) while the client is connected to the data consolidation network node

100. In another example, the operator may send the client a list of categorizations in a report about the clients assets and have the client respond by selecting the appropriate universal category definitions.

Relationship Management

As stated earlier, the effective management of the relationships and the structure between the financial data is an important distinguishing factor of the present invention over competitors. Relationship management 244 begins at the subscriber level by defining or linking entities to the subscriber then specifying the relationship between the entities according to one embodiment of the present invention. When the subscriber is first added by the present invention, this relationship structure is defined by either the client or by an authorized representative which may include the financial service provider as previously discussed in the establishing a new subscriber section of the specification. One embodiment of the present invention has no data consolidation done across subscriber boundaries as previously specified, however, in an alternative embodiment data consolidation can occur across subscriber boundaries. For example, an entity defined for one subscriber (subscriber A) may also be linked to a second subscriber (subscriber B) . FIG. 4b illustrates a situation where this may arise. The partnership entity 418 which is 75% owned by the family trast parent entity 415 may also show up for another subscriber for whom the remaining 25% ownership is attributed. In the alternative embodiment, the FIG. 4 partnership entity ownership can be fully accounted for by two subscribers in the example given above while under the originally specified embodiment where no data consolidation occurs across subscriber boundaries this would only be possible if all partnership entity owners were specified for the current subscriber only. The relationships and the data stracture are built by the present invention as data is received from the financial service providers. The relationships and entities are updated where appropriate as new data is received and reconciled with the existing data in the consolidation database. The data stracture and nature of the relationships has already been specified in the data consolidation section of this specification.

Accounting Module

The accounting module 245 is the accounting subsystem of the present invention and allows accounting and bookkeeping records to be kept in the consolidation database 230 and presented to the client through the reporting module 242 according to one embodiment of the present invention. The accounting module may perform standard general ledger (bookkeeping) tasks as well as more advanced and customized accounting tracking and reporting functions.

Value Added Services

In addition to the core services 241, the present invention provides several value added services for the client according to one embodiment of the present invention. FIG. 2 illustrates some of the potential value added services 246 that can be provided according to one embodiment of the present invention. Value added services 246 may include performance analysis 247, risk analysis 248, and portfolio analysis 249 among others 250 each of which are briefly discussed below.

Performance Analysis Performance analysis 247 is the comparison of the client's aggregated asset performance versus benchmarks or other strategies according to one embodiment of the present invention. For example, the performance of a client's equities in total may be compared with the an industry benchmark such as the performance of the S&P 500 over the same period of time. Performance analysis may occur in a number of ways including but not limited to calculations by asset, asset type, account, or portfolio. The performance analysis module 247 of the present invention allows a client to track performance across all his/her assets and liabilities and, thus, is more advantageous than the performance analysis implemented by a financial service provider that may limit the performance calculations to assets and liabilities under then management.

Risk Analysis

Risk analysis 248 is the calculation of risk factors for the client's aggregated asset holdings according to one embodiment of the present invention. Risk values can be assigned to all levels of assets and their aggregation. For example, risk may be calculated for an individual asset such as stock in XYZ Corporation, a portfolio, an account, and by asset type grouping among other calculations. One example of a risk calculation is the beta value, an industry standard value representing risk. Though the beta value is widely used in the industry, the way in which the beta value is calculated as well as the final beta value computed can vary considerably between different financial service providers for the same asset. The risk analysis module 248 of the present invention allows a client to track risk universally across all his/her assets and liabilities, and thus, is more advantageous than risk analysis performed locally by a financial service provider.

Portfolio Analysis

Portfolio analysis 249 is the analysis of the portfolio investment in terms of where (in which assets) and how (by what means or instruments) investments are made and may include risk and performance analyses according to one embodiment of the present invention. For example, an analysis of securities by industry or by largest holdings are two types of portfolio analysis that may be performed by the present invention. Portfolio analysis 249 performed by the present invention is similar to the portfolio analysis performed by the financial service providers 200 but, however, the present invention can perform portfolio analysis universally across multiple financial service providers. The ability to perform portfolio analysis 249 universally is highly advantageous to the client just like universal risk analysis 248 and universal performance analysis 246 are. Conventional portfolio analyses may be performed with the distinction that the portfolio analysis is being done across data from several financial institutions. For example, portfolio analysis may be done based on the reporting view. According to FIG. 6, this may permit Lorraine 602 to have portfolio analysis done on her investment view while the Jones Family Capital Management 608 may have different portfolio analysis done on then underlying data.

Results Depository Database

The results depository database 260 maybe one or more separate databases or may be partially or fully incorporated into the consolidation database 230 according to various embodiments of the present invention. The results depository database 260 contains the results of the analyses 240 performed on the client financial data. The types of analyses generating results for the results depository database 260 may include the analyses of the core services 241 (i.e., reconciliation, reporting module 242, compliance rules 243, relationship management 244, and accounting module 245) and the analyses of the value added services 246 (i.e., performance analysis 247, risk analysis 248, and portfolio analysis 249). The structure of the results depository database may change based on the types of value added services being performed for the various views of the financial data.

User Interface and Query Services

According to one embodiment of the present invention, the client interacts with the data aggregation network node 100 using a graphical user interface (GUI) 270 to simplify the interaction process. The GUI interface 270 allows the client to access the features mentioned herein as well as to retrieve the data contained in the consolidation database 230 and the analyses contained in the results depository database 260. The querying services 265 work with the GUI interface 270 to allow the client the ability to search his/her data and the related analyses. The querying services 265 can work separately from or in conjunction with the reporting module 242 to format and present the query results. In alternative embodiments of the present invention, non-GUI interfaces may be used. Other embodiments of the present invention may link the querying services 265 dkectly to the reporting module 270, which may be responsible for the presentation of all financial data to the client. The user interface may allow the client to update or add information directly into the system according to one embodiment of the present invention. For example, valuation information for non-market traded assets such as works of art or collectibles may be added by the client dkectly into the consolidation database. Subscriber Management System

In addition to the previously mentioned subscriber data stored in the consolidation database 230, subscriber information is also stored in the subscriber management system. According to one embodiment of the present invention, the subscriber management system is responsible for a wide range of functions related to setting up and maintaining subscribers, the principal unit of service, consolidation, and reporting. Even though subscribers enter into service contracts with the present invention provider and, thus, are the principal unit of service, the participating owners (both individuals and legal entities) of each subscriber are, according to one embodiment of the present invention, of greatest interest because they have actual ownership of assets and are involved in relationships with one and other that influence the manner in which consolidation and reporting is done. The subscriber management system stores the information about the subscriber such as contact and agreement information as well as the scope of access authorizations aheady discussed according to one embodiment of the present invention. The subscriber management system can be one or more databases or may be partially or fully incorporated into the consolidation database according to various embodiments of the present invention. The subscriber management system contains additional subscriber information including details about the subscriber such as home address, billing address, and phone numbers. The subscriber management system may also include the permission-based access (scope of access) data necessary for authorizing or. authenticating the authorization of a client to view particular data according to one embodiment of the present invention. This particular subscriber data is used to provide clients with permission to access financial data at the various levels mentioned under the data consolidation section previously discussed. For example, the subscriber data may let the system know that a subscriber does or does not have access to information about an entity, an account, a legal entity, an asset or liability, or a position. Permission based access is implemented using conventional access control practices for database management systems. According to one embodiment of the present invention, a token-based aecess. control and authentication system may be used to supplement the permission-based access pre iously discussed.

Claims

What is Claimed Is:

1. A method for aggregating financial data, comprising:

receiving, from a plurality of financial service providers, financial data associated with assets of a first user, each of the financial service providers providing a respective financial service to the first user;

determining categories for the financial data; and

automatically aggregating the financial data for the first user using the categories.

2. The method according to claim 1, wherein the receiving step includes electronically receiving the financial data from the plurality of financial service providers via electronic data feeds.

3. The method according to claim 2, wherein the receiving step includes periodically receiving the financial data from the plurality of financial service providers.

4. The method according to claim 1, wherein the receiving step includes receiving the financial data from the plurality of financial service providers via traditional mail.

5. The method according to claim 4, wherein the receiving step includes periodically receiving the financial data from the plurality of financial service providers.

6. The method according to claim 1, wherein the receiving step includes electronically receiving the financial data from the plurality of financial service providers via electronic data entry.

7. The method according to claim 6, wherein the receiving step includes periodically receiving the financial data from the plurality of financial service providers.

8. The method according to claim 1, wherein the receiving step includes electronically receiving the financial data from client via electronic data feeds.

9. The method according to claim 8, wherein the receiving step includes periodically receiving the financial data from the client.

10. The method according to claim 1, wherein the receiving step includes receiving the financial data from the client via traditional mail.

11. The method according to claim 10, wherein the receiving step includes periodically receiving the financial data from the client.

12. The method according to claim 1, wherein the receiving step includes electronically receiving the financial data from the client via elecfronic data entry.

13. The method according to claim 12, wherein the receiving step includes periodically receiving the financial data from the client.

14. The method according to claim 1, further comprising:

determining a relationship between a second user and the first user;

determining a respective scope of access for each of the first user and the second user; and

providing access to at least some of the financial data for each of the first user and the second user based on the respective scope of access and the determined relationship.

15. The method according to claim 1, wherein the automatically aggregating step includes mapping the financial data to the categories.

16. The method according to claim 1, further comprising:

storing the financial data in a database.

17. The method according to claim 16, wherein the storing step includes storing the financial data in a centralized database.

18. The method according to claim 16, wherein the storing step includes storing the financial data in a distributed database.

19. The method according to claim 1, further comprising:

performing an analysis on the aggregated financial data; and

receiving a result of the analysis.

20. The method according to claim 19, wherein the performing step includes performing a performance analysis on the aggregated financial data.

21. The method according to claim 19, wherein the performing step includes performing a risk analysis on the aggregated financial data.

22. The method according to claim 19, wherein the performing step includes performing a portfolio analysis on the aggregated financial data.

23. The method according to claim 19, wherein the performing step includes performing a compliance determination on the aggregated financial data.

24. The method according to claim 19, further comprising:

storing the result in a database.

25. The method according to claim 24, wherein the storing step includes storing the result in a centralized database.

26. The method according to claim 24, wherein the storing step includes storing the result in a distributed database.

27. The method according to claim 19, further comprising:

reporting the result.

28. The method according to claim 27, wherein the reporting step includes displaying the result on a monitor.

29. The method according to claim 27, wherein the reporting step includes printing the result on a printable medium.

30. The method according to claim 1, further comprising:

reporting on the aggregated financial data.

31. The method according to claim 30, wherein the reporting step includes displaying the aggregated financial data on a monitor.

32. The method according to claim 30, wherein the reporting step includes printing the aggregated financial data on a printable medium.

33. A method for providing financial data, comprising:

establishing relationships between a plurality of users;

storing in a database financial data associated with assets of the plurality of users;

determining for each of the plurality of users a respective scope of access; and

allowing a respective one of the plurality of users access to some of the stored financial data based on the respective scope of access and the established relationships.

34. The method according to claim 33, further comprising:

electronically receiving from a plurality of financial service providers the financial data;

deteπnining categories for the received financial data; and

automatically aggregating the received financial data using the categories;

wherein the allowing step includes allowing the respective one of the plurality of users access to at least some of the aggregated financial data.

35. The method according to claim 34, wherein the elecfronically receiving step includes electronically receiving the financial data via data feeds.

36. The method according to claim 35, wherein the electronically receiving step includes electronically receiving the financial data on a periodic basis.

37. The method according to claim 34, wherein the electronically receiving step includes electronically receiving the financial data via elecfronic data entry.

38. The method according to claim 37, wherein the electronically receiving step includes electronically receiving the financial data on a periodic basis.

39. The method according to claim 34, wherein the automatically aggregating step includes mapping the financial data by the categories.

40. The method according to claim 33, wherein the storing step includes storing the financial data in a centralized database.

41. The method according to claim 33, wherein the storing step includes storing the financial data in a distributed database.

42. The method according to claim 34, further comprising:

performing an analysis on the aggregated financial data; and

receiving a result of the analysis.

43. The method according to claim 42, wherein the performing step includes performing a performance analysis on the aggregated financial data.

44. The method according to claim 42, wherein the performing step includes performing a risk analysis on the aggregated financial data.

45. The method according to claim 42, wherein the performing step includes performing a portfolio analysis on the aggregated financial data.

46. The method according to claim 42, wherein the performing step includes performing a compliance determination on the aggregated financial data.

47. The method according to claim 42, further comprising:

storing the result in a database.

48. The method according to claim 47, wherein the storing step includes storing the result in a centralized database.

49. The method according to claim 47, wherein the storing step includes storing the result in a distributed database.

50. The method according to claim 42, further comprising:

reporting the result.

51. The method according to claim 50, wherein the reporting step includes displaying the result on a monitor.

52. The method according to claim 50, wherein the reporting step includes printing the result on a printable medium.

53. The method according to claim 34, further comprising:

reporting on the aggregated financial data.

54. The method according to claim 53, wherein the reporting step includes displaying the aggregated financial data on a monitor.

55. The method according to claim 54, wherein the reporting step includes printing the aggregated financial data on a printable medium.

56. A set of instractions stored on a medium and adapted to be executed by a processor to perform the steps of:

determining categories for the financial data; and

57. A set of instructions stored on a medium and adapted to be executed by a processor to perform the steps of:

receiving, from a plurality of financial service providers, financial data associated with assets of a first user, each of the financial service providers providing a respective financial service to the first user; determining categories for the financial data;

automatically aggregating the financial data for the first user using the categories;

determining a relationship between a second user and the first user;

58. A set of instractions stored on a medium and adapted to be executed by a processor to perform the steps of:

determining categories for the financial data;

automatically aggregating the financial data for the first user using the categories; and

storing the financial data in a database.

59. A set of instructions stored on a medium and adapted to be executed by a processor to perform the steps of:

performing an analysis on the aggregated financial data; and

receiving a result of the analysis.

60. A set of instructions stored on a medium and adapted to be executed by a processor to perform the steps of:

determining categories for the financial data;

reporting on the aggregated financial data.

61. A set of instructions stored on a medium and adapted to be executed by a processor to perform the steps of:

establishing relationships between a plurality of users;

determining for each of the plurality of users a respective scope of access; and allowing a respective one of the plurality of users access to some of the stored financial data based on the respective scope of access and the established relationships.

62. A set of instractions stored on a medium and adapted to be executed by a processor to perform the steps of:

establishing relationships between a plurality of users;

determining for each of the plurality of users a respective scope of access;

allowing a respective one of the plurality of users access to some of the stored financial data based on the respective scope of access and the established relationships;

determining categories for the received financial data; and

automatically aggregating the received financial data using the categories;