WO2000058900A1

WO2000058900A1 - Portfolio investment guideline compliance and financial fund administration system

Info

Publication number: WO2000058900A1
Application number: PCT/US2000/008642
Authority: WO
Inventors: Carmel O'shea; Dana Cashman; Dan Pezzullo; Ken Hebert; Charles Guerriero; Boris Mandel; Vanessa Drysdale; Diane Damphousse; Howard Levine; Lev Ekhtman; Will Peck; Richard Leeper; William C. Miller; Rajesh Kumar
Original assignee: The Chase Manhattan Bank
Priority date: 1999-03-31
Filing date: 2000-03-31
Publication date: 2000-10-05
Also published as: EP1212711A4; CA2369296A1; AU4186700A; JP2003504701A; CN1353842A; EP1212711A1

Abstract

A system (1) for portfolio compliance and administration receives data concerning financial instruments that comprise a financial fund (4) 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

Title: PORTFOLIO INVESTMENT GUIDELINE COMPLIANCE AND

FINANCIAL FUND ADMINISTRATION SYSTEM Inventor:

Field of the Invention The invention is related to the field of administration of financial funds, such as mutual funds and pensions funds. In particular, the invention is related to a system for performing investment guideline compliance tests and regulatory reporting, such as tax reporting and the like, for such financial funds.

Background Financial funds (also referred to as investment vehicles) are composed of a collection of various financial instruments that are managed by a fund manager. Investment vehicles may include mutual funds, unit trusts, pension plans and the like. Fund participants invest in the investment vehicles themselves, providing cash for the purchase of financial instruments. The fund manager makes decisions concerning the sale and purchase (or "trading") of different financial instruments in an attempt to optimize the value of the fund, that is, the return on investment for investors. However, funds are subject to certain rules to protect the investors that restrict the type of trades that a fund manager may make and/or set parameters around the weighting of instruments in the portfolio. These rules may be externally imposed by market-specific regulations that are promulgated by a government entity, such as the Securities and Exchange Commission or the Internal Revenue Service. Other rules may be internally imposed by the investment committee of the investment vehicle sponsor. Typically, these rules are published in the fund prospectus and include representations made to investors regarding the structure and management of the fund. Collectively, these rules are referred to as investment or compliance guidelines. Due to the large number of financial instruments making up a fund, as well as the dynamic nature of the financial instruments themselves, it can be difficult to assure compliance with these various rules. This means that compliance must be tested and reported frequently (such as daily) to keep pace with a changing portfolio structure and with changing portfolio and instrument values.

Typically, the administration of a financial fund will be handled by a financial institution such as a bank. A fund manager, the "client" of the financial institution, will make a series of trades of the financial instruments for a particular fund. These transactions are reported to the financial institution for settlement. This settlement function is performed by the ^■"custody^" department of the financial institution. This institution may also maintain the books and records for the fund in its "accounting" department. Further, the financial institution may also perform transaction accounting, calculating the value held by the particular fund participants, the portfolio value, the return on investment of the fund and guideline compliance, that is, checking the compliance of the fund with the various applicable investment guidelines in its "compliance" department. Currently, investment guideline compliance is determined by compliance analysts or dedicated compliance service teams using a fully manual or semi-manual process.

The rules that make up the guideline compliance test can take many forms. The Compliance Service Teams set up checklists of those restπctions and, on a periodic basis (daily, w eekly or monthly depending on legal, market or client requirements), examine the transactions and holdings of the accounts against the investment parameters. Such labor- mtensiv e manual compliance testing is quite time consuming and subject to human error - thus requiring tightly implemented control procedures. Further, it generally only performs the compliance tests as of a given point in time, rather than for the entire time over a period. It may also be desirable for the fund manager to consider what the effect of altering the fund rules would be on the performance of the fund. This can be very costly when performed by hand.

Fund rules may limit the amount invested in instruments from a selected country or in a particular industry. Such a fund rule might require that the fund portfolio hold no more than 5% of Net Asset Value in Japanese securities. The compliance analyst (that is, the person responsible for checking compliance of the fund with the fund's guidelines) would then need to classify the holdings of a portfolio by country of risk and calculate the percentage of the value of the Japanese holdings against the Net Asset Value. Typically, the compliance analyst will get print-outs of accounting reports, look up "country of risk" for each holding on a computer terminal and set up a computer spreadsheet to do the calculations descπbed. Any "exceptions" (that is, potential violations of the rules) are recorded manually on checklists and are reported to clients in accordance with escalation procedures set out in client-customized service level agreements. These calculations must be performed even when there is no trading of financial instruments for a given fund because the value of a given instrument may change with respect to the rest of the fund, giving it a greater or less share of Net Asset Value. Records of all client communications relating to exceptions are manually maintained. All documentation relating to compliance execution, exceptions escalation and violation resolution is stored in hardcopy.

It is commonly believed that the compliance testing for different types of funds (such as mutual funds versus pension funds) require very different types of analysis. However, there is a high level of commonality in the product attributes globally. For example, all objectives are based on prudent investor principles requiring diversification across industries, geographies and asset types, limited exposure to derivatives and investments of lower quality, etc. Consequently, it would be advantageous to have one system capable of dealing with these various funds. In the administration of a financial fund, it is often critical to develop reports that accurately and completely describe the performance of the fund apart from administration of compliance testing. For example, it may be necessary to collect specific information to determine tax liability for the fund over a particular period. Traditionally, this has been performed manually by analysts reviewing reams of financial information and calculating the required numbers. Obviously, this is a labor intensive task requiring vast amounts of time from highly skilled personnel. Further, due to the manual nature of the task, there was room for human error.

As part of the compliance testing process, a report has been generated indicating that a violation of a particular rule has occurred. Such reports are not interactive and do not permit a compliance analyst to "drill down," determining the specific nature of the violation, the precise definition of the rule or whether the violation has been removed because of a later-posted transaction.

There is thus a long-felt need for a system which can receive data concerning a financial fund, adjust that data based upon long-felt changes in circumstances (both internal and external to the fund), and provide reports at the request of a user, which is flexible enough to accommodate information from a collection of sources while allowing the user, to a great extent, to define the output and which allows the user to explore the specific bases of the report.

Advantages and Summary of the Invention One aspect of the instant invention provides a system for portfolio compliance and administration that can receive data concerning the financial instruments that comprise a financial fund from a collection of information sources. This financial data is recorded and maintained. The system allows the user the flexibility to define the financial data required for a given fund. Vaπous tests can be designed by the user and applied to the financial data to confirm that the fund is being managed in accordance with predetermined rules. While the System provides the user with the ability to correct or update the financial data, this history of changes is recorded, allowing a complete audit at a later date. The financial data (or any reports based thereon) can be provided to the user in a number of useful formats, such as on a computer display, in a pπntout or over a global computer network, such as the worldwide web. If desired, the user, such as a compliance analyst or a fund manager, can be notified automatically by more urgent means (such as a beeper, etc.) when certain financial data is reviewed by the system. Preferably, this single, integrated system allows the fund to be tested for compliance with the fund rules, creates tax reports and develops a complete audit trail without the necessity of importing the same data numerous times.

In one embodiment, the invention relates to an integrated compliance and administration system providing a unique combination of compliance, tax and financial reporting functionality to service the requirements of global investment vehicles, including, but not limited to, US mutual funds, US and global pensions, European UCITS (Undertaking for Collective Investment in Transferable Securities) and OEICS (Open-ended Investment Companies), US and European Insurance companies and Australian Superannuation pension plans. The System imports and stores holdings data, transaction data, tax lot data, general ledger data, pπces, foreign exchange rates, as well as asset descπptive data. This level of detail permits compliance testing and tax and financial reporting on the lowest level of portfolio information. Each field is stored with a date and time stamp. It is an advantage of an aspect of the instant invention that a system is provided that will record detailed transaction data along with the time and date that the transactions were recorded on the system. This complete information allows the financial fund to be analyzed based on more than end-of-day holdings information. Rather, the transactions which effect the fund can be reviewed individually (as well as on a holdings level) to confirm that the fund is in compliance with its controlling rules at any given time. Further, the System provides that any changes made to the financial data are recorded as made by a particular user. Should it ever be deemed necessary, the identity of the user who made a modification to the financial data (or other aspect of the System) can readily be determined.

It is an advantage of an aspect of the instant invention to provide a system and method for executing compliance tests on a fund portfolio. The system of the instant invention receives financial data from various sources, organizes this data, and applies compliance tests on the financial data. Should there be a potential violation of a compliance test, an alert can be sent immediately to the compliance analyst within the financial institution and to the fund manager (if so desired). Further, a preliminary warning signal can be transmitted should the fund pass a threshold, nearing a potential violation. The system permits the data to be reported and recorded in various formats, providing a more complete understanding of the fund compliance and performance. Further, the results of the compliance tests can be reported to the fund manager (or the compliance analyst) via a global computer network, such as the Internet or World Wide Web. The System can be configured to require that the analyst record the resolution of the potential violation (or postpone that recordation until later), thereby providing a record of the actions taken. The System also requires fewer skilled analysts to check compliance of any given portfolio. The improved portfolio-to-headcount ratio resulting from System (and the centralized support functions which have been put in place around the technology associated with the System) in turn result in a more efficient and accurate compliance report. Since the System does not require that highly skilled personnel spend substantial amounts of time performing laborious arithmetic, they are freed up to perform more in-depth analysis.

One aspect of the instant invention automates the currently-manual process, reducing the actual and potential errors and their consequent impact. However, the System also provide additional functionalities tailored to address the needs of the fund manager. The System can cooperate with other electronic fund information systems to provide a single global platform catering to client and geography-specific needs. The centralization of systems and process support functions reduces expenses as more users employ the System. This robust single global platform supporting investment guideline compliance allows the financial institution to serve economically as business record keeper for investment fund managers.

In accord with another aspect of the invention, the System of the instant invention employs a flexible rule-building engine that caters to the nuances of global markets. Data integrity and control features are prov ided to ensure that compliance results are produced on quality-controlled data The System creates an on-line audit trail for tracking violations and/or warnings, as well as resolution progress and/or closure The System also permits the scheduling of data imports, test execution and batch reports. Should a violation be detected, or a condition which requires a warning, an alert or warning can automatically be triggered by the System via pager, e-mail or fax to the client (e.g , the fund manager) The System allows flexible report customization These reports can be provided to the client via e-mail, fax or web-site

The Systems Administrator, in conjunction with the compliance analyst, is responsible for setting up user accounts and access πghts relating to those accounts Thus, in accord with one aspect of the invention, the System facilitates access control management Compliance analysts withm the financial institution or other users can be granted "read only" or "read/wnte" access by the system, ensuπng the lntegπty of the data on the System For example, the Data Management group only can change data element values and the individuals within that group have varying pπvilege levels depending on whether they have supervisory or other roles. Access can be limited by fund, client or other parameters as one skilled in the art would appreciate. For example, while the senior compliance managers might have access to the entire book of business (composed of a plurality of funds) for oversight purposes, compliance analysts may have only client-specific πghts.

In accord with other aspects of the invention, vaπous safeguards are integrated throughout the System to assist in its smooth operation. Should some difficulty aπse in System functions, the compliance analyst, the system administrator, and the compliance fund manager can be provided early notice. If the System is unavailable due to technical issues duπng the business day, procedures are in place to contact the senior compliance managers by telephone and keep them up to date on progress. The task scheduler runs compliance tests at the frequency and timing requested by business users. An event- tπggered escalation schedule is set up in the task scheduler aspect of the System. For example, in a typical application, if data import fails, the System will retry for 15 minutes at 5 minutes intervals and thereafter notify the system administrator (or other party) via pager, e-mail or the like. This procedure is designed to ensure that any issues aπsmg overnight are resolved by the time business opens. Obviously the time intervals, event triggers and contacted party can be changed depending upon the particular application.

In accord with another aspect of the invention, data reconciliation of fund level data, such as holdings, assets, etc.. is performed daily to ensure synchronization with the source accounting system. The system accepts automated feeds of transactions, holdings, tax lot, general ledger information and some asset descriptive data from the financial institution's core systems, such as. the internal accounting system. The system database is supplemented by additional automated asset descriptive data feeds from external data vendors. Automated data population is further supplemented by manual look-ups on alternative vendor screens or in publications. Consequently, the data set on which compliance tests or fund reports are generated is as complete as necessary to ensure accuracy and thoroughness.

In accord with another aspect of the invention, the System permits highly flexible data management while recording modifications to data, allowing a later audit. For example, an authorized data analyst within the Data Management group may enter or modify fund specific data for those fields which are defined differently for the same asset by different clients, such as industry classifications, liquidity, etc. Preferably, all asset descriptive data employed by the System will come from one centralized source internal to the financial institution. The Data Management group, using the tools programmed into System, acts as a quality assurance monitor for asset descriptive data for all users of the application. This group is also supported by approval procedures to minimize risk of error.

The System facilitates a demarcation of data sources by element. Fields that are essential to the execution of compliance tests are designated "mandatory" (for example, individual security prices). Mandatory fields may be classified as "source reliable" and imported from internal financial institution sources. These fields cannot be modified on the System. They may only be modified by a request to the data owner for that source system. Modification requests need proper supporting documentation to ensure data quality control. Any modification are "date and time stamped," that is, the System saves the previous value and records the modification including, who made it and when it was made. This complete record of modifications allows a later analyst to understand the modifications and their effect, as well as to perform any necessary follow up with the person who made the modification. Mandatory fields must be "certified" by a data administrator verifying the value against alternative sources and double clicking on a certification button to notify the database that the field value is good. In the graphical user interface provided by the System to make the entry of data or instructions more intuitive, fields are color-coded on the screens and segregated on the database to reflect their different status. Only when all mandatory fields for an asset are certified (all field values manually reviewed and confirmed) will the System permit compliance to be executed.

In accord with another aspect of the invention, the System includes a dynamic compliance rule-building engine that ensures the flexibility necessary for a system that must service a global product. The data pertaining to the particular financial instruments, such as the number of shares, the credit ratings, the market price of the shares, the classification of the financial instrument for that particular fund, etc., provide the building blocks to translate investment guidelines into system logic, allowing compliance tests to be performed by a computer. The rules that control a fund are converted into logical statements that link the data elements. Rules are grouped together to form tests. A "test" is comparable to the "checklist" from today's manual environment. Tests are set up at the outset of each client relationship by a dedicated group of Rule

Builders based at the financial institution. The Rule Builders work with the compliance analysts and client representatives in interpreting the guidelines for each client, e.g., what does a particular client define as a "derivative"? The Rule Builders are responsible for creating new rules/tests or cloning and modifying existing rules/tests, verifying the accuracy of the fund-specific definitions and assigning approved tests to funds for production purposes. System logic links the fund-specific tests to the fund-specific data that is fed into the System on a daily basis. The System task scheduler runs compliance tests at the frequency and timing requested by the compliance analysts on behalf of the client. Of course, the System also allows the compliance analyst (and other approved users) to by-pass the scheduler and run compliance tests and to generate reports (such as regulatory reports) immediately upon request.

Results are automatically generated by the System and displayed on-line by the "Results Tracking" module in accord with yet another aspect of the invention. Compliance analysts have the ability to annotate those results on-line details, thus recording the audit trail of the escalation and reporting of issues to clients and clients instructions relating to the resolution of those issues. The System stores, and can display on-line, a complete audit trail of the compliance history of the portfolio. Preferably, reporting is Excel -based but other platforms or presentations can be employed. Some reports are hardcoded, e.g., those used by the Data Management group as part of their data verification procedures. The majority of compliance reports are created during the test set-up process based on the compliance analyst requirements. Compliance analysts are granted the flexibility to save reports onto the hard-drive and to incorporate them into board of director packages. All System- generated reports print with a System footer. The footer disappears when the report is "unlocked" to permit amendments. This alerts readers that the report may not have been generated directly from System or may have been altered.

The System of the instant invention provides the option of "as of functionality, that is, the ability to load "late transaction" information that did not make the original accounting deadline and have the option to apply it to the portfolio and re-execute compliance on the revised portfolio to ascertain what the compliance status would have been on that day if the portfolio had been "whole". This is useful when trades or other information are received after accounting has been completed and the accounting source system information has already been passed to the compliance system. This new information may well affect the compliance status of the fund. An "as of reconciliation report maintains an audit trail of the changes.

The System provides for results tracking, that is a full on-line audit trail ^' of the resolution of a compliance issue. The System produces the compliance results and printed reports and compliance analysts can record their actions off-line. However, the System gives the compliance analysts the ability to continue beyond that by "opening" a record to track on-line all of their actions after viewing the results, e.g., escalating the issue to the client, receiving confirmation of an incorrect data value, "closing" the record following the resolution of an issue. Recognizing that data constraints will never allow 100% automation, a small portion of compliance will continue to be calculated off-line. The System permits the compliance analysts to create a "manual" rule by recording on-line the wording of the off-line rule. The compliance analyst then checks whether this manual rule was complied with. The System allows the compliance analyst to attach a result. The compliance analyst may also employ the Results Tracking functionality for these off-line rules and keep all client records in one place. The System provides on-line data analysis. Full front-end screens allow compliance analysts to view all data associated with their clients that has been imported to the System. The fund managers may be provided with the status of any tests run (i.e.. pass, warning or fail) via a global computer network. Further, if so desired, the fund manager may be provided more detailed reports and the ability to interact with the System. In this case, the System would allow the fund manager to drill down on the details of a report and determine the nature and cause of any violation or simply to gain a better understanding of the performance of the fund in light of the rules.

Multiple asset master data sets are stored on one segregated database to cater for multiple source accounting systems globally. This allows for universal updating of some asset fields that will be the same across global accounting systems but segregating at the asset master and even at the client level the data fields that may have different values at those lower levels.

The System provides an integrated scheduler, facilitating scheduling of all systems jobs, e.g., data imports, test execution and batch reports. This task scheduler allows interdependent scheduling of tasks, i.e. run data import from source system once indicator is triggered that source system is ready and on successful completion of the data import, run the compliance tests. Of course, the System can run tests and produce reports "on-demand," that is, in response to an ad hoc request by a System user, such as an analyst. The System preferably includes browser-based reporting and can be deployed on the web. The clients (such as fund managers) can access the key reports in layered fashion "clicking" on fields of interest to instruct the System to provide additional or more detailed information relating to that specific item of interest. The System provides six types of data fields identified as the compliance rule-building blocks and a rule approval function to ensure appropriate testing before allowing the rule to put it in production. The System permits parameters to be changed at run time.

The System can provide an early warning signal to the compliance analyst (or fund manager, if desired) when a fund is near a guideline violation. In this way, the fund manager may take corrective action, if deemed necessary, before a violation in fact occurs. The results of any tests performed on the System may be provided electronically, such as by pager, electronic mail and facsimile. The System permits a reconciliation between a source accounting system and the System itself. The System flexibility allows compliance analysts to define terms and rules for a specific fund, as requested by clients. For example, certain fields such as industry classifications, liquidity, etc. may be defined differently for different funds. The System permits such definitions to be fund specific. The System also allows compliance analysts to search the database across fund groups. For example, clicking the "holders^** button will cause the System to search for all "holders" of a particular stock in the database. This may be particularly useful if particular company is in crisis and you want to quickly see exposure across portfolios.

Brief Description of the Drawings

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

Fig. 1 is a schematic depiction of the flow of information from the fund managers, through the financial institution to the System of the instant invention.

Fig. 2 is a schematic depiction of the flow of information from external information service providers and other departments of the financial institution to the compliance department for the System of the instant invention to the users of the System.

Fig. 3 is a flow chart depicting the login process.

Figs. 4 and 4A are flow charts depicting the processing of account information.

Figs. 5A-5C are flow charts depicting the processing of account rights. Figs. 6-6A are flow charts depicting the processing of account status.

Fig. 7 is a flow chart depicting the processing of task schedule.

Fig. 8 is a flow chart depicting the processing of task queue.

Figs. 9-9A are flow charts depicting the processing of asset maintenance.

Fig. 10 is a flow chart depicting the processing of fund maintenance. Fig. 11 is a flow chart depicting the processing of fund maintenance.

Fig. 12 is a flow chart depicting the processing of fund maintenance.

Fig. 13 is a flow chart depicting the processing of fund group maintenance.

Figs. 14-14A are flow charts depicting the processing of table maintenance. Fig. 15 is a flow chart depicting the processing of the compliance engine architecture. g. 16 is a flow chart depicting the processing of notification request. g. 17 is a flow chart depicting the processing of contact maintenance. g. 18 is a flow chart depicting the processing of notification delivery service. g. 19 is a flow chart depicting the processing of compliance reports. g. 20 is a flow chart depicting the processing of violation tracking. g. 21 is a flow chart depicting the processing of automated response. g. 22 is a flow chart depicting the processing of manual violation creation. g. 23 is a flow chart depicting the processing of violation detailed display.

F g. 24 is a flow chart depicting the processing of the violation tracking user interface

Figs. 25-25 A are flow charts depicting the processing of the general ledger report.

Figs. 26-26A are flow charts depicting the processing of the holding report.

Figs. 27-27A are flow charts depicting the processing of the report by user ID.

Fig. 28 is a flow chart depicting the processing of the report list.

Figs. 29-29A are flow charts depicting the processing of a report by activity.

Fig. 30 is a flow chart depicting an overview of the wash sale processing.

Fig. 31 is a flow chart depicting the processing of Section 988 gain/loss analysis.

Fig. 32 is a flow chart depicting the processing of the calculation of the wash sale deferral amount.

Fig. 33 is a flow chart depicting an overview of the PFIC processing.

Fig. 34 is a flow chart depicting the processing of PFIC cost tracking.

Detailed Description

As discussed throughout, the "system administrator" is an operator responsible for maintaining the computer network employed by the System, such as a management information systems specialist. The "compliance analyst" is the specialist at the financial institution responsible for reviewing the compliance of the fund, reporting issues to the fund manager and assisting the fund manager in understanding the reason for any potential v iolation The "fund manager^" is responsible for the decision to buy and sell financial instruments that compπse a fund, ithm the investment guidelines imposed on the fund. It will be appreciated that any particular individual may serve any of these roles and still practice the invention. Further, a team of individuals may be employed to serve any of these roles and still practice the invention with the assistance of other computer systems

Referring to Fig 1, a schematic view of the data flow for the System 1, clients or fund managers 3 report the trades to the custody department 2 of the financial institution 10 The information concerning the trades is delivered to the vaπous entities responsible for that particular fund 4 Any number of funds may be handled by the System Preferably, this information is delivered to the custody department on the same day as the trades (that is, the "trade date") The custody department 2 will transfer the information concerning the trades to the fund accounting department 5 at the financial institution on trade date or via an overnight feed. [What is the Warehouse/CCAP?] The accounting department wrll also receive data from outside vendors 6 concerning the financial instruments, such as the credit ratings, the outstanding shares, the coupon rate, the country code, the industry class and the matuπty date. Of course, other types of information may be obtained from outside vendors and still practice the invention, as one skilled in the art would appreciate. With this information, the financial institution will function as a "transfer agency," calculating the ownership πghts for the individual investors in the fund Further, the performance measurement department of the financial institution will determine the performance of the fund in view of these recent transactions. Reports of this information may be delivered directly to the fund administration department 9 of the financial institution. Once this information is collected by the financial institution 10, it is delivered to the fund administration and compliance department 7 of the financial institution. As discussed below, the vaπous compliance tests are run against this data as scheduled by the Task Scheduler 27 (see Figs. 2 and 7) or as otherwise requested by the compliance analyst. The results of the tests are provided electronically (or on paper) to the compliance analysts by the System Upon review of the compliance report 8, the analyst can simply "click" on portions of the report to receive more detailed information. Of course, other user interfaces may be provided between the analyst and the System, as one skilled in the art would appreciate. Importantly, the System maintains a record of fund holdings, the transaction history of the funds, and the performance and the pricing of the fund. This information, any changes to the information, the identity of the entity making the change, and the date and time the change was implemented are also maintained. The System maintains records of "holdings" level data and transaction level data. This permits the System's compliance testing to confirm that any fund transaction did not violate the relevant guidelines during a given period, not merely that the fund was not in violation at the close of the period.

Again, referring to Fig. 1, the System also provides fund administration reports. In particular, the fund administration department 9 of the financial institution 10 receives the fund financial data and can produce various regulatory reports 711, such as tax reports and the like. These reports may be printed on a printer 712 or provided to outside sources such as the IRS 713. The System's maintenance of complete financial data allows the creation of financial reports as requested or needed by the client. The rule building library of the System, discussed below, permits the application of complex rules to generate reports related to global regulatory requirements, e.g. IRS or SEC requirements, as one skilled in the art would appreciate.

It will be appreciated that it is currently envisioned that the System will provide reports and the ability to drill down in the reports solely to employees of the financial institution, such as the compliance analyst. The fund managers are given status reports by the compliance analyst.

Referring to Fig. 2, a schematic view of the processing performed by the System 1, the accounting system 20 of the financial institution will transfer its fund data (including information concerning holdings, transactions, lots, income, general ledger accounts and foreign exchange rate) to the compliance system 21. The compliance system will also obtain asset data (including the credit ratings, the outstanding shares, the coupon rate, the country code, the industry class and the maturity date) from outside information vendors 22, 23 or from the internal accounting department of the financial institution. Other information concerning the financial instruments can be entered manually into the System, as depicted at block 24. Once the data is received, the System will apply the compliance tests. Preferably, the compliance tests are run overnight so that when the compliance analyst comes to work in the morning, she will be advised whether a potential violation is detected. The compliance rules engine 25 is part of the compliance system 21 and includes software which maintains the rules applicable to a given fund and applies them when scheduled. The report-writer 26 is also a part of the compliance system and generates reports concerning the application of the compliance guidelines and tax and financial reporting. The Scheduler 27 allows the Systems Administrator to schedule various tasks, such as the running of the compliance tests, at the request of the compliance analysts. The compliance engine also includes software 28 used to generate the interactive screens which are displayed to System users either to present information to the user (such as a compliance report) or to request or obtain information from the user. The compliance system also includes software directed to results tracking 29 which permits the compliance analyst to record on-line the resolution of a potential violation, thus providing an on-line audit.

Once the compliance tests have been run, the System provides output 420 in various forms as requested by the Systems user. For example, for analysts internal to the financial institution, it is preferred that reports be provided at the analyst's computer workstation. The analyst can review reports that were batch-printed overnight so he does not have to wait for them to print at the beginning of the work day. He also has the option of running reports "on the fly" as needed . When there is a violation of a compliance guideline (or a near- violation warranting a warning), the analyst may be notified by the System via facsimile, electronic mail or beeper. Similarly, the clients may be notified of violations or warnings. Of course, a more complete report can be provided and still practice the invention.

When the compliance analyst logs onto the System 1, she will be apprised of any potential violations automatically. By sending inquiries to the System (such as by clicking of fields in the graphical user interface), she can receive more detailed information from the System and determine the nature of the potential violation, the nature of the rules violated, and the apparent cause of the violation. While not generally required, at this point, a skilled compliance analyst can determine whether there is in fact a violation, reviewing the operating parameters of the System as set for that fund. Certain parameters (such as the definition of "liquidity") may be incorrect for this particular fund and will, upon correction, remove the potential violation. Further, trades may have been executed but not entered into accounting system or the System. These later trades, in combination with market value appreciation or depreciation of the financial instruments in the fund, may bring the fund back into compliance. After or while performing this investigation, the compliance analyst can contact the fund manager to apprise him of the potential violation. The System may be set up such that certain defined potential violations are brought immediately to the attention of the compliance analyst and or the fund manager. The compliance analyst will be required to enter the responsive action or resolution of the potential violation on the System. This responsive action may simply be bringing the violation to the attention of the fund manager.

The System maintains an audit record of the running of the compliance tests as well as the results. The responses of the compliance analyst are recorded as are any changes to bring the fund into compliance. For example, if a trade is entered late, the results of the initial compliance tests are recorded, the entry of the late trade is recorded and the new results of the later compliance test are recorded. If desired, one could review the entire record of the compliance test and any responses taken.

The System preferably runs on 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 may be employed and practice the invention.

The System of the invention provides the users a great flexibility in defining the nature of the reports generated as well as an intuitive interface that permits ready investigation into the data or rules affecting the report. In particular, the compliance engine 21 of the System includes a dynamic rule-building engine which ensures the flexibility necessary to service a global product. The data fields related to the funds are defined for each fund based on the analytical needs for that fund. These data fields provide the building blocks to set up investment guidelines. The guidelines or rules governing the particular fund are translated into logical statements. Rules are grouped together to form tests. System logic links the fund-specific tests to the fund-specific data which is fed into the System on a daily basis and the task scheduler runs compliance tests at the frequency and timing requested by compliance analysts (of course, the System can perform the tests at any time upon the request of the compliance analyst). The tests appropriate for each fund are set up at the outset of each relationship by a dedicated group of rule builders working with the compliance analysts and the client in interpreting the guidelines for each client (e.g., what does a particular client define as a "derivative"?). The rule builders are responsible for creating new rules or adapting existing rules, verifying the accuracy of the fund-specific definitions and assigning approved tests to funds for production purposes. These rules are developed such that they can confirm compliance by reviewing transactions themselves, not simply the holdings of a financial fund

The rules developed for the System are recorded in a rule library on a database on a computer at the financial institution 10 Rules other than composites, benchmarks, and denvativ es will require similar logic d e , a result based upon data) and may be developed as desired for a particular application These rules may have initially been developed for different funds or even different types of funds Once the software for a rule is wπtten, it may be employed with respect to new funds Consequently, when the rules for a new fund are dev eloped, the comphance analyst and rule builder can search the library for the same or similar rules It is not necessary to develop a new program for the same rule. The compliance engine 21 of the System may be modified to allow new rule types to be built

The System is designed to permit composite level testing and performance reporting. Generally, the composite accounts are aggregations of accounts by investment themes, the aggregate usually called a "fund family " For example, there may be a composite of all foreign equity portfolios and another for fixed income portfolios withm the family It is often desirable to apply tests to selected group of accounts within a given family, particularly in the case of pension funds Compliance testing is also conducted at the individual account level but the mandates may differ from the composite level as one skilled in the art would appreciate. The creation of a composite account includes the addition of account level information as defined in the composite requirements document. Once the composite is created, however, additional calculations are then performed to generate the proper data for rule executions. The types of calculations typically required at the composite level include: percentage calculations for country exposure, industry exposure, weighted average calculations, closeout and coverage logic on deπvatives. To perform such composite level testing, the System includes the ability to define composite account, execute all compliance rules against the composite account and calculate results against the composite account. For example, composite level testing can be employed to calculate deπvative exposure for the composite (as opposed to any given fund) by executing the deπvative exposure tests at the composite level. Benchmarks may be employed to compare the country exposure of the composite to the benchmark for the plan in general. The System also provides the ability to create report output for the composite account and to see the account level detail in the composite reports (i.e., if 3 accounts own one security, the report would list the values on the individual accounts and show a total line for the composite). Prospectus test reports include a listing of the account identification numbers, the account names and the net asset value of each account that comprise the composite account. The System permits scheduling of composite account tests in the Task Scheduler, as with fund testing. The notification mechanisms discussed herein with regard to fund testing may also be employed for composite tests (fax, beeper, email).

Supplemental security data may be provided via an external information vendor, such as Bloomberg. Enhancements to the information files provided by the external information vendor may be needed for the asset set-up and difference files for fixed income securities. Further, changes to the System user interface screens for new data elements may be required for any new tests, as one skilled in the art would appreciate. The purpose of such modifications is to automate the asset set-up and refresh process for securities, or other new information sources.

Many investment guidelines require that funds or composites be tested against benchmark funds. The System allows rules to be created that perform compliance testing against benchmark data. Preferably, benchmark data is imported from an Excel spreadsheet format and stored in table format. A report is created to display benchmark data with various sort options, and a date feature is provided to view the historical benchmark data. Historical data from the same benchmark (i.e., weekly, daily, monthly feeds of benchmark data) may be stored and recalled for later comparison. Compliance rules are executed for an account or composite against the benchmark. The System allows the user to build (absolute and concentration) rules that compare attributes (e.g., country of exposure) of an account or composite to that of a benchmark account and to build rules that compare portfolio level data (e.g., duration, weighted average maturity) of an account or composite to that of a benchmark account. Rules may be developed to perform calculations on both an account or composite and the benchmark and compare the results. Transaction-based rules (such as, whether the fund purchased a security with an asset type not in the benchmark) may also be developed. Tests may be executed in which the benchmark date is not equal to the post date of an account or composite. Preferably, the test will always use the benchmark data that is closest to (but not later than) the test date. For example, if the test date is 6/30/99, and there is benchmark data for 7/5/99 and 6/20/99, the test would use the 6/20/99 data. The System allows the user to specify the use of benchmarks at the rule level; the benchmark should be a parameter to allow for the same rule to use a different benchmark.

Reporting requirements for the System will show the results of the test and have a separate report for the benchmark with different sort options available. It should be noted that as-of functionality is not needed for benchmark testing (benchmark data is static). For as-of tests, if the current date is 7/10/98, and a test is executed for 6/30/98 with a cut-off date of 7/10/98, the test would still use the 6/20/98 data, rather than the 7/5/98 data. While as-of trades may be included for an account or composite, the benchmark data will remain the same. As discussed more fully below, the System permits users to generate thorough and complete reports of the financial instruments in the fund, as well as the characteristics of those financial instruments. For example, the System may be employed for tax reporting services. Offering tax services in an automated, rather than a manual environment, will improve the quality, reduce risk and improve the timeliness of tax services to the financial institution's Fund Administration customers. Beneficially, the System incorporates the investment guideline compliance testing with the complete tax reports function, allowing for more accurate and complete results.

The convenient presentation of compliance results as well as the straight-forward user interfaces allow compliance managers to modify parameters with respect to the fund and provide "What if scenario capability. "What if scenario testing is less "real-time" than pre-trade compliance discussed below. Used by investment managers, portfolio strategists and risk managers, this assists the decision-making process on the direction of a portfolio. It assists the fund manager and the compliance managers, as well as the other professionals at the financial institution, in assessing the impact to a portfolio if investment guidelines or portfolio dynamics are changed either at the manager mandate level or the aggregate level. It does not need to be "on-the-fly" but would be part of an analysis carried out over a period of days or weeks. For example, the compliance analyst may investigate the effect of changing the compliance rule or test: "What if I increase my allowable exposure to 'in-countries^* in Europe by changing my rule parameter from 5% to 10% to take advantage of Euro-opportunities?"; "What if I add a tobacco industry restriction because of potential law suits?"; "What if I completely revise my prospectus/guidelines from X to Y because of a restructuring within my organization?"; "What if I take out all of my fixed income managers accounts from the aggregate?". Further, the compliance analyst can investigate the effect of portfolio dynamics changes: "What if I buy a particular holding?"; "What if I sell a particular holding?". .Analyzing the effect these changes would have had on historic investment performance may educate the fund manager and the advisors at the financial institution as to ho to improve performance in the future.

The System may also be employed to confirm compliance pre-trade. Pre-trade compliance refers to real-time compliance checking based on real-time portfolio pricing and re-pricing and real-time asset descriptive data. Trades found to push the portfolio into violation are blocked by the System and the order cannot be executed. This capability would reside on the trading desktop as a means of controlling traders activity. Preferably, the pre-trade compliance feature is not part of the scope of the Compliance Reporting product only. An effective pre-trade compliance product would 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 against the fund. This information may be employed to develop the fund rules in the future or to provide the fund manager with insight as to the operation of the fund under new rules. In particular, it will be appreciated that the System may be employed to analyze any of the following: rules that utilize fund transaction information; portfolio turnover; short sales; forward contracts; derivative-related rules; coverage/exposure; collateral; hedging/ speculation; margin deposits; straddles and spreads; averages; dollar weighted average maturity; average quality; time of purchase rules - all rules are based on current day information. The System may also be employed analyze dual function rules (a result based on a result) such as: if portfolio borrows more than 5% of total assets, it cannot purchase securities; comparative results; boπowings must be less than x% of the lesser of market value or cost; maturity calculations that utilize shortening instruments - demand feature, puts, etc.; logic that utilize underlying securities information. Of course, any number or type of rules may be developed and applied and still practice the invention.

It will be appreciated that the System may be employed to perform several fund administration functions, which are completed using manual procedures, such as underwriting; real estate; leases; mortgage hypothecation; securities lending; indexes; exchanges; expense/payment info; survey functionality; report writer capability; allowing third party feeds, such as from other accounting systems. [How is that done?] Preferably, the System includes a menu-dπven user interface allowing the comphance analyst to readily access the information generated by the System The menu bar on the main menu screen w ill be maintained dynamically and will employ the conventions of popular user interfaces including dropdown menus and the like, such as the con entions of Windows NT from Microsoft Corporation To access the System, the user double clicks a start up icon and is requested to provide a password The user name and password identifies this user The user is granted certain defined access πghts, allowing them to perform only limited activities on the System The Main Menu screen may include a message line containing text information, such as the data field into which data is being entered and the like. Only menu items that this particular user can access will be displayed on the menu bar and submenus, such as File, Data, Compliance, Report, Windows and Help

The Reports option of the main menu preferably contains six options, compliance, results tracking, management, system access, activity log and view reports The compliance option will open the window for viewing and requesting compliance reports The results tracking option will open the window for viewing and responding to compliance violations. The management option permits the user to open a general ledger window to view general ledger audit reports and a holdings window to view the holdings audit reports. The system access option opens the window for requesting and viewing system access reports. The activity log option opens a window for requesting and viewing reports of login and logout activity The view reports option opens the window for viewing and pπnting previously generated reports.

Referring to Fig. 3, the user identifications and passwords are maintained by the network or system administrator on a distinct computer or separate program on the computer containing the program for the System. The System does not create or maintain this information. User identifications and passwords will be required when a user logs on, reenters the System after requesting a lock out, or reenters the System after being timed out by the System at block 30. The login process employs a WINDOWS NT API at block 31 to retπeve the Network User ID information at block 713. The API will return the Network User ID for that workstation. The User Table will be read at block 32. The System will pass the password entered by the user at block 33 onto the API for veπfication. The System will determine whether this user is "locked out" at block 37, for example, if this user is already logged on. If the ID is locked, the System will send a message to the user so indicating at block 36. This attempt will be logged onto the event table 34 at block 35. The System will then close at block 38.

If the user ID is not locked at block 37, the user data is formatted at block 39. The API will return a code indicating whether the password entered is correct at block 431. All login attempts will be logged onto the event table 34 in the database, whether the attempt is successful (block 530) or not (block 433). Users are sent a message at block 433 indicating when their logins are unsuccessful. If the user attempts to submit an unacceptable password three times at block 436, an SQL statement will update the user table 33 using the network ID to turn on the lock out indicator at block 437. This activity will be logged onto the event table 34 at block 438 and the System application will be closed at block 439.

If the user ID and password are accepted at block 432, the System will retrieve the user's profile table at blocks 531 and 536 and will retrieve a list of authorized system functions and data access from the database 537 at block 532. The user's access profile will be kept in memory at block 533 so that all forms on the System can determine access to functions and data for this specific user. The System will then transfer control to the Main Menu of the System at block 534.

A user may "lockout" the System on their workstation by minimizing the screen. Alternatively, the user may select "lock" from a dropdown File menu on the menu bar. Further, if no activity is recorded on the System for a given period of time (such as thirty minutes), the System will flag the users account as inactive, log them out and automatically minimize the application. To reenter the System, the user will need to double click on the system icon and reenter their password. The System will then confirm the password as discussed above. These lockout activities will be recorded on the activity table.

The System Administrator establishes new User Accounts, as well as modifies, deletes or disables existing User Account. Each User Account includes a User Profile which defines the access granted to a user, such as a compliance analyst, to System functions and data. For example, a user may be granted read-only or update privileges. It will also provide login information that contains current data on the User's login and logout activity including: Last Login Date and Time, Current Logon Status, and User Lockout Notification. Preferably, each User Account will be uniquely identified by a User ID and user access rights will be restricted appropriately. All requests for access to the User Account information in the System will require the requester to supply certain information, such as the nature of the need to review the information or the party authorizing access to the information. The request must be implemented by the system administrator after approval of the appropnate officer of the financial institution. This aspect of the System requires that all requests for User authorization will be documented and access authorizations will be established according to business need and job responsibility.

Referring to Fig. 4, the User Account information will be available as both display- only and update screens. Users (generally, System Administrators) that possess authority for both of these, as well as data access for updating, will have the ability to perform the Update function. Those users that have read-only data Access Rights, will be prevented from performing updates. By selecting the System Access Option from the File Pulldown Menu on the Main Menu Screen 715 at block 40, the user will open the System Access Window on its workstation 44. It is divided into two sections. The left window generated at block 41 will present a Users Listbox containing all User Accounts within the System from the user profile table 42. The right window generated at block 43 will contain the following three User Information Tabs: Account Information at block 44, Account Rights at block 45, and Account Status at block 46. These will provide the System Administrator with the ability to setup and maintain User Profiles, grant and revoke System access rights, and review User login status. At the bottom of the right window are three buttons: SAVE, CANCEL and CLOSE. Once the User finishes working on one of the tabs, they will have to 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 will click on the CLOSE Button to close the System Access Window, returning to the Main Menu Screen.

The User Listbox will be filled with the current list of Users. By default this List will be sorted by Last Name. However, the System Administrator can also sort it by First Name or User Id, by clicking on the appropriate column header. The Administrator can easily locate a User ID in the List, either by using the scroll bar, or typing the first letter of the ED, causing the list to jump to that point. When the System Access Window is first opened, the Account Information Tab is visible, showing the last record worked on. This tab allows the System Administrator to setup and maintain information specific to the User.

Referring to Fig. 4A, to add a new User Account at block 47, the System Administrator clicks on the NEW Button in the Users Listbox, clearing all of the fields on the Account Information Tab. The System confirms that this User has the appropriate authority at block 48. If not, the System returns to block 73 (Fig. 4) If the user has the appropriate authority, the tab fields are initialized at block 49. The system administrator enters the required fields (defining access rights, etc.) at block 440, using authorization sheets provided by the Information Owner, and clicks on the SAVE Button 441 to add the new User^'s account information to the User Profile Table 447. The System confirms that the necessary fields have been completed at block 444. If required information is missing, the field will be highlighted and a message will be displayed on the workstation 44 at block 448. If the screens are filled out completely, the System checks the locks at block 445 [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 is passed, the User Profile Table 447 is updated at block 446. Once a new User Account has been 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 on the

DELETE button in the Users Listbox at block 540 in Fig. 4A. The System confirms that this user has the appropriate authority at block 541. The System Administrator selects a User Account from the Users Listbox, causing the Account Information Tab to be populated with the User's Account Information at block 542, and clicks on the DELETE Button. A message box will be displayed requesting delete confirmation at block 543. The YES Button is clicked to confirm the deletion. The System then checks the locks at block 544. The User Account will be permanently removed from the System at block 545, which will remove the User's account information from the User Profile Table. Clicking the NO Button, cancels the Delete operation and an error message is sent to the User at block 546. Disabling an Account will prevent login to the System. To disable a User Account, the System Administrator clicks on the Disable Account Check Box, causing an 'x' to appear in the box, and clicks on the SAVE Button, to complete the change, which will indicate the User Account is disabled on the User Profile Table. The Account may be re- enabled by removing the check from the Disable Account Check Box. The System Administrator can also access the above functions by clicking on the right mouse button, while the cursor is positioned on a record in the User Listbox. A Popup Menu appears with the following 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 rights under the System, the System Administrator selects the Account Rights Tab at block 46 of Fig. 4 by clicking on the tab label, or typing the underlined letter in the tab label. The user will click on the user ID at block 60. The System reads the user's rights from the access rights table 62 in the database at block 61 which are displayed at block 63 on the workstation 44. The Account Rights Tab will contain the Assigned and Available Listboxes. The Assigned Listbox contains a tree list of rights assigned to the User Account for that particular user. The Available Listbox has a tree list of all funds, fund groups, rules, tests, and functions available on the System. When a new Account is created, the tree list in the Assigned Rights Listbox will initially be blank.

Referring to Figs. 5A and 5B, the System Administrator may access Select Account Rights Tab 45 (Fig. 4) to grant Access Rights to Users for the following Elements: Funds, Fund Groups, Rules, Tests, and System functions. To review the rights currently granted to a user, the System Administrator right clicks on the user ED at block 50. The System reads the access rights table 901 at block 51. The user ID details are then displayed on the workstation 44 at block 52.

To grant a User Account access to functions or data, the System Administrator selects a User Account at block 53 by clicking on a User record in the User Listbox. The

System determines whether the System Administrator has the appropriate authority at block

54. If so, the System reads the access rights table 901 of the database and displays the user

ID details on the monitor 44 at block 56. The user then double clicks on an element in the

Available Listbox (or single-click on it, and then on the ADD Button) at block 57 to assign or de-assign rights. The Element for which Access Rights are to be granted will move from the Available Listbox to the Assigned Listbox. To revoke an access right that a User

Account has to a particular Element, the System Administrator can either double click on the

Element in the Assigned Listbox, or click on the Element and then on the REMOVE Button at block 57. This will remove the Element from the Assigned Listbox. In addition to moving single Elements with Access Rights, the tree list can be expanded or collapsed, allowing groups of Elements 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 will be initialized at block 801. The System will then return to block 43 of Fig. 4. Alternatively, the System Administrator can save the changes by selecting the SAVE button 58. The System will then perform a screen validation at block 59. [What is this validating?] If it fails, an error message will be generated at block 902. If the validation passes, the System will check locks at block 803 (see Fig. 5B). If the lock check fails, an error message will be generated at block 902. If the lock check passes, the user profile table 901 of the database will be updated at block 804.

The System Administrator must set the privilege level for each Element in the Assigned Listbox. To do so, the Administrator will click on the 'R' to enable Read privileges, or 'W' to enable Write privileges, in the R/W Field. Write privileges automatically enable Read privileges. An enabled Element appears grayed out. To disable the privilege, the Administrator clicks on the Element a second time. The Administrator will click on the SAVE Button which will add the account rights information to the User Profile Table. While the System Administrator in either the Assigned or Available Listbox of the

System, clicking on the right mouse button, will cause a Shortcut Menu to appear, pertaining to the current element, with the following options: Add, Remove, Details, Collapse All, and Expand All. The Add, Remove, and Details options perform as described above. The Collapse All option causes the tree list to collapse to its highest level of detail. The Expand All option causes the tree list to expand to its lowest level of detail.

The Intruder Lockout Checkbox will be checked when the User has been locked out after three attempted logins with an incorrect Password. The date this last occuπed will appear in the On Cell. The Reset Account Access Checkbox allows the System Administrator to re-enable the Account's access. Referring to Fig. 6, to view User login information and reset account access for a given user, the System Administrator will first click on a User Account in the User Listbox at block 64 (and then on the Account Status Tab). The System will read the activity table 66 and the access rights table 67 for that particular user at block 65. The System displays the user ED account status on the workstation 44 at block 68 and provides a check box to reset account access rights at block 69. The Administrator can select the CANCEL button 806 and the System will initialize the tab fields at block 807. Alternatively, the user can select the SAVE button 805 and the System will check the System locks at block 808. If the lock check fails, the System will provide an error message on the Administrator's workstation at block 811. If the lock check passes, the user profile table 810 will be updated at block 809.

The System permits tasks to be scheduled for automatic execution, eliminating the need for a user to stand by and submit requests. The System will place a record into the Task Queue to request a specific function, such as running a compliance check. If the scheduled function fails, the System will retry the execution and notify the user that the execution has been delayed. The user will specify the date (or range of dates) when the function will be executed as well as the anchor dates (i.e., the as-of date and the cut-off date). The user will specify the time interval for the execution of the System function, the time interval to retry if the execution fails, and the time interval after which the user will be notified of the failure. Various templates may be employed as a user interface to allow the user to enter this information in a straight forward manner.

Fig. 7 is a flow chart depicting the processing related to the Task Scheduler. The Schedule dialog box is displayed on the monitor 44 at block 70. When the user clicks on the run frequency button 71 on the monitor display, the System permits the user to input the run frequency at block 72. The user can select to run the predetermined task on a specific single day at block 772, a specific day of the week (e.g., every Wednesday) at block 773, a specific month at block 774 and a specific day of that month at block 775, or a specific day in a specific month in a specific year at blocks 778, 777 and 776, respectively. Once the run frequency is selected, the user selects the "as of and cutoff anchor dates at block 77 and then selects the run time period and the time interval to retry if the task is unsuccessful at block 78. The user may then close and exit the system at block 471 or cancel the scheduled task at block 472. Alternatively, the user can select close and save at block 473. The System performs a screen validation at block 470 to confirm 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 the monitor 44. The System then displays the schedule dialog box. If the System determines that the user has entered the appropriate information at block 470, the schedule is saved on the Schedule/Queue Table 75 of the financial institution's computer at block 79. The System then displays the schedule dialog box. When viewing the schedule dialog box, the user can select the status button 73. The

System then retrieves information concerning the next and last run of the predetermined task from the Schedule/Queue Table 75 of the financial institution's computer at block 74. The user can then select the on hold button 76 to prevent the running of the next scheduled task until released by the user.

Referring to Fig. 8. once the task schedule has been saved, the System employs the Schedule/Queue Table 75 as well as a task queue screen that allows a user to view the task scheduled for execution and the history of prior executions on his monitor 44. The user may search the task queue for specific activities. For example, the user may wish to review the tasks performed for a specific fund. The user may filter the search results by date, name, completion status, etc. Once in the task queue screen, the user may edit or view the tasks schedule. From the main menu 80, the user selects the schedule button 81. The System then displays the task queue window on the monitor 44 at block 82. The System retrieves the next and last run information from the Schedule/Queue Table 75 at block 83. The user can then close the task queue window by clicking the close button 88. The user can double click on an event displayed on the task queue at block 85 to retrieve more information about that event. The user can also click the task schedule button 86 to schedule another task. The user can also click on the view button 87 to view other scheduled tasks.

The System employs 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 set up functions must take place. For example, each asset must be classified for the particular fund. It will be appreciated that different funds may classify the same asset differently. Certain funds may consider "cash" to be cash on hand only while other will consider "cash" to be cash on hand and any certificate maturing in the next 30 days. Consequently, before compliance can be checked, the assets must be classified on a fund level. The timing of the transaction posting has a significant effect on the schedule of compliance checking. Preferably, the trade information is delivered to the compliance system of the financial institution as quickly as possible and the compliance testing performed immediately (ideally, all done in "real time"). However, it will be appreciated that this will not always happen in practice. The transactions are processed on a custody system and the trade date is identified. On trade date or a subsequent date, the transactions are passed onto an accounting system. The accountants adjust the trade data to generate net asset values ("NAV") at the end of the day. The NAV for a fund will not be published until these adjustments are completed. During the trade date, or a subsequent date, the System will receive instructions from the accounting department in the financial institution to open the assets. If the asset does not exist, the System will open the asset and assign it a null position. The data administrator enters the classifications and adjustments prior to receiving the position and transaction data later that day. On the evening after the trade date and after the NAV's have been calculated for the fund, the holding and transaction data will be passed to the System which will then perform the rules check (i.e.. the compliance tests) and notify the compliance analysts of any violations.

Certain transactions are excepted from this processing. Same day settlement transactions are passed directly to the accounting system of the financial institution on the trade date and passed onto the System on the evening of the trade date. (The day after the trade date is referred to as Trade Date plus one). The data administrators will not be given a full day to assign classifications and perform maintenance to any new asset positions. As soon as these trades are posted on the source system (i.e., on trade date), the System will receive the asset open and position data. The System will open the new assets and positions as discussed above but the data administrators will have only until that evening to classify any new assets and positions resulting from these trades. Further, when the internal source system is the custody system, trade data is received on the evening of the trade, allowing the administrator to process compliance on the day after the trade date. The System receives data concerning the assets and positions from source systems.

Asset open data is sent to the System whenever a new position is opened on the source system. A complete asset extract will be sent from the source system to the System each time a new position is opened, ensuring that an asset record is present on the record for every new position. The asset open data will be sent as soon as the trade is posted on the source system. Typically, this occurs on the day after the trade but may occur on the day of the trade. Asset update data is sent from the source system at several intervals during the day. New position data (including the CUSEP, the description and the opening position and units) is also sent to the System whenever a new position is opened on the source system. The data administrator will classify the position. Any changes or additions to the position data will be sent to the System from the source system as soon as possible. Additionally, transaction data is sent by the source system in batch on the night of the day it was posted on the source system. Typically this will be the night two days after the trade. The System uses this information to update existing position records and fill in missing data on the new position records opened on the System earlier that day. If accounting does not complete the adjustments by the end of trade date plus one, the source systems preferably send the trade data to the System as soon as the posting of these trades is completed. In order to provide accurate compliance analysis, the System must maintain precise and timely asset information. The System provides the ability to maintain these data elements manually. Asset data in the System is classified in two overlapping categories. Source data is data generated and maintained solely by a source system, which is not subject to control and maintenance by the System. Fund administration data is data maintained by the System and not downloaded from a source system. For purposes of system operation and analysis, data elements used by a source system will be considered 100% accurate and will not be available for correction by Data Administrators. Data generated by a source system, but not used for any processes prior to transmission to the System, will be considered unreliable, and will require certification by users. The System provides the ability to disable and enable update functions for all data elements, except User ID on a System-wide basis. The business decision will be made on a per-site basis, depending on the individual source system, and can be changed based on the availability of reliable information on the source system. A dynamic Reliability Indicator will classify source system data elements as 'Reliable' or 'Unreliable'. The System does not populate the database with unreliable source system data elements. The System will allow on-line maintenance and will require certification by a user for that unreliable element. The System will not allow on-line maintenance of reliable elements.

The System records all modifications to data element values on the database. Each change will cause the generation of a log record that includes the time-date stamp of the change, the User ED of the person making the change and an optional comment, describing the reason for the change. This allows execution of any report in the System based on the data values available at different dates. It also provides the information for the auditing function. Asset fields that are flagged as unreliable may require manual certification by a Data Administrator. The list of certifiable fields is different within each asset type. The entire asset will not be considered certified, until all certifiable fields have been individually approved by a Data Administrator. The Data Administrator will have the option to postpone certification of the Asset for an interim period (i.e. for two weeks), e.g. where it is accepted in the industry that a data element is not readily available, such as outstanding shares of a new emerging market issue. This kind of certification will be called 'Postponed Certification'. An alert message will pop up on the data administrator's work station after 2 w eeks to remind him that certification was postponed temporarily but now needs to occur. The System will allow multiple versions of a single asset where that asset exists on two distinct source systems. This is necessary because it is possible for the asset to have conflicting data values on each System. Functionality will be provided to enable or disable source updating and required certification based on the source of the data. The Asset Conversion Table will be used during conversion from one Source System to another. On- line access allows data administrators to find assets by any of their identifiers: Asset ID, Description, CUSEP, SEDOL, etc. Source System ID is part of the attributes of the Asset Definition. Users are able to list all assets or all uncertified assets. Data administrators are able to view an Asset's descriptive data, by double-clicking on the asset while viewing a holding position. The User Interface preferably reflects all important steps that the data administrator needs to maintain or certify asset related information. It also describes the functions performed by the System in response to their actions, such as: Selection Assets Item from Data Pop-up Menu; Specifying Search Criteria; Search Criteria Validation; Asset List Retrieval and Validation; Selection from the Asset List; Retrieval Asset Information from Database; Managing Asset Maintenance Screens; Pop-up Asset Menu Activation; Actions to Show/Hide Main Menu Assets Submenu; Saving Asset Information; and Audit Trail of Updates in Asset Transaction Log. This interface permits the user to interact intuitively with the System.

Asset data maintenance/certification will consist of two windows. The first, the Asset Search Screen, will be used to find the appropriate asset item (or list of them) in the database. The second, the Asset Maintenance Screen, will be used to manage data.

The Data Administrator can open the Asset Search Screen by selecting the Data option from the Main Menu Screen, and then the Assets Item from the submenu that will appear. An Asset List will appear in the bottom Section of the Asset Search Screen. It will be disabled by default, and will stay disabled, until the User defines search criteria and performs a database search. The Data Administrator specifies search criteria, and the System returns a list of assets to modify and/or certify. The data administrator activates a search by pressing the SEARCH Button. The data administrator will be able to exit the Asset Search Screen by clicking on the CANCEL Button at any time. This will abort the Asset Management Functions and return the Data Administrator to the Main Application Screen. The top part of this Screen will enable the Data Administrator to define search criteπa. They will enter either prefix or complete information in any combination of text fields in the top of the screen. By choosing one of three radio buttons, the User selects: All Assets, Not Certified Assets Only, Not Certified and Postponed (Assets certified only for a short peπod of time). The System will show an error message if the search criteπa are not specified or are invalid, otherwise it will search the Database, for assets that match the specified cπteria. If no matching assets are found in the Database, the Application will display a warning message. Otherwise, the list of matching assets will appear in the bottom section of the screen. At this point the Data Administrator will choose an Asset to work with, by double-clicking on the Asset List item or by clicking on SHOW Button. If only one item is found, the System will automatically show the Asset Maintenance Screen. More than one Asset Maintenance Screen can be open at the same time, if the Data Administrator returns to the Asset Search Screen and picks additional items from the Asset List (other than one already opened).

The main purpose of the Maintenance Screen will be to modify and/or certify asset related information. It will include all correspondent asset information, as well as the Asset Transaction History. The information on the user screen may be color-coded to readily distinguish between the different status of the information. For example, source information that cannot be changed within the maintenance screen application will have a gray background. Source information that can be changed by the Data Administrator will have a dark-red background. A light-red background will indicate information supported only through the Application. The Data Administrator will be able to make changes to correspondent asset related information by pointing and clicking on the fields of the screen, and enteπng new information (or picking items from corresponding listboxes). If the Data Administrator clicks on the OK Button, the System will verify that updates were made and display an error message if no updates were done. If the Data Administrator confirms the updates, the System will attempt to write the updated/certified information to the Database. It will display an error message if any change is invalid. Also, an appropriate error message will appear if an error is encountered when writing data to the Database. Updates and/or certification information w ill not be saved if CANCEL Button is clicked. If any modifications/certifications were done before pressing the button, the Data Administrator will be prompted about them. The Data Administrator will also be able to certify information in all fields with red backgrounds, as well as the entire record (all information for the given asset). This will be done by clicking on the πght mouse button, on any area of the Asset Maintenance Screen. The Pop-up Certification Menu will appear. Alternately, both field and/or record certification can be done by using the Assets Menu.

The System will provide a "Postponed Asset Certification" dialog box on the user's workstation screen, if the Postponed Certification Menu Item was selected. The Data Administrator will be able to choose to apply default a Certification Postponement Date (two weeks from the current date), Set a New Date, or Abort Postponement Certification Process (by pressing CANCEL Button.) If Postponement Certification Date is selected, the System shows it in the top part of the Asset Maintenance Screen.

Initially, the Main Menu Assets submenu is hidden. However, the System automatically provides this menu when the Asset Maintenance Screen first becomes active, and removes it when the Data Administrator brings any other form on top of the Screen or closes the Asset Maintenance Screen. The System will change the background of certified fields to light-blue. Also, if all current Asset information was certified, the System will show the label "Certified", instead of "Not Certified". Tabs are provided in the bottom sectron of the screen to show additional information. Clickmg one tab will cause the System to display Asset Rating information. Special asset-related information will be viewed by clicking on a tabbed marked "Special". The History Tab will present Transaction Log

Information that will reflect the history of modifications and certifications related to this

Asset. Of course, other tabs may be provided to allow the user to "drill down" on a given Asset, and still practice the invention.

After all changes and/or certifications for the given asset have been completed on the screen, they are saved in the Database as permanent. To do so, the Data Administrator will click on the OK Button of the Asset Maintenance Screen. The System will prompt the Data Administrator to confirm the updates. Upon saving updated information, the System will check the validity of all Database updates, and will display an appropriate error message if it encounters an error when wπting data to the Database, if modifications violate Database referential integrity or if any change is invalid. The System will automatically enter a new record in the Asset Transaction Log Table every time an update has been successfully saved in the Database. Records in this table consist of audit trail information. It includes time of the change. User ID and the previous value. The Asset Transaction Log can reviewed at any time by clicking on the History Tab of the Asset Maintenance Screen. Referring to Figs. 9 and 9A, which depict an asset maintenance flowchart, to bring up the Asset Maintenance Screen, the Data Administrator will select Data and then Assets from the Main Menu Screen at block 92. The user selects item assets from data popup menu at block 90. The Asset Search Screen will appear. The user specifies the search criteria to get a list of assets to modify and or certify which is displayed on the monitor 44 at block 91. The Data Administrator starts a Database search by clicking on SEARCH Button at block 93. The Data Administrator exits the Asset Search Screen by clicking on the CANCEL Button 94 at any time such. This will abort Asset Management functions and return the Data Administrator to the Main Menu Screen. The System will review the search criteria at block 95 and show an error message at block 96 if the Search Criteria is not specified or is invalid. Otherwise, it will perform a Database search of assets matching specified search criteria at block 97. The System will perform Database search for assets matching the combination of entered search criteria. The System retrieves data from Asset Table 98 based on Asset ID, Description or Type, SIC Code, CUSEP, SEDOL, Ticker, Issuer or Source Information. If no conforming assets are discovered, the System will provide an error message at block 96. If assets are discovered, the System will retrieve and present a list of these matching assets and their attributes from Database, in the bottom of the Asset Search Screen.

The Data Administrator may choose an Asset to work with, by picking an appropriate item from the Asset List displayed on the monitor 44 at block 99. At any time the Data Administrator will be able to exit the Asset Search Screen by clicking on the CANCEL Button 490. This will abort the Asset Management functions and return the User to the Main Application Screen. The Data Administrator may instruct the System to start a specific Asset Data retrieval and presentation by pressing the SHOW Button 491. The System will perform Database search at block 493 and retrieve all information for the Asset from Asset Tables 98 based on Asset ID picked by the User. Initially, the Main Menu Assets Submenu is hidden. However, at block 492, this menu will automatically appear when Asset Maintenance Screen becomes active the first time and will disappear when the Data Administrator brings any other form to the top of the Screen or closes Asset Maintenance Screen. The hidden Assets Menu will reappear again if the Data Administrator activates Asset Maintenance Screen by clicking on it. The System will present Asset Maintenance Screen containing current Asset information to change and/or certify that information.

Referring specifically to Fig. 9A, the Data Administrator will be able to make changes to correspondent asset related information at block 494 by pointing and clicking on the fields on the screen. Further, they will be able to certify information in the current field, as well as entire record (all information for the given asset) by using the Assets Menu or by clicking on right mouse button at block 494. If the Data Administrator clicks on the OK Button 495, the System will initiate verification of updates at block 497 and attempt to save them permanently in the Database at blocks 498 and 499. Updates and/or certification information will not be saved if CANCEL Button is clicked. If the system determines that modifications/certifications were entered after clicking the OK Button 495, the Data Administrator will be prompted about them. The System will display an error message if no updates had been done, otherwise it starts process of saving updated information. If the Data Administrator elects to confirm the updates, the System will write the updated/certified information to the Database at blocks 498 and 499 on the asset data database 98 and the transaction log 780. The System will display an error message at block 590 if any change is invalid, as determined at block 499. Upon saving updated information, the System will check the validity of all Database updates and Database referential integrity. Appropriate error messages will be displayed, if the System encounters an error when writing data to the Database, or if any change is invalid.

The System provides the opportunity for the multiple Asset ratings. The rates used are different for different types of securities and regions. The System keeps the history of all changes in the Asset entity using a Journal Table. The System also employs Fund Data comprised of fund specific information as well as logical fields which allow the System to do customized processing and reporting for any fund on the System. Since all holding data on the System applies to specific funds, all holding related data including Asset Positions, General Ledger, Lots and Transactions will be accessed via the fund Maintenance function on the System.

35 SUBSTITUTE SHEET (RULE 2 In the System, most fund related data is entered manually and maintained by Data Administrators. However, some fields are acquired from Source Systems. This data is assumed to be completely accurate, and will not be subject to modification by Data Administrators. All holding information is received from Source Systems, and is treated as accurate and therefore will not be maintained on the System. Changes to holding information must be made on the Source System and passed to the fund Administration System as a correction transaction. All transactions will carry Post and As-of Dates, which will allow transactions to be effective prior to their posting on the System, when necessary.

As discussed above, there are two types of System fund data: Source Data and Fund Administration Data. Source Data is maintained on the Source System and cannot be changed by the Data Administrators. The Source System will extract complete fund data for all funds that reside on the Fund Administration System. The System will do a field by field comparison of all fields in the extract against the fund data in the Database. When a difference is found, the Database fund data will be overwritten with the data in the extract record. The Fund Administration Data specific to compliance checking and unavailable (or unreliable) on the Source System is entered and maintained on the Fund Administration

System by Data administrators. When the fund data is displayed, Source System data (also referred to as accounting data), will have all fields locked and unavailable for input, whereas

Fund Administration data will have all fields unlocked and available for input. Whenever a field is modified either by the System (for Source data) or by the Data Administrators (for

Fund Administration data), the "Last Update Date" and "Changed By" Fields will be updated with the current date and the User-Id/System that made the change. Additionally, an audit trail record will be written for each change with the following information:

Field Name - Name of the field that was changed; Change Date - Date that the field was updated;

Change Time - Time that the field was updated;

Change By - Source System of the new information;

Prior Value - Value of the field before the change.

In addition to providing an audit trail, the audit record will be used for historical reporting. Whenever a report is needed for a prior reporting period, the audit trail record must be checked to determine the value of the fund data fields for that previous reporting period. Whenever updates are made to the general fund data, the System will check their validity and display an error message if any are invalid. The System will them prompt the Data Administrator to confirm all changes. Once completed, the System will attempt to write the add changes to the Database. If any error is encountered while writing the changes to the Database, an appropriate error message will be displayed by the System, otherwise the changes will be made permanent.

All holdings information on the System is related to a specific fund, and is generated by transactions. Every operation, including accruals and amortization, is considered to be a transaction. The Position and Lot information for each asset held by a fund is a sum total of all or specific transactions for that asset. Each asset held by a fund is stored as a separate row in the Holding Table and is logically related to the fund through the Fund ED. The Lots that make up each holding in a fund are stored as separate rows on the Lot Table, and are logically related to the holding through the unique Fund ID - Asset ID combination. Likewise, all transactions will be stored on the Transaction Table and will be logically related to the Asset holding in the fund through the unique Fund ED - Asset ID combination. A unique Lot ID is established to define the relationship between Fund Lots and Transactions.

Asset information for assets held by a fund will be maintainable on the fund level. The Data Administrator can enter values to override global asset values. This feature will be most useful for Industry Classification. Certain funds may classify an asset differently than the accepted global classification. Asset information can also be overridden on the fund group level. This enables synchronized asset information to be maintained for a complete customer relationship. For example, one fund manager may refer to ABC securities as belonging to "Alpha-Beta Corporation", whereas another will use "ABC" to identify a security belonging to a separate corporation.

A graphical user interface allows the user to readily input and change data. When the Data Administrator selects Funds from the Data Pulldown Menu on the Main Menu Screen, the System will display the Select Fund Screen. The Data Administrator will be able to begin typing the desired Fund ED, or Fund Name, in the search boxes at the top of the screen and click on the SEARCH Button to bring up the list of funds that match the search criteria. To bring up the complete list of available funds, the Data Administrator will click the SEARCH Button without entering any search criteria. The System will then display a complete list of available funds for that Data Administrator. The listbox will be able to be sorted in ascending order on either Fund ID or Fund Name, by clicking the Field Button at the top of each column. The Data Administrator will select the fund to view and click the SELECT Button, or double click on the desired fund. With proper authority, they will be able to click on the NEW Button. This will bring up the Fund Maintenance Screen with no data displayed and all general fund information fields unlocked. They can then enter the new fund's data and click on the SAVE Button to add a new fund to the System.

The Fund Maintenance Screen will display all fund related data. The System will display three levels of detail as follows: Fund Level Data; Holding Level Data; and Lot Level Data. Initially, the System will display all fund level data (i.e., general fund information, fund performance, fund holdings, etc.). When fund level data is displayed, summary data regarding the selected fund, is displayed at the top of the screen (above the tab sheets). When the Data Administrator selects a specific asset position, they will have the ability to drill down on that holding by selecting "Holding" from the Detail Level Tree structure displayed on the screen. When displaying information at the holding level, summary information regarding the selected fund and asset position will be displayed at the top of the screen (above the tab sheets), and a different set of tabs will be available for selection. Holding level data includes detail holding information, lot information, etc. The Data Administrator will be able to drill down on a selected lot within the holding position by selecting "Lot" from the Detail Level Tree on the screen. Summary information regarding the selected fund, asset, and lot will be displayed at the top of the screen (above the tab sheets), and a different set of tabs will become available. Lot level data includes detail lot information, lot transactions, etc.

At the fund level, the graphical user interface will provide the following tabs: General Fund Tab; the Fund Performance tab; and the Fund holding tab. The General Fund Tab is displayed for the selected fund. If the Data Administrator has proper access, they will be able to modify the fund administration fields on this tab sheet. All changes will become permanent, when the Data Administrator clicks the SAVE Button. The Data Administrator can return to the list of available funds by clicking on the SEARCH Button. The Fund Performance Tab displays a fund's performance within a User selected from/to period. The Fund Holding Tab displays a list of assets held by the fund. By default, the System will display only currently held positions in the fund, however the User will be able to select the "complete Holdings" option at the top of the screen to display all asset positions for the fund even if the asset is not currently held by the fund (but was held at one time in the past).

The Fund Holding Screen displays the basic holding information regarding the asset position. It will be possible to sort each column in the list, by clicking the left mouse button on the column header for each field. The Asset ID, CUSEP, SEDOL, Long/Short Indicator and Description fields will be sorted in ascending order, whereas the Last Activity Date, Units. Cost, and Market Value fields will be 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 will be able to 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 the list, that most closely matches the value entered. In order to drill down to the holding level, the User will have to select an item from this list. The User will then be able to move to a lower level of detail regarding the selected holding, by selecting "holding" from the tree structure displayed on the screen.

Clicking the Fund Transaction Tab caused the System to display a list of all transactions for the fund within a User supplied from to time period. The Transaction Summary List can be sorted on any field by left clicking on the column header of that field. The Transaction Type will be sorted in ascending order, while all other fields will be sorted in descending order. To see detail information regarding one specific transaction, the User will be able to enter a Transaction ID at the top of the tab, and click on the SHOW Button. Alternately, the User can select a transaction from the list and click the SHOW Button or double click on a selected item in the list. Detail information regarding the transaction will be displayed. Clicking on the Fund General Ledger Tab causes the System to display a list of all general ledger transactions for the fund, within a User supplied from/to time period. The General Ledger Summary List can be sorted on any field, by left clicking on the column header of that field. The Debit and Credit fields will be sorted in descending sequence, whereas all other fields will be sorted on ascending sequence. To display additional General Ledger Transaction, the User will double click on the selected Transaction or select an item from the list and click on the SHOW Button. Once the User has selected a specific holding at the fund detail level, they will be able to view more detailed information about it, by selecting "Holding" from the Detail Level Tree on the Fund Maintenance Screen. Summary data for the selected asset will be displayed at the top of the screen, in addition to the summary data regarding the fund that is displayed at the fund level. At the Holding Detail Level, the user may click the following tabs: Holding Position Tab; Holding Interest Tab; Holding Lot Tab; Holding Transaction Tab; and Holding General Ledger Tab. Clicking the Holding Position Tab will cause the System to display detailed information regarding the selected asset holding. Data Administrators will be able to modify the Asset Classification fields on this tab sheet, but all other fields will be read only. Clicking the Holding Interest Tab will cause the System to display interest information for the selected asset. All fields on this tab are read only.

Clicking on the Holding Lot Tab will cause the System to display a list of the lots that make up this holding position. The list will contain summarized information for each Lot. The Lot Summary List will be able to be sorted on any field by left clicking on the column header of that field. The Lot ID and Transaction Type will be sorted in ascending order, while all other fields will be sorted in descending order. Once the Lot Summary List has been sorted, the User will be able to scroll to the 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 the list that most closely matches the value entered. Before drilling down to the lot level, the User must select an item from this list screen. They can then move to a lower level of detail regarding the selected lot, by selecting "Lot" from the tree structure displayed on the screen.

Clicking on the Holding Transaction Tab will cause the System to display a list of all transactions for selected asset within a User supplier from/to time period. Like the other list screens, this list can be sorted on any field by left clicking on the column header of that field. The Transaction Type will be sorted in ascending sequence, all other fields will be sorted on descending sequence. In order to see detail information regarding one specific transaction, the User can enter a Transaction ED at the top of the tab (instead of a from/to date) and click the SHOW Button. Alternately, the User can select a transaction from the list and click the SHOW Button or double click on a selected item in the list. In all instances detail information regarding the transaction will be displayed. Clicking on the Holding General Ledger Tab will cause the System to display a list of all general ledger transactions for the holding within a User supplied from to time period. This list can be sorted on any field by left clicking on the column header of that field. The Debit and Credit fields will be sorted in descending order, while all other fields will be sorted in ascending order. To display additional General Ledger Transaction fields, the User can double click on the selected Transaction or select an item from the list and click on the SHOW Button.

Once the User has selected a lot at the holding detail level, they can view more detailed information regarding the Lot by selecting Lot from the Detail Level Tree on the Fund Maintenance Screen. When this level of detail (that is, Lot Level Detail) is being displayed, summary data for the selected Lot will be displayed at the top of the screen (in addition to the summary data regarding the fund and holding that is displayed at the holding level). The user will have access to a Lot Detail Tab, a Lot Transaction Tab and a Lot General Ledger Tab. Clicking the Lot Detail Tab will cause the System to display read-only detailed information regarding the selected lot.

Clicking the Lot Transaction Tab will cause the System to display a list of all transactions for the selected lot within a User supplied from to time period. This list can be sorted on any field by left clicking on the column header of that field. The Transaction Type will be sorted in ascending order while other fields will be sorted in descending order To see detail information regarding one specific transaction, the User will be able to enter a Transaction ED at the top of the tab (instead of a from/to date) and click the SHOW Button. Alternately, the User can select a transaction from the list and click the SHOW Button or double click on a selected item in the list.

Clicking on the Lot General Ledger Tab will cause the System to display a list of all general ledger transactions for the Lot within a User supplied from to time period. This list can be sorted on any field by left clicking on the column header of that field. The Debit and Credit fields will be sorted in descending order, all other fields will be sorted in ascending order. To display additional General Ledger Transaction fields, the User will double click on the selected Transaction or select an item from the list and click on the SHOW Button. The Transaction Detail Screen displays detailed information about one transaction.

It can be accessed from the fund, holding, and lot detail levels for both regular and general ledger transaction. It is displayed independently of the Fund Maintenance Screen, as a pop- up throughout the System. All data that appears is read-only, deπving from a Source System. This Screen will display somewhat different fields depending on the transaction type (1 e. Subscπptions, Redemptions, and Option Transactions etc.).

Referπng to Fig. 10, depicting a Fund Maintenance Flow Chart, the User enters the Main Menu Screen 100. The User will select Funds from the Data Menu at block 101. The System will read the Database 780 and check the User's access authoπty at block 102. The System will display the list of funds available to the User at the terminal 44 at block 103. The Data Administrator will be able to close the Fund List Screen and return to the Main Menu Screen. To add a Fund to the Database, the Data Administrator will click on the NEW Button 105. The User will enter the fund data at block 106 at the terminal. The System will wπte new fund information at block 107 to the Database 781 to make it permanent. The User may select a fund from the list, by double clicking on the item or highlighting it and clicking on the SELECT Button 108. The General Fund Information Tab will be displayed at block 109. The User will be able to close the form and return to the Fund List Screen at block 700. The User will be able to select from the different tabs available at the fund detail level at block 704. The User will be able to change the general fund data at block 705. The System wπtes the changes to the Database. The System will access the Database to populate the tab sheets with fund related data at block 701.

Fig. 11 is a continuation of Fig. 10, and depicts the processing of the fund maintenance screen at all three detail levels: fund, holding and lot. The first tab that will be presented to the User contains general fund information 125 . A Performance Tab 111 will be available at the fund detail level. A General Ledger Tab 112 will be available at the fund detail level. A Holdings Tab 113 will be available at the fund detail level. A Tests Tab 114 will be available at the fund detail level. A Transactions Tab 115 will be available at the fund detail level. A Shareholders Tab 116 is available at the fund detail level. The User will be able to close the form and return to the list of available funds form by clicking the

Close button 117. To review the Holding Details, the User will select a specific holding and click on "Holding" in the detail level tree. The System will read the Database 126 and retπeve holding information. The System will display five different tab sheets at the holding detail level at block 710. A Position Tab at block 119 is available at the holding detail level.

An Interest Tab is available at the holding detail level. A Lot Tab is available at the holding detail level. A General Ledger Tab is available at the holding detail level. A Transactions Tab is available at the holding detail level. The user will be able to close the form and return to the list of available funds form by clicking the Close button 1 17.

The User can view data at the fund detail level by clicking on "Fund" in the detail level tree at block 108 (Fig. 10). The User will select a specific lot and click on "Lot" in the detail level tree at block 711. The System will read the Database and retrieve lot information at block 712. A General Ledger Tab, a Lot Detail Tab and a Transactions Tab are available at the lot detail level at block 713. The User can elect to return and view data at the fund or holding detail level by clicking on 'Fund' or 'Lot' in the detail level tree. The User will close the form and return to the list of available funds form. Fig. 12 is a continuation of Fig. 11 and depicts the processing after the user chooses to view transaction data. The System will read the Database 127 and retrieve transactions information at block 120. A different Transaction Detail Screens will be displayed depending on the type of transaction selected. Transaction Detail Screen will display purchase or sale transaction 121, dividends and distributions 122, subscriptions and redemptions 123 and options 124.

The System implements and maintains fund groups, allowing for collective processing of funds on the System. This will serve several purposes. Fund groups will simplify the management of funds by allowing users to run compliance checks and reports on an entire logical group of funds at once. A fund group may contain an infinite number of individual member funds. Similarly, a fund can belong to an infinite number of fund groups. Also, there some funds will not belong to any group, and a fund group can exist on the System without any member funds. Although empty fund groups serve no logical purpose, they do not violate any referential integrity rules, since a parent record is not required to have a child record, and therefore will be allowed to exist on the Database. The System will use an association table on the database to establish fund groups.

All funds on the System will be represented by a unique entry in the Fund Table. When a fund group is created, the Fund Group ED and Group Name will be stored as a record in the Fund Group Table. When a fund is associated with a group, a record containing both the Fund Group ID and the Fund ED will be stored in the association table. Each time that another fund is associated with the group, a new record containing the unique Group ED - Fund ID combination will be stored in the association table. This entry in the association table will logically link groups to funds. Retrieving all records in the association table for a given group will yield a list of all funds in that group. Similarly, retrieving all records in the association table for a given Fund ID, will yield a list of all groups which the fund participates in.

The System will use this logical link in all aspects of processing. Any checking, reporting, or tracking available at a fund level will also be available at a group fund level as well. There is no limitation to the number of funds in a group, and any fund can be grouped with any other fund for necessary or desirable business purposes. Because funds do not have to participate in a group, the System will not automatically associate a fund with a fund group. Creating fund groups and associating funds to the fund groups will be the responsibility of the Data Administrator, using the Fund Group Maintenance Screen.

Referring to Fig. 13, a flow chart depicting fund group maintenance, the user, operating from the Main Menu 130, selects the Data Menu, and then the funds group submenu at block 131. The System then checks the User Access database 134 to determine the access rights of this user at block 132. If the user has no access rights, an error message is displayed on the monitor 44. Otherwise, the System determines whether this user has authority to update funds data. If not, the funds data is retrieved from the database without locks at block 133. The fund groups are displayed on monitor 44 at block 138. After reviewing this data, the user then clicks on the CLOSE button 139 and returns to the main menu. If the user has the authority to update, the System retrieves the funds data without locks at block 136. These fund groups are displayed on the monitor at block 137. The user can close the form and return to the main menu by clicking the CLOSE button 139. Alternatively, the user can click the UPDATE FUND GROUPS button 530. The System determines whether any updating has been done by the user at block 533. If not, the System returns to showing the fund groups for update at block 137. If changes have been made, the user can cancel these changes by clicking the CANCEL button 537. To save the changes, the user clicks on the save button 536. The System validates the screen at block 534 to determine whether there are any errors at block 539. If an error is detected, the System displays an error statement at block 538. If no error is detected, the user is prompted to confirm the changes (i.e., the update) at block 630. The System updates the fund groups database 632 at block 631. The System provides a graphical user interface, the Fund Group Maintenance Screen, to allow the user to readily input information and instructions. This screen is divided into two Sections: Fund Groups and Funds. Fund groups will contain a listbox with all fund groups on the System. The Funds section contains two listboxes: the first will display funds associated with the currently selected fund group; the second will display all of the fund groups that exist on the System. The Data Administrator will have the ability (within the Fund Group Maintenance Screen) to add and delete items from this list.

The Data Administrator can add fund groups by clicking on the NEW Button directly under the Fund Group Listbox. When the NEW Button is clicked, a screen prompting the Data Administrator to enter the fund group information will appear. When this information is entered and the ADD Button is clicked, the new fund group will appear in the Fund Group Listbox on the Fund Group Maintenance Screen. The Data Administrator can add funds from the list of available funds to the list of associated funds by selecting a fund (or group of funds) from the available fund list and clicking on the ADD Button. Similarly, the Data Administrator can remove items from the list of associated funds by selecting a fund (or group of funds) from the associated list and clicking on the REMOVE Button. When all desired funds are added or removed from the association, the Data Administrator will click on the SAVE Button to make the changes permanent.

On the System, "tables" consist of data that allow a code to be associated with a description (short and/or long). The System includes a Table Maintenance portion that allows the Data Administrator to maintain tables on the System. For every table, the codes and their descriptions will be unique. The System will maintain tales for the following data types: Countries, General Ledger Accounts (GL), Issuers, Security Types, Source Systems and Transaction Codes, but others could be included. Other tables currently identified for maintenance in the System include Investment Ratings, State Codes, and Holiday Dates.

For each Country, the Country Code and its description will be maintained within the System. In addition, it will be possible to add a new country and its descriptions, as well as to modify, or delete an existing record. For each General Ledger (GL) Account, the account, as well as a long and short description, will be maintained within the System. In addition, it will be possible to add a new GL Account and its descriptions, as well as to modify, or delete an existing record. For each Issuer, the Issuer Code and its long and short descnption. w ill be maintained in the Issuer Table. It will be possible to add a new Issuer and its descπptions, as well as to modify, or delete an existing record.

For each Security type, the specific Security Type Code and its descnption, will be maintained within the System. In addition, it will be possible to add a new Security Type Code and its descnptions, as well as to modify, or delete an existing record. For each Source System, the specific Source System Code and its description, will be maintained within the System. In addition, it will be possible to add a new Source System Code and its descnptions, as well as to modify, or delete an existing record. For each Transaction Code, the codes and its description will be maintained within the System. In addition, it will be possible to add a new code and its descriptions, as well as to modify, or delete an existing record. For each Issuer, the Issuer Code and its long and short descnption, will be maintained in the Issuer Table. It will be possible to add a new Issuer and its descnptions, as well as to modify, or delete an existing record.

The System provides a graphical user interface to allow the data administrator to readily input information. By selecting Tables from the File Pulldown Menu on the Main Menu Screen, the Data Administrator will open the Table Maintenance Screen. The window will be divided into three sections. The top frame will present a Tables Combo box, containing all tables within the System, maintained by this function. The table selected in this frame will determine the contents of the remaining two frames. The center frame will present a Listbox, displaying the elements of the currently selected table. The bottom frame will present the Item Information. This frame will be used to add, modify, and delete codes on a given table. These frames will allow the Data Administrator to setup and maintain codes and their descriptions on the System.

At the bottom of the Information frame are three buttons: NEW, EDIT and DELETE. To add a new code to a table, the Data Administrator will select a table from the Tables

Combo Box, and then click the NEW Button. To edit a code and its description, the Data

Administrator will select a code, and then click on the EDIT Button. Selecting the DELETE

Button will delete the code and description appearing in the information window.

If the Data Administrator clicks on the NEW or EDIT Buttons, the SAVE, CANCEL, and DELETE Buttons will appear. Once the Data Administrator finishes adding or modifying a code on a table, they will select the SAVE Button to save their changes to that table, or the CANCEL Button to erase any changes made to the Information Frame. The CLOSE Button will close the Table Maintenance Window, returning to the Main Menu Screen.

When first opened, the Tables Combo Box will show the first table, in this case Countries. The list will be filled with the current list of tables that are maintained by this function. By default the list will be sorted by Table Name, with the Tables Combo Box showing only the first table. The Data Administrator will be able to easily locate a table in the Tables Combo Box, either by using the arrow to show the entire dropdown list, or by typing the first letter of the code. The Combo Box will jump to that point in the List.

When the Table Maintenance window is first opened, the first table on the System appears in the Tables Combo Box, and the Table Listbox is populated with all the codes from that table. When the Data Administrator selects another table from the Tables Combo

Box, the Table Listbox is then filled with all the codes from that table. The title of the Table

Listbox will contain the name of the table that is currently being displayed.

When the Data Administrator clicks on the New button, the Information Frame is filled with the required fields to enter a new code for that table. The title of the Information Frame will contain the name of the table that the Data Administrator is currently working with. If the Data Administrator selects a code from the Table Listbox, then the required fields are populated with code(s) and description(s) from that record in the table that the Data Administrator can modify. Referring to Figs. 14 and 14A, flowcharts depicting the table maintenance of the

System, the user selects TABLES from the File menu of the Main Menu 140 at block 141. At block 142, the System then reads the appropriate databases on the System, including the country table 146, the general ledger table 147, the issuer table 148, the security-type table 149, the source system table 540 and the transaction code table 541. After reading and generating the list boxes, the System displays the table maintenance window with the list boxes filled on the user's workstation 44 at block 143. In the tables listbox, the user clicks on the table button 144. The System then displays the tables window with listboxes filled at block 145.

Once the listboxes of the tables window are filled, the user can review the information and close the form by clicking on the close button 741. Alternatively, the user can click on the new BUTTON 542 to add information, such as a new code, to the tables. At block 543, the System determines whether this user has the authority to add a new code. If not. the user is returned to the main menu 140. If the user has the appropriate authority, the field codes are initialized at block 544. The user fills the fields at block 546. The user can click the delete button 549 and proceed to processing at block 745 (discussed below). The user can click cancel 548, in which his changes are deleted and the field codes are initialized again. The user can click the save button 547, in which case the System performs a screen validation at block 641. If the validation fails, an error message is generated at block 642 and displayed on the monitor 44. If the screen validation is passed, the System checks the locks 643. If the lock check fails, an error message is generated at block 642 and displayed on the monitor 44. If the lock check is passed, the database 648 is updated at block 647.

Once the listboxes of the tables window are filled, the user can click on an existing code at block 740 to edit it or delete it. If the user selects to edit at block 649, the System determines whether this user has the authority to edit the codes at block 743. If not, the user is returned to the main menu. If the user has the appropriate authority, the code details are displayed by the System at block 744. The user can then edit the fields at block 546 and the processing proceeds as discussed above.

If the user selects to delete a code at block 742, the System determines whether this user has the authority to edit the codes at block 745. If not, the user is returned to the main menu. If the user has the appropriate authority, the System displays the code details at block 746. The user is then prompted by the System to confirm the deletion at block 747. If the user does not confirm, he is returned to the main menu. If the user does confirm, the locks are checked at block 748. If the lock check fails, an error message is generated at block 545 and displayed on the monitor 44. If the lock check is passed, the code is deleted at block 749.

The System includes a subsystem that provides a User interface which creates and maintains data used by the execution engine to carry out the logic which defines the Compliance tests. The Compliance definition data has three levels: fields, rules and tests. In the lowest level of the data model are Fields. These are the building blocks of the reporting systems and represent raw data fields (or columns in database tables). Some fields are imported from the accounting system, others are generated internally. Rules, the middle data model level, are logical statements build from fields and logical operands for the selection of tested records and pass/ fail criteria. For example, a statement from a prospectus, such as "The portfolio has the ability to invest in futures in an amount equal to but not more than 30% of its total assets", will be translated into the following logical rule: selection criteria: with security type set as "future", condition: SUM of security position value <= total assets * 30 %. Security type set as future, security position value, total assets and 30% are Fields. The top data model level is Tests. A Test is a combination of rules that are executed consecutively on a specified fund or group of funds. Tests allow assignment of a common group of rules. For example, all domestic funds will check both SEC and IRS compliance. Rather than assigning every SEC and IRS compliance rule separately, two tests (or groups of rules), can be created: SEC Compliance and IRS Compliance. These tests will then be assigned to a fund or a group of funds.

Any Compliance Rule can be represented in a logical form using logical operators and fields. All information necessary to verify rules can be extracted from the source, loaded from outside data sources or calculated based on some known data or rules. The list of operators that describe 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 elements.

This structure will allow reuse of rule and field definitions, as well as customization of rules for each business situation. A library of rules can be developed. When a new rule is to be added to an existing fund, or a new fund is to be added to the system, the fund administrator can review the rule library, pulling any existing rules that have been employed previously. This allows the development of a set of rules quickly, without the necessity of reprogramming a rule for each new application. Every element in this subsystem has a numeric ID, free-form name and a description. Different locations can adopt names illustrating the purpose of an element, using different naming conventions. For example, a rule may be names as follows: Future % Restriction, Future Holdings Limit. The Compliance Subsystem enables testing (that is, execution) of a newly created or modified rule. Only authorized Data Administrators will be able to change field, rule and test definitions. All changes will be logged to the table. The System maintains all definitions in the database tables and uses them to translate currently defined logic in the tables into small programs or rules that can have two or three return values; Violation, Warning and Pass, depending on the data. Most of the data elements are defined and maintained by Data Administrators and therefore 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 elements from the next higher group in the hierarchy, with logic connecting them together. Parameters are used to pass data to the rules and allow creation of the generic rules with the same logic but different values. All compliance definitions and testing functions are accessed through subitems listed in the Compliance submenu on the Main Menu Screen.

To define a complex field, the System, computer server and the computer database are involved. All defined field types must be requested. All records are retrieved from the field types table. Any new field types are named and described. This information is verified. The name of the field is sought in the table of fields and reported to the user. The field command and request are saved. A row is inserted into the field table. If the save is successful, the field ID is sent to the database. The field definition is entered for the selected type. The user requests all fields and functions that can be employed to build a complex field. The user then defines the complex field as a function of the retrieved fields and functions. This new complex field is saved in the complex field definition table.

There are 6 types of fields:

Base - Fields that are imported from the Source System and stored in the Database or calculated by the System using predefined algorithms. Examples of such fields are: stored (e.g., Market Value, CUSEP) and calculated (e.g., Total Net

Assets, Adjusted Net Assets).

Remapped - Fields that are used to group values into a single classification.

There will be two different Remapped field types: Range and Value. Numeric values can be grouped using the Range type fields. For example, Days to maturity can be grouped to the New Field Maturity Intervals in the following way: Between 1 and 30 days => field value "Less than 30 days" Between 30 and 60 days => "From 31 to 60 days", etc.

Table driven fields can be remapped using Values, i.e. Country can be remapped to the Region the following way:

If the Country is US, Mexico or Canada the Region will be "North America" If the Country is France or England the Region will be "Europe", etc.

Parameters - Fields that are used to pass data to rules. An example of a rule with a parameter i s :

Fund cannot invest in XYZ country

XYZ is the parameter passed to the rule. The parameter allows the same rule to have many different variations, for example:

Fund cannot invest in Japanese securities" Parameter XYZ = "Japan" Fund cannot invest in Mexican Securities" Parameter XYZ = "Mexico"

Constants - Fields that have a constant value. These fields used internally for the rules definition, for example: The Constant field named "Thirty three %" can have a numeric value of 33.

Complex - User defined field containing a combination of other fields linked together using standard arithmetic and logical operators, for example: the Complex field Gain/ Loss can be defined as Market value - Cost.

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

Each type of field has a corresponding prefix in the list. Fields are created in the following order: base fields will be extracted from the Source System and then system fields will be calculated based on base fields. These categories of fields will be created during data importing. Remapped fields will be updated using base, system, parameter fields and remapping tables. Complex fields will be created based on the definition and values of all other fields. The Fields Maintenance Screen displays a list of all currently defined fields grouped by category and sorted alphabetically within a group. The Summary and Definition Tabs cover field detail information. The Summary Tab shows general field information including: ID, Name, Type, Description and History of Field Maintenance. The Definition Tab, if a field type is complex type, presents two lists of fields that can be used to create a complex field (all base, constant, remapped, system and parameter fields). Thus, this screen presentation varies based on the type of a current field. Further, it is not used for base fields. The Definition Tab for remapped fields presents a lists of fields (all base fields) that should be used as the source for this field, type of remapped field (range or values) and a table of remapping with facilities to add, remove or edit entries. As discussed elsewhere, a "rule" in accord with the System, is a logical statement representing a verbal restriction deriving from a fund prospectus, SEC or ERS document. A rule can only have two or three of the following results: Pass, Warning, Violation. Each rule consists of the following four parts: input (a list of fields (parameters) that are used to pass data to a Rule - some Rules will not have parameters); selection criteria (a set of logical statements identifying records that should be included in the application of the rule, i.e., the check); output (a list of fields, with optional sort and group by indication, used in the check that should be included in the report if a check fails); and rule definition (logical statements describing limitation of one of the output fields using of the two forms; concentration and absolute; the concentration form defines numeric limits (thresholds) on a ratio of two fields while the absolute rule form defines values in one field or a combination of values of one field and values in another field that trigger violation and/or warning).

A Rule definition creates records identifying each element of the rule and used by the execution engine of the System to apply defined logic to the defined subset of data and check for thresholds for a Warning and/or Violation. The data model is hierarchical and all elements, including functions and operators, are referenced through links in the existing tables. The benefit of this approach is that functionality can be extended (e.g. new functions or rules created) without any coding in the front-end application.

The Compliance Rules maintenance screen is composed of two frames. The left frame is a Listbox of all available rules. The right frame contains detail information of the selected rule. By clicking on a Rule in the Rule Listbox, the User can select a Rule for viewing or modification. By clicking on the New button, the User can create a new Rule. The System creates a new unique Rule ID. All other fields in the Rules Information frame are initialized. When rule definition is complete, the User clicks the Save button to store the new rule, or click the Cancel button to cancel the operation.

The right frame contains five tabs for Rule Information. The first tab is the Summary Tab. It contains general information about the rule, such as: Rule type,

Description, and Name. The Parameters Tab contains information that enables the user to customize a Rule for a Fund. In this screen the user can define the list of parameters that are used by the Rule. The Rule Maintenance - Selection Tab allows the User to define criteria in order to select a subset of the Fund Data that the rule is being applied to (i.e. - Use only Fixed Income security types). The Rule Maintenance - Output Fields Tab allows the User to define the fields the will appear on the Rule Report. This function will also provide the ability for a User to define sorting and grouping criteria. The Rule Maintenance - Definition

Tab (Concentration Rule Type) allows the User to specify the fields being used for compliance checking and to define the violation and warning thresholds for those fields. The Rule Maintenance - Definition Tab (Absolute Rule Type) allows the User to select the fields for a simple absolute rule. (e.g. - No futures allowed in portfolio). The User can select two fields for a tabular absolute rule (e.g., Securities of different types have different restrictions on their term).

A Test is a combination of rules that is applied to a fund or a group of funds formed by a list of links to the elements of rules list. All rules in a test are independent and do not have links to the data or results in other rules. This data entity was created for the convenience of assigning multiple rules to a fund or a group of funds.

The user interface for the 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 is composed of two frames. The left frame is a Listbox of all available tests. The right frame contains detail information of the selected test. By clicking on a Test in the Test Listbox, the User can select a Test for viewing or modification. By clicking on the New button, the User can create a new Test. The System creates a new unique Test Id. All other fields in the Test Information frame are initialized. When Test definition is complete, then the User clicks the Save button to store the new test, or clicks the Cancel button to cancel the operation. The right frame, for Test Information, contains three tabs. The first tab is the Summary Tab. It contains general information about the test, such as: Test Description, and Name.

The second Tab is a Rules Tab which allows the user to select what rules will be executed within the test. Two listboxes show the User the list of available rules, and rules assigned to the test. The third tab is a History Tab which shows the User when the test was created and last update, and by whom the modification was done.

The system includes a compliance engine which is used to apply the rules to the fund data. Compliance test execution will be requested in two ways: via on-line menu or from the schedule or Task Queue. It will be use a combination of stored procedures, as well as some direct SQL requests, in order to provide Database connectivity. In both cases, the Engine collects all rules requested for the same As-of7Cut-off Date combination from the Task Queue. The Compliance Engine will combine execution of multiple rules in order to provide high efficiency. Data gathering will be done via calls to the various relevant data bases on the Server. All Warning/Violation checking will be executed on the Application Server without additional access to the Database Server. Referring specifically to Fig. 15, the System will receive a request for a compliance check from the Task Queue to Block 150 or an on-line user at block 151. The Engine will collect information about all fields used in the specified set of tests and look for similar requests pending on the Task Queue 153 at block 152. This permits a more efficient operation of the System as all these similar requests can be run together. At block 154, the Engine will retrieve data from the Database 156, using a series of the stored procedures and develop Temporary Tables 155 with the current field balances for use in the tests. This process will provide minimal data access, because most of the rules/reports will share the same data. For example, if 20 rules used in several tests are required to reconstruct CUSEP, SEDOL and Asset Description for certain As-of/Cut-off Date combinations, the System will create a list of these values only once and then use it for all other rules. At block 157, the System determines whether the "as-of date is the last business day of the fund. If As-of Date is not the last business date of the fund, the Application Server will generate a series of requests at block 158 to execute stored procedures to adjust values of retrieved fields for the As-of/Cut-off Date combination. In particular, the System will retrieve data from the History Journals stored on the computer database 159 and modify the Temporary Tables 155 accordingly.

After data adjustments the temporary table created will be passed to the Application Server, which will provide sorting, criteria verification and reporting for all individual rules at block 552. This process will be totally independent from the Database Server. The estimated number of rows in the retrieved table is 100 to 500 at the most. The estimated number of fields is no more than 50. There will be one dedicated connection for each logged in on-line User to provide for on-line dialog requests. This connection will be made by the Application Server, not the User. The User will not be connected to the Database at all. Each Application Server will maintain the connection pull with an adjustable number (during fine tuning) of Database Server connections. Connection requests will be Queued by the Application server. This will provide the opportunity to execute some requests in parallel mode to increase performance of the System and take more power from the Database Server, at the same time as splitting the data manipulations between Application and Database Server.

The System automatically notifies the fund administrator and the fund manager of certain scheduled events, as well as compliance violations and warnings. These notifications can be send via facsimile, beeper or e-mail. Preferably, rule violations are reported in a results report or via the on-line Results Tracking feature. Contact names for a fund are entered into the System but a default contact may be provided. Different contact names (having different delivery methods) may be associated with different events. The notification screen can be accessed from either the Task scheduler or from the fund maintenance screen. The notification screen contains a listbox of available contacts within the System. The data administrator can select a user for notification and a method of notification from listboxes. The data administrator must select at least one notification trigger, i.e., a System event or test result, etc. that causes notification. When the notification trigger is a compliance test result, the trigger options in the

"Notify For" frame will be either warning or violation. The data administrator can select either or both of these options. If the notification trigger is another system event, then the trigger options in the Notify For frame will be success, Failure and Delayed. Again, the data administrator can select on any combination of these. Once these fields are completed, the data administrator can save this information to the database. The data administrator can click on 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 the contact. Referring to Fig. 16, depicting the notification request flow chart, drop down menus and other user interface devices may be employed to simplify the submission of this information. The database tables are read at block 161 from the contact notification delivery database 162 based upon the fund ED and the test ID to fill the screen listboxes at block 163. The listboxes are filled on the screen of the monitor 44 with this extracted data. When any field is modified, the SAVE 169 and CANCEL 560 buttons are activated. A subroutine is called up that moves tree items from one listbox to another. All data fields are validated for accuracy and validity. The data on the Notification Delivery Table 564 is modified and stored at block 563.

Referring to Fig. 17, depicting a contact maintenance flow chart, the database tables

173 are read at block 171 based upon the fund ID and the test ED to fill the screen listboxes on the monitor 44. The listboxes are filled on the screen with this extracted data at block

172. The user can click the CLOSE button 175 to return to the application module 170. The user may then edit the fields. If the user clicks the FIELD UPDATE button 176, the System activates the save and cancel functions at block 177. If the user clicks the CANCEL button 179, the System initializes the screen of monitor 44 at block 570. If the user clicks the SAVE button 178, the System validates that the data entered by the user is appropriate at block 571. If the data is determined to be incorrect at block 572, the System sends an error message to the monitor 44 at block 575 and returns to the field update screen. If the System does not determine that incorrect data has been entered at block 572, the contact database 574 is updated at block 573. The System then returns to the field update screen.

Referring to Fig. 18, depicting a Notification Delivery Service flow chart, the contact database tables 182 are read at block 181 based upon the fund ID and the test ID to fill the screen listboxes. The method of notification (i.e., beeper, fax, e-mail) is determined from the database at block 183. The message is formatted for beeper, e-mail or fax at blocks 184, 185 or 186 respectively. The System then contacts another software program at block 187, such as Lotus Notes, to send an appropriate message via the prefeπed method at block 188.

The System permits the compliance analyst to select and run various compliance tests, including IRS and SEC tests, and tax and financial reports. Reports are generated and notification is transmitted if appropriate. In particular, it is preferred that the following reports be available: prospectus tests, IRS Diversification Report, SEC 1940 Act Report and SEC 2a-7 Report. The compliance analyst may specify the anchor dates interval, i.e., the "as of, the "to" and the "cut-off 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 the compliance analyst in entering this data. A record is inserted in to the task queue indicating which tests are to be run. A server-based process will run the tests and provide the report as requested.

Referring to Fig. 19, the user selects reports from the main menu 190. Compliance, ERS and SEC data are read at block 191 from the database 192. The user must then click on the SEARCH button 193 to select the Fund Open window at block 194. The user finds and selects a fund, and then closes this window. The fund ED, name and active post date is displayed at block 195 in the top part of the Compliance Reports Window but may not be edited here. The user enters the as-of dates and the cut-off dates at block 196. The user then selects the SEC, ERS or Compliance tabs 198, 490 or 492, respectively. A list of tests for each category will be shown and the user selects (or deselects) all tests desired to be run at blocks 199, 491 or 493, respectively. The user then selects the means of report delivery at blocks 495, 496 or 497. If the test is scheduled to be run "NOW" by clicking button 498, it will be queued up immediately at block 590. The System determines whether scheduling is necessary at block 593. If not (i.e., the test is to be run now), the report is scheduled to run immediately at block 594 and placed on the queue table 595. If the user has indicated that the test will be run later by checking button 499, the task schedule dialog box will be open at block 592. 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 a record of the response) from inception. The subsystem for tracking violations consists of 5 modules: Results tracking Service; Automated Response Service; Manual Violation Generation; Results tracking User Interface; and Violation Detailed Display. The Results tracking Service will track all automated rule warnings and violations. During the execution of a compliance test, the compliance engine will invoke this service when a fund is in warning or violation for a rule and all rules for the test have been processed for a fund, whether successfully or not. The Compliance Execution Engine will format a message that contains: Fund ID - The unique identifier of the Fund being tested; Test ED - The unique identifier of the Test being performed; Rule Number - The unique identifier of the Rule in violation (for Rule Violation Message); Date Time Stamp - The time and date of the violation; Description - A brief descriptive of the violation; and Type - Indicator noting whether this violation is a Warning or Violation. (W V).

When a rule violation message is received from the compliance engine, it will be recorded on the Database. The information passed from the engine will be stored on the System Database, along with an indicator that notes whether the source of the violation was the automated engine. When a test completion message is received from the compliance engine, the System will determine the violation state of the test. If any rule within the test has been violated, then the test will be considered in a state of violation, and a message will be formatted and sent to the Notification Delivery component. If there were no rule violations within the test, then the test is not considered in violation state, and a request will be made to the Automated Response component, to turn off any automated violation. Automated Response Service will automatically post a response to an existing violation. If the execution of a compliance test on a fund does not generate any violations, the Results tracking Service will call this module to post a response to an existing violation, if necessary. If the fund was had a previous open violation for the same test that was generated automatically, then the Automated Response Service will post a Response, indicating that the fund is no longer in violation, and will turn off the violation indicator. If the open violation was generated manually by a User, then the service will post a response indicating the successful completion of the test. However, the violation indicator will be left on. This service will not be able to not turn off a manually generated violation.

The Results tracking User Interface provides a graphical interface to allow Users to display and print a report of current and previous violations. The User can delimit a report request by fund, Test, Rule, Violation/Warning indicator, or Automatic or Manual generation indicator, and its status. Additionally, the User can provide a date range for the request. Once the report is displayed, the User can request a hardcopy print. They can also request a detailed display of a single violation. It will also be possible to open a new violation manually.

The Manual Violation Generation provides for the manual posting of a compliance violation or warning. An authorized User can flag a fund as being in violation of a rule/test. By manually triggering the violation, the Violation Notification process will be automatically be invoked. A graphical User interface will allow the User to manually enter results tracking data (noted above). Once a manual violation has been created, it can only be turned off manually by an authorized User. Manual violations will be tracked the same as automated violations.

The Violation Detail Display provides for the display of detailed information of a single violation. It will provide all information on the Results tracking User Interface.

Additionally, it will provide the time of the violation, what contacts were notified, and a list of all rules that caused the violation. The User will be able to view and add responses to the violation.

The Results tracking Screen is used to view current and historical compliance violations and the responses to those violations. The screen will be composed of three sections. The upper left side of the screen will be used to quantify the selection criteria for violations. The User can select a tab for fund, test, or filter selection. The upper right side of the screen is used to display the violations that appear as a result of the selection. The lower part of the screen will contain buttons that will allow the User to retrieve violations, select a violation for detailed viewing, create a new manually generated violation, or close the screen.

The Fund Tab will allow a User to select the funds for which to display violations. By entering a Fund ID, Partial ID, Fund Name or Partial Name, the User will select the SEARCH Button to retrieve the list of matching funds from the Fund Administration Database. If no ID or Name is entered, then the entire list of funds will be displayed. The User will then select a fund to be used for selection. The User can easily scroll through the list by using a scroll bar on the side of the list.

To select a fund, the User will move the cursor to the fund desired and click on the left mouse button. The fund will be highlighted. If more than one fund is to be selected, the User can either click on the SELECT ALL Button, to select all of the funds in the list, or they can click on other funds while holding down the CTRL Key. The Tests Tab allows a User to select the compliance tests for which to display violations. By entering a Test ID, Partial ID, Test name or Partial Name, the User will select the SEARCH Button to retrieve the list of matching Tests from the Fund Administration Database. If no ID or Name is entered, then the entire list of Tests will be displayed. The User will then select a test to be used for selection. The User will be able to scroll through the list by using a scroll bar on the side of the list.

To select a test, the User will move the cursor to the test desired and click on the left mouse button. The test will be highlighted. If more than one test is to be selected, the User can either click on the SELECT ALL Button, to select all of the tests in the list, or the User can click on other tests while holding down the CTRL Key. The Filters Tab is used to filter the requested violations by its status, violation level, source of creation, or by date range. Any and all of the criteria may be used if the User so decides. The Status checkboxes allow the User to request either Open or Closed violations. The Level checkboxes allow the User to request violations in Warning or Violation. The Creation checkboxes allow the User to delimit the request by how they were generated, Automatically by the System, or Manually by a User. Additionally the User will be able to enter a date range for selection.

Once all requested fields are entered the User will click on the RETRIEVE Button. This triggers a query against the Results tracking database. The result of the query is displayed in the table at the upper right side of the screen. The resulting Violations Table contains the Fund ED of the fund in violation, the Test ED of the test that failed, the date of execution, the c rent status (Open/Closed) of the violation, the level of the violations (Warning/Violation), and the source of the violation (Manual/Automatic). The User can select a violation for detail processing by positioning the cursor over the detail line, and either double clicking the left mouse button, or single clicking the mouse button, and clicking on the SELECT Button at the bottom of the screen. This opens the Violations Detail Screen. By clicking on the NEW Button, the User can open a screen to manually generate a compliance violation.

Not all compliance checking can be performed automatically. Certain results must be calculated off-line by the compliance analyst. The System of the instant invention allows the compliance analyst to enter the results of these manual investigations onto the System. Any compliance reports (or other reports) will include not only the automated testing performed by the System but also the manual calculations performed by the compliance analyst.

.The user can create a manually generated violation, automatically loading the current date and time, the ED of the User requesting the violation. The User will provide the Fund ID, Test ED, and requested level of the violation. The User then selects the rule in violation from a combo box. The User is required to enter a brief description of the violation. By clicking on the SAVE Button the violation data will be stored on the Results tracking database. The User can cancel the operation by clicking on the CANCEL Button. To close the screen, the User will click on the CLOSE Button.

The Violation Detail Screen displays detailed information about the violation selected on the Results tracking Screen. The top frame on the screen contains detailed information about the violation. Fund ED, Test ED, Date and Time of violation, Violation level, the status of the violation, who created the violation (or System), and who was notified. Additionally, a combo box allows the User to see all of the rules that caused the violation. As a rule is selected, the description is filled in to it's right. The lower half of the screen displays all of the existing responses to the violation in a listbox. The table shows the date and time of the response, who entered the response (or System), whether the response closed the violation, and a text message. The User can enter a new response by clicking on the NEW Button. This will add a new Response detail at the top of the listbox. The Date, Time, and User will be initialized by the System. The status column is initialized to Open. However, a dropdown box with the values of Open and Closed will be created if the User clicks on the field. This will allow the User to close the violation. When the User clicks on the Text field, the field will be unprotected to allow entry of data. Once all the fields are filled, the User can click on the SAVE Button to store the data. The User can cancel the update by clicking on the CANCEL Button. By clicking on the CLOSE Button, the User will close the screen.

Referring to Fig. 20, depicting a results tracking flow chart, the results tracking process will receive a formatted message from the compliance engine at block 200. If the System determines that the message is for a Rule violation at block 201, the System will retrieve violation occurrence information from the database 205 at block 204. The message will contain: Fund ID, Test ID, Rule Number, Date, Time, and Violation/Warning indicator. The message is for a Test completion, the Rule Number will be zero. By checking the Rule Number field, it can be determined if the message is a Test completion or Rule violation message. In the event of a Rule violation, the process will store a Violation Occurrence detail at block 202 on the database 203. When a Test Completion is received, the process must determine if any rule within the test was violated at block 207. By accessing the Violation Occurrence Table 205 this can be determined. Keyed access is: Fund ID, Test ED, Date, Rule number. If a Violation Occurrence is found that means that the Test failed. In the event of a Rule violation, the process will store a Violation Occurrence detail on the database. In the event of a successful test, a message will be formatted at block 206 to respond to an existing violation of this Test for the fund at block 600. In the event of a test failure, a message will be formatted at block 208 to pass to the Notification Delivery Module at block 209.

Referring to Fig. 21, the automated response of the System is depicted. Using the formatted message received, a Violation response message is formatted at block 210. A Violation Response occurrence is created at block 211 on the database 212. By interpreting the message received, it can be determined if the message was from the Front end module to create a response, or from the Results tracking module. If an Automated response is received for a automatically generated violation (as determined at block 213), then the module will close the violation. The violation occurrence database 215 will be updated at block 214. Key fields used are: Fund ED, Test ED, Rule Number, Date, and Source.

Referring to Fig. 22, the creation of a manual violation is depicted. The user selects the violation tracking menu 228. Screen fields are formatted at block 220 with data passed from Results tracking User Interface and System data. The user then inserts any manual violation recording at block 229. If the user clicks on the CANCEL button 223, screen data is initialized for new User input at block 227. If the user clicks on the SAVE button 222. Violation Occurrence and Violation Detail database records are stored on the database 226 using screen data at block 225. The user can close this window by clicking the CLOSE button 224.

Referring to Fig. 23, starting at block 230, the violation tracking menu, the detailed display of violation information is depicted. The System reads the Violation Responses at block 231 from the System Database 232. Keys are: Fund ID, Test ID, Date. The System reads the Violation Details at block 233 from the System Database 232. Keys are: Fund ID, Test ID, Rule Number, and Date. The screen is formatted at block 433 by filling the combo box with Violation Details and filling the data tree with Violation Responses. When the user clicks on the NEW button 234, a new response or detail line is created at block 234 in the data tree with current date, time, and User ID. Update fields are provided for Status and Text. Clicking the SAVE button 237, Violation Response are stored at block 539 on the System Database 232. Any new detail line in data tree is removed.

The user can cancel the changes by clicking the CANCEL button 238 and the System will remove the new responses at block 239. Of course, the user can click on CLOSE 530 and shut this window. Referring to Fig. 24, the operation of the user interface for results tracking is depicted starting at the main menu 240. All screen fields are initialized at block 241. Clicking on NEW 243, messages for manual violation processing are formatted at block 244. The window for Manual Violation Creation is opened at block 245. Clicking on the SEARCH TESTS button 246, using Test ED and/or Test Name, all matching Tests are retrieved at block 247 from the database 249. Similarly, clicking on the Search FUNDS button 440 using Fund ID and/or Fund Name, all matching funds are retrieved from the database 243 at block 441. Test Listboxes are built and displayed using Test data at block 248. Fund Listboxes are built and displayed using fund data at block 442. Clicking on the deselect all button 445, the System removes all selections from Tests/funds (or "unselected") at block 446. Select all Test/funds are selected at block 448 by clicking the Select All button 447.. Violation Occurrence Table is read at block 540 by clicking the retrieve button 449. A violation list is displayed at block 542. Keys used are: Fund ID, Test ED, Date. A violation listbox is built using Violation Occurrence data. The window for Violation Detail Viewing is opened at block 544 by clicking Select 543.

The System provides management reports that report on the differences between the As-of date and the post date values including a General Ledger Report and a Holdings Report. The System accepts information from the accounting source on a post-date basis. Actual transaction postings (i.e., generating holding values from transactions) are not currently performed in the system. The General Ledger Report will show the cash balance data for a fund as it was received by the System on a specified trade date as well as the Debit and Credit totals for transactions received by the System after the original posting date but prior to the cut-off date. Each detail will also show the requested Trade date balance including the cut off date differences. The user may view the transaction detail that comprises the difference between the original as of date balance and the as of date balance including the cut off date transaction. Both the balance and detail reports may be viewed and printed. The Holding report shows the holding level details of the fund. Each detail contains the asset ID and description of the asset as well as the unit and cost values. Unit and cost are shown as they were received by the system on a specified trade date. The report also shows the aggregate values (unit and cost) of transactions received by the system for the trade date after the original posting date but prior to the specified cut-off date, as well as the new trade date value, including the additional cut-off date transactions. The user may view and print the balance and detail reports. When selecting the General Ledger or the Holdings management report, the user will be requested to provide selection criteria, such as the relevant dates, before being able to retrieve the data.

Referring to Figs. 25 and 25A, which show the development of the General Ledger report, the user selects the General Ledger report from the main menu at block 250. All selection criteria on the screen are initialized at block 251. The fund search window is invoked by clicking the SEARCH button 254 to allow the user to select a fund for processing at block 255. Selecting the retrieve button 253, the General Ledger data is retrieved from the database 258 at block 256. The tables to be selected are the General Ledger Account, the General Ledger Balance and the General Ledger transactions. The selection criteria include the fund and the as-of and cut-off dates. Using the general ledger balance and the general ledger transactions, the as-of balances needed for the report are calculated at block 257. The balance data is formatted into a spreadsheet on the user screen 252 at block 259. Selecting the DOUBLE CLICK button, a new spread sheet is formatted with transactions for requested detail at block 654 (Fig. 25A). The user can select the print buttons 650, 655 or the preview buttons 651, 656, in which cases the System will call up the print function at blocks 653, 658, either printing or displaying the report. Of course, the user can select the CLOSE button 657 to close the application.

Referring to Figs. 26 and 26A which depicts the generation of the Holding Report, the user selects the Holding Report from the main menu at block 260. All selection criteria on the screen are initialized at block 261. Clicking on the SEARCH button 264, the fund search window is invoked to allow the user to select a fund for processing at block 265. Clicking on the RETRIEVE button 263, the Holding and Transaction data are retrieved from the database 268 at block 266. The tables selected are Holdings and Transactions. The selection criteria include the fund and the as-of and cut-off dates. Using the Holding balance and the Holding transactions, the as-of balances needed for the report are calculated at block 267. The balance data is formatted into a spreadsheet on the user monitor 44 at block 269. The user can click on the PRINT button 659 or the PREVIEW button 699 and the System will call the print function at block 658, allowing the holdings report to be printed and/or displayed. The user can click on the screen on the holdings report, and view the transactions for that particular holding. In particular, the user double clicks the holding at block 698 and the screen is then formatted with the transactions at block 664. A new spread sheet is formatted with transactions for requested detail at block 664. The user can click on the PRINT button 655 or the PREVIEW button 656 and the System will call the print function at block 658, allowing the holdings report to be printed and/or displayed. The user can click on the CLOSE button 657 and close the holding report. The System allows the System Administrator to generate two System Access

Reports: The Report By User and the Report by Access Rights. The Report By User will show which User IDs have access rights to specific funds, fund groups, rules, tests, and System functions, as well as their read write privileges. The Report by Access Rights shows which Access Rights are accessible to which Users. The Data Administrator may select a unique subset of User Accounts and Access Rights to report on each session. A User Event occurs each time a function is initiated, a modification to data occurs, or a User leaves a function within the application. A Violation Event occurs whenever a User logs into the application with an incorrect password or attempts to log into the application after their User Account was disabled. Any standard software package will allow the System Administrator to preview a report before printing it, and will provide the standard Windows NT environment print features. Referring to Figs. 27 and 27A which depict the generation of the report by Access

Rights (or Activity or User ID), the System Administrator selects the Users include in the report header line, and which Access Rights to list in the report detail lines. Alternatively, the System Administrator may select the Access Rights to include in the report header line, and which User IDs to list in the report detail lines. To open the System Access Report Screen, the System Administrator will select the

System Access Option from the Report Menu on the Main Menu Screen at block 270. This screen will allow the System Administrator to flexibly report on this screen will have two tabs: Report by User and Report by Access Rights. Each tab is divided into two windows. The lςft will contain a listbox for specifying report headers. The right will have two listboxes for determining the report's detail lines. On both tabs, clicking on the right mouse button while positioned on an item in a listbox will cause a shortcut menu to appear. In a User ID or Categories Listbox, the following options will be available: Details, List Selected, and List Available. Details will display detailed information about the User ID or Category. List Selected will list all User IDs or Categories currently selected for the report. List Available will list all User EDs not currently included in the report. In an Available or Reported List Boxes, clicking on the right mouse button while positioned on an item in the Available or Reported List Box, will bring up a shortcut menu with the following options: Add, Remove, Details, Collapse All, and Expand All. Add and Remove function as described in each section below. Clicking on DETAILS will bring up a pop-up box with detailed information about the item selected. Collapse All will collapse the tree list to its highest level of detail. Expand All will expand the tree list to its lowest level of detail. The System Administrator can preview a report before printing, by clicking on the PREVIEW Button. A preview of the printed version of the report will appear. After reviewing the report, the Administrator will be able to print the report to their default printer, by clicking on the PRINT Button. When these buttons are selected, the System tables are read to generate the requested report. When the System Access Reports Screen is first opened, the Reports by Users Tab is visible, showing the last record worked on. The User Listbox will be filled at block 271 with a list of current Users from the database 273. The user database includes information from the user profile table, the function table, the fund table, the fund groups table, the rules table, the tests table and the access rights table. By default the list will be sorted by Last Name and displayed at block 274 on the work station 44. However, the System Administrator can also sort this list by First Name or User ID, by clicking on the appropriate column header. To locate a particular User Account, the System Administrator will be able to 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. The System Administrator will click on one or more User Accounts in the listbox, to select header(s) for a report.

To select all of the User Accounts, the Administrator will click on the tree list label "User^*', at the top at block 276. When a new report is requested, the tree list in the Reported Rights Listbox will be blank. To select detail lines for the report, the System Administrator can either double click on the Access Rights in the Available Rights Listbox, or single click on each one and then on the ADD Button. The selected Access Rights will now appear in the Reported Rights Listbox. Groups of User EDs and Access Rights can be selected for printing or removal from the report, by expanding or collapsing the relevant tree list. To remove an Access Right from the Reported Rights Listbox, the System Administrator can either double click on it, or click on it and then on the REMOVE Button. Assuming the User Account has access to the rights listed, they will be reported as detail lines in the report. Specifically, the user clicks on the USER ID button 670 and the details of the user ID are displayed at block 675. The user may also select the USER ED (HEADER) button 671 or the ACCESS RIGHTS button 672 and the listbox will be filled accordingly. The user can then click the PRINT button 679 and the System will read the access rights database table 273 for the header and detail information at block 679. A hardcopy report is printed at block 771.

If the user clicks on the PREVIEW button 678, and the System will read the access rights database table 273 for the header and detail information at block 770. The report will be displayed on the monitor 44 at block 772. The user can then click PRINT button 773 and a hard copy report will be printed at block 775. The user can also click the CANCEL button

774 and the field tabs will be initialized at block 776. The user can click on the ACCESS RIGHTS button 673 and the System will display the access rights details at block 679. Further, the user can simply click the CLOSE FORMS button 674 and the System will close the forms accordingly.

The Report by Access Rights Screen functions like the Report by User Screen. Selecting this tab at 277 (in Fig. 27), the System Administrator will be able to determine which Access Rights and functions will appear as header lines, and which User ID's will be detail lines in a given report. The System Administrator will select this tab by clicking on it or pressing the underlined letter in the tab Label at the same time as the ALT Key. The Categories Listbox will be filled with a list of categories of Access Rights. The list will be sorted alphabetically. The System Administrator will click on one or more Category in the listbox, to select header(s) for a report. To select all of the Categories, the Administrator will click on the tree list label "ID", at the top. When a new report is requested, the tree list in the Reported User ID Listbox will be blank. To select detail lines for the report, the System Administrator can either double click on the User IDs in the Available User ED Listbox, or single click on each one and then on the ADD Button. The selected User IDs will now be listed in the Reported User IDs Listbox, and will appear as detail lines in the report. Groups of User EDs and Access Rights can be selected for printing or removal from the report, by expanding or collapsing the relevant tree list. To remove a User ID from the Reported User ID Listbox, the System Administrator can either double click on it, or click on it and then on the REMOVE Button.

The user can select the View Reports option to view and print reports from a list of previously executed reports. As discussed above, reports are stored in the database. A menu-driven user interface is provided to allow the user to filter and sort the reports as desired. Referring to Fig. 28 which depicts the System's generation of a report list, the user selects VIEW REPORTS 280 from the Reports Menu on the main menu screen. The user clicks on the SEARCH button 281 and the system opens up a search window. The user selects the specific fund and returns to the task queue window at block 282. The user then enters the report name, the task name, the date and time period when the report was executed and the report completion status at block 283. The user then clicks on the RETRIEVE button 284 to retrieve the report run information at block 285. The user can click on the table column header to sort information at block 288 in the table by this column. The System will retrieve report run information from the task queue database table 287 using the retrieval criteria of fund ID. post date, task name, status, date and time. The user then selects a report row in the report list table and clicks on PRINT 581 or VIEW 580 (or double click 289 the particular report), at which point the report is either printed at block 584 or displayed at block 583. The user can close this screen by clicking on the CLOSE button 582. The user can sort the reports by clicking the SORT button 288.

The user can generate a report by activity. Referring to Figs. 29 and 29A, the System Administrator will select the Users to include in the report header line, which Activities to list in the report detail lines and to include in the report header line, and which User IDs to list in the report detail lines by means of a menu-driven user interface - an Activity Reports screen. To open the Activity Reports Screen, the System Administrator will select the Activity Log Option from the Reports Menu on the Main Menu Screen at block 290. Listboxes are then built at block 291 from the database 293. The activity report window is displayed at block 294 sorted by activity by user. However, the System Administrator can also sort this list by other parameters by clicking on the appropriate column header. To locate a particular Activity, the System Administrator will be able to either use the scroll bar, or type the first letter of the activity, which will cause the list to jump to names beginning with that letter. The System Administrator will click on one or more Activity in the listbox, to select header(s) for a report.

To select all of the Activities, the Administrator will click on the tree list label "Activity", at the top at block 296. When a new report is requested, the tree list in the

Reported Rights Listbox will be blank. To select detail lines for the report, the System

Administrator can either double click on the Access Rights in the Available Rights Listbox, or single click on each one and then on the ADD Button. The selected Access Rights will now appear in the Reported Rights Listbox. Groups of User EDs and Access Rights can be selected for printing or removal from the report, by expanding or collapsing the relevant tree list. To remove an Access Right from the Reported Rights Listbox, the System

Administrator can either double click on it, or click on it and then on the REMOVE Button.

Assuming the User Account has access to the rights listed, they will be reported as detail lines in the report. Specifically, the user clicks on the ACTIVITY button 690 and the details of the ACTIVITY are displayed at block 695. The user may also select the ACTIVITY

(HEADER) button 691 or the USER ED'S button 697 and the listbox will be filled accordingly. The user can then click the PRINT button 696 and the System will read the activity database table 293 for the header and detail information at block 699. A hardcopy report is printed at block 797.

If the user clicks on the PREVIEW button 698, and the System will read the access rights database table 293 for the header and detail information at block 790. The report will be displayed on the monitor 44 at block 792. The user can then click PRINT button 793 and a hard copy report will be printed at block 795. The user can also click the CANCEL button

794 and the field tabs will be initialized at block 796.

On both tabs, clicking on the right mouse button while positioned on an item in a listbox will cause a shortcut menu to appear. In the User ID or Categories Listbox, the following options will be available: Details, List Selected, and List Available. Details will display detailed information about the User ID or Category. List Selected will list all User IDs or Categories currently selected for the report. List Available will list all User IDs not currently included in the report. In the Available or Reported List Boxes, clicking on the right mouse button while positioned on an item in the Available or Reported List Box, will bring up a shortcut menu with the following options: Add, Remove, Details, Collapse All, and Expand All. Add and Remove function as described in each section below. Clicking on DETAILS will bring up a pop-up box with detailed information about the item selected. Collapse All will collapse the tree list to its highest level of detail. EXPAND ALL will expand the tree list to its lowest level of detail. The System Administrator can preview a report before printing, by clicking on the PREVIEW Button. After reviewing the report, the Administrator will be able to print the report to their default printer.

When the Activity Reports Screen is first opened, the Activity by Users Tab 296 is visible. The User Listbox will be filled with a list of current Users. By default the list will be sorted by Last Name. However, the System Administrator can also sort this list by First Name or User ED, by clicking on the appropriate column header. To locate a particular User Account, the User will be able to 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. The System Administrator will click on one or more User Accounts in the listbox, to select header(s) for a report. To select all of the User Accounts, they will click on the tree list label "User", at the top. When a new report is requested, the tree list in the Reported Activity Listbox will be blank. To select detail lines for the report, the System Administrator can either double click on the Activity in the Available Activity Listbox, or single click on each one and then on the ADD Button. The selected Activity will now appear in the Reported Activity Listbox. Assuming the User Account invoked the last activity listed, they will be reported as detail lines in the report. Groups of User IDs and Activities can be selected for printing or removal from the report, by expanding or collapsing the relevant tree list and either double clicking on the group, or clicking on it and then on the REMOVE Button. To remove an Activity from the Reported Activity Listbox, the System Administrator can either double click on it, or click on it and then on the REMOVE Button.

The System will provide exception handling. Exceptions will either be processed internally without User notification, or will generate User-friendly notification. All exceptions will be tracked in the Database and will be available to view by the System Administrator. 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 detection program that provides report directly to the user. Of course, exception can be detected by a central exception handling block (EHB). Depending on the severity and type of problem, the EHB will decide the next steps to be taken, (i.e., inform the User of the error situation, reconnect to the Application Server and resubmit the request). In either case, all exceptions will be stored in a local tracking file.

The System of the instant invention permits a user to develop reports tailored for a particular need. In an aspect refeπed to as "Fund Administration," the System interfaces with the financial accounting system of the financial institution and extracts the data for Tax and Financial Reporting and Compliance Monitoring. This data can be arranged in a report as defined by a user or previously established on the System. Such reports may be designed to meet any reporting need, including the reporting requirements of administrative agencies or the like, or a particular inquiry from a fund manager. These reports can be performed ad hoc (i.e., immediately on command) or as scheduled.

Historically, the acquisition of data and the generation of reports was a time- and labor-intensive process. Data had to be "manually" assembled on a daily basis, from a variety of sources and then subjected to lengthy and rigorous scrutiny by a team of analysts. For instance, if a client needed to know how much income a particular fund had earned in the last year, from dividends and interest on foreign investments, the analyst would have to peruse the entire portfolio, make a judgment call on which of the securities were foreign, and manually enter the data in a separate report. In contrast, the System permits a user, such as a compliance analyst to define their own reports. The financial data is easily accessible on-screen, and the System provides an unlimited ability to "slice and dice" the data as desired. With a series of keystrokes, the administrator can generate a report broken out by security, industry, country or other classification. One difficulty with previous manual systems was that certain financial data is not maintained - either long term or at all. Critical industry data needed to supplement transaction information is simply missing. For companies that deal with multiple clients with multiple needs, the problem becomes exponential. The System permits financial data pertinent for a fund to be defined. Typically, this is done with the assistance of money managers world-wide, to establish a list of the data elements that must be entered on the front end. This collection of data is referred to here as an "Audit Worksheet." Once the information on the Audit Worksheet is entered into the System, the System can maintain, flag and capture it, to generate a financial statement that includes the information relevant for a particular user. The System may also be employed to perform Fund Reports (another labor and time intensive process). The Fund Reporting aspect of the System generates annual and quarterly reports for US mutual funds from the raw data in the funds' daily records. The System aggregates all this low level minutia and translates it into formal general ledger records — significantly facilitating the financial statement preparation process. A report writer will be able to code to typesetting, outputting directly to a printer, a facsimile machine, e-mail, computer memory, or other media as desired.

The System also permits the generation of any desired financial statements automatically. The user defines the financial data desired for a given report and the arrangement of that data. The System can then cull through its database, retrieving and arranging the financial data as desired. It will be appreciated that the reports may include more complex parameters, such as rules and tests, not simply the core financial data. For example, the System may be employed to generate Customized Portfolio Statements, Automated Audit Worksheets, Financial Statement Reclass Rules and Audit Adjustments, Non-Income Producing Dividends, Customized, typeset financial statements, and Roll forward Proof and Analytic Reports. Further, the System can be employed to develop reports related to tax reporting, particularly in the context of mutual funds, including Wash Sales Reports, 988 Gain/Loss Reports, PFIC analysis, Dividend Received Deduction Analysis. Excise Distnbution Reporting, Exempt Income Reporting, Treasury Income and Asset Reporting, Income-by-State Reporting, Foreign Tax Credit Calculation and Reporting.

The System of the instant invention includes an aspect directed to "Wash Sale" functionality. The Wash Sale aspect of the System identifies potential wash sale transactions to determine the wash sale status, to develop the functionality to calculate the wash sale defeπal amount and to develop reporting capabilities for wash sales. A wash sale is any loss from the sale of an asset where the identical asset is acquired within a period beginning 30 days before and ending 30 days after such sale or disposition. The ERS disallows wash sale losses since the holder of the security has the same position that it had before the sale transaction. The tax department conducts wash sale analysis at excise and fiscal year end of the funds when book to tax adjustments are calculated.

Referring to Fig. 30, a flow chart depicting an overview of wash sale processing, the System identifies all potential wash sales transactions at block 30 and then determines which transactions are 'actual' wash sales. The user can then instruct the System to generate a 'potential' wash sale report at block 301. Preferably, the wash sale report includes all transactions that meet the Potential Wash Sale Identification logic criteria, such as those well-known in the art. Of course, other wash sale criteria could be employed for a particular application as one skilled in the art would appreciate. The user then verifies the results of the system at block 302, and override any transaction as needed at block 303 by going into an on-line screen that includes all 'potential' wash sale transactions for a specified period. The user overrides the wash sale status, potential, actual, or subsequent. A reason column should be included that allows the user to type in a comment for each transaction. The user will then generate an 'actual' wash sale report (report option) at block 304, which will only include those transactions that have an "actual" status. This schedule will calculate the actual wash sale deferral amount.

The wash sale aspect of the System assists the tax department of the financial institution in the preparation of the tax provision schedules for a fund by identifying wash sale transactions and calculating the deferral amount. Of course, this information may be provided to tax professionals outside the financial institution and still practice the invention. The System creates an on-line user interactive screen for overrides to wash sale status with reason table. The System includes a batch function that determines the wash sale status. Further, the System permits the development of subsequent year wash sale logic. The System creates a Wash Sale Report.

The wash sale aspect of the System provides the user with an on-line view of the reports. This aspect may be scheduled or performed at the immediate command of the user. "As of " processing, discussed above, may be employed to realize trades and other information entered later. The wash sale reports may be printed, saved electronically, or transmitted electronically, as desired.

Currently, it is preferred that a potential wash sale is a sale that meets the following criteria: any lot in the sale transaction that realized an economic loss, and that had a buy transaction with a trade date 30 days prior or 30 days after the trade date of the sale lot. The trade date of the sale is not counted in the 30 days. For example, if the trade date of the sale is 1/1/96, the buy transactions that would be included would be any with a trade date between 12/2/95-12/31/95 and 1/2/96 - 1/31/96.

For foreign debt securities (assets whose country of origin is not United States), the System identifies lots sold that generate a post bifurcated economic loss (after 988 netting rules have been applied) at the lot level. See Fig. 31, a flow chart depicting the Section 988 Gain/Loss Disposition of Debt Instrument (for each Lot). ERS Section 988 requires that the net gain/loss on the sale of a debt security (i.e. non-equity) denominated in any currency other than SUS be separated (i.e. bifurcated) into two component parts - economic and currency. The allocation of these two components of gain/loss to either currency gain loss (i.e. ordinary income for tax purposes) or investment gain loss (i.e. capital for tax purposes) is then determined by applying the "netting rules". These netting rules should be applied to the components of gain/loss related to each individual lot of the security sold. The netting rules need to be applied to the gain/loss components of each individual lot comprising the asset sale. Of course, Section 988 only applies to foreign debt securities. The netting rules are not be applied to foreign equity securities. The System initially determines, on a lot basis, the amount of currency gain or loss and the amount of economic gain or loss. As depicted in Fig. 31, the System then reclasses the amounts to the appropriate "buckets." References to 988 equates to "currency" gain loss. "Ignore 988" means post the entire amount to economic gain/loss.

Referring to Fig. 31, the System determines whether there was a total gain at block 310. If yes, the System determines whether there was a foreign exchange gain at block 311. If so. the foreign exchange gain is calculated at block 312 and the System determines whether the foreign exchange gain is greater than the total gain at block 313. If so, all of the total gain is designated as 988 gain (i.e., "ordinary income") at block 315 and the capital gain is zero at block 317. If the foreign exchange gain is not more than the total gain, the 988 gain is set equal to the computed foreign exchange amount at block 316 and the capital gain is determined to be the difference between the total gain and the 988 gain at block 318.

If there is no total gain, the System determines if there is a foreign exchange gain at block 319. If so, SEC 988 is ignored at block 710. If not, the System computes the foreign exchange loss at Block 711. The System then determines if the foreign exchange loss is more than the total loss at block 712. If so, the System sets the total loss as the 988 loss (i.e., ordinary loss) at block 713 and the capital loss is set to zero at block 715. If the foreign exchange loss is not more than the total loss, the System sets the foreign exchange loss amount as the 988 loss at block 714. The difference between the total loss and the 988 loss is set as the capital loss at block 716. A sale is not a wash sale if: The buy lot number is equal to the sale lot number and there are no more buy lots available; the current shares of the buy lot are equal to zero on the report end date and there are no more buy lots available; or there are no buy lots or there are no remaining units of buy lots left to "defer" the sale loss. However, a sale is a wash sale if a wash sale deferral amount can be calculated as shown in Fig. 32, which depicts the calculation of the wash sale deferral amount. The following assumptions are made when calculating the wash sale deferral amount: remaining units are equal to the current units before the analysis begins (In the subsequent year logic, remaining units equal the purchased units before the analysis begins.) and the report dates do not affect the calculations.

Referring to Fig. 32, a depiction of the calculation of the wash sale deferral amount, the System begins with the first sale lot and the first buy lot at block 320. The System then determines whether the buy lot number is the same as the sale lot number at block 321. If so, the System determines whether there is another buy lot at block 324. If not, the sale is determined not to be a wash sale at block 325. The System then determines there is another sale lot at block 328. If not, this calculation ends. If yes, this sale lot and the original buy lot are used for analysis at block 721 and the System returns to block 321.

If the buy lot number is not the same as the sale lot number at block 321 or if there is another buy lot at block 324, the System determines whether any units of the buy lot (greater than zero) remain at block 322. If not. the System determines whether there is another buy lot available at block 323. If not, the sale is not a wash sale and the calculation ends. If there is another buy lot available, the System returns to block 322.

If, at block 322, there remaining units of buy lots are greater than zero, the System determines whether the remaining units of the buy lot are greater than or equal to the shares of the sale lot at block 326. If yes, the System determines that the wash sale deferral amount equals the total loss from the sale lot at block 329. Further, the remaining units of the buy lot are set equal to the number of shares of the buy lot while the remaining shares of the sale lot are set to zero. The System then determines whether there is another sale lot at block 722. If not, the calculation ends. If yes, the System returns to the first available buy lot with remaining units at block 723 and the System begins the calculations again at block 321.

If, at block 326, the remaining units of the buy lot are less than the shares of the sale lot, the wash sale deferral is set equal to a prorated amount (i.e., (buy shares/sale sharesyioss from lot sale) at block 327. The remaining sale lot units is set equal to the sale shares less the buy shares. The System then determines whether there is another buy lot with remaining units greater than zero at block 720. If not, the calculation ends. If yes, the System returns to block 326.

For tax year end, the System also performs a wash sale analysis for transactions that may be deemed wash sales in the "subsequent" year. Because purchases can occur 30 days after a sale, logic is needed to identify "subsequent" year wash sales. The date range for the analysis is 30 days prior to 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 - 12/30. The System reviews the financial data for any buys that occurred in the first month after the year end (i.e. 12/1- 12/30) and determines if they can be linked to any sales that occurred in the last month of the tax year end that have not already been deferred. The System conducts the wash sale deferral analysis as discussed above except that current units are not considered. The System uses the purchased units. The System excludes all sale activity that occurred in the first month of the new fiscal year (e.g., 12/1-12/30).

The System can also perform wash sale analysis for excise year end (as opposed to tax year end). Generally, the wash sale analysis is conducted twice a year, once for the tax year end and the other for the excise year end. The two analyses are mutually exclusive, which means that transactions could have different statuses when run for each year end. The System's logic for the determination of the wash sale status is the same; except when calculating excise year end, the year end is always 10/31 of the relevant year. The Subsequent year logic discussed above may also be applied to the excise year end period.

The System may determine the wash sale status using a batch program. A batch program will execute the analysis when the report is generated. Preferably, the batch program does not override the wash sale status of a transaction that has been overridden by the user. Rather, it will use that status. After overrides have been applied, the batch (that is, the report) will need to be rerun. This batch function (report) may be implemented by the scheduler function within the System. The report date range does not affect the determination of the wash sale status or the calculation of the wash sale deferral amount. For example, if the report dates are 1/1 - 1/31, and if there is a purchase on 1/3 that was used to defer a sale from 12/20, then that logic would not change; the purchase could not be used again for a sale in January.

On a fund basis, the System provides the user the ability to view on-line all of the potential wash sale transactions for a selected period of time. The screen will show transactions at the lot level. This screen will contain a wash sale status field that will allow the user to override the system logic. There are four update options available:

1. A blank in this field will indicate that no override has been entered. 2. A "Y" in this field will indicate that the transaction is an

"actual" wash sale.

3. An "N" in this field will indicate that the transaction is not an "actual" wash sale; it is only a potential wash sale.

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

A reason column is available for each sale lot for the user to add comments. Updates to this override field are kept in a history log, showing the old and new values, the reason, the effective and post dates, and the user ED of the person who changed the status. A filter is available to allow the user to view all transactions (potential), actual wash sale transactions, and subsequent year wash sale transactions. The screen should have printing capabilities. At the fund level, an activity report details wash sale transactions. The report uses the wash sale criteria to determine which transactions to include. The report also shows the corresponding '^•triggering" purchase with the sale transaction, that is, those that caused the sale to be a potential wash sale. All monetary values are reported in US dollars; no local currency display is needed. This report should be designed in Microsoft Excel but of course other software and other means of display may be employed and practice the invention. In order to make any changes, the user will be required to save the report and make changes outside of the System.

The System provides various report options: a "potential" wash sale report (listing all transactions identified by the System as wash sales for a selected period of time); an "actual" wash sale report (listing only transactions identified as actual); and a "subsequent year" wash sale report (listing only transactions identified as subsequent year wash sale transactions). The report formats for the three options will be the same; except when the potential wash sale report is selected, an additional column will be included showing the wash sale status.

The System also provides a report option for 988 information. When selected, the report (any 3 options above) will display any post bifurcated currency loss for all applicable sale transactions. This currency loss should NOT be used in any calculations or logic in the report; it will only be displayed. When this option is not selected, the column will be hidden in the spreadsheet.

The System provides the user with the option to have the report displayed, saved electronically, transferred electronically or printed. Preferably, the data within the reports are sorted by cusip, then by sale trade date. Preferably, the reports do not provide subtotals. However, the report may total the Short-term Deferral and the Long-term Deferral columns at the end of the report. The System allows the user to set all date ranges and defaults in the "scheduler" function within the System.

For purposes of the System, certain assumptions are made. If the holding period is less than or equal to 1 year, the wash sale deferral amount is considered short-term. If the holding period is greater than 1 year, the wash sale deferral amount is considered long-term. Actual shares utilized equals the lesser of the sale lot units or the buy lot units. Of course, a user may define these terms as preferred for a given application. The System can generate and provide a non-income producing assets report for a financial fund. This period report will detail all cuπent holdings of a fund group or fund that did not declare a dividend during the period for which the report is run. Dividend declaration will be determined by referencing global dividend history records. Typically, The Financial Reporting group of the financial institution is required to identify dividend eligible assets which did not declare a dividend during the twelve months prior to the period end for presentation in the published financial statements. This report can be used as a tool to determine which asset issuers did not pay a dividend during the specified reporting period. Of course, the non-income producing assets report may be employed for other reasons, as one skilled in the art would appreciate.

To create the non-income producing assets report, the System searches the global dividend records to gather all assets held by a fund override group that did not pay a dividend during a specified period. The System then creates a report that may be viewed online or printed detailing the assets obtained in the search. The report may be generated at the fund group or fund level with different sort criteria. Preferably, at the fund group level only, the System enables users to verify non-income producing status and store at the asset level. The System creates a user modifiable table detailing reasons for non-income or income producing status that is linked to the Non-Income Producing Assets Report.

The System can also create a data extract of assets deemed to be non-income producing to be transmitted to the other systems, such as the RR Donnelley FundWorX system. This data extract may be formatted to be received effectively by such other systems.

This report is an as-of report with cut-off date functionality. All dates may be overwritten by the user. The System is set up with date defaults of a "Beginning date" as prior month-end day minus 364 or 365 days and an "End date" of prior month-end day. The "Beginning Cut-off date" is the prior month-end minus 365 or 366 days. The "End Cut-off date" is set as prior month-end day. Of course, these may be adjusted by a user.

The user may choose to run the report for a fund group or for an individual fund. The report may be sorted by CUSIP, Country/CUSIP or Class/CUSIP. If Country/CUSIP or Class/CUSIP is selected the report will list and subtotal assets in sections by country or class. Each section will have the name of the Country or Class as a heading. To generate the non-income producing assets report, the System scans the global dividend records to identify current holdings that did not have an ex-dividend in the period specified. For each asset returned in the search scan, the cost lot records of all funds in the fund group for the oldest active lot is determined. The System displays the trade date of the oldest active lot. If the trade date is over one year from the end date, the System sets the Non-Income Producing flag to Y. The reason field is updated with the following message: "Asset held greater than one year." If asset type is Warrant, Right or Option, the Non- Income Producing flag is set to Y. The reason field is updated 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 permits verification of non-income producing assets. User verification is only allowed at the fund group level. The Non-Income Producing flag is manually set to Y after confirming the position is non-income producing. If the asset is determined to be income producing, the field will be left blank. The reason for non-income or income producing status will be selected from the Reason Table. For reasons that require a date, the Pay Date field will be manually populated. All information at the asset level is stored with an effective date equal to the end date.

The System maintains a table of reasons for the non-income producing instruments. These reasons include: Asset held greater than one year, Not a dividend eligible asset, no data found, last dividend paid, stock split, and EPO. Of course, other reasons may be stored on the Table as desired for a particular application.

The System provides as-of processing capabilities for specific transactions. The as- of proof reports capture all as-of activity for a specified report date and reconcile to the report date balances. The as-of proof reports are available for General Ledger Activity as well as Fund Holdings reports. The As-of Proof reports will be utilized by Fund Administration when performing quarterly, semi-annual and year-end reconcilements.

The System creates as-of proof reports detailing the following as-of activity:

General Ledger Activity (providing three levels of detail Summary, Detail and Transaction

Detail) and Holdings (providing a summary and detail). The System displays all general ledger accounts with post date balances on the General Ledger Activity Summary report.

Group and total general ledger post date and as-of date balances are displayed by account type (assets, liabilities, capital, income and expenses). The System allows drill-down capability between various levels of detail. Reports may be generated at the fund and holding levels, as desired.

The as-of proof report is a balance report. All dates may be overridden by user at run time but default dates are set such that the Report (post) Date is the Prior business day and the Report Cut-off Date is the Prior business day. General Ledger transaction details for each as-of posting should be those reflected in the Transactions Detail screen in Fund Activity. The System gathers all post date general ledger balances for the selected report date. For each General Ledger account, the System gathers any as-of eligible transactions which have a trade date on or after the report date that were posted to the system prior to and including a specified cut-off date. If an account has no as-of activity, the System displays zeroes in the debit/credit fields. All debits and credits are totaled for each transaction. The System sums and groups post/as-of date balances, debits and credits. For each General Ledger account, the System displays details by transaction type associated with each as-of posting. For each as-of posting, the System displays the associated transactions. The amount column is totaled by transaction type.

The System can generate an As-of Holdings Summary Report. Initially, the System gathers all report date balance holdings and lists them in cusip order. The units, market value and cost are displayed along with currencies based on report selection. The title for this line item will be "Report Date Balance". All as-of transactions gathered in the detail section of the report are totaled and the units, market value and cost (currencies displayed based on report selection) are displayed. The market value based on as-of price of security times the units of the transaction is displayed. Preferably, for purchases, if the fund did not hold the security, the System uses global vendor price. If no vendor price exists, the System uses the purchase price. This line item will be titled "As-of Activity", and will also have the ability to expand and collapse to view the detail information. The "Report Date Balance" and "As-of Activity" line items for each holding displaying total units, market value, and cost is subtotaled. This line item will be titled "As-of Date Balance". The "As-of Date Activity" line items for all holdings at the end of the report under the heading Total Fund "As-of Activity" are totaled.

The System also generates an As-of Holdings Transaction Detail Report. The System gathers all as-of transactions with a trade date on or prior to report date and a post date on or after the report date, up to and including the cut-off date. The System displays cusip, sedol, asset description (long) and list each transaction with trade date, post date, transaction type, units and cost (display currencies based on report options).

The System provides as-of processing capabilities for certain selected transactions. The As-of General Ledger Proof Report details post date account balances, as-of debit/credit totals for transactions which have a trade date on or after the post date that were posted to the system prior to a specified cut-off date. This report can be used as a tool for reconciliation and confirmation of as-of general ledger transactions.

The System creates the proof detailing as-of general ledger activity. For each General Ledger account, the System allows "drill down," such as by responding to mouse clicks by a user on the interface screen, to a detailed screen which will display all as-of posting for the selected account. This drill down capability is available on any as-of posting to view details of the associated transaction. The user can print a summary and the details, as desired. The report can be generated at the fund and holding levels, as desired. Preferably, the "as of general ledger proof report is a balance report. All dates may be overridden by user at run time. Transaction detail for each as-of posting should be linked to the Transactions in Fund Activity.

To create the General Ledger proof report, the System gathers all post date general ledger balances for the selected report date. For each General Ledger account, the System gathers any as-of eligible transactions which have a trade date on or after the report date that were posted to the system prior to a specified cut-off date. All debits and credits for each transaction are totaled. The System then sums the report date balance, debits and credits. For each General Ledger account, the System displays details associated with each as-of posting The System provides an automated audit worksheet that details ledger balances as of a specified date adjusted for financial statement reclasses and adjustments. Adjustments to the audit worksheet include: pre-determined automatic ("recurring") reclasses between general ledger accounts and manually entered adjustments. The final adjusted balances generated are used in the financial statements. As part of the preparation of financial statements, typically, the Financial Reporting department of the financial institution adjusts book general ledger account balances without actually modifying accounting records so that they may be properly reflected in the related financial statements. Modifications include automatic system generated reclasses between general ledger accounts, expenses adjustments, as of activity and audit and tax adjustments. The audit worksheet of the System provides an audit trail from book accounting balances to final, financial statement balances. The final adjusted balances generated by the audit worksheet may be included in the data extract to the an outside service, such as the Donnelly FundWorX system, for preparation of typeset, camera ready, financial statements.

The System creates a rule ("reclass") maintenance screen to maintain rules for reclasses of balances from one general account to another. The System also creates a manual entry screen. An on-line audit worksheet is created that reflects applicable manual entries and reclass entries. A printed worksheet report that includes more detail than the online view is also created by the System. The System allows the user to verify and approve the audit work sheet on line. A history log of all modifications to manual entries and reclass rules is created by the System. The System also creates a Status table for worksheet verification status and establishes links to the audit worksheet. Management Reports can also be created. If desired, a data extract, such as FundWorX extract, may also be created for delivery to an outside service.

Typically, the audit worksheet report includes a date of the prior month end (if actual month end day is on a Saturday, Sunday or market holiday, use prior business day balances). The cut-off date is set to the prior month end + 1 (if actual month end day is on a Saturday, Sunday or market holiday use, prior business day balances to next subsequent business day). If month end day is on a Saturday, Sunday or market holiday ???? always display the month end date on all reports and screens. Preferably, the worksheet will be sorted by General Ledger GL Account numbers.

To build the balances, the System creates a menu choice to build general ledger balances. All general ledger balances for the worksheet date through the cut-off date are gathered and stored. Balances may be built more than once (i.e. with different cut-off dates) but only the most recently built balances are stored.

To create the worksheet, the System applies all manual entries with the effective dates equal to the worksheet date to the stored general ledger balances and print in "adjusted balance" column. All assigned reclass rules are applied to balances in the "adjusted balance" field to create a new "Final GL Balance" field. A reclass rule is not applied if

"adjusted balance" is zero. The worksheet is then populated. The System allows various changes in status to be made to the audit worksheet on line. Statuses are maintained in a status table. Status will be displayed in the on-line view. The default status is "Open^". Each time the user Builds Balances, the status is "Open" and the comment field will display "Generate Balances". Status will remain open until it is changed by a user. When modifications are made to the worksheet, the Status button is disabled until the user either saves or cancels the modification. When modifications are made and saved to the worksheet, a subsequent to status change of the status to "verified," "approved" or "final" will revert back to open and remain in this state until it is changed by a user. The user will be prompted to enter a comment for the change. This comment will be reflected in the status report.

Status is chosen from a Status table and access to each status is based on network user ID. For example, access to "open" and "verified" status is granted to all users. Access to "Approved" and "Final" status are only granted to users with appropriate additional rights. The System creates a separate tab displaying the status history for an audit worksheet. The history may be printed from the Print button.

The tax department of the financial institution may use the audit worksheet for information purposes. Before the audit worksheet may be provided to tax it must be approved. The Approved for Tax column may only marked when the worksheet is in Approval status. The tax users may view the audit worksheet on-line or print the audit worksheet from the Reports menu. Tax users have read access only.

If the audit worksheet is re-executed with a different cut-off date, the Status reverts to Open and the user is prompted to enter comment and the status remains Open until changed by a user. If modifications to the worksheet are saved subsequent to a status change to verified, approved or final, the Status reverts to Open and the user is prompted to enter comment for modification. The status remains Open until changed by a user. In order to change status to a worksheet marked Final, Locked and Approved for Tax must be marked before existing screen. The on-line view displays Final. In order to make any subsequent changes, the worksheet must be "unlocked" by an authorized user. The status reverts back to open and remains open until changed by a user. Reclass rules generate automatic reclasses of balances from one general ledger account to another. Reclass rules will be created by a designated user(s) in the Reclass Maintenance/Definition Tab. Rules are created by entering a description of the reclass, the account number to reclass from and the account to reclass to. Certain rules will only apply when certain conditions exist. Conditions are optional and not required to be used in a rule. If the user attempts to create a rule that already exists, a warning message will appear and the user will not be allowed to create the rule: "This reclass rule already exists." The rules will be stored for use in the audit worksheet.

Reclass rules will be assigned in Reclass Maintenance/Fund/Fund Groups Tab. Rules are assigned by designated users at the fund override group or fund levels. Fund override group logic applies. The fund override group will be the same as the fund override groups in the Compliance Engine. When a rule is assigned at the override group level it is automatically assigned at the fund level for each fund in the group. If a user attempts to assign a rule that is already assigned the following error message appears and the rule will not be assigned: "Error: Rule is already assigned." All modifications to reclass rules will be stored in Rules Maintenance/History Tab. The history log may be viewed on-line or may be printed from the screen. The manual entry screen will be accessible from the audit worksheet screen.

Manual entπes will be created and deleted in the Manual Entry screen. For new manual entries, when an account is selected, the account number and related account description appears in the debit/credit box with a blank field for input of the dollar amount. Before any new manual entries or deletions of existing entries may be completed either the Save, Close or Cancel buttons must be clicked. The entry is stored once the save button is clicked. A manual entry may only be saved if the Net Amount equals zero. If this condition doesn't exist the save button becomes disabled.

The users will enter the as-of shares using a dummy CCOA. Increase will be entered as a debit - decrease as a credit. The system will calculate the difference between post date and as-of date shares. The difference will be displayed in the Debit/Credits columns between the As-of Balance and Adjusted Balance columns in the audit worksheet. Adjusted shares are carried through to Final GL Balance Column. The display of history is linked to the audit worksheet date. Default from date is most recent audit worksheet date and default to date is current system date. Date may be overridden by user. History may be viewed on- line or in printed form. The worksheet is a balance report with as-of cut-off date functionality. The default dates may be overwritten by the user at schedule or run time. Preferably, the System is provided with default dates such as: Worksheet date - prior month end (if actual month end day is on a Saturday, Sunday or market holiday, use prior business day balances) and Cut-off date - prior month end + 1 (if actual month end day is on a Saturday, Sunday or market holiday use prior business day balances to next subsequent business day). The System provides a Fund Accounting Entries Report that may be used for submission to Fund Accounting for posting manual entries relating to audit and tax adjustments to the accounting system. The report is linked to the audit worksheet date. The default date is the most recent audit worksheet date but this may be overridden by user. For the specified audit worksheet date, the System gathers all manual entries with effective dates equal to the audit worksheet date and the Fund Accounting Flag marked "Y".

The System also provides a Reclass Rules History report, that is, an activity report detailing the history of reclass rules. All default dates may be overridden by the user but are initially set such that the Begin date is the most recent audit worksheet date and the End date is the purrent system date. The System gather all rule history for the fund, fund group or all rules as requested for the specified date range.

The System provides a Summary Report of Reclass Rules, that is a list of all reclass rules in the database and the reclass rules that have been assigned to a fund group or fund.

The default date is set such that the End date - prior month end date may be overridden by user. The System gathers all rules that are currently assigned to a fund group or fund and all rules in the database.

The System provides a Manual Entry History Report, that is an activity report detailing the history of manual entries for a fund for a specified period. The default dates are set such that the Report date is the most recent audit worksheet date. Date may be overridden by the user. The System gathers all the history of manual entries for the requested fund or fund group.

The System provides information for the Financial Reporting Department of the financial institution allowing them to produce typeset, camera ready financial statements. Final general ledger balances for specified worksheet date will be included in the extract file. The extract will be generated on demand by the Financial Reporting Department. The System create an ASCII tilde delimited, file of fund final general ledger balances as of a specified date. A separate file is created for each fund. The extract may be generated on demand. The extract will include final adjusted general ledger balances on the worksheet date. While all default dates may be overridden by the user, initially they are set such that the Worksheet date is the prior month end (if actual month end day is on a Saturday, Sunday or holiday use prior business day balances) and the Cut-off date is the prior month end -r 1 (if actual month end day is on a Saturday, Sunday or holiday use prior business day balances to next subsequent business day).

Referring to Fig. 33, a flow chart depicting an overview of the System's processing of PFIC information, the System allows a user to work with passive foreign investment company ("PFIC") securities information to identify PFIC securities on both a global basis and a fund basis. The System calculates tax adjustments on PFIC securities held and PFIC securities sold. Further, the System has reporting capabilities on a fund level basis for PFIC's. Traditionally, PFIC analysis has been performed manually. The System can be employed to create system-generated reports; thereby reducing a fund's exposure to human input errors. In addition, automated PFIC functionality will allow for more efficient work flows in the user community, as well as the generation of quality reports, thus enhancing the level of service that is provided to the client. The Systems treatment of PFIC's is important for tax purposes. PFIC's must be analyzed in order to avoid additional taxation and interest on distributions and disposition of their stock. To avoid such penalties, a shareholder may choose the mark to market election. This election allows the shareholder to treat the PFIC as if it had been sold for its market value on the last day of the shareholder's fiscal year.

An asset is classified as a PFIC if certain criteria relating to income, assets, etc. are met. The Investment Company Institute (ICI) Survey categorizes potential PFIC's in three ways: Type I assets are deemed to be PFIC's; Type II are potentially PFIC's, but whose status is unclear; and Type III represents assets which were suspected of being, but were determined not to be PFIC's. The ICI Survey is generated by various mutual fund complexes informing the ICI of the status that their particular complex gave an asset. Because various investment advisers may come to different conclusions, the situation may arise that an asset is listed under Category I,II,III or as multiple categories (i.e. I,III). Although some assets are listed by the ICI Survey of Potential PFIC's as Type I, the final determination of all suspected Type I PFIC's is made by the client. There is a fourth PFIC category (IN) of assets determined to be PFIC's by other investment advisers than ICI (i.e. client). Foreign mutual funds are, by definition, Type EV PFIC's. Foreign mutual funds will be identified on the System as: Assets flagged as RICS or Investment Companies in Asset Maintenance and whose Country of Origin is NOT United States; and Assets with an asset type of mutual fund and whose Country of Origin is NOT United States. When an asset is created on Asset Maintenance that meets the foreign mutual fund criteria, the asset should automatically be added to the PFIC table, and the PFIC IV status should automatically be checked.

The System permits the import PFIC information from other information systems in the financial institution. The users have the ability to override the PFIC information at the fund group and fund level with tracking ability. PFIC listings are created for data research. Reports are developed showing changes in PFIC status. A PFIC Holdings Report are created. A PFIC Sold report is also created. The System creates a PFIC Cost Tracking schedule and a PFIC Cost Sold Tracking schedule.

Preferably, other information systems at the financial institution provided information on PFIC securities on either an annual or semi-annual basis. This information will be received via a spreadsheet program, such as Excel, or possibly an Internet file, and will be imported into the System. The information populates a PFIC Table in the Table Maintenance menu. This table will then populate the PFIC check boxes in Asset Maintenance. As new assets are created in Asset Maintenance, the PFIC table should be referenced to see if the asset is listed in the table. That way, the PFIC status can be updated when the asset is created.

Referring to Fig. 33, the System imports ICI information into its Asset Maintenance section in block 330. The Asset Maintenance information is updated with PFIC statuses at block 331. The System then generates PFIC listings at block 332. The System then researches missing data and updates the Asset Maintenance information at block 333 [HOW IS THIS DONE?] DAN??? At block 334, the System generates PFIC fund reports at block 334 based upon the PFIC holdings 335, the PFIC sold report 339, the PFIC cost tracking - holdings information 930, and the PFIC cost tracking - sold information 931. The PFIC report is sent to a client for review at block 336. Once the client grants its approval, the System is updated as needed at block 337. The tax provision of the System is updated at block 338 to account for PFIC adjustments.

The assets listed in the other system files of the financial institution file can be matched to assets in the Asset Maintenance in three ways: the sedol can be matched to a sedol in Asset Maintenance; the asset description in the file can be matched via an "alpha" search of the Asset Maintenance description; and the entities listed in the file are at a company level; therefore, once a match has been found, other equity assets with the same issuer code (non-debt) would also be considered to be the same PFIC category. For example, if the XYZ Common Stock Holdings is listed as a PFIC I, then all other issues of XYZ Holdings (i.e. Preferred stock) would be considered PFIC I. The import would look to the issuer code to find all equity assets that were issued by XYZ Holdings.

Because the final determination of a PFIC status is made by the investment advisor, override functionality is needed at the fund group level and the fund level. The override at the fund level can only be done at a tax manager or higher level access. Preferably, there is just one line "PFIC" with a Yes/No option. The individual PFIC I, II, III, and IV boxes are not needed. The box will be blank (null). The user will override the box with either a Yes or No.

Many of the assets listed in the files from other departments within the financial institution contain missing data. Therefore, the reports preferably assist the users with identifying assets with missing data, so that offline research can be conducted and the System can be updated. Two such reports may be particularly useful: PFIC Listing (prints entire file of assets (may be done outside of the System)) and Exception Report (prints out a list of securities not imported into the System because no matching asset in Asset Maintenance was found). These reports should be sorted by PFIC Status, then alphabetically by asset description. Of course, any sorting order may be employed depending on the particular application.

The System permits the generation of Asset Maintenance Research Reports. From the Asset Maintenance file, the user may generate the following four reports. PFIC Listing report prints the entire table of assets with any PFIC status sorted by category, 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 TV only in Asset Maintenance, sorted alphabetically by asset description. The PFIC I and TV only report lists assets that are PFIC I and EV in Asset Maintenance, sorted alphabetically by asset description.

The System permits the generation of a PFIC Status Report- Asset Maintenance Level which shows changes made to the PFIC status. This report may be run for a period of time and include all modifications and new Asset opens that were given a PFIC status that occurred during that time. The report sorts first by modifications, then Asset opens and then, within those categories, alphabetically by description. An option is provided to sort by Post Date (latest date to earliest). The secondary sort may be alphabetically by description. The System also provides a Fund Group Level Report that shows differences between the PFIC status in the Asset Maintenance and the Fund Maintenance (indicating that the initial default status in Fund Group Maintenance has been changed). Preferably, the report only refers to the Fund Group Maintenance for those assets that have been updated (i.e. the field is not null). A difference in PFIC status would be, for example, if the Asset Maintenance status is I and the Fund Group Maintenance is N. In addition, the report should also show assets that have been flagged as a PFIC in the Fund Group Maintenance, but have no PFIC status in Asset Maintenance (i.e. Asset Maintenance is " ", and Fund Group Maintenance is "Y." This report should have the ability to be run for a selected day. The report should be sorted first by Asset Maintenance PFIC Category, then alphabetically by description (the blank Asset Maintenance category should be listed last). There should also be an option to sort by Post Date (latest date to earliest). The secondary sort would be alphabetically by description.

The System also provides a Fund Level Status Report that shows differences between the fiind level PFIC status and either the fund group level or the Asset Maintenance. This is particularly useful since overrides can be applied at the fiind level. The report compares the status at the fund level, and determines if the PFIC status is different from the Asset Maintenance or the Fund Group Level (if the fund is part of an override fund group). The report should be sorted first by Asset Maintenance PFIC Category, then alphabetically by description (the blank Asset Maintenance category should be listed last). There should also be an option to sort by Post Date (latest date to earliest). The secondary sort would be alphabetically by description.

The System provides a Potential PFIC Holdings Report which details all the current holdings at a lot level for all assets that have a PFIC status. The PFIC status that is used for this report should be from the Asset Maintenance level and no override statuses should be used. All monetary amounts are shown in US dollars (no local currency display is needed). The report title is "Potential PFIC Holdings Report - ICI Categories." The PFIC Holdings report should have print, file, and display options at both the fund level and the fund group level. For as-of reporting, the market value must be calculated. The calculation is equal to the shares multiplied by the market price on the report date. For unrealized gain/loss, the calculation is equal to the difference between the market value and the cost. The report should subtotal the shares, cost, market value, and unrealized gain/loss for those assets that have more than one lot. No grand totals should appear on the report.

The System provides a Potential PFIC Sold Report that details the sale transactions of potential PFIC securities for a specified period. The report includes all assets with a PFIC status, as well as foreign mutual funds. The PFIC status that is used for this report should be at the Asset Maintenance level and no override statuses should be used. For sale transactions that have been canceled within the reporting period, neither the original transaction nor the cancel transaction should be included. If the cancel transaction happens outside the reporting period, then the transaction would be included and the cancel transaction would appear in the next reporting period. A cancel transaction would have the opposite signs as the sale transaction. All monetary amounts should be shown in US dollars (no local currency display is needed). The report will print all sale transactions within the specified period and is titled "Potential PFIC Sold Report - ICI Categories."

The System can calculate the Realized Gain/Loss Character. However, the logic for the determination for realized gain/loss character must match the calculations from the source system. The report should subtotal the shares, cost, proceeds, and realized gain loss for each asset that has more than one lot. There should be no grand totals on the report.

The definition of a PFIC is established by the financial institution. The most current PFIC status should be used. If an asset is considered a non-PFIC and then changed to a PFIC, then the asset would be considered a PFIC, even for historical purposes. The user will run the cost tracking schedules from the original purchase date of the security; the System will need to recreate the cost tracking schedules from that date to the current date. Modifications to the PFIC status in Asset Maintenance and in Fund Group Maintenance should be allowed. The "true" PFIC status (from the ICI) will be updated in the Asset Maintenance and will be displayed in the Potential PFIC Holdings Report and the Potential PFIC Sold Report. Standard override logic is used when determining if a security is a PFIC. The reports should look first to the fund level - if there is no PFIC status, then look to the fund group level - if there is no status, then look to the Asset Maintenance level. Fig. 34 is a flow chart depicting the PFIC cost tracking holdings schedule. For all lots of assets considered to be a PFIC held by a fund, an adjusted cost basis must be calculated for tax purposes. This adjusted cost basis incorporates market appreciation into the cost. This adjusted cost basis is rolled forward every year until the lot is sold. Upon disposition, the adjusted cost basis is used to determine the tax realized gain/loss. A Cost Tracking Schedule is an activity report and is used to detail the adjusted cost basis for each lot. A lot is entered on the schedule for the year it is acquired. The lot remains on the schedule for each subsequent year it is held. The lot is removed from the schedule the year in which it is sold; however, the data from the prior years should remain on the schedule. Therefore, an asset will remain on the schedule until the year in which the last lot held is sold. All monetary amounts should be in US dollars. If an asset is changed from a non- PFIC status to a PFIC status (defined in the classification logic), the tracking schedule must be recreated for all years in which the asset is held, when the report is run by the user. The Cost Tracking Holdings Report should be designed for a spreadsheet program, such as Microsoft Excel. The user 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 cost tracking schedule. This screen should have print capabilities. There should be no update functionality available. In order to make changes to the data, the user will be required to save the file as a spreadsheet and make changes outside of the System. Referring to Fig. 34, which depicts a flow chart of the PFIC cost tracking schedule, the System determines whether the asset is considered a PFIC at block 340. If not, the calculation ends. If it is a PFIC, the System determines whether this asset was held in the prior fiscal year at block 341. If not, a new cost tracking schedule is created at block 342. If the asset was held last year, the System determines whether the lot was held in the prior fiscal year at block 344. If not, a new lot is added to the existing cost tracking schedule at block 345. If the lot was held last year, the System determines whether there was a partial sale of the lot in the current fiscal year at block 346. If not, the System calculates the adjusted cost basis for the current fiscal year at block 347. If there was a partial sale, the System prorates the year's figures for the remaining shares at block 348. The System then calculates the adjusted cost basis for the current fiscal year at block 349.

Two report options are available to the user. In the first, the user may run the entire report (includes all assets held during the fiscal or excise year) or run the report for a specified asset identifier. In the second, the user may run a report for Fiscal Year End (the schedule will reflect the holdings and values as of the fiscal year end), Excise Year End (the schedule will reflect the holdings as of the last fiscal year end, but reflect the cost, adjusted cost brought forward, and the market value as of the excise year end). The report should always show the entire history of the asset. The term "Current Fiscal Year" is equal to the year in which the analysis is being completed; or, the last fiscal year end date before the current post date. For example, if the post date is 5/5/95, and the fund's fiscal year end is March, then current fiscal year would be 3/31/95.

If a lot was completely sold (through either one sale transaction or multiple ones during the year) during the current fiscal year in which the calculations are being done, then

"Complete Sale" should appear in this column. If a lot has a partial sale during the current fiscal year, then "Partial Sale" should appear in this column. If no activity has occurred on the lot for the current fiscal year, the column should be left blank.

The status should remain on the schedule for prior years. The mark to market is equal to the difference between the market value and either the: a.) Original Cost if the lot was purchased in the current year; or the b.)Adjusted Cost Brought Forward if the lot was held in the prior fiscal year. If a partial sale of the lot occurs in the current fiscal year, then both the original cost and the adjusted cost brought forward from the prior fiscal year must be prorated for the shares remaining in the current fiscal year. Mark to Market only applies if there is market appreciation (market value > cost). Thus, if there is market depreciation, the mark to market field should be populated with " — ."

The ending adjusted cost is equal to the higher of the market value or: a.) Original Cost if the lot was purchased in the current year; or the b.) Adjusted Cost Brought Forward if the lot was held in the prior fiscal year. The adjusted cost brought forward is equal to the ending adjusted cost of the lot from the prior fiscal year. If the lot was not held in the prior fiscal year, then this column should be populated with "N/A." If a partial sale of the lot occurs in the current fiscal year, then the adjusted cost brought forward from the prior fiscal year must be prorated for the shares remaining in the current fiscal year.

When run for all assets, the report should sort alphabetically by the asset description. Within each asset, the detailed schedule should sort by fiscal year end and within each fiscal year end, by lot number. The report should subtotal for each fiscal year end, the shares, original cost, adjusted cost brought forward, market value, PFIC mark to market, and the ending adjusted cost for assets that have more than one lot. No grand total is needed for the asset or for the report.

The System also permits calculation of the adjusted cost basis for PFIC holdings for the excise period (10/31/XX)(" PFIC Cost Tracking - Holdings - Excise"). In order for an asset to appear on the excise year end schedule, it must have been treated as a PFIC at the previous fiscal year. If an asset was held at the last fiscal year end, then it would appear on the excise report, unless it was sold before the excise year end date. If additional shares of that asset have been purchased, those new lots would be included in the excise report. The adjusted cost brought forward would be equal to the value as of the prior excise year end (10/31/94) The market value would be equal to the value as of the excise date (10/31/95). The logic for the calculation of PFIC mark to market and ending adjusted cost is the same as the PFIC Cost Tracking - Holdings report, except that references to "Fiscal Year" would be replaced with "Excise Year." Referring to Fig. 34, the System provides a report of PFIC Cost Tracking - Sold

Schedule. When a lot of an asset considered to be a PFIC is sold, the adjusted cost basis is used to calculate the tax gain/loss. A cost sold tracking schedule details the calculations for these transactions. All monetary amounts should be in US dollars. If an asset is changed from a non-PFIC status to a PFIC status (defined in the classification logic), the tracking schedule must be recreated for all years in which the asset is held when the report is run by the user. The Cost Tracking Sold Report should be designed for a spread sheet program such as Microsoft Excel. The user should be able to see at the fund level, a list of PFIC holdings that have had sale transactions. By double clicking or selecting a cusip, the user should be able to "drill down" and see the entire cost tracking sold schedule. This screen should have print capabilities. There should be no update functionality available. In order to make changes to the data, the user will be required to save the file as an Excel spreadsheet and make changes outside of the System.

In this case, Two report options are available to the user. In the first, the user may run the entire report, which includes all sale transactions within the specified period, or run the report for a specified sedol. In the second report option, the user may runs the report for

Fiscal year end (the report will include sales that were posted in the last fiscal year) or the Excise year end (the report will include sales that were posted in the last excise year). The report should have the ability to be run for any date range, however.

The adjusted cost brought forward is always equal to the adjusted cost brought forward that was calculated from the prior fiscal year end. The figure is not updated throughout the fiscal year. If the trade date of the sell is equal to the fiscal year end date, use the adjusted cost brought forward from the prior year end. If the lot were not held in the prior fiscal year, then the original cost would be used. Thus, there would be no tax gain/loss, as it would equal the book gain/loss.

The adjusted cost brought forward is always equal to the adjusted cost brought forward that was calculated from the prior excise year end. The figure is not updated throughout the excise year. If the trade date of the sell is equal to the excise year end date, use the adjusted cost brought forward from the prior year end. If the lot were not held in the prior excise year, then the original cost would be used. Thus, there would be no tax gain loss, as it would equal the book gain loss. The gain or loss would be considered short-term if the number of days from the trade date of the purchase date to the trade date of the sale were equal to or less than 1 year. The gain or loss would be considered long-term if the number of days from the trade date of the purchase date of the lot to the trade date of the sale were greater than 1 year. The Tax Adjustment equals the tax gain/loss minus the book gain/loss. By definition, this will always be a negative number. For each asset, the report should subtotal the shares, original cost, adjusted cost brought forward, proceeds, short-term and long-term tax gain loss short-term and long-term book gain/loss, and the tax adjustment for transactions that have more than one lot.

The present invention has been described in terms of the preferred embodiments of the invention, which are presented for purposes of illustration and not of limitation. The present invention has several advantages over the prior art including that it can be flexibly employed with various funds, it can be easily modified to address the particular needs of a fund, it can run models with rule changes in short order. The System provides compliance testing in extremely short periods of time while providing a more accurate test result than was known in the prior art. This improved compliance testing allows for early and automatic warnings to be provided to fund managers and compliance analysts, thereby reducing the likelihood of more serious compliance violations. It will be appreciated that modifications, variations, and features within the scope of the invention, given the benefit of the disclosure, will occur to one of ordinary skill in the art.

Claims

We claim:

1. A compliance system for funds that comprise a collection of financial instruments and are governed by a predetermined set of investment rules related to the financial instruments, the system comprising:

a computer memory means for storing data;

a computer processor operably engaged to the computer memory means, the computer processor including:

means for storing the investment rules;

means for storing fund information identifying the financial instruments comprising the fund, the amount of each financial instrument and the value of each financial instrument;

means for receiving trade information concerning trades of financial instruments comprising the fund;

means for receiving value information corresponding to the value of the financial instruments over a given time period;

means for modifying the fund information based, at least in part, on at least one of either the value information or the trade information;

means for comparing the fund information to the investment rules; and

means for generating a signal based, at least in part, on the comparison.

2. A method for a financial institution to monitor compliance of client financial funds with a predetermined set of investment rules, which client financial funds comprise a collection of financial instruments, and which are monitored by a compliance analyst and controlled by a client fund manager, the method comprising:

storing the investment rules on a financial institution computer; storing fund information including the identity of the financial instruments comprising the fund, the amount of each financial instrument comprising the fund and the value of each financial instrument comprising the fund;

receiving trade information concerning trades of financial instruments comprising the fund;

receiving value information corresponding to the value of the financial instruments at a given time;

adjusting the fund information based, in part, on at least one of either the value information or the trade information;

comparing the fund information to the investment rules;

generating a signal based, at least in part, on the comparison; and

sending a message to the compliance analyst based, at least in part, on the signal.

3. The method of claim 2 wherein the signal is generated based upon a breach of the investment^, rules and wherein the message is a warning providing selected information to the compliance analyst.

4. The method of claim 3 further comprising supplying detailed information to the compliance analyst concerning the particular investment rule which was breached and the fund information concerning that breach in response to an inquiry from the analyst.

5. The method of claim 4 wherein the analyst evaluates the detailed information and contacts the client fund manager to report the breach.

6. The method of claim 2 wherein the signal is based on a comparison made at a first point in time, the method further comprising receiving additional trade information or value information after the first point in time, adjusting the fund information based, in part, on the additional trade information, receiving additional value information corresponding to the value of the financial instruments at a second point in time, adjusting the fund information based, in part, on the additional value information, comparing the adjusted fund information to the investment rules, generating an adjusted signal based, at least in part, on the comparison, and sending a warning to the compliance analyst if there is a violation of the investment rules.

7. The method of claim 6 further comprising storing information concerning the receipt of the additional information and the adjustment of the fund information.

8. A system for performing a compliance check for a financial fund, wherein the financial fund comprises a plurality of financial instruments which are purchased and sold at the direction of a fund manager, the system comprising:

means for receiving financial data concerning the financial instruments comprising the financial fund;

means for developing investment rules as a logical statement of the financial data, wherein the investment rules describe the permitted activity of the fund manager;

means for storing the investment rules;

means for developing a test comprising at least one rule;

means for applying the test to the financial data to determine whether any investment rules have potentially been violated; and

means for reporting the potential violation of the 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 information service providers external to the financial institution.

1 1. 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, by electronic means.

13. The system of claim 12 wherein the financial data is received, at least in part, via a global communications network.

14. The system of claim 9 further comprising a means for the financial institution to receive trade data from the fund manager corresponding to the sale and purchase of financial instruments comprising the fund.

15. The system of claim 14 wherein the financial institution receives trade data through its custody department who transfers it to a compliance department of the financial institution.

16. The system of claim 8 wherein the means for storing the investment rules comprises a means for storing the investment rules in a computer library.

17. The system of claim 16 wherein the means for developing investment rules comprises searching the computer library for rules previously drafted.

18. The system of claim 17 wherein the means for storing the investment rules includes a means for copying at least one investment rule from the computer library.

19. The system of claim 16 wherein the means for developing a test comprises means for copying a rules from the library.

20. The system of claim 9 further comprising means for developing a report describing the application of the test to the financial data and a display to display the report.

21. The system of claim 20 further comprising means to investigate the basis of the report.

22. The system of claim 21 wherein the display is a computer workstation and the report is presented electronically on the display and wherein the means to investigate the report comprises a user input device operably engaged to the work station.

23. A method for performing a compliance check for a financial fund, wherein the financial fund comprises a plurality of financial instruments which are purchased and sold at the direction of a fund manager, the system comprising:

receiving financial data concerning the financial instruments comprising the financial fiind;

storing the financial data; developing investment rules as a logical statement of the financial data, wherein the investment rules describe the permitted activity of the fund manager;

storing the investment rules;

developing a test comprising at least one investment rule;

applying the test to the stored financial data to determine whether any investment rules have potentially been violated; and

reporting the potential violation of the investment rules.

24. The method of claim 23 wherein the financial data is received by a computer controlled by a financial institution.

25. The method of claim 24 wherein the financial data is received, at least in part, from information service providers 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, by electronic means.

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 compnsmg receipt by the financial institution of trade data from the fund manager corresponding to the sale and purchase of financial instruments compnsmg the fund.

30. The method of claim 28 wherein the financial institution receives trade data through its custody department who transfers it to a compliance department of the financial institution.

31. The method of claim 25 wherein stoπng the investment rules compnses stoπng the investment rules in a computer library.

32. The method of claim 31 wherein developing investment rules compnses searching the computer library of rules previously drafted.

33. The method of claim 32 wherein storing the investment rules includes copying at least one investment rule from the computer library.

34. The method of claim 31 wherein developing a test comprises for copying a rules from the library.

35. The method of claim 24 further comprising developing a report descπbing the application of the test to the financial data and displaying the report on a display.

36. The method of claim 35 further comprising an agent of the financial institution investigating the basis of the report.

37. The method of claim 36 wherein the report is presented electronically on a computer workstation and wherein investigating the report comprises employing a user input device operably engaged to the workstation to click on fields in the display which are of interest to the agent.

38. The method of claim 24 wherein the investment rules are developed from conversations between the fund manager and an employee of the financial institution.

39. The method of claim 24 wherein the investment rules are promulgated by the government agency.

40. The method of claim 24 wherein the investment rules are promulgated by sponsors of the financial fund.

41. The method of claim 24 wherein potential violations are reported to an employee of the financial institution via a computer workstation.

42. The method of claim 24 wherein the potential violations are reported to an employee of the financial institution via a facsimile machine.

43. The method of claim 24 wherein the potential violations are reported to an employee of the financial institution via a beeper.

44. The method of claim 24 wherein the potential violations are reported to an employee of the financial institution via electronic mail.

45. The method of claim 24 wherein potential violations are reported to the fund manager via a computer workstation.

46. The method of claim 24 wherein the potential violations are reported to the fund manager via a facsimile machine.

47. The method of claim 24 wherein the potential violations are reported to the fund manager via a beeper.

48. The method of claim 24 wherein the potential violations are reported to the fund manager via electronic mail.

49. The method of claim 24 wherein the fund manager can access the report via a global communications network.

50. The method of claim 24 further comprising cooperating with computer systems to receive financial data and to provide reports.

51. The method of claim 24 further comprising modifying the investment rules, applying the modified investment rules to the financial data, and providing a modified report.

52. The method of claim 24 further comprising monitoring the steps of the method, retrying the steps if they are unsuccessful, and reporting the status of the steps to an employee 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 a financial analysis of a financial fund, wherein the financial fund comprises a plurality of financial instruments which are purchased and sold at the direction of a fund manager, and the financial fund has a definition defining the permitted relationship of the financial instruments comprising the financial fund, the system comprising:

means for receiving financial data which can be represented numerically and concerning the financial instruments comprising the financial fund;

means for developing investment rules as a logical statement of the financial data, wherein the investment rules describe the definition of the financial fund;

means for storing the investment rules;

means for developing a test comprising at least one investment rule;

means for reporting the determination.

55. A method for performing a financial analysis of a financial fund, wherein the financial fund is composed of a plurality of financial instruments which are purchased and sold at the direction of a fund manager, and the financial fund has a definition defining the permitted relationship of the financial instruments in the financial fund, the method compnsmg:

receiv ing financial data that can be represented numeπcally and that concerns the financial instruments in the financial fund;

developing investment rules as a logical statement of the financial data, wherein the investment rules descπbe the definition of the financial fund;

stoπng the investment rules on a computer database;

developing a test compnsmg at least one investment rule;

applying the test to the financial data to determine whether any investment rules have potentially been violated; and

reporting the determination.

56. A method for performing a financial analysis of a financial fund, wherein the financial fund is composed of a plurality of financial instruments which are purchased and sold at the direction of a fund manager, and the financial fund has a definition defining the permitted relationship of the financial instruments m the financial fund, wherein the financial analysis is performed by a financial institution having a custody department and a compliance department, the method comprising:

receiving financial data that can be represented numeπcally and that concerns the financial instruments in the financial fund, which financial data is received by a computer controlled by the financial institution;

wherein the financial data is received from, at least in part, information service providers external to the financial institution and by, at least in part, electronic media;

receiving trade data from the fund manager correspondmg to the sale and purchase of financial instruments in the fund; wherein the financial institution receives trade data through its custody department who transfers it to its compliance department;

storing the trade data and the financial data corresponding to a selected time period;

developing investment rules as a logical statement of the financial data, wherein the investment rules describe the definition of the financial fund;

storing the investment rules on a computer database;

developing a test comprising at least one investment rule;

applying the test to the financial data to determine whether any investment rules have potentially been violated during the time period;

developing a report describing the application of the test to the financial data;

displaying 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 communications network.

59. The method of claim 58 wherein storing the investment rules comprises storing the investment rules in a computer library.

60. The method of claim 59 wherein developing investment rules comprises searching the computer library of rules previously drafted.

61. The method of claim 58 wherein the report is presented electronically on a computer display.

62. A method for a financial institution to monitor client financial funds based upon a predetermined set of parameters, which client financial funds comprise a collection of financial instruments, and which are monitored by a compliance analyst and controlled by a client fund manager, the method comprising:

storing the parameters on a financial institution computer;

storing fund information including the identity of the financial instruments comprising the fund, the amount of each financial instrument comprising the fund and the value of each financial instrument comprising the fund;

receiving update information concerning changes in the fund information;

adjusting the fund information based, in part, on the update information;

comparing the fund information to the parameters;

generating a signal based, at least in part, on the comparison; and

63. The method of claim 62 wherein the parameters are promulgated by regulatory agencies, and wherein the message is a tax report concerning the fund.

64. The method of claim 62 wherein the parameters are investment guidelines that are directed to the fund information as well as the update information.

65. A method for a financial institution to monitor client financial funds and to develop financial reports for the client financial funds, which client financial funds comprise a collection of financial instruments, and which are controlled by a client fund manager, the method comprising:

storing, on a computer of the financial institution, fund information including the identity of the financial instruments comprising the fund, the amount of each financial instrument comprising the fund and the value of each financial instrument comprising the fund;

storing, on a computer of the financial institution, parameter definitions corresponding to required regulatory data for the financial fund;

receiving update information concerning changes in the fund information;

adjusting the fund information based, in part, on the update information;

retrieving, from the adjusted fund information and the update information, financial data corresponding to the parameter definitions;

generating a signal based, at least in part, on the retrieved financial data; and

sending a message to a user based, at least in part, on the signal.

66. The method of claim 65 wherein the parameters definitions are promulgated by regulatory agencies, and wherein the message is a tax report concerning the fund.

67. The method of claim 65 wherein the parameters definitions are investment guidelines that are directed to the fund information as well as the update information.

68. A computer program having a plurality of program steps to be executed on a computer to implement and control a compliance system for funds wherein the funds comprise a collection of financial instruments governed by a predetermined set of investment rules related to the financial instruments, the programs comprising: means for creating and storing the investment rules;

means for storing fund information identifying the financial instruments comprising the funds, the amount of each financial instrument and the value of each financial instrument;

means for receiving trade information concerning trades of financial instruments comprising 5 the fund;

[0 means for comparing the fund information to the investment rules; and

means for generating a signal based, at least in part, on the comparison.

69. A compliance system for funds composed of a collection of financial instruments and governed by a predetermined set of investment rules related to the financial instruments, 15 the system comprising

a computer processor having and executing a program and operational to:

store the investment rules on a financial institution computer;

store fund information including the identity of the financial instruments in the fund, the amount of each financial instrument in the fund and the value of each financial instrument in 0 the fund;

receive and store trade information concerning trades of financial instruments in the fund over a predetermined period of time;

receive value information corresponding to the value of the financial instruments at a given point in time; adjust^' the fund information based, in part, on at least one of either the value information or the trade information;

compare the fund information to the investment rules;

generate a signal based, at least in part, on the comparison; and

send a message to a compliance analyst based, at least in part, on the signal.

70. An article of manufacture comprising a computer readable storage medium having a physical substrate physically configured to represent a computer program, the computer program comprising means to store investment rules, means to store fund information including the identity of financial instruments in a fund, the quantity of each financial instrument in the fund and the value of each financial instrument in the fund, means to receive and store trade information concerning trades of financial instruments in the fund and to receive value information corresponding to the value of the financial instruments at a given point in time, means to adjust the fund information based, in part, on at least one of either the value information or the trade information, means to compare the fund information to the investment rules, and means to generate a signal based, at least in part, on the comparison.

71. A method of monitoring a client financial fund, which fund is composed of financial instruments, the method comprising:

(a) storing investment rules on a financial institution computer;

(b) receiving and storing fund information about the financial instruments in the fund on a financial institution computer;

(c) receiving trade information concerning trades of financial instruments in the fund;

(d) receiving value information concerning the value of the financial instruments in the fund;

H I (e) adjusting the fund information based, in part, on at least one of either the value information or the trade information;

(0 comparing the fund information to the investment rules; and

(g) preparing a report describing the comparison.

72. The method of claim 71 wherein the investment rales comprise rales relating to the tax requirements of the fund.

73. The method of claim 72 wherein the investment rules further comprise rales relating to the definition of the fund set forth by a fund manager.

74. The method of claim 73 wherein the investment rules further comprise rales relating to the financial performance of the fund.

75. The method of claim 73 wherein the fund information comprises holdings level data.

76. The method of claim 75 wherein the fund information comprises transaction data.

77. The method of claim 76 wherein the fund information comprises tax lot data.

78. The method of claim 77 wherein the fund information comprises general ledger data. 2854-73

79. The method of claim 78 wherein the fund information comprises foreign exchange rates.

80. The method of claim 79 wherein the fund information comprises data describing the funds.

81. The method of claim 74 wherein the fund information comprises holdings level data, transaction data, tax lot data, general ledger data, foreign exchange rates, and data describing the funds.

82. The method of claim 81 wherein at least a portion of the fund information is imported from a data source distinct from the financial institution.

83. The method of claim 71 wherein at least a portion of the fund information is imported from a data source distinct from the financial institution.

84. The method of claim 71 wherein the fund information comprises distinct portions and at least one portion is stored with a date and time stamp indicating when that portion was entered into the financial institution 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 the specific 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 submission of a query by a user regarding the report and provision of selected fund information in response to the query.

88. The method of claim 87 wherein the fund information is stored with date and time stamps indicating when an element of the fund information was entered into the financial institution computer.

89. The method of claim 71 wherein further comprising manually comparing the fund information to a compliance rale and a user manually entering a result into the financial institution computer, wherein the result is included in the report.

90. The method of claim 89 wherein the identity of the user is stored on the financial institution computer.

91. The method of claim 71 wherein the fund information comprises elements, the method further comprising identifying selected elements as reliable when they are received from within the financial institution and identifying other selected elements as unreliable when they are received from a source distinct from the financial institution.

92. The method of claim 91 further comprising requiring the manual certification of unreliable elements by a user before comparing the fund information to the investment rules.

93. The method of claim 91 further comprising designating a user as the owner of fund information wherein the reliable elements cannot be altered except with the approval of the owner.

94. The method of claim 91 wherein the elements are color-coded in the report to distinguish reliable elements from unreliable elements.

95. The method of claim 71 wherein the fund information for a plurality of funds is stored on a single financial institution computer but segmented between funds such that fund information for a given financial instrament may be updated for all funds holding the financial instrament or only for a specific fund.

96. The method of claim 71 wherein the report is electronic and is provided to a user via a global computer network.

97. The method of claim 71 further comprising scheduling any of the steps (b) - (g) such that they occur at a selected time.

98. The method of claim 71 further comprising scheduling any of the steps (b) - (g) such that they occur in a selected order.

99. The method of claim 71 wherein the investment rales must be approved by a selected person at the financial institution before it is stored on the financial institution computer.

100. The method of claim 71 wherein the investment rules can be modified immediately before the comparison.