WO2000075833A2

WO2000075833A2 - Method and business model for matching mortgage lenders and borrowers

Info

Publication number: WO2000075833A2
Application number: PCT/US2000/015329
Authority: WO
Inventors: Donald Tran; John Nhat Le; Robert Leroy Palmer
Original assignee: Loan Trader.Com
Priority date: 1999-06-07
Filing date: 2000-05-31
Publication date: 2000-12-14
Also published as: WO2000075833A8; AU5179100A

Abstract

A queue-oriented loan matching system is implemented as a webserver on the Internet. Each mortgage loan customer completes only one application for a mortgage broker. The Internet is used by such mortgage broker to communicate the loan request to a plurality of mortgage lenders. Filters are used to forward such loan requests only to lenders that want to receive applications from borrowers with particular credit ratings or scores. Brokers send loan requests to lenders that meet their product needs. Each loan request exists in one of several queues. Depending on the action to be taken, either the broker of the lender will advance a loan request from one queue to the next. The status of each loan request is therefore a function of which queue it has been placed into. Each lender generates an individual response to each loan request that the broker can pick and choose. The system allows quality control and business management controls to be efficiently and consistently applied.

Description

Method and Business Model for Matching Mortgage Lenders and Borrowers

BACKGROUND OF THE PRESENT INVENTION

TECHNICAL FIELD

The present invention relates to matching systems and more particularly to computer implemented methods for loan brokers to match mortgage lenders with borrowers.

DESCRIPTION OF THE PRIOR ART

Individual borrowers looking for mortgage loans rarely only apply to one lender. It is well-known that lenders vary on a number of scores, and not all borrowers are equally attractive. So borrowers try to find the best lender and loan they qualify for, and lenders try to find the least risky and highest interest paying borrowers possible. Therefore, for each successful loan application, each lender will have processed several borrower applications, and each borrower will have applied to several lenders.

Loan brokers thus evolved such that a customer could fill out a single loan application. The loan broker would then make a loan request to each lender the broker worked with. But since the loan requests had to be duplicated for each lender, the number of lenders a broker could work with was limited. Each loan request typically necessitated its own unique series of phone calls, faxes, messages, return calls, lost faxes, updated rate sheets, etc.

Each mortgage lender receives many individual loan requests. As with the mortgage broker, each loan request typically necessitated its own unique series of phone calls, faxes, messages, return calls, lost faxes, updated rate sheets, etc. Relatively expensive account executives are needed by the lenders to handle the incoming loan requests prior to a decision or pre-underwriting by a highly paid underwriter. The staffing requirements of lenders is therefore directly related to loan request volume. SUMMARY OF THE PRESENT INVENTION

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a functional block diagram of an Internet system embodiment of the present invention for mortgage broker and lenders to process loan requests from borrowers; and

Fig. 2 is a flow chart diagram of a loan-matching process embodiment of the present invention that may be implemented with the system of Fig. 1.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

Fig. 1 represents an Internet system embodiment of the present invention for servicing a mortgage broker and lender community, and is referred to herein by the general reference numeral 100. The system 100 comprises a plurality of independent mortgage brokers 101-104 that are connected through a corresponding plurality of Internet service providers (ISP's) 106-109 to a wide area network (WAN) 1 10, such as is best represented by the ubiquitous Internet. Similarly, a plurality of independent mortgage lenders 112-116 are connected through a corresponding plurality of Internet service providers (ISP's) 118-122 to the Internet 110. Each mortgage broker 101 -104 and each mortgage lender 112-116 has a computer network workstation with an Internet browser represented by a display and keyboard 124, a computer 126, and a modem A commercial for-profit business 130 has established an Internet presence at a website identified by a uniform resource locator (URL), e.g., "loantrader.com". Such business 130 maintains a network connection 132 with a network server 134. A computer 136 is used for network administration, customer and user enrollments and authorization, news, services referrals, etc. A computer database 138 is used to store and access lender and broker information, various loan-request queues, electronic forms, credit-rating filter data, statistics, billing data, etc. Each independent mortgage broker (W-Z) 101 -104, and each independent mortgage lender (A-E) 112-1 16 is provided with a unique user ID and password after being enrolled as a subscriber. The subscribers are billed according to use and/or on a monthly basis and pay the business 130 to continue to have access to "loantrader.com".

Subscribers are classified as being either brokers or lenders. A log-on page at "loantrader.com" requires each subscriber to enter their user-ID, password, and category of lender or broker. No specialized software is required at the broker or lender sites other than a standard browser, e.g., INTERNET EXPLORER by Microsoft, NETSCAPE NAVIGATOR by Netscape, etc.

After log-on, brokers are presented with a "home" page that includes financial industry news items and several navigation buttons. The broker can "click" on any of the buttons listed in Table I.

TABLE I Broker Home Page

If the broker selects the "New App" button on the Broker Home Page, then an electronic fill-in form is presented that requests the information listed in Table II. Once the form is completely filled in, a "Send" button can be clicked to send the loan request to the appropriate lender(s) according to a credit-rating filter tailored for each lender. Such new application will include credit report scores, e.g., BEACON, FICO, IMPERICA, etc. Fair Isaac, a company located in San Rafael, California, designed a computer program to evaluate the credit risk of consumers based on their credit report. Such risk is rated as a FICO score number. BEACON and IMPERICA are similar measures of credit risk determined by other methods.

TABLE II New Application Fill-in Form

If the broker selects the "Pending" button on the Broker Home Page, then the "Pending Queue" is presented. An example of a typical pending queue is represented in Table III. Any item in the queue can be clicked on for more detail. The pending loan requests are those that have been entered or worked on as a new application, but not yet sent to the lenders. TABLE III Pending Queue

If the broker selects the "Submitted" button on the Broker Home Page, then the "Submitted Queue" is presented, an example of a typical submitted queue is represented in Table IV. Any item in the queue can be clicked on for more detail. The loan requests that are "submitted" are those that have been sent to the lenders.

TABLE IV Submitted Queue

If the broker selects the "BRQ" (broker rate quote) button on the Broker Home Page, then the "BRQ Queue" is presented, an example of a typical BRQ queue is represented in Table V. Any item in the queue can be clicked on for more detail. The BRQ queue gives a realtime display of lender offers to fund that have accumulated for each loan request. The broker is then able to comparison shop and compare the offers when there are more than one for each loan request. The offers will include the terms and conditions that the lender is imposing, and these can be compared on the same display page with what the broker had requested. TABLE V BRQ Queue

If the broker selects the "Accepted" button on the Broker Home Page, then the "Accepted BRQ Queue" is presented, an example of a typical accepted BRQ queue is represented in Table VI. Any item in the queue can be clicked on for more detail. The loan requests in the accepted BRQ queue are those that have been proposed b y the lenders and that have been accepted by the broker. Those offers to fund loan requests that are not accepted, are automatically rejected and the lenders making those offers to fund are notified they did not succeed.

TABLE VI Accepted BRQ Queue

After log-on, lenders are presented with a "home" page that includes financial industry news items and several navigation buttons. The lender can "click" on any of the buttons listed in Table VII.

TABLE VII Lender Home Page

If the lender selects the "New App" button on the Lender Home Page, then the "New Application Queue" is presented. The source of these new applications is the brokers submitted queue. An example of a typical new application queue is represented Table VIII. Any item in the queue can be clicked on for more detail. Such queue cannot be cherry-picked. A first-in first-out rule is enforced.

TABLE VIII New Application Queue

If the lender selects the "Pipeline" button on the Lender Home Page, then the "Pipeline- -Open Queue" is presented. The other pipeline queues are then accessible from the Pipeline-Open Queue page. An example of a typical pending queue is represented in Table IX. Any item in the queue can be clicked on for more detail. A summary of the number of loan requests and their total value is presented.

TABLE IX Pipeline-Open Queue

Number of Loans Total Loan Amount $1 ,525,000

If the lender selects the "Retrieve" button on the Lender Home Page, then the compiled information provided by the broker about the next borrower loan request is presented. A typical example for a borrower named Tumer is illustrated in Table X. Credit rating computations are automatically included, e.g., FICO, BEACON, IMPERICA, etc.

TABLE X Retrieve Page

If the lender selects the "Inbox" button on the Lender Home Page, then the "Inbox Queue" is presented, an example of a typical Inbox queue is represented in Table XI. Any item in the queue can be clicked on for more detail.

TABLE XI Inbox Queue

If the lender selects the "Admin" button on the Lender Home Page, then the "Admin Page" is presented which has several buttons that can be clicked, an example of which is represented in Table XII. "Main" will retum to the Lender Home Page. "UW" goes to an underwriter page where authorized underwriters may be added or deleted by the administrator. "LO" goes to a loan officer page where authorized loan officers may be added or deleted by the administrator. "Product" allows a choice of conventional, FHA, VA, and jumbo loans. "Conditions" allows the lender to enter or check off various terms and conditions that will be made for offer to fund for a particular loan request. "Fees" goes to a page that allows the lender to fix various kinds of fees and commissions, e.g., appraisal, credit report, document prep, insurance, inspections, transfer, etc. "System" goes to a page for system configuration. "Log Off" allows the lender to quit "loantrader.com".

TABLE XII Admin Page

On the "Pipeline-Open Queue" page, various buttons are provided to go to the "pass", "accepted" and the other pipeline queues are then accessible from the Pipeline- -Open Queue page. An example of a Pass queue is represented in Table XIII. Any item in the queue can be clicked on for more detail. A summary of the number of loan requests and their total value is presented.

TABLE XIII Pipeline-Pass Queue

An example of a "Broker Accepted" queue is represented in Table XIV. Any item in the queue can be clicked on for more detail. A summary of the number of loan requests and their total value is presented.

TABLE XIV Pipeline-Broker Accepted Queue

An example of a "Broker Declined" queue is represented in Table XV. Any item in the queue can be clicked on for more detail. A summary of the number of loan requests and their total value is presented.

TABLE XV Pipeline-Broker Declined Queue

Fig. 2 diagrams a method and business model embodiment of the present invention that is implemented on the computer 136, database 138, and network server 134 (Fig. 1), and is referred to herein by the general reference numeral 200. Several queues are maintained by the "loantrader.com" website, and include "open", "pass", "pending", "decline", "accepted", etc. In fact, the process 200 can be described as a queue- oriented loan matching system. The process 200 begins with a data input step 202 in which a mortgage broker enters an application's information 204 from a prospective borrower into a new application page 206 displayed on the broker's computer monitor while running an Internet browser and after logging onto the "loantrader.com" website. The broker completes a loan request profile, e.g., a "new application", using an electronic form provided. As the broker works on the loan request, a database-record reference is maintained in a "pending" queue 208. When the broker is satisfied with the loan request, it is ready to send to a lender. When the broker clicks on a "send" button on a screen provided, a "send" step 210 is initiated.

A credit-rating filter 212 provides for a screening of the loan requests sent to particular lenders according to a credit-risk score of the borrower and any pre-established credit- risk limits imposed by the lender intended to receive the loan request. Various credit-risk scores can be computer generated by conventional programs used by artisans in the financial industry, e.g., FICO, BEACON, IMPERICA, etc. The credit-rating filter 212 can be fine-tuned over a link 214 to a corresponding lender's database 216. Such fine- tuning is done according to quality control and business management review of past loan requests that have been accepted or rejected by said corresponding lender or accepted or rejected by a broker after an offer to fund by the lender. A step 218 attaches destination addresses and duplicates the loan requests for each appropriate lender. Such addresses are provided by an informational link 220. The loan request records are then forwarded over a data link 222. A transfer 224 causes the loan request to be registered in a submitted queue 226. As far as the broker can see, such loan request exists now only in the submitted queue 226. From the lender's viewpoint, the loan request will exist only in a new application queue 228.

At a lender's site, a loan-request dispatcher 230 will assign the incoming loan requests from several different and independent brokers to an inbox queue 232 of a particular underwriter or loan officer. An underwriter 234 will then act on the loan request. If such action is an offer to fund the loan, terms and conditions are attached and the loan request is transferred to a pipeline-open queue 236. The fact of the favorable action and the offered terms and conditions are communicated over a datalink 238. This forces a transfer of the loan request record at the broker's from the submitted to lenders queue 226 to the broker rate quote (BRQ) queue 240. The offered terms and conditions are appended to the loan request record for the broker's consideration and comparison shopping with any other offers that come in for that particular loan request. If the underwriter 234 decides to refuse the loan request, then the loan request record is transferred to a pipeline-pass queue 242. The lender then waits to see if the broker will accept or reject the lender's offer to fund.

If the broker takes an action 244 to accept, the loan request with an offer to fund in the BRQ queue 240 is moved to a BRQ-accepted queue 246. Such decision is communicated back to the lender over a broker-accepted datalink 248 or a broker- declined datalink 250. A broker-accepted decision communicated on the datalink 248 causes the loan request record to be forwarded from the pipeline-open queue 236 to a pipeline-broker-accepted queue 252. A broker-rejected decision communicated on the datalink 250 causes the loan request record to be forwarded from the pipeline-open queue 236 to a pipeline-broker-declined queue 254. Loan processing can then proceed conventionally.

The process 200 allows lender management and quality control to have a supervisory monitor 256 in which the loan requests and their associated status and details can b e reviewed in real time. If too many loan requests are being passed on, it may indicate that the filter 212 is sert too loose. A fine tuning signal 258 can be sent to adjust the filter 212. If too few loan requests are being accepted by the brokers, the supervisory step 256 can be used to inspect the terms and conditions being imposed by the underwriter 234. The supervisory monitor 256 allows the lender to remain competitive given the realities of the loan requests that exist and their abilities to attract their target clientele.

In reality, all the processing, database accesses, and queue management occurs, for example, at the network server at the business 130 (Fig. 1). The individual brokers and lenders are actually working with remote accesses from terminals that communicate over the Internet. It appears to the broker that they are sending loan requests to the lender locations, and it appear to the lenders that they are receiving the loan requests from the brokers. In fact, both are simply accessing a third site where loan requests are shuffled amongst queues. It is for this reason that no specialized software to support process 200 need be installed or downloaded at any of the broker or lender sites.

Borrowers can be rated as A, A-, B+, B, B-, etc., credit risks. There credit-risks can be evaluated using numeric scores. Borrowers with FICO, IMPERICA, or BEACON numeric scores over 700 are considered very good. Borrowers with scores under 500 are considered poor risks. Lenders will cater to particular ranges credit-risk borrowers. For example, a certain lender may only accept "A" credit rated borrowers. A credit rating filter 212 is used to screen each loan request so that only A-lenders received loan requests from A-borrowers, for example. The "loantrader.com" website compares a profile of the loan request with individual profiles that have been pre-defined by a select group of lenders. The loan request is forwarded by the "loantrader.com" website to each lender's underwriter for which the profile comparison indicates which lender would want to receive the loan request. Each such underwriter makes a decision whether to accept or pass the loan request. Each accepted loan request can be tagged with an electronic data interface (EDI) response transmission fee. The "loantrader.com" website routes the responses back over the Internet to the respective mortgage broker. The broker then reviews the loan request responses from the lenders and selects one lender's response, all others are declined. Each lender is automatically notified via the Internet as their response is accepted or declined by the broker. The "loantrader.com" website notifies a particular lending officer of the acceptance and moves the loan request from the "pending" to the "accepted" queue. The broker is notified of such lending officer's contact information. The lender then processes the loan using traditional methods. The broker next can select title, escrow, and appraisal steps, each with EDI transmission fees.

Although the present invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the present invention should only be limited by the Claims included below.

Claims

1. A queue-oriented loan matching system, comprising: a computer network server connected to service a broker-class of users and a lender-class of users over the Internet; a plurality of computer-implemented queues for database records related to loan requests of borrowers and disposed in the computer network server; a pending queue included in the plurality of computer-implemented queues that lists loan requests that have been entered by a broker in said broker-class of users; a submitted queue included in the plurality of computer-implemented queues that removes loan requests from the pending queue when a corresponding loan request has been forwarded by said broker to a lender in said lender-class of users, and that lists said loan request; an inbox queue included in the plurality of computer-implemented queues that lists loan requests that have been received by a lender in said lender class of users from said broker; an open queue included in the plurality of computer-implemented queues that removes loan requests from the inbox queue when a corresponding loan request has been approved for funding by said lender; a pass queue included in the plurality of computer-implemented queues that removes loan requests from the inbox queue when a corresponding loan request has been rejected for funding by said lender; a broker rate quote (BRQ) queue included in the plurality of computer- implemented queues that removes loan requests from the submitted queue when a corresponding loan request has been approved for funding by said lender; a broker-accepted queue included in the plurality of computer-implemented queues that removes loan requests from the open queue when a corresponding loan request has been approved for funding by said lender and said broker has accepted an offer to fund a loan; and a broker-declined queue included in the plurality of computer-implemented queues that removes loan requests from the open queue when a corresponding loan request has been approved for funding by said lender and said broker has rejected an offer to fund a loan.

2. The queue-oriented loan matching system of claim 1 , wherein: the pending queue is accessible only to a particular broker in said broker-class of users that originally entered any of said loan requests within.

3. The queue-oriented loan matching system of claim 1 , wherein: the submitted queue is accessible only to a particular broker in said broker-class of users that originally entered any of said loan requests within.

4. The queue-oriented loan matching system of claim 1 , wherein: the inbox queue is accessible only to a particular lender in said lender-class of users that was intended by said broker to receive any included loan requests.

5. The queue-oriented loan matching system of claim 1 , wherein: the inbox queue is accessible only to a particular lender in said lender-class of users that was intended by a plurality of independent brokers in said broker-class of users to receive any included loan requests.

6. The queue-oriented loan matching system of claim 1 , wherein: the open queue is accessible only to a particular lender in said lender-class of users that was intended by a plurality of independent brokers in said broker-class of users to receive any included loan requests; wherein only an underwriter associated with said lender is permitted to advance any loan request from the inbox queue to either of the open and pass queues.

7. The queue-oriented loan matching system of claim 1 , wherein: the BRQ queue is accessible only to a particular broker in said broker-class of users that originally entered any of said loan requests within.

8. The queue-oriented loan matching system of claim 1 , wherein: the broker-accepted queue is accessible only to a particular lender that offered to fund any of said loan requests within.

9. The queue-oriented loan matching system of claim 1 , wherein: the broker-declined queue is accessible only to a particular lender that offered to fund any of said loan requests within.

10. The queue-oriented loan matching system of claim 1 , further comprising: a subscription and billing computer included with the computer network server for controlling access of each member of said broker-class and lender-class of users to the matching system according to payment of per-use fees or monthly subscription fees.

11. The queue-oriented loan matching system of claim 1 , further comprising: a credit-rating filter providing for a screening of loan requests sent to particular lenders in the lender-class of users according to a credit-risk score of a corresponding borrower and credit-risk limits imposed by a corresponding lender.

12. The queue-oriented loan matching system of claim 11 , wherein: the credit-rating filter is fine-tuned by said corresponding lender according to quality control and business management review of past loan requests that have been accepted or rejected by said corresponding lender or accepted or rejected by a broker after an offer to fund by the lender.

13. The queue-oriented loan matching system of claim 1 , further comprising: a lender management and quality control monitor in which any loan requests and their associated status and details can be reviewed in real time.

14. The queue-oriented loan matching system of claim 13, further comprising: a credit-rating filter providing for a screening of loan requests sent to particular lenders in the lender-class of users according to a credit-risk score of a corresponding borrower and credit-risk limits imposed by a corresponding lender; and a feedback link between the lender management and quality control monitor and the credit-rating filter that provides for an adjustment of a credit-risk threshold associated with borrowers having loan requests sent to a particular lender.

15. A queue-oriented loan matching system, comprising: a computer network server connected to service a broker-class of users and a lender-class of users over the Internet; a plurality of computer-implemented queues for database records related to loan requests of borrowers and disposed in the computer network server; a pending queue included in the plurality of computer-implemented queues that lists loan requests that have been entered by a broker in said broker-class of users, and that is accessible only to a particular broker in said broker-class of users that originally entered any of said loan requests within; a submitted queue included in the plurality of computer-implemented queues that removes loan requests from the pending queue when a corresponding loan request has been forwarded by said broker to a lender in said lender-class of users, and that lists said loan request, and that is accessible only to a particular broker in said broker-class of users that originally entered any of said loan requests within; an inbox queue included in the plurality of computer-implemented queues that lists loan requests that have been received by a lender in said lender class of users from said broker, and that is accessible only to a particular lender in said lender-class of users that was intended by said broker to receive any included loan requests; an open queue included in the plurality of computer-implemented queues that removes loan requests from the inbox queue when a corresponding loan request has been approved for funding by said lender, and that is accessible only to a particular lender in said lender-class of users that was intended by a plurality of independent brokers in said broker-class of users to receive any included loan requests; a pass queue included in the plurality of computer-implemented queues that removes loan requests from the inbox queue when a corresponding loan request has been rejected for funding by said lender; wherein, only an underwriter associated with said lender is permitted to advance any loan request from the inbox queue to either of the open and pass queues; a broker rate quote (BRQ) queue included in the plurality of computer- implemented queues that removes loan requests from the submitted queue when a corresponding loan request has been approved for funding by said lender, and that is accessible only to a particular broker in said broker-class of users that originally entered any of said loan requests within; a broker-accepted queue included in the plurality of computer-implemented queues that removes loan requests from the open queue when a corresponding loan request has been approved for funding by said lender and said broker has accepted an offer to fund a loan, and that is accessible only to a particular lender that offered to fund any of said loan requests within; a broker-declined queue included in the plurality of computer-implemented queues that removes loan requests from the open queue when a corresponding loan request has been approved for funding by said lender and said broker has rejected an offer to fund a loan, and that is accessible only to a particular lender that offered to fund any of said loan requests within; a subscription and billing computer included with the computer network server for controlling access of each member of said broker-class and lender-class of users to the matching system according to payment of per-use fees or monthly subscription fees; a credit-rating filter providing for a screening of loan requests sent to particular lenders in the lender-class of users according to a credit-risk score of a corresponding borrower and credit-risk limits imposed by a corresponding lender; the credit-rating filter is fine-tuned by said corresponding lender according to quality control and business management review of past loan requests that have been accepted or rejected by said corresponding lender or accepted or rejected by a broker after an offer to fund by the lender; a lender management and quality control monitor in which any loan requests and their associated status and details can be reviewed in real time; and a feedback link between the lender management and quality control monitor and the credit-rating filter that provides for an adjustment of a credit-risk threshold associated with borrowers having loan requests sent to a particular lender.