Recommender engine for collections treatment selection

A system for automatically recommending treatments for delinquent accounts in collections is provided. The system includes one or more sub-models for analyzing and scoring delinquent accounts and comparing them to historical accounts to identify similar historical accounts. The system can select and recommend one or more treatments for the delinquent account based on treatments for the historical accounts that may have previously provided a favorable outcome for a similar account. The system may test the efficacy of new treatments and incorporate the results into the memory, thereby learning and adapting to new treatments and account behavior.

FIELD OF THE INVENTION

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.

BACKGROUND OF THE INVENTION

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.

SUMMARY OF THE INVENTION

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.

DETAILED DESCRIPTION OF THE INVENTION

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:Look for users/items who share the same rating patterns with the active user/item (the user/item that the prediction may be for).Use the ratings from those like-minded users/similar items found in step 1 to calculate a prediction for the active user/item.
Another form of collaborative filtering may be based on implicit observations of normal user behavior (as opposed to the artificial behavior imposed by a rating task). In these systems you may observe what a user has done together with what all users may have done (what music they have listened to, what items they have bought) and may use that data to predict the user's behavior in the future or to predict how a user might like to behave if only they were given a chance. These predictions may then be filtered through business logic to determine how these predictions might affect what a business system ought to do. It may be, for instance, not useful to offer to sell somebody some music if they already have demonstrated that they own that music or, considering another example, it may not be useful to suggest more travel guides for Paris to someone who already bought a travel guide for this city.

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 engine101is 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 engine101may 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 memory105, and a system bus that couples various system components including the system memory105to 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 memory105may 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 database104for 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 engine101may be implemented on a variety of hardware platforms or implemented in a variety of software environments.

As used herein, a database104may 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 engine101may 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 engine101may operate in a model using an Extensible Markup Language (XML) interface. In some alternatives, the recommender engine101may comprise a secure Internet Web site or gateway, thereby ensuring the privacy of users and customer data. The recommendation engine101may minimize the amount of hardware and software the users must purchase and maintain. In some alternatives, the recommender engine101may be accessed from a users'102Web site. In some alternatives, the recommender engine101may also be accessed via a Virtual Private Network (VPN).

In some alternatives, the recommender engine101may consist of an Application Programming Interface (API). The API may consist of a number of function calls to the recommender engine101. 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 engine101may be deployed in an ASP model in which the client device sends data to the recommender engine101and receives a response in real time. In some alternatives, the recommender engine101may 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 engine101receiving the data. Client devices accessing the recommender engine101may 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 toFIG. 2, there is shown an exemplary process for recommending a treatment for a consumer item or product. In some embodiments of the invention, the consumer item or product may be a delinquent account. In step201, the recommender engine101may be initialized for processing a delinquent account111by populating the memory105with historical accounts109from the database104. In some alternatives, the historical accounts109, test accounts110, treatments107or rules108data (hereinafter “reference data”) may be input into the recommender engine101using communication techniques, such as a communication link via HTTPS, SOAP envelopes, or XML input and output documents or other mechanisms known in the art. For security reasons, the invention may use the Hypertext Transfer Protocol Secure (HTTPS) protocol, routed through selected system ports, as the communication protocol for remote API calls over the Internet. In some alternatives, electronic data exchange between the source systems for reference data and the recommender engine101may be facilitated by XML input and output payloads incorporating consumer and/or business data. In some alternatives, the recommender engine101may use the XML 1.0 specifications, which can be found on the Internet. In some alternatives, as part of the API calls, an XML schema may be provided that contains a data model for validating input and output reference data. In some alternatives, reference data may be input into the recommender engine101via a batch process. In some alternatives, the reference data for historical accounts transferred to the memory105may reside in a database104.

In some alternatives, the recommender system101may start up without any historical accounts109in memory and learn on its own. In some alternatives, the memory105of the recommender engine101may contain reference data from historical accounts109such 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 memory105may contain multiple entries for a particular historical account109. The multiple entries may represent snapshots of the historical accounts109at different points in time.

In some alternatives, the recommender engine101memory105may contain a list of treatments107available for all types of delinquent accounts. In some alternatives, similar treatments107with significantly varying intensity may be represented as separate treatments in the recommender engine101. For example, a strongly worded letter may be represented as a separate treatment107than a gentle reminder letter. In some alternatives, the single treatment107represented in the recommender engine101may contain several sub-treatments107in a particular order and timing. Other examples of treatments107may 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 treatment107by the users102of the recommender engine101or by the recommender engine101based on analysis of historical data109. A relationship cost may also be assigned to each treatment107by users102of the system or by the recommender engine101based on analysis of historical data109.

In some alternatives, the recommender engine101memory105may contain a set of rules108. The rules108may restrict which particular treatment107a delinquent account111may be eligible to receive at a particular point in time. For example, a rule108may suggest that a delinquent account111less than 10 days past due cannot be sent a strongly worded letter. In some alternatives, the rules108may embody the policy of a particular original creditor as well as any applicable governmental or financial industry regulations. In some alternatives, the rules108may also represent interactions between treatments107. For example, the rules108may suggest that a settlement offer may not be presented to a delinquent account111, which had been in a forbearance program anytime in its history. In another example, an individual rule108might 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 rule108might 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, rules108may typically have tunable parameters, for example, “3 letters,” “60 days,” “$150” “2 rules fired,” etc. In some alternatives, the rules108may be authored by users102of the recommender engine101. In some alternatives of the invention, the recommender engine101may be provided with a default set of rules108and these rules108may be modified by the users102.

In some alternatives of the invention, the recommender engine101may output one or more types of reports112. In some alternatives, the reports112may contain information or rationale by the recommending engine101for recommending a particular treatment107. In some alternatives, human analysts may update the expert rules108in the recommender engine101as policies and regulations change. In some alternatives, a request for recommendation113from the users102may not update the recommender engine101memory105. In some alternatives, users102may update the client device with a notification record114about a delinquent account111. Notification records114received from the client device103of events that may have occurred with a delinquent account111may update the recommender engine101memory105.

In step202, a user102via the client device103may send a request for recommendation113or notification record114or scoring request data to the recommendation engine101. In some alternatives, the scoring request data record may be a request for recommendation113or notification record114generated by the client device103containing fields as defined by an XML template or proprietarily API format as illustrated inFIG. 3. In some alternatives, the request for recommendation113or notification record114may contain scoring request data that may be scored by the sub-models in the recommender engine101. In some alternatives, a request for recommendation113or notification record114from the client device103may not have the information needed to be scored by the sub-models, in that case, the recommender engine101may use an earlier sub-model score calculated for the delinquent account111. For each delinquent account111, at a particular point in time, the scoring request data record may be input into the recommender engine101, as an XML document or in some other proprietary API format as illustrated inFIG. 3. The client device103may send the request for recommendation113or notification record114for a delinquent account111data or scoring request data to the recommender engine101in ASP mode via a web server. Specifically, the client device103may send the request for recommendation113or notification record114for the delinquent account111data or scoring request data as an XML document to the recommender engine101in a format defined by a proprietary API or other mechanisms known in the art for transmitting data.

In step203, the recommender engine101may utilize one or more sub-models, generated using known techniques. In some alternatives, the sub-models may be predictive models. The recommender engine101may 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 account111, and the best time to contact a debtor. The sub-models may be generated by using data from the recommender engine101memory105, which may store historical accounts109, all of their treatments107and rules108for use as neighbors to properly train the desired sub-model. Sampling of the data from the recommender engine101memory105may 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 accounts109data. 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 recommendation113or notification record114for a delinquent account111. In some alternatives, the recommender engine101may query the sub-models for a score and the memory105for similar historical accounts109to the request for recommendation113or notification record114for a delinquent account111received by the recommender engine101.

The recommender engine101may then query the rules to first determine the list of all treatments107that may be available from memory105for the delinquent account111. It may be the case that no treatments107are available for a delinquent account111due to restrictions applied by the expert rules108, in which case the recommender engine101may return a recommendation of no action to the client device103. For example, the delinquent account111may already be enrolled in a forbearance program that has not yet completed.

If the recommender engine101locates one or more possible treatments107available for the delinquent account111at the present point in time, the recommender engine101may query its memory105to find a group of historical account109snapshots that may be similar to the delinquent account111. The recommender engine101may retrieve scores from the one or more sub-models for the delinquent account111. 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 recommendation113or notification record114received from the client device103for the delinquent account111. These numerical sub-model scores may be a dimension in the n-feature vector used in computing the distance between the delinquent accounts111and historical accounts109, i.e., the distance between the delinquent account111vector and the historical accounts109vectors in memory105. 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 accounts109data in the memory105may 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 engine101may not be limited to computing distance based on the raw information stored in memory105, but rather may also utilize various transformations of the information in memory105as well. For example, the recommender engine101may disregard historical accounts109that entered collections longer than one or more years prior to the present scoring time. The recommender engine101may take the N (neighborhood size) closest historical accounts109to the delinquent account111. In some alternatives, recommender engine101parameters, such as N may be set during implementation based on an analysis of historical data109, but may also be adjusted by the users102. 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 accounts109in memory105, prototype accounts, i.e., a smaller list of historical accounts109may be selected from memory105and/or created by a technique such as learned vector quantization. Having a smaller number of prototype accounts in memory105may speed up the recommender engine101operations significantly.

In step204, for each treatment107available to the delinquent account109, the recommender engine101may query the memory for the (Nt) closest historical accounts109that may have received that particular treatment107. For Nt, the recommender engine101may compute the average cost incurred on the delinquent accounts109through the time they exited collections, the recovery amount, time to recovery, recovery success percentage, and other performance measures for that particular treatment107. 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 treatment107may 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 accounts109at a similar point in time in their history. Treatments107with an average fitness in historical accounts109that are higher than that of other treatments107may be recommended with higher frequency by the recommender engine101. 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 account111properties (e.g. the features to consider for early stage delinquent accounts111may differ from those important for late stage delinquent accounts111). 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 account111is 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 account109to the performance measures and fitness function may be weighted by the recency of the historical account109.

In some alternatives, for those treatments107that were not experienced by the group N, the recommender engine101may have models that predict the response to a particular treatment based on the group N response to other treatments107. The recommender engine101may also expand its search beyond group N to gain information about responses to the treatment107being considered. In some alternatives, instead of looking for past treatments107in neighboring group N, the recommender engine101may instead analyze the closest accounts that may have received the treatment107being analyzed.

In some alternatives, records from delinquent accounts111not yet resolved may be added to the historical database104as they are fed into the recommender engine101. 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 memory105may have been resolved. In some alternatives, having all historical records enter memory105immediately simplifies the design of the recommender engine101.

In step205, the recommender engine101may select at least one treatment107for a delinquent account109and return this recommended treatment107via the client device103to the users102. In some alternatives, the treatment107may be “take no action.” The selection may be performed by using the treatment107fitness values to influence the probability that a treatment107may be selected. Using this probabilistic approach may ensure that the recommender engine tests out new treatments107. Actively exploring the space of possible treatments107may be a way for the recommender engine101to experiment with, learn from, or enrich future data helping make the recommender engine101adaptive. In some alternatives, the recommender engine101may select an ordered list of top treatments107for the delinquent account111(as opposed to returning just a single recommended best treatment107) thereby allowing the users102to select from the top treatments107.

In some alternatives, the treatment107may be defined by time duration, such as days, weeks, or months. In some alternatives, the treatment107may be defined by a numeric value, such as a settlement percentage. In some alternatives, the treatment107may be defined by a frequency, such as how often to apply a treatment107within a particular time frame. In some alternatives, the overall categories of treatment107recommendations may include a specific treatment107to use, variant of the treatment107, sequence of treatments107, phone number to use, time of day to call, prioritization of accounts to receive treatment107, or identify the specific collector to work on a delinquent account.

Optionally in step206, the recommender engine101may provide a rationale for its treatment107recommendation, by generating one or more reports112. The reports112may summarize the result of the recommender engine's101analysis for a particular delinquent account111. This report112may provide details for each available treatment107, the performance measurements which may have been fed into the fitness calculation, the number of similar historical accounts109used in the analysis and other values. This information may help the users102of the recommender engine101gain insight into the rationale behind the recommender engine's101selection of a particular treatment action107thereby increasing their confidence in the recommendation.

Finally, in step207, the recommender engine101may output a snapshot of its historical database as well as any recommendations made daily for archiving and use in improving the recommender engine101performance through offline analysis of the recommender engine101. In some alternatives, as delinquent accounts111exit collections, their histories may be added to the recommender engine's101database104of historical accounts109so that the information may drive future recommendations by the recommender engine101.

In another embodiment of the invention, the recommender engine101may provide visualization functionality that enables users102to move to a point in the historical data109space (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 treatments107and their efficacy in that region of the historical account109feature space. This may help users102to fine tune their expert rules108and gain insight into the operations of the recommender engine101. In some alternatives, the historical data109space 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.