WO2002031740A2

WO2002031740A2 - Method and apparatus for processing financing application

Info

Publication number: WO2002031740A2
Application number: PCT/US2001/008122
Authority: WO
Inventors: Venkatesan Srinivasan
Original assignee: Ecredit.Com, Inc.
Priority date: 2000-10-06
Filing date: 2001-03-13
Publication date: 2002-04-18
Also published as: AU2001245705A1

Description

METHOD AND APPARATUS FOR PROCESSING FINANCING

APPLICATION:

FIELD OF THE INVENTION

This invention relates to processing financing applications, such as loan applications.

BACKGROUND OF THE INVENTION The financing of trade can take very different forms as a function of the type of buyer, product, terms, and use, among other factors. A typical financing process comprises the gathering of credit information (from internal and external sources), risk assessment and decisioning, pricing, document generation, funding, order release and shipping and booking of the financing contract in financial systems. Loan application handling systems, such as that described in U.S. Patent

5,611,052 to Dykstra et al., are known which provide for some kinds of automated credit evaluation and loan processing. With such systems, loan information may be entered through a remote terminal and provided to a processing unit. The processing unit may access credit bureau information, perform a credit scoring operation to evaluate the creditworthiness of the applicant, evaluate the loan application information and determine whether the loan will be approved.

This type of system may require a loan applicant to prepare and send multiple loan applications if applications are to be submitted to multiple lenders. Application routing systems, such as that described in U.S. Patent 5,878,403 to DeFrancesco et al., avoid this problem by allowing an applicant -to submit a single loan application that can be routed to multiple lending institutions. After the lending institutions receive and process the application, a decision to accept or deny the application can be sent back to the applicant through the routing system. Applications can be routed to different types of lenders, including those that perform traditional manual application approval processes. The remaining functions are handled either manually or in a partially automated fashion, but not in an integrated manner with the steps supported by the loan application handling systems. SUMMARY OF THE INVENTION The inventor has developed, among other aspects of the invention, a system and method that allows multiple, different lender application decisioning processes to be operated on a same financing network, e.g., a same data processing system. These different decisioning processes may be operated on the same financing network even though they might otherwise require incompatible hardware, software, operating systems, database formats and so on. In at least one aspect of the invention, the inventor has developed a system and method that allows simplified modification of existing lender decisioning processes and/or addition of new decisioning processes to a financing network. Therefore, new or modified decisioning processes may be added to an existing financing network without requiring development of an entirely new data processing system and/or substantial reconfiguration of the financing network.

In an illustrative embodiment of the invention, a centralized financing application processing system includes a memory and a process controller that receives a financing application including financing application information and sends financing decision information, such as a decision to accept or deny a financing application, pricing information and legal documents. A plurality of lender process modules operate under the control of the process controller, and each of the lender process modules is adapted to receive financing application information from the process controller and render a financing decision based on the financing application information and a decision making process or processes which have been adopted by a particular lender. In one aspect of this embodiment of the invention, routing of a financing application is possible, but not necessary, since the application may be processed in a centralized computer system. Centralizing the financing application processing may have advantages, such as speeding application processing, decreasing credit information costs (since credit information may be obtained once and used by a plurality of lender processing modules), insulating merchants from lenders (so lenders can be changed as appropriate without any impact on the merchant) and facilitating interaction between lenders, merchants, an applicant and a lender process module during application processing. In another important aspect of the system, the merchant can examine the application information with a process module first, decide to act as a lender or subject the application to processing by other lender process modules. This may result in increased financial liquidity and in the financing of an increased number of transactions.

In another illustrative embodiment of the invention, a method for processing a financing application on a centralized data processing apparatus includes receiving financing application information and selecting at least one of a plurality of lender processes that are each associated with a lender and are hosted on a centralized data processing apparatus. The financing application is evaluated using the selected at least one lender process, and financing decision information is provided based on the evaluation by the selected at least one lender process. In another illustrative embodiment of the invention, the selection of the lender can be based on a round robin basis, on the basis of a statistical algorithm that relies on a statistical distribution to reach a pre-specified allocation percentage of applications, from one or more pre-specified merchants, or from a set of pre-specified lenders.

In another illustrative embodiment of the invention, a method for obtaining credit information in a computerized financing application evaluation process includes identifying a first selected credit information source and accessing credit information from the first selected credit information source. If the credit information provided by the first selected credit information source is not sufficient, a second selected credit information source is identified and credit information from a second selected credit information source is accessed. In one aspect of this embodiment, a best set of credit information can be obtained from a plurality of credit information sources, if necessary. Credit information sources may be accessed in order of the expected quality of the information to be provided by each source. In another aspect of this embodiment, different sets of information may be obtained from different sources and combined, if appropriate, for analytical purposes. In yet another aspect of this embodiment, information may also be obtained from the seller's financial systems including its accounts receivable systems.

In another illustrative embodiment of the invention, the lender process modules can determine that additional information is needed order to reach a final decision on the financing application and send a request for additional information back to the lender, merchant and/or the applicant. Information requested from a lender may include a request to alter the evaluation criteria used by the lender process module 30a, alter the terms of the application (such as the interest rate), stop processing of the application by the lender process module 30a and perform further evaluation at the lender system 3a or manually at the Lender A's offices, and so on. Information requests to the merchant may be a request for a sales price adjustment, an adjustment in lender process selection criteria, more information regarding a product to be purchased, and so on. Applicants may be requested to provide the identity of a guarantor, additional collateral, or other information suitable for processing an application.

In another illustrative embodiment of the invention, if a lender process module cannot automatically generate a decision for an application, e.g., if an application presents an unusual situation that cannot be handled by an automated decisioning process, a credit officer or other person at a lender may intervene in the process to generate a decision for the application. The lender process module may request human intervention when further automatic processing is not possible, or a credit officer may request intervention at any point in the automatic processing by the lender process module, e.g., when the lender process module requests further information from the lender, merchant and/or applicant during automatic processing. The intervening person may use information gathered and/or determined by the lender process module up to the point of intervention, such as credit information, application scoring results or preliminary scoring figures, etc., to further process the application manually or using another automated process, such as a process implemented on a lender's application processing system.

In another illustrative embodiment of the invention, the lender process modules apply the lender's pricing logic to arrive at a risk-adjusted price for financing. In another aspect of this embodiment, the lender process module can reach a decision to offer a different financing product from the one requested in the financing application. The financing product offered could be different in many respects including but not limited to the amount of financing, repayment terms, usage, finance rate and collateral. In another aspect of this embodiment, the merchant may choose to adjust the price offered by the lender either upward or downward and present the adjusted price to the buyer. In another illustrative embodiment of the invention, after the applicant accepts the financing product offered by a lender, the lender process modules determine the specific legal documents to be executed by the applicant. In an aspect of this embodiment, the documents required are determined by a set of business rules that may include, but are not limited to, rules as a function of the financing product, the applicant and the regulatory environment.

In another illustrative embodiment of the invention, the applicant can choose to sign the documents digitally and accept the financing product. In another aspect of this embodiment, the applicant can print the documents, sign manually and send them by mail or facsimile.

In another illustrative embodiment of the invention, after the lender receives acceptable documents duly executed by the applicant, the lender can so indicate to the merchant via the network and release the funds to the merchant. In an aspect of this embodiment, the lender process modules may then communicate with the merchant's manufacturing/shipping systems to produce and/or ship the products to the applicant.

BRIEF DESCRIPTION OF THE DRAWINGS Illustrative embodiments of the invention are described with reference to the following drawings, in which like numerals reference like elements, and wherein:

Fig. 1 is a schematic block diagram of a financing system in accordance with an embodiment of the invention;

Fig. 2 is a more detailed schematic block diagram of a financing system in accordance with an embodiment of the invention;

Fig. 3 is an exemplary metadata flow chart for a process executed by the financing system of Fig. 2;

Fig. 4 is a schematic block diagram of an Internet-based financing system in accordance with an embodiment of the invention; Fig. 5 is a flow chart of steps for a method of processing financing application information in accordance with an embodiment of the invention;

Fig. 6 and 7 are flow charts of steps for a method of performing a merchant financing application process;

Fig. 8 is a flow chart of steps of a method for processing a financing application in accordance with an embodiment of the invention;

Fig. 9 is a flow chart of steps of a method for obtaining consumer credit information in an embodiment of the invention; Fig. 10 is a flow chart of steps of a method for obtaining business credit information in an embodiment of the invention; and

Fig. 11 is a schematic block diagram of two financing systems linked together in accordance with an embodiment of the invention.

DETAILED DESCRIPTION In one illustrative embodiment of the invention, a loan applicant can prepare and send a single loan application to a central financing system, such as a centralized computer system, that hosts a plurality of lender loan application processes. At least two of the lender processes may process the application, either in serial or parallel fashion. The selection of a lender process to which to submit a loan application may be based on any suitable criteria. Processing the loan application may involve obtaining and evaluating credit information for the applicant and evaluating the loan application based on any lender-supplied or other criteria. A decision to approve or decline the loan application may be determined by the lender processes in a fully automated way without human or lender intervention.

Although illustrative embodiments of the invention are described below in connection with a loan application submitted by a merchant on behalf of a loan applicant to a financing system, the invention is not limited to the illustrative embodiments. For example, a loan applicant may submit an application to the financing system without an intervening merchant. In addition, the financing application processed by the financing system need not be limited to loan applications only. Instead, the financing system may be configured to process an application for any financing transaction, such as a factoring transaction, a trade credit transaction, a leasing transaction, an escrow transaction, a credit insurance transaction, a letter of credit transaction, and so on. In addition, the invention is not limited to a single financing system, but may include two or more regionally and/or internationally distributed financing systems that communicate with each other. In short, the invention is not limited to the illustrative embodiments described below. Fig. 1 is a schematic block diagram of a financing application processing system in accordance with an illustrative embodiment of the invention. In this embodiment, the financing system 1 receives a financing application, such as a loan application, from a merchant system 2. For example, a consumer may wish to purchase an item, such as a car, from a merchant, such as a car dealership. The consumer may request the dealership to provide financing for the purchase in the form of a loan. The dealership, using the merchant system 2, may provide loan application information for the consumer to the financing system 1. As one example, an operator at the dealership may provide application information, such as the consumer's name, address, annual income, place of employment, loan amount requested and other suitable information, using a graphical user interface displayed on the merchant system 2. Once the application information is complete, the financing application may be sent to the financing system 1. Upon receiving the financing application, a process controller 10 in the financing system 1 may request a merchant process module 20 to initially evaluate the financing application. The evaluation by the merchant process module 20 may involve selecting a lender to which the financing application should be submitted, evaluating whether the merchant should self-finance the loan (e.g., assume the loan risk itself or access an existing line of credit to finance the loan), perform a preliminary evaluation to determine if the application should be denied without submitting the application to a lender, determining whether the information provided in the financing application is correct, e.g., by comparing information in the financing application to credit information, or other processes. As one example of how a financing application may be preliminarily evaluated, the merchant process module 20 may calculate a ratio of the requested loan amount and other outstanding debt of the applicant to the applicant's income. If the ratio is larger than a threshold value, the application may be denied without further processing. Alternately, the merchant process module 20 may determine if credit bureau information has been obtained for the applicant in the past, and if so, perform a preliminary analysis or veracity check of the application or credit information, if reasonably current, to determine if the application should be denied. For example, the applicant may have filed for bankruptcy within the last two years and therefore be denied further credit. Also, the merchant process module 20 may compare the financing application information to the credit information to verify that the information in the application, such as the applicant's income, address, etc., is correct, and/or that the applicant actually is the person stated in the financing application, e.g., by determining if certain information in the application that only the correct applicant would know or have access to matches certain pieces of credit information.

The merchant process module 20 may also perform a preliminary analysis of the application to determine which, if any, lenders should receive the application. For example, the merchant process module 20 may determine a preliminary grading of the application, based on the application information and/or credit information, to determine lenders to receive the application. The merchant process module 20 may determine a plurality of lenders to submit the financing application to, or divide the financing application into components that are submitted to a plurality of lenders, e.g., to form a syndication in which a plurality of lenders approve the financing application. The merchant process module 20 also may determine that the merchant should self-finance the loan using its own funds or funds obtained through an existing line of credit. If a decision is made to use an existing line of credit to finance the loan, the process controller 10 can report this decision, and the amount for a take-down operation, to the merchant system 2 and the lender that is providing the line of credit to the merchant or in the case of self finance, communicate to the accounting system.

In the example above, the consumer may have a good credit history and present a high quality, low risk application. Therefore, the merchant process module 20 may perform a preliminary evaluation of the application and determine that the application is a "grade A" application. In this example, the merchant process module 20 submits all grade A applications to Lender A first, followed by Lender B if Lender A declines the application. However, if the application were a grade B application (e.g., a higher risk application), the merchant process module 20 may be configured to submit the application to Lender B first, followed by Lender C if Lender B declines the application. Alternately, the merchant process module 20 may be configured to submit the application to all of Lenders A, B and C at the same time. It should be understood that the merchant process module 20 may use any criteria to select one or more lenders to receive an application, and the application may be provided in any suitable way.

If the merchant process module 20 selects one or more lenders to receive the financing application, the process controller 10 may determine whether the selected lender or lenders have a lender process module 30 operating on the financing system 1, and if so, submit the financing application to the lender process module 30. Otherwise, the process controller 10 may submit the financing application to a lender system 3 outside of the financing system 1. If the process controller 10 determines that the financing application should be syndicated, the process controller 10 may split the financing application into components or submit the entire application to a plurality of lender process modules 30 and/or lender systems 3. The process controller 10 may submit a financing application to a lender system 3 outside the financing system 1 by placing the financing application in a lender queue within the financing system 1 that is accessed periodically by the lender system 3. If the lender system 3 detects a financing application within the queue (which basically includes at least a list of applications to be processed by the lender), the lender system 3 may retrieve and process the application in any way, such as using an automated application evaluation process, a manual evaluation process, and so on.

In this example, Lenders A and B are associated with lender systems 3 a and 3b, respectively, and have lender process modules 30a and 30b, respectively, operating on the financing system 1. Therefore, if the merchant process module 20 selects Lender A to receive the application, the process controller 10 submits the financing application to the lender process module 30a. However, if Lender C were selected, the process controller 10 may send the financing application to the lender system 3c, e.g., using a lender queue (not shown).

Evaluation of the financing application by the lender process modules 30a and 30b may involve any lender-specified or other evaluation criteria. Such an evaluation process may involve, for example, obtaining credit information for the applicant submitting the financing application and evaluating the credit information. Evaluation of the credit information may involve traditional evaluation techniques and/or others, such as veracity check processes to authenticate the person or entity that submitted the application (i.e., confirm that the person or entity is actually the applicant listed in the application) and/or confirm that the information provided in the application is accurate. Credit information may be obtained from an information source 4 and/or a memory 40 in the financing system 1, e.g., if the applicant has submitted an application in the recent past and credit information gathered during processing of the earlier application was stored in the memory 40. The information source 4 may be, for example, a database maintained by a credit information bureau, such as Dun & Bradstreet, Equifax, Experian, Trans Union and Edgar. The lender process modules 30a and 30b may use an information source 4 selection process by which a best information source 4 is selected and accessed for needed credit information. In addition, the lender process modules 30a and 30b may use an iterative process to obtain credit information.

For example, the lender process module 30a may identify a first information source 4 as a best source and access the first information source 4 for credit information relating to the consumer's car loan application. If the first information source 4 does not supply complete or sufficient information to evaluate the consumer's application, the lender process module 30a may identify and access a second best information source 4 for the missing credit information. The lender process module 30a may continue this iterative process, accessing consecutive information sources 4 until all information sources 4 have been exhausted. Thus, credit information may be obtained from a plurality of different information sources 4 and processed in any suitable way, such as combining the credit information together into a single data set that is used to process the application. The lender process modules 30 may use any lender-specified or other criteria when evaluating a financing application or related credit information. Traditional techniques for evaluation are well known and may be used. However, other evaluation techniques may be used. For example, when processing the consumer's car loan application, the lender process module 30a may determine that the application will be denied unless further information is provided from the consumer, such as a guarantor for the loan amount, additional collateral, a reduction in the requested loan amount, etc. The lender process module 30a may request this information, e.g., by sending a request message to the merchant system 2, and/or may notify the Lender A's system 3 a of the need for additional information. The Lender A may choose to intervene in the evaluation process and authorize the request for additional information, submit a request for additional information directly from the lender system 3 a to the merchant system 2, alter the evaluation criteria used by the lender process module 30a, alter the terms of the application (such as the interest rate), stop processing of the application by the lender process module 30a and perform further evaluation at the lender system 3 a or manually at the Lender A's offices, and so on. Thus, the Lender A may interact with the application processing to further control the processing as necessary. This interactive feature may shorten the time between an applicant submitting a financing application and the application being accepted by a lender since applications not initially meeting a lender's criteria are not necessarily denied automatically. Instead, the application may be "kept alive" as alternative ways for approving the application are explored by the Lender A, the lender system 3a, the lender process module 30a and/or other entities. In addition, the ability to intervene in the processing of an application may make credit officers or other officials more efficient in their work since human intervention may only be required for certain applications that present unusual circumstances while other more routine applications are decisioned automatically.

The lender process modules 30 may approve an entire financing application, or a portion or component of the application, e.g., in a loan syndication situation. The lender process modules 30 may themselves split an application into components and approve one or more components when suitable, such as when the lender process module 30 determines that the entire financing application will not be approved by the lender process, but individual components of the application are approved. Continuing the example above, the Lender A may approve a request for further information from the consumer that includes a request for a guarantor for a portion of the loan amount, or optionally ask for the consumer's agreement to decrease the requested loan amount. A message to this effect may be sent to the merchant system 2, and the consumer may supply the requested information, e.g., agree to decrease the loan amount. While applying lender-specified or other evaluation criteria to the financing application information and the credit information, a lender process module 30a may render a decision to accept or decline the application. If a financing application is evaluated by the lender system 3 c, the lender system 3 c may send the financing decision information to the financing system 1, e.g., by placing the financing decision information in a lender queue that is identified and retrieved by the process controller 10.

In the example above, the lender process module 30a may report to the lender system 3 a that the consumer has agreed to decrease the requested loan amount. The Lender A may send a message to the lender process module 30a indicating that the application should be approved, or the lender process module 30a may reevaluate the application based on the revised loan amount and approve the application without the Lender A's intervention.

Financing decision information, which may include an approval or disapproval of the loan application, a request for further information from the applicant or other source, such as the identity of a guarantor for all or part of the requested loan amount, or other information, may be reported back to the merchant system 2. If the application is approved, the financing decision information may include legal forms or other papers needed to complete the financing transaction. For example, the lender process module 30a may send a message to the merchant system 2 indicating that the revised application for the new loan amount is approved and include a promissory note and other papers for signing by the consumer, either by using a digital signature or handwriting. The merchant system 2 may print out the loan approval forms and return the signed forms to Lender A through the mail, for example.

The process controller 10 may also be configured to allow modification of existing lender process modules 30 and/or merchant process modules 20. For example, lender process modules 30, or portions of the lender process modules 30, may be represented by metadata in the form of a flowchart. The process controller 10 may display the flow chart for a lender process module 30 in a graphical interface and allow an operator to modify the flow chart, thereby modifying the lender decisioning process within the lender process module 30. Therefore, lender process modules 30 and/or merchant process modules 20 may be altered or added to the financing system 1 without requiring complex programming or substantial reconfiguring of the financing system 1. The financing system 1, the merchant system 2 and the lender system 3 may be general purpose data processing systems, which can be, or include, a suitably programmed general purpose computer, or network of general purpose computers, and other associated devices, including communication devices, and/or other circuitry or components necessary to perform the desired input/output or other functions. The financing system 1, the merchant system 2 and the lender systems 3 can also be implemented at least and part as single special purpose integrated circuits (e.g., ASICs), or an array of ASICs, each having a main or central processor section for overall, system- level control and separate sections dedicated to performing various different specific computations, functions and other processes under the control of the central processor section. The financing system 1, merchant system 2 and lender systems 3 can also be implemented using a plurality of separate dedicated programmable integrated or other electronic circuits or devices, e.g., hardwired electronic or logic circuits, such as discrete element circuits or programmable logic devices. The systems 1, 2 and 3 may also include other devices, such as an information display device (e.g., a computer monitor or printer), user input devices, such as a keyboard, user pointing device, touch screen or other user interface, data storage devices, such as the memory 40 which may include magnetic disk or tape storage devices, volatile or non- volatile semiconductor devices, optical disk storage devices, etc., communication devices or other electronic circuitry or components. The information source 4, like the financing system 1, the merchant system 2 and the lender system 3, may be one or a network of general purpose computers and/or other devices necessary to perform the desired input/output or other functions. The information source 4 may also be, or include, an Internet web site, a public or private database or any other device or system capable of providing information to the financing system 1.

The financing system 1, merchant system 2 and lender systems 3 may communicate using any type of communication system, such as wired or wireless telecommunications networks, radio or infrared communications systems, the Internet, one or more wide-area or local-area networks, and the like. In addition, although Fig. 1 shows only one merchant system 2 and one information source 4, two or more merchant systems 2 and/or information sources 4 may be used. The invention is likewise not limited to three lender systems 3, but may use one or more lender systems 3. As discussed above, two or more financing systems 1 that are regionally and/or internationally distributed may be linked to each other.

Fig. 2 is a more detailed schematic block diagram for the financing system 1 of Fig. 1. In this illustrative embodiment, the process controller 10 includes a plurality of modules 10a- 10k that can be implemented as software modules that are executed by the process controller 10. The process controller 10, the merchant process module 20 and the lender process modules 30 may be implemented as software modules written in any suitable programming language that are executed on the financing system 1 or any other suitable data processing apparatus in any suitable environment. Alternately, these modules may be implemented as hard-wired electronic circuits or other programmed integrated or other electronic circuits or devices, e.g., hardwired electronic or logic circuits, such as discrete element circuits or programmable logic devices.

A database 41 can be used to store any information, such as credit or financing application information, and can be maintained in the memory 40. The database 41 may have any format and may be a collection of two or more different databases.

The process control Application Programming Interface (API) 10a handles communications between the merchant system 2 or other devices and the process controller 10. For example, if the financing system 1 is Internet-based, the process control API 10a may control communication between the process controller 10 and a web server or other device that handles communication between the financing system 1 and merchant systems 2. The process control API 10a may also include a parser that parses information sent from the merchant system 2 so that data fields in the information may be extracted. That is, the process control API 10a may be configured to handle communications with different merchant systems 2 that may use different communication file transfer formats.

The process manager 10b implements processes executed by the process controller 10, such as the merchant process module 20 or the lender process modules 30. The processes implemented by the process manager 10b may be described in metadata and defined as a flow chart, such as that shown in Fig. 3. The flow charts may implemented, or cause the process manager 10b to implement, any of the other managers or modules in the process controller 10. Thus, the process manager 10b can act as a central process manager that uses other modules and managers to execute a process. The flow chart shown in Fig. 3 is only one example of a process that may be implemented by the process manager 10b and will be described in more detail below.

Describing lender decisioning processes in metadata that may be defined in a flow chart form allows the financing system 1 to host a plurality of different lender process modules 30 (and/or merchant process modules 20) that might otherwise require different hardware, software, operating systems, communication formats, and so on. That is, typical lender processes cannot be simply combined together to operate within a same financing system because the processes typically require a specialized environment in which to operate and contain the proprietary knowledge of the lender. In addition, modifying typical lender processes can be a complex programming task, and is frequently avoided for fear of affecting other portions of the lender process. However, the process controller 10, and other aspects of the financing system 1, allow lender decisioning processes to be efficiently and reliably modified and/or allows new lender decisioning processes to be added to the financing system 1 without requiring complex programming, affecting the operation of other lender process modules 30 or affecting the operation of the financing system 1 as a whole.

For example, an existing lender process may be modified by a process controller 10 (e.g., using a process controller 1 Ob) directing the display of a lender process in the form of a flow chart on a graphical user interface. Portions of the flow chart, such as decision boxes or action boxes, may be deleted, moved or otherwise modified by an operator, or portions of other existing lender process flow charts may be inserted into the flow chart by an operator using graphical interface tools to adjust the lender process. Thus, modifying or creating a lender process in the financing system 1 may be performed at a more conceptual level without requiring complex computer programming or altering programming code.

Although only one process manager 10b is shown in Fig. 2, the process controller 10 may have two or more process mangers 10b that are memory resident, and thus need not be loaded from permanent memory before a process can be executed. That is, two or more process managers 10b, and greater than five process managers 10b, may be configured to be ready to implement a process when requested, rather than requiring that the process manager 10b be retrieved from a memory, such as a non- volatile storage device that is part of the memory 40, and loaded into active memory. For example, two or more process managers 10b may be software loaded into a RAM that is accessed by a central processing unit to execute the software. Maintaining two or more process managers 10b in active memory decreases the amount of time needed to implement different processes in the financing system 1, and thus allows the capacity of the financing system 1 to handle processes to be linearly related to the hardware required to implement the processes. However, the process managers 10b need not be memory resident and may be driven on a task basis. That is, process managers 10b may be started, e.g., retrieved from memory and loaded into active processor memory, when a particular process is implemented. Starting process managers 10b on a task basis may cause some delay in implementing processes since some lag time waiting for the process manager 10b to start up may be incurred before a process is executed. Events, or processes to be implemented, may be queued in a message queue to reduce database access and polling. Thus, memory-resident process managers 10b may check the message queue for any related tasks and implement related tasks in a single batch. As an example, related tasks may be processes that require implementation of the same manager, such as the knowledge manager lOd.

The interface manager 10c handles interface layouts and field mappings of data supplied from the merchant system 2 and lender systems 3. For example, a user of the merchant system 2 may enter loan application data using a graphical user interface. The interface manager 10c can track the layout and field mapping of the graphical user interface used at the merchant system 2 so that data supplied using the graphical user interface can be accurately parsed by the process control API 10a. The interface manager 10c can also track changes in the layout and field mappings of the graphical user interface to allow the process control API 10a to accurately parse data supplied using the new graphical user interface. Therefore, the interface manager 10c may reduce implementation cycle time by adding, changing or creating user interface layouts that allow for new data formats to be parsed without changing the parser in the process control API 10a. The interface manager 10c may also include a listener module that actively waits for and detects incoming messages, such as file transfer protocol messages in a message queue.

The knowledge manager lOd contains a collection of rales that are used to process a financing application. For example, the knowledge manager lOd may include, or use, decision trees, scorecards, pricing models, underwriting flags and covenants when the process manager 10b is implementing a loan application decisioning process. For example, the process manager 10b can invoke the knowledge manager to apply tools to the application information or credit information. The knowledge manager 10b allows evaluation logic for a lender to be flexibly represented and easily modified since new rules and knowledge base can be added when suitable. As with the other managers 10c- 10k, a process implemented by the process manager 10b may implement the knowledge manager lOd as required. Thus, one or more steps in the flow chart defining the process implemented by the process manager 10b may include a call to any of the managers 10c- 10k. The communication manager 1 Of acts as an external interface to information sources 4. The communication manager 1 Of may implement communication protocols, such as TCP/IP, HTTP, dial-up, etc.) using metadata. The metadata for the communication manager lOf is formed based on the communication protocol of the information source 4. Therefore, the communication manager 1 Of allows new information sources 4 to be integrated into the financing system 1 easily, and allows new information products offered by existing information sources 4 to be easily added. The scoring manager lOg implements scoring algorithms that may be based on metadata. The scoring manager lOg may implement any number of different scoring algorithms that are defined by merchants, lenders or other users of the financing system 1. The scoring manager lOg may also include evaluation parameter normalization algorithms (e.g., to normalize scoring values provided by different sources so that the values may be used on a same valuation scale), relative weighting algorithms, and exception handling algorithms that may operate at a factor level.

A repository manager lOh may hold all the metadata information about the transaction level database 41 in a metadata format. Thus the other managers lOb-lOg and 1 Oi -1 Ok may use the metadata information in the design of a process or metadata for other managers and when executing a process.

The integrity manager lOi ensures that one or more integrity rules have been met before any data that enters the financing system 1 is modified. For example, credit information for an applicant that is provided as current through a specific time in the Pacific Time zone may normally be changed within the financing system 1 to reflect the equivalent time in the Eastern Time zone of the United States. However, the integrity manager lOi ensures that a particular rule has not been violated before the time information is modified. For example, a specific lender may require that times not be adjusted based on time zone for a particular application approval process.

The API adapter lOj and other adapters 10k handle the communications between the process controller 10 and lender systems 3 or information sources 4. The other adapters 10k may be configured specifically to handle communications with a particular lender 3 or information source 4. The API adapter lOj may serve as a layer between the other adapters 10k and the managers lOb-lOi in the process controller 10. This configuration allows the financing system 1 to adapt flexibly to different lender systems 3, information sources 4 or other systems, such as other service providers.

Fig. 3 is a flow chart of steps in an exemplary lender financing application evaluation process. It should be understood that the method shown in Fig. 3 has been simplified and is used herein to generally describe the operation of the process managers 10b and some of the other managers in the process controller 10.

In step S305, a process manager 10b invokes the scoring manager lOg and the knowledge manager lOd to apply to a financing application internal rules defined by the lender. The internal rules may be a preliminary screening of the financing application to determine if the application may be denied without accessing credit information for the application. The internal rules may include determining whether the application is complete, determining if the requested loan amount is above maximum or below minimum threshold values, and so on. In step S310, if the conditions are not met, control branches to step S315 where the application is denied, and flow jumps to step S340. Otherwise, in step S320, the process manager 10b invokes the communication manager lOf to call a credit information process. The credit information process may include processes for identifying a best information source for the credit information and actually obtaining the credit information.

In step S325, a determination is made whether sufficient credit information has been retrieved. If not, the application is denied in step S330 and flow jumps to step S340. Otherwise, in step S335, the process manager 10b invokes the scoring manager lOg to analyze the credit information and application information to render a decision. Analysis of the credit and application information may involve any suitable criteria and evaluation algorithms. In step S340, the process manager 10b invokes the interface manager 10c to transfer the decision information to the applicant and the lender.

Fig. 4 is an illustrative embodiment in which the financing system 1 communicates with a merchant system 2 over the global Internet 111, and communicates with lender systems 3 and an information source 4 over a more private communication system, such as a private telecommunications network 112. Therefore, the merchant system 2 communicates with the financing system 1 via a web server 11. The web server 11 communicates with an application server 12, in which the process controller 10 (not shown in this figure) is implemented. A database server 13 provides information to the application server 12, such as metadata, messages from lender systems 3, information from information sources 4 or other information stored on the database 41.

Fig. 5 is a flow chart of steps of a method for processing financing application information in accordance with an illustrative embodiment of the invention. In step S10, a financing application is received from an applicant. The financing application may be a loan application, a factoring offer, a credit line application, or other request for financing services. In this example, a loan application is received from the applicant. The loan application may be received directly from the loan applicant or provided by a merchant from which the applicant wishes to purchase a good or service. The financing application may be received in electronic form. For example, loan application information may be provided using a graphical user interface, and the completed application information may be received over the Internet or other communication system. Any suitable data format and/or communication protocol may be used to receive the financing application.

In step S20, an optional step of performing a merchant financing application process may be performed. The merchant financing application process may involve determining whether the merchant will self-finance a loan application or submit the loan application to a lender. Self-financing may mean that a merchant submitting an application will assume the risk of a loan, or access an existing line of credit for the loan. The merchant financing application process may include a preliminary screening or veracity check of the financing application to determine if the application can be denied without obtaining credit information.

Fig. 6 shows steps in a flow chart for performing a merchant financing application process that may be used in step S20 of Fig. 5. In step S210, a determination is made whether self-financing is an option for the merchant. This decision may involve determining whether the merchant is currently financially able to self-finance the loan, or may be based on a percentage number of applications over a past time that were self- financed by the merchant. If the percentage of self-financed applications is greater than a threshold percentage, a determination may be made that self-financing is not an option, for example. Step S210 may include a preliminary analysis of the application to identify applications that are clearly not suitable for self-financing and/or submission to a lender. For example, a determination may be made that the requested loan amount is too small or too large, or the application may be scored, at least preliminarily, to determine whether the application presents an acceptable risk level for the merchant.

In step S220, a self-finance process is performed. The self-finance process may involve evaluating a loan application and credit information for the loan applicant to determine if the credit risk is acceptable to the merchant. The self-finance process may also involve determining whether an existing credit line for the merchant is available and whether the required financing could be financed through the existing credit line.

In step S230, if the loan is to be self-financed, flow jumps to step S50 in Fig. 5. If the loan is not to be self-financed, flow jumps to step S30 in Fig. 5.

Fig. 7 is a flow chart of steps of a method for performing a self-finance process in an illustrative embodiment that may be used in step S220 of Fig. 6. In step S221, a determination is made whether a credit line exists for the merchant and if the credit line is sufficient to finance the loan. If so, flow jumps to step S50 in the flow chart of Fig. 5. Otherwise, in step S223, credit information for the loan applicant is obtained. This step may involve accessing one or more credit information suppliers and compiling credit information from one or more information sources. A determination of the best source for credit information for a particular application and/or applicant may also be made. For example, a particular information source may provide more reliable credit information for the applicant than other information sources. Alternately, a first information source may provide better credit information for certain information items, but a second information source may provide better credit information for other items. For example, a first information source may provide more accurate legal name and address information for an applicant, whereas a second information source may provide more accurate payment history and lien information for the applicant. In such a case, credit information may be obtained from the two information sources, and selected portions of the reports extracted for later use.

In step S224, the credit risk of the loan application is evaluated. This step may involve conventional loan application and credit information scoring techniques and/or other processes. For example, the credit information obtained in step S223 may be checked against the loan application information to determine if the loan application information or the credit information is accurate. For example, a veracity check may be made to determine if the annual income of the applicant provided in the loan application matches income information obtained in the credit information, and/or the address of the applicant provided in the application may be compared to the address listed in the credit information, e.g., to confirm that the credit information is for the applicant and not another person or entity. Other checks may be made to confirm that the person or entity submitting the application is actually the listed applicant, e.g., by comparing information in the application with credit information or other information (such as a password) for the applicant. Discrepancies between information supplied in a loan application and credit information may suggest that the person or entity submitting the application may not be the actual listed applicant. Such information and integrity/authentication checks may be used to evaluate the overall veracity of the loan application and credit information and thus be used in scoring the overall credit risk.

In step S225, a determination is made whether the loan presents an acceptable risk to the merchant. If the risk is acceptable, flow jumps to step S50 in Fig. 5. Otherwise, flow jumps to step S30 in Fig. 5.

In step S30 of Fig. 5, at least one of a plurality of lender processes configured to operate on a same central data processing system are selected to process the financing application. For example, two or more lending institutions may agree to have loan application processing modules installed in a same loan financing system. The financing application may be submitted to one or both of the lender processes, either serially or in parallel. Selection of the lender processes to which the financing application is submitted may be based on merchant-defined criteria. For example, a merchant may define a default list of lenders such that loan applications are submitted to a first lender process for decision, and then if the application is declined, the application is submitted to a second lender process, and so on. Alternately, the merchant may define a selection process in which a particular lender is provided with a certain percentage of the merchant's overall loan applications, and/or submitted the best or lowest risk applications. The merchant may also define a process by which loan applications are graded according to a merchant application evaluation process, e.g., according to conventional loan application evaluation processes, so that applications of different grades may be submitted to different lenders or groups of lenders. Alternate selection processes will occur to those of skill in the art. For example, all lender processes operating in the financing system may be submitted an application, and the lender whose process that first returns a positive response is awarded the application. In step S40, the financing application is processed using the selected lender process. Processing of the financing application may involve traditional techniques for evaluating the credit history of an applicant and the loan application to score the application and credit information. However, the processing of the financing application may include a veracity check or other evaluation processes as the invention is not necessarily limited in the way in which financing applications are evaluated.

In step S50 of Fig. 5 financing decision information is provided to the merchant or other entities. This may involve indicating that one or more lender processes have accepted or denied the financing application, and if the application was accepted, may include legal forms and other papers for execution by the applicant, guarantors, or other necessary parties. Execution of the papers to consummate the financing transactions may involve using digital signatures or printing the papers and executing the papers by hand. The executed forms may then be sent back to the central financing system. If a decision was made to access a line of credit open to the merchant, the merchant and lender that provides the line of credit may be notified and a take-down transaction executed to reflect the amount of credit used to finance the loan.

Fig. 8 shows a flow chart of steps of a method for processing a financing application in accordance with an illustrative embodiment of the invention that may be used in step S40 of Fig. 5. In step S405, credit and application information is obtained. Application information may be obtained as part of the original financing application. For example, a merchant may submit a loan application that has complete applicant information, such as applicant's name, income, address, current place of work, etc. The application information may be provided by using a graphical user interface and submitting the information electronically. Credit information may be obtained from any of the known credit bureaus or other information sources in any suitable way. Obtaining credit information may also involve a preliminary step of identifying a set of information sources that will provide a best set of credit information for the evaluation process. For example, one credit bureau may provide more reliable information for an individual living in a certain region compared to other credit bureaus. Alternately, certain information sources may be known to provide better information for certain types of information compared to other information sources. Thus, credit information may be obtained from a plurality of information sources and the highest quality information selected from each of the information sources.

In step S410, a determination is made whether the credit and application information is complete. If yes, flow jumps to step S420. Otherwise, in step S415, a request for additional information is made. If the loan application information is incomplete, a request may be sent to the merchant for additional application information. For example, a loan application may not have provided complete information for one of the application data fields. Additional information requested from the merchant may include a request for a guarantor, a request for additional collateral, an alteration in the financing terms and conditions, or other suitable information that may alter the outcome of the application evaluation process. If the credit information is incomplete, alternate information sources may be accessed in an effort to obtain the information, and/or a request may be sent to the merchant to supply the required credit information. In step S420, lender evaluation criteria is applied to the application and credit information. For example, a lender evaluation process may be applied to score the application and credit information. Such techniques for evaluating application and credit information vary widely and are well known to those in the art.

In step S425, a determination is made whether the application presents an acceptable credit risk. If so, flow jumps to step S50 in Fig. 5. Otherwise, a determination is made in step S430 whether to advise the lender that the application does not pose an acceptable credit risk according to the evaluation criteria applied in step S420. If the lender is not to be advised, flow jumps to step S50 in Fig. 5. Otherwise, in step S435, the lender is advised and requested if additional information should be requested, whether the evaluation criteria should be adjusted, or if the lender will render a decision on the application apart from the automated lender evaluation process.

In step S440, if additional information is to be requested, flow jumps back to step S415. Otherwise, in step S445 a determination is made whether the lender will provide the decision. If not, flow jumps to step S50 in Fig. 5. Otherwise, in step S450, the lender decision is received. The lender decision may be made using a manual application evaluation process at the lender's offices, by applying of a combination of automated and manual evaluation processes on a lender processing system, or other suitable method. The decision may be received electronically, such as over a telecommunications connection between a central financing system and a lender system. By not automatically denying a financing application when the application does not present, at least initially, an acceptable risk, the loan application is "kept alive" so that alternate solutions for approving the financing application may be explored. As a result, an applicant need not receive a string of application denials and be required to complete another financing application with different terms and conditions, including additional collateral, guarantors, and so on in order to obtain financing. Instead, the applicant may submit a single financing application, and if the application does not initially present an acceptable risk level for a lender, the lender may choose to alter the evaluation criteria, obtain additional information from the applicant, or evaluate the application in another way. This type of interactive and potentially iterative process may speed the time between submitting a financing application and ultimate acceptance by a lender. Fig. 9 is a flow chart of steps in a method for obtaining credit information. The method shown in Fig. 9 may be used, for example, to obtain credit information in step S405 of Fig. 8 and has been found to be useful in obtaining consumer credit information. In step S905, a variable check Jevel is set to zero (0). The variable check Jevel is used in this example to track the iteration level of the credit information gathering process. However, the iteration level may be tracked in other ways.

In step S910, a determination is made whether a special credit information source, or bureau, will be used. For example, a particular merchant or lender may specially request that a particular bureau, such as Trans Union, Experian or Equifax, always be used to obtain credit information. In this case, the special bureau request is identified in step S910 and flow jumps to step S925. Otherwise, flow continues to step S915.

In step S915, checkjevel is incremented to the next level, e.g., checkjevel may be incremented to the next higher integer.

In step S920, a bureau selection process is implemented to identify a bureau to be accessed for credit information. The selection of a bureau may be based on any suitable information. For example, a zip code or other geographic identifier for the applicant may be used to identify a bureau, e.g., a bureau that provides a highest quality credit information for individuals or companies within the applicant's geographic region. In addition, bureaus may be ranked in order of the expected quality of information that the credit bureaus will provide. Therefore, a highest quality provider may be accessed first, followed by a next highest quality provider, and so on, if necessary. Criteria other than geographic region may be used to rank bureaus, and other bureau selection processes may be used, and may be customized for the particular merchant, lender, or other party that is requesting and may use the information.

In step S925, a determination is made whether a previous bureau report has been obtained. For example, a bureau report or other set of credit information may have been obtained for the applicant during a recent loan application process. If a previous report exists, a determination is made in step S930 whether the prior report should be overwritten. If so, flow jumps to step S935, in which credit information provided by the bureau identified in either step S910 (a special bureau) or in step S920 is accessed, e.g., a bureau may be identified in step S920 based on a bureau ranking and selection of the bureau that corresponds to the iteration level represented by checkjevel. In step S940, a determination is again made whether a special bureau was requested. If so, the process ends. Otherwise, a determination is made in step S945 whether credit information provided in step S935 is insufficient. If not, the bureau record is updated with the obtained credit information. If the information is insufficient, a determination is made whether checkjevel is equal to a maximum value, i.e., a maximum number of credit information gathering iterations. If so, the process ends. Otherwise, flow jumps to step S915 so that checkjevel may be incremented, and a next bureau selected in step S920 for gathering additional credit information in another iteration of the credit information gathering process. Therefore, the process will continue to check if the credit information is complete or not, and if not, a next bureau will be accessed in an attempt to complete the needed credit information. Insufficient information may be detected if not enough tradelines were available in the report, if a high credit report was not available, if the credit report obtained was older than a threshold number of days, or other factors.

Fig. 10 is a flow chart of steps in a method for obtaining credit information. The method shown in Fig. 10 may be used, for example, to obtain credit information in step S405 of Fig. 8, and has been found to be useful in obtaining credit information for businesses.

In step SI 005, a determination is made whether a special credit information source, or bureau, will be used. For example, a particular merchant or lender may specially request that a particular bureau, such as Dun & Bradstreet or Experian, always be used to obtain credit information. In this case, the special bureau request is identified in step S1005 and flow jumps to step S1015. Otherwise, flow continues to step S1010. In step SI 010, a bureau is selected to access credit information. As in other examples above, the selection of a bureau may be based on any suitable information. For example, a zip code or other geographic identifier for the applicant may be used to identify a bureau, e.g., a bureau that provides a highest quality credit information for companies within the applicant's geographic region. In addition, bureaus may be ranked in order of the expected quality of information that the credit bureaus will provide. Therefore, a highest quality provider may be accessed first, followed by a next highest quality provider, and so on, if necessary.

In step SI 015, a determination is made whether a reference number, or other identifier, used by the selected bureau for the applicant is available. This reference number may be supplied by the applicant in the application information or may otherwise be known, e.g., retrieved from a database. The reference number can help to ensure that credit information is obtained for the applicant and not another entity, thereby improving the validity of the evaluation process. If the reference number is available, a determination is made in step SI 020 whether to override previously gathered information for the applicant, e.g., if credit information for the applicant has been previously obtained and stored in a database. If not, flow jumps to step SI 040. Otherwise, flow jumps to step S1035.

If the reference number for the applicant is not available, in step SI 025 a determination is made whether a list of applicant name similars is available. The list of similars may include a list of names commonly used, or misused, for a particular company and may be stored in a database of a central financing application system, provided by a lender or information source, or otherwise obtained. The list of similars can be used to compare the applicant name provided in the application with similar names listed for a particular entity so that the actual legal name of the applicant, or other name used for credit information purposes, can be identified.

If a list of similars is available, flow jumps to step SI 035. Otherwise, in step S1030 the applicant's identity, i.e., the applicant's legal name, or name or other identifier used for credit information purposes, is resolved. A variety of different processes may be used to perform such resolution, such as performing fuzzy matching of the applicant's name provided in the application with other company names listed in a variety of different public and/or private databases, having a human operator inspect the provided applicant name to resolve the name, and so on.

In step SI 035, the business type and/or financing application type is identified and the bureau accessed. Determining the business type may involve determining if the applicant is a small business. Determining the financing application type may involve determining a personal guarantor has been provided. These determinations can be used to determine the credit information product that is accessed. For example, if the applicant is a small business, a score appropriate for small businesses may be pulled. If the applicant is not a small business, a score more appropriate for a commercial business may be pulled. In step S 1040, a determination is made whether the credit information criteria is met. If not, flow jumps back to step SI 010 so another bureau may be selected and additional credit information obtained, if available. Determining if the credit information criteria are met may involve determining if all credit information needed to evaluate the applicant's financing application has been received. Fig. 11 is a schematic block diagram of another illustrative embodiment of the invention in which two financing systems la and lb are linked to each other. In this embodiment, the financing systems la and lb are physically located in geographically separate areas, such as in different continents. In this embodiment, a seller 2a communicates with the financing system la, and a buyer 2b and lender 3 communicates with the financing system lb. As one example, the seller 2a and buyer 2b have agreed to a sale of goods. The buyer 2b would like to finance the transaction, and thus submits a financing application to the financing system lb. Alternately, the seller 2a may submit a financing application to the financing system la on behalf of the buyer 2b, e.g., in the case that the buyer 2b cannot, or does not, communicate with the financing system lb. In such a case, the financing system 1 a may determine that the financing application should be referred to the financing system lb because the buyer 2b is located in a different country than the financing system la. Therefore, the financing system la may refer the financing application submitted by the seller 2a to the financing system lb. Once the financing application has been referred, the financing system lb may process the application, e.g., by obtaining credit information from one or more information sources 4 and submitting the application to a lender process hosted on the financing system lb. Once a financing decision has been rendered, the decision information can be reported to the lender, and the seller 2a or the buyer 2b. Additional information, if required, may be requested from the buyer 2b and/or from the seller 2a through the financing system la.

This distributed arrangement of financing systems 1 may advantageous, since the financing system la may be configured to deal primarily with merchants 2, lenders 3 and information sources 4 that operate in a geographic region or country local to the financing system la and not with merchants 2, lenders 3 or information sources 4 in other geographic regions or countries. Therefore, the distributed financing system 1 configuration allows financing applications to be referred to appropriate financing systems 1 depending upon the situation. Alternately, using the example described above, if the financing system la had not referred the financing application to the financing system lb, the financing system la may request the financing system lb to gather required credit information from the information source 4 and send the information along with a suitable lender 3 evaluation process to the financing system la for processing. Accordingly, the financing system la need not be configured to communicate with the information source 4, but rather only need be configured to communicate with the financing system lb, which is configured to communicate with the information source 4, the lender 3 or other devices. The financing system lb can, therefore, translate information into a format common to both the financing systems la and lb.

While the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, preferred embodiments of the invention as set forth herein are intended to be illustrative, not limiting. Various changes may be made without departing from the spirit and scope of the invention.

Claims

1. A centralized financing application processing system, comprising: a memory; a process controller that receives a financing application including financing application information and sends financing decision information; and a plurality of lender process modules operating under the control of the process controller, each of the lender process modules adapted to receive financing application information sent from the process controller and render a financing decision based on the financing application information.

2. The system of claim 1, wherein each of the lender process modules is associated with a different lending institution.

3. The system of claim 1 , further comprising: a merchant process module that determines a set of lenders to submit a financing application to based on merchant specified criteria.

4. The system of claim 3, wherein the merchant process module performs a preliminary evaluation of the financing application information to determine if the application can be denied without accessing credit information for the applicant or grade the financing application to determine a set of lenders to receive the financing application.

5. The system of claim 1 , further comprising: a merchant-processing module that identifies at least one lender process module to which to submit a financing application based on merchant specified criteria.

6. The system of claim 5, wherein the merchant process module identifies a plurality of lender process modules and the financing application is submitted to the lender process modules in a sequential fashion.

7. The system of claim 6, wherein the financing application is sent to a next lender process module when a previous lender process module declines the financing application.

8. The system of claim 1, further comprising: a merchant process module that determines whether a financing application should be self-financed by a merchant that submitted the financing application or whether the financing application should be submitted to one of the lender process modules.

9. The system of claim 8, wherein the merchant process module determines whether an existing credit line exists for the merchant in determining whether the financing application should be self-financed.

10. The system of claim 1, further comprising: a merchant process module that is adapted to perform a veracity check by comparing information in obtained credit information with information provided in the financing application.

11. The system of claim 10, wherein the merchant process module compares financing application information with credit information to determine at least one of whether the financing application information is accurate and whether an applicant that submitted the financing application information is actually the applicant listed in the financing application.

12. The system of claim 1 , wherein the process controller under specified conditions sends the financing application to a lender that does not have an associated lender process module operating under the control of the process controller.

13. The system of claim 1 , wherein each of the lender process modules implements a same method for obtaining and processing credit information.

14. The system of claim 1, wherein the process controller comprises a plurality of memory-resident process managers.

15. The system of claim 14, wherein each of the process managers is adapted to implement a process represented by metadata stored in the memory.

16. The system of claim 14, wherein each of the process managers implements a process represented by a flow chart stored in the memory.

17. The system of claim 1, wherein at least one of the lender process modules is adapted to allow an applicant or a lender to interact with the lender process module while the lender process module is processing the applicant's financing application.

18. The system of claim 17, wherein the at least one lender process module is adapted to notify the applicant or the lender if the financing application will be denied without further information being provided by the applicant or the lender.

19. The system of claim 18, wherein the lender process module is adapted to allow the lender to one of indicate further information that is requested from the applicant, and stop the lender process module from processing the financing application and take over further processing of the financing application.

20. The system of claim 18, wherein the lender process module is adapted to request further information from the applicant so that the financing application can be approved.

21. The system of claim 20, wherein the requested information includes at least one of a guarantor for a requested loan amount, collateral for a loan amount, a reduction in a requested loan amount, and an adjustment in lending terms and conditions.

22. The system of claim 17, wherein at least one lender process module is adapted to stop processing of a financing application to allow fuither processing of the financing to be performed manually or by another financing application evaluation process.

23. The system of claim 1 , wherein the process controller sends financing decision information that includes at least one of an indication that the financing application has been accepted or denied, a set of documents for consummating a financing application acceptance, and an indication that a line of credit has been accessed.

24. The system of claim 1, wherein at least one of the lender process modules determines a best credit information source from which to obtain credit information to process the financing application.

25. The system of claim 24, wherein the at least one lender process module accesses credit information sources in order of expected information quality if a best credit information source does not provide sufficient credit information.

26. The system of claim 1 , wherein at least one lender process module is adapted to perform a veracity check by comparing information in obtained credit information with information provided in the financing application.

27. The system of claim 26, wherein the at least one lender process module compares financing application information with credit information to determine at least one of whether the financing application information is accurate and whether an applicant that submitted the financing application information is actually the applicant listed in the financing application.

28. The system of claim 1, wherein a plurality of lender process modules are adapted to render a financing decision to approve at least a portion of the financing application.

29. The system of claim 28, wherein the plurality of lender process modules are adapted to form a syndication in which each lender process module approves a component of the financing application.

30. A method for processing a financing application on a centralized data processing apparatus, comprising: receiving financing application information; selecting at least one of a plurality of lender processes each of which is associated with a lender and is hosted on a centralized data processing apparatus; evaluating the financing application using the selected at least one lender process; and providing financing decision information based on the evaluation by the selected at least one lender process.

31. The method of claim 30, wherein the step of receiving financing information comprises: receiving electronic financing application information over a communications system.

32. The method of claim 30, wherein the step of receiving financing information comprises: receiving electronic financing application information provided by a merchant on behalf of an applicant; and wherein the step of selecting at least one of a plurality of lender processes comprises: determining a set of lenders to which to submit a financing application based on merchant specified criteria.

33. The method of claim 32, wherein the step of determining a set of lenders comprises: performing a preliminary evaluation of the financing application information to determine if the application can be denied without accessing credit information for the applicant or grade the financing application to determine a set of lenders to receive the financing application.

34. The method of claim 30, wherein the step of receiving financing information comprises: receiving electronic financing application information provided by a merchant on behalf of an applicant; and wherein the step of selecting at least one of a plurality of lender processes comprises: identifying at least one lender process to submit the financing application based on merchant specified criteria.

35. The method of claim 34, further comprising submitting the financing application to a next lender process when a previous lender process declines the financing application.

36. The method of claim 30, wherein the step of receiving financing information comprises: receiving financing application information provided by a merchant on behalf of an applicant; and determining whether a financing application should be self-financed by the merchant that submitted the financing application or whether the financing application should be submitted to one of the lender processes.

37. The method of claim 36, wherein the step of determining whether a financing application should be self-financed comprises: determining whether an existing credit line exists for the merchant.

38. The method of claim 30, further comprising: sending the financing application to a lender that does not have an associated lender process hosted on the centralized data processing apparatus.

39. The method of claim 30, wherein the step of evaluating the financing application comprises: implementing a same, standardized method for obtaining and processing credit information for a plurality of lender processes.

40. The method of claim 30, wherein the step of evaluating the financing application comprises: maintaining a plurality of memory-resident process managers on the centralized data processing apparatus.

41. The method of claim 40, wherein the step of evaluating the financing application comprises: implementing a process represented by metadata.

42. The method of claim 40, wherein the step of evaluating the financing application comprises: implementing a process represented by a flow chart.

43. The method of claim 30, wherein the step of evaluating the financing application comprises: allowing interaction between at least one of an applicant and a lender and an associated lender process while the lender process is processing the applicant's financing application.

44. The method of claim 43, wherein the step of allowing interaction comprises: notifying at least one of the applicant and the lender if the financing application will be denied without further information being provided by the applicant or the lender.

45. The method of claim 43, wherein the step of allowing interaction comprises: allowing the lender to one of indicate further information that is requested from the applicant, and stop the lender process from processing the financing application and take over further processing of the financing application.

46. The method of claim 43, wherein the step of allowing interaction comprises: requesting further information from the applicant so that a final financing decision for the financing application can be made.

47. The method of claim 46, wherein the step of requesting comprises: requesting one of a guarantor for a requested loan amount, collateral for a loan amount, a reduction in a requested loan amount, and an adjustment in lending terms and conditions.

48. The method of claim 30, wherein the step of evaluating the financing application comprises: determining a best credit information source from which to obtain credit information to process the financing application.

49. The method of claim 48, wherein the step of evaluating the financing application comprises: accessing credit information sources in order of expected information quality if a best credit information source does not provide sufficient credit information.

50. The method of claim 30, further comprising: performing a veracity check by comparing information in obtained credit information with information provided in the financing application.

51. The method of claim 50, wherein the step of performing a veracity check comprises at least one of: comparing financing application information with credit information to determine whether the financing application information is accurate; and comparing financing application information with credit information to determine whether an applicant that submitted the financing application information is actually the applicant listed in the financing application.

52. The method of claim 30, wherein the step of evaluating the financing application comprises: determining at one lender process module to approve at least a portion of the financing application.

53. The method of claim 52, wherein the step of evaluating the financing application comprises: forming a syndication in which a plurality of lender processes each approves a component of the financing application.

54. The method of claim 30, further comprising: interrupting automated processing by at least one selected lender process; and evaluating the financing application using a manual evaluation process.

55. A method for obtaining credit information in a computerized financing application evaluation process, comprising: identifying a first selected credit information source; accessing credit information from the first selected credit information source; determining if the credit information is sufficient; identifying a second selected credit information source; and accessing credit information from a second selected credit information source.

56. The method of claim 55, wherein the step of identifying a first selected credit information source comprises: identifying a geographic region in which a financing applicant is located; and identifying a credit information source that is expected to provide best credit information for the identified geographic region.

57. The method of claim 55, wherein the step of identifying a first selected credit information source comprises: determining if a special credit information source has been designated as a first selected credit information source.

58. The method of claim 55 , further comprising : determining if an applicant identifier used by a selected credit information source to refer to a financing applicant is available; determining if a list of similar identifiers for the financing applicant is available if the applicant identifier is not available; determining an applicant identifier using the list of similar identifiers if the list of similar identifiers is available; resolving an applicant identifier if the list of similar identifiers is not available; and accessing credit information from the selected credit information source using the applicant identifier.

59. The method of claim 58, wherein the step of determining an applicant identifier using the list of similar identifiers comprises: comparing an applicant name provided in financing application information with a stored list of names, the list of names including sets of names for a plurality of different entities, each set of names including one or more informal names and a corresponding legal name for a corresponding entity; and identifying an applicant identifier as the legal name that corresponds to a set of names in which the provided applicant name is found.

60. The method of claim 58, wherein the step of accessing credit information from the selected credit information source using the applicant identifier comprises: determining at least one of a business type and a financing application type; and accessing a credit information product based on the determined at least one of a business type and a financing type.

61. The method of claim 55, further comprising: performing a validity check of credit information by comparing credit information with information obtained from a financing application.

62. A method for processing a financing application on a centralized data processing apparatus, comprising: receiving financing application information; selecting at least one of a plurality of lender processes each of which is associated with a lender and is hosted on a centralized data processing apparatus; invoking at least one process manager to evaluate the financing application using the selected at least one lender process; and providing financing decision information based on the evaluation by the selected at least one lender process.

63. The method of claim 62, wherein the step of providing financing decision information comprises: indicating that a plurality of lenders have rendered a financing decision to approve at least a portion of the financing application.

64. The method of claim 63, wherein the step of indicating comprises: indicating that a syndication has been formed in which each lender approves a component of the financing application.

65. The method of claim 62, further comprising: invoking at least one process manager to evaluate the financing application using another selected lender process if a first lender process denies the financing application.

66. The method of claim 65, further comprising: invoking at least one process manager to add a new lender process that is hosted on a centralized data processing apparatus.

67. The method of claim 66, wherein the step of invoking at least one process manager to add a new lender process comprises: generating a graphical interface that includes a flow chart representing at least a portion of the new lender process.

68. A financing application processing system, comprising: a first centralized application processing system comprising, a first memory, a first process controller adapted to receive a financing application including financing application information and send financing decision information, and a first set of lender process modules operating under the control of the first process controller, each of the lender process modules adapted to receive financing application information sent from the first process controller and render a financing decision based on the financing application information; and a second centralized application processing system geographically separated from and communicating with the first centralized application processing system, comprising, a second memory, a second process controller adapted to receive a financing application including financing application information and send financing decision information, and a second set of lender process modules operating under the control of the second process controller, each of the lender process modules adapted to receive financing application information sent from the second process controller and render a financing decision based on the financing application information; wherein the first and second centralized application processing systems are adapted to share financing application information and credit information so that a financing application can be processed at one of the first and second centralized application processing systems.