Financial Products with Consumer Protection Built-in for Future Time
Relationship banking and mobile banking are discussed and presented here. In Section 1, we present Pre-approval, Fulfillment, and Application Process. In Section 2, we present Financial Products for Protection of Consumers. In Section 3, we present Relationship-Based Score. In Section 4, we present Application of Credit Report for a “Binding” Pre-Approval for Lending Products. In Section 5, we present Deposit Slip Purchase. In Section 6, we present Reducing Frauds on Credit Cards. We also discuss the system and components, with different variations on system and method, or their designs.
The current application is related to another co-pending (Continuation of) application Ser. No. 13/222,123, now allowed, filed Aug. 31, 2011, titled “Methods and systems for financial transactions”. It claims benefit from the priority date of the prior application, and it incorporates by reference all the teachings of the prior application Ser. No. 13/222,123.
BACKGROUNDThe e-banking and e-commerce are becoming more and more integrated with our daily lives. We are introducing new concepts and teachings for relationship banking and mobile banking here, to improve on the current state of e-banking and e-commerce, with useful features for both the banks (financial institutions) and/or consumers.
Please note that U.S. Pat. Nos. 7,953,268 and 7,949,176 (assigned to Mitek Systems Inc.) teach the methods and systems for mobile image capture and processing of documents. The U.S. Pat. No. 7,899,853 teaches handheld computational device having securing elements. The U.S. Pat. No. 7,870,048 teaches method and system for flexible scheduling of repayment of a loan. The U.S. Pat. No. 7,392,216 (by Palmgren et al., from GE Capital Mortgage Corporation, filed Sep. 27, 2000, and issued Jun. 24, 2008) teaches methods and apparatus for utilizing a proportional hazards model to evaluate loan risk, with hazard rate and different variables. The U.S. Pat. No. 6,938,008 teaches loan modeler method and apparatus. However, none of the prior art teaches the features taught in this disclosure, as detailed below.
SUMMARYRelationship banking and mobile banking are discussed and presented here. In Section 1, we present Pre-approval, Fulfillment, and Application Process. In Section 2, we present Financial Products for Protection of Consumers. In Section 3, we present Relationship-Based Score. In Section 4, we present Application of Credit Report for a “Binding” Pre-Approval for Lending Products. In Section 5, we present Deposit Slip Purchase. In Section 6, we present Reducing Frauds on Credit Cards. We also discuss the system and components, with different variations on system and method, or their designs.
The systems and methods taught here help reduce the cost of processing for financial institutions/banks, and bring more customers for the bank, as well as more convenience and more options for the customers, in addition to faster processing of applications, which generally benefit all involved, including the economy, which benefits from easier circulation of money (e.g. more loans for small businesses, for more projects and new hiring).
Here are some examples/embodiments:
Section 1: Pre-Approval, Fulfillment, and Application Process
In this section, we are going to address the following 3 embodiments:
-
- Mobile instantly generated credit/debit/prepaid card fulfillment and usage
- Pre-approval Process on Mobile Devices for All Lending Products
- Lending Product Application (LPA) Process on Mobile Devices for All
“Funding-Financing-Usage” can be done using a check mailed or authorization or wire transfer or email to consumer, or a check to the dealer or merchant (e.g. car dealer, selling cars, with respect to a car loan applied by a consumer).
Fulfillment, specifically in some cases, may extend beyond the issuance and financing of the lending product, especially in the case of secured lending, where collateral serves as security for the lender's interest. However, both (A) secured and (B) unsecured lending follow the same process. (See e.g.
We include pre-paid and debit cards under the same category of lending products, since the lender floats the money on behalf of the user (or customer or consumer), until the funds from the user are accessed (sometimes instantaneously) from user's source of fund. Also, both products are subject to fraud, that is typically associated with credit cards and other lending products, and in contrast to cash financing of purchases, where typically no fraud occurs.
Whereas currently, all three steps are offered through various channels (e.g., internet, branch, phone, and fax), none is offered on mobile channels. In other words, customers (1) are not provided with lenders' pre-selection offers, (2) cannot apply and (3) cannot obtain approval, or receive the lending products on their mobile devices. In general, the fulfillment of secured ending products is more complicated, as compared to that of unsecured products. For example, for auto lending, verification of the value of the vehicle, title inspection, placing a lien by the lender on the title of the financed vehicle, and the whole department of motor vehicle title application (and transfer process) are very much involved, ultimately leading to the disbursement of funds to the dealer or the seller of the vehicle on behalf of the borrower by the lender.
Similarly, for financing a first mortgage or a home equity loan or line of credit, an appraisal of the real-estate property, borrower's income verification, and placing a lender's lien on the title are a few of the numerous steps needed in the fulfillment process. Whereas fulfilling a credit card application simply and only involves mailing the cardholder a plastic card in the mail and having the cardholder activate the card with the lender.
Summary for Pre-Approval Process on Mobile Devices for all Lending Products:
This is shown in
In general, the lists of targeted customers for these pre-selection routines comes from various sources, including but not limited to, existing customers of the lender or its affiliates and lists purchased or otherwise acquired from third-party suppliers. Such pre-selections may or may not involve the lender applying any kind of pre-selection criteria. These pre-selection notices are currently sent primarily through the following 3 channels: Internet (the lenders web site), email, and standard mail. Mobile channel has not been used for offering pre-approvals, pre-selections, ITAs, or pre-screenings.
Summary for Mobile Instantly Generated Credit/Debit/Prepaid Card Fulfillment and Usage
Please refer to
Please note that, generally, the credit card information comprises credit card number and expiration date, among others.
Please note that, generally, we have at least 3 situations covered here, as a few examples: first at the store/merchant; second on-line merchant; and third for cash withdrawal.
The inventions above enable mobile pre-selection, lending product application (LPA), decisioning (approval), and fulfillment and usage of various lending products offered by financial institutions. Whereas, our invention regarding fulfillment and usage by default assumes the customer is already an existing customer of the lender with varying extent in depth of relationship with the lender, the customer or applicant for the lending product may or may not be an existing customer with the lender. In such cases, the customer or applicant must be given the opportunity to establish a new account via the mobile device app (MDA). The lender may take additional appropriate and necessary steps that are usual and customary to prevent fraud in such cases.
Please note that the conventional application approval involves getting income, social security number, and name of the applicant, to be sent to credit bureaus, to get credit scores, to be evaluated later, based on the rules, for approval or decline of the application.
Summary for Pre-Approval Process on Mobile Devices for all Lending Products
This is shown in
In some embodiments, the lender's mobile device app (MDA) can send a push notification (mobile notice) about the availability of a pre-selection offer to the customer or inquire the customer about their interest in a specific product. In other embodiments, the same notice or push notification can be made visible to the customer, once the customer invokes the lender's mobile device app (MDA). In yet another embodiment, the notice can be visible once the customer touches a link (touch screen button) on the lender's mobile device app (MDA), specifically related to the lending product where a pre-selection offer is available.
Regardless of the notification method, two distinct cases arise. In the first case, the pre-selection of the customer for the lending product that has already occurred, is valid (has not expired yet), and is known or can be readily known (without information transmission from other sources) to the mobile device app (MDA), based on the information previously submitted to the mobile device app (MDA). In this case, should the customer be interested in acquiring the actual lending product, the customer can proceed to the lending product application (LPA) process (explained elsewhere in this disclosure), based on this pre-selection.
In the second case, where the pre-selection has yet to occur, or not known to, or cannot be readily determined by the mobile device app (MDA), the lender must transmit the information via secure transmission methods to their internal databases. Prior to such transmission, customer's agreement may be required or appropriate.
The lender then can follow their existing processes for pre-selection, which in some embodiments, may consist of applying internal credit or non-credit criteria (such as, recent or current past-due delinquency with the lender or its affiliates). Yet, in other embodiments, such regular pre-selection processes may include sending the information further to third-party vendors who may in turn obtain credit or other information and apply lender-provided or other criteria for pre-selecting the customer.
Finally, the information as to whether or not the customer is pre-selected becomes available to the mobile device app (MDA) and is shared with the customer, usually as a notice of conditional offer for the lending product. The customer at this point of time may use the offer by invoking the lending product application (LPA) process on the mobile device (see the related embodiments, described elsewhere in this disclosure).
Initially, the customer, client, consumer, user, or borrower request and purchase/download the lender software application from the on-line store, using her PC, computer, tablet, or mobile device/phone, which includes a biometrics/security module, as well, as shown in
As shown in
As shown in
As shown in
Summary for Lending Product Application (LPA) Process on Mobile Devices for all Lending Products
As mentioned above, whereas various lending product application (LPA) channels are offered to customers by lenders, those channels do not include the mobile LPA channel. This invention/embodiment relates to the area of providing customers the means of applying for financing products via mobile devices, as a way to increase accessibility and convenience for the customers. The process (in general) starts with the customer (existing or new), being interested in applying for a loan through invoking the appropriate link in the lender's mobile device app (MDA). In some embodiments, the lender may choose to follow the pre-selection process reviewed above, or in others, the lender may decide to circumvent the process.
In general, though, the lender will need to identify the customer with certainty, in order to minimize or eliminate the risk of fraud. The customer identification is simpler, if the customer is an existing customer with the lender (has a business relationship), and if the phone number or other identifying number of the mobile device is registered with the lender. However, for the process to function as designed, the customer needs not be an existing one. In the cases where a new customer applies, the required information must be applied, via the mobile device, and the process may take longer to complete.
In one embodiment of this invention, the customer has an existing relationship with the lender. The mobile device app (MDA) prompts the customer for a few variables specific to the loan, that can vary from product to product. In
Once all the information is available, and possibly verified by the customer via interaction with the mobile device app (MDA), the lender may prompt the customer if the customer would like to proceed with the lending product application (LPA). This notice of intent to proceed with the lending product application (LPA) and other relevant information are then sent to the lender's internal IT systems.
The lender may decide at this point to transmit the information to the lending product application/origination system (LPAOS) specific to the lending product for which the customer is applying. The lender's LPAOS then follows the regular lending product application (LPA) processing steps to arrive at a decision. Some of such steps may be retrieving a credit bureau report for the applicants (customer and the customer's potential co-applicants) and triggering all applicable lending rules and potential incremental ones related to mobile lending product applications (LPA). (See
In case a lending product is offered, as outlined under (2), (3), or (5) below, at this point, a product may be constructed that fits the customer's needs and meets lender's applicable lending guidelines and requirements.
Ultimately, the process may or (1) may not result in a decision. A decision may be (2) a conditional or (3) an unconditional approval, (4) a denial or decline, or (5) a counter-offer (not exactly what the customer wants, but what the lender can offer based on the customer's credit and capacity profile). In either of those cases (1) through (5), the outcome is transferred to the mobile device, and the customer is notified of the outcome and the next steps for potential fulfillment and relevant terms and conditions of the lending product, should the outcome be (2), (3), or (5). In all cases, disclosures may be required to the applicants that are conveyed to the customer via the mobile device app (MDA). Some cases, such as case (1) may require the customer to contact the lender via other means (such as phone).
Sometimes, the lender requires more information from the customer, which can be either sent in person, by mail, fax, or electronically, using email, text messages, SMS, or smart phone/communication devices, computers, tablets, PDA, or laptops.
The notification may take different forms, depending on the legal requirements and lender's preferred business practices, and may involve notices on the MDA, via email or first class mail.
Another scenario that may arise is that the offered lending product does not exactly meet the customer's needs and requirements. As an example, the customer may need a 6 year auto loan, as compared to a 5 year loan that has been offered. In an embodiment, the lender may offer those various choices to the customer on the mobile device app (MDA), and have the customer decide which one to choose. In this embodiment, the functionality must be provided to the customer on the MDA. In yet another embodiment, iterations between the MDA and the internal systems of the lender (LPAOS, for example) may be required, and the MDA has to accommodate such iterations in order to finalize the lending product offering to the customer.
In such an embodiment, the MDA will prompt the customer if the offered lending product meets its needs. If not, the MDA must offer the customer a host of parameters (terms of the loan) that may be varied in order to accommodate for the customer's needs. The decision whether or not those changes are within the lender's criteria may be made locally on the MDA, or may have to be made on the lender's internal systems (such as the LPAOS), in which case transmissions between the MDA and those systems are required. In yet another embodiment of this invention, the lender may ask the customer to contact the lender via other contact channels, such as phone or internet, for any requests to change the product.
Mobile Instantly Generated Credit/Debit/Prepaid Card Fulfillment and Usage
Please refer to
The lender's host receivables system (HRS) contains the information related to the fulfillment and usage of the Card, specifically if and which mobile device or devices are used as the usage devices, if other means of usage are used in conjunction with the mobile device, and also security and verification data fields (such as, but not limited to PINS or security questions and answers). (See e.g.,
Please note that for security verifications, one can use the tel. number and some hardware or software ID or numbers or codes, e.g. preset by the manufacturer at the factory, to make sure that the user is the right person. Other conventional/available security/authentication/verification methods can be combined, as well, such as PKI (Public Key Infrastructure)/encryption/digital signatures, or scanning or recording or taking picture/image of face, eye, fingerprint, voice, or other biometrics, using a scanning line or camera(s) or digital recorder/microphone, on the mobile device or tel. set or cell phone.
Should the customer decide to use the Card on the mobile device, for example, to make a purchase at a merchant's store, the customer invokes the relevant mobile device app (MDA) and provides the necessary security information, as established by the lender and the customer. At this point, an embodiment may require mobile device app (MDA) to display a symbolic image depicting a Card. This image is not necessary for the completion of the transaction (may be optional), and may serve the purpose of reassuring the user and the merchant that the transaction is in progress and authentic. Other images or signs of usage may be displayed in alternative embodiments. (See e.g.
The merchant's reader receives the Card information transmitted from the mobile device, via secured wireless communication channels—near-field communications (NFC) or otherwise. Merchant's reader transmits the transaction information (i.e., transaction amount) to the mobile device for the customer's (purchaser or Card holder) approval. (See e.g.
As can be seen from
In other embodiments, no merchant reader may be involved, and an online merchant requires the Card information which is provided by the mobile device app (MDA) to be manually entered by the customer in the online vendor's appropriate fields.
In yet another embodiment, an integrated shopping environment is facilitated by the mobile device, whereby the mobile shopping environment of a mobile vendor invokes (with approval and possible interaction from the customer) the Card mobile device app (MDA) and ultimately completes the transaction, as outlined above, for the in-store reader. Except that in this case, the vendor's mobile store (shopping environment) serves as the merchant and the merchant's reader, and all data transmission is (A) within the mobile device between the mobile vendor's mobile device app (MDA) and the lender's mobile device app (MDA) and (B) possible transaction clearing transmissions required by the vendor's mobile device app (MDA).
Another type of transaction typically associated with credit cards is cash withdrawal, which is typically conducted with a plastic card and a PIN on ATMs or in bank branches. This invention and its various embodiments accommodate for this type of transaction by linking the credit card on the mobile device app with the customer's checking or savings account, where the funds can be withdrawn from the credit card account and transferred to the customer's checking or savings account. An interactive menu in the MDA lets the customer set up such links by providing the selected or linked account's number and the bank's routing number. Another set of interactive steps let the customer perform the actual cash transaction once the appropriate security requirements are met.
As shown in
As can be seen in
Pre-Selection Process on Mobile Devices for all Lending Products
This is shown in
If no pre-selection exists, either on the MDA or on the lenders' internal databases, the lender may decide to follow instant pre-selection procedures, typically used in conjunction with lender's other marketing and origination channels. Furthermore, the lender may decide to ask the customer if the customer is interested in being pre-selected and provide a list of advantages of such pre-selection. If the customer is interested in such pre-selection, then the lender will have to go through a process of obtaining such pre-selection for the customer. Lenders, in order to save development costs, typically, decide to utilize the existing infrastructure for pre-selection and leverage the current process that exists for other marketing channels. However, the lenders may decide to set up a new infrastructure specifically dedicated to the mobile channel and dedicated to pre-selections.
Depending on the extent of the relationship the lender has with the customer, lenders typically decide to use customer's existing credit and other relevant information, or decide to use and leverage third-party suppliers of credit information, or a combination of these 2 sources. Both paths and also the combined path are used here, for different embodiments. Regardless of which path or the combination of the 2 paths that the lender decides to take, customer must meet all pre-selection criteria, which can vary in their depth and scope. If the customer does not meet the selection criteria, the customer may or may not need to be notified, depending on the prevailing regulations and the lender's business practices. If the customer does meet all the criteria and a pre-selection, offer can be made, or as explained previously, a pre-selection offer already exists (that mobile device app (MDA) has access to), then the customer is notified of the availability of the offer.
If the customer decides to peruse of the pre-selection offer, the lender may want to notify the customer of the next step to take, which would be to actually apply for the lending product, described under “Lending Product Application (LPA) Process on Mobile Devices for All Lending Products” section. If the offer is generated new for the customer, and did not exist previously in lender's databases, the lender may decide to store the newly generated offer until its expiration for future reference or use.
Lending Product Application (LPA) Process on Mobile Devices for all Lending Products
This refers to
Regardless of availability of pre-selection to the customer, at this point, for existing customers, MDA needs to access lender's internal databases, to retrieve all relevant information, or alternatively, have the internal systems of the lender determine which data fields are missing that the customer needs to provide. (See
Once all the pieces of information needed for the lending product application (LPA) are obtained, the lender's lending product application/origination system (LPAOS) must receive the information and process the lending product application (LPA), as it does other lending product applications (LPA) coming through other channels. (See
In this embodiment, we assume the lender leverages the lender's existing LPAOS, to process the lending product applications (LPA). However, the lender may decide to implement a simplified or duplicate LPAOS specific to the lending product applications (LPA) for mobile channel either on lender's internal systems or on the MDA itself. However, given the expenses involved in setting up such systems, this embodiment may not be most lenders' first choice, in some situations. The LPAOS processes all the information and data fields provided for the lending product application (LPA) and retrieves incremental required information from third party sources (such as, but not limited to, credit bureau reports from credit bureaus). The LPAOS then triggers and applies all the encoded lending rules to the information that may relate to lender's own credit policy, fraud prevention, legal, compliance, or other applicable rules. (See
As can be seen in
Once the lending product application (LPA) process on the LPAOS is complete, the LPAOS then transmits the results to the MDA. (See
Once the offer is presented to the customer, the MDA will prompt the customer if the lending product meets the customer's needs. If “yes”, then the information is transmitted back to the lender's internal systems (for example, LPAOS). If “no”, the MDA may have to offer to the customer choices of parameters that can be changed in the loan. As an example, the term of the loan may be changed from 5 years to 6 or 4. As another example, the customer may want to increase the amount the customer had requested earlier for the loan from, say, from $25,000 to $30,000, since e.g. the customer wants to buy and finance a more expensive vehicle. The MDA may, for example, in the case of different loan durations, determine the monthly installment payments for those scenarios and ask the customer to choose one. In some circumstances, the decision whether or not to offer the lending product with the newly selected parameter(s) must be made on lender's internal systems (such as, LPAOS). In other embodiments, enough coding has been done on the MDA, where the decision can be made locally by the MDA. Iterations may be needed until the customer is satisfied with the product, in a logical loop, for repeating the same process, until the loop is exited.
In all embodiments, the lender may decide to offer the customer to save an application, to return to it later. Also, if the customer needs to change certain parameters later on, the MDA will have to accommodate for such changes, by letting the customer retrieve the application or the approval/counter-offer, and let the customer work with it and change those parameters, if necessary.
Finally, the customer is ready to fulfill the lending product. See “Mobile instantly generated credit/debit/prepaid card fulfillment and usage” section for instant fulfillment of the application of specific lending products. For all other lending products, the customer may have to be advised to follow steps that require other (e.g. non-mobile) channels.
More on “Mobile Instantly Generated Credit/Debit/Prepaid Card Fulfillment and Usage” Section:
Please refer to
Regardless of whether or not other devices and means are used for fulfillment and usage of the Card, in order for the lender to grant permission for a customer to use a mobile device for the first time as the method of usage for the Card, the lender and the customer must establish security measures to prevent fraud. This step may involve establishing one or more of the following measures: personal identification numbers (PINs), passwords, and security questions and answers. One or more of the same verification methods may be used in the future verification of future uses of the credit on the mobile device, along with the identifying numbers of the mobile device (such as phone number, identification serial number, or the SIM card number). The security information must be transmitted from MDA to the lender's host receivables system and/or servicing systems (and any other system that such information is housed in).
If the Card requires prefunding (for example, for pre-paid cards), the funding must have taken place prior to the first time issuance or fulfillment and usage on the MDA. Such funding can be typically done with a check, or link to a checking or savings account.
At this point in time, the Card information required for conducting business, purchasing, and transferring cash is transmitted to the mobile device app (MDA), and the customer is informed that the Card is ready for use.
The remainder of this section discusses the case where a user wishes to use the MDA to actually make a purchase with the Card inside a store. MDA prompts the customer to provide the required security information that was entered in the previous steps of setting up the Card within the MDA. Once the security information has been verified, an image illustrating the ongoing credit card transaction pops open on the mobile device screen. The image can display a Card with all the relevant information that typically is displayed on a plastic Card, plus potentially additional fields on the back of the card (such as the extra 3- or 4-digit security code). A dial-button may be required to prompt the customer for the mode of transaction that will take place: 1) in-store, 2) online, or 3) cash withdrawal. Once the customer chooses the in-store mode of transaction, the MDA and the merchant's reader are ready to resume the transaction via conventional wireless communications, such as but not limited to, NFC (near-field communications). One of the optimal ways for the transaction to transpire is for the reader to send the relevant transaction information to the MDA exhibiting the merchant's name, the transaction amount, and potentially the details of the invoice (such as, the name of the purchased item). Once this information is shown on the screen of the MDA, the customer (Card-holder) can decide to accept or reject the transaction. This way, if more than one Card transaction is transpiring with multiple Card-holders, the correct transaction connects with the right MDA. Another embodiment of the system to address this issue would require that we have a queuing of the transactions, so no 2 wireless transactions occur simultaneously, leading to erroneous results. Multiple iterations may be required to finalize the merchandise or service being purchased and the transaction amount.
In yet another embodiment of the system, once the Card information is transmitted to the reader, the remainder of the transaction, such as additional verification (e.g., providing Zip code) or signature on the reader or paper slip, can transpire, as per existing processes set up for plastic Cards. This specific embodiment will reduce the production expenses both for the mobile device app (MDA) and the merchant's card reader.
Once the customer approves the transaction, MDA transmits the information to the merchant's reader and the reader transmits the information further through the regular and standard transaction clearing channels that Card transaction ordinarily are cleared through. Two clear cases emerge here. First, if the transaction is approved, the transaction concludes by the merchant receiving the payment information and the customer receives the merchandise and an electronic or digital copy of the invoice or receipt is stored on the MDA for future reference for the customer. If the transaction is rejected, either the vendor can inform the customer or the MDA can actually provide more descriptive details about the decline reasons. For example, the MDA can inform the customer that there is suspicion of fraud and the customer needs to contact the lender immediately if the customer wishes to conduct the transaction with the MDA Card right away. Or, the MDA can provide specific over-limit information to the Customer, for example: “The current remaining open line on the credit card or the available funding on the pre-paid card is $235, and the transaction amount is $340”. This kind of error message is not available to plastic card users. Thus, it is more informative and more advantageous for the user and all other parties involved.
Note that
Please note that
An Embodiment for Mobile Phones:
Let's look at
Thus, the steps are:
-
- The user goes to the application of her bank, on her smart phone.
- She invokes the button for “credit card” or “debit card”.
- If there are more than 1 Card to select from, in cases where the customer has multiple cards with the lender, the customer is given the option to choose one to use.
- An application generates the image of the specific card selected, with all the necessary information for the reader to read, e.g. OCR or scanner or bar code reader.
- A specific reader reads the information, matches against the database, and charges the credit/debit accounts, accordingly.
- To prevent fraud/reduce the fraud, the application matches, for example, the phone number and hardware ID number against the ones on the record for the account.
- One can also implement a passcode/PIN, for security.
One can also extend this concept to prepaid cards, with an extra step of purchasing the card. The consumer wants to obtain the card fast, with no preapproval needed, to get some dollar amount from e.g. her bank checking account, which can be refilled later. That is, e.g., the customer initially has to purchase and fund the card with money from her checking account. Later on, for future uses, the card is produced as an image, and available dollar amount is displayed, as well.
The application for the credit card can be integrated into the whole process of invoking the card for display on the phone and immediate usage by the customer. Once the customer applies for the credit card, the bank goes through its normal process of underwriting and origination, and once approved, the card is displayed with the available credit limit to the customer, who can invoke the card, as explained above.
This is a big value for customers and banks, since the application, issuance, and usage become simultaneous, and the customer does not have to wait for the card to arrive in the mail, once they apply for it. They can also use that for on-line purchases.
As shown in
Section 2: Financial Products for Protection of Consumers
In this section, we are going to address the following embodiments (as referenced in
Presently, a number of products provided by lenders to consumers have variable or adjustable interest rates that reset periodically based on a variable rate interest rate index, such as:
-
- 11th District Cost of Funds Index (COFI)
- London Interbank Offered Rate (LIBOR)
- 12-month Treasury Average Index (MTA)
- Constant Maturity Treasury (CMT)
- National Average Contract Mortgage Rate
- Bank Bill Swap Rate (BBSW)
- PRIME or Prime rate
Should these rates increase over time, the consumer may be exposed to an undue hike in their payments. As an example, let's say a consumer has $6,000 on their credit card account that charges PRIME +6%. Presently, PRIME is at 3.25%, making the minimum required monthly interest payment equals to approximately $6,000×(9.25%/12)=$46.25. Should PRIME double to 6.5% (in other words, increase by 3.25%), over time or perhaps in a short period of time, the payment will go up to $6,000×(12.5%/12)=$62.5, corresponding to a 35% increase in interest payment. The annual increase in the interest payment is $195, which is a relatively large increase for a consumer.
Another example would be an adjustable rate home equity line of credit (HELOC) that will reset with a LIBOR benchmark. HELOC accounts are interest-only for a fixed period of time. If the balance is $50,000 with 1-Year LIBOR currently at 1%, for example, and a spread of 4%, then it requires the borrower to pay $208 per month in interest-only payments. Should LIBOR increase to 4%, for example, the monthly payment will increase by 60% to $333. Clearly a shock to the borrowers is present. Due to elevated levels of interest rate and the consumer's potentially worse credit situation, refinancing at the end of the fixed term can also be challenging for the consumer, should the rates increase at the time of refinancing.
Current Offerings
Presently, a number of products, such as credit cards, provide no protection at all, where the cap of the interest rate is set by state usury laws, if any. Other products, such as most home equity lines of credit, provide a one-time option to the borrower to lock the fixed rate at that point in time where the fixed rate is so much higher that precludes the borrower from protecting themselves from upward movements in interest rates.
Our Invention, to Solve the Problem Above
Lenders offer the financial product proposed in this invention to borrowers of floating, variable, or adjustable interest rate loans, lines of credit, or other forms of borrowings that are benchmarked against an index as outlined above. The product provides an option to secure fixed rate financing (at a predetermined rate, which is fixed, known, and agreed upon, from the beginning) for a given balance of the debt financing (be it all or part of the actual borrowing), for a fee or as part of originating and servicing the loan offering. The following table outlines the features of this product and the types of loan it can apply to, as one embodiment:
For example, Table 1 shows the Underlying Lending Product:
For example, Table 2 shows the Interest Rate Option Product:
For example, Table 3 shows the table shown above for Credit Card example:
For example, Table 4 shows the table shown above for Credit Card example:
For example, Table 5 shows the table shown above for Home Equity Line of Credit (HELOC) example:
For example, Table 6 shows the table shown above for Home Equity Line of Credit (HELOC) example:
Therefore, a consumer has a safety net and sense of security against the large increases in the monthly payments, which is very attractive to the consumers. Therefore, for a bank or financial institution offering such a financial product and offering, the bank or financial institution can distinguish itself from the rest of its competitors, thus, increasing its customer base drastically, causing growth and more profitability in its business.
This helps consumers hedge against unexpected increases in interest rates and monthly payments that they may not be able to afford, so that they can lock at some threshold or maximum, as a worst case scenario, for a peace of mind for consumers, as a pre-determined situation (s) that is predictable and more comfortable/manageable/affordable for a consumer. This also helps reduce bankruptcy and foreclosures or forced auction of the house, for example, which is very costly for banks and consumers, with no delays at courts and less uncertainty for all parties involved.
Currently, such a product does not exist for individuals, e.g. credit cards or home equity line of credit. This will protect consumers greatly, and also will reduce the risks and expenses for the banks
Please note that each of Tables 1-6 show only examples of this embodiment. The data structure shown on those Tables are typical parameters needed for implementing this invention. Also, please refer to
As shown in
As shown in
A Note on the Interest Rates:
The stepwise rate reduction for fixed term installment loans, as an example, can be discussed as follows (e.g. please refer to
We assume monthly payment, but it can be extended to biweekly or semi-monthly loans, too. This is a conventional calculation, available from many sources, e.g. Internet or Wikipedia or Mathforum.org:
T=term in months
r1=initial annual APR
r2=secondary annual APR
K=period after which the interest rate is reduced from r1 to r2
M=payment, e.g. M1 and M2
P=principal, e.g. P0
Then, we have, based on the initial principal, P0:
After K payments, we have:
(if (r2<r1), then (M2<M1)), meaning that, without changing T, the original term of the loan, if we reduce the interest rate, the resulting installment payment will decrease.
As explained in this Section (above), this product is useful for people with little or no credit history, or poor credit history, so that they can build their credits back, and later reduce their rates, by moving from high risk category to low risk category, when performing as a reliable customer for a specific predetermined period of time, but without any new application for loan or any new approval, as long as the predetermined conditions (mostly related to timely payments) are met. This gives a chance to a person with no or bad credit history to rebuild or build a good credit, and get some benefit immediately, based on a loan approved and originated, e.g., years ago, which is a contract or agreement capturing those provisions at the beginning, e.g. many years ago.
Moving from high risk category to low risk category happens when, e.g., the person has had a good payment pattern, with no delinquencies, or the person has an improved credit profile, or the person now has a longer employment history (that may have to be verified).
The whole concept above may be non-contractual, as well. In other words, it can be an option for the lender to lower the rate, or prescriptive, according to a set of criteria, e.g. FICO score above 660, or no more than 2 delinquencies, or no delinquencies at all with the lender or any other lenders.
Section 3: Relationship-Based Score
In this section, we teach “A Credit Score Based on Borrower's Relationship with the Lender (Relationship-Based Score)”, with an example shown in
All credit scores rank order borrowers in terms of the borrowers' probability of default in the future. In other words, a higher score usually indicates a lower probability of default over a specific period of time (next 12 months, for example). Typical credit scores (pooled based on all or numerous lenders' data or custom based on a specific lender's data) rely exclusively on credit attributes pertaining to such variables as (1) length of credit history (time on file), (2) recent delinquencies, (3) past derogatory incidents, (4) bankruptcy filings, (5) number and frequency of recent credit inquiries, (6) the number of active, open, or historical trade-lines, (7) utilization of open revolving credit lines, and other such credit attributes.
Such scores have gained popularity in the 90s and until today. Smaller lenders tend to rely on pooled credit scores, and larger lenders (since they have the appropriate expertise, access to data, and the right scale) tend to develop custom scores and rely on both pooled and custom scores for their business. Most scores tend to be specific to a lending product; for example, a custom score developed for a specific large lender can be for the lender's credit card application and origination program. However, there are some scores that focus on the credit worthiness of the borrower across all lending products. The best known credit score which happens to be a pooled score and generic to all lending products is FICO, developed by FICO (www.fico.com).
Credit scores (pooled or custom) have numerous applications in the lending industry, such as, but not limited to, automated (system) and manual (by a human) decisions for credit applications and product originations, pre-selection (pre-approval, invitation-to-apply, and pre-screen), account management for revolving credit product, collections and recovery in case of delinquency and default, product pricing (in the form of rates and fees), and whether or not a specific treatment of an account or a customer should be reviewed by a human. Credit scores in the area of account management for both installment and revolving credit products are referred to as behavior scores.
All pooled credit scores (product specific or borrower centric) exclusively use credit attributes as independent variables for model development. The custom scores, however, predominantly use credit attributes as variables to the model. A few variables and attributes focusing on the customers, and their relationship with the lender, may be used as segmentation or independent variables in the custom score model. (Please note some lending and banking literature refers to independent or segmentation variables as characteristics.) Currently, no credit score uses customer and relationship attributes exclusively or predominantly as input variables. Such customer and relationship attributes measure (A) the depth (volume and balance of business), (B) breadth (how many products), (C) length (how long), and (D) the quality (e.g., activity or recent delinquencies) of relationship the lender or its affiliate financial companies have with the customer or (E) other relevant customer data (for example, marketing segments) to assess the customer's probability of default and payment performance in the future.
The fragmented nature of lending industry in the United States has resulted in the lack of use and popularity of such customer and relationship centric scores. Most customers and lenders tend to focus on a specific lending product that maximizes the customer's and lender's gains and on the value for that specific lending product rather than on a holistic view of the entire relationship. As the fixed costs of lending increase (for regulatory and other reasons) and profit margins shrink, due to the ensuing consolidation, the few remaining players will have to differentiate themselves by offering innovative products and focusing on relationship banking to add value to their customers. That is where a relationship-based credit score will be of tremendous value both the lender and the borrower.
Another reason why relationship-based scores have not become popular and are not in use is that all lenders upon taking adverse action against a customer or borrower must issue rigorous and analytically driven reasons as to why the action took place. Examples for adverse actions are a decline or rejection of a credit application or reduction in credit limit or suspension of a revolving line of credit. If an adverse action is taken based on a low relationship score and the low score is due to the customer's low or sparse level of relationship with the lender, the lender would be hard-pressed to present a plausible reason to the customer for such rejection, and furthermore, such rejection is not viable from a sound business perspective. It would be unreasonable and illogical for the lender not to want to do business with a potential customer or borrower, just because the customer has no or low business relationship with the lender. In the body of this invention and its various embodiments, we present ways of applying the score while addressing and circumventing this fundamental drawback.
The main issue with excluding customer and relationship attributes from a credit score that ranks future probability of defaults and assesses payment behavior of the customer is that a host of variables are excluded as input variables to the modeling process. Whereas the credit attribute variables (e.g. see categories (1) through (7) listed above) exhibit statistical correlation, the business relationship variables in categories (A) through (D) have little or no correlation to the credit attributes. When mathematical models are developed using uncorrelated or less correlated variables, and the resulting score has higher power of differentiation between future Goods and Bads, borrowers and accounts likely to perform well and poorly, respectively. Furthermore, the resulting score, even though it predicts the same dependent variable (probability of default in this case), since it spans a different uncorrelated set of independent variables, adds to the lender's power of predicting the dependent variable and opens up opportunities that existing scores and models have currently no means of accessing and leveraging.
This invention is related to the development and application of credit (probability of default) scores that are based on a customer's relationship and other non-credit attributes and variables. Score development process is well documented and described in the lending industry literature and publications. However, as mentioned earlier, such credit scores focus exclusively or predominantly on credit attributes as independent and segmentation variables.
In one embodiment, unlike some of credit scores based on credit data that are developed for a specific lending product, the Relationship-Based Score is for all the lending products and quantifies the customer's probability of default on any or all lending products.
The goal of the invention and all its embodiments is to develop a score and implement it successfully using relationship and other non-credit variables and attributes according to the process laid out in
Depending on the availability or sparsity of lender's data, the Observation Window may be 6 to 12 months in length. Other embodiments may have Observation Windows that are shorter or longer depending on the conditions mentioned earlier. To increase the predictive power of the score and reduce correlated inputs, in some embodiments, the developers may choose every account a customer has held to be observed only once. However, other accounts the customer has held in the observation window may get captured in the input data for the customer. The Performance Window is the period that determines the performance the model is designed to predict and is used to determine which accounts are good versus bad credit risks. The length of the Performance Window depends on and is typically correlated with the duration of the lending product, and also if the account is current or past-due.
For example, the longer the duration of the product, the longer is the performance window. An installment car loan may require a 12 to 18 month performance window, whereas a credit card may require 24 to 36 months. Furthermore, customers that are current (not past due) are likely to be scored differently from those that are past due at the point of scoring (see segmentation). The main difference in the data needs is that the current accounts will need a wider Performance Window (of one to three years, for example) and past due accounts establish their Good vs. Bad behavior in a narrower time window (say, e.g. 6 months). Please see
Finally, the lender may decide in some embodiments to use consistent Observation and Performance Windows, regardless of which product is being considered, and focus exclusively on the customer's performance in the Performance Window. Please see
Two kinds of combinations of Observation and Performance Windows are practiced, and both can be used in different embodiments of this invention. Diagram 2 illustrates the 2 types: staggered and un-staggered Performance Window. Even though both models of observation and performance windows are practiced in industry and can be used for the various embodiments of the score in this invention, the staggered version is analytically more consistent, since it monitors the performance of all observations equally long.
Step 1. Gather Historical Data: (as Detailed in
Gathering historical data (Box 1) requires collection of (A) customer's past performance with the lender and the lender's affiliates within a Performance Window, as defined earlier, and (B) customer's past relationship and non-credit attributes, as Observed within the Observation Window, as described earlier.
Step 2. Performance Definitions:
Performance definition (Box 2) warrants careful attention. Definitions of Good, Bad, and Indeterminate must be established for each product that the lender wants included in the scope of the score. Good in general means a customer makes regular and agreed upon payments. Bad, on the other hand, means the customer does not make the payments on borrowed lending products as per agreement and expectation, and furthermore has resulted in a charge-off, or is very likely to lead to a charge-off scenario, where the lender has already incurred or is highly likely to incur credit losses on the principal related to the lending product. If in some embodiments, the relationship score is developed for a specific lending product or a specific subset of the lender's products, the definition of Good, Bad, and Indeterminate has to be established for those products only. However, if for other embodiments, the relationship score is for the customer as a potential borrower of all lending products the lender offers and encompasses the whole relationship, all product histories the customer has had with the lender in a given Observation Window must be included. In other embodiments, the lender may decide to use one and the same definition for Good, Bad, and Indeterminate for all lending products, and in others each product may retain its own product-specific definition. In the following section, we offer some specific recommendations for those definitions as they related to one of our embodiments.
Finally, the customer may have numerous products captured in the Observation Window, whose performance is monitored in the Performance Windows. Customer may be Bad in all, some or only one of the products monitored in the Performance Window. Since the object of score is prediction of default, it makes more sense in the recommended embodiment to view a default on any single lending product as Bad. However, in other embodiments, the developers of the score may choose to require defaults on all or a majority of the lending products in order to define the customer as Bad.
Step 3. Segmentation Analysis:
The premise of segmentation (Box 3) is that the independent variables or attributes have a different relationship with credit risk or probability of default (dependent variable) for different segments or sub-populations. By identifying the appropriate sub-populations, the characteristics that are most predictive in isolating risk are optimized for that group. In other words, fundamentally different customer segments perform fundamentally differently and will have different variables best defining their performance characteristics.
The segmentation of the population both for developing the model and also actual scoring depends on the business model of the lender. A few general considerations:
-
- For some embodiments of segmentation, the customers that at the time of being scored (Observation Window) are not past due should be separated from those are past due, since the performance patterns and characteristics of these populations are materially and fundamentally different.
- In some embodiments, to increase the power of prediction of the score requires excluding certain populations from the score (in industry referred to as assigning an exclusion score to the customer). We provide 2 examples of such exclusion segments:
- 1. Customers who are severely delinquent (2, 3 or more payments past due at the point of scoring or for the development phase within the Observation Window) may be excluded in most embodiments, since lenders typically do not lend more to someone who is already 2 or 3 payments past due on another lending product.
- 2. In some embodiments, where relationship is the primary and only focus of the score (versus in other embodiments where other customer attributes are also included as independent variables), prospects or those who are new to the lender and all its affiliates (in other words, neither the lender nor its affiliates have any past relationship), with the customer, no meaningful Relationship-Based Score can be assigned to the customer.
- In some embodiments, another segment to be carved out and separately modeled, to add strength to the model, is those that are new to the lender, but have existing relationships with the lender's affiliates. For such a segment, independent variables that relate to the overall relationship will be dominant, whereas the relationship variables related to the bank are non-existent.
- If prospects (potential customers who have no existing relationship with the lender or any of its affiliates) are not excluded, as per earlier bullet, since other non-relationship attributes and variables are being considered, in some embodiments, such prospects may be placed in their own segment, but only non-relationship variables, such as demographics and employment data, can be used as independent variables to the model.
The remainder of the population that is neither excluded nor segmented, as per earlier recommendations, is segmented according to the business model that best describes the lender and its affiliates. If in certain embodiments, the score is not specific to a product and is related to the customers and their overall business relationship with the lender and its affiliates, product segmentation is not recommended. If the lender knows of certain demographics or sub-populations that have a materially different performance, they ought to be placed in a different model for segmentation. As an example, let's say the lender knows those people who have a life insurance product with the lender's affiliate, ceteris paribus, perform much better than everyone else. Then, this population should be placed in their own segment.
There are a number of analytical or statistical methods to segment the population prior to developing the individual models for each segment that in some embodiments may be used. A potential list is provided here:
1. Clustering
2. Logistic regression
3. Boosting (meta learning)
4. Decision trees (for example, CHAID)
Methods 2 and 3 are capable of doing the all-else-equal analysis (ceteris paribus), whereas 1 and 4 typically are not and need to be used with more expertise and in-depth knowledge of the business.
Step 4. Variable Selection and Reduction:
This step follows the standard practices known in industry and is typically executed in conjunction with the following step of fitting the model. Any linear or nonlinear regression technique or other data mining techniques for a binary outcome, such as logistic regression, can be used to fit a model. Either step-wise or by trial and error, a set of suitable independent variables is used that fits the performance behavior of the specific segment best, and gives it the highest predictive power. In this case, however, instead of a standard set of credit variables or attributes, a set of relationship and other non-credit variables or attributes is used. Regardless of embodiment, the goal of the exercise is to obtain the best (most predictive) score that can be developed for each segment.
Step 5. Adverse Action:
Due to legal and regulatory constraints, when a score is used for declining a credit application or reducing the credit limit of or suspending a revolving credit product, adverse action reasons must be used that give the customer understandable reasons as to why the credit application is denied. For Credit-based scores, these reasons are almost exclusively due to the poor payment and credit behavior of the borrower. Since a Relationship-Based Score is mostly based on a relationship that a customer has with the lender, and less so based on their past payment performance, most lenders would not want to decline customers because of the low Relationship-Based Score. The notable exception to this would be those that have had performance issues with the lender or its affiliates. However, as explained earlier, the purpose of this score is to predict credit default as a function of non-credit variables. Therefore, no independent variables or attributes in regards to having been being bad with the lender are included in the models and can be used to provide adverse action reasons. Such variables are used by other pooled and custom credit scores and may be dropped as independent variables from a relationship-based score development.
As far as performance-related independent variables are concerned, in some embodiments, those of lender's affiliates may be included in the analysis. To the extent the influence of the performance-related piece of the score is material and the score is lower than a given threshold, adverse action reason can be given to that effect. The reason would state, that customer has had performance issues with the lender's affiliates in the past, and that is sufficient reason for declining the credit application. In some embodiments, if the customer falls into one of the exclusion scores mentioned in Step 3 (delinquent or severely delinquent), the current performance of the customer with the lender is poor and adverse action reasons can reflect that.
Step 6. Implementation—Applications of the Relationship-Based Score:
The Relationship-Based Score can be applied in a number of credit decisions, credit policy, collection, and lending product pricing matters. In selected embodiments, lenders may choose to use one or more of the following potential applications areas:
1. Systematic approval of applicants who ordinarily (w/o the Relationship-Based Score) would be declined, solely based on the credit-based scores, if their Relationship-Based Score exceeds a certain threshold.
2. Systematic decision of routing to manual under-writing of those borderline cases, where due to their positive relationship, the customers have with the lender manifested in the form of a high Relationship-Based Score, an approval may be warranted, but needs to be manually examined by a human.
3. Use of the score by human underwriters, in cases routed to them (see item 2 above) based on set guidelines of exceeding a certain threshold, whereby looking at the holistic picture of the credit, debt service capacity, and relationship of the customer with the lender, a decision can more effectively be rendered.
4. Account management for revolving credit products. The following examples of account management may be used in selected embodiments:
-
- a. The open credit lines are constantly monitored by the lenders and frozen for certain risky customers, should a customer exceed a certain threshold in their Relationship-Based Score, the freeze in line can be deferred to a later time.
- b. Or should the score be below a certain threshold the freeze can be accelerated.
- c. High Relationship-Based Scores may be used to grant customers higher over-limit balances than warranted solely based on credit-based scores.
- d. Suspension of the account (soft—removed once cured—or hard—not ever lifted—freezes) can be deferred for High Relationship-Based Scores.
5. Collections activity: a high score can preclude the customer from aggressive, early, or pre-emptive collections actions, and a low score can accelerate those collection actions.
6. Pricing: a high Relationship-Based Score can lead to more favorable pricing, since the credit loss expectations for customers with better Relationship-Based Score, ceteris paribus, are lower, more favorable pricing or lower rates are warranted and justifiable.
7. Preferential treatment: customers with high Relationship-Based Scores can be placed in special buckets, to be treated more favorably than other customers. Waiting (shorter) periods on phone lines, early replies on emails to customer service, and better rewards for credit cards are a few examples of such preferential treatments.
Most, if not all, of these applications require the lender to conduct business (credit and financial) analyses that are customary to the lending business in order to establish appropriate thresholds for preferential treatments. In some embodiments, the lender may decide to divide the population to quantiles (ordered data into essentially equal-sized data subsets) and give the above mentioned preferential treatments to certain top quantiles. Establishing which quantiles get the preferential treatments may also involve those credit and financial business analyses.
More Details about Relationship-Based Score
Now, we describe more embodiments about the Relationship-Based Score: (Please refer to
Step 1. Gather Historical Data:
Gathering historical data relates to all relevant relationship and other non-credit (customer) variables and attributes in the appropriate Observation Window. Such customer and relationship attributes measure (A) the depth (volume and balance of business), (B) breadth (how many products), (C) length (how long), and (D) the quality (e.g., activity or recent delinquencies) and profitability of the relationship the lender or its affiliate financial companies have with the customer, or (E) other relevant customer data (for example, marketing segments). Such attributes may be used in various embodiments as segmentation or independent model variables.
An important note is due here on the use of credit history of the customer specifically with the lender. In some embodiments, the lender may decide to include such historical credit performance variables as to be used both within the scoring models and for segmentation. However, there are 3 caveats that need to be carefully considered. First, the score is meant as a credit score relying on no-credit attributes and characteristics. Including lender-specific credit variables may add to the strength of the model, but is contrary to the purpose and spirit of the score. Second, all lender-specific credit attributes are typically gathered by custom and pooled credit scores that rely on credit attributes as independent variables. Finally, related to the previous point, recall that the separation of credit attributes from this score gives it low correlation with other credit scores and adds to its strength. Adding back credit attributes as independent variables, even if they relate to the lender's relationship with the customer, diminishes this strength. Having stated all that, in some embodiments, the lenders may decide to include some lender specific attributes related to lending products, as independent variables. We list a sample subset under category F in the table below.
Gathering historical data also relates to performance data of previous lending products the customer has with the lender in the appropriate Performance Window. Such performance data gathering relates to the definition of performance described next.
Step 2. Performance Definitions:
Industry practices for definition of Good, Bad, and Indeterminate performance apply and are typically chosen by the lenders, based on their past experience with the product. In this case, since the score is for the customer as a current or potential future borrower, historical performance of all past products that the customer has had with the lender in the Observation Window may be used in some embodiments. A sample table is provided for various products that may be used in some embodiments, as Table 8 below.
Please note that for the “Bad” category, above, the number of days past due for the definition of bad depends on the nature and duration of the product (for example, for revolving credit or installment loan products 90 or 60 days, respectively) and also how many days past due the lender charges off the product (credit card 180 and auto 120, for example).
As discussed under segmentation (Step 3), customers that are current (not past due) are likely to be scored differently from those that are past due at the point of scoring. The main difference in the data needs is that the current accounts will need a wider performance window (of many years), and past due accounts establish their Good vs. Bad behavior in a narrower time window. The Good, Bad, and Indeterminate classification illustrated in this table (above), Table 8, is only a sample, serving a selected detailed embodiment of the invention. The actual classification depends on the lender, the lending product, and various other business considerations. In one embodiment, all products that the lenders offer and the relationships customers have with the lender must be included in the historical data, in order to develop the Relationship-Based Credit Score based on the full picture of the relationship.
Please note that
As shown in
As shown in
Contractual or Pre-Determined Rates Based on History & Relationship Score
Now, we describe a financial product where the interest rates (or the changes in rates, or behavior of the rates, or the range of the rates, or the formula for the rates, or reduction in the rates) are predetermined, e.g. as a contract between the consumer and e.g. a bank, at the beginning, so that the consumer can count on it, as what the result would be in the future.
In general, conventionally, the credit cards have variable rates, but they are not the same as the product we are describing here. In our case, we offer an installment loan, e.g. at a rate of Y percent. However, the rate goes down, e.g. to Z percent, if one of the following event happens, as an example (or stays low as long as some predetermined conditions are satisfied, or e.g., will go up if some other conditions are satisfied, for a period of time, or forever, or as long as some conditions are satisfied):
-
- The consumer paid all the payments for his/her loan on time for the past 12 or 24 months.
- The consumer was a good customer to the bank, with high score as a customer, and a long relationship with different divisions or affiliates of the bank.
- The consumer got a promotion in his/her job, with 35 percent higher salary now.
- The consumer finished his/her loan payments for his/her car, which means that he/she has more disposable income or higher debt service capacity, now, compared to the time that he/she applied and got the residential (house) loan, originally.
The logic behind this is that, e.g. if somebody is applying for a loan, originally, there is a risk associated with that consumer, with respect to that loan and the bank/lender. The higher the risk of default and non-payment by the consumer, the higher the rate should be, to justify the risk for the lender or bank. However, it is shown that, statistically, if e.g. somebody pays her mortgage and other contractual payments on-time for a few years, the probability of default decreases materially. Thus, the rate can be adjusted based on that condition, contractually, at the beginning, without any refinancing fees or refinancing or new contract or new application or any new negotiation or any new applicable rate at the time of this decision based on the market rates or indices.
So, it would be less risk for the bank, knowing that the consumer has been a good and reliable customer. It also gives more peace of mind and confidence to the consumers, with less chance of defaults and less uncertainty for future, which is better for consumer. So, the loan activities increase, with healthier results, and less defaults, which is costly for all parties involved, directly or indirectly, including health of economy in general, and construction industry in specific. So, it will be a win-win situation for all, and any bank offering such a product will be very much appreciated and noticed by consumers, which is good for the bank's business, growth, and profitability. (Please note that this product does not exist for e.g. home loans, at present time.)
In general, having loyal customers (and long-term or multiple relationship, with consistent results for the bank) is very profitable and reassuring, making the bank more successful, in general. So, this product makes the benefits of some of that success back to the consumer, for a win-win situation.
Of course, the reverse can also be added to the original agreement, e.g. when the consumer has a lower salary 5 years from now, as an option, as another product, so that the lender can or may adjust the rates based on the new data 5 years from now, per original agreement, based on the formula, agreement, table, curve, or schedule, agreed upon, beforehand. This last option is generally more attractive to the lender.
Other Embodiments Based on Relationship Score
Here, we describe other embodiments based on the Relationship Score. It is a loan product approval method by a lender, which comprises the following steps, as an example: (e.g. see
-
- a lender computing device receives a loan application, regarding a customer, from a lender application receiving device;
- the lender computing device receives credit information regarding the customer from one or more databases of various credit bureaus;
- a ranking and calculating device assigns a first weight to the credit information;
- the ranking and calculating device receives performance definitions from a performance definitions database;
- the lender computing device receives past relationship information as a client, regarding the customer, from one or more of the lender's own or affiliate companies' databases;
- a segmentation analyzer assigns which segment the customer should be assigned to (e.g. assesses the customer's probability of default and payment performance in the future);
- a modeling processor fits variables within a given model, to describe the customer's financial situation and dependability;
- the ranking and calculating device assigns a second weight to the past relationship information, based on the performance definitions;
- the ranking and calculating device receives data from the segmentation analyzer and the modeling processor;
- the ranking and calculating device combines the data received from the segmentation analyzer and the modeling processor, with the first weight, the credit information, the second weight (and in some embodiments, more important weight), and the past relationship information, to assign a relationship-based score to the customer (e g taking a weighted average);
- based on credit information scores and relying on the relationship-based score for the customer, a loan product package processing device either approves the loan application, regarding the customer, or rejects the loan application;
- in case of approving the loan application, a rate determination device assigns a current interest rate to the loan application; and
- the loan product package processing device notifies the customer about the approval or rejection of the loan application.
Here are more embodiments:
-
- The loan application is related to one or more of the following lending products: automobile, motorcycle, bike, RV (recreational vehicle), marine, boat, airplane, equipment, business, factory, unsecured installment loans, credit card, mortgage, home equity installment, or home equity line of credit, as shown in
FIG. 5 . - The loan product package processing device considers one or more of the following: income, own or rent, housing expenditure, collateral type, collateral value, requested amount, down payment, estimated closing cost, or other relevant information about the customer, as shown in
FIG. 5 . - The loan product approval method further comprises: down-sampling data, variable selecting and reducing, rejecting inference, validating data, analyzing weight of evidence, scaling and aligning data, and applying adverse action, as described in
FIG. 6 . - In one embodiment, the performance window for all observations is the same. In one embodiment, the performance windows are staggered, as shown in
FIGS. 7 a and 7b. - In one embodiment, one or more future interest rates are assigned, for the loan agreement, which may have one or more corresponding conditions, to kick in or trigger the new rate(s), which can be done using one or more of the following methods (as shown in
FIG. 19 ):- periodically.
- based on a predetermined or trigger event.
- based on a predetermined market index.
- based on a random variable. or
- based on random time intervals.
- In one embodiment, the customer is classified, in terms of a preferred interest rate, to become eligible for a specific tier of the customer classification and corresponding interest rate(s) or ranges. Basically, the more dependable the customer, the less risk for the bank, and the bank can afford to offer a lower interest rate for a loan taken, higher interest rates for the customer's saving and checking accounts, discounts, gifts, awards, bonuses, extra services, waived fees, or lower fees or bank charges (as shown in
FIG. 19 ). - In one embodiment, this process is adjusted, e.g. with new rates, periodically, or based on customer's request, or based on an event, such as customer's rating and financial situation, e.g. bankruptcy, changing job, retirement, or divorce (e.g. as shown in
FIG. 19 ). This can work as an insurance/peace of mind for customer, hedging against disaster events or unexpected or somehow expected events.
- The loan application is related to one or more of the following lending products: automobile, motorcycle, bike, RV (recreational vehicle), marine, boat, airplane, equipment, business, factory, unsecured installment loans, credit card, mortgage, home equity installment, or home equity line of credit, as shown in
Section 4: Application of Credit Report for a “Binding” Pre-Approval for Lending Products
Here, in this section, we deal with Application of Credit Report for a “Binding” Pre-Approval for Lending Products, as, for example, related to consumer lending. (Please see
For human intervention situations, the data still goes in and out of the human's computer (or terminal device, with user interface device), and the rest of the system and procedure stay the same as the fully automated system and apparatus described in this disclosure.
In a process which is typically disjoint from the lending product application process described above, lenders select prospects or potential future customers. This selection process results in a pre-selection offer that has various names and titles, such as, pre-approval, invitation-to-apply, or pre-screen.
Note that the pre-selection process does not result in a prospect's full bureau report, but the lending product application process produces the report giving the lender a full view of the applicant's credit profile at the time of application. Furthermore, in order to qualify for the product, the applicant for a lending product provides more information (such as, income or rent payment) to the lender than the lender has for the prospects at the time of submission of the pre-selection to the bureau.
The customer who applies for a lending product is an ideal candidate for more business with the lender, especially if the customer is approved for that specific product. As an example, if a customer applies and is approved for an auto loan, he or she may be an excellent credit card-holder with the lender qualifying for special low interest rate balance transfers. Currently most lenders (1) do not focus on relationship lending, (2) have disjoint decision processes and application systems for their various lending products, (3) have different business units deal with different lending products in a silo format, and (4) do not view the credit report used as part of an application process for a specific lending product as a marketing tool to expand the business relationship with the customer.
Actually reason (2) above is probably the main technical challenge why this invention is not practiced and (3) provides the organizational context. Applications for the different lending products are processed on different disjoint application processing IT systems, and linking them would typically require an investment. Furthermore, the businesses or units or divisions for each lending product category in large lenders (that can benefit from this kind of invention) work separately, with their own business objectives to reach. In a future relationship-focused banking universe, this shortcoming will have to be overcome.
Our Solution:
Since all the applicant information (including income and bureau information) is available at the point of application for a specific lending product, decision engines (credit policy rules) can be executed for all other products offered by the lender.
The decision engines for those other lending products need to be slightly modified in two ways. First, even though applications for different lending products require mostly common pieces of information and data, other pieces of information may not be common. For example, the credit card applicant typically does not specify how much in credit limit they need, but borrowers for auto loans and mortgages do specify how much they would like to borrow to purchase the car or the house. Since this information (loan amount) is not available for some loans, two ways of dealing with this exist.
In some embodiments, the lender may decide to make some assumptions on the loan amount. For example, assume or guess that the borrower might be interested in a $25,000 auto loan or a $200,000 home and see if the borrower can qualify for the lending product. In yet another embodiment, the lender would let the decision engine determine how much loan the borrower can afford. (See e.g.
As an example, a customer has gross monthly income of $4,000 and the payment-to-income ratio for the auto loan for the customer under consideration is 10%. Then, the borrower can afford a monthly payment of $400. Also, let's say the borrower has other debt burdens (such as, credit card, student loan, and a mortgage, all visible from the credit report) amounting to $1,000 per month. The debt-to-income ratio for this customer cannot exceed 40%. Therefore, the maximum monthly debt service according to this criteria is 40%×$4,000=$1,600. The customer already has to service $1,000 per month, leaving the customer with $600 per month for the auto loan. However, the decision engine will yield the lower of the monthly payments of $400 (from payment-to-income) versus $600, from debt-to-income. By making some other basic assumption on the term of the auto loan (for example, 5-year auto loans are most common loans) and interest rate that the customer qualifies for, and the maximum monthly payment the customer can afford, the maximum loan amount can be determined. Modifications of this sort need to be made to the decision engines to use them for this invention.
The second way the decision engine needs to be modified is to turn the application into a pre-selection, and not a true application. The typical decision engine produces a decision (e.g., approve/decline/counter-offer, or Yes/No/Maybe, respectively). The modified decision engines in this case produce a pre-selection offer where the customer is offered a choice of a lending product, where the positive result of the application (approval) is known with near certainty. The engine needs to be modified to reflect this difference.
Once all the modified decision engines have produced their approval, firm offers of credit can be made for all the lending products with very few caveats and terms, mostly concerning the collateral value and condition as related to secured lending. This kind of caveat is placed on credit offers even at the point of actual application. Since the collateral is not known and defined at this point, some constraints need to be placed on its valuation and nature (especially, as it relates to any loan-to-value constraints the lender may want place on the collateral). For an automobile loan, for example, the lender can place a loan-to-value constraint of 120% and a constraint of being not older than 7 years. For a home equity line of credit, for example, the lender can place a cumulative loan-to-value constraint of 90% and a constraint of being a single family dwelling.
This way, the consumer has more choices and options in front of herself/himself (with more motivation and opportunity to buy more or borrow more from the same financial institution), and the banks have happier and more satisfied consumers, with more offerings and products (See
As shown in
As shown in
Section 5: Deposit Slip Purchase
Here, in this section, we deal with the Deposit Slip Purchase. Let's consider the following situation: A consumer goes to a bank or any device (e.g. his own tel. or computer, at home or while mobile, or an ATM machine), to deposit money or check or other instruments into his/her account, e.g. into a checking account. Sometimes, a bank does not have any local branches in the specific city or country, then e.g. this can be done through the participating local stores or merchants or any signed up agent, e.g. grocery store chains, e.g. Sears or Walmart, which have many branches in different locations, acting as a proxy for the bank with no local branch.
Thus, the local merchant (for a fee or percentage, or goodwill, as an advertisement) can accept the cash from the consumer, and send the money directly to the out-of-state or remote bank, which can also charge or subtract its own fee from that amount, directly. Then, the deposit slip is issued and activated, which can be used on-line, as a credit (or cash out), for example, using a security method or module, e.g. using barcode or code or PKI or password or biometrics, by a barcode reader or camera analyzing the one or 2-dimensional bar codes, from one's computer, mobile phone, communication device, camera, or the like.
Generally, customers can deposit non-cash items via mail, fax, scan, or mobile device, deposited to their account. Cash deposits are usually a big challenge for remote lenders, since the customers have to convert their currency bills or coins into a check or instrument that can be deposited into an account. There are 2 methods here, as an example:
Method 1:
-
- Deposit slips offered for purchases
- Banks make fixed denomination deposit slips available to select participating retail or reputable outfits/merchants/agents/third parties, or those who have enough credit and trust/business backing and insurance/reliability/credibility.
- Customer buys the deposit slips from a merchant, once the deposit slip (with its bar code, identification tag, RFID tag, chip integrated tag, optical or radio wave tag, smart card tag, microprocessor tag, or any other tag) is activated. (See, e.g.,
FIG. 22 .) - To finalize the transaction, the customer takes the slip and uses the bank's web site to enter the deposit slip into his/her account. (See, e.g.,
FIG. 23 .) - Any of the above methods (e.g. mail, fax, scan, text, email, or mobile deposits), in combination, can also be used to deposit the slip into an account.
Method 2:
-
- Customer purchases a money order from a provider of money order for his/her desired denomination, using the cash at hand.
- Provider may have to be known or certified or contracted or accepted or verified or may have an agreement with the lender, so that the pricing structure and handling fees for provider are clear and known to all parties in the transaction, so that the provider can clear and get funding for all the issued instruments, periodically, for the last period, e.g. monthly, at the end of the month.
- The customer deposits the money order into his/her account with one of the above methods (e.g. mail, fax, scan, text, email, or mobile deposits).
- The bank may decide to reimburse the customer for this fee, subject to an optional monthly cap.
- If the deposit follows an automated method, such as, scan, text, email, or mobile picture transmission, the receiving processor may have to detect the issuing entity of the money order, as an approved one, for the customer to be eligible for the fee reimbursement.
- For the manual methods mentioned above, such as mail or fax, the human on the receiving end of the remote bank can establish the issuing entity and record it in the system, such that the reimbursement can take place.
This is very scalable for the banks with low number of branches or remote banks or Internet-based banks, to save cost, and increase profitability, plus attracting more customers, with current cash deposit problems, which can be solved with our method mentioned above. This will be the wave of the future banking business, as well, which will grow more, as more functions are automated or computerized.
As shown in
Section 6: Reducing Frauds on Credit Cards
To reduce fraud, banks need more photo ID and biometrics or PKI or steps to transact for a consumer, which is very inconvenient and time consuming for the card upgrades or card usage during purchases for a consumer. To encourage participation and volunteer acceptance of fraud prevention techniques, e.g. to be added to the credit cards, e.g. as a extra ID or biometrics, or as an extra step of verification for the consumer to go through each time for each purchase at the store or on Internet, to reduce fraud, and reduce the cost of banking/transactions, the lender can offer lower rates for such preferred customers, so that more customers will participate in such programs, despite the inconveniences associated with them.
In fact, the bonus, e.g. as a lower rate offered, offered to the customers, is the result of the saving for the bank, due to less fraud/less cost for the bank, which came from volunteer participation of the consumers, who opted for such higher standard of security and verifications, to reduce risk for the banks, for which they get some benefits back from the banks (See, e.g.,
The incentives for consumers (as preferred customers or high-security customers) can be lower or no fees for transactions or interchanges, or no minimum or higher minimum threshold for balance of checking accounts, or lower interest rates charged by the banks for different offerings, or any fees waived or reduced by the bank, or lower wiring fee or other service fees (or zero fee), or any similar offerings, that can be contracted and advertised by the bank (predetermined benefits), to attract current or future customers and to encourage them to join high-security programs, e.g. putting ID pictures or biometrics or password or PKI information on magnetic strips or on the card itself, as humanly-visible data or encoded/encrypted data, for reader/computer to capture/read/analyze/compare/verify/authenticate.
As shown in
General Notes for all Embodiments Above:
As shown in
As shown in
Please note that, in general, any teaching here for “pre-approved” also applies to “pre-selection”, including everything in specification, text, and figures.
Please note that there are 2 usages for the word “application” in our disclosure above: One is “lending product application”, and the 2nd one is the mobile device application/software/code, loaded on the phones or smart phones, as an example. The different usages are clear from the context.
For all teachings above/here, the concepts taught for lender also apply to card issuer, merchant bank, bank, mortgage issuer, and financial institution (i.e. they can be interchanged and replaced with each other). The same is true for phrases loan, financial product, consumer loan, car loans, home loans, credit card loans, student loans, and bank loan.
Please note that for all the teachings of this patent application, the concept of smart phone or phone here also applies to game platforms/consoles, interactive devices, display devices, monitors, multipurpose computers, GPS devices, map finders, pagers, radios, one-way broadcasters, two-way communicators, communication devices, cell phones, wireless devices, wired devices, processors, microprocessors, communication devices, computers, tablets, PDAs, laptops, computing devices, simulation devices, or other similar gadgets that can function the same, e.g. communicate with others, e.g. with a user interface or GUI.
Please note that all the teachings above for communications between 2 points or multiple points can be done by wire, cable, optical, laser, sound, electromagnetic waves, RF, microwave, wirelessly, pulse data, packets, Internet protocols, analog, digital, modulated, encrypted, encoded, with header, without header, intermodulated, mixed, phone, cell phone, mobile device, PDA, broadcasting, pager, one-way, two-way, WiFi, BlueTooth, Internet, network, private network, secure network, mixed or combination of networks, and in any format. The connection between 2 points may be direct or indirect, logical or electrical, or through intermediary, or another device in between.
Please note that for all the teachings above, the word “processor” (a device) (which is non-human for our entire disclosure) can be interchanged with one or more of the following: microprocessor, computer, computing processor, microcomputer, computing device or apparatus, computing subsystem, computing module, module (a device, not a software), calculating device, analyzing device, logic design circuit, computational circuit, digital circuit, functional circuit, mathematical or logical operation circuit, or analog circuit. Please note that for all the teachings above and throughout this disclosure, all of the terms mentioned in the current paragraph refer to a device or hardware.
Throughout this disclosure, the following refer to a hardware or device: repository, storage, database (or DB), store (either referring to a computer(s) or server(s) hosting a web site, or a brick-and-mortar building), App store (referring to a computer server or host server or computer(s)), computer, server, system, subsystem, module, terminal, network, Internet, interface, UI (user interface), GUI (graphical user interface), display, PC (personal computer), PDA (personal digital assistant), reader, scanner, processor, input module, engine, tablet, GPS, biometrics verifier, cashier register, clearing house (referring to a computer server or host server or computer(s)), aggregator (referring to a computer server or host server or computer(s)), and data collector.
Every module or device or system or subsystem or server or database or storage or memory unit here in our teachings may have one or more of the following included or attached to it (without showing all the details in the figures, to simplify the figures): a processor or microprocessor, server, PC, computer, PDA, smart phone, pager, GPS, wireless communication module, one or more memory units or RAM or ROM or storages or databases or temporary buffers, display, keyboard, user interface, GUI, mouse, input device, voice command recognition unit, cable, fiber optics, laser, optical communication module, magnetic device, acoustic device, wireless device, RFID, wired device, Bluetooth, WiFi, antenna(s), dish, array of antennas, satellite or cell reception or transmitter device, wireless interface, Internet or network interface, security interface, biometrics interface, printing interface, voice recognition interface, OCR and handwriting recognition interface, or any other interface or formatting devices.
Please note that all the teachings in this disclosure for division of a company also apply to sister company, affiliate, parent company, subsidiary, joint venture, or mother company.
All the tables shown in this disclosure show a data structure, which can be stored on a storage media (hardware) or a computer hard drive (device) or on a server (device).
Note that these alternative methods of communications and notifications apply to all other embodiments. Sometimes, the lender requires more information or documents from the customer, which can be either sent in person, or by mail, fax, telex, wire, optical method, wirelessly, sound waves, electromagnetic waves, satellite, cell phone, cable, email, text messages, SMS, or smart phone/communication devices, computers, tablets, PDA, or laptops.
Please note that the diagrams, flow charts, or methods shown in the figures or described in the text can be processed in an automated or computer system as a work flow or batch processing technique.
Any variations of the teaching above are also intended to be covered and protected by the current patent application.
Claims
1. A loan product approval method by a lender, said method comprising:
- a lender computing device receiving a loan application, regarding a customer, from a lender application receiving device;
- said lender computing device receiving credit information regarding said customer from one or more credit bureau databases;
- a rate or index aggregator module receiving an interest rate or market index from an index or rate feed module;
- said lender computing device receiving said interest rate or market index from said rate or index aggregator module;
- a related information input module receiving historical information about said customer;
- wherein said historical information about said customer comprises financial history, past loans' payment patterns, rebuilding credit profile, and number of delinquencies for said customer;
- said lender computing device receiving said historical information about said customer from said related information input module;
- said lender computing device receiving parameter information from a loan application set current and future parameters database;
- a market data input module supplying market parameters to a future forecast processor module;
- an analyst input module supplying expert analysis to said future forecast processor module;
- said future forecast processor module supplying processed forecasting information to a risk analyzer module;
- a ratio database supplying one or more loan ratios to said risk analyzer module;
- said loan application set current and future parameters database communicating said parameter information to said risk analyzer module;
- said risk analyzer module calculating risks involved with said customer for current and future situations;
- said risk analyzer module sending said risks involved with said customer for said current and future situations to said lender computing device;
- a rate analyzer module communicating with a rate and parameter setting module;
- said rate and parameter setting module appointing a rate or interest formulation for said current and future situations;
- wherein said rate or interest formulation for said current and future situations is set permanently based on a predetermined formulation stated in an original agreement corresponding to said loan application;
- said rate and parameter setting module sending said rate or interest formulation for said current and future situations to said lender computing device;
- said lender computing device receiving updated personal data for said customer;
- upon receipt of said updated personal data for said customer, said lender computing device automatically calculating a new interest rate and terms using all information from said updated personal data for said customer, said interest rate or market index, and said historical information about said customer, based on said rate or interest formulation for said current and future situations;
- wherein said updated personal data for said customer comprises updated employment history, income, and outstanding loans for said customer;
- said lender computing device sending a notice to a notification module, regarding said new interest rate and terms;
- said notification module sending said notice to said customer's device, mobile phone, computer, email, or short message service.
2. The loan product approval method by a lender as recited in claim 1, wherein said loan product comprises a fixed rate loan portion.
3. The loan product approval method by a lender as recited in claim 1, wherein said loan product comprises a variable rate loan portion.
4. The loan product approval method by a lender as recited in claim 1, wherein said loan application is related to one or more of following: automobile, motorcycle, bike, recreational vehicle, marine, unsecured installment, credit card, mortgage, home equity installment, or home equity line of credit.
5. The loan product approval method by a lender as recited in claim 1, wherein said loan product comprises an initial interest rate being larger than a final interest rate, at a later time.
6. The loan product approval method by a lender as recited in claim 1, wherein said lender computing device considers one or more of following items: housing expenditure, own or rent a house, collateral type, collateral value, requested amount, down payment, or estimated closing cost for said customer.
7. The loan product approval method by a lender as recited in claim 1, said method comprising: adding a relationship-based score for said customer.
8. The loan product approval method by a lender as recited in claim 1, said method comprising: updating a relationship-based score for said customer, periodically.
9. The loan product approval method by a lender as recited in claim 1, said method comprising: updating a relationship-based score for said customer, based on a predetermined or trigger event.
10. The loan product approval method by a lender as recited in claim 1, said method comprising: updating a relationship-based score for said customer, based on a predetermined market index.
11. The loan product approval method by a lender as recited in claim 1, said method comprising: updating a relationship-based score for said customer, based on a random variable or based on random time intervals.
12. The loan product approval method by a lender as recited in claim 1, said method comprises using one or more of following market or public financial indices: COFI, LIBOR, MTA, CMT, National Average Contract Mortgage Rate, BBSW, or Prime rate.
13. The loan product approval method by a lender as recited in claim 1, said method comprises using a collateral item.
14. The loan product approval method by a lender as recited in claim 1, said method comprises using a revolving credit.
15. The loan product approval method by a lender as recited in claim 1, said method comprises changing period of said loan product.
16. The loan product approval method by a lender as recited in claim 1, said method comprises using one-time upfront payment by said customer.
17. The loan product approval method by a lender as recited in claim 1, said method comprises using one-time payment by said customer.
18. The loan product approval method by a lender as recited in claim 1, said method comprises having an option to terminate said loan product early by said customer.
19. The loan product approval method by a lender as recited in claim 1, said method comprises using an authentication, security, or biometrics module.
20. The loan product approval method by a lender as recited in claim 1, said method comprises using a verification module.
Type: Application
Filed: Jul 16, 2013
Publication Date: Nov 21, 2013
Inventor: Mehran Chirehdast (Plano, TX)
Application Number: 13/943,296
International Classification: G06Q 40/02 (20060101);
