Abstract:
A system which integrates a whole deal process including creation of a deal, conflicts approval, expense tracking, and deal closure in a financial institution is disclosed. The invention consists of three main components. The first one is a flexible user interface with high navigation ability. The second one is that a user can access secured multi-layer information flow in real time. The third one is that the financial institution can get the whole deal lifecycle.

Description:
FIELD OF THE INVENTION 
     The present invention relates to a system which integrates a whole deal process including creation of a deal, conflicts approval, expense tracking, and deal closure in a financial institution. 
     BACKGROUND OF THE INVENTION 
     A financial institution (e.g., a large bank) offers various financial services to clients. These services include: merger and acquisition (i.e., doing financial restructuring such as helping clients buy companies, merge with companies, and sell or spin off divisions into new companies), equity capital market (i.e., issuing equity such as Initial Public Offering (IPOs), Follow-ons, and private placements into the capital markets), debt capital market (i.e., issuing varying types of debt such as bonds, loans, and leveraged finance into the capital market, and global credit risk management (i.e., managing the credit risk of a bank with respect to outstanding credit (loans leveraged) to its clients). These services are called deals. 
     During the whole lifecycle of a deal, it will go through the following steps: deal setup, conflicts approval, analyzing, making a deal including pitching, winning, executing and closing mandates, expense tracking, and deal closure. 
     Current technology doesn&#39;t offer an unified and integrated way for a whole deal lifecycle. For example, in an acquisition deal, acquisition and raising capital are separate processes instead of one, which is inefficient. In addition, different information for a deal is controlled by different deal-related departments, which results in multiple and repetitive work during a deal process. Furthermore, no mechanism exists, which integrates all deals and processes into one platform on which users can access different classes of secured financial information in real-time by means of an multi-layer user interface with high navigation ability. Hence, there is a need to establish such a system for integrating the whole lifecycle of deals. 
     SUMMARY OF THE INVENTION 
     This invention is directed to a system in which a deal team member in a financial institution can access different classes of secured financial information in real-time by means of an multi-layer user interface with high navigation ability, and the financial institution can provide categorized reporting information. 
     The invention consists of three main components. The first one is a flexible user interface with high navigation ability. The user has an ability to create a project record for a deal. This process will begin with definition of the deal. A deal workspace is automatically created when a new deal record is created by the user. The deal workspace refers to a folder structure that is created to securely store and share documents related to the deal. The client can view, manage, and edit deal properties. The user can also delete a deal, Credit Files and Compliance (CFAC), administration, or sector security folder. 
     The second one is that the user can access secured multi-layer information flow in real time, e.g., loan, bond, or leveraged finance deal. In the early stages of the deal, the user sets up the deal workspace for storage of deal related documents. As the deal becomes a formal pitch, e.g., on Request for Proposal (RFP), receipt of Material Non-public Information (MNPI) or verbal mandate, the user contacts Conflicts Office to obtain approval. The user can view historic versions of a file and associated attribute information. 
     The third one is that the financial institution can get the whole deal lifecycle so that the financial institution knows who has been involved in a deal, where the deal is, how much the incurred and potential fees are from the deal, and provides reports with classified information. The deal related expenses are centrally tracked using the project name and subsequently reimbursed by the client related to the project. The expense recovery and reporting system (FAMIS) is used to set up client related projects. 
     The above and other objects and features of the present invention will be apparent in the following detailed description of the present invention when read in conjunction with the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order to facilitate a fuller understanding of the present invention, reference is now made to the accompanying drawings. These drawings should not be construed as limiting the present disclosure, but are intended to be exemplary only. 
         FIGS. 1A-C  are block diagrams illustrating a Dealworks system in accordance with embodiments of the present invention. 
         FIG. 2  is a flowchart showing a process of creating a deal workspace for a new deal via a computer interface by a Dealworks user in accordance with one embodiment of the present invention. 
         FIG. 3  is a diagram illustrating how to use a Main Deal tab to create a new deal in accordance with one embodiment of the present invention. 
         FIG. 4  is a diagram illustrating how to use a Main Deal tab to define deal folders in accordance with one embodiment of the present invention. 
         FIG. 5  is a diagram illustrating how to search a client name in accordance with one embodiment of the present invention. 
         FIG. 6  is a diagram illustrating how to add users to the Dealworks system and set their access rights in an Access Control List (ACL) tab in accordance with one embodiment of the present invention. 
         FIG. 7  is a flowchart showing how a user of the Dealworks system submits a conflict approval request in accordance with one embodiment of the present invention. 
         FIG. 8  is a diagram illustrating a Conflicts tab for Financing and Advisory sub product in accordance with one embodiment of the present invention. 
         FIG. 9  is a flowchart showing how to set up an expense tracking pipeline in accordance with one embodiment of the present invention. 
         FIGS. 10A-B  are diagrams illustrating how to set up an expense tracking pipeline for merger and acquisition (M&amp;A) as an exemplary embodiment in accordance with one embodiment of the present invention. 
         FIGS. 11A-I  are diagrams illustrating some exemplary navigation functions of the Dealworks system in accordance with one embodiment of the present invention. 
         FIG. 12  is a flowchart showing a process of closing a deal in accordance with one embodiment of the present invention. 
         FIG. 13  is a diagram illustrating a list of deal-related files in a deal folder for closure in accordance with one embodiment of the present invention. 
         FIG. 14  is a diagram illustrating a deal closure confirmation screen in accordance with one embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1A  is a block diagram illustrating a Dealworks system  100  in accordance with one embodiment of the present invention. The Dealworks system is an engine which executes and integrates the whole lifecycle of a deal via computer and interacting with a deal team  101  and other functional entities such as Conflicts Office  102  and business managers  103 . The deal team is a functional group which comprises personnel of a financial institution and carries out the deal, including setting up a deal, analyzing, pitching, winning, executing, and closing mandates. The Dealworks system comprises a deal workspace  104 , a conflicts approval module  105 , an expense tracking pipeline  106 , and a deal closure module  107 . The deal workspace is a folder structure that is created to securely store and share documents related to a deal. The conflicts approval module is used to initiate a conflicts approval process as the deal becomes a formal pitch, and interact with the Conflicts Office to carry out an approval requirement. The expense tracking pipeline is a functional module of the Dealworks system, which is used to track expenses occurring during a deal lifecycle, and is set up after submitting the conflicts form. The financial institution receives reports with classified information via this module such as who has been involved in a deal, and how much the incurred and potential fees are from the deal. The deal closure module is used to close a deal which achieved mandate status. The deal closure is a both legal and financial process, which makes documentation for that deal as well as potentially makes the information reusuable to appropriate clients. 
       FIG. 1B  is a block diagram illustrating a Dealworks system  100  in accordance with another embodiment of the present invention. In this embodiment, the Dealworks system  100  is configured so that an interface between a client  108  and the Dealworks system is added. The client can access that particular deal&#39;s documents in the deal workspace to directly involve and control the whole deal process. In addition, a company which is involved in a deal (e.g., in a merger and acquisition deal, the company which is purchased)  109  can also access the Dealworks system. 
     Although the deal team, the client, and the deal-related company are all allowed to access the workspace via the Dealworks system as a platform during the deal, each one can only access its corresponding part of the workspace, which can be illustrated by a concept “security bubble” as shown in  FIG. 1C . If the area enclosed by these circles is taken as the whole workspace of a deal, the deal team  101  can only access the part A+B+C+E of the workspace, the client  108  can only access the part A+B+D+F of the workspace, and the deal-involved company A  109  can only access the part A+C+D+G of the workspace. The domains in the workspace which all the deal team, the client, and the deal-involved company A are clearly defined and secured. For some deal-related documents of the workspace (e.g., part E), only the deal team can access (e.g., deal-related expense revenue from the client). Likewise, for other documents of the workspace, only the client or the deal-involved company A can access (e.g., part F and part G respectively). For some documents of the workspace (e.g., part A), the deal team, the client, and the deal-involved company A can all access (e.g., the final legal documents of the deal). For some documents of the workspace (e.g., B), only the deal team and the client can access (e.g., deal analysis documents). 
     As the first step of a deal lifecycle, a user of a Dealworks system (hereafter called “DW user”) needs to create a project record for the deal with the Dealworks system. This process will begin with definition of the deal within the Dealworks system. A deal workspace is automatically created when a new Deal Record is created by the DW user. The Deal Workspace refers to a folder structure that is created in the DW system to securely store and share documents related to the deal.  FIG. 2  is a flowchart showing a process of creating a deal workspace for a new deal via a computer interface by a DW user in accordance with one embodiment of the present invention.  FIG. 3  is a diagram illustrating how to use a Main Deal tab to create a new deal in accordance with one embodiment of the present invention.  FIG. 4  is a diagram illustrating how to use a Main Deal tab to define deal folders in accordance with one embodiment of the present invention.  FIG. 5  is a diagram illustrating how to search a client name in accordance with one embodiment of the present invention.  FIG. 6  is a diagram illustrating how to add DW users and set their access rights in an Access Control List (ACL) tab in accordance with one embodiment of the present invention. The process of  FIG. 2  is described in connection with  FIGS. 3, 4, 5, and 6  in order to set forth the process in a concrete fashion easily understood by the person of ordinary skills. However, this articulation of the process is exemplary only, and the process could be implemented differently from those of  FIGS. 3, 4, 5, and 6 . 
     As set forth in  FIG. 2 , a DW user clicks on the “Create New Deal” button from a DW workspace  200 . The DW system opens a Main Deal tab, an empty form for entering deal information  201  (also  300  as shown in  FIGS. 3 and 400  in  FIG. 4 ). The DW user appears in the “Deal Team Assignments” display window  301  as shown in  FIG. 3 . The default folders for the DW user  401  are listed in the Deal Folder Definition Tab  400  as shown in  FIG. 4 . The default product for the DW user is pre-selected for each user, which could be Merger and Acquisitions (M&amp;A), Equity Capital Markets (ECM), Debt Capital Markets (DCM), or Global Credit Risk Management (GCRM)  302  as shown in  FIG. 3 . The DW user clicks on the Client Name search button to select a client  202  (also  303  as shown in  FIG. 3 ). The DW system opens the Client Center Search Tab  203  (also as shown in  FIG. 5 ). The DW user enters the first “n” letters of the client name and clicks “Lookup”  204  (also as shown in  FIGS. 5A, 5B ). The DW system displays a list of matching records  205  (also as shown in  FIG. 5C ). If the client does not exist in the Client Central  206 ( a ), the DW user closes the Client Center Search Tab  207  and the DW system returns to the Main Deal Tab  208 . The DW user enters new client name, industry and region information  209 . The DW system then sends a new client alert to an appropriate business manager  210  (also  303 - 309  as shown in  FIG. 3 ). If the client exists in Client Central  206 ( b ), the DW user selects its client name from the list  211 . The DW system closes the search tab and returns to the Main Deal Tab  212 . The DW system automatically populates the client name, CAS ID, issuer name, industry, and region information  213  (also  303 - 309  as shown in  FIG. 3 ). The DW user then enters deal specific information such as project name, product (i.e., M&amp;A, ECM, DCM, or GRCM), sub-product (i.e., for M&amp;A. Advisory, Acquisitions, Mergers, Leveraged Buy Out (LBOs), Fairness, Sellside, Defense, or Equity Private Placements (EPP); for ECM, Initial Public Offering (IPO), Rights Issue, Equity Linked, ABBs, or Follow On; for DCA Bonds, Loans. Loans/Bonds, Multilateral Trade Negotiation (MTN) Prog, MTN Trades, Bond Participation Only, Structured Finance, or Transaction and Execution Group (TEG Other); for GRCM, Bi Lats (i.e., non-syndicated loans), or TSS-Cash (i.e., treasure services)), description, and keywords  214  (also  302 ,  310 ,  311 ,  312 , and  313  as shown in  FIG. 3 ). 
     To add deal users, the DW user opens the Access Control List tab  217  (also  600  as shown in  FIG. 6 ). The default team assignments are displayed  601  as shown in  FIG. 6 . The DW user selects a user name and clicks the “Add” button  218  (also  602  as shown in  FIG. 6 ). The DW system populates the user display window with name of selected user  219  (also  603  as shown in  FIG. 6 ). For adding multiple users, this step is repeated as necessary  220 . For each user, the DW user selects an access right (i.e., full, write, version, or read)  221  (also  604  as shown in  FIG. 6 ). The DW system populates the display with the selected access level  222 . 
     To add or remove deal folders, the DW system goes to the Deal Folder Definition tab  224  (as shown in  FIG. 4 ). To add a deal folder, the DW user types in the name of a folder and clicks on the “Add Folder” button  224  (also  402  and  403  as shown in  FIG. 4 ). To remove a deal folder, the DW user highlight a folder name in the folder display list and clicks on the “Remove Folder” button  226  (also  404  as shown in  FIG. 4 ). The DW user then clicks the “Save” button  227  (also  405  as shown in  FIG. 4 ). 
     Once finishing these steps, the DW system returns to the Main Deal tab  228 . If the DW user decides to create a deal  229 ( a ), he clicks “Create Deal” button  230 . The DW system sends notifications, clears the Main Deal tab, creates a deal workspace, and opens a conflicts template  231 . If the DW user decides to reset the settings  229 ( b ), he clicks “Reset” button  232 . The DW system opens a pop-up window to confirm  233 . If the user decides to proceed  234 ( a ), the DW system closes the pop-up and resets the Main Deal tab  235 . If the user decides not to proceed  234 ( b ), the DW system closes the pop-up 236. 
     As the deal becomes a formal pitch (i.e., winning the sale of a product to a client), the DW user contacts the Conflicts Office to obtain approval.  FIG. 7  is a flowchart showing how a DW user submits a conflicts approval request in accordance with one embodiment of the present invention.  FIG. 8  is a diagram illustrating a Conflicts tab for Financing and Advisory sub product as an exemplary embodiment in accordance with one embodiment of the present invention. The process of  FIG. 7  is described in connection with  FIG. 8  in order to set forth the process in a concrete fashion easily understood by the person of ordinary skills. However, this articulation of the process is exemplary only, and the process could be implemented differently from those of  FIG. 8 . 
     As set forth in  FIG. 7 , the DW system opens the Conflicts tab with an appropriate template form selected for the sub product entered during the folder setup  700  (also  800  as shown in  FIG. 8 ). The DW system pre-populates the fields (i.e., primary deal contact, primary deal contact telephone number, project name, transaction type, client full name, client executive, exchange, description of business, industry, access control list) with information gathered at the folder setup  701 . The DW user enters conflicts information into the Conflicts tab  702 . If the user decides to proceed  703 ( a ), he selects “Submit” button  704  (also  801  as shown in  FIG. 8 ). The DW system saves the conflicts information to the deal record  705 . The DW system sends an alert to a conflicts mailbox and forwards the conflicts approval record for approval  706 . The DW system updates the deal stage status bar on the deal workspace  707 . The DW system opens the Expense Tracking Pipeline tab to set up the project for expense tracking-related purposes  708 . If the DW user doesn&#39;t want to submit the form  703 ( b ), he may selects “Save as Draft”  709  (also  802  as shown in  FIG. 8 ). The DW system saves the conflicts information to the deal record  710 . The DW system updates the deal stage status bar on the deal workspace  711  and returns to the Main Deal tab  712 . If the DW user doesn&#39;t want to submit the form  703 ( c ), he may also select “Cancel” button  713  (also  803  as shown in  FIG. 8 ). The DW system opens a pop-up asking “All information will be lost. Continue?”  714 . If the DW user selects “continue”  715 ( a ), the DW system resets the Conflicts Template Submission Form  716  and returns to the Main Deal tab  712 . Otherwise  715 ( b ), the DW system closes the form  717 . 
     The Conflicts tab for Financing and advisory sub product is used for conflicts approval if the sub-product belongs to one of the following sub-products: Advisory, Buyside-Acquisitions, Buyside-Mergers. Buyside-LBOs, Buyside-Fairness Opinion, Seilside, Defense, EPP, DCM Bonds, DCM Loans, Leveraged Finance, and Structured Finance. The DW system selects the Conflicts Equities Template Submission tab for the sub-products: IPO, Right Issue, Equity Linked, ABB. Follow On, and Block Trade. The DW system skips the Conflicts Submission phase if the following sub-products are selected at folder setup: MTN Program, MTN Trade, Bi Lats, TEG Other, and Bond Participation. As an exemplary embodiment, the fields of the Conflicts tab for Financing and advisory sub product are listed below. 
     1. Primary Deal Contact  804   
     2. Primary Deal Contact telephone number  805   
     3. Project Manager (if different)  806   
     4. Project Manager telephone number  807   
     5. Project Name  808   
     6. Status of the Deal  809   
     6a. Status of the Deal—Other: 
     7. Competing Banks  810   
     8. Transaction Type  811   
     8a. Transaction Type—Other Advisory: 
     9. Summary of the Potential Assignment  812   
     10. Transaction Size  813   
     11. Related Business Opportunities  814   
     11a. Related Business Opportunities—Other: 
     Client: 
     12. Full Name 
     13. Role 
     14. Client Exec 
     15. Description of Business 
     16. Public or Private 
     17. Ticker Symbol 
     18. Exchange 
     19. Industry 
     20. Revenues 
     21. Market Cap 
     22. Firm Value 
     23. EBITDA 
     24. Parent or Major Share Holders 
     25. JPM Relationship 
     26. Approving MD(s) if new client 
     27. Subsidiary/Division/Assets involved if subject of the transaction is not the entire company 
     28. Any other interested Parties Names, Roles 
     Conflicts and Issues 
     29. Other important background 
     30. Possibility of turning hostile 
     31. If deal is non-acquisition related credit facility/financing, indicate: purpose, agent bank, amount of JPM commitment. 
     32. If deal is credit facility amendment, indicate: agent bank, covenants changes, increase/decrease in facility amount, maturity extension, whether “troubled” credit. 
     33. Is the deal team aware of any potential conflicts or any other issues? 
     34. Describe: 
     35. Which senior managers have confirmed that there are globally no conflicts or other issues—including any “best horse’/foregone opportunities issues, relationship risks with other clients, or other reputation risks to the firm? 
     36. Confirming IB Coverage Head 
     37. Confirming M&amp;A Sector Head 
     38. Other confirming Senior Managers 
     39. Deal Team Members 
     40. Has anyone on the team worked with the target? 
     41. Are there any board seats held by JPM Chase employees? 
     42. Has JPM signed a confidentiality agreement? 
     43. Is a standstill agreement or any exclusivity language proposed? 
     44. Has JPM received material, non-public information? 
     45. Other information for Conflicts Office 
     46. If deal team has fee level(s) to propose to Engagements—Press Here 
     47. Retainer Fee 
     48. Upfront Fee 
     49. Success Fee 
     50. Opinion Letter 
     After submitting the Conflicts tab, an expense tracking pipeline for the deal is set up so that the deal related expenses are centrally tracked using the project name and subsequently reimbursed by the client related to the project.  FIG. 9  is a flowchart showing how to set up the expense tracking pipeline in accordance with one embodiment of the present invention.  FIGS. 10A and 10B  are diagrams illustrating how to set up the expense tracking pipeline for merger and acquisition (M&amp;A) as an exemplary embodiment in accordance with one embodiment of the present invention. The process of  FIG. 9  is described in connection with  FIGS. 10A-B  in order to set forth the process in a concrete fashion easily understood by the person of ordinary skills. However, this articulation of the process is exemplary only, and the process could be implemented differently from those of  FIGS. 10A-B . 
     As set forth in  FIG. 9 , the DW system opens the Expense Setup and Pipeline tab with an appropriate request form selected for the DW user  900  (also  1000  as shown in  FIGS. 10A-B ). If the sub product selected does not require expense setup, the DW system bypasses this stage and returns to the deal workspace. The DW system pre-populates the fields with the information previously entered at the folder setup and the conflicts stages  901  (e.g., client address, client executive, client CAS ID, client full name, access control list, product area, project/issue description, project leader, project name, project status, and type of deal  1001 - 1011  as shown in  FIGS. 10A-B ). The DW user enters the mandatory fields and updates the fields if necessary (e.g., JV Related, Project Name, Access Control List, Project Status, and Industry Group  1012 - 1015 ,  1001 ,  1007 ,  1009 , and  1010  as shown in  FIGS. 10A-B ). The DW user also enters the pipeline information  902  (e.g., estimated size of deal, estimated gross fee, estimated completion date, and estimated percentage of success  1016 - 1019  as shown in  FIG. 10B ). If the DW user decides to proceed  903 ( a ), he selects “Submit” button  904  (also  1020  as shown in  FIG. 10B ). The DW system saves the information to the deal record  905 . The DW system sends alerts to the ECAG/BEST teams and London Control Room  906 . The DW system forwards the information to the ECAG/BEST approval queue  907 . The DW system updates the status bar on the deal workspace  908 . The DW system returns to the deal workspace  909 . If the DW user does not want to proceed  903 ( b ), he may select “Save” button  910 . The DW system saves the information to the deal record  911 . The DW system updates the status bar on the deal workspace  912 . The DW system returns to the deal workspace  913 . If the DW user does not want to proceed  903 ( c ), he may also select “Cancel” button  914 . The DW system opens a pop-up asking “All information will be lost. Continue. Yes/No?”  915 . If the DW user clicks “Yes”  916 ( a ), the DW system closes the form, resets the form  917 , and returns to the deal workspace  913 . If the DW user clicks “No”  916 ( b ), the DW system closes the form. 
     The DW system allows the DW user to navigate through different screens when the Client tab is selected in the Navigation tab.  FIGS. 11A-1  are diagrams illustrating some exemplary navigation functions of the DW system in accordance with one embodiment of the present invention. Once the DW user is logged in, the first screen displays the following items: a client dashboard which displays clients that the DW user is working on  1101  as shown in  FIG. 11A . An A-Z selection menu wherein a user can choose to list the clients according to client name  1102 . This screen appears as a result of selecting the Client tab in the Navigation Bar  1103 . Suppose the user wants to find a client that is not present in the client dashboard. The user clicks on alphabet M (assuming the client name starts with M) in the A-Z selection menu. This lists all the client names starting with M as shown in  FIG. 11B . The DW user can browse through the client name lists by scrolling up or down using the scroll bar. The DW user clicks on the client name (e.g., Malka Limited)  1104 . The DW system adds the client Malka Limited to the client dashboard  1105  as shown in  FIG. 11C . This is only a temporary addition and this client will not be present in the client dashboard when the user logs on the next session. The selection of Malka Limited from the A-Z selection menu opens up the client marketing folder for the client. It expands the folders to 2 levels within the folder structure. The DW user can see two additional buttons in the navigation tab at the bottom called Show Client Info  1106  and Show Deal Info  1107 . Both these buttons work as toggle buttons. The DW user clicks on Show Deal Info Button. This brings up a window which displays different deals under the client by project names and products  1108  as shown in  FIG. 11D . The user can use the scroll bar to see the different deals under the client. The DW user clicks on Show Client Info to display the client information. The DW system now displays a client information window  1109 . The Show Deal Info button has changed to Hide Deal Info  1110  and the DW user can click this to hide the Deal Info part of the screen. The DW user can click on Hide Client Info tab  1111  to hide the client information window. To see the documents in the client marketing folder, the DW user clicks on one of the folders in the client marketing folder (e.g., DCM→Presentations)  1112  as shown in  FIG. 11E . To see the deal documents, the DW user clicks on one of the deals (e.g., Project Chimpanzee) inside the client deal information window  1113  as shown in  FIG. 11D . The menu bar with File, Edit and other options is also displayed  1114  as shown in  FIG. 11F . The DW user can also see status of the deal folders  1115 . If the DW user clicks on Show Deal Properties button  1116 , the deal information is displayed at the bottom of the screen on a separate pane  1117  as shown in  FIG. 11G . This includes the information on client name, project name, and status and deal type. There is also an option for editing the deal team properties by clicking Modify Deal Properties button  1118 . The deal folder is chequered because it is only a temporary addition. This means that this deal folder will disappear from the dashboard when the user logs off and logs in next time. The DW user selects the deal and clicks Tools→Add to Deal Dashboard Permanently  1119 . This will add the deal Project Chimpanzee to the deal dashboard permanently and remove the chequered appearance  1120  as shown in  FIG. 11H . If the DW user decides to remove the deal Apple computer—Geo from the deal dashboard, the DW user clicks on Apple Computer in the deal dashboard  1121 . The DW user clicks on Tools→Delete from Dashboard Permanently  1122 . The DW system displays the modified dashboard after the deletion. The DW user can selects multiple folders to add to the dashboard by ticking checkboxes  1123  as shown in  FIG. 11I . The DW user clicks on Acid to Deal Dashboard button  1124 . The DW system adds the deals to the deal dashboard and displays a message indicating that the deal folders have been added to the deal dashboard temporarily. The DW user can also click Add to Deal Dashboard Permanently  1125 . The DW system adds the folders on to the deal dashboard and removes the check marks in the checkbox displaying a message indicating that the deal folders have been added permanently to the dashboard. 
     After successfully executing a deal, it will be closed. Each deal has its own closure process with respect to the actions that have to be taken, which is partly legal and partly financial. The deal closure has to do with making documentation for that deal and documents of record, as well as potentially making the information reusuable to the appropriate audiences. The following is an exemplary embodiment illustrating how to close a merger and acquisition deal.  FIG. 12  is a flowchart showing a process of closing the deal in accordance with one embodiment of the present invention.  FIG. 13  is a diagram illustrating a list of deal-related files in the deal folder for closure in accordance with one embodiment of the present invention.  FIG. 14  is a diagram illustrating a deal closure confirmation screen in accordance with one embodiment of the present invention. The process of  FIG. 12  is described in connection with  FIGS. 13-14  in order to set forth the process in a concrete fashion easily understood by the person of ordinary skills. However, this articulation of the process is exemplary only, and the process could be implemented differently from those of  FIGS. 13-14 . 
     As set forth in  FIG. 12 , when a DW user initiates a closure process  1200 , he is warned about implications of the deal closure before the DW system commences deal closure for the deal. The user is presented with a message: “You are about to commence the deal closure process for a deal that achieved mandate status. This process is irreversible and at the end of the process files will be made read only. Seven days following closure only the current versions of files will be available. The project leader for this deal will need to provide final approval at the end of the closure process. The project leader for this deal is currently set as [project leader name], please contact your Pipeline/business manager if this is incorrect before continuing. Do you wish to continue?” Options are “Continue” and “Cancel”. If the user selects “Cancel”, then the DW system ends the deal closure process. 
     If the user selects “Continue”, then the user is asked to select which documents are sensitive. The user is presented with a list of deal-related files in the deal folder with only the latest versions of the files being available as shown in  FIG. 13 . The user is presented with a message: “All data stored within Dealworks is already restricted to ‘inside’ business users. For further security please select those files which you do not wish to be visible to others outside the immediate deal team. For further guidance on what may constitute a sensitive (MMPI) file please discuss with your local compliance contact”. The user is able to select those files which are sensitive via the checkbox&#39;s in the left most column of the list. There is no ‘select all’ option available. The user is also presented with the options “Cancel”, “Continue”, and “Save”. If the user selects “Cancel”, then the user is asked if they would like to save before canceling; if the user has requested to save, then he is informed “you may return to the deal closure process the next time you revisit this deal folder”. If the user selects “Save”, then the DW system sets the deal closure status to “In Progress” and save entries made in deal closure screens for the user to return to in future sessions. 
     If the user selects “Continue”, then the DW system retains entries made in the deal closure screens for the user. The user is presented with a message: “Please complete the following checklist for the required documentation for this folder. For all documents please specify if the file is in Dealworks, in a cardboard archive box, or if the document is not applicable.” After selecting, the user is presented with options “Cancel”, “Save”, “Back”, and “Continue”. If the user selects “Cancel”, then the user is asked if they would like to save before canceling. If the user selects “Save”, then the DW system sets the status bar to “In Progress” and saves entries made in the deal closure screens for the user to return to in future sessions. If the user selects “Back”, then the DW system retains entries made in the deal closure screens for the user and progress to the step of selecting sensitive documents. If the user selects “continue”, then the DW system retains entries made in deal closure screens for the user and checks are carried out to ensure that each row of the checklist has an option selected. If not, then the user is presented with an error message “Please complete all the rows in the checklist before proceeding further”. Checks are also carried out to ensure that a valid cardboard box ID has been entered. 
     The DW user then updates the project description. The DW system presents the user with  3  sections. The first is an editable text box “Description” which is populated with contents of the fields “Summary of potential assignment” as captured at the Conflicts stage. The user is also displayed a message: “Please check/update the description for this project which will help identify it to others”. The second is a pick list calendar and the message “Please select the date of deal closure”. The third is a drop down box showing sub products for that particular product area. The drop down box will be set to the current sub product that was selected as part of the deal folder creation. The user is also presented with a message “This deal folder is currently associated with the following type of product. Please update this if this is incorrect”. Options are “Cancel”, “Continue”, “Save”, and “Back”. If the user selects “Cancel”, then the user is asked if they would like to save before canceling and if the user has requested a save, now or prior to this stage, then they are informed “You may return to the deal closure process the next time you revisit this deal folder”, then the use case ends. If the user selects “Save”, then the DW system changes the deal closure status to “In Progress”, and saves the entries made in the deal closure screens for the user to return to in future sessions. If the user selects “Back”, then the DW system retains the entries made in the deal closure screens for this session for the user and progresses to the step of the deal file checklist. If the user selects “Continue”, then checks are carried out to ensure that all three sections have been completed. 
     If the DW user is a member of the deal team but not a project leader, then the user is presented with a message “Please note that the deal file checklist and details of the files which you have marked as being sensitive/non-sensitive will now be sent to the project leader for review. If the project leader approves the closure of this deal folder then the project folder will be renamed with the addition of the deal closure date and the sub product type”. Options are “Cancel”, “Save”, and “Continue”. If the user selects “Cancel” and if the user has previously saved progress during the deal closure process, then the user is informed “You may return to the deal closure process the next time you revisit this deal folder”. If the user selects “Cancel” and the user has not previously saved progress during the deal closure progress, then the user is asked if they would like to save their changes. If the user selects “Save”, then the DW system sets the flag Final Deal Documentation to “In Progress” and saves entries made in deal closure screens for the user to return to in future sessions. If the user selects “Continue”, then the following notification is sent to the project leader: “The deal folder [folder name] has been marked for closure by [deal team members&#39; name]. Please review the deal folder and the associated deal file checklist by clicking on the link below [URL of deal folder]. After reviewing the deal folder please approve or rejects this closure request in Dealworks. If you have received this message in error or are not the project leader for this deal folder, then please contact the Pipeline/business manager”. 
     The project leader clicks on the URL in the notification which takes him/her to the deal folder and the deal closure screens  1201 . The project leader is able to make modifications to which files are to be marked as sensitive and which files are included as part of the deal file checklist. The project leader then has the ability to approve or reject the closure request  1202 . If the project leader clicks on reject, then the following actions occur: (1) The project leader is required to enter a brief explanation of why they are rejecting the deal closure request. (2) A notification is sent to the deal closer  1203  and to the pipeline along with the comments entered by the project leader; the wording of the notification will be “The deal closure process for [project name] has been rejected by [project leader name] for the following reasons: [comments from project leader]. (3) The data entered during the deal closure process is retained. (4) The deal closure status is updated to “Reject/In Progress”, with an associated yellow color on the deal status bar. (5) The date/time of the rejection is stored in the closure screen so that it is visible to Pipeline/business managers and to the deal team. 
     If the project leader decides to approve the request, he is prompted that the documents are checked out and locks that need to be broken as shown in  FIG. 14 . A notification is sent to the deal team, ECAG (i.e., a group that uses FAMIS to support the internal business in expense capture and reporting) and Pipeline/business manager “The deal folder [old deal folder name] has been closed by the project leader [project leader name] and has been given the new name of [new deal folder name]. After 7 days only the latest versions of files will be retained. If you have any issues or concerns, please contact the project leader.” The deal closure status is updated to “Closed”. The deal status bar is stored in the closure screen so that it is visible to Pipeline/business managers and to the deal team. The color of folder as it appears in Dealworks is changed to show the new closed status. Copy of the deal file checklist is sent to the London control room. After seven days only the latest versions of files are retained. 
     Although an illustrative embodiment of the present invention, and various modification thereof have been described in detail herein with reference to the accompanying figures, it is to be understood that the invention is not limited to this precise embodiment and the described modifications, and that various changes and further modifications may be effected therein by one skilled in the art without departing from the scope or spirit of the invention as defined in the claims.