Financial market classification system6026381Abstract A system for classifying investment products into a set of hierarchical buckets based on existing CUSIP numbers and other prospectus information is disclosed herein. A bucket is an investment product classification that uniquely and consistently identifies an investment product type. In the preferred embodiment, there are buckets to classify individual securities and mutual funds into product, asset and fund types. Each bucket is a unique combination of product, asset or fund codes. Unique combinations of the actual codes define a particular bucket. Thus, the present invention provides a standard classification system into which all investment products can be categorized and grouped. Three sets of hierarchical investment buckets are created to provide a standard set of both general and detailed investment buckets. Each set of buckets is directed to a specific classification purpose: a set of product buckets, a set of asset buckets, and a set of fund buckets. The present invention uses CUSIP numbers as the keys for aggregating securities into a standard set of product buckets, asset buckets and fund buckets. The present invention uses the standard product buckets, asset buckets and fund buckets to classify investment positions. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE A
__________________________________________________________________________
INPUT DATA SPECIFICATIONS SUMMARY
Data as of 6/28/96 -- Direct-Marketed Fund Companies
__________________________________________________________________________
Data Selection:
Select all investment positions of retail accounts
administered in the U.S.
(This is to include all accounts of Private Investors, Small
Businesses, and
small Group Plans that your firm considers part of the
"retail" market.)
Level of Detail:
Provide one record for each shareholder account.
Data Security:
Strip out all personal identifiers (e.g., name, address,
tel/fax#, taxpayer ID)
Record Content:
ZIP+4 Code (required)
Account owner's ZIP+4
Distributor Code (required)
Your code for any independent broker/dealer or financial
advisor who is responsible for the account.
Branch Code (optional)
Your code for any of your field offices linked to the
account.
Customer Type (required)
Type of account owner (see Code Definition Tables).
Customer Gender (optional)
Wbere applicable.
Customer Age (optional)
Date or year of birth, where applicable.
Customer Date (optional)
Date or year relationship established with the Customer.
Unique Acct. # (optional)
Unique identifier for each account (to facilitate error
checks).
Account Type (required)
Type of account (see Code Definition Tables).
Account Date (required)
Date or year account established.
Fund Code (required)
Your internal code for the Fund.
Shares/Units Owned (req'd)
Number shares/units owned, as of 6/28/96, to 3 decimals.
Market Price/NAV (req'd)
Price or NAV, as of 6/28/96, reported to 3 decimals.
Balance (required)
Asset amount, as of 6/28/96, reported to 2 decimals.
Code Conventions:
Please use the same codes you use internally for all data
fields. Please do
not recode, convert, or roll-up any of your internal codes
before submission.
File Characteristics:
Please provide field-length records in a single file (maximum
block size =
32K). Record separators may be used for ASCII files. Do not
convert any
EBCDIC binary fields.
File Documentation:
Please provide documentation; including: record layout, block
size, blocking
factor, total number of records and dollars of assets
submitted.
Preferred Medium:
3480/3490 cartridges or Windows NT DAT tape back-up
__________________________________________________________________________
versions.
Tables 1 through 3 of the Appendix contain three tables describing the preferred embodiment bucket code information. The three tables describe the different product, fund and asset buckets. Although the tables illustrate the preferred embodiment, due to the nature of the investment product industry, new product, fund and asset bucket codes will continue to be added, and existing bucket codes modified. Table 1 contains a list of the buckets describing the product bucket code information. The product bucket codes of Table 1 are used to recode the CUSIP classification file 104 which, in turn, is used to recode the financial institution's position database. Table 2 and Table 3 contain the asset and fund bucket codes, respectively. The asset bucket codes are used to establish a series of asset classes. These asset classes are derived from the combination of fund and product bucket codes assigned to an investment product. The CUSIP classification file 104, therefore, cannot be recoded with the asset bucket codes until the product and fund bucket codes have been assigned to the investment products in the CUSIP classification file 104. After the fund and product bucket codes have been assigned to each investment product in the CUSIP database, the combination of fund and product bucket codes for each investment product are analyzed to determine the appropriate asset bucket code to be assigned to the investment product. After the recoding process, the CUSIP classification file 104 contains a list of investment products recoded with the product, asset and fund bucket codes from Tables 1, 2 and 3. The recoded CUSIP classification file 104 can then be used to place all of the investment products in a financial institution's position database in investment product buckets.
TABLE 1
__________________________________________________________________________
Product Codes
Bucket Codes
Prod 1
Prod 2
Prod 3
ProdName 1
ProdName 2
ProdName 3
__________________________________________________________________________
1 0 0 Cash
1 1 0 Cash Cash Balances
1 1 1 Cash Cash Balances
Cash Balances
1 2 0 Cash Money Market Funds
1 2 1 Cash Money Market Funds
Taxable
1 2 2 Cash Money Market Funds
Tax-Exempt
2 0 0 Munis
2 1 0 Munis Tax-Exempt
2 2 0 Munis Taxable
2 3 0 Munis Zero-Coupon
3 0 0 Dom. FI
3 1 0 Dom. FI US Savings Bonds
3 2 0 Dom. FI Treasuries
3 2 1 Dom. FI Treasuries
Bills
3 2 2 Dom. FI Treasuries
Notes
3 2 3 Dom. FI Treasuries
Bonds
3 3 0 Dom. FI US Gov't Zero
Coupon Bonds
3 3 1 Dom. FI US Gov't Zero
Treasury Strips
Coupon Bonds
3 3 2 Dom. FI US Gov't Zero
Other Zero Coupons
Coupon Bonds
3 4 0 Dom. FI Federal Agency Debt
3 5 0 Dom. FI Mortgage-Backed
Securities
3 5 1 Dom. FI Mortgage-Backed
GNMA
Securities
3 5 2 Dom. FI Mortgage-Backed
FNMA
Securities
3 5 3 Dom. FI Mortgage-Backed
FHLMC
Securities
3 5 4 Dom. FI Mortgage-Backed
Other Issuers
Securities
3 6 0 Dom. FI CMOs
3 7 0 Dom. FI Asset-Backed
Securities
3 8 0 Dom. FI CDs
3 9 0 Dom. FI Corporates
3 9 1 Dom. FI Corporates
Commercial Paper
3 9 2 Dom. FI Corporates
Notes & Bonds
3 9 3 Dom. FI Corporates
Zero Coupons
3 9 4 Dom. FI Corporates
Convertibles
3 9 5 Dom. FI Corporates
Type Not Specified
4 0 0 Dom. Equity
4 1 0 Dom. Equity
Preferred Stock
4 1 1 Dom. Equity
Preferred Stock
Regular
4 1 2 Dom. Equity
Preferred Stock
Convertible
4 2 0 Dom. Equity
Common Stock
4 2 1 Dom. Equity
Common Stock
NYSE/AMEX
Exchanges
4 2 2 Dom. Equity
Common Stock
NASDAQ-Listed
4 2 3 Dom. Equity
Common Stock
Regional Exchanges
4 2 4 Dom. Equity
Common Stock
OTC & NQB
4 2 5 Dom. Equity
Common Stock
Canadian Exchanges
4 2 6 Dom. Equity
Common Stock
Exchange Not
Specified
4 3 0 Dom. Equity
Other Equities
4 3 1 Dom. Equity
Other Equities
Warrants
4 3 2 Dom. Equity
Other Equities
Units
4 3 3 Dom. Equity
Otber Equities
Rights
4 3 4 Dom. Equity
Other Equities
Scrip
4 3 5 Dom. Equity
Other Equities
Other
5 0 0 O/E Funds
5 1 0 O/E Funds
Debt-Oriented
5 2 0 O/E Funds
Equity-Oriented
6 0 0 C/E Funds &
Trusts
6 1 0 C/E Funds &
Closed-End Mutual
Trusts Funds
6 1 1 C/E Funds &
Closed-End Mutual
Debt-Oriented
Trusts Funds
6 1 2 C/E Funds &
Closed-End Mutual
Equity-Oriented
Trusts Funds
6 2 0 C/E Funds &
UITs B11
Trusts
6 2 1 C/E Funds &
UITs Debt
Trusts
6 2 2 C/E Funds &
UITs Equity
Trusts
6 3 0 C/E Funds &
REITs
Trusts
6 4 0 C/E Funds &
Other
Trusts Funds/Trusts/MLPs
7 0 0 Foreign
7 1 0 Foreign Foreign Debt Issues
7 1 1 Foreign Foreign Debt Issues
US Exchanges
7 1 2 Foreign Foreign Debt Issues
Canadian Exchanges
7 1 3 Foreign Foreign Debt Issues
Exchange Not
Specified
7 2 0 Foreign Foreign Equity Issues
7 2 1 Foreign Foreign Equity Issues
ADRs
7 2 2 Foreign Foreign Equity Issues
US Exchanges (Non-
ADRs)
7 2 3 Foreign Foreign Equity Issues
Canadian Exchanges
7 2 4 Foreign Foreign Equity Issues
Exchange Not
Specified
7 3 0 Foreign Off-Shore
Funds/Trusts
7 4 0 Foreign Other Foreign
Securities
7 4 1 Foreign Other Foreign
Private Placements
Securities
7 4 2 Foreign Other Foreign
Options/Futures
Securities
7 4 3 Foreign Other Foreign
Other
Securities
8 0 0 Other
8 1 0 Other Private Limited
Partnership
8 2 0 Other Private Placements
8 3 0 Other Options (on)
8 3 1 Other Options (on)
Equity Issues
8 3 2 Other Options (on)
Debt Issues
8 3 3 Other Options (on)
Interest Rates
8 3 4 Other Options (on)
Indices
8 3 5 Other Options (on)
Commodities
8 3 6 Other Options (on)
Currencies
8 4 0 Other Futures
8 4 1 Other Futures Regular
8 4 2 Other Futures Managed Funds
8 5 0 Other Precious Metals
8 6 0 Other Physical
Commodities
8 7 0 Other Other
8 8 0 Other Unclassified Assets
M M M Margin Balances
__________________________________________________________________________
3. Description of the System Implementation FIG. 5 illustrates the main procedure 500 for classifying investment products. The system is preferably implemented on a computer system as a series of process steps. After the raw position text file from a financial institution has been processed into position database 302 in step 502, position database 302 is summarized in step 504. The summarization process comprises the steps of identifying unique combinations of ZIP code, account, CUSIP number information in the position database 302 from the internal codes provided by the financial institutions. As would be recognized by one of skill in the relevant art, the provider and nature of the data processed by the present invention is implementation and application specific. The present invention is equally applicable to position data from other sources as well as to other types of financial data. After the unique combinations of information in position database 302 are identified, new summary position databases 308, 310 are created that include a record for each unique combination of information stored in position database 302. Position database 302 can be summarized on multiple combinations of fields resulting in multiple summary position databases 308, 310. By creating a summary database, the information in position database 302 can be verified against known valid combinations of fund, account, product and asset codes. As described above, the summarization step facilitates cross-referencing and ensures that information in position database 302 is valid. The summarization process could also be applied to record-level files containing elements such as the number of accounts, transactions, trades, revenue credits or any other financial data which can be associated with a specific CUSIP number. The main procedure 500 includes seven high level steps that process the financial institution's data into a final form for analysis. Step 502 opens the raw position text file and processes it into position database 302. The raw position text file is provided by a financial institution and contains investment position information. A position corresponds to an individual holding of a single investment product. For example, an individual holding 50 shares of a particular issue of stock would constitute a position. Position information could include for example; ZIP code, customer type (e.g., individuals, trustees, etc.), customer gender, customer age, account type (regular taxable, IRA, etc.), account date, shares owned, asset value, and other position related information. The raw position text file is processed into a position database with each record corresponding to an individual position at step 502. After position database 302 has been summarized in step 504, the information in position database 302 is verified at step 506. The verification step 506 is performed to test the validity of the position data and to identify new field combinations in position database 302. By cross-referencing summary position database(s) 304, 306 with known valid combinations of fund, account, product and asset information, errant data and new combinations can be identified. Cross reference step 506 ensures the integrity of the data in the position database 302. Errant records (containing erroneous information) are removed and records containing new unique combinations of information are identified and added to the cross-reference database at step 506. Step 508 of main procedure 500 recodes CUSIP classification file 104 with standard fund, product and asset bucket codes. As noted above, S&P assigns a unique CUSIP number for every issue. IDC compiles a database of all valid CUSIP numbers and prospectus information associated with each security. CUSIP classification file 104 is recoded with standard fund, product and asset bucket codes at step 508. Prior to the recoding of CUSIP classification file 104, the prospectus information is contained in many different fields, each of which may contain numerous different values. The many permutations of the prospectus information fields makes analysis of the prospectus information difficult. The recoding, therefore, is used to identify a manageable number of product, asset and fund types for analysis. After recoding step 508, CUSIP classification file 104 contains a fixed number of known standard bucket codes. After the information in position database 302 has been verified in step 506, step 510 recodes position database 302 with standard product, fund and asset bucket codes from the recoded CUSIP classification file 104 from step 508. Step 510 maps the recoded CUSIP classification file 104 to position database 302, keyed on CUSIP number. The product, fund and asset bucket codes in the CUSIP classification file 104 are then copied into position database 302 for corresponding CUSIP numbers. After position database 302 has been recoded with the bucket codes, it is possible to analyze position database 302 based on the bucket codes. After position database 302 has been recoded with the buckets in step 510, position database 302 is compressed in step 512. The compression process summarizes multiple records in position database 302 into single records based on desired analysis fields. The summarization process results in a summary position database 406 with each record containing a unique combination of the fields specified for analysis purposes. The preferred embodiment employs summarization on the product, fund and asset buckets combined with ZIP code. The summary position database 406 is usually smaller than position database 302. After position database 302 has been compressed in step 512, step 514 creates a aggregate position database. Steps 502-512 have generated a summary position database 406 for an individual financial institution. Position database 302 for that financial institution has been processed in a standardized form. The standardized form allows the summary position database 406 to be combined with summary position databases from other financial institutions. This enables analysis of multiple financial institutions' position information at the same time. By combining the standardized and recoded position databases from a plurality of financial institutions, an aggregate position database file is created at step 514. The aggregate position database represents the records of a plurality of financial institutions whose position text files have been processed in steps 502-512. The aggregate file created in step 514 can represent the entire financial product marketplace, allowing analysis of market-wide financial information. In an alternative embodiment, a particular subset of the market can be represented by aggregating a subset of the position databases into aggregate position database. FIG. 6 further illustrates the process of converting the raw position text file into position database 302 of step 502. Data describing the structure of the raw position text file is read from a lookup file in step 602. The data read in step 602 contains, for example, how the raw position text file is delimited, how many fields are contained in the raw position text file, the nature of the data contained in the raw position text file (i.e., character or numeric), the length of the information contained in the raw position text file, etc. This step ensures correct alignment of the information from the raw position text file with the fields of position database 302 that is to be created. Next, a position database structure is created in step 604 based on the data read in step 602. The raw position information is then appended from the raw position text file into position database 302 in step 606. Position database 302 created in step 606 is then checked for valid account numbers at step 608. If it is determined at step 608 that not all records in position database 302 contain account numbers, an account number for each record lacking one is created in step 610. If all the records in position database 302 have account numbers (or have new account numbers from step 610), then the process returns to the main procedure 500 at step 612. FIG. 7 further illustrates summarizing position database 302, step 504. After position database 302 has been created in step 502, position database 302 is summarized at step 504. The summarization process has been described in more detail in conjunction with FIG. 3, above. First, position database 302 is opened at step 702. The process then determines the fields to be summarized at step 704. The summary fields could include any information which lends itself to verification such as account type, product type, ZIP code, etc. Based on the fields determined in step 704, new summary position databases 304, 306 are created in step 706. Unique combinations of the fields determined in step 704 are copied into new summary position databases 304, 306 at step 706. After the summary position databases 304, 306 have been created at step 706, the process returns to main procedure 500 at step 708. If multiple fields or field combinations are to be verified, position database 302 can be summarized on different fields and field combinations, resulting in multiple summary position databases 304, 306 at step 504. These multiple summary position databases 304, 306 would then be verified against multiple cross-reference databases 308, 310 for verification. For example, position database 302 could be summarized on ZIP code, to ensure no invalid ZIP codes are contained in position database 302 that would cause analysis errors later. Likewise, the product and other codes can be verified independently using multiple summary and cross-reference files. For the purposes of explanation, however, the number and combination of the fields that are verified have been limited. FIG. 8 is a more detailed illustration of the data verification process, step 506. First, both the summary position and cross-reference databases 308, 310 are opened at step 802 and 804. Cross reference databases 308, 310 contain known valid combinations of fields to be compared with the field combinations in summary position database 304, 306. The two databases are compared at step 806. The comparison is then used to identify valid, new, and errant field combinations at step 808. The process returns to the main procedure 500 flow at step 810. FIG. 9 illustrates a more detailed view of verifying the field combinations in summary position database 304, 306, steps 806 and 808. Summary position database 304, 306 is selected in step 902. Cross-reference database 308, 310 is then searched for the combination of fields contained at the first record in Summary position database 304, 306 at step 904. If the field combination from the summary position database 304, 306 exists in the cross-reference database, then the field combination is determined to be a known valid combination at step 906. The process then continues to step 916 to determine whether the end of the summary position database 304, 306 has been reached. If the process has reached the end of summary position database 304, 306, then it is known that the cross-reference database now contains a complete, verified list of field combinations at step 918. If, on the other hand, it is determined that the end of summary position database 304, 306 has not been reached at step 916, then the next record in summary position database 304, 306 is selected at step 914 and the process continues in a loop to step 904. At step 906, if the summary position database field combination does not exist in the cross-reference database, then the process determines if the field combination is valid at step 908. If the field combination is not valid, then the errant data in summary position database 304, 306 is flagged and removed from summary position database 304, 306 at step 910. If, on the other hand, the field combination is deemed to be valid at step 908, then a new field combination is created in the cross-reference database at step 912. The process then determines whether the end of file has been reached at step 916. After the end of summary position database 304, 306 has been reached at step 916, the process returns to the main procedure 500 at step 920. FIG. 10 further illustrates the recoding of the CUSIP classification file 104 step 508. The recoding of CUSIP classification file 104 can be completed anytime in the process before position database 302 is recoded at step 510. The recoding of CUSIP classification file 104 begins at step 1002, where the fund bucket codes are copied into the CUSIP classification file 104. After CUSIP classification file 104 has been recoded with fund bucket codes, CUSIP classification file 104 is recoded with the product bucket codes in step 1004. After CUSIP classification file 104 has been recoded with both the fund bucket codes at step 1002 and the product bucket codes at step 1004, CUSIP classification file 104 is recoded with the asset bucket codes at step 406. The asset bucket codes are determined based on the combination of fund and product bucket codes in each record of CUSIP classification file 104. It is necessary, therefore, that the asset bucket codes be determined at step 406 after steps 402 and 404. After the completion of step 406, the process returns to the main procedure 500 at step 408. FIG. 11 further illustrates how CUSIP classification file 104 is recoded with the Lipper Analytical Services' information at step 402. The CUSIP and Lipper database files are opened at step 1102. After the CUSIP and Lipper files have been opened, the Lipper database is related (mapped) into CUSIP classification file 104 based on CUSIP number, and the Lipper Investment Objectives from the Lipper database 102 are copied into CUSIP classification file 104 at step 1104. CUSIP classification file 104 is then mapped to bucket database 202 keyed on Lipper Investment Objectives. Bucket database 202 contains bucket codes defining fund, product and asset buckets, and the Lipper Investment Objectives to which they correspond. The fund bucket codes are then copied from bucket database 202 into CUSIP classification file 104 at step 1106, matching on Lipper Investment Objectives. The process returns to process 506 at step 1108. FIG. 12 illustrates recoding of product type information in CUSIP classification file 104 at step 1004 in more detail. Bucket database 202 and CUSIP classification file 104 are opened at step 1202. Bucket database 202 contains bucket codes defining fund, product and asset buckets, and the IDC prospectus codes to which they correspond. Bucket database 202 is mapped into CUSIP classification file 104 based on IDC prospectus codes. The product bucket codes from the bucket database 202 are then copied into CUSIP classification file 104, record by record, for matching combinations of IDC prospectus codes at step 1204. FIG. 13 is a more detailed illustration of recoding CUSIP classification file 104 with asset bucket codes of step 1008. Bucket database 202 is opened and mapped into CUSIP classification file 104 based on matching combinations of fund and product bucket codes at step 1302. The asset bucket codes are then copied from bucket database 202 into CUSIP classification file 104 for matching combinations of fund and product buckets at step 1304. After the asset bucket codes of CUSIP database 202 have been recoded, the process returns to the main procedure 500 at step 510. FIG. 14 is a more detailed illustration of recoding the position database 302, step 510. First position database 302 and CUSIP classification file 104 are selected. CUSIP classification file 104 and position database 302 are mapped based on CUSIP number at step 1404. Next, the fund, product and asset bucket codes are copied from CUSIP classification file 104 into position database 302. After the fund, product and asset buckets have been assigned to each investment product of position database 302, the process returns to the main procedure 500 at step 512. FIG. 15 further illustrates the compression of position database 302 at step 512. Recoded position database 302 is selected at step 1502. The process of step 512 is very similar to the process of step 504, where the summary position database 304, 306 is created. The process then summarizes recoded position database 302 on the fund, product, and asset buckets combined with ZIP code and totaling the number of records and investment amounts for each unique combination. As stated above, the summarization process results in a summary database that contains all of the unique combinations of the fields specified for the summarization process. The summary will allow analysis based on the summary fields. It should be recognized, however, that since the summary fields are determined by the analysis procedure, the selection of more, fewer or different fields to summarize is encompassed by this invention. After the summarization process, step 512, position database 406 has been put in standardized form. The standardized summary position database 406 will then be combined with standardized position databases from other financial institutions to produce a aggregate file that provides a more complete view of the financial position marketplace. After the summarization process at step 1504, the process then returns to main procedure 500 at step 1506. FIG. 16 is a more detailed illustration of creating the aggregate file at step 514. The aggregate file is a compilation file of a plurality of summarized position databases 406 that have been processed. For example, multiple financial institutions produce multiple raw position text files. These position databases are processed by steps 502-512 and then combined into a aggregate file. The procedure to create the aggregate file begins with opening the aggregate file at step 1602. After step 1602, it is determined whether there are new, final summarized position databases 406 to be added to the aggregate file at step 1604. If there are no additional summarized position databases 406 to be added, the aggregate file is closed at step 1606. If, on the other hand, there are additional summarized position databases 406 to be added to the aggregate file, the new summarized position file 406 is opened at step 1608. The records of the new summarized position file 406 are then merged with the aggregate file at step 1610. Merging the newly created summarized position file 406 with the aggregate file is accomplished by appending the records of the summarized position file 406 to the aggregate file, so that the aggregate file contains all of the different financial institutions' position information. The process then continues to step 1604, where it is determined whether additional summarized position files exist to be added to the aggregate file. This process continues until there are no additional summarized position files to be added to the aggregate file, in which case the aggregate file is complete. 4. System Configuration The chosen embodiment of the present invention is computer software executing within a computer system. FIG. 17 shows an exemplary computer system. The computer system 1702 includes one or more processors, such as a processor 1704. The processor 1704 is connected to a communication bus 1706. The computer system 1702 also includes a main memory 1708, preferably random access memory (RAM), and a secondary memory 1710. The secondary memory 1710 includes, for example, a hard disk drive 1712 and/or a removable storage drive 1714, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as EPROM, or PROM), etc. which is read and written to by a removable storage unit 1716. Removable storage unit 1716, also called a program storage device or a computer program product, represents a floppy disk, magnetic tape, compact disk, etc. As will be appreciated, the removable storage unit 1716 includes a computer usable storage medium having stored therein computer software and/or data. The removable storage drive 1714 reads from and/or writes to a removable storage unit 1716 in a well-known manner. The computer system 1702 may also include other similar means for allowing computer programs or other instructions to be loaded. Such means can include, for example, a communications interface 1718. Communications interface 1718 allows software and data to be transferred between computer system 1702 and external devices. Examples of communications interface 1718 can include a modem, a network interface (such as an Ethernet card), a communications port, etc. Software and data transferred via communications interface 1718 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 1718. In this document, the term "computer program product" is used to generally refer to removable storage unit 1716, a hard disk installed in hard disk drive 1712, and signals transferred via communications interface 1718. These computer program products are means for providing software to a computer system 1702. In an embodiment where the invention is implemented using software, the software may be stored in main memory 1708, or in a computer program product and loaded into computer system 1702 using removable storage drive 1714, hard disk drive 1712, or communications interface 1718. The software, when executed by the processor 1704, causes the processor 1704 to perform the functions of the invention as described herein. In another embodiment, the invention is implemented primarily in hardware using, for example, a hardware state machine. Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant arts. The best mode of the present invention is directed to a computer system 1702 comprising a personal computer. More specifically, the personal computer includes, in the preferred embodiment, a Pentium processor with 66 or 90 MHZ, executing Windows NT, or a Gateway 2000 Pentium processor with 133 MHZ, executing Windows 95. Furthermore, the preferred embodiment includes a personal computer having 4 gigabytes (GB) of memory with 32 megabytes (MB) of RAM. It should be understood, however, that the invention is not limited to this embodiment. Instead, the invention is described with reference to these computer systems for convenience purpose only. Other computer systems could alternatively be used. Additionally, the preferred embodiment is directed to the present invention being implemented in software. Preferably, Microsoft Visual FoxPro, version 3.0, and Delphi execute on the chosen computer system. It should be understood that the invention is described with reference to Visual FoxPro and Delphi for convenience purpose only. Other software packages could alternatively be used. 5. Analysis of Resultant Data After the position databases have been recoded, summarized and collected into the aggregate file, the aggregate file can be analyzed. The product, asset and fund bucket codes in conjunction with ZIP code, and other position information can be analyzed by any of a number of data analysis tools currently available. In the preferred embodiment, GeoFrame is a software package designed specifically to exploit the data that is produced in the recoding process. GeoFrame was developed in the Delphi programming language with a Borland Database search engine. One of skill in the relevant art, however, will recognize that there are many database and geographic analysis tools available to analyze and manipulate the product of the present invention. FIG. 18 is an example of geographic analysis and display of the position information. There are two primary interfaces in the analysis and graphical display tool of the preferred embodiment. The first interface is the geographical area selection interface. The user may select a specific geographical area for data analysis. This geographical area can include groups of individual ZIP codes, counties, states, metroplexes, Metropolitan Statistical Areas (MSAs) and Designated Market Areas (DMAs). MSAs and DMAs are market areas provided by the U.S. Census Bureau and A. C. Nielsen & Company, respectively. Metroplexes are collections of one or more counties that define a greater metropolitan area, or market. The selection of geographic region and the geographic selection interface selects the subset of position data in the aggregate file that corresponds to the geographic area selected. The second interface allows analysis of the data that has been selected in the geographic selection interface. Through the second interface, the user can specify the investment product buckets and types of analysis to be performed on the information selected in the geographical interface. FIG. 18 is a graphical representation of how the recoded data in the position database may be analyzed. Map 1802 represents the Houston, Tex. metroplex area by ZIP code. A metroplex is a geographical area comprising one or more counties which, as a set, generally have a minimum population of 100,000 households. The metroplex unit is a construct used to represent greater metropolitan areas for the purposes of investment product data analysis. As can be readily understood, any geographical unit may be used to analyze the investment product position information. Map 1802 is divided into smaller geographic areas which represent individual ZIP codes in the Houston metroplex area. In the metroplex area of Map 1802, the ZIP code areas are given different shadings corresponding to the amount of assets in the metroplex area. Each area is given a darker shading to represent the greater share of the total investment product assets for the metroplex area. A lighter shading indicates that the ZIP code area contains a smaller share of the assets in the metroplex area. Table 1806 describes the quantitative relationship between the shading in map 1802 and the assets in each of the ZIP codes. For example, unshaded areas to very lightly shaded areas represent minimum assets of 0 to 2.2 million dollars per ZIP code. FIG. 19 illustrates the analysis of a financial institution's relative share of the Houston metroplex open-end mutual fund market by different investment product buckets. The analysis is performed on the investment product buckets at a very high level resulting in only seven different fund types. The different investment product types are embodied by each different fund type illustrated as a fund type list 1902. For the purposes of the company share report (or relative market share), the percentages of total assets for the particular company with respect to the total investment product market can be compared. The position database is separated into the two primary categories of all firms and the particular financial institution for which the analysis is being performed. The top bar of each pair of bars embodied as element 1904 of FIG. 19 represents the percentage of total assets the clients of a particular financial institution hold in a particular fund type. For example, the clients of the financial institution of FIG. 19 holds approximately 42% of their total assets in Money Market Funds. The lower bar of each set of bars represents the percentage of total assets all firms hold in a particular fund type. For example, the total market of FIG. 19 holds approximately 32% of its total assets in Money Market Funds. Comparison of the two top bars representing the percentage of total assets in Money Market Funds shows that the clients of the particular financial institution in question hold an above average share of Money Market Funds for the particular market. The company share by fund types report of FIG. 19 identifies which product types are popular in a particular geographic area. By comparing the percent of total asset distribution in the company share report, a financial institution can determine particular investment products which are favored or unfavored in the particular geographical area. FIGS. 20-24 illustrate a report of all financial position information for the Houston metroplex area. Balances are determined for each individual ZIP code and displayed in decreasing order. The report of FIGS. 20-24 compares the investment products sold by all firms to the investment products sold by the financial institution for whom the report is being run. This enables the financial institution to determine its market share in each individual ZIP code of the Houston metroplex area. For example, the 77024 ZIP code of Houston, Tex. has a total financial position balance of $2.708 billion dollars. The particular financial institution for whom the report is being run, has sold $166.3 million dollars of investment products in the 77024 ZIP code, constituting a 6.14 percent relative market share. The last three columns of data, in FIGS. 20-24, represent the percentages of investment product assets that each ZIP code represents. Conclusion While various embodiments of the present invention have been described above, it should be understood that they have been presented by the way of example only, and not limitation. If it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
|
Same subclass Same class Consider this |
||||||||||
