Patent Application
20080208655
The present invention relates to the field of legal entity and financial entity creation approval and reporting. In particular, the invention provides a system and methods for generating approvals and documentation related to forming or acquiring an entity or to initiate a transaction involving an entity and storing the information in a historical database for report generation, analysis and updating.
Prior to new company entities, special purpose entities (“SPE's” and/or “financial entities”), and transactions being formed or entered into or company entities being acquired by a financial institution, these entities/transactions (hereinafter collectively “entities”) must go through an approval process. The approval process generally requires that several different individuals or groups in financial, accounting, legal, tax, treasury, and operational divisions of the institution evaluate the new or acquired entity based on their particular area of expertise to determine if certain standards or thresholds are met or policies are followed. The number of parties that must approve an entity can be numerous and the information that each approver needs to complete their evaluation of an entity can be wide-ranging. Conventional approval systems did a poor job of tracking the status of an approval for an entity once the approval request was generated. This meant that the person sponsoring the new entity for approval had to track down each approver to determine where they were in the approval process.
The conventional entity approval systems also did not automatically provide the individualized information that each approver needed to complete their analysis, or did not provide it in a format geared to the needs of that particular approver. This meant that the approver would typically have to manually transfer information from one system to another to complete their approval review. Furthermore, conventional systems generally did a poor job of pointing out a situation where an entity approval was rejected by one or more of the approvers. This resulted in approvers who completed their analysis subsequent to the rejection continuing their approval review, even though it was not necessary.
Once the entity is approved, the sponsor for the entity or another needs to notify the system that the entity was formed or acquired. Once either formed or acquired (or the transaction entered into), information relating to the entity is manually entered into in a database for future needs. These needs potentially include subsequent evaluation of the entity based on new or updated information and accumulation of information for accounting analysis, and financial, corporate, and regulatory reporting. Conventional systems for storing the historical entity information are separate from the approval system. The separation of the approval system from the historical tracking system for an entity makes it difficult to track the life cycle of an entity from its inception to its termination. Once an entity is approved, information developed or stored during the approval process must be manually transferred to the historical database if the institution wishes to use that information. Furthermore, information from the approval process and the historical information of the entity is typically needed when completing an audit. By having the approval system and the historical database system separate from each other, it increases the risk that information needed for an audit, financial, corporate, or regulatory report will be overlooked or not presented to the auditor or may unintentionally be omitted from financial, corporate, or regulatory reports.
In view of the foregoing, there is a need in the art for a method and system for generating approval documentation and monitoring the approval process of a newly formed or acquired company entity, special purpose entity, transaction or entity that is going to be acquired. Furthermore, there is a need in the art for a method and system for storing company entity and SPE related information in one or more databases and generating corporate, regulatory, accounting, and financial reporting documentation related to the company entity or SPE. In addition, there is a need in the art for a method of searching for and viewing historical information related to a company entity or an SPE. Furthermore, there is a need in the art for a single system capable of capturing and tracking information about both company entities and SPE's.
There is also a need in the art for a system and methods for generating legal structure organizational charts and/or consolidation organizational charts for company entities and SPE's. Furthermore, there is a need in the art for a system and method for generating requests to certify accounting information related to a company entity or SPE and receiving and storing the responses to the certification request in a historical database. In addition, there is a need in the art for a system and methods for evaluating data related to an SPE or company entity for changes that signify a need to review an entity's status and generating a request to review the entity's status based on the change to determine if the status of the company entity or SPE has changed or the accounting evaluation for the entity is different based on the change in the data.
The inventive system can provide efficiencies and improvements over conventional methods by automating the approval process for company entities and SPE's and by storing the approval information in a historical database. The system also provides methods for maintaining and updating information about the entity during its lifetime. For one aspect of the present invention, the approval system can accept information that identifies the type of entity or transaction for which approval is being sought. For example, the entity type can be a company entity or an SPE. Based on the entity type determined, different information can be requested and presented by the system. The system can accept descriptive, corporate, regulatory, financial, and accounting data for the entity and a series of data fields in an approval datasheet.
Approvers can be selected, automatically assigned by the system or a portion can be selected and another portion can be automatically selected by the system. The approvers evaluate the entity and the data provided to determine if the entity should be approved for creation or acquisition (or for the transaction to be entered into). The approval datasheet is transmitted to each of the selected or assigned approvers for their evaluation of the entity. The approval datasheet sent to each approver can be a subset of the entire sheet and provide only that information that is pertinent to a particular approver's review of the entity for approval. The system can evaluate that status of each approver's review to determine if the entity has been approved for acquisition or creation (or for the transaction to be entered into) and can be designated as approved if each of the approvers approves the entity. Furthermore, the system permits approvers to subject the approval of the creation or acquisition of any entity (or the entry into a transaction) to conditions.
For another aspect of the present invention, a historical database can store approval and historical information about company entities and SPE's during their lifespans. Information in the historical database for an SPE or company entity can be updated, corrected, or moved as necessary in the exemplary system. To correct a data entry for an entity in the historical database, an entity identifier can be accepted by the system. The entity identifier can be the name of the entity or an identification number for the entity. A new effective date for the new data can be accepted by the system. The data in a data field can be changed by replacing the original data with new data (i.e. data that is different than the original data).
The system can evaluate the historical record for the data field to determine the original effective date for the original data in the data field. The system can compare the new effective date to the original effective date to determine if the dates are different. If the effective dates for both the original data and the new data are the same, the system can designate the change as a correction to the information in the data field. The system can then generate a display of the data change for the data field. The display can be presented on a user interface for a computer and can include an identifier for the data field in which the change was made, the original data, the original effective date, the new data, the new effective date, and the change designation, which in the manner described was a correction.
For yet another aspect of the present invention, to update a data entry for an entity in the historical database, an entity identifier can be accepted by the system. A new effective date for the new data can be accepted by the system. The data in a data field can be changed by replacing the original data with new data. The system can evaluate the historical record for the data field to determine the original effective date for the original data in the data field.
The system can compare the new effective date to the original effective date to determine if the dates are different. If the effective dates for the original data and the new data are different, the system can designate the change as an update to the information in the data field. The system can then generate a display of the data change for the data field. The display can be presented on a user interface for a computer and can include an identifier for the data field in which the change was made, the original data, the original effective date, the new data, the new effective date, and the change designation, which in the manner described was a correction.
For yet another aspect of the present invention, to move a data entry for an entity to an earlier effective date in the historical database, an entity identifier can be accepted by the system. A new, earlier effective date for the original data can be accepted by the system. The data in a data field can be changed by entering the original data on a new, earlier effective date. The system can evaluate the historical record for the data field to determine the new, earlier effective date for the original data in the data field.
The system can compare the new earlier effective date to the original effective date to determine if the dates are different. If the effective dates for the original data are different, the system can designate the change as a move of the information in the data field. The system can then generate a display of the data change for the data field. The display can be presented on a user interface for a computer and can include an identifier for the data field in which the change was made, the original data, the original effective date, the new effective date, and the change designation, which in the manner described was a move.
From the following detailed description of the exemplary embodiments, as read in conjunction with, and in reference to, the accompanying drawings, the above aspects, objects, and features of the present invention, along with others, will become apparent to one of ordinary skill in the art.
For a more complete understanding of the exemplary embodiments of the present invention and the advantages thereof, reference is now made to the following description in conjunction with the accompanying drawings in which:
The present invention includes computer-implemented methods and systems for: generating approvals and documentation related to forming or acquiring an entity or to initiating a transaction involving an entity; storing entity or transaction information in a historical database for retrieval, analysis and report generating; generating current and historical reports related an entity or transaction, such as general corporate, regulatory and financial reporting documentation; and modifying entity or transaction information in the historical database. The present invention further includes various interactive displays and notification tools to implement or facilitate the foregoing methods and systems.
Referring now to the drawings in which like numerals represent like elements throughout the several figures, aspects of the present invention and an exemplary operating environment will be described in the context of
The exemplary operating system 100 includes an enterprise database 105. The enterprise database 105 includes one or more information storage mediums from which information is retrieved and inserted into an approval engine 110 for completing an approval process for a company entity or an SPE. In one exemplary embodiment, the enterprise database 105 includes a portion of the company entity related information and all special purpose entity (“SPE”) information, including approval records, certification records and other financial and accounting information related to SPE's. The system 100 also includes an approval engine 110 communicably attached via a distributed computer network to the enterprise database 105 and a personal computer 140. The approval engine includes a company entity approval program 115 and an SPE approval program 120.
The system 100 also includes a data pool database 125 that is communicably attached via a distributed computer network to the enterprise database 105. In one exemplary embodiment, the data pool database 125 accesses employee data 130 and provides that employee data 130 to the enterprise database 105 for us in an approval process. The system 100 includes an SPE database 145 that is communicably attached via a distributed computer network to the enterprise database 105. In one exemplary embodiment, the SPE database 145 provides information including, but not limited to, net asset value per unit for products, bid prices for products, and information about issuers and products for SPE's. The system 100 also includes the profit and loss (“P&L”) database 150, which is communicably attached via a distributed computer network to the enterprise database 105. The P&L database 150 provides financial information related to company entities, SPE's and products to the enterprise database 105. The system 100 further includes the credit database 155. The credit database 155 is communicably attached via a distributed computer network to the enterprise database 105.
The system 100 further includes a general purpose computing device that can be in the form of a conventional personal computer 140. As shown in
In step 220, an inquiry is conducted to determine if the approval process has been completed. If the approval process has not been completed, the “NO” branch is followed to step 210. On the other hand, if the approval process has been completed, the “YES” branch is followed to step 225. In step 225, an inquiry is conducted to determine if the entity has been formed or acquired or if the transaction has been closed. If the entity has not been formed or acquired or the transaction has not been closed, the “NO” branch is followed back to the beginning of step 225 to await formation or acquisition of the entity or the closure of the transaction. On the other hand, if the entity has been formed or acquired or the transaction has been closed, the “YES” branch is followed to step 230, where the date that the entity was formed or acquired or the date that the transaction was closed is accepted by the system 100 from a user.
Entity or transaction validation is completed in step 235. In one exemplary embodiment, the validation can be different for SPE's and company entities or transactions to be initiated. In step 240, general corporate, regulatory and financial information for the entities and transactions is stored in the enterprise database 105 and the system 100 begins report generation for that entity or transaction. In step 245, the entity and/or transaction information that is stored in the historical database 105 can be updated (i.e. modified to correct, update, or move the stored information). In step 250, reports can be generated based on the entity or transaction information stored in the historical database 105. The process continues from step 250 to the END step.
In step 306, an inquiry is conducted to determine the type of entity or transaction being formed. In one exemplary embodiment, the types of entities or transactions include, but are not limited to, company entities, issuances, securitizations and mutual funds. If the entity or transaction being formed is an issuance, the “Issuance” branch is followed to step 307, where the system 100 requests and receives from the user information defining the parent of the issuance so that the system 100 can form an interrelationality between the parent and the issuance. The process then continues from step 307 to step 308.
Returning to step 306, if the entity or transaction being formed is a securitization or mutual fund, the “Securitization or mutual fund” tab is followed to step 308, where the entity or transaction is fast-tracked to the SPE approval process. In step 310, an inquiry is conducted to determine if the user copies an existing datasheet that has been stored in the system 100. In one exemplary embodiment, the user may select from the database 105 a datasheet that has been previously completed in order to reduce the amount of time it may take the user to complete the datasheet. If the user copies an existing datasheet, the “YES” branch is followed to step 312. Otherwise, the user does not copy an existing datasheet and the “NO” branch is followed to step 312.
In step 312, an inquiry is conducted to determine if approval is necessary. For certain entities or transactions, the datasheet may need to be completed for tracking and report generation purposes based on the information contained therein, but the entity or transaction itself may not be required to go through the approval process. If approval is not necessary, the “NO” branch is followed to step 313, where a notification datasheet is generated and completed by a user for the entity or transaction. The process then continues from step 313 to step 235 of
Returning to step 306, if the type of entity or transaction being formed or acquired is a company entity, the “Company entity” branch is followed to step 316, where the system 100 accepts the country of formation, jurisdiction of formation and the legal form of the company entity. In step 318, the system 100 requests and accepts additional information from the user to determine if the entity or transaction being formed meets predetermined levels for voting percentage, equity percentage, or control over the entity. In one exemplary embodiment the predetermined level for voting percentage is twenty percent of total voting on an undiluted basis. In another exemplary embodiment, the predetermined level for equity percentage is twenty-five percent of total equity. If the entity or transaction meets the predetermined levels for voting percentage, equity percentage, or control over the entity, the entity or transaction will typically be categorized as a company entity. In step 320, an inquiry is conducted to determine if the entity or transaction meets the control levels. If the entity or transaction does not meet the control levels, the “NO” branch is followed to step 308. Otherwise, if the entity or transaction meets the control levels, the “YES” branch is followed to step 322 to determine if the entity or transaction is “to be formed” or “to be acquired.” In one exemplary embodiment, several different types of company entity datasheets are available for generation and submission based on whether the company entity is “to be formed” or “to be acquired” and/or based on the global legal form for the entity. In step 324, the system 100 generates a new company entity datasheet based on whether the entity is “to be formed” or “to be acquired.” The system 100 receives information in the generated datasheet and receives the request to submit the datasheet. The process then continues from step 324 to step 210 of
In step 415, data is accepted into the data fields of the tabbed screens. In step 420, an inquiry is conducted to determine if the datasheet is complete. In one exemplary embodiment, the SPE datasheets are completed or populated by front office personnel. In this exemplary embodiment, datasheet completion is based on whether all of asterisked required fields have been populated. If the datasheet is not complete, the “NO” branch is followed back to step 420. Otherwise, the “YES” branch is followed to step 425, where the “submit” button is enabled and the color of the tab changes from grey to green when all of the required fields have been populated. In step 430, the system 100 accepts the submitted datasheet. The process continues from step 430 to step 210 of
In step 510, the system 100 generates an e-mail and dashboard alerts to the assigned approvers. The accounting policy group reviews the datasheet for the entity or transaction in step 512. In step 514, information related to the financial accounting page is accepted. In one exemplary embodiment, the accounting policy group provides the information for the financial accounting page. A financial accounting memo is accepted into the datasheet application in step 516. In one exemplary embodiment, the financial accounting memo is generated by the accounting policy group.
In step 518, an inquiry is conducted to determine if the accounting policy group approves the new/acquired entity or transaction. If the accounting policy group does not approve the new/acquired entity or transaction, the “NO” branch is followed to step 526. Otherwise, the “YES” branch is followed to step 520, where the system 100 generates an e-mail and dashboard alert. In step 522, an inquiry is conducted to determine if all of the other remaining assigned approvers approved the new/acquired entity or transaction. If the remaining approvers did not approve the new/acquired entity or transaction, the “NO” branch is followed to step 526. On the other hand, if the remaining approvers did approve the new/acquired entity or transaction, the “YES” branch is followed to step 524. In step 524, an inquiry is conducted to determine if there are any conditions to the approvals posted by the approvers. In one exemplary embodiment, an approver may place one or more conditions on the approver's approval of the entity or transaction that must be met before actual approval is granted by the approver. If there are conditions to the approval, the “YES” branch is followed to step 556 of
In step 526, an inquiry is conducted to determine if the approval of the new or acquired entity or transaction was rejected by one or more persons in the approval group. If the approval was not rejected, the “NO” branch is followed to step 538. Otherwise, the “YES” branch is followed to step 528, where the system 100 generates a pop-up box requesting the reason for the rejection. In one exemplary embodiment, the approver who rejects the approval of the entity or transaction will provide information related to why they decided to reject it. In step 530, the system 100 accepts the reasoning for the rejection. The system 100 generates an e-mail and dashboard alert to the sponsor and all approvers regarding the fact that one of the approvers rejected the entity or transaction in step 532. In step 534, the approval list is updated with the rejection of one of the approvers and the remaining approvals are locked out so that no additional approvals or rejections may be accepted. In step 536, the system 100 changes the status of the entity or transaction such that the status is designated as “rejected.” The process continues from step 536 to step 554.
In step 538, an inquiry is conducted to determine if the current date is equal to the approval reminder date. In one exemplary embodiment, the approval reminder date is a date provided by the administrator that assigns the approvers and is a date such that, if an approver has not approved or rejected an entity or transaction by the approval reminder date, that particular approver will be sent a reminder e-mail message that an approval is necessary within a short period of time. If the current date is equal to the approval reminder date for the current entity or transaction, the “YES” branch is followed to step 540, where the system 100 generates an e-mail and dashboard alert for all approvers who have not yet approved or rejected the entity or transaction. On the other hand, if the date is not equal to the approval reminder date, the “NO” branch is followed to step 542.
In step 542, the administrator sends the final documents to the accounting policy group. The accounting policy group reviews the final documents and verifies its prior approval in the financial accounting tab in step 544. In step 546, an inquiry is conducted to determine if the accounting policy group has changed its approval. If the accounting policy group has not changed is approval, the “NO” branch is followed to step 548, where the system 100 changes the status of the entity or transaction such that the status is designated as “approved.” The process continues from step 548 to step 235 of
Returning to the “YES” branch originating in step 524 of
In step 560, an inquiry is conducted to determine if the SPE or transaction is a consolidated entity that the chief financial officer or other executive must approve. If the SPE or transaction is not a consolidated entity, the “NO” branch is followed to step 566. If the entity or transaction is a consolidated entity that must be approved by the CFO or other executive, the “YES” branch is followed to step 562, where the system 100 changes the status of the entity or transaction such that the status is designated as “awaiting CFO approval.” In step 564, an inquiry is conducted to determine if the CFO or other executive has approved the entity or transaction. If not, the “NO” branch is followed to step 564 to await CFO approval. Otherwise, the “YES” branch is followed to step 566, where the system 100 changes the status of the entity such that the status for the current entity is designated as “approved” or “approved to trade.” In step 570, the system 100 generates an e-mail. The process then continues from step 570 of
An email is generated and transmitted to each selected approver in step 620. In step 625, the system 100 generates a listing of approvers by department and lists the status of approval for each approver. In step 630, the system 100 generates a decision button and decision status next to each approvers name in the approval tab. The process continues from step 630 to step 508 of
In step 708, an inquiry is conducted to determine if the requester of the status is an administrator, sponsor, preparer, or approver. In one exemplary embodiment, the requester is capable of qualifying as more than one of the positions above. If the requester is an administrator, sponsor, or preparer, the “Administrator, sponsor or preparer” branch is followed to step 710. On the other hand, if the requester is an approver, the “Approver” branch is followed to step 718. In step 710, an inquiry is conducted to determine if there are any new or acquired entities with the status of “incomplete” within the group of new or acquired entities that were retrieved for the particular requester. If there are new or acquired entities with the status of “incomplete,” the “YES” branch is followed to step 712, where the system 100 lists each new or acquired entity with the entity ID, entity name, preparer, department, and deal closure date in an “Incomplete” datasheet table. A copy of the “Incomplete” datasheet table is provided
In step 714, an inquiry is conducted to determine if there are any new or acquired entities with the status of “initiated.” If there are new or acquired entities with the status of “initiated” in the list that was retrieved in step 706, the “YES” branch is followed to step 716, where the system 100 lists each entity with its entity ID, entity name, preparer, department, and deal closure date in the “Submitted” datasheet table. A copy of the “Submitted” datasheet table is provided in
In step 722, an inquiry is conducted to determine if there are any new or acquired entities with the status of “approved, not validated,” “approved, not formed,” or “formed, not validated” in the list of entities retrieved in step 706. If there are new or acquired entities with the status of “approved, not validated” or “formed, not validated,” the “Approved not validated or formed not validated” branch is followed to step 724, where the system 100 generates a corresponding icon to begin the validation process. The process then continues from step 724 to step 732. On the other hand, if there are entities with the status of “approved, not formed,” the “Approved, not formed” branch is followed to step 726, where the system 100 generates a corresponding icon to insert the formation date for the entity. In step 728, an inquiry is conducted to determine if the formation date has been received by the system 100. If the formation date has not been received, the “NO” branch is followed to step 728. Otherwise, the “YES” branch is followed to step 730, where the system 100 generates a corresponding icon to begin validation.
In step 732, the system 100 lists each entity with its entity ID, entity name, preparer, department, and deal closure date in an “Approved entities” datasheet table. A copy of the “Approved entities” datasheet table is provided in
Exemplary types of dashboard alerts for the transaction support group include, but are not limited to SPE's awaiting final documents; datasheets submitted; SPE's with leavers; SPE's approvals pending; and SPE conditions outstanding. Exemplary types of dashboard alerts for the accounting policy group include, but are not limited to approvals pending; final opinion pending; reassessments pending; and trigger event approvals pending. Exemplary types of dashboard alerts for the sponsor and/or preparer include, but are not limited to incomplete datasheets; acknowledgements pending; SPE's awaiting final documents; and SPE's awaiting certification. Exemplary types of dashboard alerts for the approvers and the chief financial officer include, but are not limited to approvals pending. Exemplary types of dashboard alerts for the responsible party include, but is not limited to SPE conditions outstanding.
Returning to step 736, if there are not any dashboard alerts for the requester, the “NO” branch is followed to step 740 of
In step 820, an inquiry is conducted to determine if all of the fields for the SPE entity validation form are populated and correct. If all of the fields in the entity validation form are not populated or not correct, the “NO” branch is followed to step 820. Otherwise, the “YES” branch is followed to step 825, where the validation button is enabled. In step 830, the user selects the validation button and the system 100 moves the entity or transaction information into the historical database 105. In one exemplary embodiment, all of the data in all of the data fields for the SPE datasheet is stored in the historical database 105. The process continues from step 830 to step 240 of
In step 850, an inquiry is conducted to determine if all of the fields for the entity validation form are populated and correct. If all of the fields in the company entity validation form are not populated or not correct, the “NO” branch is followed to step 855. In step 855, an inquiry is conducted to determine if the user wants to save the entity validation form and complete it at a later date or time. If the user wants to complete the entity validation form later, the “YES” branch is followed to step 860, where the entity validation form is saved. In step 865, the system 100 allows the company entity validation form to remain in a saved format for an unspecified, extended period of time. Returning to step 855, if the user does not want to complete the company entity validation form later, the “NO” branch is followed to step 870 where the system 100 awaits the remaining fields to be populated or can request that the remaining fields be populated.
Returning to step 850, if all of the fields in the company entity validation form are populated and correct, the “YES” branch is followed to step 873. In step 873, the system 100 accepts confirmation that the information in the validation form is complete and accurate. In one exemplary embodiment, a user completes this confirmation on a line-by-line basis by selecting and placing check marks in a series of boxes on the display. In step 875, the validation button is enabled. In step 880, the user selects the validation button and the system 100 moves the predetermined fields of company entity information into the historical database 105. In one exemplary embodiment, only data from a portion of the data fields in the company entity datasheet is saved into the historical database 105. The process continues from step 880 to step 240 of
In step 910, the certification type is accepted by the system 100. In one exemplary embodiment, each certification type has a different set of certification questions, certifiers and certification managers associated with it. In one exemplary embodiment, the certification types include, but are not limited to, entity manager, special purpose entity sponsor, SPE's and mutual funds, and regional controller. The system 100 accepts the entity or transaction type for the entity that will be certified in step 915. The region and region type for the entities to be certified are accepted in step 920. In one exemplary embodiment, the region types include, but are not limited to, transaction support, corporate secretary, regional management, and consolidation regions. Regions can include, but art not limited to, global, Americas, Asia/Pacific, EMEA, and Switzerland. One or more regions may be selected for the certification process.
In step 925, one or more drop-down boxes may be provided to allow a user to select a group of certifiers. The template is stored in step 930. A template is selected for completing a certification request in step 935. In one exemplary embodiment, the system 100 stores all current and archived certifications. The current certifications are typically organized by certification name and displayed as a link. Upon selection of the link, the details of that particular certification request are displayed. The link to the archived certifications provide a user with access to historical certification reports.
In step 940, the certifiers are automatically selected and the system 100 accepts the date of the certification deadline. In one exemplary embodiment, the information for conducting the certification include, but is not limited to, the certification period, the entity effective date, certification frequency, the certification start date, and the certification reminder date. In one exemplary embodiment, certification frequency sets forth the number of certification periods that occur within a given year. The certification frequency includes, but is not limited to, quarterly, semi-annual, annual, and ad-hoc. In step 950, once the information is received, the system 100 prompts the user to select specific entity filters, such as entity status, type, etc., to define the specific certification population. The system 100 generates an e-mail and dashboard alert to all certifiers requesting that certification of the entity be completed in step 955. In step 960, a certifier may select a link in the e-mail or on the digital dashboard to access the certification.
In step 965, the system 100 displays a listing of entities that the certifier is believed to be a financial controller for and requests confirmation of the controller status from the certifier. A certifier's entity ownership confirmation is accepted from the certifier in step 970. In step 975, an inquiry is conducted by the system 100 to determine if ownership by the certifier was verified. If not, the “NO” branch is followed to step 990. Otherwise, the “YES” branch is followed to step 980, where the certification questions for all entities upon which the certifier verified ownership are presented to the certifier on the user interface by the system 100. A completed certification request is accepted by the system 100 from a certifier in step 985. In step 990, a listing of entities for which ownership was not verified or for which the answer to verification was “NO” is generated and presented to the administrator in the administrator's rejection list. The process then continues from step 990 to the END step.
In step 1008, the system 100 accepts additional “include”/“exclude” criteria. In one exemplary embodiment, “include” thresholds include, but are not limited to, a selection of the region, the division, the domicile for the entity, whether the entity is a branch, representative office, or small merchant banking investment. In particular, in one exemplary embodiment, the additional criteria includes criteria to determine entities that are “otherwise controlled” by an entity. A determination is made in step 1010 if each entity is included or excluded based on the accepted thresholds and criteria of steps 1005, 1006, and 1008. In step 1012, counter variable X is set equal to one. Counter variable X represents an entity in the organizational chart. The system 100 accepts the first entity in step 1014. In step 1016, an inquiry is conducted to determine if the aggregate total voting interest in the first entity is non-equal. If the voting interest in the first entity is non-equal, the “YES” branch is followed to step 1018, where the entity with the highest voting interest is designated as the primary parent of the first entity. The process then continues to step 1025. On the other hand, if the voting interest in the first entity is equal, the “NO” branch is followed to step 1020.
In step 1020, an inquiry is conducted to determine if one parent of the first entity has a higher organizational level. If one parent does have a higher organizational level, the “YES” branch is followed to step 1022, where the parent with the higher organizational level is designated as the primary parent for the first entity. The process then continues to step 1025. Returning to step 1020, if neither parent has a higher organizational level, the “NO” branch is followed to step 1024, where the system 100 determines the primary parent for the child entities according to alphabetical order. In one exemplary embodiment, the parent that is listed first in alphabetical order is designated as the primary parent.
In step 1025, for entities that have more than one parent entity, the remaining parent entities of each entity, based on interrelationality, are listed in a separate column and sorted by the highest voting interest or highest equity interest and if both voting and equity interests are equal, then alphabetically. In step 1026, an inquiry is conducted to determine if there is another entity to evaluate. If there is another entity to evaluate the “YES” branch is followed to step 1028, where counter variable X is incremented by 1. The process then returns to step 1014 to accept the next entity. Returning to step 1026, if there are no additional entities to evaluate, the “NO” branch is followed to step 1030, where the system 100 determines the branches of each entity.
In step 1032, the branch entities for each entity are listed in alphabetical order below the entity. In step 1034, a determination is made as to which entities are representative offices of each entity. The representative office entities are listed in alphabetical order below the entity in step 1036. In step 1037, the system 100 lists the child entities under the entity in alphabetical order. In step 1038, the entities that are otherwise controlled by the entity are listed in alphabetical order below the entity. The process continues from step 1038 to the END step. Those skilled in the art will appreciate that steps 1018-1025 and 1030-1038 of
A determination is made in step 1112 if each entity is included or excluded based on the accepted criteria. In step 1114, the system 100 lists all of the child entities that have a consolidation relation to the selected entity based on the selected consolidation status and the selected GAAP in alphabetical order by entity name. Representative examples of the consolidation status options that can be selected when United States GAAP is selected include, but are not limited to, consolidated—subsidiary; consolidated—branch/representative office; equity accounted; fair market value; cost accounted; non variable interest entity—not consolidated; variable interest entity—consolidated; variable interest entity—not consolidated. Representative examples of the consolidation status options that can be selected when Swiss GAAP is selected include, but are not limited to, consolidated—subsidiary; consolidated—branch/representative office; equity accounted; not consolidated; participation; variable interest entity—consolidated; fair market value.
In step 1116, for each child entity listed under the selected entity, the system 100 lists in alphabetical order by entity name all of the child entities that have a consolidation relation to the selected entity based on the selected consolidation status and the selected GAAP. In one exemplary embodiment, the process of selecting each entity listed in the previous step and listing all the other entities that have a consolidated relation continues until the entities listed beneath do not have additional entities that have a consolidation interest.
In step 1118, an inquiry is conducted to determine if any of the listed child entities have more than one parent. If so, the “YES” branch is followed to step 1120, where each child entity is listed under every parent entity for which it is a child. Otherwise, the “NO” branch is followed to step 1122. In step 1122, an inquiry is conducted to determine if there is another parent entity to evaluate. If there is another parent entity, the “YES” branch is followed to step 1124 where the system 100 selects the next parent entity. The process then returns to step 1114. Returning to step 1122, if there are no additional parent entities, the “NO” branch is followed to step 1126, where the system 100 lists all other parents of each entity, based on interrelationality, in a separate column in the report, sorted by highest voting interest or highest equity interest, and if both equity and voting interest are equal, then alphabetically. The process continues from step 1126 to the END step.
In step 1215, the system 100 accepts the mandatory baseline data in the mandatory data fields. In one exemplary embodiment, the mandatory data fields include the edit as of date, entity category, entity type and entity status. In step 1220, an inquiry is conducted to determine if all of the mandatory fields in the ad-hoc reporting menu have been populated. If not, the “NO” branch is followed to step 1220 to await population of the mandatory data fields. Otherwise, the “YES” branch is followed to step 1222. In step 1222, the filter selection fields are displayed based on user permissions. In one exemplary embodiment, each filterable field has an assigned security level to it and each user of the system 100 has an assigned security level. If the security level of the user satisfies the security level of the filterable field (for example it is the same as or higher than the security level for the filterable field), the filterable field will be displayed for selection by the user. Thus, in one exemplary embodiment, a user of the system 100 is only able to see those fields that the user has permission to view. Those of ordinary skill in the art will recognize that several alternative methods for restricting the access of a user to seeing or searching by the field are available within the conventional arts and are considered within the scope of this invention.
In step 1225, the system 100 accepts a filter selection from a listing of available filters. Upon selection of a filter from the available filters list, the system 100 moves the selected filter to the listing of selected filters in step 1230 and generates a listing of available values for the selected filter in the “available values” box in step 1235. A user selects a value for the filter in step 1240. Examples of filters include, but are not limited to, deal date, division, entity ID, entity name, country of jurisdiction or formation, acquisition date, country, sponsor product, regional management region, etc.
In step 1245, an inquiry is conducted to determine if another filter is selected. If another filter is selected, the “YES” branch is followed to step 1225 to accept the next filter selection. On the other hand, if another filter is not selected, the “NO” branch is followed to step 1247. In step 1247, the system 100 accepts the fields that will be included in the report by receiving a selection of one or more fields in the “hidden fields” box and moving the selected field(s) to the “viewable fields” box. The order of the fields in the ad-hoc report can be reorganized by modifying the order of the fields in the “viewable fields” box in step 1250.
In step 1255, the system 100 accepts the selection of the “show criteria” button, requesting the generation and display of the criteria selected for the report. A summary of the report criteria is generated and displayed in step 1260. In step 1265, the “generate report button is selected by the user. In step 1270, the user is provided with the opportunity to save the report parameters for subsequent use. In an alternative embodiment of step 1270, the user is provided with the ability to export the report to a spreadsheet application. In step 1275, the system 100 accepts a subsequent selection of the “generate” button.
The system 100 evaluates the historical record database 105 contents to determine the results based on the selected filters and mandatory fields in step 1280. A security subroutine determines what data the user completing the search request has authority to view. The system 100 includes security functionality that allows a user to only search and retrieve information that the user has permission to view via their database security role. In step 1285, the system 100 sorts and displays the results that the user has the authority to view based on the user's security level. In one exemplary embodiment, the results that a user can view are determined based on a comparison of the security level of the user with the security level of the particular data in the database 105. If the user's security level is higher than or equal with that of the data, the user is able to view the data. In one exemplary embodiment, the results are sorted by the entity identification number and entity name. In an alternative exemplary embodiment, the user can sort the results based on the hierarchy of viewable fields selected for the report such that the results will be sorted first by the top field in the “viewable field” box and the sort will work progressively downward through the listing of fields in the “viewable field” box. The process continues from step 1285 to the END step.
While not presented in a representative flowchart, additional search methods are provided in the inventive system 100. For example, as shown in
In an alternative embodiment, the user may employ a wildcard function by placing an asterisk on the front, back or both sides of the input search term. By placing the asterisk prior to the search term, the system 100 will search for and return results that have an ending that matches the search term. By placing the asterisk on the back side of the search term, the system 100 will search for and return results that have a beginning that matches the search term. By placing an asterisk on both sides of the search term, the system 100 will search for and return results that have the search term anywhere within that result. The search techniques described above may also be incorporated into the ad-hoc search process through the filter selection and value selection process of steps 1225-1240 of
In step 1306, the entity information is obtained based on the selected parameters and imported into the system 100. In one exemplary embodiment, the data is imported into the enterprise system 100 from other linked data systems. This data may be received by the system 100 through automatic feeds or through templates imported into the system 100. To ensure the integrity of the data, in an exemplary embodiment, a data integrity check of the data imported into the system 100 is completed in step 1308.
In step 1310, the system 100 evaluates the trigger event fields for each entity to determine if a change has been made to one of the fields. In one exemplary embodiment, what is and is not a triggering event is based on Financial Accounting Standards Board Interpretation No. 46R. In an exemplary embodiment, these trigger event fields may include, but are not limited to, the fields listed below in Table 1.
In an exemplary embodiment, the trigger event fields can be evaluated and adjusted through the product tab. However, regardless of which trigger events are specified, if the system 100 detects a change in one of the trigger event fields, the entity is added to a reassessment report (as discussed below). Accordingly, in one exemplary embodiment, the system 100 monitors entities since the last disclosure report to detect when data affecting the trigger event fields is updated. If a trigger event is detected, the entity is added to a reassessment report that can be accessed and used to produce a subsequent disclosure report.
According to an exemplary embodiment, the system 100 may allow a user to create a new report or run a pending report. When a chooses to run a pending report, the system 100 generate selectable options to perform a reassessment, prepare a disclosure report, or run a final disclosure report. In step 1312, the system 100 accepts a request to perform a reassessment by running a change report (i.e., reassessment report). In an exemplary embodiment, the reassessment report will reflect information in the database 105 for the preceding quarter and will comprise entities with changes to trigger event fields during that quarter.
For each entity listed in the reassessment report, the system 100 provides a list comprising the field that was changed, the prior entry in that field, and the current entry in that field. An exemplary version of a reassessment report is provided in
In step 1314, each changed trigger event in the change report is evaluated to determine if a reassessment of the entity or transaction is necessary. In step 1316, an inquiry is conducted to determine if a reassessment by the accounting policy group for the entity or transaction is necessary based on the change in the trigger event. If a reassessment is necessary, the “YES” branch is followed to step 1318, where the system 100 accepts selection of the voting button requesting reassessment of an entity or transaction. The reassessment is completed in step 1320. In one exemplary embodiment, the reassessment of the entity or transaction is completed by the accounting policy group. This reassessment is performed through a reassessment form generated by the system 100. An example of a reassessment form is illustrated in
In step 1322, an inquiry is conducted to determine if the opinion of the accounting policy group is revised. If the opinion is not revised, the “NO” branch is followed to step 1328. Otherwise, the “YES” branch is followed to step 1324, where the revised opinion is saved as a new historical opinion in the database 105 and the database 105 registers the revised opinion as an update. In step 1326, the reasons for the changes to the opinion are accepted by the system 100. The process continues from step 1326 to step 1330. Saving the reassessment performed by the accounting policy group and the reasons for the changes allows a member of a transaction support group or other party to review the changes at a later time and either accept or amend the reassessment. Further, according to an exemplary embodiment, at any time during the reporting process, a sample disclosure report is generated based on the changes made to the entities without generating a final report. In this way, the changes to the entities can be viewed instantaneously as the changes are performed. The system 100 can generate a sample disclosure report by storing the reassessment report and accepting a request to prepare a disclosure report. In one exemplary embodiment, an option to generate a sample disclosure report is displayed on the disclosure reporting menu provided by the system 100. An exemplary menu for running a reassessment report and disclosure report is illustrated in
Returning to step 1316, if a reassessment of the entity or transaction is not necessary, the “NO” branch is followed to step 1328. In step 1328, if reassessment was not completed or the opinion was not changed, the determination of whether the entity or transaction should be added to a disclosure report is based on whether the entity or transaction was disclosed in the prior disclosure report for the prior reporting period. However, if the entity is newly created and is of significant interest, it may be displayed in the report despite not being previously disclosed (as discussed with regard to
In step 1330, the system 100 accepts the product category for each entity that was reassessed. In one exemplary embodiment, the product categories include, but are not limited to, commercialized debt obligation (“CDO”), commercial paper conduit (“CP Conduit”), and financial intermediates. In step 1332, the total assets for each entity or transaction to be disclosed are accepted. The maximum exposure to loss for each entity to be disclosed is accepted in step 1334.
In step 1336, an inquiry is conducted to determine if any of the values of the report need to be edited. In one exemplary embodiment, the user generating the report, which may be transaction support, has the capability to edit values prior to finalizing and printing or exporting the disclosure report to another application or system 100. If the values will be edited, the “YES” branch is followed to step 1338, where the system 100 accepts edits to the values of one or more fields in the disclosure report. Otherwise, the “NO” branch is followed to step 1340, where the system 100 generates the disclosure report. An exemplary disclosure report and additional information related to the creation of the disclosure report is included in
According to an exemplary embodiment, the system 100 tracks and receives updated data for entities tracked by the system 100. The exemplary method 1400 begins at the START step and continues to step 1405. At step 1405, the system 100 determines whether the entities stored in the system 100 were validated within the last quarter. If so, the “YES” branch is followed to step 1410, where the system 100 determines if there are historical records in the products tab. If the entity has been disclosed before, then the “YES” branch is followed and the entity is added to the reassessment report in step 1435. If, instead, the entity has not been disclosed in a disclosure report during the previous reporting period, then the “NO” branch is followed to step 1415, where the system 100 determines whether the entity should be added to a disclosure report. To determine whether to add the entity to a disclosure report, the system 100 detects if the entity has been marked as one of significant interest (e.g., the system 100 looks to see if the significant interest bit is set for the entity). If the entity is marked as one of significant interest, then the “YES” branch is followed and the entity is placed in the disclosure report. In one exemplary embodiment, the entity is placed in a listing of entities categorized as “New VIEs/Entities newly classified as VIE” in the disclosure report. However, if the entity is not of significant interest (i.e., it should not be disclosed), then is the system 100 excludes the entity from the disclosure report in step 1450.
Returning to step 1405, if the entity was not validated within the last quarter, the “NO” branch is followed to step 1420b. There, the system 100 checks to see if a trigger event occurred for the entity. Examples of trigger events are listed in Table 1, above. If a trigger event is detected, the “YES” branch is followed to step 1430. If a trigger event is not detected, then the “NO” branch is followed to step 1425. There, the system 100 determines if the entity should be placed in the disclosure report despite the absence of a trigger event (as discussed below).
Returning to step 1430, the system 100 compares the current value of the trigger event field to a historical value for the trigger event field stored in the system 100. In this way, the system 100 determines whether the value for the trigger event is different than the historical value (i.e., is the value for the trigger event different than it was the last quarter). If the system 100 determines the value to be different, then the “YES” branch is followed to step 1435, where the system 100 adds the entity to the reassessment report. However, if the value of the trigger event field did not change from the last report, then the “NO” branch is followed to step 1425. Because of these steps, the system 100 will not add an entity to the reassessment report simply because the entity has had trigger events occur since the last disclosure reporting period, but the entity has returned to status quo (e.g., total number of units fluctuated during a quarter, but the total number remains the same at the end of the current reporting period as it was at the end of the prior reporting period).
In step 1425, the system 100 determines whether the entity should be placed in the disclosure report (e.g., whether the entity is of significant interest). Similar to step 1415, at step 1425 the system 100 evaluates data entries for the entity to determine if the entity has been marked as one of significant interest. If the entity is not marked as one of significant interest, then the “NO” branch is followed and the system 100 excludes the entity is excluded from the disclosure report in step 1450. However, if the entity has been marked as one of significant interest, then the “YES” branch is followed and information for the entity is added to the disclosure report. In one exemplary embodiment, the entity is categorized in the disclosure report as “New VIEs/Entities newly classified as VIE”.
Once the system 100 determines whether the entity should be presented in the disclosure report, excluded from the disclosure report, or added to the reassessment report, it generates a reassessment request form for completing a reassessment. An exemplary embodiment of this process is illustrated in
If a reassessment request is received, the system 100 generates and displays a reassessment form at step 1520 so that changes can be made to fields applicable to the entity. These editable fields in the reassessment form may include, but are not limited to: QSPE; Sale Accounting Permitted Y/N; company entity that cannot derecognize; consolidated Y/N; company entity that consolidates; reason for Consolidation/Non-Consolidation; and Significant Y/N. In one exemplary embodiment, the system 100 accepts changes to the reassessment form from a member of the accounting policy group and stores the reassessment changes in the database 105.
At step 1525, the system 100 reviews the changes saved by the user and determines if the significant interest field remains the same for the entity after the reassessment form has been altered. If so, then the “YES” branch is followed to step 1530, where the system 100 assigns a “No change” indicator to the entity in the reassessment report to alert the reviewer (i.e., in an exemplary embodiment, a member of the transaction report group) that a reassessment is not necessary. However, if the system 100 detects that the significant interest field has changed (e.g., “Y” to “N” or “N” to “Y”), then the “NO” branch is followed to step 1535. At step 1535, the system 100 checks to determine if the significant interest field has changed from a yes, “Y”, to a no, “N”. If not, then the “NO” branch is followed to step 1540, where the system 100 supplies a drop-down box so that the reviewer (e.g., a member of the transaction support group) can specify the reassessed entity into a specific category for the disclosure report. In an exemplary embodiment, the system 100 generates a drop-down box that includes one of the following categories when the significant interest field is changed from a “Y” to a “N”: “New”, “No Longer PB,” or “Region Transfer (+)”. Similarly, if the system 100 detects that the significant interest field has been changed from a “Y” to a “N” (i.e., it has been changed from “N” to “Y”), then the system 100 will present a different set of categories for the reviewer at step 1545. According to an exemplary embodiment, these categories include, but are not limited to: “Now PB”; “Disposed”; “Region Transfer (−)”: or “Exclude from Disclosure”.
After the system 100 accepts a selection of one of the categories presented by the system 100 for each entity, the system 100 generates the draft and final versions of the disclosure report. Also, in an exemplary embodiment, a sample disclosure report may be generated by the system 100 at any time during the process by the system 100. When the option to run a disclosure report is received by the system 100, the system 100 displays the entities in the categories to which each has been assigned by the system 100 or the reviewer. Further, those entities marked by the reviewer or system 100 as “Exclude from Disclosure” will not be disclosed in the disclosure report. Once the system 100 generates a disclosure report, manual changes can be made to it. Once the report is acceptable, the system 100 generates the final disclosure report. The system 100 can export the report to another system or print it out.
A change to one or more data fields is accepted by the system 100 from the user in step 1615. The system 100 determines if the effective date has changed for the data fields that were changed by the user in step 1620. In step 1625, the system 100 recognizes the change to the information in the data fields as a “correction” because the data fields had a change to the data but no change to the effective date for that data. In another exemplary embodiment, if the data field did not previously contain data and the user goes in and puts data into that data field, the system 100 would recognize the insertion as a correction, no matter what date is selected. In step 1630, the system 100 generates a change details report displaying the fields that were changed. In one exemplary embodiment, the change details report includes, the prior field entry, the effective date of the prior field entry, the current field entry, the effective date of the current field entry, and the type of change, which is listed as a “correction.” An exemplary display of a “correction” change details report is provided in
In step 1640, an inquiry is conducted to determine if there is another data change to the same field(s) in the database 105 subsequent to the effective date of the current data change. If there is a subsequent change, the “YES” branch is followed to step 1645, where the historical database 105 propagates and saves the newly entered data field information on an occurrence-by-occurrence basis until one minute before the effective date of the next different information recorded in that data field in the historical database 105. In one exemplary embodiment, an occurrence is a record or something that has a record data, or a change to a record in the historical database 105. The process continues from step 1645 to the END step. Returning to step 1640, if there is not a subsequent change, the “NO” branch is followed to step 1650, where the historical database 105 propagates and saves the new data field information on an occurrence-by-occurrence basis until the present date. The process continues from step 1650 to the END step.
A change to one or more data fields that contained data is accepted by the system 100 from the user in step 1715. The system 100 determines if the effective date was changed to a date more recent than the effective date of the prior entry for the data fields that were changed by the user in step 1720. In step 1725, the system 100 recognizes the change as an “update” if both the effective date for the data field and the data within the data field has changed. In step 1730, the system 100 generates a change details report displaying the fields that were changed. In one exemplary embodiment, the change details report includes, the prior field entry, the effective date of the prior field entry, the current field entry, the effective date of the current field entry, and the type of change, which is listed as an “update.” An exemplary display of an “update” change details report is provided in
In step 1740, the system 100 records the “end date” for the prior entry in that data field as one minute prior to the effective date for the new data field entry. In step 1745, an inquiry is conducted to determine if there is another data change to the same field(s) in the database 105 subsequent to the effective date of the current data change. If there is a subsequent change, the “YES” branch is followed to step 1750, where the historical database 105 propagates and saves the newly entered data field information on an occurrence-by-occurrence basis until one minute before the effective date of the next different information recorded in that data field in the historical database 105. The process continues from step 1750 to the END step. Returning to step 1745, if there is not a subsequent change, the “NO” branch is followed to step 1755, where the historical database 105 propagates and saves the new data field information on an occurrence-by-occurrence basis until the present date. The process continues from step 1755 to the END step.
The system 100 accepts a change to one or more data fields that is the same value as the particular data field on the originally recorded effective date in step 1815. The system 100 begins propagating the change forward on an occurrence-by-occurrence basis in step 1820. In step 1825, the data entry on the originally recorded effective date for that data field is reached. The system 100 determines that the entry on the originally recorded effective date in the data field is the same as the entry being propagated in step 1830. The system 100 overwrites the entry on the originally recorded effective date with the entry being propagated in step 1835. In step 1837, the system 100 overwrites the originally recorded effective date with the effective date of the entry being propagated. In step 1840, the system 100 recognizes the change as a “move” because the data field had a different and earlier effective date and the data in the data field was the same for both the original entry and the entry being propagated. In step 1845, the system 100 generates a change details report displaying the fields that were changed. In one exemplary embodiment, the change details report includes, the prior field entry, the effective date of the prior field entry, the current field entry, the effective date of the current field entry, and the type of change, which is listed as a “move.” An exemplary display of a “move” change details report is provided in
In step 1855, the system 100 records the “end date” for the prior entry in that data field as one minute prior to the effective date for the entry being propagated. In step 1860, an inquiry is conducted to determine if there is another data change to the same data field(s) in the database 105 subsequent to the effective date of the entry being propagated. If there is a subsequent change, the “YES” branch is followed to step 1865, where the historical database 105 propagates and saves the new data field information for the entry being propagated on an occurrence-by-occurrence basis until one minute before the effective date of the next different information recorded in that data field in the historical database 105. The process continues from step 1865 to the END step. Returning to step 1860, if there is not a subsequent change, the “NO” branch is followed to step 1870, where the historical database 105 propagates and saves the new data field information for the entry being propagated on an occurrence-by-occurrence basis until the present date. The process continues from step 1870 to the END step.
While not shown and described in the form of a process flowchart, a user can also modify the effective date to a date subsequent to the date currently in the database 105. To move the effective date forward without modifying the data in the data field, the user would first complete a correction by inserting the immediately previous data record for that field into the field for the original effective date for the data record being modified. The user would then select save and the database will propagate the information forward in substantially the same manner as described hereinabove. Next, the user would complete an update by going to the new, subsequent, effective date and changing the data in the data field to the data for the record being modified. The user would then select save and the database 105 will propagate the information forward in substantially the same manner as described hereinabove.
In conclusion, the present invention supports a computer-implemented method for generating the documentation and approvals to form or acquire an entity or initiate a transaction, store entity and transaction data for general corporate, regulatory and financial reporting and monitor changes to the data for the entities and transactions over time at the data field level. It will be appreciated that the present invention fulfills the needs of the prior art described herein and meets the above-stated objectives. While there have been shown and described several exemplary embodiments of the present invention, it will be evident to those of ordinary skill in the art that various modifications and changes may be made thereto without departing from the spirit and the scope of the present invention as set forth herein.
This non-provisional patent application claims priority under 35 U.S.C. §119 to U.S. Provisional Patent Application No. 60/855,728, titled Method and System for Generating Approvals and Documentation for Entities and Transactions and for Generating Current and Historical Reporting Related Thereto, filed Oct. 28, 2006. This provisional application is hereby fully incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60855728 | Oct 2006 | US |
