Method and apparatus for a mortgage loan management system6985886Abstract The automated system of the present invention uses the Federal, State, local and professional regulations and requirements and implementing instructions to generate a plurality of tasks which can be used to control and drive the process of handling a mortgage loan application to completion and settlement in accordance with these regulations. Loan requestors may specify that the system will generate the plurality of required tasks, including tasks required by applicable federal and/or state law, provide the plurality of required tasks to the requester for his execution, and monitor the completion of all required tasks so as to provide a completion certificate to the requestor. Alternatively, loan requestors may specify that the automated system will generate the plurality of required tasks, including tasks required by applicable federal and/or state law, will manage and control the execution of the required tasks, and monitor the completion of all required tasks so as to provide a completion certificate to the requestor. Claims We claim: Description COPYRIGHT NOTICE
Making either selection will notify the System of the Borrower's intent to proceed with the mortgage loan origination process and will initiate the rules evaluation process, coincident with underwriting of the loan, as described in the next paragraph. The System's Compliance Engine will apply a set of rules appropriate to each mortgage loan transaction, including property and borrower profile, originator's professional guidelines, state and federal regulations and other relevant rules. The final filtered task list will then apply to each mortgage loan transaction in an attempt to assure that the mortgage loan is originated in accordance with applicable federal and state laws. This will include, making sure that qualified Loan Originators, Independent Contractors and Local Loan Processors are permitted to perform services associated with the loan origination process and that all services required to be performed in order for the Loan Originator, Independent Contractor and/or Local Loan Processor to receive compensation in connection with the mortgage loan transaction are actually performed. Based on the mortgage loan origination process requirements defined by the Compliance Engine, the Loan Originator will make decisions about each of the service providers (e.g., inspection companies, surveyors, appraisers, title companies, etc.) the Loan Originator wishes to have involved in the mortgage loan transaction. Any qualified service provider will be able to be selected by the Loan Originator and entered into the System at this point. Some nationwide service providers may, in the future, have a direct online ordering system available inside the System. Others may still require the typing in of the name and contact information. OnePipeline.com, Inc. expects that it will be most common for Borrowers to select local service providers with whom they are familiar. After the Borrower selects the service providers, the Loan Processor will confirm to the system which services have been provided by the Loan Originator. As described in more detail below, the services actually performed by the Loan Originator, Independent Contractor and/or Local Loan Processors will serve as the basis for the fees earned as fair market compensation for performing settlement services in connection with the mortgage loan origination process under the Program. After each of the above steps are completed, the System will automatically create a workflow process based on the applicable rules and appropriate tasks will be eventually assigned to each of the service providers for the mortgage loan transaction. In a preferred embodiment, the mortgage loan data and applicable tasks will be passed to a workflow generation system, either implemented as an integral part of the system of the invention, or as a service provided by a remote application service provider (ASP), which will generate an automated workflow process which can notify each service provider of his task(s) and allowing each service provider to interact in completing needed tasks. All task assignments will be distributed by the System and tracked. At this point, many people will be working on the loan simultaneously though the System. For example, the Loan Originator may be obtaining financial information from the Borrower, the Independent Contractor may be ordering an appraisal, the Local Loan Processor may be verifying Borrower information, and various service providers may be performing services and adding information to the mortgage loan file through the System. Hard copy data will be input by either OnePipeline's staff, an Independent Contractor (to the extent permitted under state law) or the Local Loan Processor, and added to the physical mortgage loan file. Work notices and status communications may be generated automatically by the System to keep the process moving and to ensure that all appropriate parties perform their assigned tasks in the proper order to meet all rules requirements applicable to the mortgage loan transaction. c. Products Available Borrowers may obtain a loan using the facilities of the lender organization, in which mode the system of the invention merely determines which tasks are required and tracks the completion of the required tasks. By obtaining a loan through the Program, Borrowers will be given access to a wide variety of first lien, fixed and variable rate, closed-end mortgage products (both purchase money and refinancings) at competitive rates and pricing, and in a timely and efficient manner. For example, as noted above, OnePipeline.com, Inc. will make available to the Borrower, loan products and interest rates that are available from its participating lenders. OnePipeline's System and Program also will make available and support secondary lien, fixed and variable rate, closed-end loan products and interest rates available from its participating lenders. In the future, OnePipeline may give Borrowers access to first and second lien, fixed and variable rate, open-end mortgage products through the Program. OnePipeline's Program and System will not make available or support mortgage loans that constitute "High Cost" or Section 32 mortgage loans, which are covered by Section 32 of Regulation Z, 12 C.F.R § 226.3. d. Funding Source In a preferred embodiment, OnePipeline.com, Inc. will not fund any mortgage loans, and no mortgage loans will be closed in OnePipeline's name. OnePipeline will be acting exclusively in the capacity as mortgage broker. All mortgage loans will be funded by, and closed in the name of a participating lender. In an alternative embodiment, OnePipeline could fund certain mortgage loans and close loans in their name in those jurisdictions where qualified to do so. e. Disclosures and Form Documents In a preferred embodiment, the System will produce applicable Borrower disclosures (on a state specific basis) required under applicable law to be provided to the Borrower in connection with the mortgage loan origination process under the Program. The Loan Originator will be required to provide the disclosures to Borrowers at the appropriate times. Moreover, the Loan Originators will be required to provide the Borrower with a disclosure that informs the Borrower that the Loan Originator will receive compensation for services actually performed by the Loan Originator in connection with the mortgage loan transaction. This disclosure also will inform the Borrower that the Loan Originator is an exclusive part-time W-2 employee of OnePipeline, and that the Borrower is free to use another mortgage broker or lender other than OnePipeline. The System also will allow a lender to elect to use a standard set of mortgage loan documents, which can be printed off of the System, in connection with a mortgage loan originated through OnePipeline's Program, or the Lender may use its own forms. The forms available off of the System will be provided to OnePipeline by a third-party document vendor. f. Mortgage Loan Fees Fees will generally include, among other permissible fees: (1) origination fee payable to the lender and passed through to the Loan Originator based on services performed; (2) underwriting fee payable to the lender and passed through to Local Loan Processor; (3) impound waiver fee payable to the lender and passed through to secondary market investor (only on loans without escrow accounts); (4) processing fee payable to the lender and passed through to Local Loan Processor; (5) document preparation fee payable to the lender and passed through to third-party vendor; (6) tax related service fee payable to the lender and passed through to third-party vendor; and (7) attorney fee payable to lender and passed through to closing attorney. OnePipeline.com, Inc. will charge a lender a membership fee to participate in OnePipeline's Program and a flat fee for each Completion Certificate issued to the lender. g. Loan Originators In a preferred embodiment, mortgage loans will be originated through the System and Program by licensed real estate sales professionals, such as real estate agents/salespersons and, in limited cases, real estate brokers. The individual real estate agents and individual real estate brokers (i.e., brokers that are not corporations or similar business entities) will enter into an employment agreement with OnePipeline, and become part-time W-2 employees of OnePipeline.com. The employment agreements will expressly require the Loan Originator to originate mortgage loans exclusively for OnePipeline.com, and prohibit the Loan Originators from receiving compensation for performing loan origination services for another mortgage lender or mortgage broker. In the future, other non-traditional originators, such as investment advisors, financial advisors, accountants and other professionals may be added to the Program as Loan Originators, in each case to the extent permitted by applicable law. Loan Originators may also have an affiliation with a mortgage lender, which defines the selection of loan products the Loan Originator may offer. i. Local Loan Processors In a preferred embodiment, wherein the loan is being processed through the system of the invention, loan processing functions which would trigger mortgage broker or similar licensing requirements under applicable state law will be delegated to properly licensed Local Loan Processors who will receive compensation intended to be fair compensation for services actually rendered by them. The Local Loan Processors will be either mortgage brokers and mortgage bankers. j. Services Performed As noted above, in a preferred embodiment, a Loan Originator will initiate the mortgage loan process with a borrower using OnePipeline's System. The services that a Loan Originator will have to perform, in all cases, in order to be fully compensated include the following: (1) obtaining the applicant's signature on disclosures, (2) obtaining the applicant's signature on the credit authorization, (3) pre-qualifying applicants, (4) assisting applicants in selecting loan products, (5) taking the loan application or obtaining loan application information, (6) reviewing the credit decision with the applicant, (7) explaining the good faith estimate and other disclosures to the applicant, (8) collecting documentation from the applicant that is needed in connection with processing and underwriting the loans, (9) updating the applicant and responding to applicant inquiries, (10) locking the interest rate, and (11) scheduling and attending the closing. If a Loan Originator does not perform all required services, the services will be performed by OnePipeline's staff, Lender's staff, an Independent Contractor (to the extent permitted under applicable state law) or by a Local Loan Processor, and the compensation received by the Loan Originator will be reduced accordingly. By way of additional background, the basic of the rules and regulations which form the heart of the present invention are now described in more detail. RESPA Compliance The following is a brief summary of RESPA and its implementing regulation, Regulation X, and their requirements. It is not intended to be comprehensive. For example, RESPA and Regulation X may not apply in all situations, and their application is not discussed below. Users should consult RESPA, Regulation X and independent legal counsel for complete explanation of RESPA, Regulation X and their requirements. The Real Estate Settlement Procedures Act ("RESPA") is a federal statute that was enacted by Congress in 1974. A federal regulation implementing RESPA ("Regulation X") also has been promulgated by the United States Department of Housing and Urban Development ("HUD"). HUD is the federal agency charged with administering and enforcing RESPA, Regulation X and their requirements. RESPA was enacted to provide Borrowers with greater and more timely information on the nature and costs of the home buying/settlement process, and to protect Borrowers from unnecessarily high settlement charges caused by certain practices believed to be abusive. Among other requirements, RESPA and Regulation X prohibit the payment or receipt of "any fee, kickback or thing of value" (i.e., a referral fee) in exchange for the referral of settlement service business. Settlement service business includes, among other services, loan origination services such as taking applications, obtaining income verifications and communicating with a borrower or lender. RESPA and Regulation X permit a lender to make reasonable payments to its agents and contractors for services actually performed in the origination, processing or funding of a loan. Based on interpretations of this provision in RESPA and Regulation X, real estate sales professionals and others may, in certain circumstances, provide loan origination services and receive fair market compensation for the services they actually perform. The preferred embodiment of the invention in OnePipeline.com's program and system are designed around this provision. Applicant's loan originators are required to perform certain settlement services in connection with loans originated by OnePipeline.com, and the compensation received by these loan originators and regional loan processors is intended to be fair market compensation for the services they actually perform. Other Federal and State Compliance The following is a brief summary of other federal and state statutes, regulations and laws that impact OnePipeline.com's system and program, and a user's performance of services under this system and program. It is not intended to be comprehensive. Users should consult the statutes, regulations and laws, and independent legal counsel, for a complete explanation of other applicable federal and state statutes, regulations and laws. Among other federal laws, the Truth in Lending Act ("TILA") and the Equal Credit Opportunity Act ("ECOA") impact OnePipeline.com's program and system, and the user's performance of services under applicant's system and program. The TILA, and its implementing regulation, Regulation Z, were enacted and promulgated to assure meaningful disclosure of credit terms so that the Borrower will be able to compare more readily the various terms available to the Borrower. Under the TILA, certain disclosures are required to be made to the Borrower prior to the consummation of a mortgage loan transaction. The ECOA, and its implementing regulation, Regulation B, were enacted and promulgated to require that lenders engaged in the extension of credit make that credit equally available to all creditworthy Borrowers without regard to race, color, religion, national origin, sex, marital status, age, receipt of public assistance or the fact that the Borrower in good faith exercised any right under the Federal Consumer Credit Protection Act. In addition to the prohibition against discrimination, the ECOA and Regulation B also contain, among others, requirements regarding the provision of appraisal reports, evaluation of applications, spousal signatures, and the provision of adverse action notices. Regarding state laws, most jurisdictions have enacted licensing statutes that may require real estate sales professionals, builders, financial institutions/lenders and mortgage brokers to obtain a license and satisfy various other financial, educational and operational requirements. Most jurisdictions also have enacted laws that impose, among others, requirements regarding the types of fees that may be charged to a Borrower in connection with a mortgage loan transaction and the persons entitled to receive such fees, as well as certain jurisdiction-specific disclosures that must be provided to the Borrower. OPERATING ENVIRONMENT The environment in which the present invention is used encompasses the use of general purpose computers as client or input machines for use by loan originators, lenders and other parties interested in the mortgage loan process. Such client or input machines may be coupled to the Internet (sometimes referred to as the "Web") through telecommunications channels which may include wireless devices and systems as well. Some of the elements of a typical Internet network configuration are shown in FIG. 1, wherein a number of client machines 105 possibly in a branch office of an Real Estate Service, or financial institution, lender, etc., are shown connected to a Gateway/hub/tunnel-server/etc. 106 which is itself connected to the internet 107 via some internet service provider (ISP) connection 108. Also shown are other possible clients 101, 103 possibly used by other loan originators, or interested parties, similarly connected to the internet 107 via an ISP connection 104, with these units communicating to possibly a home office via an ISP connection 109 to a gateway/tunnel-server 110 which is connected 111 to various enterprise application servers 112, 113, 114 which could be connected through another hub/router 115 to various local clients 116, 117, 118. Any of these servers 112, 113, 114 could function as a server of the present invention, as more fully described below. Any user situated at any of these client machines would normally have to be an authorized user of the system as described more fully below. An embodiment of the Mortgage Loan Management System of the present invention can operate on a general purpose computer unit which typically includes generally the elements shown in FIG. 2. The general purpose system 201 includes a motherboard 203 having thereon an input/output ("I/O") section 205, one or more central processing units ("CPU") 207, and a memory section 209 which may or may not have a flash memory card 211 related to it. The I/O section 205 is connected to a keyboard 226, other similar general purpose computer units 225, 215, a disk storage unit 223 and a CD-ROM drive unit 217. The CD-ROM drive unit 217 can read a CD-ROM medium 219 which typically contains programs 221 and other data. Logic circuits or other components of these programmed computers will perform series of specifically identified operations dictated by computer programs as described more fully below. DETAILED DESCRIPTION OF THE INVENTION In consideration of it's major aspects, the present invention is a system and methodology, comprising a 'container' concept, wherein the mechanics of real estate transactions beginning with loan origination and proceeding serially and in some instances in parallel through the closing, funding and disbursement and reporting of funds may be accomplished. The system also controls the timing of the process and the time allocated to the completion of each loan occurrence. When the time allocated to a process expires, the task is transferred as required by the rule base. The system, constituting the present invention, is designed to programmatically manage and document all attendant processes with compliance to applicable regulatory rule sets and requirements of participating workers. In a preferred embodiment, data exists within the executing programs as 'objects', the meaning of which as commonly understood by those skilled in the art of 'object-oriented programming'. In a preferred embodiment, the software programs comprising a portion of the present invention are also object-oriented. An integrated relational database management system is utilized to maintain persistent data and to permit and facilitate queries and reports against the persistent data. While the embodiment of the present invention embraces certain elements of a 'closed loop', or self-contained decision-making process, it's strength lies in the ability to orchestrate the workers or agents participating in the lending transaction with respect to responsibilities and financial compensation. The system of the invention encompasses a means whereby the object-oriented 'instances' or discrete occurrences of data, may be stored and retrieved from the relational database management system. In the preferred embodiment, such storage and retrieval is accompanied by programmatic conversion of said data instances to 'formats', or preferred representations upon which the required program(s) may act. Such data storage occurrences and the accompanying manipulations of said data follow preferred programmatic documentation procedures such as sequentially 'nested' descriptors. An example of a sequentially 'nested' descriptor would be, 'borrower.occupation', where the nested descriptors are separated by a '.' or 'dot', and in such manner are understood to mean, 'the identified borrower's occupation'. Such 'dot' notation will hereafter be used to describe the higher level of programmatic functionality when such explanation is necessary. Those skilled in the art will understand JAVA™ programming, Object oriented Programming, and the use of automated "Agents" to perform programmed tasks whenever activated to do so, HTTP, XML and other communications protocols as described in more detail below. An exemplary way to articulate the concept and embodiment of the present invention is the idea of a 'container', which brings together the loan originator, the subject real property attributes, and the lender, as well as means to validate transaction profitability and bundle said transactions for sale to lenders. Or in an alternative view, as a means for generating the required compliance tasks for a specific loan transaction, provide the tasks to a lender and monitor the completion of all required tasks by the lender's service providers. The present invention provides decision points wherein the loan originator makes selections from menu(s) generated by the compliance engine acting upon the original information supplied by the originator. The selection process introduces the refined data into an integrated 'workflow' process wherein rule-based engines and other workers or agents act toward a common goal of closing, funding, shipping, and collecting transaction fees on a loan. Referring to FIG. 3 there is illustrated, in schematic form, a preferred embodiment of the present invention. The business model is comprised of several functional elements, including at the highest level, embodiments which effect loan origination 301, closing, processing 303, funding 305, and shipping 307, with transfer of funds. In concert, these elements may be referred to as the 'pipeline' or system which embodies the whole of the several elements comprising the present invention. As indicated above, the present invention is a method and apparatus for automating the process of generating a set of tasks required for controlling, and regulating a mortgage loan application, underwriting the loan, and tracking the tasks through the closing process, wherein the tasks comply with all known Federal, State and local requirements for the specific loan. Elements of an alternative embodiment include loan origination, authenticating the loan originator, underwriting the loan, closing, processing, funding, and shipping, with transfer of funds, within the regulatory legal framework of funding and reporting, required for these processes. In a preferred embodiment, which is described in detail below, some or most of these functions may be performed by the lender or application service providers (ASPs) with the system of the invention providing the set of required tasks generated by a Compliance Engine and simply monitoring the completion of those tasks. Referring now to FIGS. 4A, 4B, 4C and 4D, the principal elements of a preferred embodiment of the present invention are illustrated in more functional detail. Original inputs from a lender/loan originator come into the system 401 through the 'Loan Origination Gateway' (451 in FIG. 4C) or portal, which serves as an 'entry point' or gateway to the 'pipeline' or system for loan originator data and borrower data. The loan originator data 403 is used as input data to an authentication module (453 in FIG. 4C) to verify the lender/loan originator's ID and password. Those skilled in these arts will recognize that this authentication process for the client/user may include digital signature authentication as well as other types of cryptographic verification and authentication of users. If the lender/loan originator's ID and or password do not authenticate, a message is sent back to the originator indicating that fact and the system exits. If the loan originator is found to be qualified, the loan originator data and borrower data are passed to the Compliance Engine 405 (476 in FIG. 4D) for later use. The borrower-supplied credit data is then passed to a Loan Origination & Program Matching module 407 (456 in FIG. 4C). The Loan Origination & Program Matching module returns a list of loan products for which the borrower is qualified 409. In a preferred embodiment, this function is provided by a PremierPricer™ program supplied by GHR Systems™ Inc. The PremierPricer™ Component is described in more detail at the GHR Systems web site, which can be found at www.ghrsystems.com, which description is hereby incorporated fully herein by reference. Additional detail on the interface to this PremierPricer™ Component is provided below. In an alternative embodiment, the Loan Origination & Program Matching module is one which is supplied by applicants as an integral part of the pipeline system, wherein up-to-the-minute product and pricing information is provided when the module is supplied with basic transaction parameters (i.e., LTV, loan amount, property location, property type, etc.). Continuing with reference to FIG. 4A, borrower then selects a loan from the list of loan products for which the borrower is qualified and submits a loan application 411. In a preferred embodiment, the system, recognizing the loan application selection, submits a credit report request to a credit bureau 413 and passes this data to the GHR Systems PremierPricer™ Component 413. A list of loan products for which the borrower is qualified are returned to the lender & borrower 415. If the borrower is not qualified for any loans, 419 the loan request is referred to a loan officer and the system exits 429. If the borrower is qualified, he selects one of the listed loans (his original selection may or may not be on this list) 421, 423. Referring now to FIG. 4B the lender uses this data to process the loan and inputs loan approval data to the system 431. The loan data is passed to the Compliance Engine 431 (477 in FIG. 4D). As part of this set of input data the user/lender selects optional tasks for this loan and inputs his selections along with data indicative of his fee arrangement with the borrower 432. Referring now to FIG. 4D, this data is passed by the system to the Compliance Engine 479 and the Compliance Engine uses these data (the loan data 477 and the user task selections 479) to generate a required set of tasks for this specific loan (433 in FIG. 4B). This required set of tasks is generated 478 by selecting the tasks from the task file 480 which are specifically required by the particular loan (i.e. loan type, location, value, etc.) and the contexts 481 (i.e. the combinations of circumstances where the tasks apply). The resultant set of tasks for the specific loan 483 is separately recorded 482 in a file which can be modified as new tasks may be added or deleted, and as task completions are identified 485. In a preferred embodiment, the system can supply this required task list in its entirety to the lender if the lender wishes to manage the task completions himself through his own automated systems (see 441, 443 in FIG. 4B). In this case, the system would merely monitor task completion data 445 (see also 485, 486, 487 and 488 in FIG. 4D) and if required, issue a Completion Certificate 447 when the tasks are completed and the loan process closed. If the user/lender wants OnePipeline to handle the loan, the Compliance Engine can transfer the set of tasks for this loan to an internal Loan Processing & Workflow engine 437. This internal Loan Processing & Workflow engine (Forte Conductor™, Framework Lendware™, etc) (see also 462, 463, 464, 466 and 467 in FIG. 4C) will automatically transmit specific tasks to specific workers who have been previously identified as responsible for those kind of tasks 438, will supply task completion data to the Compliance Engine 440 when tasks are completed. The Compliance Engine will supply the completion data to the system so as to generate worker compensation and loan completion reports (see 468 in FIG. 4C), and Completion Certificates 442. The final process module in the system, the Banking & Loan Management process (469 in FIG. 4C), adds the loan, if it was provided by OnePipeline, and its related financial parameters to the inventory of loans managed by applicants. In a preferred embodiment, this Banking & Loan Management process 469 includes a secondary banking engine which manages the packaging and placing of loans with secondary financial institutions so as to optimize the financial returns on the loans handled by applicants. This process would be managed by Lendware™ via an on-site installation or by a Framework™ application service provider (ASP) or equivalent implementation. In an alternative embodiment, this secondary banking engine which manages the packaging and placing of loans with secondary financial institutions so as to optimize the financial returns on the loans handled by applicants would be a package developed internally by applicants. A depiction of an alternative embodiment of the present invention is shown in FIG. 5 which describes the elements shown in FIGS. 4A, 4B and 4C in a different depiction. Each of these features is described in more detail below. The 'Loan Origination Gateway' 501 or portal, serves as an 'entry point' or gateway to the 'pipeline' or system. The loan originator enters data for both himself and for the borrower. This data is passed to the Authentication module 503 which uses these data as inputs to the Compliance Engine 520. The Compliance Engine 520 uses these data from its associated worker's description 521 and legal context 523 files to determine whether the loan originator can originate this loan for this property. If so, the Authentication module 503 "authenticates" the transaction and passes the information to the Loan Origination System 505 for analysis of corespondent pricing and for underwriter approval. As indicated above, this function could be performed by the system or through the interface to an equivalent service such as the PremierePricer™ product supplied by GHR Systems™ Inc. Then the loan originator is asked to indicate which tasks he will do (of the optional tasks available) 519. These optional task and fee data along with the original Loan Originator data and borrower data and underwriter data are then passed to the Compliance Engine 520 wherein the mandatory tasks identified based on the legal requirements for this loan originator and this location of the property, and the selected optional tasks are combined by the Compliance Engine 520 into a required set of tasks for this loan and passed as inputs to the Loan Fulfillment System 545. The Loan Fulfillment System 545 assembles the inputs and task requirements for input to the Mortgage Workflow Engine 553 which automatically manages the task execution by various responsible parties. In the process of managing the execution of the required tasks the Mortgage Workflow Engine 553 automatically communicates with parties having an interest in this loan via the Task Maintenance & Status Reporting Gateway 550 and communicates with various service providers via the Transaction Service Provider Gateway 555. When the loan is finally closed (i.e. all designated tasks completed) this status is communicated to the Compensation & Task Performance Report system 557 for the generation of these reports. The loan completion status is also communicated to the Secondary Banking & Loan Inventory Management system 563 which adds the completed loan data to the loan inventory and periodically, using a Secondary banking Engine 559, optimally packages certain loans for transfer to secondary funding sources. Having described a preferred embodiment and an alternative embodiment of the applicants invention, we now describe the major components in more detail. FIGS. 7-11 indicate the basic original entry into the automated system and shows the kinds of data that is inputted. These data are then processed as follows. The 'Loan Application Gateway' Referring to FIG. 33, A loan originator, in any of several manifestations, may originate a mortgage loan request on behalf of a client, a 'borrower'. The 'Loan Application Gateway' provides for the Lender/Loan Originator to enter his data and borrower data 3401 and envisions at a minimum, three (3) ways by which the system may be accessed by a loan originator; (1) via Internet website 3405 of the assignee of the present invention, the data typically being in HTML format; (2) via custom-written software 3403 which connects in a data transmission-enabled manner to the present invention and would typically be in XML format; and (3) via 'wireless' devices, including web-enabled cell phones, wireless, modem-equipped hand-held or laptop computing devices, satellite communication devices, and other such wireless data and communication methods and devices 3407 as may come into common use, these data typically being in the WML or WAP formats, or other formats as may come into common use. The principle purpose of the 'Loan Application Gateway' 3400, in serving as a portal, is to provide a way for the loan originator to exchange required data with to the "Loan Application System' without having to worry about what input method he is using and/or the related data formats and protocols. Consequently the major purpose of the input gateway is to perform the middleware tasks of—recognizing the input channel and data format and protocol used 3409 and convert the data to the standard Application Programming Interface (API) format 3411 which will be used by downstream modules. This standard Application Programming Interface (API) format 3411 is described in more detail below in the section covering the Compliance Engine. The input data originates from the input screens provided by the system. Upon making the connection to the OnePipeline system, the loan originator is presented with introductory screen sets (FIGS. 7-12) and input screen sets (FIGS. 13-18) whereby the particular information which describes, to the OnePipeline system, the circumstances of the borrower, as well as the property under contemplation for purchase. Suitable reference and 'help' screens are made available to the loan originator to assist in the entry of required data. Notably, display information and on-screen prompts for data input are tailored to the nature and speed of the data link as well as the display limitations of the terminal device in use by the loan originator. Referring to FIGS. 7-18, such data or information is required for originating and underwriting a loan, and typically includes the following: a subscribing loan originator's identification FIG. 7, pertinent information sufficient to identify the pending borrower FIG. 13, and information on the subject property FIG. 14. The subscribing loan originator's identification FIG. 7, in turn, provides the present invention with a profile of the originator and the location of the property in question thereby providing sufficient information to facilitate authentication of the originator's qualification, according to regulations, to originate a loan, and other such information as is deemed necessary to logically connect the originator with agents, workers, or services which have been associated with the originator as 'loan affiliates'. These 'affiliates' constitute a variety of resources which may be called upon on a loan-by-loan basis to provide services common in the industry, to the originator in order to complete the loan. The Authentication System In a preferred embodiment of the system, a Lender may make use of the OnePipeline system merely to obtain the set of tasks required for a specific loan, including tasks required by applicable federal and/or state law, and to obtain a Completion Certificate, or he may originate a loan through OnePipeline's network of Loan Originators also obtaining a Completion Certificate based upon the systems monitored performance of the required tasks involved. In either case the Loan Originator's qualifications are not verified by the Compliance Engine. That is, the Compliance Engine does not check the lenderId and property location to determine whether this Loan Originator is qualified to represent this loan applicant. In an alternative preferred embodiment, this authentication of the loan originator/lender is performed. This process will now be described. Upon completion of data entry by the loan originator, the OnePipeline system launches a validation or 'authentication' process 403 in FIGS. 4A and 503 in FIG. 5. The authentication module verifies the identity of the loan originator through the use of conventional means, a security 'login' typically requiring user names and passwords, which are programmatically verified as belonging to the loan originator. Various data security mechanisms may be incorporated in this sub-system as well, including the use of digital signatures as required. The completeness of the required input data is also verified. The Authentication module also authenticates the loan originator as being qualified to originate a loan for the property location specified. The module gets the loan originator and borrower input data 401 and calls the 'Compliance Engine' 405, to determine whether the loan originator can originate this loan. If the initial queries to the legal context databases (these are described in more detail below with respect to the compliance engine description) indicate that the loan originator is not qualified then this "not-qualified" data is returned to the loan originator. If the loan originator is found to be qualified to originate loans in the locality a "yes" is returned and the authentication module may instruct the Compliance Engine to complete a "worker profile" for this loan originator, borrower and property. The Automatic Compliance Engine The Automatic Compliance Engine (the "Compliance Engine"), (458 in FIG. 4C and 520 in FIG. 5), is now described in a preferred embodiment. The Compliance Engine is called a number of times by several modules. As described above, many government, professional, and business institutions impose requirements on land and mortgage lending transactions. A requirement can be the disclosure of specified information to the borrower, filling out a required form, or the gathering of specified information, to name a few. OnePipeline.com, Inc. retains the services of legal professionals throughout the country who continuously gather these requirements and organize them into a comprehensive rule base. The purpose of the Automated Compliance Engine is to apply these rules in an automated way to identify all requirements that apply to a specific loan and to track the completion of those tasks. The output of the engine is a task list comprised of all the tasks which the engine has determined need to be completed for a specific loan, augmented with task completion information for completed tasks. In a preferred embodiment, the task list is prepared by selecting a subset of tasks from the list of all task definitions known by the Automated Compliance System. Tasks are selected by evaluating expressions written in a dynamically interpreted programming language that test facts pertaining to the specific loan information. If the expression evaluates to true, then all tasks associated with that expression are added to the task list. All of the expressions in the rule base are sequentially evaluated for each loan instance. The Automated Compliance Engine is thus a rule based system, where each expression represents the 'if' part of a rule, and the subset of tasks associated with the expression represents the 'then' part of a rule. For example, the following is a set of tasks for a given context:
Once required tasks are identified, the engine applies lender task profiles in order to override task description, the URL to print a form, and other task information provided in the standard task definitions with more specific values from the Lender Task Profiles. This allows a high degree of flexibility in customizing the engine for specific lender requirements, including changing the wording of the description of the task or changing the form that must be filled out. Once the task list has been initially prepared, it is presented to those persons responsible for completing the tasks. This may be as a simple task list transmission to a lender who is doing his own loan origination and/or processing and simply wants OnePipeline to monitor task completion, or it may be an automatic transmission to an automated workflow process engine. In a preferred embodiment, the automated workflow process engine may be Framework™ Inc.'s "Lendware™" program or a functional equivalent, such as one based on Forte Software™ Inc.'s Forte Conductor™ product. In this case the Workflow process engine presents the tasks to the persons identified as being responsible for doing the task. As each task is completed, the Compliance Engine receives notice of the completion event and the task list is updated to include the identification of the person completing the task and the date and time of completion. The task list is considered completed when all required tasks have a completion date. Compensation may be issued to those who performed specified tasks with assurance that all required tasks have been completed and that the compensation is within the bounds of the laws and policies of the participating institutions. Data Representation In the preferred embodiment, all Compliance Engine inputs and outputs are in represented externally in Extended Markup Language format (XML) which is described in the document found at www.w3.org/TR/1998/REC-xml-19980210 which is incorporated fully herein by reference. XML provides an extensible hierarchical data structure where each element of information is labeled with a tag and optionally contains a value and any number of child elements. Internally, the same information is represented and manipulated in a standard tree format using the Document Object Model tree (DOM) which is described in the document at www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-1590626202 and which is incorporated fully herein by reference. Conversion between internal and external representation is provided by output methods of the DOM tree implementation and input methods of the Java API for XML Parsing (JAXP) which is described in the document at the URL java.sun.com/xml/docs/api/ which is incorporated fully herein by reference. For convenience in referring to DOM tree elements, but not of necessity, the tree implementation is extended to provide easier tree traversal using a simple "get (String path)" method that takes a path argument such as 'task.name'. The tags between the dots '.' are parsed out of this path and used to search for corresponding elements in the tree. In this example, the get method searches for the first-occurring element of the tree with tag "task". Once found, the get method then searches for the 'name' tag among the child elements of the 'task' element, and so on for all the tags listed in the path. Further descriptions herein will use this path notation to refer to specific data elements in the data model trees defined below. Alternative ways to represent and access the information could include files, objects, database records, arrays, structs, TCP/IP socket streams, 'if-then-else' statements in a programming language, or other ordinary means for representing structured information. Data Mode In recognition of the need to automate as many of these activities as possible, to the mutual advantage of the real estate and mortgage loan community, the Mortgage Bankers Association of America (MBAA) recently originated an effort to develop data structure standards to provide standardization of common business transactions in the mortgage industry. This effort is coordinated by a workgroup of mortgage industry representatives and is called the Mortgage Industry Standards Maintenance Organization (MISMO). Initial deliverables of MISMO include 1) an XML Transaction Architecture to encompass data exchanges from loan origination, the secondary market and servicing; 2) a data dictionary to provide business definitions and corresponding tag names of each of the data elements included in the architecture; and 3) a data model to provide relationships between the elements in the business data. The current versions of these deliverables are contained at www.mismo.org and are fully incorporated herein by reference. This description refers to the detailed data model in the MISMO web site mentioned above (www.mismo.org). The Data Model is described therein as follows:
The Compliance Engine XML/HTTP Transaction API described below includes Example values for clarification. The core knowledge of compliance requirements is represented in the 'rules' structure, consisting of 'rules.contexts' and 'rules.operations'. Each 'rules.contexts.context' represents an if/then rule, where the 'context.if' part describes a specified loan situation (context), and the 'context.then' part is a list of 'taskname' references to the tasks that are required in that context. Each 'context.if' definition is expressed in a programming language statement that examines the facts of a specific loan and evaluates to true or false, as described in the algorithm description below. Each 'rules.operations.task' defines detailed information about a specific task, independent of the contexts in which it may be required. This information includes a description of the task, a URL link to any forms that may be required for the task, a time period within which the task is expected to be completed, and potentially other information pertinent to a task. References from the context structure in each 'rules.contexts.context.then.taskname' are matched with the corresponding name in 'rules.operations.task.name'. In this manner, a detailed task definition is associated with one or more specific contexts, by task name reference. This separation between tasks and contexts is a convenience that allows a task to be defined in a single place yet be associated with multiple contexts. Alternatively, the 'rules.operations' list could be eliminated by replacing every 'rules.contexts.context.then.taskname' with an equivalent 'task' structure as presently defined in 'rules.operations.task', although many of the tasks would need to be defined and maintained redundantly in this mode. Elements of a 'rules.operations.task' definition may be overridden by a corresponding element in an 'override.tasks.task' definition whose 'rules.operations.task.name' matches the 'override.tasks.task.name'. This allows customization by supplying customer-specific information in the task definition, such as a customer-specific form, description in more familiar language, or any other task definition element. Any number of 'override' structures may be applied in sequence, each overriding the result from the previous 'override' application. This allows overrides from customers, and their brokers, agents, and other affiliates to be applied in any desired priority ordering that ultimately determines which override changes will be final. The method of applying the override information is described in the algorithm below. The 'loan' structure contains all the information pertaining to a specific loan application. The loan application contains information about the borrower, the property to be mortgaged, its location, the loan amount, and the type of loan applied for. This is the information that is evaluated by the 'rules.contexts.context.if' expression to determine whether the conditions specified in the context definitions are true in the case of a specific loan. Compliance Engine XML/HTTP Transaction API The Compliance Engine Application Program Interface (API) defines structures for communication between the Automated Compliance Engine and the external environment. The request is initiated by an external agent with accompanying request parameters described below, and the response is a complete Task Status Report consisting of the 'tasks' list output of the engine plus the completion information of completed tasks. Each output 'tasks.task' defines a task that the engine has determined is required in the case of the specified loan. The list will typically be a subset of all defined tasks. Each task includes the detailed task definition information from 'rules.operations.task', with some elements possibly overridden by corresponding task override information from 'override.tasks.task'. Data is exchanged via pre-authenticated HTTP in XML format (DTD available). It is presented in indented format for readability. All XML elements are required. The lender must provide, for each loan product, a description containing the product attributes that are required for compliance analysis, such as whether ARM, fixed, balloon, index, etc. Each loan application is linked to this information via the loanProductId compliance parameter, described below. This must be updated whenever the product attributes change. The MISMO standard mentioned above contains most of the information required by the Compliance Engine to perform its work, but not all. The key missing pieces are the type of loan product the borrower is applying for, and the lender and agent identification. Loan products differ from each other in terms of whether they are adjustable rate (ARM) or fixed, whether the rate is tied to T-bills or some other index, whether there is a Balloon payment, whether the property will be owner occupied or rented out, whether there is cash out or not, etc. The loan product information is complex, and there are several compliance rules that arise out of different characteristics of the lender's loan product. In a preferred embodiment, rather than try to identify all facets of the loan product in a structured way and apply rules each time those facets are examined, instead, the loan product information is analyzed by hand, one time, up front, and a decision is made as to what compliance tasks are required for that type of loan. Then when it's time to generate a task list, there is a single rule that indicates if you have loan product type XYZ then you must do tasks 1, 2, and 3. The main piece of information that is not provided by MISMO is the loan product ID, which is the id given the loan product by a lender. Besides the loan product ID, the compliance API also requires the lender id, which is used in conjunction with the loan product id to fully identify the loan product, and it also tells us where the loan originator's pay will come from, which lender profile to apply, the lender to send notifications to, etc. The API also requires the loan originator agent id, which identifies who the loan originator is so he/she can be paid appropriately when that time comes. The loan originator id is assigned by OnePipeline. The lender may also provide a task list profile that defines override values for task.description and task.form for any task. These values override the OnePipeline default values for these fields, if present. This allows lenders to describe tasks in their preferred terminology and to use their own forms, subject to compliance requirements. These data provided via the Loan Application Gateway 3400 (described above) include the following exemplary type data: New Task List Transaction This transaction creates a new loan compliance record in the OnePipeline compliance database, and creates the task list. Input:
Output: Task Status Report (see below) Update Transaction This transaction updates the loan compliance record when one or more tasks are completed, or when loan compliance parameters are changed. If loan compliance parameters are changed, a new task list is generated, and the old one is moved to the taskListArchive section. Task completion information is retained in both the current task list and in the archived task lists. Input:
Output: Task Status Report (see below) Task Status Report Transaction Output: Format and structure is the same for all transaction types. When changed loan compliance parameters require regenerating the task list, old task lists are preserved in the taskListArchive section. Completion information is present only for completed tasks, in both tasks and taskListArchive sections.
Algorithm Refer to the description of XML, JAXP, and DOM in the data representation description above, and to the data model description and detail data model elements also described above. At startup, the Automated Compliance Engine reads the XML-formatted 'rules' from external storage into memory. This XML stream is parsed by the JAXP parser into a DOM internal tree. For each 'rules.operations.task', the 'task.name' is used as a key in adding task detail definition elements to a java.util.Hashtable to enable looking up a task definition by 'task.name'. Similarly, an array is loaded with each 'task' indexed by 'task.id', to enable looking up each task by the unique 'task.id' integer value. A separate hashtable is loaded with task override information for each lender, again using the 'task.name' as the key. Also, a socket connection to a network is opened by a web server or other HTTP service to enable Compliance Engine users to submit requests to the Compliance Engine server and to return responses. HTTP socket connections are describer described in the document found at www.w3.org/Protocols/rfc2616/rfc2616.html and which is incorporated fully herein by reference. Once initialized, the Compliance Engine server operates in a stateless request-response fashion, similar to a web server, following the HTTP protocol. Alternative protocols could be used. The request and response are both formatted externally in XML format, and internally in DOM trees, as described in the data representation description above. The Compliance Engine API provides for three different request types: New Task List, Task Completion, and Task Status Report. These are described below. The response in all cases is a Task Status Report containing a 'tasks.task' list. The remainder of this algorithm section describes how the task list is created or updated in response to these requests. The Compliance Engine also incorporates an 'event generation mechanism', the purpose of which is to trigger actions upon the occurrence of specified events. These events may include a 'pushed' report where a task list is periodically updated according to specified parameters and delivered. New Task List The New Task List request consists of a 'loan' structure that contains information about a specific loan sufficient to determine which compliance tasks are required. The 'tasks.task' list is prepared as follows. Each 'rules.contexts.context.if' expression is evaluated, one at a time, in a loop from first to last. The 'if' expression is written in the JPython programming language, which is an interpretive scripting language that can evaluate string expressions at runtime. The Python Programming Language is described in the book "Internet Programming with Python" by Aaron Waters, Guido van Rossum and James C. Ahlstrum, M & T Books (Div. of Henry Holt & Co.) 1996, which is incorporated herein by reference. Other languages could be used. The expressions typically reference a specific element in the 'loan' structure to see if the element contains a specific value. For example, to determine if the loan property is in the state of Utah, the expression could be "val('loan.property.address.state')='UT'". The "val( ) method takes a string describing a path into a DOM tree, and returns the first value of the first DOM node found on that path. If the actual value of the 'loan.property.address.state' node of a specific loan was 'UT', the expression evaluates to true, otherwise false. When such an 'if' expression evaluates to true, all of the associated 'rules.contexts.context.then.taskname' references are followed by using the 'taskname' value as a key to look up the referenced task detail definition through a java.util.Hashtable populated at startup. After finding the task detail in the hashtable, the 'rules.operations.task.name' task detail definition structure could be copied directly to an output task list; however, for convenience in the preferred embodiment, the integer value of the included 'rules.operations.task.id' element is used to set a corresponding bit in ajava.util.BitSet. This 'id' integer value is unique for each task in the 'rules' set. After all rules have been evaluated and all applicable bits are set, the resultant BitSet contains a true bit for every task with a true 'if' expression. The BitSet thus represents the subset of all tasks which the Compliance Engine has determined to be required in the case of the specified loan. The purpose of this BitSet representation is to allow, in the future, rapid and simple boolean operations (and, or, or not operations on the BitSet) to combine task lists from different rule sets to improve flexibility and/or increase performance. One way to increase performance, for example, is to create a BitSet at startup time from a rule set that contains contexts that are always true for every loan. This initially created BitSet can be combined with the dynamically created BitSet using a bitwise 'and' operation in a manner that avoids unnecessary re-evaluation of some rules. Once a final BitSet is constructed, the program loops through each bit in the BitSet, and where a true bit is found in a particular bit position, the bit position is used as the index to retrieve the corresponding 'task' definition structure from the array that was indexed at startup time using the matching 'task.id' integer value. This 'task' detail definition structure is then copied and the copy appended to the DOM output tree containing the output task list. After constructing the list of task detail definitions for all required tasks, the task override information is applied. This is accomplished by iterating through each task on the output task list, and looking up the task override information for the lender specified in the request. If a task override structure is present in the table, then the program loops through each element in the override structure task definition and replaces the corresponding element in the output task definition. For example, if the override task structure includes a lender-provided task description, then the value of that description is copied over the top of the more generic description from the original rules structure. Exemplary Task List An exemplary task list generated by the Compliance Engine in a preferred embodiment is as follows:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||