Intelligent Processing of Mortgage Loan Applications Using a Virtual Processor

Implementations relate generally to mortgage lending. More specifically, implementations relate to methods and systems for the intelligent processing of mortgage loan applications using a virtual processor.

The mortgage lending industry can be characterized by a high degree of fragmentation and variability. Each lender has its own unique set of requirements, forms, and processes that must be adhered to in order to secure a mortgage loan. This includes tasks which must be completed by a mortgage broker, applicant, or correspondent lender in order to fund the loan. Not only may the tasks themselves vary from lender to lender, but the required information for each task may also vary, as well as the format of documents to be completed. This lack of standardization creates significant challenges for mortgage brokers and applicants who must navigate and comply with different sets of rules, leading to inefficiencies and increased processing times.

Traditionally, mortgage brokers working with multiple lenders need to manage multiple sets of paper-based or electronic forms, each tailored to the specific requirements of individual lenders. This often involves redundant data entry, reformatting documents, and revalidating information to meet each lender's specifications. Such processes are not only time-consuming but also prone to errors, which can further delay loan approvals and increase costs for both brokers and applicants.

The current state of the art lacks a unified approach to handling the disparate requirements of multiple lenders. Existing software solutions typically focus on the needs of a single lender, producing standardized output only for that lender. This limitation forces brokers to use multiple systems or platforms to meet the diverse demands of different lenders, resulting in a fragmented workflow. Additionally, when an applicant decides to switch lenders, the process of re-submitting information and generating new documents further compounds the inefficiencies. This fragmented approach underscores the need for a more streamlined and intelligent solution to process mortgage loan applications effectively.

The appended claims may serve as a summary of this application.

In this specification, reference is made in detail to specific embodiments of the disclosure.

For clarity in explanation, the disclosure has been provided with reference to specific embodiments, however it should be understood that the disclosure is not limited to the described embodiments. On the contrary, the disclosure covers alternatives, modifications, and equivalents as may be included within its scope as defined by any patent claims. The following embodiments of the disclosure are set forth without any loss of generality to, and without imposing limitations on, the disclosure. In the following description, specific details are set forth in order to provide a thorough understanding of the present disclosure. The present disclosure may be practiced without some or all of these specific details. In addition, well known features may not have been described in detail to avoid unnecessarily obscuring the disclosure.

In addition, it should be understood that steps of the exemplary methods set forth in this exemplary patent can be performed in different orders than the order presented in this specification. Furthermore, some steps of the exemplary methods may be performed in parallel rather than being performed sequentially. Also, the steps of the exemplary methods may be performed in a network environment in which some steps are performed by different computers in the networked environment.

Some embodiments are implemented by a computer system. A computer system may include a processor, a memory, and a non-transitory computer-readable medium. The memory and non-transitory medium may store instructions for performing methods and steps described herein.

In one embodiment, the system receives a set of non-standardized input data including information required by one or more lenders associated with a user who is a mortgage broker, applicant, or correspondent lender; catalogs one or more requirements of each lender based on the non-standardized input data; standardizes the received non-standardized input data into a standardized format; receives preliminary information from the user; processes the received preliminary information to determine additional requirements of the lender based on a multitude of variables derived from the preliminary information; assigns one or more tasks to the user based on the requirements of the lenders; receives, in response to assigning the one or more tasks, information related to the user; generates, using at least the information related to the user, output documents in specific formats required by the one or more selected lenders using the standardized input data; and facilitates the e-signature of the generated output documents by the user.

Further areas of applicability of the present disclosure will become apparent from the remainder of the detailed description and the claims. The detailed description and specific examples are intended for illustration only and are not intended to limit the scope of the disclosure.

is a diagram illustrating an exemplary environment in which some embodiments may operate. In the exemplary environment, a user deviceis connected to a processing engineand, optionally, a platform. The processing engineis connected to the platform, and optionally connected to one or more repositories and/or databases, including, e.g., an input data repository, an information repository, and/or an output documents repository. One or more of the databases may be combined or split into multiple databases. The user devicein this environment may be a computer, and the platformand processing enginemay be applications or software hosted on a computer or multiple computers which are communicatively coupled via remote server or locally.

The exemplary environmentis illustrated with only one user device, one processing engine, and one platform, though in practice there may be more or fewer additional user devices, processing engines, and/or platforms. In some embodiments, the user device(s), processing engine, and/or platform may be part of the same computer or device.

In an embodiment, the processing enginemay perform the exemplary method ofor other method herein and, as a result, provide intelligent processing of mortgage loan applications using a virtual processor. In some embodiments, this may be accomplished via communication with the user device, processing engine, platform, and/or other device(s) over a network between the device(s) and an application server or some other network server. In some embodiments, the processing engineis an application, browser extension, or other piece of software hosted on a computer or similar device, or is itself a computer or similar device configured to host an application, browser extension, or other piece of software to perform some of the methods and embodiments herein.

The user deviceis a device with a display configured to present information to a user of the device who is a user of the platform. In some embodiments, the user device presents information in the form of a visual UI with multiple selectable UI elements or components. In some embodiments, the user deviceis configured to send and receive signals and/or information to the processing engineand/or platform. In some embodiments, the user device is a computing device capable of hosting and executing one or more applications or other programs capable of sending and/or receiving information. In some embodiments, the user device may be a computer desktop or laptop, mobile phone, virtual assistant, virtual reality or augmented reality device, wearable, or any other suitable device capable of sending and receiving information. In some embodiments, the processing engineand/or platformmay be hosted in whole or in part as an application or web service executed on the user device. In some embodiments, one or more of the platform, processing engine, and user devicemay be the same device. In some embodiments, the user deviceis associated with a first user account within a platform, and one or more additional user device(s) may be associated with additional user account(s) within the platform.

In some embodiments, optional repositories can include an input data repository, information repository, and/or output documents repository. The optional repositories function to store and/or maintain, respectively, non-standardized input data associated with lenders; information received from brokers or applicants; and output documents in specified formats required by lenders. The optional database(s) may also store and/or maintain any other suitable information for the processing engineor platformto perform elements of the methods and systems herein. In some embodiments, the optional database(s) can be queried by one or more components of system(e.g., by the processing engine), and specific stored data in the database(s) can be retrieved.

Platformis a platform configured to provide the intelligent processing of mortgage loan applications using a virtual processor, in relation to the systems and methods herein. The platformmay present a user, who may be a mortgage broker, applicant, or correspondent lender, with one or more user interfaces or interface components which facilitate the processing of a mortgage loan application using the virtual processor.

is a diagram illustrating an exemplary computer systemwith software modules that may execute some of the functionality described herein. In some embodiments, the modules illustrated are components of the processing engine.

Receiving modulefunctions to receive a set of non-standardized input data including information required by one or more lenders associated with a user, who is one of a mortgage broker, applicant, or correspondent lender. The module also functions to receive information related to the user.

Cataloging modulefunctions to catalog one or more requirements of each lender based on the non-standardized input data.

Standardizing modulefunctions to standardize the received non-standardized input data into a standardized format.

Information modulefunctions to receive preliminary information from the user.

Processing modulefunctions to process the received preliminary information to determine additional requirements of the lender based on a plurality of variables derived from the preliminary information.

Assigning modulefunctions to assign one or more tasks to the user based on the requirements of the lenders.

Generating modulefunctions to generate, using at least the information related to the user, output documents in specific formats required by the one or more selected lenders using the standardized input data.

Facilitating modulefunctions to facilitate the e-signature of the generated output documents by the user.

The above modules and their functions will be described in further detail in relation to an exemplary method below.

is a flow chart illustrating an exemplary method that may be performed in some embodiments.

At step, the system receives a set of non-standardized input data including information required by one or more lenders associated with a user within a virtual processor platform. The user may be one of a mortgage broker, applicant, or corresponder lender associated with a user account on the platform. In the context of this method, the term “user” refers to a stakeholder involved in the mortgage loan application process who interacts with the virtual processor. These users can be broadly categorized into three main types: mortgage brokers, applicants, and correspondent lenders. A mortgage broker acts as an intermediary between borrowers (i.e., applicants) and lenders. Mortgage brokers assist applicants in finding and securing mortgage loans by comparing different loan products from various lenders. They collect necessary information from the applicant, help them complete the required documentation, and submit loan applications on their behalf. An applicant is an individual or entity seeking a mortgage loan. Applicants require financing to purchase real estate, refinance existing mortgages, or leverage their property equity for other financial needs. A correspondent lender is a type of lender that originates and funds mortgage loans but typically sells these loans to larger mortgage lenders or investors shortly after closing. Correspondent lenders manage the entire loan process, from application to funding, and maintain direct interaction with the applicant or broker during this period. They handle the underwriting, closing, and initial funding of the loan, but their primary business model involves selling the funded loans to secondary markets to mitigate risk and maintain liquidity. The virtual processor platform caters to these different users and stakeholders by providing a user interface, information, and interactivity within the platform that supports the unique needs of each category.

In various embodiments, this non-standardized input data encompasses various types of information that lenders typically require to evaluate mortgage loan applications. This can include, for example, needed personal information of the applicant, such as name, address, social security number, and contact details; financial information, including income, employment history, credit score, and existing debts; property details, such as the address, type, and value of the property being mortgaged; and specific loan details, such as the desired loan amount, interest rate, and term. In some embodiments, the non-standardized input data includes specific formatting requirements for output documents as stipulated by different lenders.

In various embodiments, lenders may be associated with a broker or applicant in various ways. In some embodiments, the applicant or broker can select which lenders they are associated with by using a drop-down box or by entering text into a text field on a user interface. This selection process allows the system to tailor the required tasks and document formats to the specific lenders chosen by the user, ensuring that the information collected is relevant and correctly formatted for the selected lenders.

In some embodiments, the system operates within a virtual processor platform that serves a multitude of users, including, e.g., brokers, applicants, correspondent lenders, or some combination of the three. In some embodiments, this platform provides a user interface catered to these users, displaying information related to the loan application process and enabling interactive entry or selection of information. In some embodiments, brokers can use the platform to, e.g., manage multiple loan applications simultaneously, track the progress of each application, and communicate with applicants and lenders. In some embodiments, applicants can access the platform to, e.g., provide required information, review loan terms, and digitally sign documents. In some embodiments, correspondent lenders can use the platform to, e.g., manage the underwriting process, ensure compliance with lender requirements, facilitate the efficient processing and funding of loans, and prepare the loans for sale in the secondary market. The user interface is designed to streamline the loan application process, providing a seamless, user-friendly experience for all parties involved and facilitating efficient communication and collaboration throughout. In some embodiments, one single platform may be utilized by both brokers, applicants, and correspondent lenders as users, with certain branding and other aspects tailored to some types of users (such as brokers) and different branding and other aspects tailored to other types (such as users).

In some embodiments, the system is designed to handle input data that arrives in various formats and structures. This non-standardized data can come from different sources, including, for example, digital forms filled out by applicants, documents uploaded by mortgage brokers, or data directly pulled from third-party systems such as, for example, credit bureaus or employment verification services. In some embodiments, the input data may include lender-specific requirements for document formats and submission protocols.

In some embodiments, upon receiving the non-standardized input data, the system employs advanced data parsing techniques to interpret and categorize the information. This can involve identifying and extracting relevant data fields from the input, even when the data is presented in an unstructured or semi-structured format. In various embodiments, the system uses one of or a combination of: rule-based algorithms, machine learning models, and natural language processing to accurately map the incoming data to a standardized schema. This process ensures that all necessary information is captured and correctly understood, regardless of the initial format in which it was received, and accommodates the specific document formatting needs of different lenders.

In some embodiments, the robustness of the data reception process is further enhanced by one or more validation mechanisms. These mechanisms check the completeness and accuracy of the received data against predefined rules and lender-specific requirements. For example, the system may verify that mandatory fields are not left blank, check for valid formats in numerical data, and cross-reference information with external databases to ensure its authenticity. In some embodiments, the system additionally ensures that the data conforms to the specific document formatting requirements of each lender. Any discrepancies or missing information are flagged for further review, and the user is promptly notified to provide the necessary corrections.

At step, the system catalogs one or more requirements of each lender based on the non-standardized input data. In some embodiments, this process involves analyzing the received input data to identify the specific requirements imposed by each lender participating in the mortgage loan application process. These requirements may vary significantly between lenders and encompass a wide range of criteria, including, for example, document formats, information completeness, submission deadlines, and specific data validation rules.

In some embodiments, the system utilizes advanced algorithms and data processing techniques to extract and categorize the lender-specific requirements from the non-standardized input data. In some embodiments, this involves parsing through the information provided by the lenders and identifying key criteria that must be met for each loan application to be considered complete and compliant. In some embodiments, the system may access internal databases or external sources to cross-reference the lender requirements with industry standards and regulatory guidelines. Once cataloged, the lender requirements are stored within the system's database, organized in a structured format for easy retrieval and reference during subsequent stages of the loan application process.

In some embodiments, the system stores the cataloged requirements of each lender in a centralized database accessible by the virtual processor. This database serves as a repository for storing and managing the unique requirements, preferences, and guidelines associated with each participating lender. By storing the cataloged requirements in a database, the system establishes a comprehensive and structured knowledge base that consolidates information pertinent to the mortgage loan application process. This centralized repository streamlines access to lender-specific data, eliminating the need to repeatedly gather and analyze requirements for each transaction. Mortgage brokers, applicants, and other system users can leverage this repository to quickly retrieve relevant information and streamline decision-making processes. In some embodiments, the database may incorporate features for, e.g., version control, audit logging, and/or data governance to maintain data integrity and compliance with regulatory requirements.

In some embodiments, the cataloged requirements of each lender are updated in real-time based on changes in the lenders' submission guidelines. In some embodiments, the system continuously or periodically monitors and tracks changes in the submission guidelines of each lender participating in the mortgage loan application process. This may involve, e.g., subscribing to data feeds, accessing online portals, or interfacing with APIs provided by the lenders to receive timely updates regarding any modifications or revisions to their requirements. Upon detecting changes in the lenders' submission guidelines, the system automatically updates the cataloged requirements associated with each lender. This real-time updating process ensures that the system maintains an accurate and up-to-date repository of lender-specific requirements, reflecting the latest expectations and preferences of the lenders.

At step, the system standardizes the received non-standardized input data into a standardized format. In some embodiments, this process involves transforming the heterogeneous data obtained from various sources and in diverse formats into a uniform structure that can be efficiently processed and analyzed by the system. In some embodiments, to achieve standardization, the system employs one or more data normalization techniques. In some embodiments, the data normalization techniques include identifying common data elements across different input formats and mapping them to a predefined schema. This schema serves as a template that defines the structure and attributes of the standardized data format, encompassing fields such as, for example, applicant information, financial details, property specifications, and loan parameters. In some embodiments, the system carefully validates and verifies each data element to ensure accuracy and completeness, correcting any inconsistencies or discrepancies encountered during the standardization process.

In some embodiments, the standardization process may involve enriching the input data by augmenting it with additional contextual information or metadata, enhancing its relevance and utility for subsequent processing steps. This enrichment may include appending, for example, timestamps, unique identifiers, or other relevant identifiers to the standardized data, facilitating traceability and auditability throughout the mortgage loan application lifecycle.

In some embodiments, once standardized, the input data is transformed into a cohesive and structured dataset that conforms to the system's internal data model. This standardized format enables efficient data manipulation, analysis, and retrieval, empowering the system to perform advanced processing tasks such as, e.g., task assignment, document generation, and compliance checks with precision and accuracy.

In some embodiments, the standardized format includes a standardized input form to collect information from the user needed for any of the one or more lenders. This standardized input form serves as a universal template designed to collect information from mortgage brokers or applicants, catering to the requirements of any of the one or more lenders involved in the mortgage loan application process. In some embodiments, the standardized input form encompasses all the essential fields and data points required by the participating lenders. It provides a structured framework for capturing various types of information, which may include, for example, personal details, financial information, property specifications, and loan preferences, among others.

At step, the system receives preliminary information from the user. In various embodiments, this preliminary information often originates from an initial loan request submitted by the applicant, and can include basic details about the user's loan application (or, e.g., an applicant's loan application that a broker is managing), such as the type of loan, the loan amount, and initial personal and financial information. The type of loan could range from, for example, residential mortgages to commercial real estate loans, refinancing options, or construction loans. The preliminary information may also encompass data points such as the intended use of the loan (e.g., purchase, refinance, or construction), property details, and the desired loan term.

In some embodiments, the preliminary personal information collected at this stage may include, for example, the user's or applicant's name, contact details, and identification information, such as a social security number or tax identification number. Financial information may include the user's or applicant's income, employment status, credit score, and existing debt obligations. For a mortgage broker, this information might also include their business details and licensing information. By gathering this data upfront, the system can create a comprehensive profile of the user or applicant, which can be utilized for accurately assessing loan eligibility and for providing personalized task assignments and document generation later in the process.

In some embodiments, in addition to basic personal and financial details, the system may also capture initial property-related information. This may include, for example, the property's address, estimated value, and details about the property's current ownership and condition. For a purchase loan, the system might collect information about the seller and the purchase agreement. For a refinance loan, the system might gather information about the current loan, including the loan balance and payment history.

At step, the system processes the received preliminary information to determine additional requirements of the lender based on a multitude of variables derived from the preliminary information. The system begins this process by analyzing the preliminary information provided by the user, which often originates from an initial loan request submitted by the applicant. In some embodiments, this preliminary data encompasses various details, such as, e.g., the type of loan sought, the requested loan amount, and initial personal and financial information of the applicant. In some embodiments, the system utilizes multi-variable analysis to dynamically and intelligently determine the specific requirements of each lender. In some embodiments, this multi-variable analysis involves evaluating a multitude of variables that are relevant to the loan application process. In various embodiments, key variables may include, for example, the property type (e.g., residential, commercial, mixed-use), the intended use of the funds (e.g., purchase, refinance, construction), the applicant's credit score, and the desired loan term length. Additionally, the system may consider other financial metrics and personal details, such as, for example, the applicant's debt-to-income ratio, employment status, and existing financial obligations. These variables often play a role in shaping the requirements that lenders will impose on the loan application.

In some embodiments, to perform this analysis, the system leverages a combination of rule-based logic and machine learning models. Rule-based logic helps to quickly filter and categorize the preliminary information based on predefined criteria set by the lenders. For instance, a lender might have specific requirements for applicants with certain credit scores or for loans of particular amounts. On the other hand, in some embodiments, machine learning models are trained on historical loan data to predict lender requirements more accurately. These models may be trained to identify patterns and correlations in the data. In some embodiments, the training of these models involves feeding them large datasets containing previous loan applications and outcomes, enabling them to learn and adapt over time.

Once the system has processed the preliminary information and evaluated the relevant variables, it generates a refined set of requirements specific to each lender involved in the application. In various embodiments, these requirements might include, for example, additional documentation, specific forms, or further verification steps that need to be completed by the applicant or broker.

At step, the system assigns one or more tasks to the user based on the generated set of requirements of the lenders. In some embodiments, this process involves dynamically allocating specific actions or responsibilities to the relevant parties involved in the mortgage loan application process, in order to ensure compliance with the unique requirements set forth by each participating lender.