WO2001080123A1 - Online credit services brokering - Google Patents

Online credit services brokering Download PDF

Info

Publication number
WO2001080123A1
WO2001080123A1 PCT/US2001/011668 US0111668W WO0180123A1 WO 2001080123 A1 WO2001080123 A1 WO 2001080123A1 US 0111668 W US0111668 W US 0111668W WO 0180123 A1 WO0180123 A1 WO 0180123A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
credit
applicant
application
data
computer
Prior art date
Application number
PCT/US2001/011668
Other languages
French (fr)
Inventor
Mirza Mohsin Beg
David Daniel Grossman
Jonathan Marc Meyers
Original Assignee
Livecapital, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance, e.g. risk analysis or pensions

Abstract

An online broker that enables an applicant to apply online for multiple credit products from multiple credit providers. At pre-determined points in the application process, the application data is subjected to a progressive cumulative filtering. When and if application data passes the filtering, the online broker performs an underwriting evaluation and prepares a list of qualified credit options for the applicant (4). The applicant chooses an option and the online broker sends the application to the provider identified by the chosen credit option (7).

Description

ONLINE CREDIT SERVICES BROKERING

FIELD OF THE INVENTION

This invention relates generally to automated systems for credit approval, and more particularly to an interactive, online credit brokering service.

COPYRIGHT NOTICE/PERMISSION

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright © 1999, LiveCapital.com, All Rights Reserved.

BACKGROUND OF THE INVENTION

Both consumers and businesses apply for credit in the form of loans, lines of credit, credit cards, mortgages, leases, etc. Credit approval is generally based in part on a credit scoring procedure implemented by the lending institution or obtained from a third party that specializes in credit approval systems.

Methods for credit scoring are well known throughout the credit industry, having been developed and applied by several companies for many years. All credit scoring methods rely on application data and credit history data. The credit scoring procedure is based on a model that predicts the likelihood of credit repayment, based on many variables in the credit history (e.g., number of inquiries, average days beyond terms in paying bills, record of prior bankruptcies, tax liens, etc.) Before use, the model is validated by extensive offline statistical testing against a database of prior credit experience.

Automated systems that provide credit scoring are in common use by lending institutions. In the typical loan application process, the applicant provides information to a human loan examiner who inputs the data to a computer program. On command, this program fetches the applicant's credit history from an online credit history database. If the application is for a business loan, the program may also fetch the business' s credit history from a different online credit history database.

Depending on the resulting credit score and the accompanying application information, the loan examiner may approve the loan, reject the loan, or seek more information before making a decision, possibly in collaboration with his manager or a loan committee. Thus, traditional loans may take up to two weeks to be approved.

In recent years, so called "instant credit" has become commonplace in department stores, allowing a consumer to immediately apply for a store credit card. The customer service person accesses the consumer's credit history and then generally approves a store credit card for a limited amount until a full credit evaluation can be performed.

One simple extension of the current automated credit systems lets the applicant directly input the relevant information into a computer, either in the bank or through a remote connection (e.g., via the Internet). Various Internet websites now provide instant credit applications, but these sites simply automate the process of filling in the required information. The approval decision is still made offline by a human. Other websites process an application and provide instant pre-approval (i.e., the likelihood of credit approval) without any manual intervention by a human being. A few websites provide actual instant approval of an online application (i.e., the certainty of credit approval subject only to detection that the application was fraudulent) without requiring a human decision. However, such current online instant credit application systems evaluate the applicant for only a single lending institution and for only a single type of credit, i.e., loan or line of credit but not both.

Brokers that represent multiple credit products and multiple credit providers currently exist in the credit industry. The broker generally performs an initial evaluation of the applicant and decides which ones of the offered credit products and associated lenders are most likely to approve the credit. Early broker systems typically routed a physical application to one or more lenders, either serially or in parallel, for manual processing. Even today although the application may be transmitted electronically to a lender, the processing is usually performed by traditional means.

Few brokers today offer online applications and almost none provide actual approval of an online application. Doing so opens the credit approval process to a host of potential problems including (a) new ways to falsify an application, (b) the difficulty of impartially representing multiple credit providers, (c) the sensitivity of the negative information that a broker is legally required to provide to an unsuccessful applicant, (d) the rapid transmission of the application to the selected lenders, and (e) the tracking of payments for website traffic generation, credit origination, and credit issuance.

A conventional credit application is vulnerable to two well-known forms of fraud: the applicant may claim the identity of someone else, or the application information may be intentionally inaccurate. An online application introduces additional forms of fraud. For example, the applicant may change his input in response to the result of his application, or the applicant may submit multiple applications. In general, fraud is less detectable in an online application because the applicant is not physically present in front of a human credit examiner. Also, fraudulent applications can be automatically cloned and quickly widely distributed through the Internet, and thus can have a much larger and more rapid impact than a fraudulent paper application.

Since each credit provider represented by an online broker may offer multiple credit products, such as operating loans, equipment loans, leases, lines of credit, credit cards, etc., the online broker must evaluate a complicated array of credit criteria to determine the applicant's eligibility for any of the credit options (i.e., the combination of the credit products and the corresponding providers). For example, a provider may offer particular credit products only in certain states, or only in certain ZIP codes, or only to certain types of businesses, etc. Different credit providers may have different underwriting criteria and may use different underwriting processes. Thus, different lenders may reject the application for entirely different reasons.

Lenders also need an electronic way to input their changing product parameters to the online broker while ensuring that the changes are authorized by the lender. Additionally, the applicant must be prevented from fraudulently accepting offers from more than one credit provider. Finally, the broker needs to provide an aura of impartiality. If an application is approved on behalf of more than one lender, then there are issues concerning the order in which the results are displayed to the applicant.

Under the Fair Credit Reporting Act, if a credit application is rejected, the applicant may request the reasons in writing. By using an online application, a person can apply for credit using another name, not for the purpose of fraudulently obtaining credit, but rather for the purpose of trying to learn private information about the other person (e.g., an ex-spouse or a movie star). Thus, the applicant may be lying about his identity in order to elicit written, derogatory financial information about the target person.

Although an online broker must be able to rapidly submit the application to the lender, most lenders are not willing to provide a broker with the ability to input data directly into the lender's system for security reasons. Instead, fax (facsimile transmission) or encrypted email (electronic mail) is a commonplace means of sending data. Once the document has been received, the data must be entered by the lender into the lender's system.

Each credit provider has a work-flow management process that keeps track of the stages of processing of an application. Most of this bookkeeping data is unavailable to a broker. Nevertheless, the broker needs a means of tracking these processes, because payment of the broker's fees depends upon them. For example, the broker needs to know that credit has been funded in order to be able to invoice the lender for the relevant fees.

None of the current brokering systems solves all the new and complex problems that result from extending existing automated credit systems into an online environment. Therefore, there is a need for a direct, online brokering system that supplies an impartial selection of different credit products to the applicant and allows for actual, instant approval of the application while securing the credit process and the financial information upon which it relies. Such a system should also permit electronic data exchange between the broker and associated lenders to simplify data entry for the lenders and to automate the necessary bookkeeping tasks for the broker.

SUMMARY OF THE INVENTION

The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification.

An online broker offering multiple credit products from multiple credit providers collects application data from an applicant through a computer network. The data is received in one or more parts, and the broker performs a progressive cumulative filtering at predetermined points as these parts are received. If the progressive cumulative filtering determines the applicant is ineligible for all of the credit products offered, or the data indicates the likelihood of a fraudulent application, the online broker sends a rejection message as soon as the data is evaluated and terminates the application process without collecting any further data. Assuming the applicant is not filtered out, the online broker performs a credit evaluation on the application and prepares a list of credit options (i.e., credit product and associated credit provider) for which the applicant is qualified. The applicant chooses an option and the online broker uses an electronic connection with the provider identified by the chosen credit option to send the application to the provider.

In one aspect, the applicant is presented with a list of unconditionally approved credit products from which to choose. In another aspect in which the list contains conditionally approved credit products, the provider of the chosen credit product may require additional information from the applicant. In those instances when it is able to do so, the online broker collects the additional information and re-evaluates the applicant accordingly. The chosen credit option is removed from the list if the applicant is rejected as a result. In this case, the applicant is then given the opportunity to choose another credit option if there are still qualified credit options on the list.

In yet another aspect of the invention, a subsequent application from the same applicant can be blocked for a period of time. The time period is dependent upon the status of the previous application and may be dictated by the credit option chosen for the previous application.

Because the applicant is presented with a list of all credit options for which he or she is qualified, the present invention allows the applicant to determine which of the types of available credit and which credit providers are most acceptable, allowing credit fungibility for the applicant. The online broker can provide the applicant with both unconditionally approved and conditionally approved credit options from which to choose. When the broker and the credit provider are linked through a computer network, the broker can quickly transmit the application to the provider and can also receive accounting data through the same link. Furthermore, because the online broker filters the application data and promptly rejects the during the data collection phase, the applicant is not sending sensitive data unnecessarily through the computer network. The filtering process also analyzes the application data for fraud indicators, thus reducing the chances that a fraudulent online application is submitted to a lender.

The present invention describes systems, clients, servers, methods, and computer- readable media of varying scope. In addition to the aspects and advantages of the present invention described in this summary, further aspects and advantages of the invention will become apparent by reference to the drawings and by reading the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of one embodiment of an operating environment suitable for practicing the present invention;

FIG. 2 is a diagram of one embodiment of a computer system suitable for use in the operating environment of FIG. 1;

FIG. 3 A is an overview diagram of networked client and server computers for practicing one embodiment of the invention;

FIG. 3B is a diagram illustrating a sequence of messages exchanged among the client and server computers shown in FIG. 3 A;

FIG. 3C is a diagram illustrating one embodiment of a server computer for an online broker.

FIG. 4 is a flowchart of one embodiment of a credit approval method to be performed by the server computer shown in FIG. 3C;

FIG. 5 is a flowchart of one embodiment of a company identification method used in conjunction with the method of FIG. 4;

FIG. 6 is a flow chart of one embodiment of blocking method used in conjunction with the method of FIG.4;

FIG. 7 is a flow chart of one embodiment of a filtering method used in conjunction with the method of FIG. 4;

FIG. 8 is a flow chart of one embodiment of a credit evaluation method used in conjunction with the method of FIG. 4;

FIG. 9 A illustrates an overview of one embodiment of the process of the database search method used in conjunction with FIG. 5;

FIG. 9B illustrates one embodiment of pre-processing data in the database for the search of FIG. 9A; FIG. 9C illustrates one embodiment of a search executed in the database of FIG. 9A;

FIG. 9D-E illustrate one embodiment of the process of scoring the results of the database search of FIG. 9 A;

FIG. 10 is a diagram of an application data structure for use in an implementation of the invention; and

FIG. 11 is a diagram of a provider underwriting criteria data structure for use in an implementation of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of embodiments of the invention, reference is made to the accompanying drawings in which like references indicate similar elements, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical, functional and other changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.

The detailed description is divided into five sections. In the first section, the hardware and the operating environment in conjunction with which embodiments of the invention may be practiced are described. In the second section, an operational overview of the invention is presented. In the third section, methods for an embodiment of the invention are provided. In the fourth section, data structures for a particular implementation of the invention are described. Finally, in the fifth section, a conclusion of the detailed description is provided.

Operating Environment

The following description of FIGs. 1 and 2 is intended to provide an overview of computer hardware and other operating components suitable for implementing the invention, but is not intended to limit the applicable environments. One of skill in the art will immediately appreciate that the invention can be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.

FIG. 1 shows several computer systems that are coupled together through a network 103, such as the Internet. The term "Internet" as used herein refers to a network of networks which uses certain protocols, such as the TCP/IP protocol, and possibly other protocols such as the hypertext transfer protocol (HTTP) for hypertext markup language (HTML) documents that make up the World Wide Web (web). The physical connections of the Internet and the protocols and communication procedures of the Internet are well known to those of skill in the art. Access to the Internet 103 is typically provided by Internet service providers (ISP), such as the ISPs 105 and 107. Users on client systems, such as client computer systems 121, 125, 135, and 137 obtain access to the Internet through the Internet service providers, such as ISPs 105 and 107. Access to the Internet allows users of the client computer systems to exchange information, receive and send e-mails, and view documents, such as documents which have been prepared in the HTML format. These documents are often provided by web servers, such as web server 109 which is considered to be "on" the Internet. Often these web servers are provided by the ISPs, such as ISP 105, although a computer system can be set up and connected to the Internet without that system being also an ISP as is well known in the art.

The web server 109 is typically at least one computer system which operates as a server computer system and is configured to operate with the protocols of the World Wide Web and is coupled to the Internet. Optionally, the web server 109 can be part of an ISP which provides access to the Internet for client systems. The web server 109 is shown coupled to the server computer system 111 which itself is coupled to web content 110, which can be considered a form of a media database or file system. It will be appreciated that while two computer systems 109 and 111 are shown in FIG. 2, the web server system 109 and the server computer system 111 can be one computer system having different software components providing the web server functionality and the server functionality provided by the server computer system 111 which will be described further below.

Client computer systems 121, 125, 135, and 137 can each, with the appropriate web browsing software, view HTML pages provided by the web server 109. The ISP 105 provides Internet connectivity to the client computer system 121 through the modem interface 123 which can be considered part of the client computer system 121. The client computer system can be a personal computer system, a network computer, a Web TV system, hand-held device, or other such computer system. Similarly, the ISP 107 provides Internet connectivity for client systems 125, 135, and 137, although as shown in FIG. 1, the connections are not the same for these three computer systems. Client computer system 125 is coupled through a modem interface 127 while client computer systems 135 and 137 are part of a LAN. While FIG. 1 shows the interfaces 123 and 127 as generically as a "modem," it will be appreciated that each of these interfaces can be an analog modem, ISDN modem, cable modem, satellite transmission interface (e.g. "Direct PC"), or other interfaces for coupling a computer system to other computer systems. Client computer systems 135 and 137 are coupled to a LAN bus 133 through network interfaces 139 and 141, which can be Ethernet network or other network interfaces. The LAN bus 133 is also coupled to a gateway computer system 131 which can provide firewall and other Internet related services for the local area network. This gateway computer system 131 is coupled to the ISP 107 to provide Internet connectivity to the client computer systems 135 and 137. The gateway computer system 131 can be a conventional server computer system. Also, the web server system 109 can be a conventional server computer system.

Alternatively, as is well-known, a server computer system 143 can be directly coupled to the LAN bus 133 through a network interface 145 to provide files 147 and other services to the clients 135, 137, without the need to connect to the Internet through the gateway system 131.

FIG. 2 shows one example of a conventional computer system that can be used as a client computer system or a server computer system or as a web server system. It will also be appreciated that such a computer system can be used to perform many of the functions of an Internet service provider, such as ISP 105. The computer system 201 interfaces to external systems through the modem or network interface 203. It will be appreciated that the modem or network interface 203 can be considered to be part of the computer system 201. This interface 203 can be an analog modem, ISDN modem, cable modem, token ring interface, satellite transmission interface (e.g. "Direct PC"), frame relay, or another interface for coupling a computer system to other computer systems. The computer system 201 includes a processor 205, which can be a conventional microprocessor such as an Intel Pentium microprocessor or Motorola Power PC microprocessor. Memory 209 is coupled to the processor 205 by a bus 207. Memory 209 can be dynamic random access memory (DRAM) and can also include static RAM (SRAM). The bus 207 couples the processor 205 to the memory 209 and also to nonvolatile storage 215 and to display controller 211 and to the input/output (I/O) controller 217. The display controller 211 controls in the conventional manner a display on a display device 213 which can be a cathode ray tube (CRT) or liquid crystal display. The input/output devices 219 can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. The display controller 211 and the I/O controller 217 can be implemented with conventional well known technology. A digital image input device 221 can be a digital camera which is coupled to an I/O controller 217 in order to allow images from the digital camera to be input into the computer system 201. The non- volatile storage 215 is often a magnetic hard disk, an optical disk, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory 209 during execution of software in the computer system 201. One of skill in the art will immediately recognize that the term "computer-readable medium" includes any type of storage device that is accessible by the processor 205.

It will be appreciated that the computer system 201 is one example of many possible computer systems which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be considered to be a peripheral bus. Network computers are another type of computer system that can be used with the present invention. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 209 for execution by the processor 205. A Web TV system, which is known in the art, is also considered to be a computer system according to the present invention, but it may lack some of the features shown in FIG. 2, such as certain input or output devices. A typical computer system will usually include at least a processor, memory, and a bus coupling the memory to the processor.

It will also be appreciated that the computer system 201 is controlled by operating system software which includes a file management system, such as a disk operating system, which is part of the operating system software. One example of an operating system software with its associated file management system software is the operating system known as Windows '95® from Microsoft Corporation of Redmond, Washington, and its associated file management system. The file management system is typically stored in the non- volatile storage 215 and causes the processor 205 to execute the various acts required by the operating system to input and output data and to store data in memory, including storing files on the non- volatile storage 215.

Operational Overview

An overview of the operation of an embodiment of the invention in the environment illustrated in FIGs. 1 and 2 is described by reference to FIGs. 3A-C. FIG. 3 A illustrates a public wide area network 301, such as the Internet, through which a client computer for a credit applicant 303 can connect to a server computer for an online broker 305. The online broker server 305 is connected to server computers for credit providers A 307 and B 309 represented by the online broker, and to credit bureaus A 311 and B 313 through private networks 315. Messages containing various types of data are transmitted between the client computer for applicant 303 and the server computer for the online broker 305 using any of the protocols supported by the underlying public area network 301. Similarly, messages are transmitted between the server computer for the online broker 305 and server computers for the credit providers A 307, B 309, and credit bureaus A 311 and B 313, using a protocol appropriate for the corresponding underlying private network 315. Depending on the protocol, the messages can be transmitted as a single data packet, multiple data packets, or as a data stream.

FIG. 3B illustrates a sequence of such messages exchanged between the client for the applicant 303 and the server for the online broker 305 to perform the online credit approval process of the invention.

The online credit approval process begins when applicant 303 submits message 1 containing application data to the broker 305. While illustrated and described in this section in terms of a single message containing the application data for ease of explanation, the credit approval process encompasses the use of multiple application data messages corresponding to portions of the application data, such as the pages of a credit application, as explained in the next section.

The broker 305 requests and receives the applicant's 303 credit history from the online credit history databases maintained by credit bureau A 311 in message 2. The broker 305 uses an automated credit scoring system to calculate a credit score for the applicant 303 (or obtains the credit score from one of the credit bureaus A 311 or B 313) and then performs an underwriting evaluation process that compares the applicant's characteristics against the underwriting criteria for the credit options offered by the broker, i.e., all of the credit products from the credit providers A 307 and B 309 in FIG. 3B. In this local underwriting process, the broker effectively is bidding on behalf of the credit providers. As an alternative, the broker may send the applications directly to the credit providers for their remote underwriting decisions. In this case, however, privacy is reduced because applicant information is put into many hands. Additionally, any provider that rejects the application is legally responsible for providing the applicant with adverse action reasons. Also, there are costs to replicate credit reports. For these reasons, if remote underwriting is used, the applicant data should be made anonymous, by removing identifying information such as name, Social Security Number, Federal Tax Id, etc.

A rejection message 3 (shown in phantom) is returned if the applicant 303 does not qualify for any of the credit options offered through the broker 305. For example, the applicant may have a poor credit score or may reside in a state not serviced by any of the credit providers represented by the broker 305. An application may also be rejected because the applicant has submitted more than one application within a certain time period or because the application appears fraudulent, as explained in detail in the next section.

When multiple application data messages are used, the message ordering is slightly different. The broker 305 performs a progressive cumulative filtering process upon receipt of one or more pre-determined messages (illustrated as message 1) by comparing the application data cumulatively received against a subset of the underwriting criteria. The broker 305 returns the rejection message 3 as soon as the progressive cumulative filtering determines that the applicant 303 cannot qualify for any of the credit options offered, or immediately when a prior blocking application exists or upon detecting fraud in the application. Once all the application data is received and the progressive cumulative filtering has not rejected the applicant 303, the credit history is fetched (message 2) and the underwriting evaluation is performed.

If the underwriting evaluation determines that the applicant 303 qualifies for at least one of the offered credit options, the broker 305 responds with a message 4 containing a list of options from which the applicant 303 can choose; otherwise, the rejection message 3 is returned. The applicant 303 returns its choice in message 5. The broker 305 next determines if the chosen option requires additional information about the applicant 303 and if so, can optionally request and receive the additional information from the applicant (also illustrated as message 1) for local decisioning or for forwarding to the lender for remote decisioning.

If no additional information is required or collected, or the evaluation of the additional data does not disqualify the applicant 303, the broker 305 sends a status message 6 to the applicant. The broker 305 also sends all the data required by the chosen lender, e.g. credit history, to the lender in message 7. It will be appreciated that the broker 305 can also be viewed as an agent for the applicant 303 when it submits the data to the chosen lender.

If the applicant 303 is disqualified by the additional data collected by the broker 305, the broker 305 sends a revised list of credit options (also illustrated as message 4), assuming there is at least one option remaining. The broker 305 continues presenting credit options to the applicant 303 until the applicant 303 is approved (conditionally or unconditionally) for the chosen credit option or no credit options remain for which the applicant qualifies.

FIG. 3C illustrates logic modules and databases used in one embodiment of the computer server for an online broker. The server 305 communicates to the applicant 303 through an applicant interface 321. The applicant interface 321 sends an interactive application form to the applicant and receives the application data corresponding to message 1 of FIG. 3B from the applicant 303. The application data is transferred to the credit approval logic 323 for evaluation when it is received by the applicant interface 321.

The credit approval logic 323 calls blocking logic 325 to determine if the application should be blocked because of a previous application or because of potential fraud. Certain portions of the application data may trigger fraud evaluation, while other portions trigger past activity evaluation. The blocking logic 325 searches an application database 327 for a record for the applicant. If a record is found that indicates the applicant had submitted a previous application, the current applicant may be blocked for a period of time specified in the record. The blocking logic 325 also performs fraud analysis on the application data. When the blocking logic 325 indicates that the application is to be blocked, the credit approval logic 323 returns rejection message 3 to the applicant 303 through the applicant interface 321. If a corresponding record is not found, one is created in the database 327 for the applicant.

Assuming the application is not blocked, the credit approval logic 323 calls filtering logic 329 at certain points in the process to determine if the application data collected up to this point disqualifies the applicant from all of the credit options offered by the broker, i.e., the progressive cumulative filtering. The filtering logic 329 refers to a subset of the underwriting criteria for the credit options stored in a provider underwriting criteria database 337 that corresponds to the application data received. If the applicant 303 does not qualify for at least one of the credit options, the rejection message 3 is returned.

If the applicant is rejected by the broker, the applicant interface 321 presents the applicant with a form to fill out to request a written explanation. If such a request is received, the broker provides this written explanation ("adverse action" letter), which can be delivered through email or regular surface mail.

When the application is for business credit, the credit evaluation logic 335 calls company identifier logic 331 to search a company information database 333 for a matching company name as described in the next section. The company information database 333 can be local or remote to the broker.

Once all the application data has been received through the applicant interface 321, the credit approval logic 323 calls credit evaluation logic 335 to perform the underwriting evaluation that determines for which credit options the applicant is qualified. The credit approval logic 323 obtains the applicant's credit history from credit bureau 311 and determines a credit score for the applicant 303 based on the credit history. In one embodiment, the credit approval logic 323 uses an online credit scoring application to create a credit score for the applicant 303. In an alternate embodiment, the credit approval logic obtains a credit score from the credit bureau 311 that provides the credit history or from a different credit bureau. It will be appreciated that the credit approval logic may obtain more than one type of credit history for an application, e.g., a personal and a business credit history, and also calculate or obtain more than one type of credit score, e.g., an applicant score, a business score, a combined applicant-business score, a credit score for a specific credit product or for a specific credit provider. The application data for the applicant 303 is then compared against the underwriting criteria for all the credit options to create a list of qualified credit options, which the credit evaluation logic 335 passes back to the credit approval logic 323 for presentation to the applicant 303 in message 4.

The applicant's choice of credit option in message 5 is received by the application interface 321 and forwarded to the credit approval logic 323. Any additional information that is collected is passed through the application interface 321 for evaluation by the credit evaluation logic 335 or for transfer to the chosen credit provider 307 through a provider interface 339. Any additional information that is collected may eliminate the chosen credit option, at which point the credit evaluation logic 335 revises the list of credit options for re-presentation to the applicant 303. The provider interface 339 can send the information to the provider 307 through encrypted email, fax, or other electronic means.

Once the applicant 303 has been approved (either conditionally or unconditionally) for the chosen credit option, the credit approval logic sends the status message 6 to the applicant 303 through the applicant interface 321 and submits the application in message 7 to the chosen credit provider 307 through the provider interface 339. The credit approval logic 323 also updates a blocking period in the applicant's record in the application database 327 as described in the next section. Assuming the provider 307 requires a signed, physical contract, the provider sends a contract to the applicant 303. Normally this process will involve the non- automated process of a credit examiner reading the credit information and possibly performing additional diligence. The applicant 303 then reads the contract, completes it, signs it, and returns the executed contract to the provider 307. Once the contract is signed, the provider 307 provides the money to the applicant 303 through a conventional mechanism, such as automated fund transfer.

Each provider 307 periodically provides through the provider interface 339 accounting and other information to the broker 305 regarding which applications were successfully completed and funded. On the basis of this information, the broker 305 derives a payment from that lender.

The provider interface 339 is also used to collect data for the provider underwriting criteria database 337. Each provider 307 sends its credit product description and all or a portion of its underwriting criteria to broker 305. The broker stores them in the database 337 and echoes the data back to provider, which then sends confirmation or corrections.

Similarly, when the company information database 333 is local, the broker obtains the name list from one or more credit bureaus and stores it in the database 333.

The system level overview of the operation of an embodiment of the invention has been described in this section of the detailed description. An online broker system collects and evaluates data from an applicant against multiple credit options offered by the broker, and returns a list of credit options for which the applicant qualifies. The applicant chooses a particular credit product and the broker forwards the application data to the associated credit provider. When the application data is made up of several parts, the broker system performs a cumulative progressive filtering at predetermine points in the application process, and rejects the applicant as soon as the application data cumulatively received disqualifies the applicant from all of the multiple credit options. Additional data may be required for the chosen credit option and if the additional data is collected and it disqualifies the applicant from the chosen credit option, the applicant can chose a different credit option from the list.

While the invention is not limited to any particular arrangement of software logic modules, one embodiment of modules that perform the processes of the invention has been described. Furthermore, it will be appreciated that the type and order of the messages exchanged between the participants, and the order in which the applicant data is processed can vary from that presented herein without exceeding the scope of the invention.

Methods of Embodiments of the Invention

In the previous section, a system level overview of the operations of embodiments of the invention was described. In this section, the particular methods of the invention are described in terms of computer software with reference to a series of flowcharts in FIGs. 4-9E.

The methods to be performed by a server computer for the online broker 305 in FIGs. 3A-C constitute computer programs made up of computer-executable instructions. Describing the methods by reference to a flowchart enables one skilled in the art to develop such programs including such instructions to carry out the methods on suitably configured computers (the processor of the computer executing the instructions from computer-readable media). If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and for interface to a variety of operating systems. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, module, logic...), as taking an action or causing a result. Such expressions are merely a shorthand way of saying that execution of the software by a computer causes the processor of the computer to perform an action or to produce a result.

FIG. 4 illustrates one embodiment of a credit approval method, while FIGs. 5-9E provide additional details for some of the processes performed by the credit approval method in evaluating a credit application.

Referring first to FIG. 4, the acts to be performed by an online broker server computer executing one embodiment of a credit approval method 400 are shown. The credit approval method 400 is divided into two phases: a data collection phase and a data evaluation phase. The data collection phase sends one or more portions of the application as screens to the applicant's client computer, such as client computer 303 in FIGs. 3 A-C. In one embodiment, the application screens correspond to the pages on a physical credit application. The applicant fills in the information requested on each screen, such as:

Characteristics of desired credit (e.g., amount, intended purpose);

Company information if the credit is for a business (e.g., company name and address, industry, federal tax id number, fax number, checking account balance, years in business, annual sales);

Consumer information (e.g., name and address, email address, home and work phone number, Social Security number, annual income, personal worth, email, phone).

If the credit is for a business, the applicant would be the business owner (or an officer of a corporation), and the information might include other owner information such as years as an owner, percent ownership, optional contact name if different from owner, etc.

As each screen is filled in by the applicant, it is returned to the broker's server where it is checked for accuracy. For example, phone numbers must have 9 or 10 digits, Social Security numbers must have 9 digits,, checking account balances cannot be under $1 or over $1 million, email addresses must have an @ symbol and a period, etc. (block 401). If detailed Standard Industrial Classification (SIC) information is essential but the applicant does not input its SIC code, the broker's server can return a list of SIC codes to the applicant. Because the entire list of SIC codes is very lengthy, in one embodiment the applicant describes the business in the context of a natural language sentence and the words in this description are used as weighted search keywords into an inverted list of SIC codes and meanings. Other embodiments incorporating different SIC designation mechanisms will be immediately apparent to one of skill in the art and are within the scope of the invention.

The screen is returned to the client computer for correction, if necessary. When the screen contains a company name, the method 400 performs a company identification method, described in conjunction with FIG. 5 below, to verify the existence and identity of the company.

After the error check is completed for each screen, the method 400 determines whether a past activity analysis should be performed on the application data (block 403). In one embodiment, an application can be blocked because the applicant has previously applied for, or been approved for, credit within a pre-determined time period. If sufficient data has not yet been received to perform the past activity analysis or the applicant's past activity does not block the application (block 404), the method 400 determines whether a fraud analysis should be performed on the application data (block 405). In one embodiment, an application that is likely to be fraudulent is also blocked (block 406). If the application is blocked by either analysis, the method 400 terminates with a rejection message to the applicant (block 425). In an alternate embodiment, an application that is found to be potentially fraudulent is not rejected but instead is flagged as a questionable application for later analysis. A detailed flowchart illustrating an embodiment of a blocking method that performs both the past activity and fraud analysis is shown in FIG. 6 and described in more detail below.

If the application is not blocked or is not sufficient for either analysis, the method 400 determines if the progressive cumulative filtering should be performed on the cumulatively received application data (block 407). If so, the data is evaluated against a subset of the full underwriting criteria to determine if the applicant qualifies for any of the offered credit options, i.e., any credit product from any of the credit providers represented by the online broker. If there are no credit options for which the applicant is qualified (block 408), the credit approval method 400 terminates with a rejection message to the applicant. One embodiment of a filtering method is illustrated in FIG. 7 and described further below.

Assuming the applicant qualifies for at least one credit option at block 408 and the application is not complete (block 409), another screen is sent to the applicant at block 401 to obtain more data. The data collection phase represented by blocks 401 through 409 is repeated until either the applicant is rejected, or all the application data has been received and the applicant can qualify for at least one credit option. In an alternate embodiment (not shown), the last screen sent to the application is a legal agreement that must be accepted before the data evaluation phase can begin. If the legal agreement is not accepted, the method 400 terminates with a rejection message to the applicant.

It is important that a rejection message appears promptly during the data collection phase, so that the applicant does not submit a lot of additional private information that is irrelevant. Any time an applicant is rejected by the credit approval method 400, the applicant is entitled by law to an explanation of the reason(s) for the rejection. In one embodiment, the rejection message sent to the applicant at block 425 includes a form that that the applicant prints out and returns to the broker to trigger an offline "adverse action" letter.

Once all the application data has been collected, at least one credit history is fetched, the applicant is given at least one credit score, and the application is compared against all the underwriting criteria specified by the credit providers (block 411). The application can be evaluated against conditionally or unconditionally approved credit options, or against a mixture of the two. If the applicant qualifies for at least one credit product with a category of approved, then the application is approved. If the applicant qualifies for at least one credit product with a category of conditionally approved, then the application is conditionally approved. A given application can be approved, or conditionally approved, or both. One embodiment of the credit evaluation method represented by block 411 is described below in conjunction with FIG. 8.

If the credit evaluation indicates that the application is either conditionally or unconditionally approved (block 413), a list of qualified credit products and the associated lenders is presented to the applicant (block 415). Otherwise, the method 400 terminates with a rejection to the applicant. In one embodiment, the processing represented by block 415 includes "pruning" the list to narrow the choices. The pruning can be random or systematic. If systematic, it may be based, for example, on the comparative demographics of the credit providers (e.g., which is the largest), on prior broker experience (e.g., which is most likely to be chosen), on economics (e.g., which maximizes the expected fee gained by the broker), or on a combination of these and other factors. One of skill in the art will immediately appreciate that the pruning criteria can include many different elements without departing from the scope of the invention.

The method 400 waits to receive a choice of credit option from the applicant (block 417). In one embodiment, if no choice is made before a pre-determined time limit, the method 400 terminates. In an alternate embodiment, the applicant is also given the choice of suspending the decision for a certain time period. If that choice is made, the status of the application is saved and the applicant can resume the process during the time period. If the decision is not made within the time period, the application is considered void.

When a choice is made, the method 400 determines if the chosen option requires additional data (block 419). The additional information may be required because the applicant has chosen a conditionally approved credit option. For example, assume the applicant chose a conditionally approved SBA (Small Business Administration) loan and thus needs to answer questions specific to SBA loans. Also, to the extent that even approved options are conditional on the absence of fraud, there may be additional questions and screening for approved credit options. For example, a lender might have its own online list of fraudulent social security numbers. Additionally, the rates and fees for an approved option might depend on whether or not the applicant is already a client of that lender. In some instances, the additional data may be tax-related and is retrieved from a public data base of tax records. The collection and evaluation of the additional information proceeds as directed by the requirements and limitations of the chosen credit provider.

When the method 400 can evaluate the additional data online, it obtains the data from the applicant and applies additional underwriting criteria specified by the particular lender (block 429). For a conditional approval credit product, the credit approval method 400 determines if the applicant can be unconditionally approved or rejected for the chosen credit product based on the additional information, and marks the application accordingly. Otherwise, the application continues to be marked as conditionally approved. The lender's particular fraud checks are carried out at block 429 for both approved and conditionally approved credit products. A negative result from the fraud check results in the application being marked as rejected.

If the applicant is approved, either conditionally or unconditionally, for the credit option (block 431), the method 400 submits data regarding the application to the provider as described below (block 421). Otherwise, the credit product is removed from the list (block 433). If the list is empty (block 435), the application is marked as rejected (block 437), a rejection message is sent to the applicant (block 425), and the method 400 terminates. If the applicant still qualifies for at least one credit product at block 435, the method 400 continues the data evaluation phase at block 415. It will be appreciated that the number of times an applicant is allowed to chose from the list may be limited.

Alternatively, the broker collects the additional information at block 429 but skips the evaluation process represented by block 429. The applicant is still considered qualified for the credit product, so the credit approval method 400 continues onto block 421, where the credit method 400 forwards the additional information to the lender for decision making. In still another embodiment, the credit approval method 400 treats the credit option as if there were no additional information required at block 419, passes the application data to the lender at block 421, and the lender then contacts the applicant with the additional questions. In this case, the method 400 indicates to the applicant that the application must be directly evaluated by the lender at block 425.

The collected information required for the chosen credit option is submitted to the associated lender (block 421). In one embodiment, all the information collected is transmitted to the associated lender as an encrypted email to the lender through a network connection between the broker's server and the lender's server as illustrated in FIGs. 3A-C above. In an alternate embodiment, the broker's server generates and sends a fax to the lender that contains the information. It will be readily understood that other transmission medium can be substituted without exceeding the scope of the invention.

In yet another embodiment, the type of information submitted varies based on the type of credit product and the provider. For example, if the applicant has chosen an approved credit option, or if a conditionally approved option is converted to unconditionally approved at block 429, the information transmitted to the lender specifies that this is a signup for an approved option and includes the application data, the credit history(ies) and credit score(s), and any fraud indicators. If the applicant chooses a conditionally approved credit option that cannot be approved online, the incomplete information from the basic application, plus any additional information obtained at block 429, is submitted through the transmission medium between the broker and the lender. After the method 400 sends the appropriate application status message (approved, conditionally approved, rejected, etc.) to the applicant at block 425, it performs certain bookkeeping procedures (block 427) before exiting. In one embodiment, the bookkeeping procedure records the identifier for the website that delivered the applicant to the broker, all application data, decision data, and credit choices presented to the applicant, and data regarding the applicant's interaction with the broker's server (e.g., date, pages accessed, applicant's network address, applicant's browser type, applicant's operating system, etc.). In a further embodiment, the bookkeeping data is used to provide the application with an online status of the credit process.

Turning now to the details of the credit approval method 400, FIG. 5 illustrates one embodiment of a company identification method 500 used in the data collection phase of FIG. 4. While previously described as part of the processing represented by block 401 in FIG. 4, one of skill in the art will readily recognize that the company identification method 500 can be deployed at any time after a company name has been received by the broker server as part of the credit application. The company identification method 500 uses the company name as a search key to locate similar names in a company database (block 501). A list is created from all company names that match the search key to a pre-determined degree and presented to the applicant (block 505). Assuming the correct company name appears on the list, the applicant will choose it (block 507) and that name is returned to the credit approval method 400 (block 509).

If no matching names are found (block 503) or the applicant does not choose one of the names on the list, the applicant can assert that the company name submitted on the application is correct (block 511) and the asserted name is returned to the credit approval method 400 (block 513). If the company name submitted on the application is in error, the applicant can correct the error and the company identification method 500 will use the corrected data (block 515) to perform another search. While it will be appreciated that the invention is not limited to a particular search methodology, a particular embodiment of the company name database search is described in conjunction with FIGS. 9A-E further below. Furthermore, one of skill in the art will immediately recognize that the broker's server can also call an external search procedure that returns its results to the company identification method 500 for further processing. FIG. 6 illustrates one embodiment of a blocking method 600 that prevents an application from being processed because of potential fraud or because the broker system had recently processed a previous application from the same applicant. When the credit approval method 400 illustrated in FIG. 4 calls the blocking method 600 during the data collection phase, the blocking method determines if it is to perform a fraud analysis on the application data (block 601). If so, various fraud criteria are used to determine if the application is likely to be fraudulent (block 602). If the analysis indicates potential fraud (block 603), the application is marked as blocked (block 611), which causes the credit approval method 400 to return a rejected message to the applicant.

Conventional fraud detectors are used at block 602, e.g., lists of social security numbers of dead people, name address mismatch, etc., along with a unique series of counters developed to detect online fraudulent activity by tracking certain patterns of input as described in U.S. Patent application Serial No. 09/299,384, titled SYSTEM AND METHOD FOR REDUCING FRAUD IN ONLINE FINANCIAL APPLICATIONS, filed on April 27, 1999 and assigned to the assignee of the present application. One such a counter records the number of times an applicant changes data in a certain field or fields during a given online "session." For example, if the user said his checking account balance was $100 and then changed it to $10,000, this would count as one change. A large number of changes is an indication that the applicant is making up numbers. Another sign of potential online fraud is the number of times identical identity information appears in recent multiple sessions, such as a social security number or a federal tax identification number.

If the credit approval method 400 has called the blocking method 600 to perform a past activity analysis, the application database is searched using an unique identifier for the applicant (block 605). If no record is found (block 607), one is created for the applicant (block 613) and the application is allowed to proceed (block 615).

When using the blocking method 600, the credit analysis method 400 updates the application database when the list of qualified credit options is presented to an applicant at block 415 in FIG. 4 and also when application information is submitted to a lender at block 425. Thus, when the application database search at block 605 returns an existing record, the blocking method 600 determines if the blocking period stored in the record has expired (block 610). If it has, or if there is no blocking period specified, the processing of the current application is allowed to continue (block 615). Otherwise, the current application is blocked (block 611).

In one embodiment, the length of time for which the current application is blocked depends on the status of the previous application. If the application was not completed, a record would be created for the applicant at block 613 but there would be no blocking period specified. If the application was completed and a list of credit options presented to the applicant, a pre-determined default blocking period would be added to the record by the credit approval method 400 at block 415. If the applicant chose a credit product from a provider that required a blocking period different than the default, the associated record would be modified to reflect the required blocking period at block 425. In one embodiment, an application that was completed but rejected would set a blocking period. In an alternate embodiment, a rejected application is not considered in calculating the blocking period.

If a new application is received from the applicant prior to the expiration of the blocking period, the new application will be blocked. In one embodiment, the applicant is told to resubmit the new application at a later date. Alternatively, the data for the new application can be recorded in the application database and given a different blocking period, thus eliminating the need for the applicant to resubmit the data when the blocking period on the blocking application has expired.

As described above, the credit approval method 400 performs progressive cumulative filtering on the application data at pre-determined points during the data collection phase. One embodiment of the filtering process 700 during the data collection phase is illustrated in FIG. 7.

Each completed portion of the application may have specific data corresponding to underwriting criteria specified by each lender for the credit products offered by that provider. When the credit approval method 400 determines that one of the predetermined filtering points has been reached, the filtering process 700 extracts the relevant data from the cumulatively received application data (block 701) and compares the relevant data against a corresponding subset of the underwriting criteria for all the credit options represented by the broker (block 703). If the comparison indicates that the applicant cannot qualify for any of the credit options (block 705), the application is marked as rejected (block 707). For example, if the applicant wants a loan of $200,000, lives in Idaho, and is in the Restaurant business, then it may be that there are no qualified options.

In one embodiment illustrated in FIG. 7, the filtering method 700 collects statistics about the reasons the application is rejected and uses those statistics to determine an optimal ordering for the data on future applications (block 709, shown in phantom). The analysis results in the screens containing the data most likely to cause an application to be rejected to be sent to the applicant early in the application process so that the applicant can be rejected once a minimal amount of data has been collected.

For example, suppose that the first three interactive screens contain the following information: screen 1 : desired amount of credit and purpose of credit; screen 2: state and zip code; screen 3: years in business and type of business.

Each time that an applicant is rejected, the data is analyzed to determine the minimal subsets of known parameters that would have resulted in this rejection. For instance, if rejection occurred at the end of screen 2, then the following subsets are analyzed:

{desired amount of credit, purpose of credit, state, zip code}, i.e., the full set;

{desired amount of credit, purpose of credit, zip code};

{desired amount of credit, purpose of credit, state};

{purpose of credit, state, zip code};

{purpose of credit, zip code};

{purpose of credit, state};

{desired amount of credit, state, zip code};

{desired amount of credit, zip code};

{desired amount of credit, state}; and

{ state, zip code}. (Note that it is not necessary to examine subsets that were contained on screen 1 since in this example there was no rejection because of the subsets on screen 1.) If any of the above subsets resulted in the rejection, then the minimum cardinality of all such rejection subsets is determined. For all rejection subsets with cardinality equal to the minimum value, all member parameters as assigned one "vote". After accumulation of a large number of statistics, the votes are used to reorder the questions and screens. The optimization process continues until a stable state is reached.

It will be appreciated that the statistics collected at block 709 can also be used for other purposes.

In still another embodiment, the filtering process is incremental in that the credit options for which the applicant qualifies as a result of filtering on earlier data are saved and the data from each subsequent screen is used to further winnow down the number of qualified credit options.

FIG. 8 illustrates one embodiment of a credit evaluation method 800 suitable for use at block 411 of the credit approval method 400 in FIG. 4. The credit evaluation method 800 relies on credit histories for the applicant (and business when appropriate) and credit scoring to determine the credit options for which the applicant qualifies.

The method 800 obtains the credit history for the applicant from an external online database, such as those maintained by credit bureaus (block 801). When the online credit history data includes independent data that overlaps data provided by the applicant, a further fraud analysis is performed (block 803). For example, if the application is for business credit, the business' s credit history often includes the industry SIC code. A difference in the value provided by the applicant and that provided by the credit history database is an indication of possible fraud. If the application appears fraudulent or does not qualify for any of the credit options, the application is marked as rejected (block 815). In an alternate embodiment, a fraudulent application is flagged but not rejected.

If there is no indication of fraud (block 805), a credit scoring process is performed on the application data and the credit history data (block 807). The credit scoring process can be performed directly by the broker's server, or can be executed on another computer that returns the results to the broker server. For example, a credit scoring system produced by HNC Software Inc. can be used to analyze the credit history and output a credit score and certain standard fraud indicators, e.g., file variation, name variation, social security number variation, and address variation. The application data, certain pre-determined credit history fields (e.g., SIC code), the credit score, and any fraud indicators are collectively compared to the approval or conditional approval specifications associated with the credit options offered by the various lenders represented by the broker (block 809). For some credit products, the detailed underwriting decision rules are implemented in proprietary systems owned by the separate providers ("proprietary decision"). When those types of products are represented by the broker, one embodiment of the credit evaluation method 800 sends an electronic message to all the relevant lenders at block 809, requesting their proprietary decisions before creating the list of qualified credit options.

Assuming the application is at least conditionally approved, a list of the qualified credit options is created for presentation to the applicant (block 813). The applicant can click a button to obtain further details about any of the credit options in the list. In one embodiment, when an application is approved (and/or conditionally approved) on behalf of more than one provider, the results are ordered within the list based on a sort criteria set by the broker. Some examples of such sort criteria include alphabetical, ascending interest rate, descending credit amount, and/or the chronological sequence in which a proprietary decision was returned to the broker.

When the application is for business credit, the credit histories for both the business and the applicant may be required to determine the credit options. In this case, the credit evaluation method 800 will initially evaluate the application using one of the credit histories and only fetch the other credit history for further evaluation if the initial evaluation produces one or more qualified credit options.

FIG. 9A illustrates an overview of one embodiment of the process of a database search method 900. As described with respect to FIG. 5 the system receives a company identification from a user, and performs a search, returning a list of matches to the applicant (block 505).

The company names database is preprocessed (block 901). This process may occur at any time. This process is described in more detail with respect to FIG. 9B.

The search term received from the user is processed (block 903). The processing is similar to the processing of the database.

The database is searched to match the search term to the processed database contents (block 905). This process is described in more detail with respect to FIG. 9C.

It is determined whether the search returned any candidate matches (block 907). If no results are returned, the process exits to FIG. 5, block 511. This is described above, with respect to FIG. 5. If a result was found, the process continues to block 909.

The candidate matches are scored (block 909). The process of scoring is described with respect to FIGs. 9D and 9E. The scored matches are sorted by score (block 911), and the top scoring results are returned to the system (block 913). Based on the result of the scoring, the set of matches are sorted so that candidate strings are in declining order of score. Finally, a leading subset is returned. For one embodiment, the size of this subset depends on the length of the input search name and on the relative scores of elements of the set. For example, if the highest score were 14.5, then the subset returned might include all names with a score higher than 7.25, up to a maximum number of names equal to 5 plus the number of characters in the input search name. As described with respect to FIG. 5, these top scoring results are returned to the user, who is prompted to select the appropriate result.

FIG. 9B illustrates one embodiment of pre-processing data in the database for the search. For one embodiment, this process is done when the database is initially downloaded. For another embodiment, this process may be done periodically, as the database is updated.

The database is preprocessed (block 915) to contain only the upper case alphanumeric characters (e.g., A-Z and 0-9) and common punctuation characters (e.g., space, period, comma, single quote, double quote, hyphen, ampersand, asterisk, and '@'). It should be noted that the use of a constrained character set for the search does not impose any inherent limitation on the final output, because the final output can revert to a full character set. Designate as N each item in the database minus punctuation and common words. For example, if the name is 'THE ABC SCANDINAVIAN FURNITURE IMPORT CO., INC then N is 'ABC SCANDINAVIAN FURNITURE IMPORT'.

Key "O" is generated by taking the leading characters of each entry N excepting spaces (block 917). For one embodiment, this could be limited to 10 characters. In the example, this would be 'ABCSCANDIN'. Key "P" is the same as "O", with first uncommon word removed (block 919). In the example, this would be 'SCANDiNAVI'.

Key "Q" is the result of converting N into a biased phonetic string (block 921). An example of a phonetic string would be 'BSNDNVNFRNTRMPRT', obtained by deleting the vowels from the example string, considering C and S as equivalent, deleting spaces, and compressing adjacent equivalent letters into a single letter. Alternatively, the Soundex conversion may be used, with the leading character removed, as is known in the art.

For another embodiment, the biased phonetic string may be language specific. For example, 'W in English is phonetically equivalent to 'OO', while in German 'W is pronounced like the English 'V. For another embodiment, the phonetic conversion can be biased towards invariance with respect to spelling errors. The best way to deal with this is by processing characters in pairs and triplets, instead of processing them singly. For instance, in English, 'PH' usually is pronounced as 'F'. Also, 'SH', 'CH', and 'TH' have special phonemes, 'TIO' is pronounced like 'SHA', and 'B' is silent in 'BY. Thus, the phonetic conversion may use character sets instead of individual characters.

The lead characters of leading words of N are converted into a numeric value that is invariant with respect to word permutation, this is designated key "R" (block 923). For practical purposes, this could be based on the first 3 characters of the first 3 words. In the example, these letters would be 'ABC, 'SCA', and 'FUR'. If each letter were then mapped into its alphabetic position (e.g., A=l, B=2, ..., Z=26), then the numeric value obtained by multiplication would be l x 2 x 3 x 22 x 3 x l x 6 x 21 x l8.

There are many pairs of letters whose ordinality products are, say, 24. For example, 'AX' is 1 x 24, *BM' is 2 x 12, 'CH' is 3 x 8, and 'DF' is 4 x 6. For one embodiment, instead of mapping A to Z into the integers 1 to 26, the characters are mapped into the first 26 primes (i.e., 2 to 101). For one embodiment, this mapping orders the letters in ascending frequency of use, because this will lead to smaller multiplicative products, which can then be processed and stored at lower precision.

For another embodiment, the first character of the word is mapped into the first 26 primes, the second character into the next 26 primes, and the third character into the next 26 primes. The effect of this is to make the multiplicative product of the first three characters of the first three words invariant with respect to word order, but not invariant with respect to character order within any word.

FIG. 9B illustrates the generation of four keys — O, P, Q, and R - as well as the original raw search string N. One or more of these keys may be used to search the database.

FIG. 9C illustrates one embodiment of a search executed in the database. For one embodiment, a database search is performed that generates a set that is the union of what would be obtained from separate searches on the five keys N, O, P, Q, and R

The search term is processed similarly to the database processing described above with respect to FIG. 9B. The results of the search term processing are designated N' for the raw search string, O', P', Q', and R' for the various keys. For example, if N' is 'ABIE'S SCANDANAVEN FURN' then O' would be 'ABIESSCAND', P* would be 'SCANDANAVE', and Q' would be 'BSNDNVNFRN*.

The keys N, O, P, and Q are searched for matches on leading characters of N', O', P', and Q'. In one embodiment, there are some parameters, PI through P3, specifying the number of leading characters. Key R is also searched for matches with R'. For one embodiment, a search may be performed on key O with P', and on key P with O', to compensate for the possibility of an omitted word.

In the embodiment the process is:

• PI leading characters of N' are used to search N (block 923), the indexed column of N procedure 2. In the example, with PI =7, this would be 'ABIES S* versus 'ABC SCA' which does not match.

• P2 leading characters of O' are used to search O. In the example, with P2=6, this would be 'ABIESS' versus 'ABCSCA' which does not match.

• P2 leading characters of P' are used to search P. In the example, with P2=6, this would be 'SCANDI' versus 'SCANDA' which does not match.

• P2 leading characters of O' are used to search P. In the example, with P2=6, this would be 'ABIESS' versus 'SCANDA' which does not match.

• P2 leading characters of P' are used to search O (block 925). In the example, with P2=6, this would be 'SCANDI' versus 'ABCSCA' which does not match. • P3 leading characters of Q' are used to search Q (block 927). In the example, with P3=8, this would be "BSNDNVNF' versus 'BSNDNVNF which matches.

• R' is used to search R (block 929). Note 1hat l x 2 x 9 x 22 x 3 x l x 6 x 2l x

18 does not match I x 2 x 3 x 22 x 3 x l x 6 x 21 x 18.

A union of the above results is generated (block 931). In the example above, since Q' vs. Q yields a match, the set obtained by the union of these steps would include the example N in the match set generated from N'. For one embodiment, the results of the four searches are combined, such that each term that is matched by each search is listed in the result. In another embodiment, a subset of these searches are performed.

Rather than have fixed string length parameters PI, P2, P3, each of these numbers can be adapted to the particular input search name. One possible way of doing this is to pre-compute the frequency of character strings in the original very long list. For example, one could count all instances in which the relevant database column starts with 'AAA', 'AAB', ..., to 'ZZZ'. Say that 'STA* is the most common set of starting characters, occurring 100,000 times, while 'XXZ' occurs only once in the input data. Then if the search string starts with 'STA' the parameter might be PI =7, while if it starts with 'XXZ' the parameter might be PI =3.

The string length parameters can be computed determined dynamically in order to have the corresponding set of matches fall within a desired range. (This is relevant because certain lead strings are likely to have frequencies that may depend on ancillary search criteria, e.g., among business names in general, the leading characters 'TEX' may be infrequent, but in subset of all business names in the state of TEXAS, it is likely that a very large number will begin with the string 'TEX'.) For example, suppose the desired range is 100 to 200 matches. Further suppose that starting with P2 = 8 gives only 10 matches. Then one could successively try P2 = 7, 6, etc., until the generated sublist length exceeds 100. Clearly, the successive search could be done more efficiently as a binary search, e.g., P2 = 4 followed by either P2 = 2 or P2 = 6, etc. If a step of 1 causes the sublist length to jump over the desired range, then some appropriate terminating condition would be applied.

There can be an arbitrary "escape" in case any value of the parameter generates a sublist that is either too short or too long.

For one embodiment, the list of results may be organized by a number of hits. In other words, if all of the above comparisons generated the same company name as a result, that result is at the top of the list of results. For one embodiment, this list of results is then presented directly to the user. For another embodiment, the process described below is used to score the search results. FIG. 9D-E illustrate one embodiment of the process of scoring the results of the database search. The scoring described below is performed on the results obtained from one or more of the database searches.

Figure 9D is a flowchart of one embodiment of character match scoring. This is a low level procedure that establishes the degree to which two words are similar. For one embodiment, this procedure starts with the first character of each word and slides to the right in a zigzag manner identifying matching (equal) characters. Each time 2 matching characters are found, the process continues with the next character of each word, until the ends of the words are reached.

The characters of the search term are identified as SI to Sm, and the characters of the potential match term are identified as PI to Pn (block 935). Also, X is set to 1, and Y is set to one more than a maximum displacement value (M). The maximum displacement value is the maximum amount of displacement between letters of P and S that is considered acceptable. For one embodiment, M is set to four. Alternative values of displacement may be used, anything from one to m (the maximum length of the search term).

It is determined whether S or P are out of letters (block 937). If either of the two words are out of letters, the process continues to block 939. If neither P nor S are out of letters, the process continues to block 943.

If one of the words is out of letters, a word match score is calculated for the terms S and P (block 939). For example, the number of matching letters may be 6. The longer word may have 9 letters, and the shorter word may have 7 letters. A possible scoring formula would be the number of matches multiplied by the ratio of the shorter word to the longer word, i.e., 6 x 7 / 9 = 4.667. In general, the formula should reward longer matches.

The process then tests whether there are any remaining words (block 941). If there are remaining words, the process returns to block 935. Otherwise, the character match process terminates.

If at block 937, neither of the words were out of letters, the process continued to block 943.

It is determined whether SX and PY match (block 943). On the initial comparison, this compares the first letter of S to the third letter of P, if M = 2. If a match is found, the process increments the match counter by one, and increments both X and Y by one (block 945). The process then returns to block 937.

If no match is found, X is incremented by one, and Y is decremented by one (block 947).

The process then tests whether Y = 0 (block 949). If Y ≠ 0, the process returns back to block 937. If Y = 0, the process continues to block 951.

The first letters of S and P are deleted, and the values of X and Y are reset to 1 and M+ 1 respectively (block 951). Now, the formerly second letter of S and P have become the first letters. The process then returns to block 937.

The procedure above matches one word against another word. This process fails to compensate for eliding of words. For example, if 'WILLOWBROOK' and 'WILLOW BROOKE' might denote the same name. For one embodiment, if the words to be compared are of equal length the procedure above is used. For one embodiment, if the length of the words is unequal, the shorter word is concatenated with the next word in the name (if there is one) to see if this change results in a higher score. For example, 'WILLOWBROOK' versus 'WILLOW might yield a score of 6 x 6 / 11 = 3.3, while 'WILLOWBROOK' versus 'WILLOW concatenated with 'BROOKE' might yield a score of ll x 10/11 = 10.0.

Figure 9E is a flowchart of one embodiment of the word match. The word match is a higher level procedure that applies a zigzag process to words instead of letters. For one embodiment, the process evaluates all possible word-to-word match scores up to a given relative word displacement, chooses the pair with the highest matching score above some threshold T and then progresses to the right. For example, suppose the comparison may be between the strings 'THE ABC SCANDANAVIAN FURNITURE CO INC and 'ABIES SCANDANAVEN FURN*. The words of the search term are identified as TI to Tm, and the words of the possible match are identified as Ml to Mn. The value of A is set to one. (block 965).

The process tests whether the value of A is greater than m. If so, then there are no more search term words remaining, and the process continues to block 977. If the value of A is less than m, the process continues to block 969.

The word TA is compared to Ml through Mn, and the highest character match score is determined (block 969). For one embodiment, the character match score is determined as described above with respect to Figure 9D. Alternative methods of determining a character match score may be used. For example, the match score may simply compare the number of matching letters, by removing all of the non-matching letters, and determining how many letters remain. Alternative methods may be used to determine a character match score. In the example described above, the comparison would be 'THE* and 'ABIES', 'THE' and 'SCANDANAVEN', 'ABC and 'ABIES', 'THE' and 'FURN', and 'SCANDANAVIAN' and 'ABIES'. Of these possibilities, the one with the highest word to word match score is 'ABC and 'ABIES'. The same procedure would establish that 'SCANDINAVIAN' best matches 'SCANDANAVEN*. The same procedure would establish that 'FURNITURE' best matches 'FURN*.

It is determined whether the highest character match score is above a threshold (block 971). The threshold may be set to any number. For example, the threshold may be set to test whether at least half of the letters match. In the example above, the high score between ABC and ABIES is T=2, for example, and this may be considered as not matching.

If the score is above the threshold, the character match score for that word is stored (block 973). The value of A is then incremented (block 975), and the process returns to block 967.

If the score is below the threshold, the character match score is not stored, and the process continues directly to block 975, where A is incremented.

When the value of A is greater than the value of m, e.g. there are no more words for comparison, the process continues to block 977. The total score for the potential match is calculated based on the stored character match scores (block 977). For one embodiment, the overall score for the string match uses a formula that depends on the combination of the matching word scores. For example, a possible formula is Wl + W2 + W3. In general, the formula rewards more word matches and higher scoring matches. This score is the final score for the match.

Then, the process determines whether there are any further potential matches that have not been scored (block 979). If there are remaining potential matches, the process returns to block 965. The scoring process then terminates, to block 911, and the potential matches are sorted by score.

The objective of the company name matching process is efficiency in reducing the very long list of names to a much shorter list without dropping the particular desired matching entry.

The particular methods performed by a server computer for an online broker when executing an embodiment of the invention have been described. The method performed by the server computer has been shown by reference to a series of flowcharts including all the acts from 401 until 437, from 501 until 513, from 601 until 615, from 701 until 709, from 801 until 813, and from 901 until 979.

Implementation

In this section of the detailed description, an application data structure and a provider underwriting criteria data structure used in a particular implementation of the invention are described with reference to FIGs. 10 and 11.

FIG. 10 illustrates one embodiment of an application data structure 1000 used to store application information in the application database 327 shown in FIG. 3C and used in conjunction with the credit approval method 400 and the blocking method 600 described in the previous section. The application data structure 1000 is keyed on the applicant's social security number 1001 and a federal tax identifier number 1003. Optional auxiliary identifiers 1005 (shown in phantom), such as name, address, phone number, etc., can also be present in the application data structure 1000. As described previously, the application data structure 1000 is used to determine if an application is blocked by a prior application, so a time and date stamp 1007 and a status 1009 of a completed application are stored in the data structure 1000, along with any blocking period 1011 that will be imposed on a subsequent application from the same applicant. Each credit provider represented by the online broker offers one or more credit products through the broker. The underwriting specification for the credit products are maintained in the provider underwriting criteria database 337 of FIG. 3C as a provider underwriting criteria data structure 1100 shown in FIG. 11, and used by the credit approval method 400, the filtering method 700, and the credit evaluation method 800 as described in the previous section.

An instance of the data structure 1100 for each provider is identified by a provider identifier 1101. Each credit product offered by the provider is stored in a credit product entry 1103. The credit product entry 1103 includes an identifier 1105 for the credit product, the type of credit product 1107 (an operating loan, equipment loan, lease, line of credit, credit card, etc.), and the approval category 1109 (unconditionally approved, conditionally approved). Each instance also contains a series of fields that contain underwriting criteria specified by the credit provider for the particular credit product for comparison against the value of corresponding fields on the application and with values generated during the credit approval process. Such fields may include the following: allowed amount of credit 1111; purpose of credit (e.g., construction, expansion, inventory) 1113; type of business (SIC code) 1115; geographical location (e.g., state, zip code) 1117; years in business 1119; annual income 1121; checking account balance 1123; years as owner 1125; percent ownership 1127; credit score 1129; bankruptcies 1131.

For each field 1111-1131, the provider criterion may specify an upper limit, a lower limit, or both, one or more allowed ranges, one or more forbidden ranges, a specific or an allowed set of values, or a null value that signifies that the data is not important. For example, the entry for credit product X in the provider underwriting criteria data structure 1100 for lender A may specify that an applicant can only qualify for the credit product if:

$10,000 < desired amount of credit < $20,000 (corresponds to allowed amount of credit 1111); purpose of credit 1113 ≠ construction; type of business 1115 ≠ restaurant or bar; state 1117 = CA, OR, or WA; years in business 1119 > 1; years as owner 1125 > 1 ; percent ownership 1127 > 50%; credit score 1129 > 210; and bankruptcies 1131 < 1, while the applicant's zip code, annual income and checking account balance are not important.

The provider underwriting criteria data structure 1100 also specifies the blocking period 1133 required by the particular provider when an application has been approved for a credit product that corresponds to credit product entry 1103. The particular characteristics of the credit products, such as fees, interest rate, offer period, etc., can also be stored in the provider underwriting criteria data structure 1100 as credit product attributes 1135.

It will be appreciated that the order of the fields within the data structures 1000 and 1100 is not critical and that one or more fields can be added or deleted without affecting the scope of the invention.

Conclusion An online broker that enables an applicant to apply online for multiple credit products from multiple credit providers has been described. The present invention allows local decisioning in that the broker has underwriting criteria of each lender. When an application is received, the broker need obtain the credit history information only once to evaluate it against all lenders' criteria to determine the products for which the applicant is qualified. The applicant then chooses one of these products. Thus, the applicant's sensitive information is forwarded only to one chosen lender as opposed to broadcast decisioning, in which the applicant's data is broadcast to many providers so that they can determine the applicant's eligibility for their products. Local decisioning protects the applicant and also increases the speed at which the applicant can be approved.

The online broker also enables the fungibility of credit products. Fungibility refers to the possibility of an applicant possibly being given a choice of different types of credit, e.g., a loan, a line of credit, or an equipment lease, instead of being confined to a single type of credit.

Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement which is calculated to achieve the same purpose may be substituted for the specific embodiments shown. This application is intended to cover any adaptations or variations of the present invention.

The terminology used in this application with respect to networks, client computers, and server computers is meant to include all such environments commonly understood by those of skill in the art. Therefore, it is manifestly intended that this invention be limited only by the following claims and equivalents thereof.

Claims

CLAIMSWhat is claimed is:
1. A computerized method for online brokering of multiple credit products associated with multiple credit providers comprising: collecting application data from an online applicant; rejecting the online application at a pre-determined point when the application data cumulatively collected fails a progressive cumulative filtering for the multiple credit products; evaluating the application data against underwriting criteria for each of the multiple credit products when all the application data is collected; rejecting the online applicant when the application data cannot satisfy the underwriting criteria for any of the multiple credit products; qualifying the online applicant for each credit product having underwriting criteria that are satisfied by the application data; requesting a choice of a qualified credit option from the online applicant; and forwarding the application data to the credit provider associated with the chosen qualified credit product.
2. The computerized method of claim 1, wherein the application data comprises a series of screens, the application data is collected one screen at a time, and the predetermined point is upon collection of each screen.
3. The computerized method of claim 2, wherein each screen corresponds to a page of a physical credit application.
4. The computerized method of claim 1 , wherein qualifying the online applicant comprises: conditionally approving the online applicant when additional application data is necessary to unconditionally approve the online applicant.
5. The computerized method of claim 4, further comprising: collecting the additional application data; unconditionally approving the online applicant when the additional application data satisfies requirements specified by the underwriting criteria for unconditional approval of the chosen qualified credit product; rejecting the online application when the additional application data does not satisfy the requirements specified by the underwriting criteria for unconditional approval of the chosen qualified credit product; and forwarding the additional data to the credit provider associated with the chosen qualified credit product when the requirements for unconditional approval of the chosen qualified credit product are not specified by the underwriting criteria.
6. The computerized method of claim 1, wherein qualifying the online applicant comprises: unconditionally approving the online application when the application data satisfies requirements specified by the underwriting criteria for unconditional approval of the chosen qualified credit product.
7. A computer-readable medium having computer-executable instructions to cause a server computer for an online broker offering multiple credit options to perform a method comprising: receiving application data from an applicant coupled to the server computer through a computer network; sending a rejection message to the applicant when the application data cumulatively received at a first pre-determined point disqualifies the applicant from all of the multiple credit options; creating a list of qualified credit options from the multiple credit options when all the application data is received; sending the list to the applicant when the list contains at least one qualified credit option; receiving a choice of a qualified credit option from the applicant; forwarding the application data to a credit provider associated with the chosen qualified credit option; and sending an application status to the applicant.
8. The computer-readable medium of claim 7, wherein each credit option comprises a credit product and a credit provider for the credit product.
9. The computer-readable medium of claim 7, wherein the application data cumulatively received at the first pre-determined point is evaluated against a subset of underwriting criteria for the multiple credit options to determine if the applicant is disqualified from all of the multiple credit options.
10. The computer-readable medium of claim 9, wherein the method further comprises: obtaining a portion of the underwriting criteria from a credit provider associated with each one of the multiple credit options.
11. The computer-readable medium of claim 7, wherein the application data is evaluated against past activity criteria at a second pre-determined point to determine if the applicant should be blocked from applying for credit from the online broker.
12. The computer-readable medium of claim 11 , wherein the method further comprises: creating the past activity criteria based on application data previously submitted by the applicant to the online broker.
13. The computer-readable medium of claim 7, wherein the application data is evaluated against fraud criteria at a third pre-determined point to determine if the applicant should be blocked from applying for credit from the online broker.
14. The computer-readable medium of claim 7, wherein the application data is evaluated against underwriting criteria for each of the multiple credit options to create the list of qualified credit options.
15. The computer-readable medium of claim 14, wherein the method further comprises: obtaining the underwriting criteria from a credit provider associated with each one of the multiple credit options.
16. The computer-readable medium of claim 7, wherein the method further comprises: receiving additional data from the applicant when the chosen qualified credit option requires the additional data; revising the list to exclude the chosen qualified credit option if the additional data disqualifies the applicant from the chosen qualified credit option; and sending the revised list to the applicant when the revised list contains at least one qualified credit option.
17. The computer-readable medium of claim 16, wherein the method further comprises: sending the additional data to the credit provider associated with the chosen qualified credit option; and receiving an indication from the credit provider that the applicant is approved for the chosen qualified credit option.
18. The computer-readable medium of claim 7, wherein the application data comprises a company name and having further computer-readable instructions comprising: searching for company information associated with the company name.
19. The computer-readable medium of claim 7, wherein the method further comprises: receiving accounting information from the credit provider associated with the chosen qualified credit option.
20. A computer-readable medium having stored thereon an application data structure comprising: an applicant identifier field containing data representing a social security number for an applicant; a tax identifier field containing data representing a federal tax identifier for the applicant identified by the applicant identifier field; a time/date field containing data representing a time and date of a credit application submitted by the applicant identified by the applicant identifier field; a status field containing data representing a processing status for a credit application submitted by the applicant identified by the applicant identifier field; and a blocking field containing data representing a time period in which a subsequent application submitted by the applicant identified by the applicant identifier field cannot be processed.
21. The computer-readable medium of claim 20 further comprising: an auxiliary identifier field containing data representing additional data associated with the applicant identified by the applicant identifier field.
22. A computer-readable medium having stored thereon an application data structure comprising: a provider identifier field containing data representing an identifier for a credit provider; and at least one credit product field containing data representing an entry for a credit product offered by the credit provider identified by the provider identifier field, wherein the credit product field comprises: a product identifier field containing data representing an identifier for a credit product offered by the credit provider identified by the provider identifier field; a credit type field containing data representing a type for the credit product identified by the product identifier field; an approval category field containing data representing an approval category for the credit product identified by the product identifier field; an allowed amount of credit field containing data representing monetary amount underwriting criteria for the credit product identified by the product identifier field; a purpose of credit field containing data representing credit purpose underwriting criteria for the credit product identified by the product identifier field; a type of business field containing data representing business type underwriting criteria for the credit product identified by the product identifier field; a geographic location field containing data representing location underwriting criteria for the credit product identified by the product identifier field; a years in business field containing data representing business duration underwriting criteria for the credit product identified by the product identifier field; an annual income field containing data representing income underwriting criteria for the credit product identified by the product identifier field; a checking account balance field containing data representing cash underwriting criteria for the credit product identified by the product identifier field; a years as owner field containing data representing ownership duration underwriting criteria for the credit product identified by the product identifier field; a percent ownership field containing data representing ownership percentage underwriting criteria for the credit product identified by the product identifier field; a bankruptcies field containing data representing bankruptcy underwriting criteria for the credit product identified by the product identifier field; and a blocking period field containing data representing an amount of time for which a subsequent application from a applicant will be disallowed when the applicant has applied for the credit product identified by the product identifier field.
23. The computer-readable medium of claim 22, wherein the data representing underwriting criteria in each field is selected from the group consisting of an upper limit value, a lower limit value, at least one allowed range of values, at least one forbidden range of values, a specific allowed set of values, a specific disallowed set of values, or a null value.
24. The computer-readable medium of claim 22 further comprising a credit product attributes field containing data representing characteristics for the credit product . identified by the product identifier field.
25. A method of communicating between a client computer for a credit applicant and server computer for an online credit broker, the method comprising: sending, by the client computer, a request for a credit application; performing a data collection process as a result of the request for the credit application until a rejection message is sent to the client computer or until all portions of the credit application are received, the data collection process comprising: sending, by the server computer, a portion of the credit application to the client computer; sending, by the client computer, a corresponding completed portion to the server computer after the applicant has input data to the portion received from the server; filtering, by the server computer, the credit application based on the data on the completed portions cumulatively received from the client; sending, by the server computer, a rejection message to the client computer when the filtering disqualifies the applicant from all credit options offered by the online broker; and sending, by the server computer, a subsequent portion of the credit application to the client computer when the filtering determines the applicant remains qualified for at least one of the credit options offered by the online broker; and performing a data evaluation process when all portions of the credit application are received and a rejection message has not been sent to the client computer, the data evaluation process comprising: evaluating, by the server computer, the data on the credit application against underwriting criteria for each of the credit options; creating, by the server computer, a list of the credit options for which the applicant is determined qualified by the evaluation; sending, by the server computer, the list to the client computer; sending, by the client computer, a choice of a credit option to the server computer when the applicant has chosen a credit option from the list received from the server; and sending, by the server computer, a status for the chosen credit option to the client computer when the credit application has been submitted to a credit provider identified by the chosen credit option.
26. The method of claim 25, wherein the data evaluation process further comprises: determining, by the server computer, if the chosen credit option requires additional data; sending, by the server computer, a request for additional data to the client computer as a result of determining that the chosen credit option requires the additional data; sending, by the client computer, the additional data to the server computer as a result of receiving the request for the additional data when the applicant has input the additional data; evaluating, by the server computer, the additional data against the underwriting criteria for the chosen credit option in response to receiving the additional data; revising, by the server computer, the list when the evaluation of the additional data disqualifies the applicant from the chosen credit option; sending, by the server computer, a revised list to the client computer when there is at least one credit option on the revised list; and sending, by the server computer, a rejection message to the client computer if there are no credit options on the revised list.
27. A computer-readable medium having stored thereon computer-executable logic for an online broker offering multiple credit options, the logic comprising: an applicant interface for receiving completed portions of a credit application from an applicant and for returning messages from the online broker to the applicant; credit approval logic coupled to the applicant interface for blocking the application, for rejecting the application, and for approving the application for one of a set of qualified credit options; blocking logic coupled to the credit approval logic for determining if the application should be blocked because of a previous application or because of fraud; filtering logic coupled to the credit approval logic for performing a preliminary evaluation of the portions of the application cumulatively received to determine if the applicant is qualified for any of the multiple credit options; and credit evaluation logic coupled to the credit approval logic for determining the set of qualified credit options for the applicant.
28. The computer-readable medium of claim 27 having further computer-executable logic comprising: a provider interface for exchanging messages and data with a credit provider for at least one of the multiple credit options.
29. The computer-readable medium of claim 27 having further computer-executable logic comprising: company identification logic for obtaining company information for a company name.
30. A method of providing business credit over a network, the method comprising: maintaining a database of a plurality of potential lenders, including underwriting criteria for each of the plurality of lenders; initiating a credit approval process upon receiving an application from a user for business credit comprising: retrieving other data about the user based on information in the application; matching the application and the information against the underwriting criteria; determining if the user is qualified for any business credit; displaying options for the business credit, and permitting a user to select an option; and during the credit approval process: performing a progressive cumulative filtering against the lending criteria at a pre-determined point in the credit application process, to determine if there are any qualified options remaining at each stage of the credit application process; and terminating the credit application process, at any stage of the credit application process, if there are no qualified options.
31. The method of 30 further comprising: requesting a company name from the applicant; and using the company name from the applicant as a search term to match against a database of potential company names.
32. The method of claim 31 , wherein matching the company name comprises: preprocessing the database to generate at least one mapping of the potential company names; processing the search term to generate at least one mapping of the search term; comparing the mappings of the database and the search term; and generating a single set of results based on the comparison.
33. The method of claim 32 further comprising : scoring a company name corresponding to each result in the single set of results; and returning to the applicant a subset of the results, for the applicant to select a correct company name.
34. The method of claim 33, wherein the scoring comprises: performing a word match to determine a best match for each word in the search result and each word in a potential match; and if the match score is above a threshold, adding the match score to the total for the potential match.
35. The method of 34 further comprising : performing a character match comparison to determine the best match for each word.
36. A computer data signal embodied in a carrier wave and representing computer- executable instructions to cause a server computer for an online broker offering multiple credit options to perform a method comprising: receiving application data from an applicant coupled to the server computer through a computer network, wherein the application data comprises multiple parts; sending a rejection message to the applicant if the application data cumulatively received disqualifies the applicant from all of the multiple credit options; creating a list of qualified credit options from the multiple credit options when all the parts of the application are received; sending the list to the applicant when the list contains at least one qualified credit option; receiving a choice of a qualified credit option from the applicant; forwarding the application data to a credit provider associated with the chosen qualified credit option; and sending an application status to the applicant.
37. The computer data signal of claim 36, wherein each credit option comprises a credit product and a credit provider for the credit product.
38. The computer data signal of claim 36, wherein the data from a first predetermined number of parts of the application is evaluated against a subset of underwriting criteria for the multiple credit options when the data is received to determine if the applicant is disqualified from all of the multiple credit options.
39. The computer data signal of claim 38, wherein the method further comprises: obtaining a portion of the underwriting criteria from a credit provider associated with each one of the multiple credit options.
40. The computer data signal of claim 36, wherein the data from a first predetermined number of parts of the application is evaluated against past activity criteria to determine if the applicant should be blocked from applying for credit from the online broker.
41. The computer data signal of claim 40, wherein the method further comprises: creating the past activity criteria based on application data previously submitted by the applicant to the online broker.
42. The computer data signal of claim 36, wherein the data from a third predetermined number of parts of the application is evaluated against fraud criteria to determine if the applicant should be blocked from applying for credit from the online broker.
43. The computer data signal of claim 36, wherein the data from all the parts of the application are evaluated against underwriting criteria for each of the multiple credit options to create the list of qualified credit options.
44. The computer data signal of claim 43, wherein the method further comprises: obtaining the underwriting criteria from a credit provider associated with each one of the multiple credit options.
45. The computer data signal of claim 36, wherein the method further comprises: receiving additional data from the applicant when the chosen qualified credit option requires the additional data; revising the list to exclude the chosen qualified credit option if the additional data disqualifies the applicant from the chosen qualified credit option; and sending the revised list to the applicant when the revised list contains at least one qualified credit option.
46. The computer data signal of claim 45, wherein the method further comprises: sending the additional data to the credit provider associated with the chosen qualified credit option; and receiving an indication from the credit provider that the applicant is approved for the chosen qualified credit option.
47. The computer data signal of claim 36, wherein the application data comprises a company name and further representing computer-readable instructions comprising: searching for company information associated with the company name.
48. The computer data signal of claim 36, wherein the method further comprises: receiving accounting information from the credit provider associated with the chosen qualified credit option.
49. A server computer system for an online credit broker comprising: a processing unit operable for coupling to a network through a system bus; a memory coupled to the processing unit through the system bus; a computer-readable medium coupled to the processing unit through the system bus, the computer-readable medium having stored thereon underwriting criteria for a plurality of credit products associated with a plurality of credit providers; a credit approval program executed from the computer-readable medium by the processing unit, wherein the credit approval program causes the processing unit to: collect application data from an online applicant coupled to the network; reject the online application when the application data cumulatively collected at a pre-determined point fails a progressive cumulative filtering based on the underwriting criteria for the plurality of credit products; evaluate the application data against the underwriting criteria for each of the plurality of credit products when all the application data is collected; reject the online applicant when the application data cannot satisfy the underwriting criteria for any of the plurality of credit products; qualify the online applicant for each credit product having underwriting criteria that are satisfied by the application data; request a choice of a qualified credit option from the online applicant; and forward the application data to the credit provider associated with the chosen qualified credit product.
50. The server computer system of claim 49, wherein the credit approval program further causes the processing unit to conditionally approve the online applicant when qualifying the online applicant if additional application data is necessary to unconditionally approve the online applicant.
51. The server computer system of claim 50, wherein the credit approval program further causes the processing unit to: collect the additional application data; unconditionally approve the online applicant when the additional application data satisfies requirements specified by the underwriting criteria for unconditional approval of the chosen qualified credit product; reject the online application when the additional application data does not satisfy the requirements specified by the underwriting criteria for unconditional approval of the chosen qualified credit product; and forward the additional data to the credit provider associated with the chosen qualified credit product when the requirements for unconditional approval of the chosen qualified credit product are not specified by the underwriting criteria.
52. The server computer system of claim 49, wherein the credit approval program further causes the processing unit to unconditionally approve the online application when qualifying the online applicant if the application data satisfies requirements specified by the underwriting criteria for unconditional approval of the chosen qualified credit product.
53. An apparatus comprising: an applicant interface means for receiving completed portions of a credit application from an applicant and for returning messages from an online broker to the applicant; credit approval means coupled to the applicant interface means for blocking the application, for rejecting the application, and for approving the application for one of a set of qualified credit options; blocking means coupled to the credit approval means for determining if the application should be blocked because of a previous application or because of fraud; filtering means coupled to the credit approval means for performing a preliminary evaluation of the portions of the application cumulatively received to determine if the applicant is qualified for any of the multiple credit options; and credit evaluation means coupled to the credit approval means for determining the set of qualified credit options for the applicant.
54. The apparatus of claim 53 further comprising: a provider interface means coupled to the credit approval means for exchanging messages and data with a credit provider for at least one of the multiple credit options.
55. The apparatus of claim 53 further comprising: company identification means coupled to the credit approval means for obtaining company information for a company name.
PCT/US2001/011668 2000-04-14 2001-04-09 Online credit services brokering WO2001080123A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US54982200 true 2000-04-14 2000-04-14
US09/549,822 2000-04-14

Publications (1)

Publication Number Publication Date
WO2001080123A1 true true WO2001080123A1 (en) 2001-10-25

Family

ID=24194498

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/011668 WO2001080123A1 (en) 2000-04-14 2001-04-09 Online credit services brokering

Country Status (1)

Country Link
WO (1) WO2001080123A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002065351A1 (en) * 2001-02-12 2002-08-22 Accenture Australia Ltd. Aggregation of credit facilities
US6823319B1 (en) 1999-07-19 2004-11-23 Home American Credit, Inc. System and method for automated process of deal structuring
US7340424B2 (en) 2002-12-30 2008-03-04 Fannie Mae System and method for facilitating sale of a loan to a secondary market purchaser
US7747519B2 (en) 2002-12-30 2010-06-29 Fannie Mae System and method for verifying loan data at delivery
US8046298B1 (en) 2003-07-21 2011-10-25 Fannie Mae Systems and methods for facilitating the flow of capital through the housing finance industry
US9928546B2 (en) 2002-12-30 2018-03-27 Fannie Mae System and method for processing data pertaining to financial assets

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774882A (en) * 1992-03-12 1998-06-30 Keen; Regina D. Credit approval system
US5878403A (en) * 1995-09-12 1999-03-02 Cmsi Computer implemented automated credit application analysis and decision routing system
US6009424A (en) * 1996-09-04 1999-12-28 Atr Interpreting Telecommunications Research Laboratories Similarity search apparatus for searching unit string based on similarity
US6014645A (en) * 1996-04-19 2000-01-11 Block Financial Corporation Real-time financial card application system
WO2000026381A2 (en) * 1998-10-30 2000-05-11 Cornell Research Foundation, Inc. High fidelity thermostable ligase and uses thereof
US6088686A (en) * 1995-12-12 2000-07-11 Citibank, N.A. System and method to performing on-line credit reviews and approvals
US6112190A (en) * 1997-08-19 2000-08-29 Citibank, N.A. Method and system for commercial credit analysis

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774882A (en) * 1992-03-12 1998-06-30 Keen; Regina D. Credit approval system
US5878403A (en) * 1995-09-12 1999-03-02 Cmsi Computer implemented automated credit application analysis and decision routing system
US6088686A (en) * 1995-12-12 2000-07-11 Citibank, N.A. System and method to performing on-line credit reviews and approvals
US6014645A (en) * 1996-04-19 2000-01-11 Block Financial Corporation Real-time financial card application system
US6009424A (en) * 1996-09-04 1999-12-28 Atr Interpreting Telecommunications Research Laboratories Similarity search apparatus for searching unit string based on similarity
US6112190A (en) * 1997-08-19 2000-08-29 Citibank, N.A. Method and system for commercial credit analysis
WO2000026381A2 (en) * 1998-10-30 2000-05-11 Cornell Research Foundation, Inc. High fidelity thermostable ligase and uses thereof

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6823319B1 (en) 1999-07-19 2004-11-23 Home American Credit, Inc. System and method for automated process of deal structuring
WO2002065351A1 (en) * 2001-02-12 2002-08-22 Accenture Australia Ltd. Aggregation of credit facilities
US7340424B2 (en) 2002-12-30 2008-03-04 Fannie Mae System and method for facilitating sale of a loan to a secondary market purchaser
US7747519B2 (en) 2002-12-30 2010-06-29 Fannie Mae System and method for verifying loan data at delivery
US8515861B2 (en) 2002-12-30 2013-08-20 Fannie Mae System and method for facilitating sale of a loan to a secondary market purchaser
US9928546B2 (en) 2002-12-30 2018-03-27 Fannie Mae System and method for processing data pertaining to financial assets
US8046298B1 (en) 2003-07-21 2011-10-25 Fannie Mae Systems and methods for facilitating the flow of capital through the housing finance industry

Similar Documents

Publication Publication Date Title
US6941271B1 (en) Method for accessing component fields of a patient record by applying access rules determined by the patient
US6205472B1 (en) Method and apparatus for querying a user knowledge profile
US7065494B1 (en) Electronic customer service and rating system and method
US7555459B2 (en) Automated loan processing system and method
US6792410B1 (en) Automated claim repricing system
US8145563B2 (en) Computer system and method for networked interchange of data and information for members of the real estate financial and related transactional services industry
US20030191711A1 (en) System and method for obtaining customer bill information and facilitating bill payment at biller websites
US6604131B1 (en) Method and system for distributing a work process over an information network
US20030004874A1 (en) Electronic bill presentment system with client specific formatting of data
US6795811B1 (en) Method for investing working capital
US20020007335A1 (en) Method and system for a network-based securities marketplace
US20010029482A1 (en) Online mortgage approval and settlement system and method therefor
US8271313B2 (en) Systems and methods of enhancing leads by determining propensity scores
US20050273368A1 (en) System and method for capturing an image
US20040158746A1 (en) Automatic log-in processing and password management system for multiple target web sites
US20050086170A1 (en) System and method for processing partially unstructured data
US20030236728A1 (en) Method and apparatus for managing a financial transaction system
US20060074799A1 (en) Method and system for integrated payment processing
US20100312705A1 (en) Apparatuses, methods and systems for a deposit process manager decisioning engine
US20040078228A1 (en) System for monitoring healthcare patient encounter related information
US7139728B2 (en) Systems and methods for online selection of service providers and management of service accounts
US7769650B2 (en) Network-based sub-allocation systems and methods for swaps
US20020143562A1 (en) Automated legal action risk management
US20080249936A1 (en) Bill paying systems and associated methods
US20030144887A1 (en) System and method for electronically creating, filing and approving applications for insurance coverage

Legal Events

Date Code Title Description
AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP