Patent Application
20130151383
The present invention relates generally to the recommendation of items, and in particular, but not exclusively, to an automated system for recommending treatments for accounts in collections.
Today, original creditors, such as financial institutions, credit card issuers, utility companies and other service providers lose millions of dollars from uncollectible customer accounts. An original creditor may refer a customer's account to collections (hereinafter “delinquent account”) when no payment has been received at the end of one or more billing periods. Most original creditors have a collections department, in which delinquent accounts may be segmented into buckets. The buckets may identify the billing cycle that a particular delinquent account falls under. The buckets may generally relate to a length of time that a delinquent account is past due, for example, 1-30 days, 31-60 days or 61-90 days. The buckets may further be divided into smaller risk segments, for example, High Risk (low credit score, defaulted on last payment plan and several past bad debt accounts in the last 12 months) or Medium Risk (average credit score, history of on-time payments and less than 2 past bad debt accounts in the last 12 months).
Each of the bucket-risk segment combinations described above may roughly correspond to a particular set of treatments. For example, a delinquent account which has just entered collections (bucket 1) and is likely to pay the money back (low risk segment) may receive only a nicely worded reminder letter, or no action by the original creditor. After several consistent payments, the original creditors may “re-age” a delinquent account and may bring it back to a current status. A long overdue delinquent account which has a very low chance of repayment (high risk), may be charged-off by the original creditor; the balance of the delinquent account may either be sold or outsourced to a collection agency or other type of debt collection entity. The original creditor may also note the charge-off on the consumer's credit report for several years. An original creditor may also send a delinquent account to litigation, e.g. depending on the outstanding balance of the delinquent account.
This segmentation approach presents several problems although it bears some merit and may have been successful in the past. For example, the segmentation approach may create a system with a spaghetti-like environment, unprincipled and complex segmentation boundaries, non-optimal mappings between segments and treatments, and numerous rules. In another example, the segmentation approach may lack the ability to automatically learn and adapt to changes in the environment. In a further example, the segmentation approach may also suffer from an inability to rapidly apply aggressive treatments to a delinquent account that may currently be in a segmentation bucket that prohibits such aggressive treatment.
Therefore, there is a need for a system to evaluate the effectiveness of different treatments for delinquent accounts and provide dynamic treatment recommendations for changes in the environment of delinquent accounts.
The invention provides a recommender engine to analyze the effectiveness of treatments for delinquent accounts and make treatment recommendations, by using one or more sub-models, such as predictive models to analyze delinquent accounts and predict the likelihood that delinquent accounts may self-cure (become current without any intervention).
Embodiments of the present invention may include a computer-implemented method for recommending one or more treatments for delinquent accounts at a particular point in time. The method capable of performing at least the following steps of: accessing one or more servers, the one or more servers comprising a database with one or more sub-models, and a memory comprising reference data for historical accounts; expressing the reference data as a first set of n-element feature vectors in an n-dimensional feature space (historical vectors); receiving one or more recommendation request data records for delinquent accounts; converting the one or more recommendation request data records with the scores from one or more sub-models to a second set of n-element feature vectors in an n-dimensional feature space (request vectors); determining neighbors (neighbor vectors) from the first set of n-element feature vectors (historical vectors) for each of the second set of n-element feature vectors (request vectors), based on a recommender algorithm analysis of the n-dimensional feature space; from a superset list of treatments (all treatments), generating a second, subset list of possible treatments (allowed treatments) allowed by one or more sets of policy and regulation rules; for each treatment in the allowed treatments list, computing a fitness score utilizing in general the reference data (historical vectors), and in particular, the data from the neighbors (neighbor vectors); for each of the recommendation requests (vectors B), selecting at least one of the treatments available from the list of possible treatments for each of the delinquent accounts (allowed treatments); and presenting the selected at least one treatment to a user to produce the recommended treatment(s).
Embodiments of the present invention may include a system for recommending treatments for delinquent accounts at a particular point in time. The system includes a processor operable to execute programs; a memory coupled to the processor; a database associated with said processor and said memory; the memory comprising reference data for historical accounts; said programs comprising one or more sub-models; a program stored in the memory and executable by the processors, the program being operable to accessing reference data for historical account in the memory and the one or more sub-models, and implementing the recommendation method described above.
Embodiments of the present invention may include a user interface for a computer program so users may gain-insight to the system's operations or to fine-tune rules for a recommender engine for recommending one or more treatments for delinquent accounts. The user interface comprising a processor operable to execute programs; a memory coupled to the processor; the memory comprising reference data for historical accounts; a database associated with said processor and said memory; said programs comprising one or more sub-models; an analysis program stored in the memory, executable by the processor, the analysis program being operable to accessing the one or more sub-models in the database; expressing the reference data for historical accounts in the one or more sub-models as n-feature vectors in an n-dimensional feature space; reducing the n-dimensional feature space; selecting at least one of the n-feature vectors; generating a report about treatments and their efficacy for the selected at least one of the n-feature vectors; and displaying one or more fields for fine tuning rules for the treatments and the selected at least one of the n-feature vectors.
Additional features, advantages, and embodiments of the invention are set forth or apparent from consideration of the following detailed description, drawings and claims. Moreover, it is to be understood that both the foregoing summary of the invention and the following detailed description are exemplary and intended to provide further explanation without limiting the scope of the invention as claimed.
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate preferred embodiments of the invention and together with the detailed description serve to explain the principles of the invention. In the drawings:
In the following detailed description of the illustrative embodiments, reference is made to the accompanying drawings that form a part hereof. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is understood that other embodiments may be utilized and that logical or structural changes may be made to the invention without departing from the spirit or scope of this disclosure. To avoid detail not necessary to enable those skilled in the art to practice the embodiments described herein, the description may omit certain information known to those skilled in the art. The following detailed description is, therefore, not to be taken in a limiting sense.
Recommender systems or engines may be used to generate meaningful recommendations to a collection of users for items or products that might interest them. For example, suggestions for books on AMAZON, or movies on NETFLIX, are real world examples of the operation of industry-strength recommender systems. The design of such recommendation systems may depends on the domain and the particular characteristics of the data available. For example, movie watchers on NETFLIX frequently provide ratings on a scale of 1 (disliked) to 5 (liked). Such a data source records the quality of interactions between users and items. Additionally, the recommendation system may have access to user-specific and item-specific profile attributes such as demographics and product descriptions respectively. Recommender systems differ in the way they analyze these data sources to develop notions of affinity between users and items which can be used to identify well-matched pairs.
The myriad of approaches to recommender systems may be categorized broadly as Collaborative Filtering, Content-based recommending or Hybrid approaches. Content-based approaches may work by recommending items that are similar in content to items the user may have preferred in the past, or matched to attributes of a user.
The Hybrid approach recommender systems leverage the strengths of the content-based and collaborative recommenders. For example, the Hybrid approach may allow both content-based and collaborative filtering methods to produce separate ranked lists of recommendations, and then merge their results to produce a final list.
Collaborative Filtering is the process of filtering for information or patterns using techniques involving collaboration among multiple agents, viewpoints, data sources, etc. Applications of collaborative filtering typically involve very large data sets. Collaborative filtering methods have been applied to many different kinds of data including sensing and monitoring data—such as in mineral exploration, environmental sensing over large areas or multiple sensors; financial data—such as financial service institutions that integrate many financial sources; or in electronic commerce and web 2.0 applications where the focus may be on user data, etc. Collaborative filtering may be used to make automatic predictions (filtering) about the interests of a user by collecting taste information from many users (collaborating). The underlying assumption of the Collaborative filtering approach may be that those who agreed in the past tend to agree again in the future. For example, a collaborative filtering or recommendation system for television tastes could make predictions about which television show a user should like given a partial list of that user's tastes (likes or dislikes). Most collaborative filtering systems have the following common elements:
There are three types of collaborative filtering methods, memory-based, model-based and hybrids algorithms. Memory-based collaborative filtering algorithms may utilize user rating data to compute similarity between users or items. Memory-based algorithms may be used for making recommendations and may be used in many commercial systems. Memory-based algorithms may be easy to implement and are effective. Typical examples of Memory-based algorithms may be neighborhood based collaborative filtering and item-based/user-based top-N recommendations. The neighborhood-based algorithm may calculate the similarity between two users or items, produce a prediction for the user taking the weighted average of all the ratings. Similarity computation between items or users may be an important part of this approach. Multiple mechanisms such as Pearson correlation and vector cosine based similarity may be used for this neighborhood-based algorithm approach. The user based top-N recommendation algorithm identifies the k most similar users to an active user using similarity based vector model. After the k most similar users are found, their corresponding user-item matrices are aggregated to identify the set of items to be recommended. A popular method to find the similar users may be the locality sensitive hashing, which may implement the nearest neighbor mechanism in linear time.
Model-based collaborative filtering algorithms are developed using data mining, machine learning algorithms to find patterns based on training data. These may be used to make predictions for real data. There are many model based Collaborative Filtering algorithms, such as Bayesian Networks, clustering models, latent semantic models such as singular value decomposition, probabilistic latent semantic analysis, Multiple Multiplicative Factor, Latent Dirichlet allocation and Markov decision process based models. Model-based algorithms may have a more holistic goal to uncover latent factors that explain observed ratings. Most of the Model-based algorithms may be based on creating a classification or clustering technique to identify the user based on the test set. The number of the parameters may be reduced based on types of principal component analysis.
Hybrid collaborative filtering algorithms combine the memory-based and the model-based collaborative filtering algorithms. Hybrid algorithms may overcome the limitations of other collaborative filtering approaches. Hybrid algorithms may provide improved prediction performance over memory-based or model-based algorithms. Importantly, hybrid algorithms may overcome the collaborative filtering problems such as sparsity and loss of information. However, hybrid algorithms may have increased complexity and may be more expensive to implement.
In one embodiment of the invention, a recommender engine 101 is provided that may use a neighborhood-based/memory-based collaborative filtering approach to recommend consumer items or products. In some alternatives of the invention, the consumer items or products may be consumer accounts, consumer accounts at various states in a debt collection cycle, such as historical accounts, delinquent accounts, new accounts or test accounts. The recommender engine 101 may be implemented with one or more computer systems. Each computer system may be well known to those skilled in the art and may include a display, a central processor, a system memory 105, and a system bus that couples various system components including the system memory 105 to the central processor unit. System bus may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The structure of system memory 105 may be well known to those skilled in the art and may include a basic input/output system (BIOS) stored in a read only memory (ROM) and one or more program modules such as operating systems, application programs and program data stored in random access memory (RAM). The computer systems may also include a variety of interface units and drives for reading and writing data and a database 104 for storing data. The computer systems may operate under the Linux Operating system, Microsoft Operating system or other operating system. The computer systems that implement the recommender engine 101 may be implemented on a variety of hardware platforms or implemented in a variety of software environments.
As used herein, a database 104 may be a relational database, flat file database, relational database management system, object database management system, operational database, data warehouse, hyper media database, post-relational database, hybrid database models, RDF database, key value database, XML database, XML store, text file, flat file or other type of database.
In one embodiment of the invention, the recommender engine 101 may be a net-centric real-time system implemented in an Application Service Provider (ASP) model that allows users to receive dynamic treatment recommendations for delinquent accounts. An ASP model includes but may not be limited to a model wherein an application may be hosted on a server which can be accessed by the Internet or a network. In one alternative, the present invention may be embodied in a computer program, typically an application program running on a Web server that facilitates the ad-hoc treatment recommendations for delinquent accounts. Although the illustrative embodiment will be generally described in the context of an application running on a Web server, otherwise known as an ASP model, those skilled in the art will recognize that the present invention may be implemented in any distributed computing environment including local area networks, wide area networks, and the Internet. The network may include permanent connections, such as wire or fiber optic cables, or temporary connections made through telephone or wireless communications. The distributed computing environments may include the Internet with networks representing a worldwide collection of networks and gateways that use various protocols to communicate with one another, such as Lightweight Directory Access Protocol (LDAP), Transport Control Protocol/Internet Protocol (TCP/IP), Hypertext Transport Protocol (HTTP), Wireless Application Protocol (WAP), and others.
In some alternatives, the recommender engine 101 may operate in a model using an Extensible Markup Language (XML) interface. In some alternatives, the recommender engine 101 may comprise a secure Internet Web site or gateway, thereby ensuring the privacy of users and customer data. The recommendation engine 101 may minimize the amount of hardware and software the users must purchase and maintain. In some alternatives, the recommender engine 101 may be accessed from a users' 102 Web site. In some alternatives, the recommender engine 101 may also be accessed via a Virtual Private Network (VPN).
In some alternatives, the recommender engine 101 may consist of an Application Programming Interface (API). The API may consist of a number of function calls to the recommender engine 101. The API may be accessed using communication protocols, such as the Simple Object Access Protocol (SOAP) protocol and data may be submitted to the API using XML. In some alternatives, calls to the API may be synchronous.
In some alternatives, the recommender engine 101 may be deployed in an ASP model in which the client device sends data to the recommender engine 101 and receives a response in real time. In some alternatives, the recommender engine 101 may be deployed in an ASP model in which there may be one or more additional layers between the client device sending the data and the recommender engine 101 receiving the data. Client devices accessing the recommender engine 101 may include, servers, personal computers, laptops, notebooks, netbooks, tablet PCs, smart phones and other wireless devices with a browser, which may be a well known software application for accessing documents and processing messages in a variety of formats, such as graphic files, word processing files, XML, Hypertext Markup Language (HTML), Handheld Device Markup Language (HDML), Wireless Markup Language (WML), Security Assertion Markup Language (SAML), and various other formats and types of files. Client devices may include a display, a processing unit, memory such as RAM and ROM etc, data and program storage, and network or Internet transmission media.
Referring now to
In some alternatives, the recommender system 101 may start up without any historical accounts 109 in memory and learn on its own. In some alternatives, the memory 105 of the recommender engine 101 may contain reference data from historical accounts 109 such as account demographics, treatments, model scores, account properties, account behaviors (e.g. promises to pay), days past due, the final collections result on the account, and other account attributes. In some alternatives, the memory 105 may contain multiple entries for a particular historical account 109. The multiple entries may represent snapshots of the historical accounts 109 at different points in time.
In some alternatives, the recommender engine 101 memory 105 may contain a list of treatments 107 available for all types of delinquent accounts. In some alternatives, similar treatments 107 with significantly varying intensity may be represented as separate treatments in the recommender engine 101. For example, a strongly worded letter may be represented as a separate treatment 107 than a gentle reminder letter. In some alternatives, the single treatment 107 represented in the recommender engine 101 may contain several sub-treatments 107 in a particular order and timing. Other examples of treatments 107 may include a letter sent to the holder of a delinquent account (hereinafter “debtor”), a phone call may be made by a collection specialist, or no action at all may be taken. Letters and phone calls may be made at a variety of different times, and may target both the debtor's home and work locations. Electronic mail and Short Message Service (SMS) messages may also be used to contact the debtor. The original creditor may assess late fees and penalties to the debtor's delinquent account, and the original creditor may offer the debtor delinquent account counseling. The original creditor may allow the debtor to restructure the delinquent account, forgive a portion of the delinquent account, make multiple smaller payments or borrow additional money. The original creditor may perform a skip trace search if the debtor is missing. Finally, the original creditor may pursue legal action against the debtor or sell the delinquent account to a collection agency or other debt collection facility.
An operational cost may be assigned to each treatment 107 by the users 102 of the recommender engine 101 or by the recommender engine 101 based on analysis of historical data 109. A relationship cost may also be assigned to each treatment 107 by users 102 of the system or by the recommender engine 101 based on analysis of historical data 109.
In some alternatives, the recommender engine 101 memory 105 may contain a set of rules 108. The rules 108 may restrict which particular treatment 107 a delinquent account 111 may be eligible to receive at a particular point in time. For example, a rule 108 may suggest that a delinquent account 111 less than 10 days past due cannot be sent a strongly worded letter. In some alternatives, the rules 108 may embody the policy of a particular original creditor as well as any applicable governmental or financial industry regulations. In some alternatives, the rules 108 may also represent interactions between treatments 107. For example, the rules 108 may suggest that a settlement offer may not be presented to a delinquent account 111, which had been in a forbearance program anytime in its history. In another example, an individual rule 108 might state: “If 3 or more letters have been sent in the last 60 days and no response received, consider rule ‘ignored #1’ to have fired.” In another example, another rule 108 might state: “If 2 or more ‘ignored’ rules fire and the outstanding delinquent account may be over $150, then utilize phone call script #6.” In this example, “phone script #6” may be a specifically developed script for collectors to use with debtors who ignore communication efforts. In some alternatives, rules 108 may typically have tunable parameters, for example, “3 letters,” “60 days,” “$150” “2 rules fired,” etc. In some alternatives, the rules 108 may be authored by users 102 of the recommender engine 101. In some alternatives of the invention, the recommender engine 101 may be provided with a default set of rules 108 and these rules 108 may be modified by the users 102.
In some alternatives of the invention, the recommender engine 101 may output one or more types of reports 112. In some alternatives, the reports 112 may contain information or rationale by the recommending engine 101 for recommending a particular treatment 107. In some alternatives, human analysts may update the expert rules 108 in the recommender engine 101 as policies and regulations change. In some alternatives, a request for recommendation 113 from the users 102 may not update the recommender engine 101 memory 105. In some alternatives, users 102 may update the client device with a notification record 114 about a delinquent account 111. Notification records 114 received from the client device 103 of events that may have occurred with a delinquent account 111 may update the recommender engine 101 memory 105.
In step 202, a user 102 via the client device 103 may send a request for recommendation 113 or notification record 114 or scoring request data to the recommendation engine 101. In some alternatives, the scoring request data record may be a request for recommendation 113 or notification record 114 generated by the client device 103 containing fields as defined by an XML template or proprietarily API format as illustrated in
In step 203, the recommender engine 101 may utilize one or more sub-models, generated using known techniques. In some alternatives, the sub-models may be predictive models. The recommender engine 101 may employ multiple different types of sub-models, including neural networks, regression analysis, integrated rules systems, decision tree models and other statistical models known in the art. In some alternatives, the sub-models may be used to predict accounts in early delinquency that will self-cure, straight roller accounts (accounts that will never be paid no matter what types of interventions are attempted), the correct collection specialist to work on a delinquent account, the optimum method of communicating with a debtor, the net present value of a delinquent account 111, and the best time to contact a debtor. The sub-models may be generated by using data from the recommender engine 101 memory 105, which may store historical accounts 109, all of their treatments 107 and rules 108 for use as neighbors to properly train the desired sub-model. Sampling of the data from the recommender engine 101 memory 105 may be conducted using any methods known in the art. The sub-models may convert the data to n-feature vectors in an n-dimensional feature space using known techniques. A feature vector may be generally an n-dimensional vector used in, for example pattern recognition and machine learning for providing a numerical representation of an object. Many algorithms in machine learning require a numerical representation of objects, because such representations may facilitate processing and statistical analysis. According to the present invention, each feature vector for sub-model scoring comprises many features derived from fields in the scoring request data record or historical accounts 109 data. In some alternatives of the invention, the n-dimensional feature space for determining neighbors may be a 3-dimensional feature space. In some alternatives, the n-feature vectors may be stored as a set of numbers.
In some alternatives, the sub-models may score the data received from the request for recommendation 113 or notification record 114 for a delinquent account 111. In some alternatives, the recommender engine 101 may query the sub-models for a score and the memory 105 for similar historical accounts 109 to the request for recommendation 113 or notification record 114 for a delinquent account 111 received by the recommender engine 101.
The recommender engine 101 may then query the rules to first determine the list of all treatments 107 that may be available from memory 105 for the delinquent account 111. It may be the case that no treatments 107 are available for a delinquent account 111 due to restrictions applied by the expert rules 108, in which case the recommender engine 101 may return a recommendation of no action to the client device 103. For example, the delinquent account 111 may already be enrolled in a forbearance program that has not yet completed.
If the recommender engine 101 locates one or more possible treatments 107 available for the delinquent account 111 at the present point in time, the recommender engine 101 may query its memory 105 to find a group of historical account 109 snapshots that may be similar to the delinquent account 111. The recommender engine 101 may retrieve scores from the one or more sub-models for the delinquent account 111. These scores may either be the most recent sub-models scores for the delinquent account or a scoring of the information present in the request for recommendation 113 or notification record 114 received from the client device 103 for the delinquent account 111. These numerical sub-model scores may be a dimension in the n-feature vector used in computing the distance between the delinquent accounts 111 and historical accounts 109, i.e., the distance between the delinquent account 111 vector and the historical accounts 109 vectors in memory 105. Similarity may be a function of closeness (distance) in the feature space, which includes predictive scores on the accounts, demographic information, balance, days past due, and other information which characterizes delinquent accounts. In some alternatives, the historical accounts 109 data in the memory 105 may be converted into n-feature vectors.
In some alternatives, the distance may be computed by one or more algorithms. In some alternatives, the algorithm may include a Mahalanobis distance calculation, Manhattan or Euclidean distance formulas or other known formulas known in the art to calculate distance between multiple vectors.
In some alternatives, the algorithm may utilize various similarity measures, such as the Pearson correlation coefficient, Spearman rank correlation, Kendall's τ correlation, mean squared differences, entropy, adjusted cosine similarity or other similarity measures known in the art.
The recommender engine 101 may not be limited to computing distance based on the raw information stored in memory 105, but rather may also utilize various transformations of the information in memory 105 as well. For example, the recommender engine 101 may disregard historical accounts 109 that entered collections longer than one or more years prior to the present scoring time. The recommender engine 101 may take the N (neighborhood size) closest historical accounts 109 to the delinquent account 111. In some alternatives, recommender engine 101 parameters, such as N may be set during implementation based on an analysis of historical data 109, but may also be adjusted by the users 102. In calculating the similarity between accounts, each feature may have a weight, which may determine how much that particular feature dimension influences the distance calculation. In some alternatives, transformations may be averages of a variable over time, or passing a value through a function such as a sigmoid, or other transform functions, such as taking the maximum value over a series of values. In computing the distance, a weight may multiply the absolute difference between a feature value to increase or decrease the contribution of that feature to the overall distance value.
In some alternatives, in lieu of storing all historical accounts 109 in memory 105, prototype accounts, i.e., a smaller list of historical accounts 109 may be selected from memory 105 and/or created by a technique such as learned vector quantization. Having a smaller number of prototype accounts in memory 105 may speed up the recommender engine 101 operations significantly.
In step 204, for each treatment 107 available to the delinquent account 109, the recommender engine 101 may query the memory for the (Nt) closest historical accounts 109 that may have received that particular treatment 107. For Nt, the recommender engine 101 may compute the average cost incurred on the delinquent accounts 109 through the time they exited collections, the recovery amount, time to recovery, recovery success percentage, and other performance measures for that particular treatment 107. These performance measures may be fed into a fitness function which summarizes the performance measures into a single fitness score. The fitness for any particular treatment 107 may be a combination of the overall average for group N and the average for set Nt, weighted by the number of accounts in set Nt. For example, if there is only one account in set Nt, the fitness may be close to the average for group N. For those actions which were not experienced by N, the system may assign that treatment the overall average performance measures and fitness for group N. The efficacy of taking no action may also be computed and competes with the other actions for selection as the recommended treatment, i.e., do nothing to this account at this time may be an action and in some cases may have better fitness than any other available action. In one alternative, the fitness function may be the sum of money paid back from current time through resolution point on a delinquent account or in a fixed look forward time window. In one alternative, the fitness function may be the sum of money paid back in a look forward time window on historical accounts 109 at a similar point in time in their history. Treatments 107 with an average fitness in historical accounts 109 that are higher than that of other treatments 107 may be recommended with higher frequency by the recommender engine 101. In some alternatives, the fitness score may also provide some indication of confidence. In some alternatives, intermediate success such as a promise to pay may be fed into the fitness function. In some alternatives, the feature weighting used in the distance calculation can vary based on delinquent account 111 properties (e.g. the features to consider for early stage delinquent accounts 111 may differ from those important for late stage delinquent accounts 111). In some alternatives, there may be one or more possible fitness functions. In some alternatives, the fitness function may vary based on whether the delinquent account 111 is early or late stage collections since the goal of the lender may be different for each stage. In some alternatives, the contribution of any particular historical account 109 to the performance measures and fitness function may be weighted by the recency of the historical account 109.
In some alternatives, for those treatments 107 that were not experienced by the group N, the recommender engine 101 may have models that predict the response to a particular treatment based on the group N response to other treatments 107. The recommender engine 101 may also expand its search beyond group N to gain information about responses to the treatment 107 being considered. In some alternatives, instead of looking for past treatments 107 in neighboring group N, the recommender engine 101 may instead analyze the closest accounts that may have received the treatment 107 being analyzed.
In some alternatives, records from delinquent accounts 111 not yet resolved may be added to the historical database 104 as they are fed into the recommender engine 101. They can be used in computing intermediate successes such as promises to pay, or can be ignored by the neighborhood function by querying whether the account in any historical record in memory 105 may have been resolved. In some alternatives, having all historical records enter memory 105 immediately simplifies the design of the recommender engine 101.
In step 205, the recommender engine 101 may select at least one treatment 107 for a delinquent account 109 and return this recommended treatment 107 via the client device 103 to the users 102. In some alternatives, the treatment 107 may be “take no action.” The selection may be performed by using the treatment 107 fitness values to influence the probability that a treatment 107 may be selected. Using this probabilistic approach may ensure that the recommender engine tests out new treatments 107. Actively exploring the space of possible treatments 107 may be a way for the recommender engine 101 to experiment with, learn from, or enrich future data helping make the recommender engine 101 adaptive. In some alternatives, the recommender engine 101 may select an ordered list of top treatments 107 for the delinquent account 111 (as opposed to returning just a single recommended best treatment 107) thereby allowing the users 102 to select from the top treatments 107.
In some alternatives, the treatment 107 may be defined by time duration, such as days, weeks, or months. In some alternatives, the treatment 107 may be defined by a numeric value, such as a settlement percentage. In some alternatives, the treatment 107 may be defined by a frequency, such as how often to apply a treatment 107 within a particular time frame. In some alternatives, the overall categories of treatment 107 recommendations may include a specific treatment 107 to use, variant of the treatment 107, sequence of treatments 107, phone number to use, time of day to call, prioritization of accounts to receive treatment 107, or identify the specific collector to work on a delinquent account.
Optionally in step 206, the recommender engine 101 may provide a rationale for its treatment 107 recommendation, by generating one or more reports 112. The reports 112 may summarize the result of the recommender engine's 101 analysis for a particular delinquent account 111. This report 112 may provide details for each available treatment 107, the performance measurements which may have been fed into the fitness calculation, the number of similar historical accounts 109 used in the analysis and other values. This information may help the users 102 of the recommender engine 101 gain insight into the rationale behind the recommender engine's 101 selection of a particular treatment action 107 thereby increasing their confidence in the recommendation.
Finally, in step 207, the recommender engine 101 may output a snapshot of its historical database as well as any recommendations made daily for archiving and use in improving the recommender engine 101 performance through offline analysis of the recommender engine 101. In some alternatives, as delinquent accounts 111 exit collections, their histories may be added to the recommender engine's 101 database 104 of historical accounts 109 so that the information may drive future recommendations by the recommender engine 101.
In another embodiment of the invention, the recommender engine 101 may provide visualization functionality that enables users 102 to move to a point in the historical data 109 space (reduced to 3 dimensions either by selecting the most critical dimensions, or through a dimensionality reduction analytic technique). The visualization functionality may produce summary information about the treatments 107 and their efficacy in that region of the historical account 109 feature space. This may help users 102 to fine tune their expert rules 108 and gain insight into the operations of the recommender engine 101. In some alternatives, the historical data 109 space may be reduced to 3 dimensions by sub-models using sample data or testing data. In some alternatives, the dimensionality reduction analytic technique may include the sub-models selecting features to use for the neighborhood space using generally known techniques.
Although the foregoing description is directed to the preferred embodiments of the invention, it is noted that other variations and modifications will be apparent to those skilled in the art, and may be made without departing from the spirit or scope of the invention. Moreover, features described in connection with one embodiment of the invention may be used in conjunction with other embodiments, even if not explicitly stated above.
