CN1353842A - Portfolio investment guideline compliance and financial fund administration system - Google Patents

Abstract

A system (1) for portfolio compliance and administration receives data concerning financial instruments that comprise a financial fund from a collection of information sources. Tests are designed and applied to the financial data to confirm that the fund is being managed in accordance with predetermined rules. The user may correct or update the financial data but this history of changes is recorded, allowing a complete audit. The financial data (or any reports based thereon) can be provided to the user in a number of formats (711, 712), such as on a computer display, in a printout or over a global computer network, such as the worldwide web. The user is notified automatically by urgent means when certain test results are obtained by the system. The fund may be tested for compliance with the fund rules (7), tax reports (8) may be created and a complete audit trail developed without importing the same data numerous times.

Description

Portfolio investment guideline compliance and financial fund management system

field of invention

The invention relates to the field of financial fund management, such as mutual funds and pension funds. In particular, the invention relates to a system for performing investment guideline compliance tests and periodic reporting such as tax reporting etc. for such financial funds.

Background technique

Financial funds (also known as investment vehicles) consist of a collection of various financial securities managed by a fund manager. Investment vehicles can include mutual funds, unit trusts, pension schemes, etc. Fund participants invest themselves in investment instruments that provide cash for the purchase of financial securities. Fund managers make decisions about the sale and purchase (or "trade") of different financial securities in an attempt to optimize the value of the fund, that is to say the return on investment for investors. However, the fund adheres to certain rules to protect investors, namely to limit the types of transactions that the fund manager may make and/or to set parameters regarding the weighting of securities in the portfolio. These rules can be imposed externally through market-related regulations promulgated by governmental entities such as the Securities and Exchange Commission or the Internal Revenue Service. Other rules may be imposed internally by the investment vehicle sponsor's investment committee. Typically, these rules are published in the fund's prospectus, including instructions to investors about the fund's structure and management. Centrally speaking, these rules are called investment or compliance guidelines. Ensuring compliance with these different rules can be difficult due to the large number of financial securities that form funds, and the dynamic nature of financial securities themselves. This means that compliance must be tested and reported on a regular basis (eg, daily) to keep pace with changing portfolio structures and changing portfolio and security values.

Typically, the management of financial funds is handled by financial institutions such as banks. The fund manager, the "client" of the financial institution will make a series of transactions for a particular fund. These transactions are reported to the financial institution for resolution. This resolution function is carried out by the "supervision" department of the financial institution. The institution may also maintain books or records within its "accounting" department for the fund. In addition, financial institutions may also perform transaction bookkeeping, calculation of the value held by specific fund owners, portfolio values, returns on fund investments and guideline compliance, that is, within its "compliance" department, check the fund's compliance with various Compliance with applicable investment guidelines. Currently, investment guideline compliance is determined using manual or semi-manual processes by compliance analysts or specialized compliance services teams.

The rules that form the guideline compliance test can take many forms. The Compliance Services Group establishes a checklist of these limits and reviews transaction and account holdings against investment parameters on a periodic basis (daily, weekly or monthly, as per legal, market or client needs). Such labor-intensive manual compliance testing is time-consuming and prone to human error, and therefore requires a rigorously implemented control process. Also, compliance testing is typically performed only for a given point in time, rather than for the entire time or period. Fund managers may also wish to consider what the effect of reminding the fund of the rules is on the performance of the fund. This can be expensive when performed manually.

Fund rules may limit the amount of investment in securities from a selected country or in a particular industry. Such fund rules may require holding no more than 5% of the fund's NAV in Japanese securities. The compliance analyst (that is, the person responsible for checking the fund's compliance with the fund's guidelines) then needs to classify the holdings of the portfolio by risky countries and calculate the percentage value of the Japanese holdings relative to the NAV. Typically, the compliance analyst will take the printed accounting reports, look up the "country at risk" for each holding on a computer terminal and create a computer spreadsheet to do the above calculations. Any "exceptions" (ie possible violations of the rules) are manually noted on a checklist and reported to the customer according to the escalation steps established in the customer-customized service level agreement. These calculations must be performed even when there are no transactions in financial securities for a given fund, because the value of a given security can vary relative to the remainder of the fund, giving it a greater or lesser NAV. A record of all customer communications regarding exceptions is maintained manually. All documentation pertaining to compliance enforcement, exception escalation, and violation disarmament is stored in hard copy.

It is generally believed that compliance testing for different types of funds (such as mutual aid funds to pension funds) requires very different types of analysis. However, globally there is a high level of commonality of product attributes. For example, all objects are based on prudent investor principles, require different industries, geography and asset types, limited open derivatives and lower quality investments, etc. Therefore, it is advantageous to have a system that can handle these different funds.

In the management of financial funds, it is often critical to produce reports that accurately and fully describe the performance of the fund beyond regulatory compliance testing. For example, certain information may need to be gathered to determine the taxability of a fund to support it during a particular period. Traditionally, this has been performed manually by analysts reviewing large volumes of financial information and calculating the required numbers. Clearly, this is a labor-intensive task that requires a significant amount of time from highly skilled personnel. Additionally, due to the manual nature of the task, there is a potential for human error.

As part of the compliance testing process, reports are generated indicating violations of specific rules. This report is not interactive and does not allow the compliance analyst to "drill down" to determine the specific nature of the violation, the precise definition of the rule or whether the violation has been eliminated due to later posted transactions.

There is therefore a long-felt need for a system that can receive data about a financial fund, adjust that data based on long-term changes in circumstances (internal or external to the fund), and provide reports as required by users, that is sufficiently flexible To accommodate information from a set of information sources, while allowing the user to define the output to a large extent and allow the user to utilize the specific basis of the report.

Summary of the invention

One aspect of the present invention provides a system for portfolio compliance and management that receives data from a collection of information sources regarding financial securities comprising a financial fund. This financial data is recorded and maintained. The system allows the user the flexibility to define the financial data required for a given fund. Various tests can be designed by the user and applied to financial data to verify that the fund is managed according to predetermined rules. While the system provides the user with the ability to correct or update financial data, recording a history of this change allows for a full audit at a later date. This financial data (or any reports based on it) can be provided to users in some useful form, such as displayed on a computer, printed or published on a global computer network such as the World Wide Web. If desired, eg compliance analysts or fund managers can automatically notify users via more urgent equipment (such as pagers, etc.) when certain financial data is received by the system. Preferably, this single integrated system allows a fund to be tested for compliance with fund rules, generate tax reports and establish a full audit trail without having to enter the same data multiple times.

In one embodiment, the present invention relates to an integrated compliance and management system that provides a unique combination of compliance, tax and financial reporting functions to serve the needs of global investment vehicles including, but not limited to, US mutual funds, US and Global Pensions, European UCITS (Union of Pooled Investments in Transferable Securities) and OEICS (Open-End Investment Companies), US and European insurance companies and Australian retirement pension schemes. The system inputs and stores holding data, transaction data, tax share data, general ledger data, prices, foreign exchange rates, and asset description data. This level of detail allows for compliance testing and tax and financial reporting at the lowest level of portfolio information. Each field is stored with a date and time stamp.

It is an advantage of one aspect of the present invention to provide a system which records detailed transaction data and the time and date the transaction was recorded in the system. This complete information allows analysis of financial funds based on more than one end-of-day holding information. In particular, transactions affecting a fund can be reviewed individually (and at the holding level) to verify that the fund is complying with its governing rules at any given time. In addition, the system provides for recording any changes made to the financial data by a particular user. The identity of the user making the modification to the financial data (or other aspects of the system) can be readily determined should the need be deemed at any time.

An advantage of one aspect of the present invention is to provide a system and method for performing compliance testing of a portfolio of funds. The system of the present invention receives financial data from different data sources, organizes the data, and applies compliance testing to the financial data. If there is a possible breach of compliance testing, an alert can be sent immediately to compliance analysts and fund managers within the financial institution (if so desired). Additionally, a basic warning signal can be transmitted if the fund crosses a threshold approaching a possible breach. The system allows data to be reported and recorded in various formats, providing a more complete understanding of a fund's compliance and performance. Additionally, the results of the compliance testing can be reported to the fund manager (or compliance analyst) via a global computer network, such as the Internet or the World Wide Web. The system can be configured to require the analyst to record the resolution of a possible violation (or defer recording until a later time), thereby providing a record of the actions taken. The system does not require highly skilled analysts to check the compliance of any given portfolio. The improved portfolio-to-headcount ratios resulting from the system (and the support functions placed at the center around the technology associated with the system) in turn result in more efficient and accurate compliance reporting. Because the system does not require highly skilled personnel to spend a considerable amount of time performing laborious arithmetic operations, they are thus freed up for more in-depth analysis.

One aspect of the present invention automates current manual processes, reducing actual and potential errors and their corresponding impact. However, the system also provides additional customization capabilities to account for the needs of fund managers. The system can interoperate with other electronic fund information systems to provide a single integrated platform to meet customer and specific geographic needs. Centralization of system and processing support functions reduces overhead as more users use the system. This robust single integrated platform supporting investment guideline compliance allows financial institutions to economically serve as business record holders for investment fund managers.

According to another aspect of the present invention, the system of the present invention uses a flexible rule building engine to meet the nuances of the global market. Provides data integration and control features to ensure consistent results on quality-controlled data. The system generates an on-line audit trail to track violations and/or warnings, as well as progress and/or termination of releases. The system also allows scheduling of data entry, execution of tests and batch reporting. If a violation is detected, or a condition requiring warning, an alert or warning can be automatically triggered by the system to the client (eg fund manager) via pager, email or fax. The system allows flexible customization of reports. These reports can be provided to customers by e-mail, fax or World Wide Web site.

System administrators, combined with compliance analysts, are responsible for establishing user accounts and the access rights associated with those accounts. Thus, according to one aspect of the invention, the system facilitates access control management. Compliance analysts or other users within the financial institution can be granted "read-only" or "read/write" access by the system, ensuring the integrity of the data on the system. For example, only a group of data stewards can change data item values, and individuals within that group have different priorities depending on whether they have supervisory and other roles. Access can be limited by funds, clients or other parameters, as will be readily understood by those skilled in the art. For example, while a senior compliance analyst may have access to the entire business ledger (consisting of multiple funds) for monitoring purposes, the compliance analyst may only have access to specific clients.

According to other aspects of the invention, various safeguards are integrated throughout the system to aid in smooth operation. Early notification may be provided to compliance analysts, system administrators and compliance fund administrators if certain difficulties arise in system functionality. If the system is unavailable on a business day due to a technical matter, there is procedural action to reach out to the senior compliance administrators by phone to keep them up to date on the progress. The task scheduler runs the compliance tests with the frequency and timing required by the business user. Set up an event-triggered upgrade scheduler on the system's task scheduler side. For example, in a typical application, if data entry fails, the system attempts to retry at 5 minute intervals for 15 minutes, and thereafter notifies the system administrator (or other party) via pager, email, etc. This process is designed so that any events that occurred the previous night are undone by the time service start. Obviously, time intervals, event triggers and contacted parties may vary according to the particular application.

According to another aspect of the present invention, data consistency of fund-level data, such as holdings, assets, etc., is performed daily to ensure synchronization with the source bookkeeping system. The system receives automatic feeds of transactions, holdings, tax shares, general ledger information, and certain asset descriptive data from the financial institution's core systems such as internal bookkeeping systems. The system database is supplemented by additional automated supply of asset descriptive data from external data vendors. Automated data population is further supplemented by manual review of alternate vendor screens or publications. As a result, the data set from which a compliance test or fund report is generated is sufficient to fully warrant the need for accuracy and thoroughness.

According to another aspect of the invention, the system allows for highly flexible data management, while recording modifications to the data, allowing for later auditing. For example, an authorized data analyst within the data management group may enter or modify data for specific funds in those areas defined by different clients, such as industry classifications, liquidity, etc., for the same asset. Preferably all asset description data used by the system comes from a central data source within the financial institution. The Data Management Group, using tools programmed into the system, acts as the quality assurance overseer for the asset specification data for all users of the application. The group also supports minimizing the risk of errors through the approval process.

The system divides data sources into items. Fields that are essential for performing compliance testing are designated as "required" (eg, personal insurance prices). Required fields may be categorized as "sourced reliable" and imported from internal financial institution sources. These fields cannot be modified on the system. They can only be modified for the source system by request of the data owner. Amendment requests require appropriate supporting documentation to ensure data quality control. Any modification is "date and time stamped", that is, the system saves the previous value and records the modification, including who modified it and when it was modified. This complete record of the modification allows subsequent analysis to understand the modification and its effects, as well as perform any necessary tracing of who made the modification. Required fields must be "confirmed" by the data steward, validating the value against an alternate data source, double-clicking the Validate button informs the database that the field value is good. The input of data or instructions is more intuitive in the graphical user interface provided by the system, and the fields are color-coded on the screen and separated on the database to reflect their different states. The system allows compliance to be enforced only if all required fields are validated for an asset (all field values manually reviewed and validated).

According to another aspect of the invention, the system includes a dynamic compliance rule building engine that ensures the flexibility required to service an integrated product. Data pertaining to a particular financial institution, such as stock numbers, credit ratings, market prices of stocks, classifications of financial securities for that particular fund, etc., provide the building blocks to transform investment guidelines into system logic, allowing computer Perform compliance testing. The rules governing a fund are translated into logical statements linking data items. Group rules together to form tests. "Tests" can be compared to checklists in today's manual environments.

Tests are established at the beginning of each customer relationship by a dedicated group of financial institution-based rule builders. The rule builder works with compliance analysts and customer representatives to interpret the guidelines for each customer, eg what does a particular customer define as "derivatives"? Rule Builders are responsible for creating new rules/tests or cloning and modifying existing rules/tests, verifying the accuracy of fund-specific definitions and assigning approved tests to funds for production purposes. The system logic links fund-specific tests to fund-specific data fed into the system on a per-purpose basis. The system task scheduler runs the compliance tests at the frequency and timing requested by the compliance analyst on behalf of the customer. Of course, the system also allows compliance analysts (and other approved users) to bypass the scheduler to run compliance tests and generate reports immediately upon request (such as periodic reports).

According to yet another aspect of the present invention, results are automatically generated by the system and displayed online by the "Results Tracking" module. Compliance analysts have the ability to annotate those results in detail on-line, thus documenting escalated audit trails and client instructions to report matters and decisions concerning those matters to the client. The system stores and can display online a complete audit trail of the portfolio's compliance history. Preferably, reports are based on Excel? , but other platforms or representations may also be used. Some reports are hardcoded, for example, those used by data management groups as part of their data validation process. Most compliance reports are generated on demand by compliance analysts during test build. Empower compliance analysts with the flexibility to save reports to hard drive and integrate them into the board. All system-generated reports are printed with a system footer. The footer does not appear when the report is "unlocked" to allow modification. This alerts the reader that the report may not have been generated directly by the system, or may have been modified.

The system of the present invention provides the option of "as of" functionality, that is, the ability to load "post-trade" information that does not have an original posting deadline set and have the ability to apply it to the portfolio and then modify it. Option to re-execute compliance for the portfolio to determine what the status of compliance was on that day if the portfolio was "full". This is useful when transaction or other information is received after billing is complete and the billing source system information has been passed to the complying system. This new information could significantly affect the fund's compliance status. A "current" consensus report maintains an audit trail of changes.

The system provides outcome tracking, ie a fully online audit trail of compliance release decisions. The system generates compliance results and prints reports, and compliance analysts can log their actions offline. However, the system gives compliance analysts the ability to continue online tracking of all their actions after reviewing the results by "opening" a record, such as escalating the release to a client, receiving confirmation of an incorrect data value, after a release decision "Close" logging.

Recognizing that data constraints will never allow 100% automation, a small fraction of compliance will continue to be computed offline. The system allows compliance analysts to create "manual" rules by recording the wording of offline rules online. Compliance analysts then check for compliance with this manual rule. The system allows compliance analysts to link a result. Compliance analysts can also use the results tracking feature for these offline rules and keep all customer records in one place.

The system provides online data analysis. A full front-end screen allows compliance analysts to view all data associated with their customers that has been entered into the system. The status (ie pass, warning or fail) of any run test can be provided to the Fund Manager via the global computer network. Additionally, fund managers can be provided with more detailed reporting and the ability to interact with the system if desired. In this case, the system will allow the fund manager to drill down into the details of a report and determine the nature and cause of any breach or simply gain a better understanding of the fund's performance against the rules.

Multi-asset master data sets are stored in a separate database to comprehensively satisfy multi-source bookkeeping systems. This allows general updating of certain asset fields, which are identical on the general ledger system, but separated at the asset owner and even at the customer level, which can have different values at lower levels.

The system provides an integrated scheduler to facilitate scheduling of all system jobs such as data entry, test execution and batch reporting. The task scheduler allows tasks to be scheduled in relation to each other, ie to run data entry from the source system once an indicator is triggered indicating that the source system is ready, and to run compliance tests when the data entry completes successfully. Of course, the system can run tests and generate reports "on demand", that is, in response to an ad hoc request from a system user such as an analyst.

The system preferably includes browser-based reporting and is available on the World Wide Web. Clients (such as fund managers) can access key reports in a hierarchical fashion, "click" on fields of interest, and the system provides additional or more detailed information on specific items of interest. The system provides 6 data fields that identify building blocks for compliance with a rule and a rule approval function to ensure that the rule is properly tested before allowing it into production. The system allows parameters to be changed during runtime.

The system can provide an early warning signal to compliance analysts (or fund managers, if desired) when a fund is close to violating guidelines. In this way, fund managers can take corrective action, if deemed necessary, before a violation actually occurs. The results of any tests performed on the system may be provided electronically, such as by pager, email or fax. The system allows reconciliation between the source accounting system and the system itself. The flexibility of the system allows compliance analysts to define terms and rules for specific funds when requested by clients. For example, certain fields such as industry classification, liquidity, etc. may be defined differently for different funds. The system allows such definitions to be fund-specific. The system also allows compliance analysts to search the database on fund groups. For example clicking on the "Shareholders" button will cause the system to search the database for all "Shareholders" for a particular stock. This is especially useful if a particular company is in crisis and you want to quickly see portfolio openings.

Description of drawings

Additional features of the invention, its nature and various advantages, will become more apparent from the accompanying drawings, in which like reference numbers refer to like elements, and from the following detailed description of the invention, wherein:

Figure 1 schematically shows the flow of information from a fund manager through a financial institution to the system according to the invention.

Figure 2 schematically shows the flow of information from external information service providers and other departments of the financial institution to compliance departments for the system of the present invention to users of the system.

Fig. 3 is a flowchart illustrating logical processing.

4 and 4A are flowcharts illustrating account information processing.

5A-5C are flowcharts illustrating account authorization processing.

6-6A are flowcharts illustrating account status processing.

Fig. 7 is a flowchart illustrating task scheduler processing.

Fig. 8 is a flowchart illustrating task queue processing.

9-9A are flowcharts illustrating asset maintenance processing.

Fig. 10 is a flowchart illustrating fund maintenance processing.

Fig. 11 is a flowchart illustrating fund maintenance processing.

Fig. 12 is a flowchart illustrating fund maintenance processing.

Fig. 13 is a flowchart illustrating fund group maintenance processing.

14-14A are flowcharts illustrating table maintenance processing.

Fig. 15 is a flow chart illustrating the processing of conforming to the engine structure.

Fig. 16 is a flowchart illustrating notification request processing.

Fig. 17 is a flowchart illustrating contact maintenance processing.

Fig. 18 is a flowchart illustrating notification delivery service processing.

Fig. 19 is a flowchart illustrating compliance reporting processing.

Fig. 20 is a flowchart illustrating violation tracking processing.

Fig. 21 is a flowchart illustrating automatic response processing.

Fig. 22 is a flowchart illustrating manual violation establishment processing.

Fig. 23 is a flowchart illustrating violation detail display processing.

FIG. 24 is a flowchart illustrating violation tracking user interface processing.

25-25A are flowcharts illustrating ledger reporting processing.

26-26A are flowcharts illustrating holding reporting processing.

27-27A are flowcharts illustrating the processing of reports by user ID.

Fig. 28 is a flowchart illustrating report list processing.

29-29A are flowcharts illustrating the processing of reports by activity.

Fig. 30 is a flowchart illustrating an outline of wash sale processing.

FIG. 31 is a flowchart illustrating the 988 partial gain/loss analysis process.

Fig. 32 is a flow chart illustrating the processing of the deferred amount of the wash sale.

Fig. 33 is a flowchart illustrating an outline of PFIC processing.

Fig. 34 is a flowchart illustrating PFIC fee tracking processing.

Detailed description of the invention

As discussed throughout, a "system administrator" is an operator, such as a management information systems specialist, responsible for maintaining the computer network used by the system. A "compliance analyst" is a specialist at a financial institution responsible for reviewing a fund's compliance, reporting matters to the fund manager and helping the fund manager understand the rationale for any possible violations. The "fund manager" is responsible for deciding to buy or sell the financial securities that make up the fund, within the investment guidelines imposed on the fund. It should be understood that any particular individual may assume any of these roles and still implement the invention. Additionally, groups of individuals may be employed in any of these roles and still implement the invention with the aid of other computer systems.

Referring to FIG. 1 , a schematic view of the data flow for a system 1 , a client or a fund manager 3 to report a transaction to the supervisory department 2 of a financial institution 10 . Information about transactions is delivered to each entity responsible for a particular fund4. The system can handle any number of funds. Preferably, this information is delivered to the Regulatory Department on the day of the transaction (ie "trade day"). The supervisory department 2 will transmit the information about the transaction to the fund accounting department 5 of the financial institution on the transaction day or by overnight supply. [What is a Warehouse/CCAP? ] The accounting department will also receive information from outside vendors 6 about financial securities such as credit ratings, shares outstanding, coupon rates, country codes, industry classifications, and maturity dates. Of course, it is also possible to obtain other types of information from outside vendors and still implement the present invention, as will be understood by those skilled in the art. Using this information, the financial institution will act as a "transfer agent" to calculate ownership for individual investors in the fund. In addition, the performance measurement department of the financial institution will determine the performance of the fund based on these recent transactions. Reports of this information can be delivered directly to the Fund Management Department of the financial institution9.

Once this information is collected by the financial institution 10, it is delivered to the financial institution's Management and Compliance Department 7. As discussed below, various compliance tests are run against this data, either scheduled by the task scheduler 27 (see Figures 2 and 7), or requested by a compliance analyst. The results of the tests are provided electronically (or on paper) by the system to the compliance analyst. While reviewing the compliance report 8 the analyst can simply "click" on sections of the report to receive more detailed information. Of course, other user interfaces may be provided between the analyst and the system, as will be understood by those skilled in the art. Importantly, the system maintains a record of fund holdings, the fund's transaction history, the fund's performance and pricing. This information, any changes to that information, the identity of the entity making the change, and the date and time the change was effected are also maintained. The system maintains records of "holding" level data and transaction level data. This allows for systematic compliance testing to verify that no fund transactions were in violation of the relevant guidelines during a given period, not just that the fund was not in violation at the end of that period.

Referring again to Figure 1, the system also provides fund management reports. In particular, the fund management section 9 of the financial institution 10 receives fund financial data and can generate various periodic reports 711 such as tax reports and the like. These reports can be printed on printer 712 or provided to an external source, such as IRS 713 . The system's maintenance of complete financial data allows financial reports to be generated upon client request or need. The rule-building library of the system discussed below allows the application of complex rules to generate reports related to global periodic requirements, such as IRS or SEC requirements, as will be understood by those skilled in the art.

It should be understood that it is now envisioned that the system will provide reports and the ability to drill down into these reports only to employees of the financial institution. Fund managers will receive reports from compliance analysts.

Referring to FIG. 2, a schematic diagram of the processing performed by the system 1, the financial institution's accounting system transmits its fund data (including related holdings, transactions, losses, income, ledger accounts and foreign exchange rates) to the compliance system 21. The compliance system also obtains asset data (including credit ratings, outstanding shares, coupon rates, country codes, industry classifications, and maturity dates) from external information vendors 22, 23 or from the financial institution's internal accounting department. Additional information about the financial institution may be manually entered into the system, which is indicated at box 24 .

Once the data is received, the system applies compliance testing. Preferably, the compliance test is run at night, so that when the compliance analyst comes to work in the morning, he is advised whether a possible violation has been detected. Compliance rules engine 25 is part of compliance system 21 and includes software that maintains the rules applicable to a given fund and applies them when scheduling. Report writer 26 is also part of the compliance system and generates reports on the application of compliance guidelines and tax and financial reporting. Scheduler 27 allows system administrators to schedule various tasks, such as running compliance tests at the request of compliance analysts. The compliance engine also includes software 28 for generating interactive screens that are displayed to the system user, either presenting the user with current information (such as a compliance report) or requesting information from the user. The compliance system also includes software leading to results tracking29, which allows compliance analysts to log online the resolution of a possible violation, thereby providing online auditing.

Once the compliance tests have been run, the system provides output 420 in various forms requested by the system user. For example, for analysts within a financial institution, the reports are preferably provided on the analyst's computer workstation. An analyst can review reports printed in a nightly batch, so he doesn't have to wait to print them at the start of the workday. He can also choose to run the report "anytime" when he needs it. When a compliance guideline is violated (or a warning of an approaching violation is issued), the analyst can be notified by the system by fax, e-mail or pager. Similarly, violations or warnings can also be given to customers. Of course, a more complete report could be provided and still implement the invention.

When a compliance analyst logs into System 1, he will be automatically notified of any possible violations. By sending a query to the system (such as by clicking on a field in the graphical user interface), he can receive more detailed information from the system and determine the nature of the possible violation, the nature of the rule violated, and the apparent reason for the violation. Although not generally required, at this point a skilled compliance analyst can determine whether there is in fact a violation by reviewing the operating parameters of the system set for the fund. Certain parameters (such as the definition of "liquidity") may be incorrect for this particular fund, and corrections will clear up this possible violation. Alternatively, a transaction may have been executed but not entered into the accounting system or the system. These subsequent transactions, combined with a rise or fall in the market value of the financial securities within the fund, can bring the fund back into compliance. After conducting an investigation or while it is in progress, the compliance analyst may approach the fund manager to notify him of a possible breach. The system can be set up such that certain defined possible violations are immediately brought to the attention of compliance analysts and/or fund managers. A compliance analyst is required to enter a response action or resolve a possible violation on the system. Responsive action may simply bring the breach to the attention of the fund manager.

The system maintains an audit trail of running compliance tests and their results. The compliance analyst's response is recorded for any changes that brought the fund into compliance. For example, if a transaction is later entered, the result of the initial compliance test is recorded, the entry of the subsequent transaction is recorded, and the new result of the subsequent compliance test is recorded. If desired, one can review the entire record of compliance testing and any actions taken.

The system preferably operates in a distributed 3-tier client server environment. It has a Windows NT (version 4.0) front end, is coded in Visual Basic (version 5.0), and operates on a Sybase (System 11) database. Of course, other comparable software and platforms can also be used to implement the invention.

The system of the present invention provides the user with great flexibility in defining the nature of the reports generated as well as an intuitive interface that allows off-the-shelf investigation of the data or rules affecting the reports. In particular, the system's compliance engine 21 includes a dynamic rule building engine that ensures the flexibility needed to service an integrated product. Data fields about the fund are defined for each fund as required by the analysis for that fund. These data fields provide the building blocks to build investment guidelines. The guidelines or rules governing a particular fund are translated into logical statements. Rules are grouped together to form tests. The system logic connects the fund-specific tests with the fund-specific data fed into the system on a daily basis, the task scheduler runs the tests at the frequency and timing requested by the analyst (of course the system can comply with the analyst's request Execute the test at any time). Appropriate testing for each fund is performed by a dedicated group of rule builders in each relationship with compliance analysts and clients who interpret the guidelines for each client (e.g. what does a particular client define as a "derivative"?) The beginning of the establishment. Rule Builders are responsible for creating new rules or adopting existing rules, verifying the accuracy of fund-specific definitions and assigning approved tests to funds for production purposes. Develop these rules so that they can demonstrate compliance through their own review of transactions, not just holdings of a financial fund.

The rules developed for the system are recorded in a rule base in the database of the computer of the financial institution 10 . Rules other than compositions, benchmarks, and derivatives require similar logic (ie, data-based results), which can be developed as needed for a particular application. These rules were initially established for different funds and even different types of funds. Once the software for a rule is written, it can be used against new funds. Thus, when generating a rule for a new fund, compliance analysts and rule builders can search the rule base for the same or similar rules. It is not necessary to develop new programs for the same rules. The compliance engine 21 of the system can be modified to allow new rule types to be created.

The system is designed to allow for combined proficiency testing and performance reporting. Generally, a portfolio account is a collection of accounts based on investment topics, and this collection is usually called a "fund family". For example, there could be a combination of all foreign equity portfolios and another combination of fixed income portfolios within the family. It is often desirable to apply tests to selected groups of accounts within a given family, particularly in the case of pensions. Compliance testing is also done at the individual account level, but payment orders can be different from the group level, as those skilled in the art will understand. The creation of a composite account consists of summing account-level information defined in the composite request file. However, once this combination is established, additional calculations are then performed to generate data suitable for executing the rules. The types of calculations typically required at the portfolio level include: percentage calculations for country exposures, industry exposures, weighted average calculations, and sell and cover logic for derivatives.

To perform such portfolio-level testing, the system includes the ability to define a portfolio account, execute all compliance rules with respect to that portfolio account, and calculate results with respect to that portfolio account. For example, the derivative opening (as opposed to any given fund) can be calculated for the portfolio using portfolio level testing, by performing derivative opening testing at the portfolio level. In general benchmarks can be used to compare the portfolio's national openness and planned benchmarks. The system also provides for creating report output for the portfolio account and seeing account level detail in the portfolio report (i.e. if 3 accounts have a guarantor, the report will list the value of the individual accounts and be expressed as the sum of the portfolio Line (totalline)) capability. The Prospectus Test Report includes a listing of account identification numbers, account names, and the net asset value of each account that makes up the composite account. The system allows scheduling portfolio account testing in the task scheduler, just like for fund testing. The notification mechanism discussed here with respect to the fund test is also used for the combined test (fax, pager, e-mail).

Supplemental security data may be provided through an external information vendor, such as Bloomberg. Different files that may be created for assets and for fixed income securities require enhancements to the information files provided by external information vendors. In addition, any new test may require changes to the system user interface screens for new data items, as will be understood by those skilled in the art. The purpose of this modification is to automate the asset creation and refresh process for securities or other new information sources.

Many investment guidelines require testing a fund or portfolio against a benchmark fund. The system allows for the establishment of rules for performing compliance testing against benchmark data. Preferably benchmark data is imported from an Excel spreadsheet format and stored in a table format. Generate a report showing benchmark data with various options and provide a data feature to view historical benchmark data. Historical data from the same baseline (ie, weekly, daily, monthly feeds) can be stored and recalled for later comparison. Compliance rules are enforced for an account or portfolio against this baseline. The system allows the user to establish (absolute and aggregate) rules for comparing an account or portfolio's attributes (e.g. open country) to a benchmark account's attributes and to establish comparisons of an account or portfolio's portfolio-level data (e.g., duration , weighted average maturity) with a benchmark account for the portfolio-level data rule. Rules can be established to perform calculations on both accounts or portfolios and benchmarks and compare the results. Rules based on transactional events (such as whether the fund purchased securities of asset types that were not within the benchmark) could also be developed. A test can be performed where the base date is not equal to the posting date for an account or combination. Preferably, the test always uses the benchmark data closest to (but not later than) the test date. For example, if the test date is 6/30/99 and the baseline data is 7/5/99 and 6/20/99, the test should use the 6/20/99 data. This system allows the user to specify a base to use at the rule level, which should be a parameter that allows different bases to be used for the same rule.

The reporting requirements for the system will represent the results of the test and have a separate report for the benchmark, with different sorting options available. It should be noted that the current functionality is not required for the benchmark (the benchmark data is static). For the current test, if the current date is 7/10/98, and a test is executed on 6/30/98 with a deadline of 7/10/98, the test should still use the data from 6/20/98 instead of 7 /5/98 data. While current transactions can be included for an account or portfolio, the benchmark data remains the same.

As explained more fully below, the system allows a user to generate a thorough and complete report of the financial securities in the fund, as well as the characteristics of those financial securities. For example, the system may be used for tax reporting services. Providing tax reporting in an automated rather than manual environment will improve quality, reduce risk and improve the timeliness of tax services to financial institutions' money management customers. Advantageously, the system combines investment guideline compliance testing with full tax reporting functionality, allowing for more accurate and complete results.

Convenient presentation of compliance results along with a clear user interface allows compliance managers the ability to modify parameters relative to funds and provide "what if" scenarios. "What if" scenario testing is less "real-time" than pre-transaction compliance as discussed below. Used by investment managers, portfolio strategists and risk managers, it aids in the decision-making process in the direction of a portfolio. It helps fund managers and compliance managers, as well as other professionals in the financial institution, evaluate a portfolio as investment guidelines or portfolio dynamics change, either at the level required by the manager or at the aggregate level shock. Does not need to be "anytime", but should be part of an analysis performed by an analyst over a period of days or weeks. For example, a compliance analyst can investigate the effect of changing a compliance rule or test: "If I increase my permissible opening to 'at home' in Europe by changing my rule parameter from 5% to 10%, what can be exploited?" What kind of European opportunity?"; "What if I add restrictions to the tobacco industry because of possible legal action?"; "What if I completely revise my proposal/guidelines from X to Y because of restructuring within my organization? How?"; "What happens if I withdraw my Fixed Income Manager account from the pool?". Additionally, compliance analysts can investigate the effects of changes in portfolio dynamics: "What if I sell a particular holding?". Analyzing the effect of these changes on historical investment performance can educate fund managers and advisors to financial institutions how to improve performance in the future.

The system can also be used to verify compliance with pre-transactions. Pre-trade compliance refers to real-time compliance checks based on real-time portfolio pricing and repricing and real-time asset specification data. It is found that the transaction that pushes the investment portfolio into violation is blocked by the system, and the order cannot be executed. This capability will reside on the trading desktop as a tool to control a trader's activities. Preferably, the pre-transactional compliance feature is not only part of the scope of the compliance reporting product. An effective pre-trade compliance product will need to be fully integrated with a trade order entry and portfolio management system.

Compliance analysts and fund managers can develop new rules to test funds. This information can be used to generate fund regulations in the future or to provide fund managers with insight into the operation of the fund under new regulations. In particular, it should be understood that the system may be used to analyze any of the following: rules using information on fund transactions; portfolio flows; short sales; futures contracts; rules relating to derivatives; coverage/opening; guarantees Balanced trades/speculative trades; Margin; Options and spreads for buying and selling stocks; Average; Dollar-weighted average expiration; Average quality; Time to buy rules - all rules are based on current day information. The system can also be used to analyze dual function rules (outcome based on one outcome) such as: if a portfolio borrows more than 5% of total assets, it cannot buy securities; compare results; borrowing must be less than market value or lesser of costs x% of one; maturity calculations using shortened maturities - order features, stock put rights, etc; logic using underlying security information. Of course, any number or type of rules may be established and applied while still implementing the invention.

It should be understood that the system can be used to perform several fund management functions that are accomplished using manual processes, such as subscriptions; real estate; leases; mortgages; stock lending; indices; Third-party supplies, such as other accounting systems. [What should it do? ]

Preferably, the system includes a menu-driven user interface allowing compliance analysts to easily access information generated by the system. The menu bar on the main menu screen dynamically maintains and uses common user interface conventions, including pull-down menus, such as Microsoft Corporation's Windows NT conventions. To access the system, the user double-clicks the startup icon, and the system requests a password. A username and password identify a user. Users are granted certain certain access rights that allow them to perform only limited actions on the system. The main menu screen may include message lines containing text, such as data fields into which data is to be entered. Only those menu items accessible to that particular user are displayed on the menu bar and submenus, such as File (file), Data (data), Compliance (compliance), Repot (report), Windows (window), and Help (help).

The report option of the main menu preferably includes 6 options: Compliance, Results Tracking, Administration, System Access, Activity Log and Observation Report. The Compliance option will open a window for observing and requesting compliance reports. The Results Tracking option opens a window for observing and responding to compliance violations. The management option allows the user to open the general ledger window to observe the general ledger audit report and the holding window to observe the holding audit report. System Access Options opens a window for requesting and viewing System Access Reports. The Activity Logging option opens a window for requesting and observing reports of logon and logoff activity. The View Report option opens a window for viewing and printing previously generated reports.

Referring to Figure 3, user IDs and passwords are maintained by the network or system administrator in a separate program on a separate computer or on the computer included as the program for the system. This system does not generate or maintain this information. A user ID and password are required when a user logs in, to re-enter the system after requesting a lockout, or to re-enter the system at block 30 after a timeout by the system. The login process retrieves network user ID information at frame 713 using the WONDOWS NT API at frame 31. This API will return the network user ID for the workstation. At block 32 the user table is read. The system passes the password entered by the user at frame 33 to the API for verification. The system determines at block 37 whether the user is "blocked", eg, if the user is already logged in. If the ID is blocked, the system will send a message to the user, which is indicated at block 36. This attempt will be recorded in the event table 34 at block 35 . The system then ends at block 38 .

If the user ID is not blocked at block 37, the user data is formatted at block 39. The API will return a code at block 431 indicating whether the password entered was correct. All login attempts are logged in the event table 34 in the database, whether the attempt was successful (block 530) or unsuccessful (block 433). A message is sent to the user at block 433 when their login was unsuccessful. If the user tries to submit an unacceptable password 3 times at frame 436, then a SQL statement uses the network ID to update the user table 33 to turn on the block indicator at frame 437. This action will be logged in the event table 34 at block 438 and the system application will end at block 439 .

If the user ID and password are accepted at block 432, the system will retrieve the user profile at blocks 531 and 536 and a list of authorized system functions and data access from database 537 at block 532. The user's access profile is saved in memory at block 533 so that all tables on the system can determine access to functions and data for this particular user. The system then passes control to the system's main menu at block 534.

Users can "lock out" the system on their workstations by minimizing the screen. Alternatively, the user may select "Block" from the drop-down file menu located on the menu bar. Additionally, if no activity is recorded on the system for a given period of time (eg, 30 minutes), the system marks the user account as inactive, logs it out, and automatically minimizes the application. To re-enter the system, users need to double-click the system icon and re-enter their password. The system then verifies the password as discussed above. These blocking activities will be recorded in the activity table.

System administrators create new user accounts, and modify, delete, or disable existing user accounts. Each user account includes a user profile that defines the access to system functions and data authorized to the user, such as a compliance analyst. For example, a user can be granted read-only or update privileges. Also provides login information, which contains the current date of user login and logout activity, including: date and time of last login, current login status, and user block notifications. Preferably, each user account is uniquely identified by a user ID and user access rights are appropriately restricted. All requests for access to user account information in the system will require the requestor to provide certain information, such as the nature of the information to be observed or the party authorized to access the information. The request must be fulfilled by the system administrator after approval by the appropriate officials of the financial institution. This aspect of the system requires that all requests for user authorization be documented and access authorization established based on business needs and task responsibilities.

Referring to Figure 4, user account information can be used in both display-only and updateable screen scenarios. A user (typically a system administrator) with both authorizations and data access for updates will have the ability to perform update functions. Users with read-only data access will be prevented from performing updates. By selecting the system access option from the file drop-down menu on the main menu screen 715 at box 40, the user will open the system access window on his workstation 44. It is divided into two parts. The left window created at frame 41 will present a user list box containing all user accounts from the user profile table 42 within the system. The right window created at box 43 includes the following three user information tabs: Account Information at box 44, Account Permissions at box 45, and Account Status at box 46. These will provide system administrators the ability to establish and maintain user profiles, grant and revoke system access, and audit user login status. At the bottom of the right window there are 3 buttons: SAVE (save), CANCEL (undo) and CLOSE (close). Once the user finishes working on a tab, he must select the SAVE button to save their changes to the user profile table. The CANCEL button will erase any changes made to the current tab before saving. The user clicks the CLOSE button to close the system access window and return to the main menu screen.

The user list box is populated with the current user list. By default this list is stored with lastname. However, system administrators can also sort by first name or user ID by clicking on the appropriate column header. A system administrator can easily locate a user ID in the table, either by using the scroll bar, or by typing the first character of the ID to cause the list to jump to that point. When the system access window is opened for the first time, the account information table can be seen, indicating the last record of work done on it. This tab allows system administrators to create and maintain user-specific information.

Referring to FIG. 4A, to add a new user account at frame 47, the system administrator clicks the NEW button in the user list box, clearing all fields on the account information form. The system verifies at block 48 whether this user has proper authorization. If not, the system returns to box 43 (FIG. 4). If the user has the appropriate authorization, the label field is initialized at block 49 . The system administrator enters the required fields (defining access rights, etc.) at box 440, uses the authorization page provided by the information owner, and clicks the SAVE button 441 to add the new account information to the user profile table 447. The system verifies at block 444 that the necessary fields have been completed. If the required information is missing, the field is highlighted and a message is displayed on the workstation 44 at block 448 . If the screen is completely filled, then at frame 445 the system checks for a lock [what does this mean here? ]. If the lock check fails, an error message is transmitted to the user at block 448 . If the lock check passes, then at block 446 the user profile table 447 is updated. Once a new user account is added to the system, the system administrator can either click the NEW button to add another or click the CANCEL button 442 to close the window.

To delete a user account from the system, the system administrator clicks the DELETE button in the user list box at box 540 in FIG. 4A. The system verifies at block 541 whether the user has proper authorization. The system administrator selects a user account from the user list box, populates the Account Information tab with the user's account information at box 542, and clicks the DELETE button. A message box is displayed at block 543 requesting confirmation of deletion. Click the YES button to confirm the deletion. Then at frame 544 the system checks the lock. The user account will be permanently deleted at block 545, which will clear the user's account information from the user profile table. Clicking the NO button undoes the delete operation, and at block 546 an error message is sent to the user.

Banning an account will prevent logging into the system. To disable a user account, the system administrator clicks on the Disabled Account check box so that an "x" appears in the box, and clicks the SAVE button to complete the change, which will indicate that the user account is disabled in the User Profiles table. The account will be re-allowed by removing the check mark from the Ban account check box.

System administrators can also access the above functions by clicking the right mouse button while placing the cursor on a record in the user list box. A pop-up menu appears with the options: add a new user account, delete the user account, or show details about the user account.

Referring to FIG. 6 , to review a user's permissions under the system, the system administrator selects the Account Permissions tab at box 46 of FIG. 4 by clicking on the tabs tab or entering underlined characters within the tabs. The user clicks on the user ID at block 60 . The system reads the user's rights at box 61 from the access rights table 62 in the database, which are displayed on the workstation 44 at box 63 . The Account Permissions tab will contain the Assigned and Available list boxes. The Assigned list box includes a tree view of the permissions assigned to the user account for that particular user. The Available List Box has a tree table of all funds, fund groups, rules, tests, and functions available on the system. When a new account is created, the tree form in the Assigned Permissions list box is initially empty.

Referring to Figures 5A and 5B, the system administrator can access the Select Account Permissions tab (Figure 4) to grant access to the user for: Funds, Fund Groups, Rules, Tests, and System Functions. To review the permissions currently granted to a user, the system administrator right clicks on the user ID at frame 50. The system reads the access rights table 901 at block 51 . The user ID details are then displayed on the workstation 44 at box 52 .

To authorize a user account to access functions or data, the system administrator selects a user account at box 53 by clicking on a user record in the user list box. At block 54, the system determines whether the system administrator has appropriate authorization. If so, the system reads the access rights table 901 of the database and displays the details of the user ID on the monitor 44 at block 56 . Then at box 57 the user double-clicks an item in the available list box (or clicks on it and then the ADD button) to assign or revoke permissions. The items to be granted access are moved from the Available list box to the Assigned list box. To revoke a user's access to a particular item, at box 57 the system administrator can either double-click the item in the Assignment list box, or click the item and then click the REMOVE button. This will clear the item from the assignment list box. In addition to moving individual items with access rights, the tree table can be expanded or collapsed, allowing groups of items to be selected for granting or revoking access. The user can select the CANCEL button 800 and the changes will not be saved, but the screen is initialized at block 801 . The system then returns to box 43 of FIG. 4 . Alternatively, the system administrator can save changes by selecting the SAVE button 58 . Then at block 59 the system performs a screen check. [What does this verify? ] If it fails, an error message is generated at block 902. If this verification passes, the system checks the lock at block 803 (see Figure 5B). If the lock check fails, an error message is generated at block 902. If the lock check passes, then at block 804 the user profile table 901 in the database is updated.

The system administrator must set the privilege level for each item in the Assignment list box. To do this, the system administrator will click 'R' in the R/W field to allow read privileges, or 'W' to allow write privileges. Write privileges automatically allow read privileges. An allowed item is shown in gray. To disable the privilege, the system administrator clicks the item a second time. The system administrator clicks the SAVE button, which will add the account privilege information to the user profile table.

When the system administrator is in the System's Assignment list box or in one of the Available list boxes, clicking the right mouse button will cause a shortcut menu to appear, belonging to the current item, with the following options: Add, Clear, Details, Full Collapse, Full Expand . Add, Clear, and Detail options are performed as described above. The Full retract option retracts the tree table to its highest level of detail. The Fully Expand option causes the tree table to expand to its lowest level of detail.

The intruder block check box will be checked when the user is blocked after 3 attempts to log in with an incorrect password. The last occurred data will appear in On Cell. The Reset Account Access checkbox allows the system administrator to re-allow access for that account. Referring to FIG. 6, to view user login information and reset account access for a given user, the system administrator will first click on the user account in the user list box at box 64 (and then click on the account status tab). At block 65 the system reads the activity table 66 and the access rights table 67 for that particular user. The system displays the user ID account status on the workstation 44 at box 68 and provides a check box at box 69 to reset account access rights. The system administrator can select the CANCEL button 806 and the system initialization label field at block 807 . Alternatively, the user may select the SAVE button 805 at block 808 and the system checks the system lock. If the lock check fails, the system provides an error message at block 811 on the administrator's workstation. If the lock check passes, then at block 809 the user profile table is updated.

The system allows tasks to be scheduled for automatic execution without requiring users to stand by and submit requests. The system will place a record in the task queue to request a specific function, such as running a compliance check. If the scheduled function fails, the system retries the execution and notifies the user that the execution is postponed. The user will specify the dates (or range of dates) and anchor dates (ie current date and due date) on which the function will be performed. The user will specify the time interval for executing system functions, the time interval for retrying if the execution fails, and the time interval for notifying the user of the failure thereafter. Various templates can be used as a user interface to allow the user to enter this information in a straightforward manner.

Fig. 7 is a flowchart illustrating processing related to the task scheduler. A scheduling dialog is displayed on monitor 44 at block 70 . The system allows the user to enter the operating frequency at box 72 when the user clicks on the operating frequency button 71 on the monitor display. The user can select on what day to run a scheduled task in the following manner, selecting a specific single day at box 772, selecting a specific day of the week at box 773 (e.g., every Wednesday), selecting the month at box 774 and selecting a specific day at box 775. A particular day of the month is selected, or a particular day of a particular month of a particular year is selected at boxes 778, 777 and 776, respectively.

Once the run frequency is selected, the user selects "Current" and a due fixed date at box 77, and then at box 78 selects a run time period and a time interval to retry if the task is unsuccessful. The user can then shut down and log out of the system at block 471 or undo the scheduled task at block 472 . Alternatively, the user may choose to close and save at block 473 . The system performs an on-screen validation at block 470 to verify that the data entered by the user is appropriate. If there is an error, an error message is generated at block 474 and displayed on monitor 44. The system then displays the Schedule dialog box. If the system determines at block 470 that the user has entered suitable information, then at block 79 the schedule is saved in the schedule/queue table 75 of the financial institution's computer. The system then displays the Schedule dialog box.

The user may select the status button 73 while viewing the schedule dialog. The system then retrieves information about the next and last scheduled task to run from the financial institution's computer's schedule/queue table 75 at block 74 . The user can then select the on hold button 76 to prevent the next scheduled task from running before being released by the user.

Referring to FIG. 8, once the task schedule is saved, the system uses the schedule/queue table 75 and the task queue screen which allows the user to view on his monitor 44 the tasks scheduled for execution and the history of their original execution. Users can retrieve task queues for specific activities. For example, a user may wish to review tasks performed for a particular fund. Users can filter search results by date, name, completion status, etc. Once in the task queue screen, the user can edit or view the task schedule.

From the main menu 80 the user selects the schedule button 81 . The system then displays a task queue window on monitor 44 at block 82 . At block 83 , the system retrieves next and last run information from the schedule/queue table 75 . The user can then close the task queue window by clicking the close button 88 . The user can double-click an event displayed on the task queue at box 85 to retrieve more information about the event. The user can also click on the task schedule button 86 to schedule another task. Users can also click the watch button to watch another scheduled task.

The system uses data received from electronic source systems within the financial institution as well as external to the financial institution. However, for this information to be useful, certain installation functions must occur. For example, each asset must be classified for a particular fund. It should be understood that different funds may classify the same asset differently. Certain funds may consider "cash out" only existing cash on hand, while others consider "cash out" to be cash on hand and any securities maturing within the next 30 days. Therefore, assets must be classified at a fund level before compliance can be checked.

The timing of transaction postings has a significant impact on the schedule of compliance checks. Preferably, transaction information is delivered to the financial institution's compliance system as quickly as possible and compliance testing is performed immediately (ideally, all in "real time"). However, it should be understood that this does not always happen in practice. Transactions are processed in the supervisory system and identify the transaction date. Transactions are transmitted to the accounting system on the transaction date or a subsequent date. The accountant adjusts the transaction data to generate a resulting net asset value ("NAV") at the end of the day. The NAV for a fund will not be announced until the adjustment is completed. During the transaction date, or on a subsequent day, the system will receive instructions from the financial institution's accounting department to open the asset. If the asset does not exist, the system will open the asset and assign it an empty location. Data stewards enter classifications and adjustments before receiving location and transaction data later that day. On the night after the trade day and after the NAV is calculated for the fund, the holding and transaction data are passed to the system, which then performs rule checks (and compliance testing) and notifies compliance analysts of any violations.

Certain transactions are excluded from this processing. Transactions processed on the same day are directly transmitted to the accounting system of the financial institution on the transaction day and to this system on the night of the transaction day. (The day after the trading day is called the trading day plus one). Data stewards are not given a full day to assign classifications and perform maintenance on any new asset locations. Asset opening and location data are received by the system as soon as these transactions are posted to the source system (ie, on the transaction day). The system will open this new asset and location as above, but the data steward will only classify any new assets and locations resulting from these transactions at night. Additionally, when the internal source system is a regulatory system, transaction data is received on the night of the transaction, allowing administrators to process compliance the day after the transaction day.

The system receives data about assets and locations from source systems. Asset open data is sent to this system whenever a new location is opened on the source system. A full asset summary is sent from the source system to the present system each time a new location is opened, ensuring that an asset record appears on the record for each new location. Asset opening data is sent as soon as the transaction is posted to the source system. Usually, this happens the day after the trade but can also happen on the trade day. Asset update data is sent from source systems at several intervals throughout the day. Whenever a new location is opened on the source system, new location data (including CUSIP, description and opening location and units) is also sent to the native system. Data stewards will classify locations. Whenever possible, any changes and additions to location data are sent from the source system to the present system. Additionally, transaction data is sent in batches by the source system on the night of posting to the source system. Usually, this is the night after two days of trading. The system updates existing location records with this information and fills in missing data on new location records opened on the system earlier in the day. If the accounting is not adjusted by the end of the transaction day plus one, the source system preferably sends the transaction data to the system as soon as the posting of these transactions is completed.

To provide accurate compliance analysis, the system must maintain accurate and timely asset information. The system provides the ability to maintain these data items manually. Asset data in the system is categorized in two overlapping categories. The source data is uniquely generated and maintained by the source system, which is not controlled and maintained by this system. Fund management data is data maintained by this system and is not downloaded from the source system. For system operation and analysis purposes, the data items used by the source system will be considered 100% accurate and cannot be corrected by the data administrator. Data generated by the source system, but not used for any processing prior to transmission to the present system, will be considered unreliable and require user verification.

The system provides the ability to disable and allow update functionality on a system-wide basis for all data items except user IDs. Business decisions will be made on a per-site basis, dependent on individual source systems, and may change based on the availability of reliable information on the source systems. A dynamic reliability indicator will classify source system data as "reliable" and "unreliable". The system does not populate the database with unreliable source system data. The system allows on-line maintenance and requires user verification for unreliable items. The system does not allow reliable items to be maintained online.

The system logs all modifications to data item values on the database. Each change will cause a log record to be generated containing the time-date stamp of the change, the user ID of the person who made the change, and an optional comment stating the reason for the change. This allows any reporting in the system to be performed based on data values available on different dates. It also provides information for auditing functions. Asset fields marked as unreliable may need to be manually validated by a data steward. The list of verifiable fields differs within each asset type. All assets are considered certified after all verifiable fields have been individually approved by the data steward. Data administrators have the option of deferring asset certification for a temporary period (eg two weeks), for example, in an industry that recognizes that a data item is not readily available, such as an emerging market issue of outstanding stock. This type of verification will be referred to as 'delayed verification'. After two weeks a notification message will pop up on the data administrator's workstation, reminding him that the validation has been temporarily postponed and needs to be done now.

The system will allow multiple versions of a single asset, where the asset exists on two different source systems. This is needed because it is possible to have conflicting data values on each system for the asset. Provides functionality to allow or disallow source updates and required validation against data sources. Asset translation tables are used during conversion from one source system to another. Online access allows data stewards to find assets by any of their identifiers: Asset ID, Description, CUSIP, SEDOL, etc. The source system ID is part of the asset definition properties. Users are able to list all assets or all unverified assets. Data administrators can view an asset's description data by double-clicking on the asset while viewing a holding position.

The user interface preferably reflects all the important steps required by a data administrator to maintain or certify information about an asset. Also describes functions performed by the system in response to their actions, such as: selecting an asset item from a data pop-up menu; specifying retrieval criteria; retrieval criteria validation; asset list retrieval and validation; selecting from an asset list; retrieving from a database Asset information; manage asset maintenance screen; popup asset menu activation; action on show/hide main menu asset submenu; save asset information; audit records updated in asset transaction log. This interface allows users to interact intuitively with the system.

Asset Data Maintenance/Validation consists of two windows. Use the first, the Asset Search screen, to find suitable asset items (or a list of them) in the database. Use the second, Asset Maintenance screen, to maintain data.

The Data Administrator can open the Asset Retrieval screen by selecting the Data option from the main menu screen, then select the Asset item from the resulting submenu. A list of assets will appear at the bottom of the asset search. It is displayed by default and remains disabled until the user defines search criteria and performs a database search. The data steward specifies retrieval criteria, and the system returns a list of assets to modify and/or certify. The data administrator activates the search by pressing the SEARCH button. The data administrator can exit the asset retrieval screen at any time by clicking the CANCEL button. This will drop the asset management functionality and return the data manager to the main application screen. The top of the screen will allow the data administrator to define search criteria. They will enter either prefix or complete information in any combination of text fields at the top of the screen. By selecting one of 3 radio buttons, the user selects: All Assets, Uncertified Assets Only, Uncertified and Postponed (Verified Assets Only for a Short Period). If no or invalid search criteria are specified, the system displays an error message, otherwise it searches the database for assets that match the specified criteria. If no matching asset is found in the database, the app displays a warning message. Otherwise, a list of matching assets appears at the bottom of the screen. At this point, the data steward will select an asset to process, either by double-clicking the asset list item or by clicking the SHOW button. If only one item is found, the system automatically displays the asset management screen. If the data administrator returns to the asset retrieval screen and picks another item from the asset list (other than the one already open), more than one asset management screen can be open at the same time.

The main purpose of maintenance screens is to modify and/or certify information related to assets. It includes all replied asset information, and asset transaction history. Information on user screens can be color coded to easily distinguish between different states of information. For example, source information that cannot be changed in a maintenance screen application will have a gray background. Source information that can be changed by a data steward will have a dark red background. A light red background indicates information supported only through the app. The data steward can change information related to the corresponding asset by pointing and clicking fields in the screen, and enter new information (or pick items from the corresponding list boxes). If the data administrator clicks the OK button, the system will verify that the update was made and display an error message if it was not. If the data administrator verifies that an update was made, the system attempts to write the updated/verified information to the database. If any changes are invalid, an error message is displayed. Additionally, if an error is encountered while writing data to the database, an appropriate error message appears. If the CANCEL button is clicked, the updated and/or confirmed information is not saved. If any amendments/verifications were made prior to pressing the button, the Data Controller is alerted to this. The data steward will also be able to attest to the information in all fields with a red background, as well as the entire record (all information for that given asset). This is done by clicking the right mouse button or anywhere on the asset management screen. A popup confirmation menu will appear. Optionally, validation of both fields and/or records is done by using the Assets menu.

If the Postponed Verification menu item is selected, the system provides a "Postponed Asset Verification" dialog box on the user's workstation screen. The Data Administrator can choose to apply the default validation deferral date (two weeks from the current date), set a new date, or abort the deferral validation process (by pressing the CANCEL button). If you choose to defer the certification date, the system displays it at the top of its asset management screens.

Initially, the main menu assets submenu is hidden. However, the system automatically provides this menu when the asset management screen is activated for the first time and clears it when the data manager puts any other format on top of the screen or closes the asset management screen. The system changes the background of the Validated field to light blue. Additionally, if all current asset information is verified, the system displays the label "Verified" instead of "Not Verified." Tabs are provided at the bottom of the screen to display additional information. Clicking on a tab will cause the system to display asset class information. Specific asset-related information is viewed by clicking on the tab labeled "Special". The History tab will submit transaction log information that reflects the history of modifications and validations associated with the asset. Of course, other tabs may be provided to allow the user to "drill down" into a given asset and still implement the present invention.

After all changes and/or validations are done on screen for a given asset, they are permanently saved to the database. To do so, the data administrator clicks the OK button on the asset management screen. The system prompts the data administrator to confirm the update. After saving the updated information, the system will check the validity of all database updates and display an appropriate error message if an error is encountered while writing data to the database, if the modification violates database referential integrity, or if any changes are invalid . The system automatically enters a new record in the Asset Transaction Log table each time an update is successfully saved in the database. The records in this table consist of audit record information. It includes the time of change, user ID and previous value. The asset transaction log can be reviewed at any time by clicking the History tab of the Asset Management screen.

Referring to Figures 9 and 9A, which shows an asset maintenance flow diagram, to display the asset maintenance screen, the data manager selects data and then assets from the main menu screen at box 92. The user selects an asset item at box 90 from the data pop-up menu. The Asset Retrieval screen will appear. The user specifies search criteria to obtain a list of assets to revise and/or validate, which is displayed on monitor 44 at block 91 . The data administrator starts the database search by clicking the SEARCH button at box 93 . The data administrator exits the asset retrieval screen at any time by clicking the CANCEL button 94 . This will abort the asset management functions and return the data manager to the main menu screen. The system reviews the search criteria at block 95 and displays an error message at block 96 if the search criteria were not specified or invalid. Otherwise, it will perform a database search at block 97 for assets matching the specified search criteria. The system will perform a database search for assets that match the combination of search criteria entered. The system retrieves data from the asset table 98, based on asset ID, description or type, SIC code, CUSIP, SEDOL, ticker, issue or source information. If no matching assets are found, the system provides an error message at block 96 . If assets are found, the system will retrieve and submit a list of these matching assets and their attributes from the database at the bottom of the asset retrieval screen.

The data steward can select the asset to process by picking the appropriate item from the asset table displayed on the monitor 44 at block 99 . At any time, the data administrator can exit the asset retrieval screen by clicking the CANCEL button. This will forego asset management functionality and return the user to the main app screen. The data administrator can instruct the system to start a particular asset data retrieval and presentation by pressing the SHOW button 491 . The system will perform a database search at block 493 to retrieve all information for that asset from the asset table 98 based on the asset ID picked up by the user. Initially, the main menu assets submenu is hidden. However, at block 492, it automatically appears when the asset management screen is first activated, and disappears when the data administrator brings any other format to the top of the screen or closes the asset maintenance screen. The hidden asset menu reappears if the data administrator activates it by clicking on the asset maintenance screen. The system submits asset maintenance screens containing current asset information for modification and/or validation of that information.

Referring specifically to FIG. 9A , the data administrator can change information related to the corresponding asset at block 494 by pointing and clicking on a field in the screen. Additionally, at block 494, they can verify the information in the current field, as well as the entire record (all information for a given asset) by using the asset menu or by clicking the right mouse button. If the data administrator clicks the OK button 495, the system validates the updates at block 497 and attempts to permanently save them to the database at blocks 498 and 499. If the CANCEL button is clicked, the updated and/or confirmed information is not saved. If the system decides to enter a modification/confirmation after clicking the OK button 495, the data administrator is prompted to do so. If no modifications have been made, the system displays an error message, otherwise it starts the process of saving the updated information. If the data administrator chooses to validate the update, the system writes the updated/validated information to the database and transaction log 780 of the asset database 98 at 498 and 499 . If any changes are determined to be invalid at block 499, the system displays an error message at block 590. After saving the updated information, the system checks the validity of all database updates and the integrity of the database references. If the system encounters an error while writing data to the database, or if any changes are invalid, an appropriate error message will be displayed.

The system provides the opportunity to assign ratings to a variety of assets. The grades used vary for different types of securities and regions. The system uses journal tables to save all changes to asset entities. The system also uses fund data, which consists of fund-specific information as well as logical fields that allow the system to customize processing and reporting for any fund in the system. Because all holding data in the system applies to a specific fund, all holding-related data including asset locations, ledgers, shares and transactions will be accessed through the fund maintenance screens in the system.

In this system, most of the fund-related data are entered and maintained manually by data administrators. However, some fields are obtained from the source system. This data is assumed to be completely accurate and will not be verified by the data controller. All holding information is received from the source system and is believed to be accurate and therefore not maintained in the system. Changes to holding information must be made on the source system and passed to the fund management system as an amended transaction. All transactions have a posting and current date, which will allow transactions to be valid before they are posted to the system, if necessary.

As mentioned above, there are two types of system fund data: source data and fund management data. Source data is maintained on the source system and cannot be changed by the data administrator. The source system extracts complete fund data for all funds residing on the fund management system. The system compares all fields in the extracted data field by field against the fund data in the database. When a difference is found, the fund data in the database will be overwritten with the data from the extracted record. Fund management data that is specific to compliance checks and not available (or unreliable) to source systems is entered into and maintained in the fund management system by data stewards. When displaying fund data, source system data (also known as accounting data) will have all fields blocked and unavailable for input, while fund management data will have all fields unlocked and available for input. Whenever a field is modified, either by the system (for source data) or by a data administrator (for fund management data), the "last updated" and "changed by" fields will use the current data and the date of the change User ID/system update. Additionally, an audit record is written for each change with the following information:

field name - the name of the changed field;

ChangeDate - the date the field was updated;

ChangeTime - the time the field was updated;

Changed by whom - the source system of the new information;

Original Value - The value of the field before the change.

In addition to providing audit trails, use audit trails for historical reports. Whenever a report is required for the previous reporting period, the audit trail must be checked to determine the value of the fund data field for the previous reporting period.

Whenever updates are made to general fund data, the system will check their validity and display an error message if any are invalid. The system then prompts the data administrator to confirm all changes. Once complete, the system will attempt to write the add/change to the database. When any errors are encountered while writing changes to the database, the system displays an appropriate error message, otherwise the changes are made permanent.

All holding information in the system is related to a specific fund and is generated by transactions. Every operation, including accruals and installments, is considered a transaction. The position and share of each asset held for a fund is the sum of all or specific transactions for that asset. Each asset held by a fund is stored as a separate row in the holdings table and is logically related to that fund by a fund ID. The shares that make up each holding in a fund are stored as separate rows in the share table and are logically related to that share by a unique fund ID-asset ID combination. Similarly, all transaction items are stored in the transaction item table, and are logically related to asset holdings in the fund through a unique fund ID-asset ID combination. Establish a unique share ID to define the relationship between fund shares and transactions.

Asset information for assets held for a fund can be maintained at the fund level. Data stewards can enter values to overrule synthetic asset values. This feature is most useful for industrial classifications. Certain assets can classify an asset differently than the accepted general classification. Asset information can also be overruled at the fund group level. This allows maintaining synchronized asset information for a complete customer relationship. For example, one fund manager may refer to ABC securities as belonging to an "alpha-beta company," while another will use "ABC" to identify securities belonging to a separate company.

A graphical user interface allows users to easily enter and change data. When the Data Administrator selects Funds from the Data drop-down menu on the Main Menu screen, the system displays the Select Funds screen. The Data Administrator will be able to start typing the desired fund ID, or fund name, into the search box at the top of the screen and hit the SEARCH button to pull up a list of funds matching the search criteria. To retrieve the complete list of available funds, the data administrator clicks on the SEARCH button without entering any search criteria. The system then displays a complete list of available funds to the data administrator. Clicking the field buttons at the top of each column will enable the list box to be sorted in ascending order by Fund ID or Fund Name. The data administrator selects the fund to watch, and clicks the SELECT button, or double-clicks the desired fund. They will be able to click the NEW button when they have proper authorization. This will produce the fund management screen with no data displayed, and all general fund information fields are not blocked. They can then enter the new fund's data and click the SAVE button to add a new fund to the system.

The Fund Management screen will display all fund related data. The system will display 3 levels of detail as follows: fund level data; holding level data; and share level data. Initially, the system will display all fund-level data (ie general fund information, fund performance, fund holdings, etc.). When displaying fund-level data, summary data about the selected fund is displayed at the top of the screen (above the tabs). When data administrators select a particular asset location, they will have the ability to drill down to that holding by selecting "holding" from the detail level tree structure displayed on the screen. When displaying information at the holding level, at the top of the screen (above the tabs) summary information about the selected fund and asset location is displayed, with different sets of tabs available for selection. Holding level data includes detailed holding information, share information, etc. The data administrator can drill down to a selected share within a holding position by selecting "Share" from the detail level tree on the screen. At the top of the screen (above the tabs) will display summary information about the selected funds, assets, and shares, and there are different sets of tabs available. Share-level data includes detailed share information, share transactions, etc.

At the fund level, the GUI provides the following tabs: General Fund Tab; Fund Performance Tab; Fund Holdings Tab. Displays the General Fund tab for the selected fund. If data stewards have the appropriate access rights, they will be able to modify the Fund Management fields on this tab. When the data administrator clicks the SAVE button, all changes are permanent. Data stewards can return to the list of available funds by clicking the SEARCH button. The Fund Performance tab is displayed for the fund's performance during a user-selected from/to period. The Fund Holdings tab displays a list of assets held by the fund. By default, the system only displays the positions currently held in the fund, however users can select the "full holding" option at the top of the screen to display all asset positions for the fund, even if the assets are not currently held by the fund Yes (but held for some time in the past).

The Fund Holdings screen displays underlying holding information about asset locations. Each column in this list can be sorted by clicking the left mouse button on the column header for each field. The Asset ID, CUSIP, SEDOL, Long/Short Indicator, and Description fields are sorted in ascending order, while the Last Activity Date, Unit, Fee, and Market Value fields are sorted in descending order. This will allow the most recent or largest transactions to appear at the top of the list. After the holding summary list is sorted as desired, the user will be able to scroll to the desired position. Alternatively, the user can place the cursor on the cell at the top of the list and start typing the desired value. The system will place the appropriate entry that most closely matches the value entered into the list. To drill down to holding levels, the user must select an item from this list. The user can then move to a lower level of detail about the selected holding by selecting "Holdings" from the tree structure displayed on the screen.

Clicking on the Fund Transactions tab causes the system to display a list of all transactions for that fund within a user-supplied From/To period. The transaction summary list can be sorted on any field by left-clicking on that field's column header. Transaction types will be sorted in ascending order, while all other fields will be sorted in descending order. To see detailed information about a particular transaction, the user can enter a transaction ID at the top of the tab and click the SHOW button. Alternatively, the user can select a transaction from the list and click the SHOW button or double-click the selected item in the list. Details about the transaction will be displayed.

Clicking on the Fund Ledger tab causes the system to display a list of all ledger transactions for that fund within a user-supplied from/to time period. The Ledger Summary list can be sorted by any field by left-clicking on that field's column header. The debit and credit fields will be sorted in descending order, while all other fields will be sorted in ascending order. To display additional ledger transactions, the user double-clicks the selected transaction or selects an item from the list and clicks the SHOW button.

Once the user selects a particular holding at the fund detail level, he can view more detailed information about it by selecting "holding" from the detail level tree on the fund management screen. Summary data for the selected asset will be displayed at the top of the screen, in addition to the summary data about the fund displayed at the fund level. At the holding detail level, the user can click on the following tabs: holding position tab; holding interest tab; holding shares tab; holding transactions tab; and holding ledger tab. Clicking on the Holding Location tab causes the system to display detailed information about the selected asset holding. Data stewards can modify the Asset Classification fields on this tab, but all other fields are read-only. Clicking on the Holding Interest tab causes the system to display interest information for the selected asset. All fields on this tab are read-only.

Clicking on the Holding Shares tab will cause the system to display a list of the shares forming this holding position. The list will include summary information for each share. The share summary list can be sorted for any field by left-clicking on that field's column header. Lot ID and Transaction Type are sorted in ascending order, while all other fields are sorted in descending order. Once the share summary list is sorted, the user can scroll to a desired position. Alternatively, the user can position the cursor in the cell at the top of the list and begin typing the desired value. The system will move to the appropriate entry in this list that most closely matches the entered value. The user must select an item from this list screen before drilling down to the share level. They can then move to a lower level of detail about the selected share by selecting "Share" from the tree structure displayed on this screen.

Clicking on the Holding Transactions tab will cause the system to display a list of all transactions for the selected asset within a user-supplied from/to time period. Like other list screens, the list can be sorted by left-clicking on any field's column header. Transaction types are sorted in ascending order, while all other fields are sorted in descending order. To view detailed information about a specific transaction, the user can enter a transaction ID at the top of the tab (not the from/to date) and click the SHOW button. Alternatively, the user can select a transaction from the list and click the SHOW button or double-click a selected item in the list. In all cases detailed information about the transaction will be displayed.

Clicking on the Holding Ledger tab will cause the system to display a list of all ledger transactions for that holding within a user-supplied from/to time period. The list can be sorted on any field by left-clicking on that field's column header. The debit and credit fields will be sorted in descending order, while all other fields will be sorted in ascending order. To display additional G/L transaction fields, the user can either double-click the selected transaction or select an item from the list and click the SHOW button.

Once the user selects a share at the holding detail level, he can view more detailed information about that share by selecting the share from the detail level tree on the fund management screen. When this level of detail (ie, the lot level) is displayed, summary data for the selected lot is displayed at the top of the screen (in addition to summary data for the fund and holdings shown at the holding level). Users can access the Lot Details tab, Lot Transactions tab, and Lot Ledger tab. Clicking on the Share Details tab will cause the system to display read-only information about the selected share.

Clicking on the Lot Transactions tab will cause the system to display a list of all transactions for the selected lot within a user-provided from/to time period. The list can be sorted on any field by left-clicking on that field's column header. Transaction types are sorted in ascending order, while other fields are sorted in descending order. To view detailed information about a particular transaction, the user can enter a transaction ID at the top of the tab (instead of the from/to dates) and click the SHOW button. Alternatively, the user can select a transaction from the list and click the SHOW button or double-click a selected item in the list.

Clicking on the Lot Ledger tab will cause the system to display a list of all ledger transactions for that lot within a user-supplied from/to time period. The list can be sorted on any field by left-clicking on that field's column header. The debit and credit fields will be sorted in descending order, and all other fields will be sorted in ascending order. To display additional G/L transaction fields, the user double-clicks the selected transaction or selects an item from the list and clicks the SHOW button.

The Transaction Details screen displays detailed information about a transaction. It can be accessed from the fund, holding, and share detail level for periodic and general ledgers. It is displayed independently of the fund maintenance screen and acts as a pop-up screen throughout the system. All data presented is read-only, exported from the source system. This screen will display slightly different fields depending on the transaction type (ie order, repay, and option transactions, etc.).

Referring to FIG. 10, which is a flowchart illustrating fund management, the user enters the main menu screen 100. Referring to FIG. The user selects a fund at box 101 from the data menu. The system reads the database 780 at block 102 and checks the user's access rights. The system displays at terminal 44 a list of funds available to the user at block 103 . The data administrator can close the fund list screen to return to the main menu screen. To add funds to the database, the data administrator clicks the NEW button and the user enters fund data at box 106 on the terminal. The system writes new fund information to database 781 at block 107, making it permanent. The user can select a fund from the list by double-clicking on the item or highlighting it and clicking the SELECT button 108 . At block 109 the General Fund Information tab will be displayed. The user can close the form at block 700 and return to the fund list screen. The user can select at block 704 from the different tabs available at the fund detail level. The user can change general fund data at block 705 . The system writes the changes to the database. At block 701, the system accesses the database and populates tabbed pages with fund-related data.

Figure 11 is a continuation of Figure 10 and shows the processing of the Fund Maintenance screen at all three levels of detail: Fund, Holding and Lot. The first tab presented to the user contains general fund information 125 . Performance tab 111 is available at the fund detail level. The Ledger tab 112 is available at the fund detail level. The Holdings tab 113 is available at the fund detail level. Test tags 114 are available at the fund detail level. Transactions tab 115 is available at the fund detail level. Shareholders tab 116 is available at fund detail level. The user closes the format by clicking the close button 117 and returns to the list of available fund formats. To review holding details, the user selects the particular holding and clicks on "holding" in the detail level tree. The system will read the database 126 and retrieve holding information. The system displays five different tabs at block 710 at the holding detail level. The location tab at box 119 is available at the holding detail level. Interest tags are available at holding detail level. Share tab available at holding detail level. The G/L tab is available at the holding detail level. The Transactions tab is available at the holding detail level. The user can close the format and return to the list of available fund formats by clicking the close button 117 .

The user can view the data at the fund detail level at block 108 (FIG. 10) by clicking on "Fund" in the detail level tree. The user selects a particular share at box 711 and clicks on "Share" in the detail level tree. The system reads the database at block 712 and retrieves share information. At block 713 the Ledger tab, the Lot Detail tab and the Transactions tab are available at the Lot Detail level. The user has the option to go back and retrieve data at the fund or holding detail level by clicking on "Fund" or "Share" in the detail level tree. The user will turn off the format and be returned with a list of available fund formats.

FIG. 12 is a continuation of FIG. 11 and shows the processing after the user selects and views transaction data. The system reads database 127 at block 120 and retrieves transaction information. Different transaction screens are displayed depending on the transaction type selected. The Transaction Details screen shows Buy or Sell Transactions 121 , Dividends and Distributions 122 , Orders and Redemptions 123 and Picks 124 .

The system implements and maintains fund groups, allowing centralized processing of funds on the system. This will serve several purposes. Fund groups simplify fund management by allowing users to run compliance checks and report on a complete logical fund group at once. A fund group can contain an unlimited number of individual member funds. Similarly, a fund can belong to an unlimited number of fund groups. Also, there are some funds that do not belong to any group, and fund groups can be withdrawn into the system without any member funds. While empty fund groups serve no logical purpose, they do not violate any referential integrity since parent records are not required to have children and thus allow fallback to the database.

The system uses a relational table of the database to establish fund groups. All funds on the system will be represented by a unique entry in the funds table. When a fund group is generated, the fund group ID and fund group name are stored as a record in the fund group table. When a fund is associated with a group, records containing the fund group ID and fund group name are stored in the association table. Every time another fund is associated with the group, a new record containing the unique group ID-fund ID combination will be stored in the association table. This entry in the association table groups logical connections into funds. Retrieving all records in the association table for a given group will produce a list of all funds in that group. Similarly, retrieving all records in the association table for a given fund ID will produce a list of all groups that the fund participates in.

The system will use this logical connection in all aspects of processing. Any checking, or tracking, that is available at the fund level can also be available at the group fund level. There is no limit to the number of funds in a group, and any fund may be grouped with any other fund as needed or desired for business purposes. Because funds do not have to participate in a group, the system does not automatically associate funds with fund groups. Creating fund groups and associating funds with fund groups is the responsibility of the data administrator, using the fund group maintenance screen.

Referring to Fig. 13, which is a flowchart illustrating fund group maintenance, the user operates from the main menu 130, selects the data menu at box 131, and then selects the fund group submenu. The system then checks the user access database 134 at block 132 to determine the user's access rights. If the user does not have access rights, an error message is displayed on monitor 44 . Otherwise, the system determines whether the user authorizes updating fund data. If not, then at block 133 the fund data is retrieved from the database and blocked. The fund group is displayed on monitor 44 at block 138 . After reviewing this data, the user then clicks on the CLOSE button 139 to return to the main menu.

If the user has authorization to update, the system retrieves the fund data at block 136 and does not block it. These groups of funds are displayed on the monitor at block 137 . The user can close the form by clicking the CLOSE button 139 and return to the main menu. Alternatively, the user may click on the UPDATE FUND GROUPS button 530. The system determines at block 533 whether the user has made any updates. If not, the system returns and the fund group shown at box 137 is updated. If changes were made, the user can cancel these changes by clicking the CANCEL button 537 . To save these changes, the user clicks on the save button 536 . The system verifies the screen at block 534 and determines at block 539 whether there are any errors. If an error is detected, the system displays an error statement at block 538. If no errors are detected, the user is prompted at block 630 to confirm the change (ie update). The system updates the fund group database 632 at block 631 .

The system provides a graphical user interface, the fund group maintenance screen, to allow the user to easily enter information and instructions. This screen is divided into two sections: Fund Groups and Funds. Fund groups include a list box with all fund groups in the system. The fund part includes two list boxes: the first part displays the funds associated with the currently selected fund group; the second part displays all fund groups withdrawn to the system. The Data Administrator has the ability to add and delete items from this list (in the Fund Group Maintenance screen).

The data administrator can directly click the NEW button under the fund group list box to add fund groups. When the NEW button is clicked a screen will appear prompting the data administrator to enter fund group information. When this information is entered and the ADD button is clicked, the new fund group appears in the fund group list box on the fund group maintenance screen. Data administrators can add funds from the list of available funds to the list of linked funds by selecting a fund (or group of funds) from the list of available funds and clicking the ADD button. Similarly, the Data Administrator can delete items from the list of linked funds by selecting a fund (or group of funds) from the list of linked funds and clicking the REMOVE button. When all desired funds are added or removed from the association the data administrator clicks the SAVE button to make this change permanent.

In the present system, "tables" consist of data that allow codes to be associated with descriptions (short and/or long). The system includes a table maintenance section which allows data administrators to maintain tables in the system. The codes and their descriptions are unique to each table. The system maintains tables for the following data types: Country, General Ledger Account (GL), Issue, Security Type, Source System, and Transaction Code, but may include other types. Other tables currently identified in the system include investment grades, state codes, and holiday dates.

For each country, the country code and its description are maintained in the system. Additionally, new countries and their descriptions can be added and existing records can be modified or deleted. For each general ledger (GL) account, the account is maintained within the system along with a long or short description. Additionally, new GL accounts and their descriptions can be added as well as existing records modified or deleted. For each release, the release code and its long or short description are maintained in the release table. It is possible to add new releases and their descriptions and to modify or delete existing records.

For each security type, a specific security type code and its description are maintained within the system. Additionally, new security type codes and their descriptions can be added and existing records modified or deleted. For each source system, the specific source system code and its description are maintained within the system. Additionally, new source system codes and their descriptions can be added and existing records modified or deleted. For each transaction code, the code and its description are maintained within the system. Additionally, new codes and their descriptions can be added and existing records can be modified or deleted. For each release, the release code and its long or short description are maintained in the release table. It is possible to add new releases and their descriptions and to modify or delete existing records.

The system provides a graphical user interface to allow data administrators to easily enter information. By selecting Table from the File drop-down menu on the main menu, the Data Administrator opens the Table Maintenance screen. The window is divided into 3 parts. The top box shows the table optional input box, containing all the tables maintained by this function in the system. The table selected in this box determines the contents of the remaining two boxes. The middle box presents a list box showing the currently selected table's items. The bottom frame displays item information. Use this box to add, modify, and delete code for a given table. These boxes allow data administrators to create and maintain codes and their descriptions in the system.

At the bottom of the message box there are 3 buttons: NEW, EDIT and DELETE. To add a new code to a table, the data administrator selects a table from the table selectable input box and clicks the NEW button. To edit a code and its description, the data administrator selects a code and clicks the EDIT button. Selecting the DELETE button will delete the code and description that appear in the info window.

If the data administrator clicks the NEW or EDIT button, the SAVE, CANCEL, and DELETE buttons appear. Once the data administrators have finished adding or modifying a code on the table, they select the SAVE button to save their changes to the database, or the CANCEL button to erase any changes made to the message box. The CLODE button will close the table maintenance window and return to the main menu screen.

When first opened, the table selectable input box will display the first table, in this case countries. The list will be populated with the current list of tables maintained by the function. By default, the list is sorted by table name, and the table optional input box only displays the first table. Data administrators can easily locate a table in the table selectable input box, either by using the arrow to indicate the entire drop-down list, or by typing the first character of the code. The selectable input box will jump to this point in the list.

When the table maintenance window is first opened, the first table in the system appears in the table selectable input box, and the table list box is populated with all codes for that table. When the data manager selects another table from the table selectable input box, the table list box is then populated with all the codes for that other table. The title of the table list box contains the name of the currently displayed table.

When the data administrator clicks the NEW button, the information box is populated with the required fields to enter a new code for the table. The title of the infobox will contain the name of the table the data manager is currently working on. If the data administrator selects a code from the table list box, the required fields are populated with the code and description of the record in the table that the data administrator can modify.

Referring to Figures 14 and 14A, which are flow diagrams representing the table maintenance of the system, the user selects TABLES at box 141 from the file menu on the main menu 140. At block 142, the system then reads the appropriate databases in the system, including country table 146, ledger table 147, issue table 148, security type table 149, source system table 540, and transaction code table 541. After reading and generating the list box, the system displays the list maintenance window on the user's workstation at block 143, and the list box is populated with data. In these table list boxes, the user clicks on the table button 144 . The system then displays the table window at block 145 with the list box populated.

Once the table window's list box is populated, the user can review the information and close the format by clicking the close button 741 . Alternatively, the user may click on the NEW button 542 to add information to the table, such as a new code. At block 543, the system determines whether the user has authorization to add new codes. If not, the user returns to the main menu 140 . If the user has appropriate authorization, field codes are initialized at block 544. The user fills in these fields at block 546 . The user may click on the delete button 549 and proceed to the processing of block 745 (discussed below). The user can click Undo 548 so his changes are deleted and the field code is initialized again. The user may click on the save button 547, in which case the system performs the verification at block 641. If verification fails, an error message is generated at block 642 and displayed on monitor 44. If screen verification is passed, the system checks the lock 643 . If the lock check fails, an error message is generated at block 642 and displayed on monitor 44. If the lock check passes, then at block 647 the database is updated.

Once the table window's list box is filled, the user can click on an existing code at box 740 to edit or delete it. If the user selects to edit at block 649, the system determines at block 743 whether the user authorizes editing of the code. If not, the user is returned to the main menu. If the user has the appropriate authorization, the code details are displayed by the system at block 744. The user can then edit the field at block 546 and processing proceeds as described above.

If the user chooses to delete the codes at block 742, the system determines at block 745 whether the user has authorization to edit the codes. If not, the user is returned to the main menu. If the user has proper authorization, the system displays the code details at block 746. The system will prompt the user at block 747 to confirm the deletion. If the user is not authenticated, return him to the main menu. If the user confirms, then check the lock at block 748. If the lock check fails, an error message is generated at block 545 and displayed on monitor 44. If the lock check passes, the code is deleted at block 749.

The system includes a subsystem that provides a user interface that generates and maintains data used by the execution engine to execute the logic defining the compliance tests. Compliance definition data has 3 layers: fields, rules and tests. At the lowest level of the data model are fields. They are the building blocks of reporting systems and represent raw data fields (or columns in a database table). Some fields are entered from the billing system, others are generated internally. Rules are the middle level of the data model, they are logical statements made up of fields, logical operands for selecting records for testing and pass/fail criteria. For example, a statement from a prospectus such as "The portfolio has the ability to invest in the future equal to but not more than 30% of its total assets" would be translated into the following logical rule: Selection Criterion: Security Type set to "Future" , condition: the sum of stock position values<=total assets*30%. Security Type, Security Position Value, Total Assets, and 30% set to Future are fields. The top level of the data model is the test. A test is a combination of rules that are executed sequentially for a given fund or group of funds. Tests allow specifying common rule groups. For example, all domestic funds will check for SEC and IRS compliance. Rather than specifying each SEC and IRS compliance rule separately, two tests (or sets of rules) can be created: SEC compliance and IRS compliance. These tests are then assigned to a fund or group of funds.

Any compliance rule can be expressed in a logical form using logical operands and fields. All information needed for validation rules can be extracted from sources, loaded from external data sources or calculated based on some known data or rules. The operand table illustrating the logic of a rule consists of standard comparison operators (<, <=, =, >, >=, SET, NOT SET), logical operators (AND, OR, and NOT), functions (MIN, MAX, AVERAGE, SUM, COUNT) and fields or data items.

This structure will allow reuse of rules and field definitions, as well as customizing rules for each business situation. Rule bases can be developed. When adding a new rule to an existing fund, or when a new fund is to be added to the system, the fund administrator can review the rule base and retrieve any existing rules that were previously used. This would allow a set of rules to be developed very quickly without having to reprogram the rules for each new application. Each item within this subsystem has a numeric ID, a free-form name, and a description.

Different locations may adopt names that describe the purpose of an item, using different naming conventions. For example, a rule could be named as follows: Future % Limit, Future Holding Limit. The compliance subsystem allows testing (ie, enforcement) of a newly created or modified rule. Only authorized data administrators can change field, rule and test definitions. All changes will be logged to this table.

The system maintains all the definitions in the database tables and uses them to transform the logic currently defined in the tables into applets or rules that can have two or 3 return values: violation, warning and pass, depending on the data. Most data items are defined and maintained by data stewards, so they can be customized for new business environments or transactions. All compliance data is organized into a hierarchical model including fields, rules and tests. Each level consists of the next set of items in the hierarchy, with logic connecting them together. Use parameters to pass data to rules and allow building classes of rules with the same logic but different values. All compliance definition and test functions are accessed through subitems listed in the Compliance submenu on the main menu screen.

To define a complex field, systems, computer servers and computer databases are involved. All defined field types must be requested. Retrieves all records from the field type table. Name and describe all new field types. Verify this information. Looks up the field's name in the field's table and reports it to the user. Save field commands and requests. Insert a row into the fields table. If the save is successful, send the field ID to the database. Enter a field definition for the selected type. The user requests all fields and functions that can be used to build a complex field. The user then defines the complex field as a function of the retrieved fields and functions. Save this new complex field to the complex field definition table.

There are 6 types of fields:

Basic Fields - Fields that are entered from the source system and saved in the database or calculated by the system using a predefined algorithm. Examples of such fields are: saved (eg market value, CUSIP) and calculated (total equity, adjusted equity).

Remapped Fields - Fields used to group values into a single classification. There are two different types of remapped fields: range and numeric. Numeric values can be grouped using range type fields. For example, a due date could be marshaled to the new field due_interval in the following manner:

1 to 30 days => field value "less than 30 days"

30 to 60 days => "from 31 to 60 days", etc.

Table-driven fields can be remapped using values, i.e. countries can be remapped as regions in the following way:

If the country is the United States, Mexico, or Canada, the region will be "North America",

If the country is France or the UK, the region will be "Europe", etc.

Parameter Fields - Fields used to pass data to the rule. An example of a rule with parameters is:

Fund cannot invest in XYZ country

XYZ is the parameter passed to the rule. Parameters allow multiple different variations of the same rule, for example:

Parameter XYZ="Japan" that the fund cannot invest in Japan

The parameter XYZ="Mexico" that the fund cannot invest in Mexico

Constant Field - A field with a constant value. These fields are used internally by the rule definition, for example, a constant field named "33%" could have a numeric value of 33.

Composite Field - A user-defined field that contains a combination of other fields joined together using standard arithmetic and logical operators, for example, a composite field Gain/Loss could be defined as Market Value - Cost.

System Fields - Fields that are hard-coded in the system and used by the public, for example, today's date and user ID.

Each type of field has a corresponding prefix in the table. Fields are generated in the following order: base fields are extracted from the source system, and system fields are calculated from the base fields. Fields of these classes are generated during data entry. Remap fields are updated using base fields, system fields, parameter fields, and remap tables. Composite fields are generated from the definitions and values of all other fields.

The Fields Management screen displays a list of all currently defined fields grouped by category and sorted alphabetically within a group. Summarize and define tabs to cover field details. The summary tag represents general field information, including: ID, name, type, description and history of field maintenance. The definition tag, if the field type is a composite type, indicates two lists of fields (all basic fields, constant fields, remap fields, system fields, and parameter fields) that can be used to generate a composite field. Thus, this screen representation will change according to the type of the current field. Also, it is not used for base fields. The Definition tab for a remapped field indicates the list of fields (all base fields) that should be used as the source for that field, the type of remapped field (range or value) and the remapped table with functionality to add, delete or edit entities.

As discussed elsewhere, "rules" under this system are logical statements representing verbal restrictions derived from fund prospectus SEC or IRS filings. A rule can have only two or three of the following outcomes: Pass, Warning, Violation. Each rule consists of the following 4 parts: input (a list of fields (parameters) used to pass data to the rule - some rules have no parameters); selection criteria (a set of logic statements that identify what should be included in the application of the rule records, i.e. checks); output (a list of fields, optionally indicating ordering and grouping, for fields that should be included in the record if the check fails); and rule definitions (logical statements, specifying the fields using one of two forms Limits for output fields: centralized and absolute; the centralized form defines a numeric limit (threshold) on a two-field ratio, while the absolute rule form defines the value in a field or the value of a field that triggers a violation and/or warning and combination of the value of another field).

A rule definition produces a record that identifies each item of the rule and is used by the system's execution engine to apply defined logic to defined subsets of data and thresholds for checking for warnings and/or violations. The data model is hierarchical and all items, including functions and operators, are referenced through joins in existing tables. The benefit of this approach is that functionality can be extended (eg new functions or rules can be created) without coding in the front-end application.

The Compliance Maintenance screen consists of two frames. The left frame is a list box of all available rules. The box to the right includes details of the selected rule. By clicking a rule in the rule list box, the user can select the rule to view or modify. By clicking the NEW button, the user can create a new rule. The system generates a new unique rule ID. All other information in the rule info box is initialized. When the rule definition is complete, the user clicks the save button to store the new rule or clicks the undo button to cancel the operation.

The right frame contains 5 tabs for rule information. The first tab is the summary tab. It includes general information about the rule, such as: rule type, description and name. The Parameters tab includes information that allows the user to customize the rules for a fund. From this screen, the user can define a list of parameters to be used by the rule. The Rule Maintenance - Selection tab allows the user to define criteria for selecting a subset of the fund data to which the rule applies (ie - use only fixed income security types). Rule Maintenance - The Output Fields tab allows the user to define the fields that will appear on the rule report. This functionality also provides the ability for user-defined sorting and grouping criteria. The Rule Maintenance-Definitions tab (Central Rule Type) allows the user to specify the fields to be used for compliance checking and to define violation and warning thresholds for these fields. The Rule Maintenance - Definitions tab (Absolute Rule Type) allows the user to select fields for a simple absolute rule. (e.g. - does not allow futures in a portfolio). The user can select two fields for a tabular absolute rule (for example, different types of securities have different limits on their maturities).

A test is a combination of rules applicable to a fund or a group of funds formed by a list of connections to the items of the rule list. All rules in a test are independent and have no connections to data or structures in other rules. This data entity is created for the convenience of assigning multiple rules to a fund or group of funds.

The user interface for compliance test maintenance includes several tabs that allow the user to drill down to obtain information about a test. The Summary tab displays the Compliance Test Maintenance screen, which consists of two frames. The left frame is a list box of all available tests. The box to the right includes details of the selected test. By clicking on a test in the test list box, the user can select a test to view or modify. By clicking the NEW button, the user can create a new test. The system creates a new unique test ID. All other fields in the test info box are initialized. When finished defining the test, the user then clicks the SAVE button to store the new test, or the CABCEL button to cancel the operation. The right box contains 3 tabs for test information. The first tab is a summary tab. It includes general information about the test, such as: test description and name.

The second tab is the Rules tab, which allows the user to choose what rules to execute within this test. Two list boxes show the user a list of available rules and rules assigned to the test. The third tab is the History tab, which shows the user when the test was generated and last updated, and who made the modification.

The system includes a compliance engine for applying rules to fund data. A compliance test can be requested in two ways: via the online menu or from the schedule or task queue. Use a combination of stored procedures, and some direct SQL requests to provide database connectivity. In both cases, the engine collects all rules requested from the task queue for the same current/deadline combination. The compliance engine combines the execution of multiple rules to provide high efficiency. Data collection is carried out by calling various relevant databases on the server. All warning/violation checks will be performed on the application server without additional access to the database server.

With particular reference to FIG. 15 , the system receives a compliance check request from a task queue at block 150 or from an online user at block 151 . The engine will gather information on all fields used in the specified set of tests at block 152 and look for similar requests that are pending on task queue 153 . This allows for more efficient operation of the system as all these similar requests can be run together. At block 154, the engine retrieves data from database 156, using a series of stored procedures and builds temporary table 155 with current field balances for use in testing. This process will provide minimal data access as most rules/reports will share the same data. For example, if 20 rules used in several tests were required to reconstruct CUSIP, SEDOL, and asset descriptions for a certain current/deadline combination, the system would only build a list of these values once and then use them for all other rules it. At block 157, the system determines whether the "current" date is the last day of operation for the fund. If the current date is not the last day of business for the fund, the application server will generate a series of requests at block 158 to execute stored procedures to adjust the values of the fields retrieved for the current/closed date combination. In particular, the system will retrieve data from historical logs stored in computer database 159 and modify temporary table 155 accordingly.

After data adjustment, the resulting temporary table will be passed to the application server, which will provide sorting, criterion validation and reporting for all individual rules at block 552. This processing will be completely independent of the database server. The estimated number of rows in the retrieved table is at most 100 to 500. The estimated number of fields is no greater than 50. There is a dedicated connection for each logged-in online user to provide online chat requests. This connection is established by the application server, not the user. Users are not connected to the database server at all. Each application server will maintain a connection condition (pull), with an adjustable number (during fine-tuning) of database server connections. Connection requests are queued by the application server. This will provide an opportunity to execute certain requests in parallel to increase system performance and extract greater capacity from the database server, while dividing data operations between the application and the database server.

The system automatically notifies fund administrators and fund administrators of certain scheduled events, as well as compliance violations and warnings. These notices may be sent by fax, pager or email. Preferably, rule violations are reported in the results report or via an online results tracking feature. A contact name for a fund is entered into the system but a default contact name can be provided. Different contact names (with different delivery methods) can be associated with different events.

The Notifications screen can be accessed from the Task Scheduler or from the Fund Maintenance screen. The Notifications screen includes a list box of available contacts within the system. Data stewards can select a user notification and notification method from the list boxes. The data steward must select at least one notification trigger that causes notification, such as a system event or test result, etc.

When the notification trigger is a compliance test result, the trigger option in the "Why Notify" box will be either a Warning or a Violation. Data stewards can choose one or both of these options. If the notification trigger is another system event, the trigger options for this box in the notification are Success, Failure, or Postpone. Again, data stewards can choose any combination of these options. Once these fields are completed, the data administrator can click CANCEL at any time to delete any changes and refresh the screen data to the beginning of the session.

The Contact Maintenance screen allows the Data Administrator to enter or edit information about contacts. Referring to FIG. 16, which shows a flow diagram of a notification request, the submission of this information can be simplified using drop-down menus or other user interface devices. The database table is read from the contact notification delivery database 162 at block 161 to populate the list box of the screen at block 163 based on the fund ID and test ID. A list box on the monitor 44 screen is populated with this extracted data. When modifying any field, the SAVE button 169 and the CANCEL button 560 are activated. Call the subroutine to move tree items from one list box to another. All fields are verified for accuracy and validity. Data on notification delivery table 564 is modified and stored at block 563 .

Referring to FIG. 17 which shows a contact maintenance flow diagram, at block 171 the database table 173 is read to populate the monitor 44 screen list boxes based on the fund ID and test ID. An on-screen list box is populated at block 172 with the extracted data. The user can click on the CLOSE button 175 to return to the application module 170 . The user can then edit the fields. If the user clicks on the FIELD UPDATE button 176, the system activates the save and undo functions at box 177. If the user clicks on the CANCEL button 179, the system initializes the monitor 44 screen at block 570. If the user clicks on the SAVE button 178, the system verifies at block 571 that the data entered by the user is appropriate. If the data is determined to be incorrect at block 572, the system sends an error message to monitor 44 at block 575, returning to the field update screen. If the system does not determine that the data entered at block 572 is incorrect, then at block 573 the contact database 574 is updated. The system then returns to the field update screen.

Referring to Figure 18 which shows a flow diagram of the notification delivery service, at block 181 the contact database table 182 is read to populate the screen list box based on the fund ID and test ID. The notification method (ie, pager, fax, email) is determined from the database at block 183 . The message is formatted for pager, email or fax at blocks 184, 185 or 186, respectively. The system then contacts another software program at frame 187, such as Lotus Notes, so that an appropriate message is sent by the preferred method at frame 188.

The system allows compliance analysts to select and run a variety of compliance tests, including IRS and SEC tests, and tax and financial reporting. Generate reports and transmit notifications if appropriate. In particular, the following preferred reports are available: Prospectus Test, IRS Dispersion Report, SEC 1940 Act Report and SEC 2a-7 Report. The compliance analyst can specify anchor date periods, ie "now", "to" and "from" dates. The type of report format (print, file or display) and the scheduled time to run the report are specified by the Compliance Analyst. A menu-driven graphical user interface may be provided to assist compliance analysts in entering this data. Insert a record in the task queue indicating when to run the test. A server-based process will run and provide reports upon request.

Referring to Figure 19, the user selects Reports from the main menu. Compliance, IRS and SEC data is read from database 192 at block 191 . The user must then click the SEARCH button 193 to select a fund at box 194 to open the window. The user discovers and selects a fund, then closes the window. The Fund ID, Name and Activity Posting Date are displayed at box 195 at the top of the Compliance Report window, but may not be edited here. The user enters the current date and due date at box 196 . The user then selects the SEC, IRS or Compliance tab 198, 490 or 492, respectively. A list of tests is displayed for each category, and the user selects (or deselects) all tests that he wishes to run at boxes 199, 491 or 493, respectively. The user then selects the means of report delivery at boxes 495, 496 or 497. If the test is scheduled to run "now" by clicking button 498, it is queued immediately at block 590. The system determines at block 593 whether this arrangement is necessary. If not (ie, the test is to run now), the report is scheduled to run immediately at block 594 and placed in queue table 595. If the user has indicated by clicking button 499 that the test is to be run later, then at box 592 a task scheduling dialog is opened. When the user is finished, he closes the compliance report menu and returns to the main menu screen.

The system tracks compliance warnings and violations and stores these (along with response records) from the beginning. The violation tracking subsystem includes five modules: result tracking service; automatic response service; manual violation generation; result tracking user interface; and violation detail display. The Results Tracking Service tracks all automated rule warnings and violations. During compliance test execution, the compliance engine will invoke this service when a fund is in warning or violation for a rule, and all rules for that test have been processed for a fund, whether successful or not. Comply with the Execution Engine to format a message that includes: Fund ID - the unique identifier of the fund being tested; Test ID - the unique identifier of the test being executed; RuleNumber - the unique identifier of the rule in violation ( is a rule violation message); DateTimestamp - time and date of the violation; Description - brief description of the violation; and Type - an indicator (W/V) indicating that this violation is a warning or a violation.

When a rule violation message is received from the compliance engine, it is logged in the database. Information passed from this engine will be stored in the system database along with an indicator indicating whether the source of the violation was this automated engine. When a test completion message is received from the compliance engine, the system will determine the violation status of the test. If any rule within the test is violated, the test is considered to be in violation and a message is formatted and sent to the notification delivery component. If there are no rule violations within the test, then the test is considered not in a violation state, and the automatic response component is requested to turn off any automatic violations.

The auto-response service automatically delivers responses to existing violations. If compliance testing performed on a fund does not result in any violations, the Results Tracking Service will invoke this module to transmit a response to an existing violation, if required. If the fund had a previously unhandled violation for the same test that was automatically generated in the past, the automated response service will transmit a response indicating that the fund is no longer under a violation and turn off the violation indicator. If the unhandled violation was manually generated by a user, the system will transmit a response indicating that the test completed successfully. However, the violation indicator remains on. The service cannot close manually generated violations.

The results tracking user interface provides a graphical interface to allow the user to display and print reports of current and previous violations. A user may delimit a report request by fund, test, rule, violation/warning, indicator, or automatically or manually generate an indicator, and its status. Alternatively, the user can provide a date range for the request. Once the report is displayed, the user can request a hard copy printout. They can also request a detailed display of a single violation. You can also manually open a new violation.

Manual violation generation provides manual transmission of compliance violations or warnings. An authorized user can flag a fund for violating a rule/test. By manually triggering a violation, the violation notification process will be invoked automatically. A graphical user interface will allow the user to manually enter tracking data (noted above). Once a manual violation has been generated, it can only be manually closed by an authorized user. Manual violations will be tracked the same as automatic violations.

The Violation Details display provides details of a single violation. It provides all information on the result tracking UI. Additionally, it provides the time of the violation, what contact was notified, and a list of all rules that caused the violation. Users will be able to watch and add responses to the breach.

Use the Results Tracking screen to view current and historical compliance violations and responses to those violations. This screen consists of 3 parts. The upper left side of the screen is used to quantify the selection criteria that are violated. The user can select a tag for finding, testing or filtering. The upper right side of the screen is used to display the violations that occurred as a result of the selection. The lower portion of the screen includes buttons that allow the user to retrieve a violation, select a violation to view in detail, create a new manually generated violation, or close the screen.

The Funds tab allows the user to select the funds for which violations are to be displayed. By entering a fund ID, partial ID, fund name or partial name, the user will select the SEARCH button to retrieve a list of matching funds from the fund management database. If no ID or name is entered, the entire list of funds is displayed. The user then selects a fund to use for selection. The user can easily scroll through the list by using the scroll bar on the side of the list.

To select a fund, the user moves the cursor over the desired fund and clicks the left mouse button. The fund will be highlighted. If more than one fund is to be selected, the user can click the SELECT ALL button to select all funds in the list, or they can click on the other funds while keeping the CTRL key pressed. The Tests tab allows the user to select the compliance tests for which violations are displayed. By entering a Test ID, Part ID, Test Name or Part Name, the user selects the SEARCH button to retrieve a list of matching tests from the fund management database. If no ID or name is entered, the entire list of tests is displayed. The user then selects a test to be used for selection. The user can scroll through the list by using the scroll bar on the side of the list.

To select a test, the user moves the cursor over the desired test and clicks the left mouse button. The test will be highlighted. If more than one test is to be selected, the user can click the SELECT ALL button to select all tests in the list, or the user can click on other tests while keeping the CTRL key pressed. Use the filter tabs to filter requested violations by their status, violation level, source of origin, or date range. Any and all criteria may be used if the user so decides. A status check box allows the user to request that violations be turned on or off. A level checkbox allows the user to request a violation in Warning or Violation. Establishing checkboxes allows the user to delimit requests by how they are generated, automatically by the system, or manually by the user. Additionally, the user can enter a range of dates for selection.

Once all requested fields are entered, the user clicks the RETRIEVE button. This will trigger a query to the results tracking database. The results of the query are displayed in a table on the upper right side of the screen. The resulting violation table contains the fund ID of the fund in violation, the test ID of the test that failed, the execution date, the current state of the violation (on/off), the level of the violation (warning/violation), and the source of the violation ( manual/automatic). The user selects a violation to detail by placing the cursor on the detail line and double-clicking the left mouse button or clicking the mouse button and clicking the SELECT button at the bottom of the screen. By clicking the NEW button, the user can open the screen to manually create a compliance violation.

Not all compliance checks can be automated. Certain results must be calculated offline by the Compliance Analyst. The system of the present invention allows compliance analysts to input the results of these manual investigations into the system. Any compliance report (or other report) includes not only the automated tests performed by the system, but also manual calculations performed by the compliance analyst.

A user can create a manually generated violation, which automatically loads the current date and time, and the ID of the user who requested the violation. The user provides the fund ID, test ID, and level of violation requested. The user then selects the rule in Violation from the selectable input box. Requires user input for a brief description of the violation. By clicking the SAVE button, this violation data will be stored in the results tracking database. The user can undo the operation by clicking the CANCEL button. To close the screen, the user clicks the CLOSE button.

The Violation Details screen displays detailed information about the violation selected on the Results Tracking screen. The top frame of the screen contains detailed information about the violation. Fund ID, Test ID, date and time of breach, level, status of breach, who generated the breach (or system), and who was notified. Another optional input box allows the user to see all the rules that caused the violation. When a rule is selected, the description is populated to the right of it. The lower half of the screen displays all existing responses to violations in the list box. The table indicates the date and time of the response, who entered the response (or system), whether the response closed the violation, and the text message. The user can enter a new response by clicking the NEW button. This will add a new response on top of the listbox. The system will initialize the date, time, and user. The status column is initialized to open. However, if the user clicks on the field then a dropdown box with on and off values will be generated. This will allow the user to close the violation. When the user clicks on a TEXT field, the field is unprotected to allow data to be entered. Once all the fields are filled, the user can click the SAVE button to store the data. Users can cancel the update by clicking the CANCEL button. By clicking the CLOSE button, the user will close the screen.

Referring to FIG. 20 which illustrates a results tracking flowchart, the results tracking process accepts a formatted message at block 200 from the compliance engine. If the system determines at block 201 that the message is for a rule violation, the system retrieves violation occurrence information from database 205 at block 204 . The message includes: Fund ID, Test ID, Rule Name, Date, Time, and Violation/Warning Indicator. This message is for a test complete and the rule number will be zero. By checking the rule number field, you can decide whether the message is a test completion or a rule violation message. In the event of a rule violation, the process will at block 202 store details of the occurrence of the violation to database 203 . When it is accepted that the test is complete, the process must decide at block 207 whether any rules were violated in the test. This can be determined by accessing the violation occurrence table 205 . Keyword access includes: fund ID, test ID, date, rule number. If a violation is found, it means that the test has failed. In the event of a rule violation, the process will store details of the violation in the database. In the event of a successful test, a message is formatted at block 206 to respond at block 600 to an existing violation of this test for the fund. In the event of a test failure, a message is formatted at block 208 for delivery to the notification delivery module at block 209 .

Referring to Figure 21, this figure shows the automatic response of the system. Using the received formatted message, a violation response message is formatted at block 210 . A violation response occurs on database 212 at block 211. By interpreting the received message, it can be determined whether the message came from the front-end module to generate a response, or from the result tracking module. If an automatic response is received for an automatically generated violation (which was determined at block 213), the module will close the violation. At block 214 the violation occurrence database 215 will be updated. The key fields used are: Fund ID, Test ID, Rule Number, Date, and Source.

Referring to Figure 22, the establishment of a manual violation is illustrated. The user selects the Breach Tracking menu 228 . The screen fields are formatted at block 220 with the data transferred from the results tracking user interface and the system data. The user then inserts any manual violation records at box 229 . If the user clicks on the CANCEL button 223, then at box 227 the initialization screen data is entered for the new user. If the user clicks on the SAVE button 222, the violation occurrence and violation details database records are stored to the database 226 at block 225 using the screen data. The user can close this window by clicking on the CLOSE button 224 .

Referring to Figure 23, beginning at block 230, a violation tracking menu, detailed display of violation information is shown. The system reads the violation response from the system database 232 at block 231 . The keywords are: fund ID, test ID, date. The system reads the violation details from the system database 232 at block 233 . The keywords are: Fund ID, Test ID, Rule Number, and Date. The screen is formatted at block 433 by populating the selectable entry box with violation details and the data tree with violation responses. When the user clicks on the NEW button 234, a new response or detail row is generated in the data tree at block 234, with the current date, time and user ID. Provides update fields for status and text. Clicking on the SAVE button 237 saves the violation response to the system database 232 at block 539 . Clears any new detail rows in the data tree.

The user can cancel the change by clicking the CANCEL button 238 and the system will clear the new response at block 239 . Of course, the user can click the CLOSE button 530 to close this window.

Referring to FIG. 24 , the operation of the user interface for results tracking is illustrated, starting from the main menu 240 . All screen fields are initialized at block 241 . Clicking the NEW button 243 formats the message at box 244 for manual violation handling. At block 245 the window established for the manual violation is opened. Clicking the SEARCHTESTS button 246 retrieves all matching tests from the database 249 at block 247 using the test ID and/or test name. Similarly, the Retrieve SEARCH FUNDS button 440 retrieves all matching funds from the database 243 at block 441 using the fund ID and/or fund name. A test list box is created at block 248 and displayed with the test data. A fund list box is created at block 442 and displayed using the fund data. By clicking the deselect all button 445 at box 446, the system clears all selections from tests/funds (or "unselected"). All tests/funds are selected at box 448 by clicking the select all button 447 . By clicking on the search button 449, the Violation Occurrence List is read at block 540. At block 542 a list of violations is displayed. The keywords used are: Fund ID, Test ID, Date. Creates a violation list box with violation occurrence data. A window for viewing violation details is opened at box 544 by clicking the select button 543 .

The system provides management reports on the difference between the current date and the transferred date value, including general ledger reports and holding reports. The system accepts information from billing sources on a delivery date basis. Actual transaction postings (ie generating holding values from transactions) are not currently performed in the system. The general ledger report represents cash balance data for a fund as it is received by the system on a specified transaction date, and debits and credits for transactions received by the system after the original posting date but before the due date. Sum. Each detail will also represent the requested transaction date balance, including the closing date difference. The user can view transaction details including the difference between the original current date balance and the current date balance including the closing date transaction. Both balance and detail reports can be viewed and printed.

The holding report represents the holding level details of the fund. Each detail includes an asset ID and a description of the asset as well as unit and cost values. Units and fees are expressed as they are when received by the system on a specified transaction date. The report also shows aggregate values (units and fees) for transactions received by the system for transaction dates after the original posting date but before the specified cutoff date, as well as new transaction date values, including additional cutoff date transactions. Users can view and print balance and detail reports. When selecting General Ledger or Holding Management Reports, the user will be asked to provide selection criteria, such as the relevant dates, before the data can be retrieved.

Referring to Figures 25 and 25A, which illustrate generating a ledger report, the user selects a ledger report at box 250 from the main menu. All selection criteria on the screen are initialized at block 251 . By clicking the SEARCH button 254 a fund search window is invoked to allow the user to select a fund for processing at block 255 . Selecting the reproduce button 253 retrieves the ledger data from the database 258 at block 256 . The tables to select are G/L Accounts, G/L Balance, and G/L Transactions. Selection criteria include funds and current and closing dates. Using the ledger balance and ledger transactions, the current balance required for reporting is calculated at block 257 . The balance data is formatted into a spreadsheet on user screen 252 at block 259 . Selecting the DOUBLE CLICK button formats a new spreadsheet at block 654 (FIG. 25A) with transactions for the requested details. The user may select the print buttons 650, 655 or the preview buttons 651, 656, in which case the system will invoke the print function at blocks 653, 658 to either print or display the report. Of course, the user can select the CLOSE button 657 to close the application.

Referring to Figures 26 and 26A, which illustrate the generation of the Holdings Report, the user selects the Holdings Report at box 260 from the main menu. At block 261 the selection criteria on the screen are initialized. Clicking the SEARCH button 264 invokes a fund search window at block 265 to allow the user to select a fund process. Clicking the RETRIEVE button 263 retrieves the stock and transaction data from the database 268 at block 266 . The tables selected are Holdings and Transactions. Selection criteria include funds and current and closing dates. Using the holding balance and holding transactions, the current balance required for this report is calculated at box 267 . The balance data is formatted into a spreadsheet on the user monitor 44 at block 269 . The user can click the PRINT button 659 or the PREVIEW button 699 and the system will invoke the print function at box 658, allowing the holding report to be printed and/or displayed. Users can click on the holding report on the screen to view transactions for a specific holding. In particular, the user double-clicks the holding at frame 698, and the screen is then formatted at frame 664 with transactions. At block 664 a spreadsheet is formatted with transactions for the details of the request. The user can click the PRINT button 655 or the PREVIEW button 656 and the system will invoke the print function at box 658, allowing the holding report to be printed and/or displayed. The user can click the CLOSE button 657 to close the holding report.

The system allows system administrators to generate two system access reports: a report by user and a report by access rights. The report by user will indicate which user IDs have access to specific funds, fund groups, rules, tests, and system functions, and their read/write privileges. Reports by access rights indicate which access rights are available to which user. Data stewards can select a unique subset of user accounts and access rights to report on each conversation. A user event occurs every time a function is started, data is modified, and the user navigates away from the function in the application. A violation occurs whenever a user logs into the application with an incorrect password or attempts to log in to the application after their account has been banned. Any standard software package allows system administrators to preview a report before printing it, providing standard Windows NT environment printing features.

Referring to Figures 27 and 27A, which illustrate the generation of reports by access rights (or activity or user ID), the system administrator selects users to include in the report header row, and which access rights are to be listed in the report detail row. Optionally, system administrators can choose which user IDs access rights are included in the report header row and which user IDs are listed in the report detail row.

To open the system access report screen, the system administrator selects the system access option at block 270 from the reports menu on the main menu screen. This screen allows system administrators flexible reporting and has two tabs: Report by User and Report by Access. Each tab is divided into two windows. The left window includes a list box for specifying the report headers. The right window has two list boxes for defining the report detail rows. On these two tabs, clicking the right mouse button while hovering over an item in a list box will cause a shortcut menu to appear. In a User ID or Category list box, the following options are available: Details, Selected Lists, and Available Lists. Details will display detailed information about the user ID or category. The selected list will list all user IDs or categories currently selected for this report. The available list will list all user IDs that are not currently included in the report. In an Available or Reported list box, clicking the right mouse button while holding over an item in the Available or Reported list box will bring up a shortcut menu with the following options: Add, Clear, Details, Full Zoom Back, fully unfolded. Add and clear functions are described in each section below. Clicking on DETAILS will produce a popup box with detailed information about the selected item. Zooming out fully will zoom out the tree list to the highest detail level. Fully Expand will expand the tree list to its lowest level of detail. System administrators can preview the report before printing by clicking the PREVIEW button. A preview of the printed version of the report will appear. After previewing the report, administrators can print the report on their default printer by clicking the PRINT button. When these buttons are selected, the system tables are read to generate the requested report.

When you first open the System Access screen, you can see the Report by User tab, which indicates the last record processed. The user list box is populated at block 271 with a list of current users from the database 273 . The user database includes information from user profile tables, function tables, fund tables, fund group tables, rule tables, test tables, and access rights tables. The list is sorted by last name by default and is displayed on workstation 44 at block 274 . However, the system administrator can also sort the list by name or user ID by clicking on the appropriate column header. To locate a specific user account, the system administrator can either use the scroll bar, or type the first letter of the user's last name, which will cause the list to jump to names beginning with that letter. System administrators click one or more user accounts in this list box to select as headers for this report.

To select all user accounts, the administrator clicks at box 276 on the top tree list tab "Users". When requesting a new report, the tree list in the Report's Permissions list box is empty. To select a detail row for the report, the system administrator can either double-click on the access rights in the Available Rights list box, or click on each one and then click the ADD button. The selected access rights now appear in the Reported Rights list box. User IDs and access rights groups can be selected for printing or removed from the report by expanding or contracting the relevant tree list. To remove an access right from the Reported Rights list box, the system administrator can either double-click it, or click it and then click the REMOVE button. Assuming the user account has access for the permissions listed, they are reported as detail rows in the report. Specifically, the user clicks on the USER ID button 670, and the details of the user ID are displayed at frame 675. The user can also select the USER ID (HEADER) button 671 or the ACCESS RIGHTS button 672 and the list box is populated accordingly. The user can click the PRINT button 679 and the system will read the access rights database table 273 at block 679 for the report header and detail information. At block 771, a hard copy report is printed.

If the user clicks on the PREVIEW button 678, the system reads the access rights database table 273 at block 770 for the report title and detail information. The report is displayed on monitor 44 at block 772 . The user can then click the PRINT button 773 to print a hard copy report at frame 775. The user may also click the CANCEL button 774 to initialize field labels at block 776 .

The user can click the ACCESS RIGHTS button 673 and the system will display the access rights details at box 679. Alternatively, the user can simply click on the CLOSE FORM button 674 and the system will close the form accordingly.

The Report by Access screen functions similarly to the Report by User screen. By selecting this tab at 277 (in FIG. 27 ), the system administrator can determine which access rights and functions will appear in the header row, and which user IDs will be the detail rows in a given report. The system administrator selects the tab by clicking on it or pressing the underlined letter and the ALT key within the tab label. The Category list box is populated with a list of categories for access rights. The list is sorted alphabetically. The system administrator clicks one or more categories in the list box and selects them as the title of a report. To select all categories, the system administrator clicks on the tree list tab "ID" at the top. When requesting a new report, the tree list in the report's User ID list box is empty. To select detail rows for this report, the system administrator can either double-click a user ID in the Available User IDs list box, or click each one and then click the ADD button. The selected user IDs are now listed in the report's User ID list box and appear in the report as detail rows. User ID groups and access rights can be selected for printing or removed from the report by expanding or contracting the relevant tree list. To remove a user ID from the Reported User IDs list box, the system administrator can either double-click it, or click it and then click the REMOVE button.

A user may select the view report option to view and print a report from a list of previously executed reports. As mentioned above, reports are stored in a database. Provides a menu-driven user interface to allow users to filter and sort reports as desired. Referring to Figure 28, which shows the system generating a list of reports, the user selects VIEW REPORTS 280 from the report menu on the main menu screen. The user clicks the SEARCH button 281 and the system opens a search screen. The user selects a particular fund at box 282 and returns to the Task Queue window. The user then enters in box 283 the report name, the task name, the date and time period the report was performed and the status of the report completion. The user then clicks RETRIEVE button 284 at box 285 to reproduce the report run information. The user may click on a table column header at box 288 to sort the information in the table by that column. The system retrieves report run information from the job queue database table 287 using the retrieval criteria of fund ID, posting date, job name, status, date and time. The user then selects a report row in the report list table and clicks PRINT 581 or VIEW 580 (or double-clicks 289 for a particular report), at which point the report is either printed at frame 584 or displayed at frame 583. The user can close this screen by clicking on the CLOSE button 582. The user can sort the report by clicking the SORT button 288 .

Users can generate reports by activity. Referring to Figures 29 and 29A, the system administrator selects the users to be included in the report header row, the activities to be listed in the report detail row and in the report header row, and the The user ID to list in the report detail line. To open the Activity Reports screen, the system administrator selects the Activity Log option at box 290 from the Reports screen on the Main Menu screen. The list box is then created at block 291 from the database 293 . The activity report screen is displayed at block 294 and is sorted by user activity. However, the system administrator can also sort the list by other parameters by clicking on the appropriate column header. To locate a particular activity, the system administrator can use the scroll bar, or type in the first letter of the activity, which will cause the list to jump to names beginning with that letter. The system administrator clicks on one or more activities in the list box to select a title (or titles) for a report.

To select all activities, the system administrator at box 296 clicks on the top tree list tab "Activities". When requesting a new report, the tree list in the Report's Permissions list box is empty. To select a detail row for this report, the system administrator can either double-click an access right in the Available Rights list box, or click each one and then click the ADD button. The selected access rights now appear in the Reported Rights list box. User ID groups and access rights can be selected for printing or removed from the report by expanding or contracting the relevant tree list. To remove an access right from the Reported Rights list box, the system administrator can either double-click it, or click it and then click the REMOVE button. Assuming the user account has access to the permissions listed, they will receive a detail row in the report. Specifically, the user clicks on the ACTIVITY button 690 and at block 695 the details of the ACTIVITY are displayed. The user can also select the ACTIVITY (HEADER) button 691 or the USER ID button 697 and the list box will be populated accordingly. The user can then click the PRINT button 696 and the system will read the active database table 293 at block 699 for the title and detail information. A hard copy report is printed at box 797.

If the user clicks on the PREVIEW button 698, the system will read the access rights database table 293 at block 790 for the title and detail information. The report is displayed on the monitor 44 at block 792 . The user can then click the PRINT button at box 795 to print a hard copy report. The user can also click the CANCEL button 794 and the field labels will be initialized at block 796 .

On both tabs, clicking the right mouse button while hovering over an item in the list box will cause a shortcut menu to appear. In the ID or Category list box, the following options are available: Details, Selected List, and Available List. Details will display detailed information about the user ID or category. The selected list will list all user IDs or categories currently selected for this report. The available list will list all user IDs that are not currently included in the report. In the Available or Reported list box, clicking the right mouse button and hovering over an item in the Available or Reported list box will bring up a shortcut menu with the following options: Add, Clear, Details, Shrink All, All Expand. Add and clear functions are described in each section below. Clicking on DETAILS will produce a popup box with detailed information about the selected item. Shrink All will shrink the tree listing to its highest level of detail. Expand All will expand the tree list to its lowest level of detail. By clicking the PREVIEW button, the system administrator can preview the report before printing it. After previewing the report, the administrator can print the report on the default printer.

When the activity report screen is first opened, activity by user label 296 can be seen. The user listbox will be populated with the current user. By default the list is sorted by last name. However, the system administrator can also sort the list by name or user ID by clicking on the appropriate column header. To locate a particular account, the user uses the scroll bar, or types the first character of the user's last name, which will cause the list to jump to first names beginning with that character. The system administrator clicks on one or more user accounts in the list box to select the title (or titles) for a report. To select all user accounts, they will click on the top tree list tab "Users". When a new report is requested, the tree list in the report's active list box will be empty. To select detail rows for this report, the system administrator can either double-click on an activity in the Available Activities list box, or click on each one and then click the ADD button. The selected activities now appear in the Reported Activities list box. Assuming the user account invoked the last activities listed, they are reported as detail lines in the report. User ID groups and activities can be selected for printing or removed from the report, by expanding or contracting the relevant tree list and double-clicking on the group, or clicking on it and then clicking the REMOVE button. To remove an activity from the Reported Activities list box, the system administrator can either double-click it, or click it and then click the REMOVE button.

The system provides exception handling. Exceptions can either be handled internally without notifying the user, or can generate user-friendly reports. All exceptions are logged in the database and can be viewed by administrators. There are several types of exceptions: run-time program errors; database access errors; and communication errors. Each component of the system preferably includes its own error monitoring program which provides reporting directly to the user. Of course, exceptions can be monitored by a central exception handling block (EHB). Depending on the severity and type of the problem, the EHB determines the next steps to be taken (ie, notify the user of the error condition, reconnect the application server and resubmit the request). In either case, all exceptions are stored in a local trace file.

The system of the present invention allows users to generate reports customized to specific needs. In one aspect known as "fund management," the system interfaces financial accounting systems for financial institutions and extracts data for tax and reporting and compliance monitoring. This data can be arranged in a report defined by the user or previously created in the system. This report can be designed to meet any reporting needs, including those of reporting agencies, etc., or ad hoc inquiries from a fund manager. These reports can be performed ad hoc (ie, immediately when needed) or scheduled.

Historically, data acquisition and report generation have been time and labor intensive processes. Data can be collected "manually" on a daily basis from a variety of sources and then reviewed over time and rigorously by a team of analysts. For example, if a user needs to know how much a particular fund earned in the last year from dividends and interest on foreign investments, the analyst must go through the entire portfolio, determine which stocks are foreign, and report them in a separate report. Enter data manually. Instead, the system allows users such as compliance analysts to define their own reports. Financial data is easily accessed on-screen, and the system provides unlimited ability to "slice and dice" data at will. With a series of keystrokes, administrators can generate reports by security, industry, country, or other classification.

One difficulty with previous manual systems was not maintaining certain financial data - either long term or not at all. Critical industry data needed to supplement transactional information are simply ignored. This problem becomes even more exponential for companies dealing with multiple clients with diverse needs. The system allows defining financial data associated with a fund. Typically, this is done with world-wide currency managers to build a list of data items that must be entered on the front end. This collection of data is referred to herein as an "audit worksheet". Once the data on the audit worksheet is entered into the system, the system can maintain, tag and capture it to generate financial statements including information pertaining to a particular user.

Fund reporting (another labor and time intensive process) can also be performed using the system. The fund reporting aspect of the system generates annual and quarterly reports for US mutual funds from raw data in the funds' daily reports. The system aggregates all this low-level detail and converts it into a formal ledger record - significantly facilitating the financial statement preparation process. The report writer is able to code and format for direct output to a printer, fax machine, e-mail, computer memory, or other media as desired.

The present system also allows for the automatic generation of any desired financial statements. The user defines the desired financial data and the arrangement of that data for a given report. The system can then search its database, retrieve and arrange the financial data as desired. It will be appreciated that reports may include more complex parameters, such as rules and tests, rather than just core financial data. For example, the system can be used to generate customized portfolio statements, automated audit worksheets, financial statement reclassification (reclass) rules and audit adjustments, non-revenue generating dividends, customizing and typesetting financial statements, and roll forward evidence and analysis Report. In addition, the system can be used to generate reports related to tax reporting, especially in the context of mutual funds, including Wash Sales reports, 988 gain/loss reports, PFIC analysis, deduction analysis for dividend receipts, and GST distributions Reporting, Tax Exempt Income Reporting, Treasury Bill Income and Assets Reporting, State Income Reporting, Foreign Tax Deduction Calculation and Reporting.

The system of the present invention includes aspects directed to a "wash sale" function. The wash-sale aspect of the system identifies possible wash-sale transactions to determine wash-sale status, and develops reporting capabilities for calculating wash-sale deferred amounts and developing wash-sales. A wash sale is any loss from the sale of an asset, where the same asset is acquired during the period beginning 30 days before and ending 30 days after such sale or disposition. The IRS does not allow washout losses because the security holder has the same position it had before the sale transaction. The Ministry of Taxation conducts wash sale analysis at the end of excise and fiscal year of the funds for which tax adjustments are scheduled to be calculated.

Referring to FIG. 30, which is a flowchart illustrating an overview of wash sale processing, the system identifies all possible wash sell transactions at block 300 and determines which transactions are "actual" wash sell transactions. Then at block 301 the user can instruct the system to generate a "possible" wash sale report. Preferably, the wash sale report includes all transactions that meet the logical criteria for possible wash sale identification, such as those well known in the art. Of course, other wash sale criteria may be used for a particular application, as will be understood by those skilled in the art. The user then verifies the results of the system at block 302 and, at block 303, rejects any trades if desired by entering an on-line screen that includes all "possible" wash trades for a particular period. User vetoed wash sale status, possible, actual, or subsequent. A reason column should be included that allows the user to enter a comment for each transaction. The user then generates an "actual" wash sale report (report option) at block 304 which will only include those transactions with an "actual" status. This schedule will calculate the number of actual wash-sell extensions.

The wash sale aspect of the system assists the tax department of a financial institution in preparing a tax provision schedule for a fund by identifying wash sale transactions and calculating deferral amounts. Of course, tax professionals outside the financial institution could be provided with this information and still practice the invention. The system creates an online user interface screen with a reason form for the Veto Wash Sale status. The system includes a batch function to determine the status of wash sales. In addition, the system allows the development of subsequent year wash sale logic. The system creates a wash sale report.

The wash sale aspect of the system provides users with the ability to view reports online. This aspect can be scheduled or executed upon immediate command from the user. As noted above, "current" processing can be used to effectuate transactions and other information entered later. Wash sale reports can be printed, saved electronically, or electronically transmitted as desired.

Currently, it is preferred that a possible wash sale is a sale that satisfies the following criteria: any share of the economic loss is realized in the sale transaction, and the transaction date of the purchase transaction is 30 days before or after the transaction date of the sale share within 30 days. The trade day of the sale does not count towards the 30 day period. For example, if the sale's trade date is 1/1/96, the buy transactions that should be included would be any trades with trade dates on 12/2/95-12/31/95 and 1/2/96 to 1 /31/96 transactions.

For foreign debt securities (assets whose country of origin is not the United States), the system identifies sales of shares that generate a post fork economic loss at the share level (after application of the 988 net adjustment rule). See Figure 31, which illustrates the gain/loss disposition (for each share) of 988 sections of a debt security. Section 988 of the IRS requires that the net gain/loss on the sale of a debt security (i.e. non-equity) denominated in any currency other than the U.S. dollar be divided (i.e. bifurcated) into two components - economic and monetary. The distribution of these two components of gain/loss to either monetary gain/loss (ie, ordinary income for tax purposes) or investment gain/loss (ie, funds for tax purposes) is then determined by applying the "adjustment rule". These adjustment rules should be applied to the gain/loss component associated with each individual share of the security sold. Adjustment rules need to be applied to the gain/loss component of each individual share that includes the sale of the asset. Of course, Section 988 applies only to foreign debt securities. This adjustment rule does not apply to foreign equity shares. The system initially determines the amount of monetary gain or loss and the amount of economic gain or loss on a share basis. As shown in Figure 31, the system then reclassifies the quantities into the appropriate "buckets". References to 988 equal "money" gains/losses. "Ignore 988" means posting the entire amount to economic gain/loss.

Referring to Figure 31, the system determines at block 310 whether there is a total benefit. If so, the system determines at block 311 whether there are foreign exchange gains. If so, the foreign exchange gain is calculated at block 312 and the system determines at block 313 whether the foreign exchange gain is greater than the total gain. If so, all gross gains are designated 988 at block 315 and capital gains are zeroed at block 317. If the foreign exchange return is not greater than the gross return, then at block 316 the 988 return is set equal to the calculated foreign exchange amount, and at block 318 the capital return is determined to be the difference between the gross return and the 988 return.

If there is no total gain, the system determines at block 319 whether there is a foreign exchange gain. If so, at block 710 the portion 988 is ignored. If not, the system calculates the foreign exchange loss at block 711. The system then determines at block 712 whether the foreign exchange loss is greater than the total loss. If so, the system sets the total loss at block 713 to 988 loss (ie ordinary loss) and at block 715 the capital loss to zero. If the foreign exchange loss is not greater than the total loss, the system sets the foreign exchange loss amount to 988 losses at block 714 . The difference between the total loss and the 988 loss is set at block 716 as the capital loss.

If: the number of purchased shares is equal to the number of sold shares and no more purchased shares are available; the current portion of purchased shares is equal to zero on the reporting end date and no more purchased shares are available; or there are no purchased shares or no remaining units of purchased shares remain "Postponed" the loss of a sale, the sale is not a wash sale. However, if a wash sale deferred amount can be calculated as shown in Figure 32 showing the wash sale deferred amount calculation, then the sale is a wash sale. The following assumptions are made when calculating the wash sale deferred quantity: units remaining equal to units purchased before the analyst started and when the reporting date does not affect the calculation (in subsequent year logic, units remaining equal to units purchased before the analyst started).

Referring to FIG. 32, which illustrates the calculation of the wash sale deferred amount, the system begins at block 320 with the first sold share and the first purchased share. The system then determines at block 321 whether the number of shares purchased is the same as the number of shares sold. If so, the system determines at block 324 whether there are additional purchase shares. If not, then at block 325 it is determined that the sale is not a wash sale. The system then determines at block 328 whether there is another sales share. If not, the calculation ends. If so, then at block 721 the sales share and the original purchase share analysis are used and the system returns to block 321 .

If the number of purchased shares and the number of sold shares are not the same at block 321, or if there is another purchased share at block 324, the system determines at block 322 whether there are any purchased share units (greater than zero) left. If not, the system determines at block 323 whether another purchase share is available. If not, the sale was not a wash sale and the calculation is over. If another purchase share is available, the system returns to frame 322.

If at block 322 the remaining units of the purchased share is greater than zero, then at block 326 the system determines whether the remaining units of the purchased share is greater than or equal to the fraction of the sold share. If so, the system determines at block 329 that the wash sale delay amount is equal to the total loss from the sales share. In addition, the remaining units of the purchase share are set equal to the number of purchase share parts, while the remaining part of the sale share is set to zero. The system then determines at block 722 whether there is another sale. If not, the computation ends. If so, the system returns at block 723 to the first available sales share with units remaining, and the system begins the calculation at block 321 again.

If at block 326 the remaining units of the purchased share are less than the portion of the sold share, then at block 327 a washout delay is set equal to the prorated amount (i.e. (buy portion/sale portion*loss from share sale)). The remaining sales share unit is set equal to the portion of the sale that is less than the portion purchased. The system then determines at block 720 whether there is another purchase share whose remaining units are greater than zero. If not, the calculation ends. If so, the system returns to block 326.

For tax year end, the system also performs a washout analysis for transactions that may be considered washouts in the "next" year. Because the purchase can occur 30 days after the sale, logic is needed to identify the "next" year wash sale. The data range for analysis is 30 days before the tax year end date, and 30 days after the tax year end date. For example, if the year end is 11/30, the date range would be 11/1 to 12/30. The system reviews the financial data for any purchases that occurred in the first month after the year-end (i.e. 12/1 to 12/30) and decides whether they can be linked to those that occurred in the last month of the tax year-end that has not been delayed any sale. The system performs wash sale delay analysis as above, except that the current unit is not considered. The system uses the purchased units. The system excludes all sales that occur within the first month of the new fiscal year (eg 12/1 to 12/30).

The system can also perform wash sale analysis for excise year end (as opposed to tax year end). Generally speaking, there are two false-sale analyzes a year, one for the end of the tax year and the other for the end of the excise tax year. These two analyzes are mutually exclusive, which means that transactions can have different statuses when run for each year-end. The system logic for determining wash sale status is the same; except that when calculating the excise year end, the year end is always 10/31 of the year in question. The subsequent year logic discussed above can also be applied to excise year-end periods.

The system can use a batch program to determine the status of the wash sale. Batch programs perform analysis while generating reports. Preferably, the batch program does not veto the wash sale status of transactions that have been vetoed by the user. After applying the veto, the batch (ie report) needs to be re-run. The batch function (report) can be realized through the scheduling function in the system. The reporting date range does not affect the determination of wash sale status or the calculation of wash sale delayed quantities. For example, if the reporting date is 1/1 to 1/31, and if there was a purchase on 1/3 that was used to delay a purchase on 12/20, the logic would be the same, the purchase could be within the month Buy to use again.

On a fund basis, the system provides the user with the ability to review all possible wash trades online for a selected time period. The screen will represent transactions at the lot level. This screen will contain a wash sale status field that allows the user to override the system logic. There are 4 update options available:

1. A blank field indicates that no vetoes have occurred.

2. A "Y" in this field indicates that the transaction is an "actual" wash sale.

3. An "N" in this field indicates that the transaction is not an "actual" wash sale, it is only a possible wash sale.

4. An "S" in this field indicates that the transaction is a subsequent year wash sale.

For each sales share there is a reason column for users to add reviews. Updates to this veto field are kept in a history log, showing the old and new values, reason, effective and past data, and the user ID of the person who changed the state. A filter may be used to allow the user to view all trades (possible), actual wash trades, and trailing year wash trades. This screen should have printing capabilities.

At the fund level, activity reports detail wash-sale transactions. The report uses washout criteria to determine which transactions to include. The report also indicates corresponding "trigger" purchases with sales transactions, that is, those that cause sales that are likely wash-offs. All currency values are reported in U.S. dollars; local currency display is not required. The report should be designed in Microsoft Excel, but of course other software or other display methods can be used to implement the invention. In order to make any changes, the user is required to save the report and make changes outside of the system.

The system offers various reporting options: "Possible" Washout Report (lists all transactions identified by the system as being for a selected period); "Actual" Washout Report (lists only transactions identified as actual ); and a "subsequent year" washout report (listing only transactions identified as subsequent year washout transactions). The report format is the same for these 3 options, except that an additional column indicating washout status will be included when the Possible Washout report is selected.

The system also provides reporting options for 988 messages. When selected, this report (any of the 3 options above) will show any past fork currency losses for all applicable sale transactions. This monetary loss should not be used in any calculations or logic in the report; it is only displayed. When this option is not selected, the column is hidden in the spreadsheet.

The system also provides the user with the option to have the report displayed, stored electronically, transmitted electronically, or printed. Preferably, the data within the report is sorted by CUSIP and then by transaction date. Preferably, the report does not provide subtotals. However, the report can total the short-term latency and long-term latency columns at the end of the report. The system also allows the user to set all date ranges and defaults within the system with a "scheduler" function.

For the purposes of this system, some assumptions are made. If the holding period is less than or equal to one year, the liquidated delayed quantity is considered to be short-term. If the stock period is greater than one year, the wash sale delayed quantity is considered long-term. The actual portion used is equal to or less than the selling share unit or the buying share unit. Of course, the user can define these items as preferences for a given application.

The system can generate and provide a non-income generating asset report for a financial fund. This period report details all current holdings of a fund group or funds that did not declare dividends during the period of the run. Dividend declarations will be determined with reference to the consolidated dividend history. Generally, a financial institution's financial reporting group is required to identify dividend-qualifying assets that do not declare dividends during the 12-month period preceding the end of the period in which financial statements are prepared for publication. This report can be used as a tool to determine which assets issued outstanding dividends during the specified reporting period. Of course, non-revenue generating asset reports may be used for other reasons, as will be understood by those skilled in the art.

To build the non-yielding asset report, the system searches the consolidated dividend records to collect all assets held by a fund veto group that has not paid dividends for a specified period. The system then builds a report, which can be viewed online or printed, detailing the assets found in the search. The report can be generated with different sorting criteria at the fund group or fund level. Preferably, at the fund group level only, the system allows users to verify non-yield generating status and storage at the asset level. The system creates user-modifiable tables detailing the rationale for reporting non-revenue or revenue-generating status for links to non-revenue-generating assets.

The system can also create data extracts that are transmitted to other systems such as RR Donnelley FundWorxxits and are considered non-revenue generating assets. This data extract can be formatted for efficient reception by other such systems.

This report is a current report with an expiration date. All dates can be overwritten by the user. The system creates a default date with the "Start Date" being the day at the end of the previous month minus 364 or 365 days and the "End Date" being the day at the end of the previous month. The "Start Deadline" is the end of the previous month minus 365 or 366 days. The "End Deadline" is set to the last day of the previous month. Of course, these can be adjusted by the user.

Users can choose to run reports for groups of funds or for an individual fund. The report can be sorted by CUSIP, Country/CUSIP or Class/CUSIP. If Country/CUSIP or Class/CUSIP is selected, the report will list and subtotal assets by country or class. Each section will have country or class name as heading.

To generate a non-yielding asset report, the system scans the consolidated dividend records to identify current holdings that did not pay dividends during the specified period. For each asset returned in the search scan, determine the fee share among the oldest active shares of all funds in the fund group. The system displays the transaction date for the oldest active share. If the transaction date exceeds one year from the end date, the system sets the non-revenue generating flag to Y. Update the Reason field with the following message: "Asset held for greater than one year". The non-revenue generating flag is set to Y if the asset type is a security, right, or option. Update the Reason field with the following message: "Not a dividend eligible asset". All data at the asset level is stored with an effective date equal to the end date.

The system allows verification of non-revenue generating assets. User authentication is only allowed on the fund group level. Manually set the non-revenue-generating flag to Y after verifying that the position is a non-revenue-generating one. If the asset is determined to be revenue-generating, leave the field blank. Reasons for non-revenue or benefit-generating status will be selected from the justification table. For reasons that require a date, manually fill in the Payment Date field. All information at the asset level is stored with an effective date equal to the end date.

The system maintains a table of justifications for non-revenue generating securities. These reasons include: assets held for more than one year, not a dividend eligible asset, no data found, last dividend paid, stock split, and IPO. Of course, other reasons may be stored in the table as desired for a particular application.

The system provides current processing capabilities for specific transactions. Current evidence reports capture all current activity for a specified reporting date and balance up to the reporting date. This current evidence report is available for ledger activity as well as fund holding reports. Current evidence reports are used by fund administrators when performing quarterly, half-yearly and year-end reconciliations.

The system builds a current evidence report detailing the following current activities: Ledger Activity (provides 3 levels of detail summary, detail and transaction detail) and holdings (provides summary and detail). The system displays all general ledger accounts with past data balances in the General Ledger Activity Summary report. Displays the past and current balance of the ledger grouped and totaled by account type (assets, liabilities, capital, income, and expenses). The system allows the ability to drill down to various levels of detail. Reports can be generated at the fund and holding level when desired.

The current evidence report is a balanced report. All dates can be overridden by the user at run time but default dates are set such that the reporting (posting) date is the last business day and the report due date is the last business day. The G/L transaction details for each current post should be those reflected in the Fund Activity's Transaction Details screen. The system collects all posting date general ledger balances for the selected reporting date. For each general ledger account, the system collects any currently eligible transactions with a transaction date on or after the report date that were posted to the system by and including a specified cutoff date. If there is no current activity on an account, the system displays zeros in the Debit/Credit fields. Total all debits and credits for each transaction. The system sums and groups posting/current date balances, debits and credits. For each general ledger account, the system displays details by the transaction type associated with each current posting. For each current posting, the system displays the associated transaction. Total Quantity column by transaction type.

The system can generate the current holding summary report. Initially, the system collects all reporting date balance holdings and lists them in CUSIP order. Units, market values and fees are displayed along with the currency selected based on the report. The title for this line item is "Report Date Balance". All current transactions collected in the Detail section of the report are totaled and displayed in Units, Market Value and Fees (based on the currency the report chooses to display). Displays the market value in units based on the security's current price multiplied by the transaction. Preferably, for purchases, if the fund does not hold securities, the system uses the composite vendor price. If no vendor price exists, the system uses the purchase price. This line item is titled "Current Activity" and also has the ability to expand and contract to view details. Subtotals are "Report Date Balance" and "Current Activity" for each holding's line item showing total units, market value, and expenses. The title of this line item is "Current Date Balance". Totals are made for the "Current Date Activity" line item for all holdings under the heading Total Fund "Current Activity" at the end of this report.

The system also generates a current holding transaction detail report. The system collects all current transactions that have a transaction date on or before the report date and a posting date on or after the report date up to and including the cutoff date. The system displays CUSIP, SEDOL, asset description (long) and lists each transaction with transaction date, posting date, transaction type, unit and fee (display currency based on reporting options).

The system provides the current processing capacity for certain selected transactions. The Current Ledger Evidence report details the post date account balance as the current debit/credit totals for transactions with transaction dates on or after the post date and that were posted to the system by a specified cutoff date. This report can be used as a tool for reconciling and validating current ledger transactions.

The system generates evidence detailing current ledger activity. For each general ledger account, the system allows "drilling down" to a detail screen, such as by responding to a user clicking a mouse on the interface screen, which will display all current postings for the selected account. This drill-down capability can be used on any current posting to view details of related transactions. Users can print summary and details as needed. The report can be generated on demand at the fund and holding level. Preferably, the "current" ledger evidence report is a balance report. All dates can be overridden by the user at runtime. The transaction details for each current post should be linked to the transactions in the fund activity.

To build the G/L Evidence report, the system collects all post date GL balances for the selected reporting date. For each general ledger account, the system collects any eligible current transactions that have a transaction date on or after the report date and are posted to the system by a specified cutoff date. Totals all debits and credits for each transaction. The system then sums the balances, debits, and credits for the reporting date. For each general ledger account, the system displays details related to each current posting.

The system provides an automated audit worksheet detailing the general ledger balance for the specified date adjusted for financial statement reclassifications and adjustments. Adjustments to the audit worksheet include predetermined automatic (recurring) reclasses between general ledger accounts and manually entered adjustments. The resulting final adjusted balance is used in the financial statements. As part of preparing financial statements, typically, the financial reporting department of a financial institution adjusts book general ledger account balances without actually modifying the accounting records so that they can be properly reflected in the relevant financial statements. Modifications include system-automatically generated reclassifications, expense adjustments, current activities, and audit and tax adjustments between general ledger accounts. The system's audit worksheets provide an audit trail from book balance to final, financial statement balance. The final adjusted balance resulting from the audit worksheet can be included in the data extraction to an external service, such as the Donnelly FundWorX system, for typesetting, shooting-ready financial statements.

The system creates a rule ("reclassification") maintenance screen to maintain rules for reclassifying balances from one general account to another. The system also creates a manual entry screen. Create an online audit worksheet that reflects applicable manual entries and reclassified entries. The system also creates a printed work order report that includes more detail than viewed online. The system allows users to verify and approve the audit worksheet online. The system maintains a historical log of all modifications to manual entries and reclassification rules. The system also builds a status table for the verification status of the work order and establishes a link to the audit work order. Management reports can also be created. It is also possible to create a data feed for delivery to an external service, such as a FundWorX feed, if desired.

Typically, audit work order reports include the previous month-end date (if the actual month-end falls on a Saturday, Sunday or market holiday, use the previous business day balance). The cut-off date is set to the end of the previous month + 1 (if the actual month-end falls on a Saturday, Sunday or market holiday, use the preceding business day to balance to the next succeeding business day). If the end of the month falls on a Saturday, Sunday or market holiday then? ? ? ? Always displays the end of the month on all reports and screens. Preferably, the work orders are sorted by general ledger GL account number.

To establish a balance, the system creates a menu selection to establish a ledger balance. Collect and sort all ledger balances from the work order date to the due date. The balance can be established more than once (ie using different expiration dates), but only the most recently established balance is stored.

To create the work order, the system applies all manually entered GL balances with effective dates equal to the work order date to stored GL balances and prints them in the "Adjusted Balance" column. All specified reclassification rules are applied to the balance in the "Adjusted Balance" field to create a new "Last GL Balance" field. If the "adjusted balance" is zero, no reclassification rules apply. Then populate the worksheet.

The system allows various changes to the status of audit work orders online. State is maintained in a state table. Status is shown in online viewing. The default state is "on". Every time the user establishes a balance, the status is "On" and the column field displays "Generate Balance". When a modification is made to the worksheet, the status button is disabled until the user saves or undoes the modification. When a work order is modified and saved, subsequent status changes to the "verified", "approved" or "final" status will return to ON and remain in that status until it is changed by the user. The user will be prompted to enter a comment for the change. This comment will be reflected in the status report.

Select states from the state table and access each state based on the network user ID. For example, grant access to the "ON" and "VERIFIED" states for all users. Access to the "Approved" and "Last" states is only granted to users with otherwise appropriate permissions. The system creates a separate tab that displays the status history for an audit work order. The history can be printed from the print button.

Financial institution tax departments may use audit worksheets for informational purposes. Before an audit work order can be provided to the tax collector, it must be approved. Taxation can be marked approved only if the work order is in Approved state. Tax users can view audit worksheets online or print audit worksheets from the reports menu. Tax users only have read access.

If the audit work order is re-executable with a different due date, the status returns to ON, the user is prompted for comments, and the status remains ON until changed by the user. If a modification to the work order is saved following a status change to a verified, approved or final status, the status will return to ON and the user will be prompted to enter a comment for the modification. Status remains on until changed by the user. In order to change status for work orders marked final, blocked and approved for tax, they must be marked before exiting the screen. Watch online shows last. In order to make any subsequent changes, the worksheet must be "unlocked" by an authorized user. The state returns to ON and remains ON until changed by the user.

Reclassification rules generate automatic reclassifications of balances from one general ledger account to another. Reclassification rules are created by designated users in the Reclassification Maintenance/Definitions tab. Create a rule by entering a description of the reclassification, the account number to reclassify from, and the account to reclassify to. Certain rules apply only when certain conditions exist. Conditions are optional and do not need to be used in a rule. If the user tries to create a rule that already exists, a warning message appears and does not allow the user to create the rule: "This reclassification rule already exists." Store the rule for use in the audit worksheet.

Specify reclassification rules in the Reclassification Maintenance/Funds/Fund Groups tab. Rules are specified at the fund veto group or fund level by the named user. Apply fund veto group logic. Fund rejection groups are the same as fund rejection groups in the compliance engine. When a rule is specified at the veto group level it is automatically specified at the fund level for every fund in that group. If the user attempts to specify a rule that is already specified, the following error message appears and the rule is not specified: "Error: Rule already specified." All modifications to reclassification rules are stored in the Rule Maintenance/History tab. History logs can be viewed online, or can be printed from the screen.

The manual entry screen can be accessed from the Audit Work Order screen. Create and delete manual entries on the manual entry screen. For new manual entries, when an account is selected, the account number and associated account description appear in the Debit/Credit box, with an empty field for entering the dollar amount. One of the Save, Close or Undo buttons must be clicked before any new manual entries or existing entries are deleted. Once the save button is clicked the entry is stored. Manually entered items can only be saved when the net quantity is equal to zero. If the condition does not exist, the save button is disabled.

The user will enter the current share using a dummy CCOA. Increases are entered as debits and decreases are entered as credits. The system calculates the difference between the posting date and the current date part. This difference is shown in the Debit/Credit column between the Current Balance and Adjusted Balance columns in the Audit Worksheet. The adjusted share is performed on the last GL balance column. The historical display is linked to the audit work order date. The default start date is the most recent audit work order date, and the default end date is the current system date. User can veto date. History can be viewed online or in print. Work Order is a balance report with current/due date functionality. The default date can be overridden by the user on a scheduled date or at runtime. Preferably, the following default dates are provided for the system: Work Order Date - Last Month End (balance using previous business day if actual Month End is a Saturday, Sunday or market holiday) and Deadline - Month End + 1 (if Actual Month End is a Saturday, Sunday or market holiday, use the preceding business day to balance to the next succeeding business day).

The system provides a fund book entry report that can be used to submit to fund bookkeeping for posting manual entries related to audit and tax adjustments to the bookkeeping system. This report is linked to the audit work order date. The default date is the most recent audit work order date, but this can be overridden by the user. For the specified work order date, the system collects all manually entered items whose effective date is equal to the work order date and whose fund bookkeeping flag is marked as "Y".

The system also provides reclassification rule history reports, that is, activity reports detailing the history of reclassification rules. All default dates can be overridden by the user, but are initially set so that the start date is the most recent work order date and the end date is the current system date. The system collects all rule history for a fund, group of funds, or all rules needed for a specified date range.

The system provides a Reclassification Rules Summary Report, which is a listing of all reclassification rules in the database and the reclassification rules that have been assigned to a fund group or fund. The default date is set as EndDate - The end date of the previous month which can be overridden by the user. The system collects all rules currently assigned to a fund group or fund and all rules in the database.

The system provides a Manual Entry History Report, which is an activity report detailing the manual entry history for a fund for a specified period. The default date is set so that the report date is the most recent audit work order date. Dates can be vetoed by the user. The system collects the history of all manual entries for the requested fund or group of funds.

The system provides information to the financial reporting departments of financial institutions, allowing them to produce typesetting, film-ready financial reports. The last ledger balance for a specified work order date is included in the extract file. Extract files are produced at the request of the Financial Reporting Department. The system creates an ASCII " ^- " delimited file with the fund's final ledger balance on the specified date. Create separate files for each fund. This excerpt can be produced upon request. This extract includes the last adjusted ledger balance on the work order date. Although all default dates can be overridden by the user, they are initially set such that the work order date is the end of the previous month (balanced using the previous business day if the actual month end is a Saturday, Sunday, or market holiday) and the due date is +1 at the end of the previous month (if the actual month end is a Saturday, Sunday or market holiday, use the preceding business day to balance to the next succeeding business day).

Referring to FIG. 33, which is a flowchart illustrating an overview of the processing of PFIC information by the system, the system allows users to process interest-free foreign investment company ("PFIC") securities information to identify PFIC securities on an aggregate basis and on a fund basis. The system calculates tax adjustments for PFIC securities held and PFIC securities sold. Additionally, the system has reporting capabilities for PFICs on a fund-level basis. PFIC analysis is traditionally performed manually. The system can be used to build system-generated reports; thereby reducing the Fund's exposure to human input errors. In addition, automated PFIC functionality allows for more efficient workflow within the user community, as well as the generation of high-quality reports, thus enhancing the level of service provided to customers. The systematic treatment of PFIC is important for tax purposes. PFICs must be analyzed in order to avoid additional taxes and interest on the distribution and disposal of their shares. To avoid this penalty, stockholders can choose to mark up the option on the market. This option allows the shareholder to treat the PFIC as if it had been sold for market value on the last day of the shareholder's fiscal year.

Assets are classified as PFIC if certain criteria regarding income, assets, etc. are met. The Investment Company Institute (ICI) survey classifies possible PFICs in 3 ways: Type I assets are considered PFICs: Type II are possible PFICs, but their status is unclear; Type III represents those PFICs that are now suspected to be but have decided not to be in the past . ICI surveys are generated by various mutual fund syndicates, notifying ICI of the status of their particular syndicate given an asset. Because various investment advisors may reach different conclusions, it may be the case that an asset is listed under categories I, II, III, or as multiple categories (ie, I, III). While some assets are classified as Type I by the ICI investigation of possible PFICs, the final determination of all PFICs suspected of being Type I is performed by the client. There is also a fourth PFIC asset class (IV), which is determined to be a PFIC by other investment advisors who are not ICIs (ie clients). By definition, foreign mutual funds are Type IV PFICs.

Identify foreign mutual funds on the system as: assets marked as RISC or investment companies in asset management, whose original country is not the United States; asset type is mutual funds, whose original country is not the United States. When creating a property on property maintenance that meets the foreign fund criteria, the property should be automatically added to the PFIC table and automatically checked for PFIC IV status.

The system allows input of PFIC information from other information systems of financial institutions. Users have the ability to override PFIC information at the Fund Group and Fund level using the Tracking capability. Build a PFIC list for data research. A report is generated indicating a change in the status of the PFIC. Build a PFIC holdings report. Also build a PFIC sales report. The system creates a PFIC expense tracking schedule and a PFIC expense sales tracking schedule.

Preferably, the financial institution's other information system provides PFIC security information on an annual or semi-annual basis. This information will be received through a spreadsheet program such as Excel or via an Internet file and entered into the system. This information populates a PFIC table in the Table Maintenance menu. The table is then populated with the PFIC checkbox in Asset Maintenance. When a new asset is created in asset maintenance, the PFIC table should be consulted to see if the asset is listed in the table. In this way, the PFIC status can be updated when assets are generated.

Referring to Figure 33, the system enters ICI information at block 330 into its Asset Maintenance section. The asset maintenance information is updated at block 331 with the PFIC status. The system then generates a PFIC list at block 332 . The system then researches the missing data and updates asset maintenance information at box 333 (how is this done?) At box 334, the system generates PFIC fund reports based on PFIC holdings 335, PFIC sales reports 339, PFIC expense tracking-holding information 930, and PFIC Fee Tracker - Sales Info 931. At block 336, the PFIC report is sent to the client for review. Once user authorization is approved, the system is updated as necessary at block 337 . The system's tax provision is updated at block 338 to account for the PFIC adjustment.

Assets listed in other system files of financial institution files can be matched with assets in asset maintenance in 3 ways: sedol can be matched with sedol in asset maintenance; asset description in the file can be specified by "α" of asset maintenance description Searches for matches; entities listed in the file are at the company level; therefore, once a match is found, other equity assets with the same issue code (not debt) will also be considered for the same PFIC category. For example, if XYZ Public Equity Holdings is listed as PFIC I, then all other offerings of XYZ Holdings (i.e. preferred stock) will be considered as PFIC I. Entering will look at the issue code to find all equity assets issued by XYZ Holdings.

Because the final decision on PFIC status is made by investment advisors, a veto function is required at the fund group level and at the fund level. Fund-level vetoes are only available on Tax Manager or higher access. Preferably, only one row of "PFIC" has a yes/no selection. Individual PFIC I, II, III, and IV boxes are not required. The box is empty (zero). User overrules the box with yes or no.

Many assets listed in documents from other departments within the financial institution include missing data. Therefore, the reports preferably help users identify assets with missing data so that research can be done offline, and the system can be updated. Two such reports can be particularly useful: PFIC List (prints the entire file for an asset (can be done outside the system)) and Exceptions Report (prints out a list of securities that were not entered into the system because no matching asset was found in Asset Maintenance) . These reports should be sorted by PFIC status and then alphabetically by asset description. Of course, any sort order can be used, depending on the particular application.

The system allows the generation of asset maintenance studies. From the asset maintenance file, the user can generate the following 4 reports: The PFIC List report prints the entire list of assets with PFIC status, sorted by category and then alphabetically by asset description. The PFIC I Only report lists assets that are PFIC I only in Asset Maintenance, sorted alphabetically by asset description. The PFIC IV Only report lists assets that are PFIC IV only in Asset Maintenance, sorted alphabetically by asset description. The PFIC I and IV only report lists assets that are PFIC I and IV in Asset Maintenance, sorted alphabetically by asset description.

The system allows the generation of a PFIC Status Report - Asset Maintenance Level, which indicates changes made to the PFIC status. This report can be run for a period of time and includes all modifications and new assets opened during that period and given a PFIC status. The report is first sorted by modification, then opened by asset, and then, within these categories, alphabetically by description. Provides an option to sort by posting date (latest to oldest). A second sort can be alphabetical by description.

The system also provides a fund group level report that shows the difference between PFIC status in asset maintenance and fund maintenance (indicating that the initial default status in fund group maintenance has changed). Preferably, the report only mentions Fund Group Maintenance for those assets that have been updated (ie this field is not empty). The difference in PFIC status will be, for example, if asset maintenance status is I and fund group maintenance is N. In addition, the report should also indicate the assets that have been marked as PFIC in the fund group maintenance but have no PFIC status in the asset maintenance (that is, the asset maintenance is "" and the fund group maintenance is "Y"). The report should have the ability to run for a selected day. The report should be sorted first by asset maintenance PFIC category, then alphabetically by description (empty asset maintenance categories should be listed last). There should also be an option to sort by posting date (most recent to oldest). Second sorting should be alphabetical by description.

The system also provides a fund level status report which shows the difference between the fund level PFIC status and one of the fund group level or asset maintenance. This is especially useful because vetoes can be applied at the fund level. The report compares the status at the fund level to determine if the PFIC status is different than at the asset maintenance or fund group level (whether the fund is a rejected fund group). The report should be sorted first by asset maintenance PFIC category, then alphabetically by description (empty asset maintenance categories should be listed last). There should also be an option to sort by posting date (most recent to oldest). Second sorting should be alphabetical by description.

The system provides a possible PFIC holdings report detailing all current holdings at the lot level for all assets with PFIC status. The PFIC status used for this report should come from the asset maintenance level and the veto status should not be used. All currency quantities are expressed in USD (local currency does not need to be displayed). The title of the report is "Possible PFIC Holdings Report - ICI Category". The PFIC Holdings report should have print, file, and display options at both the fund level and fund group level. For the current report, the market value must be calculated. This calculation equals the share multiplied by the market price at the reporting date. For unrealized gains/losses, the calculation is equal to the difference between market value and cost. The report should subtotal shares, costs, market values, and unrealized gains/losses for assets with more than one share. Totals should not appear on the report.

The system provides a Probable PFIC Sales Report detailing possible sales transactions of PFIC securities during a specified period. The report includes all assets with PFIC status, ie foreign mutual funds. The PFIC status used for this report should be at asset maintenance level, and the veto status should not be used. For sales transactions that were canceled during the reporting period, neither the original transaction nor the cancellation transaction is included. A reverse transaction should be included if it occurs outside the reporting period, and the reverse transaction should appear in the next reporting period. A reverse transaction has the opposite sign to a sale transaction. All currency amounts should be expressed in USD (local currency does not need to be displayed). This report will print all sales transactions for a specified period and is titled "Possible PFIC Sales Report - ICI Category".

The system can calculate realized gain/loss characteristics. However, the logic for determining the realized gain/loss characteristics must match the calculations from the source system. The report should subtotal the shares, costs, benefits and realized gains/losses for each asset with more than one share. Totals should not appear on the report.

Definitions of PFIC are established by financial institutions. The most current PFIC state should be used. If an asset is considered a non-PFIC asset and then changes to a PFIC asset, the asset should be considered a PFIC asset, even for historical purposes. The user runs the expense tracking schedule from the security's original purchase date, and the system needs to re-establish the expense tracking schedule from that date to the current date. Modification of PFIC status in Asset Maintenance and Fund Group Maintenance should be allowed. The "true" PFIC status (from ICI) will be updated in Asset Maintenance and displayed in the Probable PFIC Holdings Report and Probable PFIC Sales Report. Standard rejection logic is used when deciding whether a security is a PFIC. The report should first look at the fund level - whether there is no PFIC status, then look at the fund group level - whether there is no status, and then look at the asset maintenance level.

Figure 34 is a flowchart illustrating the PFIC fee tracking holding schedule. For all shares of PFIC assets deemed to be held by a fund, an adjusted fee basis must be calculated for tax purposes. This adjusted fee basis incorporates market value added into the fee. This adjusted fee basis is rolled forward each year until the share is sold. On disposal, use the adjusted expense basis to determine the tax realized gain/loss. A fee tracking schedule is an activity report detailing the adjusted fee basis for each share. A share enters the schedule for the year in which it was earned. The share remains on the schedule for each subsequent year in which it is maintained. The share is cleared from the schedule in the year it was sold; however, data from the previous year should remain in the schedule. Thus, an asset will remain on the schedule until the year in which the last share held is sold. All currency amounts are in US dollars. If an asset changes from non-PFIC status to PFIC status (defined in the classification logic), the tracking schedule must be re-established for all years that the asset was held, when the report is run by the user. Expense Tracking Holdings reports should be designed for a spreadsheet program, such as Microsoft Excel. Users should be able to see a list of holdings at the fund level, and by double-clicking or selecting a holding, should be able to "drill down" and see the entire expense tracking schedule. This screen should have printing capabilities. There should be no update functionality available. To make changes to the data, the user is required to save the file as a spreadsheet and make changes outside the system.

Referring to FIG. 34, which illustrates a flow diagram of the PFIC expense tracking schedule, the system determines at block 340 whether the asset is considered a PFIC. If not, the computation ends. If it is a PFIC, the system determines at block 341 whether the asset was held within the previous fiscal year. If not, then a new expense tracking schedule is created at block 342 . If the asset was held in the last year, the system determines at block 344 whether the share was held in the previous fiscal year. If not, then at block 345 a new share is added to the existing expense tracking schedule. If the share was held in the last year, the system determines at block 346 whether there has been a partial sale of the share in the current fiscal year. If not, the system calculates an adjusted fee basis for the current fiscal year at block 347 . If there are partial sales, the system prorates the year's figure for the remaining share at box 348 . The system then calculates an adjusted fee basis for the current fiscal year at block 349 .

Users have two reporting options available. In the first, the user can run the entire report (including in the fiscal or excise year) or run the report for a specified asset identifier. In the second, the user can set the value for fiscal year end (the schedule will reflect holdings and the value of the fiscal year end) excise tax year end (the schedule will reflect holdings at the end of the previous fiscal year, but reflect expenses, adjusted forward expenses, and market value at the end of the excise tax year) to run a report. The report should always represent the entire history of the asset. The term "current fiscal year" is equal to the year in which the analysis was completed; or the last fiscal year end date prior to the current posting date. For example, if the posting date is 5/5/95 and the fund's fiscal year end is March, the current fiscal year is 3/31/95.

If a unit was fully sold (either through a single sale transaction or multiple transactions during the year) during the current fiscal year in which the calculation is being made, then "Complete Sale" should appear in this column. "Partial Sale" appears in this column if a share was partially sold during the current fiscal year. Leave this column blank if no activity has occurred on the share during the current fiscal year. Status should remain on the schedule for previous years.

The assessment of the market is equal to the difference between the market value and one of: a.) the original fee, if the share was purchased during the current year; b.) the forward-adjusted fee, if the share was purchased in the previous held within a fiscal year. If a portion of the sale of the share occurs during the current fiscal year, both the original charge and the charge adjusted forward from the previous fiscal year must be prorated for the remaining share in the current fiscal year. Appraisal of the market is only applied when the market is value-added (market value > cost). Thus, if there is a market depreciation, the Rating field for the market should be filled with "-".

The termination adjustment fee is equal to the market value or: a.) the original fee, if the share was purchased during the current year; b.) the forward adjustment fee, if the share was held in the previous fiscal year, whichever is higher one of. The cost adjusted forward is equal to the cost of the share adjusted from the end of the previous financial year. If the share has not been sold within the previous year, then this column should be populated with "N/A". If a partial sale of the share occurs during the current fiscal year, the charge adjusted forward from the previous fiscal year must be prorated for the remaining portion during the current fiscal year.

When run for all assets the report should be sorted alphabetically by asset description. Within each asset, the detailed schedule should be sorted by fiscal year end, and within each fiscal year end, by share number. The report should subtotal for each fiscal year, tranche, original cost, forward adjusted cost, market value, PFIC assessment to market, and termination adjusted cost for assets with more than one tranche. Totals are not required for this asset or this report.

The system also allows the calculation of an adjusted fee basis for PFIC for the Excise Period (10/31/XX) ("PFIC Fee Tracker-Holding-Excise"). In order for an asset to appear on the excise year-end schedule, it must have been treated as a PFIC in a previous financial year. If an asset is held at the end of the last fiscal year, it appears on the excise tax report unless it is sold before that excise year end date. If additional shares of the property were purchased, these new shares will be included in the excise tax report. Forward adjusted charges will be equal to the value at the end of the previous fiscal year (10/31/94). The market value will be equal to the value on the excise date (10/31/95). The logic for calculating the fee for PFIC assessment and termination adjustments to the market is the same as for the PFIC Fee Tracker - Holding Report, except that references to "Fiscal Year" will be replaced with "Excise Year".

Referring to Figure 34, the system provides a PFIC Fee Tracking - Sales Schedule report. When a share of an asset that is considered a PFIC is sold, the tax gain/loss is calculated using the adjusted expense basis. The expense sales tracking schedule details the calculations for these transactions. All currency quantities are in US dollars. If an asset changes from non-PFIC status to PFIC status (defined in the classification logic) when the report is run by the user, the tracking schedule must be re-established for all years that the asset was held. Expense Tracking Sales Reports should be designed for a spreadsheet program, such as Microsoft Excel. Users should be able to see a list of PFIC stocks that have had sales transactions at the fund level. By double clicking or selecting a cusip, the user should be able to "drill down" and see the entire expense tracking sales calendar. This screen should have printing capabilities. There should be no update function. In order to make changes to the date, the user is required to save the file as an Excel spreadsheet and make the changes outside of the system.

In this case, the user has two reporting options available. First, the user can run the entire report, which includes all transactions for the specified period, or run the report for a specified sedol. In the second reporting option, the user can run the report for Fiscal Year End (the report will include sales posted in the last fiscal year) or run the report for Excise Year End (the report will include sales posted in the last Excise Year) . However, the report should have the ability to run for any date range.

The forward adjusted charge always equals the forward adjusted charge calculated from the end of the previous fiscal year. This figure is not updated for the full fiscal year. If the transaction date of the sale is equal to the fiscal year end date then the forward adjusted charge from the previous year end is used. If the share was not held in the previous financial year, the original fee is used. This way, there will be no tax gain/loss as it will be equal to book gain/loss.

The forward adjusted charge is always equal to the forward adjusted charge calculated from the end of the previous excise tax year. This figure is not updated throughout the excise year. If the transaction date of the sale is equal to the excise tax year-end date then the forward-adjusted charge from the previous year-end is used. If the share was not held in the previous excise tax year, the original charge is used. This way, there will be no tax gain/loss as it will be equal to book gain/loss.

The gain or loss is considered short-term if the number of days from the transaction date of the purchase date to the transaction date of the sale is 1 year or less. The gain or loss is considered long-term if the number of days from the transaction date of the purchase date of the share to the transaction date of the sale is greater than 1 year. Tax adjustment equals tax gain/loss minus book gain/loss. By definition, this will always be a negative number. For each asset, the report should subtotal tranche, original expense, forward adjusted expense, gain, short-term and long-term tax gain/loss, short-term and long-term book gain/loss, and transaction of more than one tranche tax adjustment.

The present invention has been described in terms of its preferred embodiments, which are presented for purposes of illustration and not limitation. The present invention has several advantages over the prior art, including that it can be flexibly applied to various funds, that it can be easily modified to meet a fund's particular needs, and that it can quickly run the model with changing rules. The system provides compliance testing in an extremely short period of time while providing more accurate test results than known in the prior art. Improved compliance testing allows early and automatic warnings to fund managers and compliance analysts, thereby reducing the likelihood of more serious compliance violations. It should be understood that within the scope of the invention, modifications, changes and features may be effected by those skilled in the art, giving the benefit of the disclosure.

Claims (100)

1. A compliance system for funds consisting of collections of financial securities governed by a predetermined set of investment rules relating to those financial securities, the system comprising: computer memory devices used to store data; A computer processor operably connected to the computer memory device, the computer processor comprising: devices for storing investment rules; a facility for storing fund information identifying the financial securities comprising the fund, the quantity of each financial security and the value of each financial security; Equipment for receiving transaction information regarding transactions in financial securities comprising the Fund; equipment for receiving value information corresponding to the value of these financial instruments during a given period of time; means for modifying fund information based at least in part on at least one of the value information or transaction information; equipment for comparing fund information with investment rules; and A device for generating a signal based at least in part on the comparison. 2. A method for a financial institution to monitor compliance of a client financial fund comprising a collection of financial securities monitored by a compliance analyst and controlled by a fund manager using a predetermined set of investment rules, the method comprising: Storing investment rules on the computer of the financial institution; storing fund information including the identity of the financial securities, including the fund, the quantity of each financial security comprising the fund, and the value of each financial security comprising the fund; receive transactional information regarding transactions in the financial securities comprising the Fund; receiving value information corresponding to the value of these financial instruments at a given time; modifying fund information based at least in part on at least one of the value information or transaction information; Compare fund information and investment rules; generating a signal based at least in part on the comparison; and A compliance analyst is sent a message based at least in part on the signal. 3. The method of claim 2, wherein the signal is generated based on a violation of an investment rule, wherein said message is a warning to a compliance analyst to provide selected information. 4. The method of claim 3, further comprising providing, in response to a query from the analyst, the compliance analyst with detailed information regarding the particular investment rule that was violated and the fund information regarding the violation. 5. The method of claim 4, wherein an analyst evaluates said details and contacts a client fund administrator to report the breach. 6. The method of claim 2, wherein said signal is based on a comparison made at a first point in time, the method additionally comprising receiving additional transaction information or value information after the first point in time, adjusting in part based on the additional transaction information the fund information, receiving additional value information responsive to the value of the financial security at a second point in time, adjusting the fund information based in part on the additional value information, comparing the adjusted fund information to investment rules, and generating an adjusted fund information based at least in part on the comparison. , and send a warning to compliance analysts if there is a violation of the investment rules. 7. The method of claim 6, further comprising storing information regarding receipt of additional information and adjustments to funding information. 8. A system for performing compliance testing on a financial fund comprising a variety of financial securities that are purchased and sold under the direction of a fund manager, the system comprising: equipment for receiving financial data relating to the financial securities comprising the financial fund; means for generating investment rules as logical statements of the financial data, wherein the investment rules describe the activities permitted by the fund manager; A device for storing investment rules; A device that produces tests that include at least one rule; A device that applies test rules to financial data to determine whether there is a potential violation of any investment rules; and Report equipment that may violate investment rules. 9. The system of claim 8, wherein the means for receiving financial data is a computer system controlled by a financial institution. 10. The system of claim 9, wherein the financial data is received at least in part from an information service provider external to the financial institution. 11. The system of claim 9, wherein the computer system is controlled by a compliance department of the financial institution and the financial data is received at least in part from another department of the financial institution. 12. The system of claim 11, wherein the financial data is received at least in part via the electronic device. 13. The system of claim 12, wherein the financial data is received at least in part via a global communication network. 14. The system of claim 9, further comprising means for the financial institution to receive from the fund manager data corresponding to sales and purchases of financial securities comprising the fund. 15. The system of claim 14, wherein the financial institution receives the transaction data through its regulatory department, which transmits the transaction data to the financial institution's compliance department. 16. The system of claim 8, wherein the means for storing investment rules comprises means for storing investment rules in a computer library. 17. The system of claim 16, wherein the means for generating investment rules includes searching a computer library for previously drafted rules. 18. The system of claim 17, wherein the means for storing investment rules comprises means for copying at least one investment rule from a computer library. 19. The system of claim 16, wherein the means for generating tests comprises means for copying rules from a computer library. 20. The system of claim 9, further comprising means for generating financial data illustrating the application of the test and a display for displaying the report. 21. The system of claim 20, further comprising survey reporting based means. 22. The system of claim 21, wherein the display is a computer workstation and the report is electronically submitted on the display, wherein the means for investigating the report comprises a user input device operatively connected to the workstation. 23. A method of performing compliance testing on a financial fund, wherein the financial fund includes a plurality of financial securities that are purchased and sold at the direction of a fund manager, the method comprising: receive financial data about the financial securities comprising the financial fund; store the financial data; generating investment rules that are logical statements of the financial data, wherein the investment rules describe the activities permitted for the fund manager; storage investment rules; generating a test comprising at least one investment rule; apply the test to stored financial data to determine whether any investment rules are likely to be violated; and Report possible violations of investment rules. 24. The method of claim 23, wherein the financial data is received by a computer controlled by the financial institution. 25. The method of claim 24, wherein the financial data is received at least in part from an information service provider external to the financial institution. 26. The method of claim 25, wherein the computer is controlled by a compliance department of the financial institution and the financial data is received at least in part from another department of the financial institution. 27. The method of claim 26, wherein the financial data is received at least in part via an electronic device. 28. The method of claim 27, wherein the financial data is received at least in part via a global communications network. 29. The method of claim 24, further comprising receiving, by the financial institution, transaction data corresponding to sales and purchases of financial securities comprising the fund from the fund manager. 30. The method of claim 28, wherein the financial institution receives the transaction data through its regulatory department, which transmits the transaction data to the financial institution's compliance department. 31. The method of claim 25, wherein storing the investment rules includes storing the investment rules in a computer library. 32. The method of claim 31, wherein generating investment rules includes searching the computer library for previously drafted rules. 33. The method of claim 32, wherein storing investment rules includes copying at least one investment rule from a computer library. 34. The method of claim 31, wherein generating a test includes copying a rule from the library. 35. The method of claim 24, further comprising generating a report describing application of the test to financial data and displaying the report on a display. 36. The method of claim 35, further comprising investigating an agent of the financial institution on which the report is based. 37. The method of claim 36, wherein said report is submitted electronically to a computer workstation, and wherein surveying the report includes clicking on fields of interest to the agent on the display using an input device operatively connected to the workstation. 38. The method of claim 24, wherein the investment rules are generated from a dialogue between a fund manager and an employee of the financial institution. 39. The method of claim 24, wherein investment rules are issued by a government agency. 40. The method of claim 24, wherein the investment rules are issued by the sponsor of the financial fund. 41. The method of claim 24, wherein the possible violation is reported to an employee of the financial institution via the computer workstation. 42. The method of claim 24, wherein the possible violation is reported to an employee of the financial institution by facsimile machine. 43. The method of claim 24, wherein the possible violation is reported to an employee of the financial institution via a pager. 44. The method of claim 24, wherein the possible violation is reported to an employee of the financial institution via electronic mail. 45. The method of claim 24, wherein the possible violation is reported to the fund administrator via the computer workstation. 46. The method of claim 24, wherein the possible violation is reported to the fund administrator by facsimile machine. 47. The method of claim 24, wherein the possible violation is reported to the fund manager via a pager. 48. The method of claim 24, wherein possible violations are reported to fund administrators by electronic mail. 49. The method of claim 24, wherein the fund manager can access the report through a global communication network. 50. The method of claim 24, further comprising cooperating with the computer system to receive financial data and provide reports. 51. The method of claim 24, further comprising modifying investment rules, applying the modified investment rules to financial data, and providing a modified report. 52. The method of claim 24, further comprising the steps of monitoring the method, retrying unsuccessful steps, and reporting the status of those steps to employees of the financial institution. 53. The method of claim 24, further comprising modifying the financial data and then applying the test to the modified data. 54. A system for performing financial analysis on a financial fund comprising a plurality of financial securities that are purchased and sold at the direction of a fund manager, the financial fund having a defined permissive relationship of the financial securities comprising the financial fund Defined, the system includes: Equipment for receiving financial data, which can be expressed numerically and are related to the financial securities constituting the financial fund; means for generating an investment rule as a logical statement of financial data, wherein the investment rule states the definition of the financial fund; A device for storing investment rules; generating equipment for testing comprising at least one investment rule; A device that applies the test to financial data to determine whether any investment rules may be violated; and The device reporting the decision. 55. A method of performing financial analysis on a financial fund, wherein the financial fund is comprised of a plurality of financial securities that are purchased and sold under the direction of a fund manager, the financial fund having a definition of the financial securities within the financial fund The definition of the allowed relationship, the method includes: receiving financial data that can be expressed numerically and are about financial securities in the financial fund; generating an investment rule as a logical statement of financial data, wherein the investment rule states the definition of the financial fund; storing investment rules in a computer database; generating a test comprising at least one investment rule; Apply this test to financial data to determine whether any investment rules may be violated; Report the decision. 56. A method of performing financial analysis on a financial fund, wherein the financial fund is comprised of a plurality of financial securities that are purchased and sold under the direction of a fund manager, the financial fund having defined financial Definition of permissible relationships for securities in which financial analysis is performed by a financial institution with regulatory and compliance departments, the method includes: receiving financial data, which may be expressed in numerical values and are related to financial securities in the financial fund, received by a computer controlled by a financial institution; wherein the financial data is received at least in part from an information service provider external to the financial institution and at least in part via electronic media; receiving transaction data from the fund manager corresponding to the sale and purchase of financial securities within the fund; Among them, the financial institution receives transaction data through its supervision department, and the supervision department transmits the data to its compliance department; storing transaction data and financial data corresponding to a selected time period; generating investment rules as logical statements of financial data, wherein the investment rules state the definition of a financial fund; storing investment rules in a computer database; generating a test comprising at least one investment rule; Apply tests to financial data to determine whether any investment rules may have been violated during that time period; generate reports illustrating the application of tests to financial data; and Display the report. 57. The method of claim 56, wherein the financial data is received at least in part via a global communications network. 58. The method of claim 56, wherein the report is delivered via a global communication network. 59. The method of claim 58, wherein storing the investment rules includes storing the investment rules in a computer library. 60. The method of claim 59, wherein generating investment rules includes searching a computer library for previously drafted rules. 61. The method of claim 58, wherein the report is represented electronically on the display. 62. A method for a financial institution of monitoring client financial funds comprising a collection of financial securities monitored by a compliance analyst and controlled by client fund administrators according to a predetermined set of parameters, the method comprising: storage of parameters on the computer of the financial institution; storing fund information including the identity of the financial securities comprising the fund, the quantity of each financial security comprising the fund, and the value of each financial security comprising the fund; receive updates regarding changes in financial information; adjust fund information in part based on the updated information; Compare fund information and parameters; generating a signal based at least in part on the comparison; and A message is sent to the compliance analyst based at least in part on the signal. 63. The method of claim 62, wherein the parameter is issued by a controlling agency, and wherein the message is a tax report on the fund. 64. The method of claim 62, wherein the parameters are investment guidelines pointing to fund information and updating information. 65. A method of monitoring and generating financial reports for a client financial fund for a financial institution, the client financial fund comprising a collection of financial securities and controlled by a client fund administrator, the method comprising: storing on a computer of the financial institution fund information including the identity of the financial securities comprising the fund, the quantity of each financial security comprising the fund, and the value of each financial security comprising the fund; Storing on the computer of the financial institution the definition of parameters corresponding to the control data required for the financial fund; receive updates regarding changes in financial information; adjust fund information in part based on the updated information; Retrieve financial data corresponding to parameter definitions from adjusted fund information and update information; generate a signal based at least in part on the retrieved financial data; and A message is sent to the user based at least in part on the signal. 66. The method of claim 65, wherein the parameter is issued by a controlling agency, and wherein the message is a tax report on the fund. 67. The method of claim 65, wherein the parameter definitions are investment guidelines pointing to fund information and updating information. 68. A computer program having a plurality of program steps executed on a computer to implement and control a compliance system for a fund comprising a collection of financial securities governed by a set of predetermined investment rules relating to the financial securities control, the program includes: means for establishing and storing investment rules; means for storing fund information identifying the financial securities comprising the fund, the quantity of each financial security and the value of each financial security; means for receiving transaction information regarding transactions in financial securities comprising the fund; means for receiving value information corresponding to the value of the financial instrument during a given period of time; means for modifying fund information based at least in part on at least one of value information or transaction information; means of comparing fund information and investment rules; means for generating a signal based at least in part on the comparison. 69. A compliance system for a fund consisting of a collection of financial securities governed by a predetermined set of investment rules relating to the financial securities, the system comprising: Computer processors having and executing programs and operable to: Storing investment rules on the computer of the financial institution; storing fund information including the identification of financial securities in the fund, the quantity of each financial security in the fund, and the value of each financial security in the fund; receiving and storing transaction information regarding transactions in financial securities within the fund for a predetermined period of time; receiving value information corresponding to the value of the financial security at a given point in time; adjusting fund information based in part on at least one of the value information or transaction information; Compare fund information and investment rules; generating a signal based at least in part on the comparison; and A message is sent to the compliance analyst based at least in part on the signal. 70. A product comprising a computer readable storage medium having a physical substrate physically configured to represent a computer program including means for storing investment rules storing identification of financial securities included in a fund means for receiving and storing transaction information about transactions in financial securities in the fund and for receiving and storing transaction information in a given means for receiving value information corresponding to the value of a financial security at a predetermined point in time, means for adjusting fund information based in part on at least one of the value information or transaction information, means for comparing the fund information with investment rules, generating results based at least in part on the comparison A signaling device. 71. A method of monitoring a client's financial fund, the fund consisting of financial securities, the method comprising: (a) storing investment rules on the computer of the financial institution; (b) receive and store fund information on financial securities in the fund on a computer of the financial institution; (c) receive transaction information regarding transactions in financial securities within the fund; (d) receive value information regarding the value of financial securities within the fund; (e) adjusting fund information in part based on at least one of the value information or transaction information; (f) compare fund information with investment rules; and (g) Prepare a report illustrating the comparison. 72. The method of claim 71, wherein the investment rules include rules relating to the tax requirements of the fund. 73. The method of claim 72, wherein the investment rules additionally include rules relating to the definition of the fund announced by the fund manager. 74. The method of claim 73, wherein the investment rules additionally include rules related to the financial performance of the fund. 75. The method of claim 73, wherein the fund information includes holding level data. 76. The method of claim 75, wherein the fund information includes transaction data. 77. The method of claim 76, wherein the fund information includes tax share data. 78. The method of claim 77, wherein the fund information includes ledger data. 79. The method of claim 78, wherein the fund information includes foreign exchange rates. 80. The method of claim 79, wherein the fund information includes data describing the fund. 81. The method of claim 74, wherein the fund information includes holding level data, transaction data, tax share data, ledger data, foreign exchange rates, and data describing the fund. 82. The method of claim 81, wherein at least some of the fund information is imported from a data source other than the financial institution. 83. The method of claim 71, wherein at least some of the fund information is entered from a data source other than the financial institution. 84. The method of claim 71, wherein the fund information includes distinct portions and at least one portion is stored with a date and time stamp indicating when the portion entered the financial institution's computer. 85. The method of claim 84, wherein the report can be generated for a specific point in time. 86. The method of claim 85, further comprising adjusting the fund information after a specified point in time, storing the time and date of the adjustment and running another report based on the adjusted fund information. 87. The method of claim 71, wherein the report is an interactive report presented on a monitor, further comprising submitting a query regarding the report by a user and providing selected fund information in response to the query. 88. The method of claim 87, wherein the fund information is stored with a date and time stamp indicating when the item of fund information entered the computer of the financial institution. 89. The method of claim 71, further comprising manually comparing the fund information with compliance rules and the user manually entering the results into the financial institution's computer, wherein the results are included in the report. 90. The method of claim 89, wherein the identity of the user is stored in a computer of the financial institution. 91. The method of claim 71 , wherein the financial information includes items, the method further comprising identifying selected items as authentic when they are received from within a financial institution, and when other selected items are received from a data source other than the financial institution. items are identified as unreliable. 92. The method of claim 91, further comprising requiring manual verification by a user of unreliable terms prior to comparing the fund information with investment rules. 93. The method of claim 91, further comprising designating a user as the owner of the fund information, wherein the authentic data cannot be changed except with the approval of the owner. 94. The method of claim 91, wherein items are color coded in the report to distinguish reliable items from unreliable items. 95. The method of claim 71, wherein the fund information for multiple funds is stored on a single financial institution computer, but is segmented among the funds such that the fund information for a given financial security can be used for holding the Update for all funds of financial securities or just for a specific fund. 96. The method of claim 71, wherein the report is electronic and provided to the user via a worldwide computer network. 97. The method of claim 71, further comprising scheduling steps (b)-(g) such that they occur at a selected time. 98. The method of claim 71, further comprising scheduling steps (b)-(g) such that they occur in a selected order. 99. The method of claim 71, wherein the investment rules must be approved by a selected person within the financial institution before being stored in the financial institution's computer. 100. The method of claim 71, wherein investment rules are modifiable immediately prior to the comparison.

Images