The exemplary embodiments of this invention relate generally to cognitive credit scoring of informal financial transactions, and example embodiments encompass credit scoring of merchant receivables from informal transactions with multiple customers which may be used to obtain a loan for sustaining and/or expanding the merchant's business.
When providing loans to customers and entrepreneurs, bank assess the risk by verifying financial data from them such as monthly income, credit history, bill payment and transactions history, and the like, and the loan is provided if all this information fulfils the loan risk requirements. But analyzing the risk of the unbanked and underbanked population is a challenge. Most of these populations do not have credit and transaction history data which makes it difficult for the banks to evaluate their repayment risk. Many times such non-traditional prospective borrowers will themselves use informal financial practices such as lending among friends and within their own neighborhood. Another common practice is to sell goods in exchange for a promise to pay later (such as in a month or more) when the customer is expected to have money to repay the informal loan. In many of these cases the payment due dates are uncertain and somewhat malleable among the parties, which also means uncertainty in when these informal lenders will themselves be paid back. These types of informal transactions involve trust between the parties.
In the
In a first aspect thereof the embodiments of this invention provide a method performed on at least one computing device, the method comprising: receiving a requester's credit request comprising a reason, a credit amount, a repayment period and a number of installments; and in response:
In another aspect thereof the embodiments of this invention provide an apparatus comprising one or more memories comprising computer-readable code and one or more processors. The one or more processors are configured, in response to execution of the computer-readable code, to cause the apparatus to perform actions comprising: in response to receiving a requester's credit request comprising a reason, a credit amount, a repayment period and a number of installments:
In a further aspect thereof the embodiments of this invention provide a computer readable memory storing program code that is executable by a computing system to cause the computing system to perform: receiving a requester's credit request comprising a reason, a credit amount, a repayment period and a number of installments; and in response:
Embodiments of these teachings concern a credit scoring model that uses information from informal financial transactions such as those outlined in the background section above. The model that is presented herein by example and not by way of limitation can be combined with traditional information, if available, such as past transaction history and personal data of the merchant's individual customers as well as the merchant him/herself.
It is known to generate a financial credit score based on consumer financial data (U.S. Pat. Nos. 7,925,582 and 7,877,304) or financial transactions (US 2014/0156501). Calculating an anticipated credit score is also known (US 2012/0278227), as is the use of hypothetical values for simulating a credit score (U.S. Pat. No. 8,335,741). Other techniques are to calculate a property value based on the owner's credit score (U.S. Pat. No. 8,494,792) and to base a credit score on a share of a wallet (US 2014/0012734; U.S. Pat. No. 8,447,689) or spending capacity information (U.S. Pat. No. 8,438,105). Credit scores can be improved by settling debts (U.S. Pat. No. 7,814,005), or improved for a motor vehicle loan by installing a location device (US 2013/0117173). Future credit scores can be predicted (US 2010/0268639) and credit scores can be used in real time when authorizing transactions (US 2010/0010930). Psychometrics interview data can be used in creditworthiness checks (US 2004.0177030) and can be done in the absence of traditional credit bureau data (U.S. Pat. No. 8,386,377). Credit scores can be based in personal data gathered from an online social footprint (U.S. Pat. No. 8,694,401) and different trust record sources can be used to build an aggregated trust profile (US 2010/0076987). Score reputation can be based on the reputation of online marketplace participants (US 2007/0192169), and there are also specific ways to evaluate a merchant's reliability (US 2008/0270209) as well as how to detect fraudulent online merchants (US 2011/0225076). But none of these are seen suitable for enabling a merchant that serves the unbanked or underbanked population to monetize his/her receivables from that population as outlined with respect to the
Embodiments of these teachings include a system and method for cognitive credit score. Such a system contains models capable of learning from various types of data, including informal financial transactions and personal data, and is capable of adjusting and adapting dynamically as the system gains new knowledge with new incoming data. As mentioned in the background section, such informal transactions may include a promise of future payments from a client/customer in exchange for a service or good provided by a merchant. Normally during these informal transactions no cash is exchanged; the merchant provides to the client/customer the good or service to the client and writes the purchase in a notebook, such as the customer name, amount, date to repay, and the like.
In such a case, embodiments of these teachings first have the merchant enter the records from the notebook in the cognitive system that later will be used to generate a score of these customers. The score of these customers will then be used to score the credit of the merchant when that merchant applies for a loan. In broad terms this may be considered somewhat like invoice discounting or loans against accounts receivable, where the borrowing involves the use of the accounts receivable assets as collateral for the loan.
One aspect of these embodiments is that the responsibility for raising payment for the sales invoice and credit control stays with the merchant; the bank or other lending facility that provides the loan to the merchant has no access to the merchant's specific receivables for the informal transactions because the lending facility is given information on which to base its approve/disapprove decision for the loan that is insufficient to identify any of the merchant's individual informal transaction customers/debtors. In these embodiments no reports on the sales ledger and credit control process is sent to the lending facility/credit provider, which ensures the privacy of these unbanked/underbanked customers that enter into the informal financial transactions with the merchant. In this regard all the relevant processing is executed locally at the merchant's system. In the
To provide additional assurances to the lending facility the software running the cognitive credit scoring process on the merchant's system can provide the lending facility with certain security/non-corruption markers to prove the software has not been tampered with to alter the bundled score and/or new credit score that is output for consideration by the lending facility.
The system is run locally, under control of the merchant since it needs access to the customer repayment information which is to be kept private from the lending facility itself. The system will aggregate the customer repayment information that is relevant to the merchant's loan request into a ‘bundle’ and establish a credit score for that bundle so that the bundle score can be provided to the lending facility/bank without revealing the financial information of the individual customers with whom the merchant has informal transactions that are relevant to the merchant's repayment of the loan he/she is requesting.
The system uses this information to select a set of informal transactions and to generate a score for this bundle. The bundle can include multiple customers, as well as multiple informal transactions from one or more individual customers. The score is based on the past transactions of the customers that are selected for the bundle, for example the customers that always pay on time will have a higher score than the ones that always pay late (assuming all other considered factors are equal). The customers selected for the bundle are those for which there is at least one payment due to the merchant, during the term of the merchant's requested loan and whose repayments are to support the merchant's own loan request, on an outstanding balance due to the merchant according to an informal transaction. Then the system generates or otherwise computes a unique score (the bundle score) from all the individual scores collected from the selected customers. So, for each different loan request by the merchant there will be a different bundle selected and the bundle score will be generated on that specific bundle.
With the bundle score now calculated, the merchant's loan request is then sent to the lending facility/credit provider at step 202 along with the bundle score to be analyzed for an approve/disapprove/modify decision. The lending facility/credit provider may be a bank, a peer-to-peer lending group, a micro-credit agency, an individual, or the like. The credit provider receives the merchant's loan request and checks the bundle score at step 203 of
As
This is not to exclude embodiments in which the merchant's request ha's a blend of traditional and non-traditional transactions to be used as collateral or proof of the merchant's repayment ability; in one implementation all of the transactions supporting the loan request are bundled regardless of whether or not they are conventional credit/installment agreements, while in another implementation only the non-traditional financial transactions with the merchant are used to form the bundle score and other more conventional credit arrangements between the merchant and his/her customers are separately detailed to the credit provider as is conventional for financing a merchant's receivables from borrowers whose repayment risk can be evaluated conventionally. For simplicity in further detailing the more novel aspects of these teachings, the description below assumes the bundle score represents only the merchant's non-traditional financial arrangements which would typically be with the merchant's un-banked or under-banked customers.
The credit risk predictive models according to embodiments of these teachings can be built using statistical methods, and/or machine learning methods and/or artificial intelligence methods. Such methods correlate the various data in order to discover patterns and predict credit risk. Examples of machine learning and statistics techniques include but not limited to:
The credit risk predictive model according to these teachings can utilize one or more of the above techniques.
The request interface 310 receives the input for a credit request which includes at least the merchant's reason for the credit (for example to buy new furniture or rebuild the store), the amount requested, the period for repayment (for example 2 months or 6 months) and the total number of installments (for example 6 or 12 installment payments spread out over the repayment period).
One type of information that is input into the credit score model is repayment control per customer 321, which includes the information about the debt per customer such as for example the customer's purchase history with date of purchase, date to pay, amount, type of good and historical debits that have been repaid and whether those repayments were on time or late (and if late by how much).
Another type of information that is input into the credit score model is the merchant's cash flow information, which includes information about inventory, selling history and sales forecasts, and cash outflow such as utility, rent and supply expenses and payroll and the like so the model can calculate the balances at various dates during the credit repayment period. The lower portion of the table at
The financial and personal data analyzer 330 of
Finally the credit score model 320 can operate to compute the new credit score based on bundle of debt. This model is created based on the customer debit/repayment control 321, for example was payment made on the day agreed, was it in full or in part, how many transactions has this customer had, what is the value of his/her purchases, and the like. This information can be retrieved from the databases and it can be refined periodically, as may be configured by the system administrator. When a request for credit 301 arrives, the model 320 is used to compute the creditworthiness of the set of users or bundle, based on the provided information per customer 321 where the specific customers to use for the model 320 are selected for a particular credit request 301. As noted above, the model 320 can use statistical methods, machine learning and/or artificial intelligence.
One aspect of the model's analysis of the merchant's selected customers is shown in the rightmost column of
First the model selects all of the customers/debtors who have at least one payment due to the merchant during the total repayment period of the merchant's credit request. Then these selected customers/debtors are ranked based on their individual score and their individual repayments due to the merchant. Then the model makes a further selection among these ranked customers/debtors for each of the installment periods/due dates of the merchant's credit request, beginning with the highest ranked debtor, until the payment amounts due from all these further selected debtors equals the merchant's payment amount for the given installment period of the merchant's credit request. It is this further selection of customers/debtors whose individual scores are used to compute the bundle score.
The bundle score aggregates at least the risk assessed concerning repayment by the selected customers, and in some embodiments such as is shown at
In order to have cash to pay the loan, Junior depends on the repayment from Maria, João, José and Carol at each of the 30-day, 60-day and 90-day. So, the system uses the individual credit score from each customer (in this example Maria 0.8, João 0.5, José 0.7 and Carol 0.9) to compute the final bundle credit score for Junior that will be 0.8. One embodiment is to use all the customer's individual scores that will pay during the repayment period to compute the final bundle score. Another embodiment makes a further selection among these ranked customers/debtors for each of the installment periods/due dates of the merchant's credit request, beginning with the highest ranked debtor, until the payment amounts due from all these further selected debtors equals the merchant's payment amount for the given installment period of the merchant's credit request.
The output of processing these various inputs by the model 320 is a new credit score 340. In
Specifically, at block 504 a plurality of the requester's debtors are selected, those debtors which have a payment due to the requester during the repayment period. In the
Block 506 retrieves the respective repayment information for the repayment period for each of the debtors that were selected at block 504. These are shown in
Block 508 retrieves the requester's cash flow information such as the periodic total cash inflows and outflows at
There is a repayment probability score per debtor that is computed at block 510 for the case where the accumulated balance is greater than the amount of the credit request, which is based on at least the respective debtor's repayment history prior to the repayment period. If for an individual customer/debtor there is no repayment history available (for example, this merchant/requester has never extended credit to this customer/debtor prior to the existing debt) then basing the probability score for this particular customer/debtor on the fact that there is no repayment history for him/her is sufficient. If any of the customers/debtors have traditional banking history the traditional credit reporting data can be gathered at 331 of
Now there is a further selection among the customers/debtors to arrive at only those whose payments to the requester/merchant will be supporting the merchant's credit request. At block 512 the debtors from block 504 are ranked, based on their respective probability score and the amount of their respective payments due per installment. Then at block 514 there is a further selection from among these ranked debtors, and this further selection is in order of rank until a total of the amounts of the payments due per installment of the further selected debtors at least equals a payment amount of the respective installment. This is done over the entire repayment period to ensure there are enough debtors to support the merchant's repayment of each of the installment amounts.
Finally the repayment probability scores from block 510, of the debtors that are further selected at block 514, are aggregated into a bundle score at block 516. An example of such a bundle score is explicitly shown at
Block 518 of
In the
In the
In one implementation different from that shown at
The present invention may be implemented as a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) such as a memory having computer readable program instructions stored thereon for causing a processor to carry out certain aspects of the present invention.
The computer readable storage medium such as the memory can be a tangible device that can retain and store instructions for use by an instruction execution device (such as the data processor(s) of the computer, as shown as the credit score module 320 and/or the data analyzer 330 of
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed.
The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
As such, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. As but some examples, the use of other similar or equivalent vulnerability types may be used by those skilled in the art. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention.