US7966256B2 - Methods and systems of predicting mortgage payment risk - Google Patents

Methods and systems of predicting mortgage payment risk Download PDF

Info

Publication number
US7966256B2
US7966256B2 US12/246,407 US24640708A US7966256B2 US 7966256 B2 US7966256 B2 US 7966256B2 US 24640708 A US24640708 A US 24640708A US 7966256 B2 US7966256 B2 US 7966256B2
Authority
US
United States
Prior art keywords
data
risk
mortgage
model
models
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US12/246,407
Other versions
US20090099959A1 (en
Inventor
Yuansong Liao
Rui Yan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CoreLogic Solutions LLC
Original Assignee
CoreLogic Information Solutions Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/526,208 external-priority patent/US7587348B2/en
Application filed by CoreLogic Information Solutions Inc filed Critical CoreLogic Information Solutions Inc
Priority to US12/246,407 priority Critical patent/US7966256B2/en
Assigned to BASEPOINT ANALYTICS LLC reassignment BASEPOINT ANALYTICS LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: YAN, Rui, LIAO, YUANSONG
Publication of US20090099959A1 publication Critical patent/US20090099959A1/en
Assigned to JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT reassignment JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: FIRST AMERICAN CORELOGIC, INC.
Assigned to CORELOGIC INFORMATION SOLUTIONS, INC. reassignment CORELOGIC INFORMATION SOLUTIONS, INC. CHANGE OF NAME Assignors: FIRST AMERICAN CORELOGIC, INC.
Assigned to FIRST AMERICAN CORELOGIC, INC. reassignment FIRST AMERICAN CORELOGIC, INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: BASEPOINT ANALYTICS LLC
Priority to US13/162,517 priority patent/US8065234B2/en
Application granted granted Critical
Publication of US7966256B2 publication Critical patent/US7966256B2/en
Assigned to BANK OF AMERICA, N.A., AS COLLATERAL AGENT reassignment BANK OF AMERICA, N.A., AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: CORELOGIC INFORMATION SOLUTIONS, INC.
Assigned to CORELOGIC SOLUTIONS, LLC reassignment CORELOGIC SOLUTIONS, LLC MERGER (SEE DOCUMENT FOR DETAILS). Assignors: CORELOGIC INFORMATION SOLUTIONS, INC.
Assigned to BANK OF AMERICA, N.A. reassignment BANK OF AMERICA, N.A. SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CORELOGIC SOLUTIONS, LLC
Assigned to CORELOGIC SOLUTIONS, LLC (F/K/A/ FIRST AMERICAN CORELOGIC, INC.) reassignment CORELOGIC SOLUTIONS, LLC (F/K/A/ FIRST AMERICAN CORELOGIC, INC.) NOTICE OF RELEASE OF PATENT SECURITY INTEREST Assignors: JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT
Assigned to CORELOGIC TAX SERVICES, LLC, CORELOGIC DORADO, LLC (F/K/A CORELOGIC DORADO CORPORATION AND F/K/A DORADO NETWORK SYSTEMS CORPORATION), CORELOGIC INFORMATION RESOURCES, LLC (F/K/A CORELOGIC US, INC. AND F/K/A FIRST ADVANTAGE CORPORATION), CORELOGIC REAL ESTATE INFORMATION SERVICES, LLC (F/K/A FIRST AMERICAN REAL ESTATE INFORMATION SERVICES, INC.), CORELOGIC SOLUTIONS, LLC (F/K/A MARKETLINX, INC. AND F/K/A CORELOGIC REAL ESTATE SOLUTIONS, LLC (F/K/A FIRST AMERICAN REAL ESTATE SOLUTIONS LLC AND F/K/A CORELOGIC INFORMATION SOLUTIONS, INC. (F/K/A FIRST AMERICAN CORELOGIC, INC.)), CORELOGIC VALUATION SERVICES, LLC (F/K/A EAPPRAISEIT LLC), CORELOGIC, INC. (F/K/A FIRST AMERICAN CORPORATION) reassignment CORELOGIC TAX SERVICES, LLC RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011 Assignors: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT
Assigned to CORELOGIC TAX SERVICES, LLC, CORELOGIC DORADO, LLC (F/K/A CORELOGIC DORADO CORPORATION AND F/K/A DORADO NETWORK SYSTEMS CORPORATION), CORELOGIC INFORMATION RESOURCES, LLC (F/K/A CORELOGIC US, INC. AND F/K/A FIRST ADVANTAGE CORPORATION), CORELOGIC REAL ESTATE INFORMATION SERVICES, LLC (F/K/A FIRST AMERICAN REAL ESTATE INFORMATION SERVICES, INC.), CORELOGIC SOLUTIONS, LLC (F/K/A MARKETLINX, INC. AND F/K/A CORELOGIC REAL ESTATE SOLUTIONS, LLC (F/K/A FIRST AMERICAN REAL ESTATE SOLUTIONS LLC AND F/K/A CORELOGIC INFORMATION SOLUTIONS, INC. (F/K/A FIRST AMERICAN CORELOGIC, INC.)), CORELOGIC VALUATION SERVICES, LLC (F/K/A EAPPRAISEIT LLC), CORELOGIC, INC. (F/K/A FIRST AMERICAN CORPORATION) reassignment CORELOGIC TAX SERVICES, LLC CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE FROM 04/04/2014 TO 04/09/2014 PREVIOUSLY RECORDED ON REEL 033034 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011. Assignors: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT
Assigned to CORELOGIC SOLUTIONS, LLC reassignment CORELOGIC SOLUTIONS, LLC RELEASE OF SECURITY INTEREST RECORDED AT 032798/0047 Assignors: BANK OF AMERICA, N.A.
Assigned to U.S. BANK NATIONAL ASSOCIATION reassignment U.S. BANK NATIONAL ASSOCIATION SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CDS BUSINESS MAPPING, LLC, Clareity Security, LLC, CoreLogic Credco, LLC, CORELOGIC DORADO, LLC, CORELOGIC SOLUTIONS, LLC, CORELOGIC TAX SERVICES, LLC, CORELOGIC, INC., FNC, INC., LOCATION INC. GROUP CORPORATION
Assigned to ARES CAPITAL CORPORATION reassignment ARES CAPITAL CORPORATION SECOND LIEN PATENT SECURITY AGREEMENT Assignors: CDS BUSINESS MAPPING, LLC, Clareity Security, LLC, CoreLogic Credco, LLC, CORELOGIC DORADO, LLC, CORELOGIC SOLUTIONS, LLC, CORELOGIC TAX SERVICES, LLC, CORELOGIC, INC., FNC, INC., LOCATION INC. GROUP CORPORATION
Assigned to JPMORGAN CHASE BANK, N.A. reassignment JPMORGAN CHASE BANK, N.A. FIRST LIEN PATENT SECURITY AGREEMENT Assignors: CDS BUSINESS MAPPING, LLC, Clareity Security, LLC, CoreLogic Credco, LLC, CORELOGIC DORADO, LLC, CORELOGIC SOLUTIONS, LLC, CORELOGIC TAX SERVICES, LLC, CORELOGIC, INC., FNC, INC., LOCATION INC. GROUP CORPORATION
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03Credit; Loans; Processing thereof

Definitions

  • the embodiments described herein relate to determining or predicting the likelihood of payment defaults in financial transactions.
  • Fraud detection systems detect fraud in financial transactions.
  • a mortgage fraud detection system can be configured to analyze loan application data to identify applications that are being obtained using fraudulent application data.
  • EPD early payment default
  • a system for the detection of a risk of payment default based on historical mortgage data is described herein.
  • a method for detecting a risk of payment default comprises receiving mortgage data associated with a mortgage application, the mortgage data associated with an applicant, determining a first score for the mortgage data based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant, and generating data indicative of a risk of payment default based at least partly on the first score.
  • a method for detecting a risk of payment default comprises receiving mortgage data associated with a plurality of mortgage applications, each mortgage application associated with an applicant; determining a plurality of first scores for the mortgage data for each of the plurality of mortgage applications based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant; generating data indicative of a risk of payment default for each of the plurality of mortgage applications; prioritizing the mortgage applications based on the plurality of data generated; determining a plurality of second scores for the mortgage data for each of the plurality of mortgage applications based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions; and generating data indicative of a risk of fraud for each of the prioritized mortgage applications based at least partly on the second score.
  • a system for detecting a risk of payment default comprises a storage configured to receive mortgage data associated with a mortgage application, the mortgage applications associated with an applicant; and a processor coupled with the storage, the processor configured to determine a first score for the mortgage data based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant, and generate data indicative of a risk of payment default based at least partly on the first score.
  • a system for detecting a risk of payment default comprises a storage configured to receive mortgage data associated with a plurality of mortgage applications, each of the plurality of mortgage applications associated with an applicant; and a processor coupled with the storage, the processor configured to determine a plurality of first scores for the mortgage data for each of the plurality of mortgage applications based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant, generate data indicative of a risk of payment default for each of the plurality of mortgage applications based at least partly on the first score, prioritize the mortgage applications based on the plurality of data generated, determine a plurality of second scores for the mortgage data for each of the plurality of mortgage applications based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions, and generate data indicative of a risk of fraud for each of the prioritized mortgage applications based at least partly on the second score.
  • FIG. 1 is a functional block diagram illustrating a fraud detection system such as for use with a mortgage origination system in accordance with one embodiment
  • FIG. 2 is a functional block diagram illustrating an example of the fraud detection system of FIG. 1 in more detail in accordance with one embodiment
  • FIG. 3 is a functional block diagram illustrating an example of loan models that can be included in the fraud detection system of FIG. 2 ;
  • FIG. 4 is a functional block diagram illustrating examples of entity models that can be included in the fraud detection system of FIG. 2 ;
  • FIG. 5 is a flowchart illustrating model generation and use in the fraud detection system of FIG. 2 ;
  • FIG. 6 is a flowchart illustrating an example of using models in the fraud detection system of FIG. 2 ;
  • FIG. 7 is a flowchart illustrating an example of generating a supervisory model in the fraud detection system of FIG. 2 ;
  • FIG. 8 is a flowchart illustrating an example of generating entity models in the fraud detection system of FIG. 2 ;
  • FIG. 9 is a functional block diagram illustrating a payment default detection system such as for use with a mortgage origination system.
  • FIG. 10 is a functional block diagram illustrating an example of an payment default detection system in more detail.
  • Existing fraud detection systems can use transaction data in addition to data related to the transacting entities to identify fraud. Such systems can operate in either batch (processing transactions as a group of files at periodic times during the day) or real time mode (processing transactions one at a time, as they enter the system). However, the fraud detection capabilities of existing systems have not kept pace with either the types of fraudulent activity that have evolved or increasing processing and storage capabilities of computing systems.
  • fraud detection can be improved by using stored past transaction data in place of, or in addition to, summarized forms of past transaction data.
  • fraud detection can be improved by using statistical information that is stored according to groups of individuals that form clusters.
  • fraud can be identified with reference to deviation from identified clusters.
  • embodiments of mortgage fraud detection systems can use data that is stored in association with one or more entities associated with the processing of the mortgage transaction such as brokers, appraisers, or other parties to mortgage transactions.
  • the entities can be real persons or can refer to business associations, e.g., a particular appraiser, or an appraisal firm.
  • Fraud generally refers to any material misrepresentation associated with a loan application and can include any misrepresentation which leads to a higher probability for the resulting loan to default or become un-sellable or require discount in the secondary market.
  • mortgages can include residential, commercial, or industrial mortgages.
  • mortgages can include first, second, home equity, or any other loan associated with a real property.
  • other embodiments can also include fraud detection in other types of loans or financial transactions.
  • Exemplary applications of fraud detection relate to credit cards, debit cards, and mortgages. Furthermore, various patterns can be detected from external sources, such as data available from a credit bureau or other data aggregator.
  • FIG. 1 is a functional block diagram illustrating a fraud detection system 100 such as for use with a mortgage origination system 106 .
  • the system 100 can be used to analyze applications for use in evaluating applications and/or funded loans by an investment bank or as part of due diligence of a loan portfolio.
  • the fraud detection system 100 can receive and store data in a storage 104 .
  • the storage 104 can comprise one or more database servers and any suitable configuration of volatile and persistent memory.
  • the fraud detection system 100 can be configured to receive mortgage application data from the mortgage origination system 106 and provide data indicative of fraud back to the mortgage origination system 106 .
  • the fraud detection system 100 uses one or more models to generate the data indicative of fraud.
  • data indicative of fraud can also be provided to a risk manager system 108 for further processing and for analysis by a human operator.
  • the analysis system 108 can be provided in conjunction with the fraud detection system 100 or in conjunction with the mortgage origination system 106 .
  • a model generator 110 can provide models to the fraud detection system 100 .
  • the model generator 110 can provide the models periodically to the system 100 , such as when new versions of the system 100 are released to a production environment.
  • at least a portion of the model generator 110 can be included in the system 100 and configured to automatically update at least a portion of the models in the system 100 .
  • FIG. 2 is a functional block diagram further illustrating an example of the fraud detection system 100 .
  • the system 100 can include an origination system interface 122 providing mortgage application data to a data preprocessing module 124 .
  • the origination system interface 122 can receive data from the mortgage origination system 106 of FIG. 1 .
  • the origination system interface 122 can be configured to receive data associated with funded mortgages and can be configured to interface with suitable systems other than, or in addition to, mortgage origination systems.
  • the system interface 122 can be configured to receive “bid tapes” or other collections of data associated with funded mortgages for use in evaluating fraud associated with a portfolio of funded loans.
  • the origination system interface 122 comprises a computer network that communicates with the origination system 106 to receive applications in real time or in batches. In one embodiment, the origination system interface 122 receives batches of applications via a data storage medium.
  • the origination system interface 122 provides application data to the data preprocessing module 124 which formats application data into data formats used internally in the system 100 .
  • the origination system interface 122 can also provide data from additional sources such as credit bureaus that can be in different formats for conversion by the data preprocessing module 124 into the internal data formats of the system 100 .
  • the origination system interface 122 and preprocessing module 124 can also allow at least portions of a particular embodiment of the system 100 to be used to detect fraud in different types of credit applications and for different loan originators that have varying data and data formats.
  • Table 1 lists examples of mortgage application data that can be used in various embodiments.
  • the preprocessing module 124 can be configured to identify missing data values and provide data for those missing values to improve further processing. For example, the preprocessing module 124 can generate application data to fill missing data fields using one or more rules. Different rules can be used depending on the loan data supplier, on the particular data field, and/or on the distribution of data for a particular field. For example, for categorical fields, the most frequent value found in historical applications can be used. For numerical fields, the mean or median value of historical applications can be used. In addition, other values can be selected such as a value that is associated with the highest risk of fraud (e.g., assume the worst) or a value that is associated with the lowest risk of fraud (e.g., assume the best).
  • rules can be used depending on the loan data supplier, on the particular data field, and/or on the distribution of data for a particular field. For example, for categorical fields, the most frequent value found in historical applications can be used. For numerical fields, the mean or median value of historical applications can be used. In addition, other values can be selected
  • a sentinel value e.g., a specific value that is indicative of a missing value to one or more fraud models can be used (allowing the fact that particular data is missing to be associated with fraud).
  • the preprocessing module 124 can also be configured to identify erroneous data or missing data. In one embodiment, the preprocessing module 124 extrapolates missing data based on data from similar applications, similar applicants, or using default data values.
  • the preprocessing module 124 can perform data quality analysis such as one or more of critical error detection, anomaly detection, and data entry error detection. In one embodiment, applications failing one or more of these quality analyses can be logged to a data error log database 126 .
  • the preprocessing module 124 identifies applications that are missing data that the absence of which is likely to confound further processing.
  • missing data can include, for example, appraisal value, borrower credit score, or loan amount.
  • no further processing is performed and a log or error entry is stored to the database 126 and for provided to the loan origination system 106 .
  • the preprocessing module 124 identifies continuous application data values that can be indicative of data entry error or of material misrepresentations. For example, high loan or appraisal amounts (e.g., above a threshold value) can be indicative of data entry error or fraud.
  • Other anomalous data can include income or age data that is outside selected ranges.
  • such anomalous data can be logged and the log provided to the origination system 106 .
  • the fraud detection system 100 continues to process applications with anomalous data. The presence of anomalous data can be logged to the database 126 and/or included in a score output or report for the corresponding application.
  • the preprocessing module 124 can be configured to identify non-continuous data such as categories or coded data that appear to have data entry errors. For example, telephone numbers or zip codes that have too many or too few digits, incomplete social security numbers, toll free numbers as home or work numbers, or other category data that fails to conform to input specifications can be logged. The presence of anomalous data can be logged to the database 126 and/or included in a score output or report for the corresponding application.
  • the preprocessing module 124 can be configured to query an input history database 128 to determine if the application data is indicative of a duplicate application.
  • a duplicate can indicate either resubmission of the same application fraudulently or erroneously. Duplicates can be logged. In one embodiment, no further processing of duplicates is performed. In other embodiments, processing of duplicates continues and can be noted in the final report or score. If no duplicate is found, the application data is stored to the input history database 124 to identify future duplicates.
  • the data preprocessing module 124 provides application data to one or more models for fraud scoring and processing.
  • application data is provided to one or more loan models 132 that generate data indicative of fraud based on application and applicant data.
  • the data indicative of fraud generated by the loan models 132 can be provided to an integrator 136 that combines scores from one or more models into a final score.
  • the data preprocessing module 124 can also provide application data to one or more entity models 140 that are configured to identify fraud based on data associated with entities involved in the processing of the application.
  • Entity models can include models of data associated with loan brokers, loan officers or other entities involved in a loan application.
  • Each of the entity models can output data to an entity scoring module 150 that is configured to provide a score and/or one or more risk indicators associated with the application data.
  • the entity scoring module 150 can provide scores associated with one or more risk indicators associated with the particular entity or application.
  • risk indicator refers to data values identified with respect to one or more data fields that can be indicative of fraud.
  • appraisal value in combination with zip code can be a risk indicator associated with an appraiser model.
  • the entity scoring module 150 provides scores and indicators to the integrator 136 to generate a combined fraud score and/or set of risk indicators.
  • the selection of risk indicators are based on criteria such as domain knowledge, and/or correlation coefficients between entity scores and fraud rate, if entity fraud rate is available.
  • Correlation coefficient between entity score s i for risk indicator j and entity fraud rate f is defined as
  • the entity scoring model 150 combines each of the risk indicator scores for a particular entity using a weighted average or other suitable combining calculation to generate an overall entity score.
  • the risk indicators having higher scores can also be identified and provided to the integrator 136 .
  • the combined score for a particular entity can be determined using one or more of the following models:
  • entity fraud rate or entity performance data (EPD: not to be confused with EPD as defined below) rate is available, the fraud/EPD rate can be incorporated with entity committee score to generate the combined entity score.
  • entity score S E can be calculated using one of the following equations:
  • the preprocessing module 124 can also provide application data to a risky file processing module 156 .
  • the risky file processing module 156 is configured to receive files from a risky files database 154 .
  • “Risky” files include portions of applications that are known to be fraudulent. It has been found that fraudulent applications are often resubmitted with only insubstantial changes in application data.
  • the risky file processing module 156 compares each application to the risky files database 154 and flags applications that appear to be resubmissions of fraudulent applications.
  • risky file data is provided to the integrator 136 for integration into a combined fraud score or report.
  • the integrator 136 can be configured to apply weights and for processing rules to generate one or more scores and risk indicators based on the data indicative of fraud provided by one or more of the loan models 132 , the entity models 140 and entity scoring modules 160 , and the risky file processing module 156 .
  • the risk indicator 136 generates a single score indicative of fraud along with one or more risk indicators relevant for the particular application. Additional scores can also be provided with reference to each of the risk indicators.
  • the integrator 136 can provide this data to a scores and risk indicators module 160 that logs the scores to an output history database 160 .
  • the scores and risk indicators module 160 identifies applications for further review by the risk manager 108 of FIG. 1 . Scores can be real or integer values.
  • scores are numbers in the range of 1-999.
  • thresholds are applied to one or more categories to segment scores into high and low risk categories.
  • thresholds are applied to identify applications for review by the risk manager 108 .
  • risk indicators are represented as codes that are indicative of certain data fields or certain values for data fields. Risk indicators can provide information on the types of fraud and recommended actions. For example, risk indicators might include a credit score inconsistent with income, high risk geographic area, etc. Risk indicators can also be indicative of entity historical transactions, e.g., a broker trend that is indicative of fraud.
  • a score review report module 162 can generate a report ir, or, e or more formats based on scores and risk indicators provided by the scores and risk indicators module 160 .
  • the score review report module 162 identifies loan applications for review by the risk manager 108 of FIG. 1 .
  • One embodiment desirably improves the efficiency of the risk manager 108 by identifying applications with the highest fraud scores or with particular risk indicators for review thereby reducing the number of applications that need to be reviewed.
  • a billing process 166 can be configured to generate billing information based on the results in the output history.
  • the model generator 110 receives application data, entity data, and data on fraudulent and non-fraudulent applications and generates and updates models such as the entity models 140 either periodically or as new data is received.
  • FIG. 3 is a functional block diagram illustrating an example of the loan models 132 in the fraud detection system 100 .
  • the loan models 132 can include one or more supervised models 170 and high risk rules models 172 .
  • Supervised models 170 are models that are generated based on training or data analysis that is based on historical transactions or applications that have been identified as fraudulent or non-fraudulent. Examples of implementations of supervised models 170 include scorecards, naive Bayesian, decision trees, logistic regression, and neural networks. Particular embodiments can include one or more such supervised models 170 .
  • the high risk rules models 172 can include expert systems, decision trees, and for classification and regression tree (CART) models.
  • the high risk rules models 172 can include rules or trees that identify particular data patterns that are indicative of fraud.
  • the high risk rules model 172 is used to generate scores and/or risk indicators.
  • the rules, including selected data fields and condition parameters, are developed using the historical data used to develop the loan model 170 .
  • a set of high risk rule models 172 can be selected to include rules that have low firing rate and high hit rate.
  • a rule i when a rule i is fired, it outputs a score: s rule i .
  • the score represents the fraud risk associated to the rule.
  • the loan models 170 and 172 are updated when new versions of the system 100 are released into operation.
  • the supervised models 170 and the high risk rules models. 172 are updated automatically.
  • the supervised models 170 and the high risk rules models 172 can also be updated such as when new or modified data features or other model parameters are received.
  • FIG. 4 is a functional block diagram illustrating examples of the entity models 140 in the fraud detection system 100 . It has been found that fraud detection performance can be increased by including models that operate on entities associated with a mortgage transaction that are in addition to the mortgage applicant. Scores for a number of different types of entities are calculated based on historical transaction data.
  • the entity models can include one or more of an account executive model 142 , a broker model 144 , a loan officer model 146 , and an appraiser (or appraisal) model 148 .
  • Embodiments can also include other entities associated with a transaction such as the lender.
  • an unsupervised model e.g., a clustering model such as k-means, is applied to risk indicators for historical transactions for each entity.
  • a score for each risk indicator, for each entity is calculated based on the relation of the particular entity to the clusters across the data set for the particular risk indicator.
  • a risk indicator that is a single value, e.g., loan value for a broker
  • the difference between the loan value of each loan of the broker and the mean (assuming a simple Gaussian distribution of loan values) divided by the standard deviation of the loan values over the entire set of historical loans for all brokers might be used as a risk indicator for that risk indicator score.
  • Embodiments that include more sophisticated clustering algorithms such as k-means can be used along with multidimensional risk indicators to provide for more powerful entity scores.
  • the corresponding entity scoring module 150 for each entity can create a weighted average of the scores of a particular entity over a range of risk indicators that are relevant to a particular transaction.
  • FIG. 5 is a flowchart illustrating a method 300 of operation of the fraud detection system 100 .
  • the method 300 begins at a block 302 in which the supervised model is generated.
  • the supervised models 170 are generated based on training or data analysis that is based on historical transactions or applications that have been identified as fraudulent or non-fraudulent. Further details of generating supervised models are discussed with reference to FIG. 7 .
  • the system 100 generates one or more unsupervised entity models such as the account executive model 142 , the broker model 144 , the loan officer model 146 , or the appraiser (or appraisal) model 148 . Further details of generating unsupervised models are discussed with reference to FIG. 8 .
  • the system 100 applies application data to models such as supervised models 132 and entity models 150 .
  • the functions of block 306 can be repeated for each loan application that is to be processed. Further detail of applying data to the models is described with reference to FIG. 6 .
  • the model generator 110 generates and/or updates models as new data is received or at specified intervals such as nightly or weekly. In other embodiments, some models are updated continuously and others at specified intervals depending on factors such as system capacity, mortgage originator requirements or preferences, etc. In one embodiment, the entity models are updated periodically, e.g., nightly or weekly while the loan models are only updated when new versions of the system 100 are released into operation.
  • FIG. 6 is a flowchart illustrating an example of a method of performing the functions of the block 306 of FIG. 5 of using models in the fraud detection system 100 to process a loan application.
  • the function 306 begins at a block 322 in which the origination system interface 122 receives loan application data.
  • the data preprocessing module 124 preprocesses the application 324 as discussed above with reference to FIG. 2 .
  • the application data is applied to the supervised loan models 170 which provide a score indicative of the relative likelihood or probability of fraud to the integrator 136 .
  • the supervised loan models 170 can also provide risk indicators.
  • the high risk rules model 172 is applied to the application to generate one or more risk indicators, and/or additional scores indicative of fraud.
  • the application data is applied to one or more of the entity models 140 to generate additional scores and risk indicators associated with the corresponding entities of the models 140 associated with the transaction.
  • the integrator 136 calculates a weighted score and risk indicators based on scores and risk indicators from the supervised loan model 170 , the high risk rules model 172 , and scores of entity models 140 .
  • the integrator 136 includes an additional model, e.g., a trained supervised model that combines the various scores, weights, and risk factors provided by the models 170 , 172 , and 140 .
  • the scores and risk indicators module 160 and the score review report module 162 generate a report providing a weighted score along with one or more selected risk indicators.
  • the selected risk indicators can include explanations of potential types of frauds and recommendations for action.
  • FIG. 7 is a flowchart illustrating an example of a method of performing the block 302 of FIG. 5 of generating the loan models 132 in the fraud detection system 100 .
  • Supervised learning algorithms identify a relationship between input features and target variables based on training data.
  • the target variables comprise the probability of fraud.
  • the models used can depend on the size of the data and how complex a problem is. For example, if the fraudulent exemplars in historical data are less than about 5000 in number, smaller and simpler models can be used, so robust model parameter estimation can be supported by the data size.
  • the method 302 begins at a block 340 in which the model generator 110 receives historical mortgage data.
  • the model generator 110 can extract and convert client historical data according to internal development data specifications, perform data analysis to determine data quality and availability, and rectify anomalies, such as missing data, invalid data, or possible data entry errors similar to that described above with reference to preprocessing module 124 of FIG. 2 .
  • model generator 110 can perform feature extraction including identifying predictive input variables for fraud detection models.
  • the model generator 110 can use domain knowledge and mathematical equations applied to single or combined raw input data fields to identify predictive features.
  • Raw data fields can be combined and transformed into discriminative features.
  • Feature extraction can be performed based on the types of models for which the features are to be used. For example, linear models such as, logistic regression and linear regression, work best when the relationships between input features and the target are linear. If the relationship is non-linear, proper transformation functions can be applied to convert such data to a linear function.
  • the model generator 110 selects features from a library of features for use in particular models. The selection of features can be determined by availability of data fields, and the usefulness of a feature for the particular data set and problem. Embodiments can use techniques such as filter and wrapper approaches, including information theory, stepwise regression, sensitivity analysis, data mining, or other data driven techniques for feature selection.
  • the model generator 110 can segment the data into subsets to better model input data. For example, if subsets of a data set are identified with significantly distinct behavior, special models designed especially for these subsets normally outperform a general fit-all model.
  • a prior knowledge of data can be used to segment the data for generation of models.
  • data is segregated geographically so that, for example, regional differences in home prices and lending practices do not confound fraud detection.
  • data driven techniques e.g., unsupervised techniques such as clustering, are used to identify data segments that can benefit from a separate supervised model.
  • the model generator 110 identifies a portion of the applications in the received application data (or segment of that data) that were fraudulent. In one embodiment, the origination system interface 122 provides this labeling. Moving to a block 344 , the model generator 110 identifies a portion of the applications that were non-fraudulent. Next at a block 346 , the model generator 110 generates a model such as the supervised model 170 using a supervised learning algorithm to generate a model that distinguishes the fraudulent from the non-fraudulent transactions. In one embodiment, CART or other suitable model generation algorithms are applied to at least a portion of the data to generate the high risk rules models 172 .
  • historical data is split into multiple non-overlapped data sets. These multiple data sets are used for model generation and performance evaluation.
  • the data can be split into three sets, training set 1 , training set 2 , and validation.
  • the training set 1 is used to train the neural network.
  • the training set 2 is used during training to ensure the learning converge properly and to reduce over-fitting to the training set 1 .
  • the validation set is used to evaluate the trained model performance.
  • Supervised models can include one or more of scorecards, naive Bayesian, decision trees, logistic regression, and neural networks.
  • FIG. 8 is a flowchart illustrating an example of a method of performing the block 304 of FIG. 5 of generating entity models 140 in the fraud detection system 100 .
  • the method 304 begins at a block 360 in which the model generator 110 receives historical mortgage applications.
  • the model generator 110 can perform various processing functions such as described above with reference to the block 340 of FIG. 7 .
  • the model generator 110 receives data related to mortgage processing related entities such as an account executive, a broker, a loan officer, or an appraiser.
  • the model generator 110 selects risk indicators comprising one or more of the input data fields.
  • expert input is used to select the risk indicators for each type of entity to be modeled.
  • data driven techniques such as data mining are used to identify risk indicators.
  • the model generator 110 performs an unsupervised clustering algorithm such as k-means for each risk indicator for each type of entity.
  • the model generator 110 calculates scores for risk indicators for each received historical loan based on the data distance from data clusters identified by the clustering algorithm. For example, in a simple one cluster model where the data is distributed in a normal or Gaussian distribution, the distance can be a distance from the mean value. The distance/score can be adjusted based on the distribution of data for the risk indicator, e.g., based on the standard deviation in a simple normal distribution.
  • scores for each risk indicator and each entity are calculated based on model, such as a weighted average of each of the applications associated with each entity. Other embodiments can use other models.
  • EPD Early Payment Default
  • certain embodiments descried herein are directed to detecting EPD instead of, or in addition to fraud.
  • an early payment default (EPD) alert system are described herein.
  • such a system can employ statistical pattern recognition to generate a score designed to assess the risk of early payment default in mortgage applications and loans.
  • such a system can use advanced analytic scoring technology that enables mortgage lenders, investment banks, and servicers to score and identify each loan's early payment default risk in real-time during the underwriting process, before a new loan is funded, before it is purchased on the secondary market, and during the loan servicing cycle.
  • Such an EPD alert can provide a sophisticated, analytics-based solution to help curtail the growing problem of early mortgage defaults.
  • an EPD alert system as described herein uses pattern recognition technology to find early payment default risk based on historical patterns of both performing and non-performing mortgage loans from the a database of historical loans. These analytic models accurately predict the likelihood of a loan defaulting early, resulting in financial loss to the lender or investor.
  • the systems and methods related to EPD alert systems can be described in a similar fashion as the embodiments for detecting mortgage related fraud described above. For example, a process similar to that of FIG. 6 can be employed in an EPD alert system, wherein steps 326 , 328 and 330 would be customized and directed to detecting early payment default.
  • an EPD alert system can be a complementary system used with systems and methods for detecting fraud, credit, and compliance risk, such as those described above, used during the loan underwriting, loan trading due diligence, and servicing processes to specifically identify early default risk.
  • One embodiment of an EPD alert system can include a model configured to detect early payment default and improve the identification of EPD risk over traditional credit scores.
  • Lenders can score new loan applications and select the highest scoring, e.g., within a specified cutoff, of applications for a further targeted review. For example, when used by investment banks in evaluating loan pools for purchase on the secondary market, one embodiment of an EPD alert system uses the limited bid tape data to identify high risk loans, which are then selected for further due diligence review.
  • An EPD alert system as described herein can provide both a risk score and specific risk indicators that help guide and expedite the investigative process.
  • EPD alert system can be used independently or in conjunction with a score indicative of the likelihood of fraud to identify both mortgage fraud and EPD risk prior to funding or loan purchase, or during servicing of the loan.
  • the EPD alert system is part of a suite of fraud detection and risk management software designed to provide analytic solutions to the mortgage industry.
  • One such system is described in co-pending U.S. patent application Ser. No. 11/526,208, filed Sep. 26, 2006, which is hereby incorporated by reference.
  • an EPD model can be generated using a supervised learning model (step 302 ) that uses examples of loans with and without early payment default to effectively learn how to generate a score that represents the likelihood of a loan defaulting during a particular portion of the life of the loan, e.g., the first, second or third payment, without anticipated cure.
  • the score can be a value in a particular range, e.g., 1-999 with high scores indicating highest risk of payment default. It should be noted that the payment default can be early payment default, or a default that occurs over a longer period.
  • One embodiment provides an operational workflow that uses both scores in a cascading risk management process for a more comprehensive assessment of fraud and early payment default risk.
  • a cascaded approach can involve receiving mortgage data (step 322 ) and preprocessing an application (step 324 ).
  • loan data can be processed using EPD loan models 932 (see FIG. 10 ) instead of supervised loan models 132 in order to detect the potential for EPD.
  • High risk rules can be matched to the application in step 328 based on the modeling of step 326 and a score can be determined for entity models in step 330 , if entity models are being used.
  • a calculated weighted score can be determined for EPD and a report can be generated in step 334 .
  • the fraud analysis process described above can be performed, either after or in parallel with the process for EPD detection.
  • the results of the EPD process can be used to prioritize applications for the fraud analysis.
  • the codes in table 2 can be used, for example, to identify applications that are a high risk for EPD that are also a high risk for fraud. These applications can then be prioritized for the fraud process.
  • Fraud misrepresentation of a loan is typically detected through a review of the loan file, with occasional use of external data. Risk of early payment default, on the other hand, requires research into the financial viability of the applicant. Thus, the income stability and accuracy/existence of assets should be confirmed. Total debt should be reviewed to see if there are obvious expenses missing, or indications that debt is rising. Analysis of the credit report can provide insight into the trend of the debt-to-income ratio, and provide an indication that the applicant's financial viability might be worsening.
  • risk factors can be included in the supervisory models 170 used for EPD detection native to fraud detection. Those factors can broadly be defined as: borrower's risk, geographic risk, borrower's affordability, and property valuation risk.
  • Borrower's risk can include information such as a credit score, payment history, employment information, tenure in current employment position, debt, income, occupancy, etc. This information can be used to evaluate the risk factors associated with the borrower. For example, if the buyer has a risky credit score or employment, then they may be a higher risk for EPD and the EPD models 932 can take this into account as can the weighting factors applied by, e.g., integrator 936 .
  • Property appraisal information and the geographic location of the property can also be used to determine the EPD risk.
  • the property may be overvalued relative to other properties in the area and/or the area may have a high rate of defaults.
  • such information can be used in models 932 to determine a geographic risk factor and/or a property valuation risk factor.
  • An EPD alert score can be used alone or in combination with a mortgage fraud score to identify loans (or applications) for further review.
  • the EPD alert score suggested areas to begin a user's loan investigation.
  • risk managers are provided a way to use a fraud checklist and verifications to confirm if fraud exists. Presence of fraud provides assurance in the decision to not fund or purchase the loan due to the immediate confirmation of the problem.
  • the remaining loans can then be researched if they contain high scoring EPD alerts, and a determination made about whether the applicant shows indications they will not be able to make their payments.
  • An EPD alert model can have some common variables with the mortgage fraud detection system, but each model should have specific variables to predict the targeted outcome. While fraud and EPD can both occur on the same loan, it has been found that other fraud behavior and credit risk-specific EPD mean that the performance is not the same. Each model can contribute uniquely to the total risk assessment.
  • Embodiments can use a timeframe for the target definition of EPD that is selected to most closely match what lenders typically measure, and that are associated with the most issues for EPD whether the loan is held or sold.
  • the model targets detecting early payment default in the first few months after funding. But it will be understood that the probability for payment default can be detected for any time period after loan funding or adjustments.
  • the EPD model is based on data combining multiple sources of information, e.g., which contain loan application and performance data from lenders that is broader than the mortgage loan data typically available through the credit bureau.
  • An EPD model as described herein can target detection of early payment default in mortgage loans, in contrast to credit models that can have broader targets such as delinquency in 24 months within all credit relationships, or bankruptcy. Given the high impact of early payment defaults on lenders, such an EPD model is better suited to mortgage use.
  • an EPD alert system as described herein can be designed to prevent early payment defaults that can result in severe loss scenarios such as foreclosure or repurchase.
  • the models used target mortgage-related behavior, rather than a broad credit risk model that detects problems such as bankruptcy or charge-off.
  • Feature Extraction is the process of designing predictive input variables for fraud and EPD detection models. Feature extraction can be performed using other models, alone or with input from human analysts. These predictive features are derived from the raw data fields in the loan application data and are calculated on each loan during model processing. The quality of the predictive features is measured by their ability to separate good from bad loans. The final models make use of such identified features to improve predictive performance.
  • EPD model described herein incorporates variables related to the presence of a co-borrower on the loan.
  • the system outputs risk indicators, which can be used for further analysis of the loan.
  • the risk indicators represent the factors that contribute the most to the level of early payment default risk for each loan.
  • the risk indicators are statistically derived.
  • cut-offs can be established for the models.
  • the system can also perform a historical evaluation to help establish the appropriate strategy.
  • a cascading risk management approach can assist in the operational efficiency of implementing the fraud+EPD risk assessment.
  • the EPD alert system can produce a result in real time or in a report that can be accessed in a batch mode.
  • the model output file can contain a combination of the results of applying loan data to both the fraud detection system and the EPD alert system in a single file.
  • the scores enable a focused investigation of the risk.
  • the indicators and suggested actions help tailor the loan review for efficiency, based on the factors contributing to the risk.
  • Lenders can use cascading risk decision criteria to streamline the review for fraud and EPD risk assessment provided by the models.
  • Lenders can use the EPD score to determine the loans with highest risk of early payment default. Based on the results of an investigation, lender policies and fair lending guidelines, a loan application could have additional conditions placed on it, or be declined.
  • an EPD alert system such as system 901 (see FIG. 9 ) can process mortgage data and provide an EPD risk alert and likely reason for the alert.
  • the alert can, in certain embodiments also be used in the loan processing or to prioritize certain applications for fraud analysis.
  • Example risk alerts can include whether the applicant's patent score falls within a range that correlates with a high level of defaults, whether the income level is in a range that correlates with a high level of defaults, whether the property zip code is in an area with high defaults, etc.
  • FIG. 9 is a functional block diagram illustrating a system 900 for EPD detection such as for use with a mortgage origination system 906 .
  • the system 900 can be used to analyze applications for use in evaluating applications and/or funded loans by an investment bank or servicer, or as part of due diligence of a loan portfolio.
  • System 900 can comprise a mortgage origination system configured to provide mortgage data related to mortgage applications; a risk detection system 902 , which can be configured to detect fraud risk associated with the mortgage applications as described with respect to FIGS. 1 and 2 ; a EPD alert system 901 , which can be configured to assess the EPD risk for the mortgage applications; and a model generator 910 that can generate models for use by risk detection system 902 and EPD alert system 901 .
  • the EPD alert system 901 can receive and store data in a storage 904 .
  • the storage 904 can comprise one or more database servers and any suitable configuration of volatile and persistent memory.
  • the system 901 can be configured to receive mortgage application data from the mortgage origination system 906 and provide data indicative of fraud and EPD alerts back to the mortgage origination system 906 .
  • the system 901 uses one or more models to generate the data indicative of fraud and EPD risk.
  • data indicative of fraud and EPD risk can also be provided to a risk manager system 908 for further processing and/or analysis by a human operator.
  • the analysis system 908 can be provided in conjunction with the system 901 or in conjunction with the mortgage origination system 906 .
  • a fraud or other risk detection system 902 can be used in conjunction with, or share databases and other system components with, the EPD alert system 901 .
  • FIG. 10 is a functional block diagram further illustrating an example of the EPD alert system 901 .
  • system 901 is similar to system 100 , with EPD models 932 replacing the loan models 132 and the introduction of credit data 925 .
  • the system 901 can include an origination system interface 922 providing mortgage application data to a data preprocessing module 924 .
  • a credit data system 925 can be configured to receive applicant credit data from one or more credit bureaus or from the lender such as via the loan origination system interface 922 to store and provide that data to the EPD alert system 901 .
  • the origination system interface 922 can receive data from the mortgage origination system 906 of FIG. 9 .
  • the origination system interface 922 can be configured to receive data associated with funded mortgages and can be configured to interface with suitable systems other than, or in addition to, mortgage origination systems.
  • the system interface 922 can be configured to receive “bid tapes” or other collections of data associated with funded mortgages for use in evaluating EPD risk associated with a portfolio of funded loans.
  • the origination system interface 922 can comprise a computer network that communicates with the origination system 906 to receive applications in real time or in batches.
  • the origination system interface 922 receives batches of applications via a data storage medium.
  • the origination system interface 922 can provide application data to the data preprocessing module 924 , which formats application data into data formats used internally in the system 901 .
  • the origination system interface 922 can also provide data from additional sources such as the lender or directly from credit bureaus that can be in different formats for conversion by the data preprocessing module 924 into the internal data formats of the system 901 .
  • the origination system interface 922 and preprocessing module 924 also allow at least portions of a particular embodiment of the system 901 to be used to score EPD risk in different types of mortgage applications and for different loan originators that have varying data and data formats.
  • Table 1 lists examples of mortgage application data that can be used in various embodiments.
  • the preprocessing module 924 can be configured to identify missing data values and provide data for those missing values to improve further processing. For example, the preprocessing module 924 can generate application data to fill missing data fields using one or more rules. Different rules can be used depending on the loan data supplier, on the particular data field, and/or on the distribution of data for a particular field. For example, for categorical fields, the most frequent value found in historical applications can be used. For numerical fields, the mean or median value of historical applications can be used.
  • the preprocessing module 924 can also be configured to identify erroneous data or missing data. In one embodiment, the preprocessing module 924 extrapolates missing data based on data from similar applications, or using default data values. The preprocessing module 924 can perform data quality analysis such as one or more of critical error detection, anomaly detection, and data entry error detection.
  • the data preprocessing module 924 can provide application data to one or more models for EPD risk scoring and processing.
  • application data is provided to one or more EPD models 932 that generate data indicative of EPD risk based on application and applicant data.
  • the data indicative of EPD risk generated by the EPD models 932 can be provided to an integrator 936 that combines scores from one or more models into a final score.
  • the data preprocessing module 924 can also provide application data to one or more entity models 940 that are configured to identify EPD risk based on data associated with entities involved in the processing of the application.
  • Entity models can include models of data associated with loan brokers, loan officers or other entities involved in a loan application. More examples of such entity models 940 are illustrated with reference to FIG. 4 .
  • Each of the entity models can output data to an entity scoring module 950 that is configured to provide a score and/or one or more risk indicators associated with the application data.
  • risk indicator refers to data values identified with respect to one or more data fields that can be indicative of EPD risk.
  • the entity scoring module 950 can provide scores associated with one or more risk indicators associated with the particular entity or application.
  • appraisal value in combination with zip code can be a risk indicator associated with an EPD model.
  • the entity scoring module 950 provides scores and indicators to the integrator 936 to generate a combined EPD risk score and/or set of risk indicators.
  • the integrator 936 can be configured to apply weights and/or processing rules to generate one or more scores and risk indicators based on the data indicative of EPD risk provided by one or more of the loan models 932 , the entity models 940 and entity scoring modules 960 .
  • the risk indicator 936 can generate a single score indicative of EPD risk along with one or more risk indicators relevant for the particular application. Additional scores can also be provided with reference to each of the risk indicators.
  • the integrator 936 can provide this data to a scores and risk indicators module 960 that logs the scores to an output history database 960 .
  • the scores and risk indicators module 960 can identify applications for further review by the risk manager 908 of FIG. 9 . Scores can be real or integer values.
  • scores are numbers in the range of 1-999.
  • thresholds are applied to one or more categories to segment scores into high and low risk categories.
  • thresholds are applied to identify applications for review by the risk manager 908 .
  • risk indicators are represented as codes that are indicative of certain data fields or certain values for data fields. Risk indicators can provide information on the types of EPD risk and recommended actions. For example, risk indicators might include a credit score that falls within high % of default ranges, a high risk of default geographic area, etc. Risk indicators can also be indicative of entity historical transactions, e.g., a CLTV percentage that is indicative of EPD risk.
  • a score review report module 962 can generate a report in one or more formats based on scores and risk indicators provided by the scores and risk indicators module 960 .
  • the score review report module 962 identifies loan applications for review by the risk manager 908 of FIG. 9 .
  • One embodiment desirably improves the efficiency of the risk manager 908 by identifying applications with the highest EPD risk scores or with particular risk indicators for review thereby reducing the number of applications that need to be reviewed.
  • a billing process 966 can be configured to generate billing information based on the results in the output history.
  • Score review report module 962 can output a score report in several formats.
  • the report can include information related to the fraud score as well as the EPD alert score.
  • only information related to the EPD alert score can be output.
  • only the score results e.g., including risk codes, likely reason codes, suggested action codes, etc., can be output, while in other embodiments this information can be combined with the input information, e.g., from table 1 as well.
  • the model generator 910 receives application data, entity data, and data on EPD and non-EPD applications and generates and updates models such as the entity models 940 either periodically or as new data is received.
  • embodiments can combine the functions identified with various blocks of FIGS. 9 and 10 with those of a mortgage fraud detection system 100 .
  • the score review report generator 962 can output reports that include both EPD risk information and data indicative of fraud.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine.
  • a processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
  • a software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
  • An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium.
  • the storage medium can be integral to the processor.
  • the processor and the storage medium can reside in an ASIC.
  • the ASIC can reside in a user terminal.
  • the processor and the storage medium can reside as discrete components in a user terminal.

Abstract

A method for detecting a risk of payment default comprises receiving mortgage data associated with a mortgage application, the mortgage application associated with an applicant, determining a first score for the mortgage data based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant, and generating data indicative of a risk of payment default based at least partly on the first score.

Description

RELATED APPLICATIONS INFORMATION
This application claims the benefit as a continuation-in-part under 35 U.S.C. §120 of U.S. patent application Ser. No. 11/526,208, filed Sep. 22, 2006 and entitled “System and Method for Detecting Mortgage Related Fraud,” which in turn claims the benefit of and incorporates by reference in their entirety, U.S. provisional patent application No. 60/785,902, filed Mar. 24, 2006 and U.S. provisional patent application No. 60/831,788, filed on Jul. 18, 2006. All of the above applications are incorporated by reference in their entirety as if set forth in full. This application also claims the benefit under 35 U.S.C. 119(e) of U.S. Provisional Patent Application Ser. No. 60/978,033, filed Oct. 5, 2007, and entitled “Method and System of Predicting Mortgage Defaults,” which is also incorporated herein by reference in its entirety as if set forth in full.
BACKGROUND
1. Technical Field
The embodiments described herein relate to determining or predicting the likelihood of payment defaults in financial transactions.
2. Related Art
Fraud detection systems detect fraud in financial transactions. For example, a mortgage fraud detection system can be configured to analyze loan application data to identify applications that are being obtained using fraudulent application data.
Existing fraud detection systems, however, have failed to keep pace with the dynamic nature of financial transactions and mortgage application fraud. Moreover, such systems have failed to take advantage of the increased capabilities of computer systems.
Additionally, there currently are no effective systems for detecting the probability of payment default, such as early payment default (EPD). EPD, for example, can have a large impact on a lender. Beyond the obvious lost revenue potential, EPD can generally reduce the value of loans in the secondary market. If EPD, as well as longer term defaults, can be reduced or eliminated, then there will be less inherent risk in the loans and the overall value of the loans should increase.
SUMMARY
A system for the detection of a risk of payment default based on historical mortgage data is described herein.
According to one aspect, a method for detecting a risk of payment default comprises receiving mortgage data associated with a mortgage application, the mortgage data associated with an applicant, determining a first score for the mortgage data based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant, and generating data indicative of a risk of payment default based at least partly on the first score.
According to another aspect, a method for detecting a risk of payment default comprises receiving mortgage data associated with a plurality of mortgage applications, each mortgage application associated with an applicant; determining a plurality of first scores for the mortgage data for each of the plurality of mortgage applications based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant; generating data indicative of a risk of payment default for each of the plurality of mortgage applications; prioritizing the mortgage applications based on the plurality of data generated; determining a plurality of second scores for the mortgage data for each of the plurality of mortgage applications based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions; and generating data indicative of a risk of fraud for each of the prioritized mortgage applications based at least partly on the second score.
According to still another aspect, a system for detecting a risk of payment default comprises a storage configured to receive mortgage data associated with a mortgage application, the mortgage applications associated with an applicant; and a processor coupled with the storage, the processor configured to determine a first score for the mortgage data based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant, and generate data indicative of a risk of payment default based at least partly on the first score.
According to still another aspect, a system for detecting a risk of payment default comprises a storage configured to receive mortgage data associated with a plurality of mortgage applications, each of the plurality of mortgage applications associated with an applicant; and a processor coupled with the storage, the processor configured to determine a plurality of first scores for the mortgage data for each of the plurality of mortgage applications based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions and based on historical credit information related to the applicant, generate data indicative of a risk of payment default for each of the plurality of mortgage applications based at least partly on the first score, prioritize the mortgage applications based on the plurality of data generated, determine a plurality of second scores for the mortgage data for each of the plurality of mortgage applications based at least partly on one or more models that are based on data from a plurality of historical mortgage transactions, and generate data indicative of a risk of fraud for each of the prioritized mortgage applications based at least partly on the second score.
These and other features, aspects, and embodiments are described below in the section entitled “Detailed Description.”
BRIEF DESCRIPTION OF THE DRAWINGS
Features, aspects, and embodiments are described in conjunction with the attached drawings, in which:
FIG. 1 is a functional block diagram illustrating a fraud detection system such as for use with a mortgage origination system in accordance with one embodiment;
FIG. 2 is a functional block diagram illustrating an example of the fraud detection system of FIG. 1 in more detail in accordance with one embodiment;
FIG. 3 is a functional block diagram illustrating an example of loan models that can be included in the fraud detection system of FIG. 2;
FIG. 4 is a functional block diagram illustrating examples of entity models that can be included in the fraud detection system of FIG. 2;
FIG. 5 is a flowchart illustrating model generation and use in the fraud detection system of FIG. 2;
FIG. 6 is a flowchart illustrating an example of using models in the fraud detection system of FIG. 2;
FIG. 7 is a flowchart illustrating an example of generating a supervisory model in the fraud detection system of FIG. 2;
FIG. 8 is a flowchart illustrating an example of generating entity models in the fraud detection system of FIG. 2;
FIG. 9 is a functional block diagram illustrating a payment default detection system such as for use with a mortgage origination system; and
FIG. 10 is a functional block diagram illustrating an example of an payment default detection system in more detail.
DETAILED DESCRIPTION
The following detailed description is directed to certain specific embodiments, but it will be understood that the systems and methods described herein can be embodied in a multitude of different ways as defined and covered by the claims. For example, certain embodiments described herein are described generally in relation to Early Payment Default (EPD). But it will be understood that these same embodiments can be applied to payment default that can occur at any period during the loan. Accordingly, nothing in the description that follows should be seen as limiting the systems and methods described herein to EPD situations.
Further, while the systems and methods herein are described in relation to mortgage applications, or mortgage transactions, it will be understood that this by way of example only and that the systems and methods described herein can extend to other types of transactions.
In this description, reference is made to the drawings wherein like parts are designated with like numerals throughout.
Existing fraud detection systems can use transaction data in addition to data related to the transacting entities to identify fraud. Such systems can operate in either batch (processing transactions as a group of files at periodic times during the day) or real time mode (processing transactions one at a time, as they enter the system). However, the fraud detection capabilities of existing systems have not kept pace with either the types of fraudulent activity that have evolved or increasing processing and storage capabilities of computing systems.
For example, it has been found that, as discussed with reference to some embodiments, fraud detection can be improved by using stored past transaction data in place of, or in addition to, summarized forms of past transaction data. In addition, in one embodiment, fraud detection can be improved by using statistical information that is stored according to groups of individuals that form clusters. In one such embodiment, fraud can be identified with reference to deviation from identified clusters. In one embodiment, in addition to data associated with the mortgage applicant, embodiments of mortgage fraud detection systems can use data that is stored in association with one or more entities associated with the processing of the mortgage transaction such as brokers, appraisers, or other parties to mortgage transactions. The entities can be real persons or can refer to business associations, e.g., a particular appraiser, or an appraisal firm. Fraud generally refers to any material misrepresentation associated with a loan application and can include any misrepresentation which leads to a higher probability for the resulting loan to default or become un-sellable or require discount in the secondary market.
Mortgages can include residential, commercial, or industrial mortgages. In addition, mortgages can include first, second, home equity, or any other loan associated with a real property. In addition, it is to be recognized that other embodiments can also include fraud detection in other types of loans or financial transactions.
Exemplary applications of fraud detection relate to credit cards, debit cards, and mortgages. Furthermore, various patterns can be detected from external sources, such as data available from a credit bureau or other data aggregator.
FIG. 1 is a functional block diagram illustrating a fraud detection system 100 such as for use with a mortgage origination system 106. In other embodiments, the system 100 can be used to analyze applications for use in evaluating applications and/or funded loans by an investment bank or as part of due diligence of a loan portfolio. The fraud detection system 100 can receive and store data in a storage 104. The storage 104 can comprise one or more database servers and any suitable configuration of volatile and persistent memory. The fraud detection system 100 can be configured to receive mortgage application data from the mortgage origination system 106 and provide data indicative of fraud back to the mortgage origination system 106. In one embodiment, the fraud detection system 100 uses one or more models to generate the data indicative of fraud. In one embodiment, data indicative of fraud can also be provided to a risk manager system 108 for further processing and for analysis by a human operator. The analysis system 108 can be provided in conjunction with the fraud detection system 100 or in conjunction with the mortgage origination system 106.
A model generator 110 can provide models to the fraud detection system 100. In one embodiment, the model generator 110 can provide the models periodically to the system 100, such as when new versions of the system 100 are released to a production environment. In other embodiments, at least a portion of the model generator 110 can be included in the system 100 and configured to automatically update at least a portion of the models in the system 100.
FIG. 2 is a functional block diagram further illustrating an example of the fraud detection system 100. The system 100 can include an origination system interface 122 providing mortgage application data to a data preprocessing module 124. The origination system interface 122 can receive data from the mortgage origination system 106 of FIG. 1. In other embodiments, the origination system interface 122 can be configured to receive data associated with funded mortgages and can be configured to interface with suitable systems other than, or in addition to, mortgage origination systems. For example, in one embodiment, the system interface 122 can be configured to receive “bid tapes” or other collections of data associated with funded mortgages for use in evaluating fraud associated with a portfolio of funded loans. In one embodiment the origination system interface 122 comprises a computer network that communicates with the origination system 106 to receive applications in real time or in batches. In one embodiment, the origination system interface 122 receives batches of applications via a data storage medium. The origination system interface 122 provides application data to the data preprocessing module 124 which formats application data into data formats used internally in the system 100. For example, the origination system interface 122 can also provide data from additional sources such as credit bureaus that can be in different formats for conversion by the data preprocessing module 124 into the internal data formats of the system 100.
The origination system interface 122 and preprocessing module 124 can also allow at least portions of a particular embodiment of the system 100 to be used to detect fraud in different types of credit applications and for different loan originators that have varying data and data formats. Table 1 lists examples of mortgage application data that can be used in various embodiments.
TABLE 1
Examples of Mortgage Data.
Field Name Field Description
portfolio_id Specifies which model was executed
client_discretionary_field Reserved for client use
loan_no Unique Identifier for Loans
appl_date Application Date
appraisal_value Appraisal Value
borr_last_name Borrower Last Name
borr_home_phone Borrower Home Phone
borr_ssn Borrower Social Security Number
coborr_last_name Co-Borrower Last Name
coborr_ssn Co-Borrower SSN
doc_type_code Numeric Code For Documentation Type
(Stated, Full, Partial, etc)
credit_score Credit Risk Score
loan_amount Loan Amount
prop_zipcode Five Digit Property Zip Code
status_desc Loan Status
borr_work_phone Borrower Business Phone Number
borr_self_employed Borrower Self Employed (Yes/No)
borr_income Borrower Monthly Income
purpose_code Loan Purpose (Refi (1st, 2nd) or Purchase
(1st, 2nd))
borr_prof_yrs Borrower's Number of Years in this
Profession
acct_mgr_name Account Manager name
ae_code Account Executive identifier (can be name or
code)
category_desc Category Description
loan_to_value Loan to Value Ratio
combined_ltv Combined Loan to Value Ratio
status_date Status Date
borrower_employer Borrower Employer's Name
borrower_first_name Borrower first name
coborr_first_name Co-Borrower first name
mail_address Borrower mailing street address
mail_city Borrower mailing city
mail_state Borrower mailing state
mail_zipcode Borrower mailing address zipcode
prop_address Property street address
prop_city Property city
prop_state Property state
Back_end_ratio Back End Ratio
front_end_ratio Front End Ratio
Appraiser Data
appr_code Unique identifier for appraiser
appr_first_name Appraiser first name
appr_last_name Appraiser last name
appr_tax_id Appraiser tax ID
appr_license_number Appraiser License Number
appr_license_expiredate Appraiser license expiration date
appr_license_state Appraiser license state code
company_name Appraiser company name
appr_cell_phone Appraiser cell phone
appr_work_phone Appraiser work phone
appr_fax Appraiser fax number
appr_address Appraiser current street address
appr_city Appraiser current city
appr_state Appraiser current state
appr_zipcode Appraiser current zip code
appr_status_code Appraiser status code
appr_status_date Date of appraiser's current status
appr_email Appraiser e-mail address
Broker Data
brk_code Broker Identifier
broker_first_name Broker first name (or loan officer first name)
broker_last_name Broker last name (or loan officer last name)
broker_tax_id Broker tax ID
broker_license_number Broker license number
broker_license_expiredate Broker license expiration date
broker_license_state Broker license state code
company_name Broker company name
brk_cell_phone Broker cell phone
brk_work_phone Broker work phone
brk_fax Broker fax number
brk_address Broker current street address
brk_city Broker current city
brk_state Broker current state
brk_zipcode Broker current zip code
brk_status_code Broker status code
brk_status_date Date of broker's current status
brk_email Broker e-mail address
brk_fee_amount Broker fee amount
brk_point_amount Broker point amount
program_type_desc Program Type Description
loan_disposition Final disposition of loan during application
process:
FUNDED - approved and funded
NOTFUNDED - approved and not funded
FRAUDDECLINE - confirmed fraud and
declined
CANCELLED - applicant withdrew
application prior to any risk evaluation
or credit decision
PREVENTED - application conditioned
for high risk/suspicion of misrepresentation
and application was subsequently
withdrawn or declined (suspected
fraud but not confirmed fraud)
DECLINED - application was declined for
non-fraudulent reasons (e.g. credit risk)
FUNDFRAUD - application was approved
and funded and subsequently found to be
fraudulent in post-funding QA process
The preprocessing module 124 can be configured to identify missing data values and provide data for those missing values to improve further processing. For example, the preprocessing module 124 can generate application data to fill missing data fields using one or more rules. Different rules can be used depending on the loan data supplier, on the particular data field, and/or on the distribution of data for a particular field. For example, for categorical fields, the most frequent value found in historical applications can be used. For numerical fields, the mean or median value of historical applications can be used. In addition, other values can be selected such as a value that is associated with the highest risk of fraud (e.g., assume the worst) or a value that is associated with the lowest risk of fraud (e.g., assume the best). In one embodiment, a sentinel value, e.g., a specific value that is indicative of a missing value to one or more fraud models can be used (allowing the fact that particular data is missing to be associated with fraud). The preprocessing module 124 can also be configured to identify erroneous data or missing data. In one embodiment, the preprocessing module 124 extrapolates missing data based on data from similar applications, similar applicants, or using default data values. The preprocessing module 124 can perform data quality analysis such as one or more of critical error detection, anomaly detection, and data entry error detection. In one embodiment, applications failing one or more of these quality analyses can be logged to a data error log database 126.
In critical error detection, the preprocessing module 124 identifies applications that are missing data that the absence of which is likely to confound further processing. Such missing data can include, for example, appraisal value, borrower credit score, or loan amount. In one embodiment, no further processing is performed and a log or error entry is stored to the database 126 and for provided to the loan origination system 106.
In anomaly detection, the preprocessing module 124 identifies continuous application data values that can be indicative of data entry error or of material misrepresentations. For example, high loan or appraisal amounts (e.g., above a threshold value) can be indicative of data entry error or fraud. Other anomalous data can include income or age data that is outside selected ranges. In one embodiment, such anomalous data can be logged and the log provided to the origination system 106. In one embodiment, the fraud detection system 100 continues to process applications with anomalous data. The presence of anomalous data can be logged to the database 126 and/or included in a score output or report for the corresponding application.
In data entry detection, the preprocessing module 124 can be configured to identify non-continuous data such as categories or coded data that appear to have data entry errors. For example, telephone numbers or zip codes that have too many or too few digits, incomplete social security numbers, toll free numbers as home or work numbers, or other category data that fails to conform to input specifications can be logged. The presence of anomalous data can be logged to the database 126 and/or included in a score output or report for the corresponding application.
In one embodiment, the preprocessing module 124 can be configured to query an input history database 128 to determine if the application data is indicative of a duplicate application. A duplicate can indicate either resubmission of the same application fraudulently or erroneously. Duplicates can be logged. In one embodiment, no further processing of duplicates is performed. In other embodiments, processing of duplicates continues and can be noted in the final report or score. If no duplicate is found, the application data is stored to the input history database 124 to identify future duplicates.
The data preprocessing module 124 provides application data to one or more models for fraud scoring and processing. In one embodiment, application data is provided to one or more loan models 132 that generate data indicative of fraud based on application and applicant data. The data indicative of fraud generated by the loan models 132 can be provided to an integrator 136 that combines scores from one or more models into a final score. The data preprocessing module 124 can also provide application data to one or more entity models 140 that are configured to identify fraud based on data associated with entities involved in the processing of the application. Entity models can include models of data associated with loan brokers, loan officers or other entities involved in a loan application.
More examples of such entity models 140 are illustrated with reference to FIG. 4. Each of the entity models can output data to an entity scoring module 150 that is configured to provide a score and/or one or more risk indicators associated with the application data. The entity scoring module 150 can provide scores associated with one or more risk indicators associated with the particular entity or application.
The term “risk indicator” refers to data values identified with respect to one or more data fields that can be indicative of fraud. For example, appraisal value in combination with zip code can be a risk indicator associated with an appraiser model. In one embodiment, the entity scoring module 150 provides scores and indicators to the integrator 136 to generate a combined fraud score and/or set of risk indicators.
In one embodiment, the selection of risk indicators are based on criteria such as domain knowledge, and/or correlation coefficients between entity scores and fraud rate, if entity fraud rate is available. Correlation coefficient between entity score si for risk indicator j and entity fraud rate f is defined as
r i = j = i N ( s j i - s _ ) ( f i - f _ ) ( N - 1 ) SD ( s i ) SD ( f ) ,
where si, is the score for entity j on risk indicator i; and fi is the fraud rate for entity j. If ri is larger than a pre-defined threshold, then the risk indicator is selected.
In one embodiment, the entity scoring model 150 combines each of the risk indicator scores for a particular entity using a weighted average or other suitable combining calculation to generate an overall entity score. In addition, the risk indicators having higher scores can also be identified and provided to the integrator 136.
In one embodiment, the combined score for a particular entity can be determined using one or more of the following models:
    • An equal weight average:
S c = 1 N i = 1 N s i ,
    •  where N is the number of risk indicators;
    • A weighted average:
S c = 1 N i = 1 N s i α i ,
    •  where N is the number of risk indicators and αi is estimated based on how predictive risk indicator i is on individual loan level α;
    • A competitive committee:
S c = 1 M i = 1 M s i ,
    •  where sjε(set of largest M risk indicator scores).
If entity fraud rate or entity performance data (EPD: not to be confused with EPD as defined below) rate is available, the fraud/EPD rate can be incorporated with entity committee score to generate the combined entity score. The entity score SE, can be calculated using one of the following equations:
    • SE=SC, if relative entity fraud/EPD rate ≦1;
    • SE=SD,+min(α*max(absoluteFraudRate, absoluteEPDRate),0.99)(998−SD),
    • if relative entity fraud/EPD rate>1 and SC<SD.
    • SE=SC+min(α*max(absoluteFraudRate, absoluteEPDRate),0.99)(998−SD), where α=b*tan h(α*(max(relafiveFraudRate,relativeEPDRate)−1)).
The preprocessing module 124 can also provide application data to a risky file processing module 156. In addition to application data, the risky file processing module 156 is configured to receive files from a risky files database 154. “Risky” files include portions of applications that are known to be fraudulent. It has been found that fraudulent applications are often resubmitted with only insubstantial changes in application data. The risky file processing module 156 compares each application to the risky files database 154 and flags applications that appear to be resubmissions of fraudulent applications. In one embodiment, risky file data is provided to the integrator 136 for integration into a combined fraud score or report.
The integrator 136 can be configured to apply weights and for processing rules to generate one or more scores and risk indicators based on the data indicative of fraud provided by one or more of the loan models 132, the entity models 140 and entity scoring modules 160, and the risky file processing module 156. In one embodiment, the risk indicator 136 generates a single score indicative of fraud along with one or more risk indicators relevant for the particular application. Additional scores can also be provided with reference to each of the risk indicators. The integrator 136 can provide this data to a scores and risk indicators module 160 that logs the scores to an output history database 160. In one embodiment, the scores and risk indicators module 160 identifies applications for further review by the risk manager 108 of FIG. 1. Scores can be real or integer values.
In another embodiment, scores are numbers in the range of 1-999. In one embodiment, thresholds are applied to one or more categories to segment scores into high and low risk categories. In one embodiment, thresholds are applied to identify applications for review by the risk manager 108. In one embodiment, risk indicators are represented as codes that are indicative of certain data fields or certain values for data fields. Risk indicators can provide information on the types of fraud and recommended actions. For example, risk indicators might include a credit score inconsistent with income, high risk geographic area, etc. Risk indicators can also be indicative of entity historical transactions, e.g., a broker trend that is indicative of fraud.
A score review report module 162 can generate a report ir, or, e or more formats based on scores and risk indicators provided by the scores and risk indicators module 160. In one embodiment, the score review report module 162 identifies loan applications for review by the risk manager 108 of FIG. 1. One embodiment desirably improves the efficiency of the risk manager 108 by identifying applications with the highest fraud scores or with particular risk indicators for review thereby reducing the number of applications that need to be reviewed. A billing process 166 can be configured to generate billing information based on the results in the output history.
In one embodiment, the model generator 110 receives application data, entity data, and data on fraudulent and non-fraudulent applications and generates and updates models such as the entity models 140 either periodically or as new data is received.
FIG. 3 is a functional block diagram illustrating an example of the loan models 132 in the fraud detection system 100. In one embodiment, the loan models 132 can include one or more supervised models 170 and high risk rules models 172. Supervised models 170 are models that are generated based on training or data analysis that is based on historical transactions or applications that have been identified as fraudulent or non-fraudulent. Examples of implementations of supervised models 170 include scorecards, naive Bayesian, decision trees, logistic regression, and neural networks. Particular embodiments can include one or more such supervised models 170.
The high risk rules models 172 can include expert systems, decision trees, and for classification and regression tree (CART) models. The high risk rules models 172 can include rules or trees that identify particular data patterns that are indicative of fraud. In one embodiment, the high risk rules model 172 is used to generate scores and/or risk indicators. In one embodiment, the rules, including selected data fields and condition parameters, are developed using the historical data used to develop the loan model 170. A set of high risk rule models 172 can be selected to include rules that have low firing rate and high hit rate. In one embodiment, when a rule i is fired, it outputs a score: srule i. The score represents the fraud risk associated to the rule. The score can be a function of:
s rule i=ƒ(hitRateOfRule1,firingRateOfRulei,scoreDistributionOfloanAppModel),
and
S rule=max(S rule 1 . . . S rule N).
In one embodiment, the loan models 170 and 172 are updated when new versions of the system 100 are released into operation. In another embodiment, the supervised models 170 and the high risk rules models. 172 are updated automatically. In addition, the supervised models 170 and the high risk rules models 172 can also be updated such as when new or modified data features or other model parameters are received.
FIG. 4 is a functional block diagram illustrating examples of the entity models 140 in the fraud detection system 100. It has been found that fraud detection performance can be increased by including models that operate on entities associated with a mortgage transaction that are in addition to the mortgage applicant. Scores for a number of different types of entities are calculated based on historical transaction data. The entity models can include one or more of an account executive model 142, a broker model 144, a loan officer model 146, and an appraiser (or appraisal) model 148. Embodiments can also include other entities associated with a transaction such as the lender. For example, in one embodiment, an unsupervised model, e.g., a clustering model such as k-means, is applied to risk indicators for historical transactions for each entity. A score for each risk indicator, for each entity, is calculated based on the relation of the particular entity to the clusters across the data set for the particular risk indicator.
By way of a simple example, for a risk indicator that is a single value, e.g., loan value for a broker, the difference between the loan value of each loan of the broker and the mean (assuming a simple Gaussian distribution of loan values) divided by the standard deviation of the loan values over the entire set of historical loans for all brokers might be used as a risk indicator for that risk indicator score. Embodiments that include more sophisticated clustering algorithms such as k-means can be used along with multidimensional risk indicators to provide for more powerful entity scores.
The corresponding entity scoring module 150 for each entity (e.g., account executive scoring module 152, broker scoring module 154, loan officer scoring module 156, and appraisal scoring module 158) can create a weighted average of the scores of a particular entity over a range of risk indicators that are relevant to a particular transaction.
FIG. 5 is a flowchart illustrating a method 300 of operation of the fraud detection system 100. The method 300 begins at a block 302 in which the supervised model is generated. In one embodiment, the supervised models 170 are generated based on training or data analysis that is based on historical transactions or applications that have been identified as fraudulent or non-fraudulent. Further details of generating supervised models are discussed with reference to FIG. 7. Moving to a block 304, the system 100 generates one or more unsupervised entity models such as the account executive model 142, the broker model 144, the loan officer model 146, or the appraiser (or appraisal) model 148. Further details of generating unsupervised models are discussed with reference to FIG. 8. Proceeding to a block 306, the system 100 applies application data to models such as supervised models 132 and entity models 150. The functions of block 306 can be repeated for each loan application that is to be processed. Further detail of applying data to the models is described with reference to FIG. 6.
In one embodiment, the model generator 110 generates and/or updates models as new data is received or at specified intervals such as nightly or weekly. In other embodiments, some models are updated continuously and others at specified intervals depending on factors such as system capacity, mortgage originator requirements or preferences, etc. In one embodiment, the entity models are updated periodically, e.g., nightly or weekly while the loan models are only updated when new versions of the system 100 are released into operation.
FIG. 6 is a flowchart illustrating an example of a method of performing the functions of the block 306 of FIG. 5 of using models in the fraud detection system 100 to process a loan application. The function 306 begins at a block 322 in which the origination system interface 122 receives loan application data. Next at a block 324, the data preprocessing module 124 preprocesses the application 324 as discussed above with reference to FIG. 2.
Moving to a block 326, the application data is applied to the supervised loan models 170 which provide a score indicative of the relative likelihood or probability of fraud to the integrator 136. In one embodiment, the supervised loan models 170 can also provide risk indicators. Next at a block 328, the high risk rules model 172 is applied to the application to generate one or more risk indicators, and/or additional scores indicative of fraud. Moving to a block 330, the application data is applied to one or more of the entity models 140 to generate additional scores and risk indicators associated with the corresponding entities of the models 140 associated with the transaction.
Next at a block 332, the integrator 136 calculates a weighted score and risk indicators based on scores and risk indicators from the supervised loan model 170, the high risk rules model 172, and scores of entity models 140. In one embodiment, the integrator 136 includes an additional model, e.g., a trained supervised model that combines the various scores, weights, and risk factors provided by the models 170, 172, and 140.
Moving to a block 334, the scores and risk indicators module 160 and the score review report module 162 generate a report providing a weighted score along with one or more selected risk indicators. The selected risk indicators can include explanations of potential types of frauds and recommendations for action.
FIG. 7 is a flowchart illustrating an example of a method of performing the block 302 of FIG. 5 of generating the loan models 132 in the fraud detection system 100. Supervised learning algorithms identify a relationship between input features and target variables based on training data. In one embodiment, the target variables comprise the probability of fraud. Generally, the models used can depend on the size of the data and how complex a problem is. For example, if the fraudulent exemplars in historical data are less than about 5000 in number, smaller and simpler models can be used, so robust model parameter estimation can be supported by the data size. The method 302 begins at a block 340 in which the model generator 110 receives historical mortgage data. The model generator 110 can extract and convert client historical data according to internal development data specifications, perform data analysis to determine data quality and availability, and rectify anomalies, such as missing data, invalid data, or possible data entry errors similar to that described above with reference to preprocessing module 124 of FIG. 2.
In addition, the model generator 110 can perform feature extraction including identifying predictive input variables for fraud detection models. The model generator 110 can use domain knowledge and mathematical equations applied to single or combined raw input data fields to identify predictive features. Raw data fields can be combined and transformed into discriminative features. Feature extraction can be performed based on the types of models for which the features are to be used. For example, linear models such as, logistic regression and linear regression, work best when the relationships between input features and the target are linear. If the relationship is non-linear, proper transformation functions can be applied to convert such data to a linear function. In one embodiment, the model generator 110 selects features from a library of features for use in particular models. The selection of features can be determined by availability of data fields, and the usefulness of a feature for the particular data set and problem. Embodiments can use techniques such as filter and wrapper approaches, including information theory, stepwise regression, sensitivity analysis, data mining, or other data driven techniques for feature selection.
In one embodiment, the model generator 110 can segment the data into subsets to better model input data. For example, if subsets of a data set are identified with significantly distinct behavior, special models designed especially for these subsets normally outperform a general fit-all model. In one embodiment, a prior knowledge of data can be used to segment the data for generation of models. For example, in one embodiment, data is segregated geographically so that, for example, regional differences in home prices and lending practices do not confound fraud detection. In other embodiments, data driven techniques, e.g., unsupervised techniques such as clustering, are used to identify data segments that can benefit from a separate supervised model.
Proceeding to a block 342, the model generator 110 identifies a portion of the applications in the received application data (or segment of that data) that were fraudulent. In one embodiment, the origination system interface 122 provides this labeling. Moving to a block 344, the model generator 110 identifies a portion of the applications that were non-fraudulent. Next at a block 346, the model generator 110 generates a model such as the supervised model 170 using a supervised learning algorithm to generate a model that distinguishes the fraudulent from the non-fraudulent transactions. In one embodiment, CART or other suitable model generation algorithms are applied to at least a portion of the data to generate the high risk rules models 172.
In one embodiment, historical data is split into multiple non-overlapped data sets. These multiple data sets are used for model generation and performance evaluation. For example, to train a neural network model, the data can be split into three sets, training set 1, training set 2, and validation. The training set 1 is used to train the neural network. The training set 2 is used during training to ensure the learning converge properly and to reduce over-fitting to the training set 1. The validation set is used to evaluate the trained model performance. Supervised models can include one or more of scorecards, naive Bayesian, decision trees, logistic regression, and neural networks.
FIG. 8 is a flowchart illustrating an example of a method of performing the block 304 of FIG. 5 of generating entity models 140 in the fraud detection system 100. The method 304 begins at a block 360 in which the model generator 110 receives historical mortgage applications. The model generator 110 can perform various processing functions such as described above with reference to the block 340 of FIG. 7. Next at a block 362, the model generator 110 receives data related to mortgage processing related entities such as an account executive, a broker, a loan officer, or an appraiser. Moving to a block 364, the model generator 110 selects risk indicators comprising one or more of the input data fields. In one embodiment, expert input is used to select the risk indicators for each type of entity to be modeled. In other embodiments, data driven techniques such as data mining are used to identify risk indicators.
Next at a block 368, the model generator 110 performs an unsupervised clustering algorithm such as k-means for each risk indicator for each type of entity. Moving to a block 370, the model generator 110 calculates scores for risk indicators for each received historical loan based on the data distance from data clusters identified by the clustering algorithm. For example, in a simple one cluster model where the data is distributed in a normal or Gaussian distribution, the distance can be a distance from the mean value. The distance/score can be adjusted based on the distribution of data for the risk indicator, e.g., based on the standard deviation in a simple normal distribution. Moving to a block 372, scores for each risk indicator and each entity are calculated based on model, such as a weighted average of each of the applications associated with each entity. Other embodiments can use other models.
As noted above Early Payment Default (EPD) can also reduce the value of loans and increase risk for lenders. Accordingly, certain embodiments descried herein are directed to detecting EPD instead of, or in addition to fraud. For example, various embodiments of an early payment default (EPD) alert system are described herein. Generally, such a system can employ statistical pattern recognition to generate a score designed to assess the risk of early payment default in mortgage applications and loans. In one embodiment, such a system can use advanced analytic scoring technology that enables mortgage lenders, investment banks, and servicers to score and identify each loan's early payment default risk in real-time during the underwriting process, before a new loan is funded, before it is purchased on the secondary market, and during the loan servicing cycle. Such an EPD alert can provide a sophisticated, analytics-based solution to help curtail the growing problem of early mortgage defaults.
In one embodiment, an EPD alert system as described herein uses pattern recognition technology to find early payment default risk based on historical patterns of both performing and non-performing mortgage loans from the a database of historical loans. These analytic models accurately predict the likelihood of a loan defaulting early, resulting in financial loss to the lender or investor. As will be discussed in more detail below, the systems and methods related to EPD alert systems can be described in a similar fashion as the embodiments for detecting mortgage related fraud described above. For example, a process similar to that of FIG. 6 can be employed in an EPD alert system, wherein steps 326, 328 and 330 would be customized and directed to detecting early payment default.
As such, an EPD alert system can be a complementary system used with systems and methods for detecting fraud, credit, and compliance risk, such as those described above, used during the loan underwriting, loan trading due diligence, and servicing processes to specifically identify early default risk. One embodiment of an EPD alert system can include a model configured to detect early payment default and improve the identification of EPD risk over traditional credit scores.
Lenders can score new loan applications and select the highest scoring, e.g., within a specified cutoff, of applications for a further targeted review. For example, when used by investment banks in evaluating loan pools for purchase on the secondary market, one embodiment of an EPD alert system uses the limited bid tape data to identify high risk loans, which are then selected for further due diligence review. An EPD alert system as described herein can provide both a risk score and specific risk indicators that help guide and expedite the investigative process.
Again, embodiments of such an EPD alert system can be used independently or in conjunction with a score indicative of the likelihood of fraud to identify both mortgage fraud and EPD risk prior to funding or loan purchase, or during servicing of the loan. In one embodiment, for example, the EPD alert system is part of a suite of fraud detection and risk management software designed to provide analytic solutions to the mortgage industry. One such system is described in co-pending U.S. patent application Ser. No. 11/526,208, filed Sep. 26, 2006, which is hereby incorporated by reference.
In one embodiment, an EPD model can be generated using a supervised learning model (step 302) that uses examples of loans with and without early payment default to effectively learn how to generate a score that represents the likelihood of a loan defaulting during a particular portion of the life of the loan, e.g., the first, second or third payment, without anticipated cure. The score can be a value in a particular range, e.g., 1-999 with high scores indicating highest risk of payment default. It should be noted that the payment default can be early payment default, or a default that occurs over a longer period.
There is overlap between detection of fraud and prediction of early payment default, since a portion of EPD can be due to fraud, and a portion of such fraud is therefore reflected in the models of an EPD alert system described herein. By focusing the pattern recognition detection on specific targets for each model, high risk fraud and/or credit risk loans are detected. In one embodiment, the models are specifically focused on predicting payment risk of financial loss to the lender.
One embodiment provides an operational workflow that uses both scores in a cascading risk management process for a more comprehensive assessment of fraud and early payment default risk. Studies with lenders determined that additional savings result from the combined model approach. For example, with reference to FIG. 3, such a cascaded approach can involve receiving mortgage data (step 322) and preprocessing an application (step 324). In this case, however, loan data can be processed using EPD loan models 932 (see FIG. 10) instead of supervised loan models 132 in order to detect the potential for EPD. High risk rules can be matched to the application in step 328 based on the modeling of step 326 and a score can be determined for entity models in step 330, if entity models are being used. In step 332, a calculated weighted score can be determined for EPD and a report can be generated in step 334.
The process up to this point is discussed for EPD in more detail below and with respect to the systems illustrated in FIGS. 9 and 10.
But in certain embodiments, the fraud analysis process described above can be performed, either after or in parallel with the process for EPD detection. For example, in certain embodiments, the results of the EPD process can be used to prioritize applications for the fraud analysis. The codes in table 2 can be used, for example, to identify applications that are a high risk for EPD that are also a high risk for fraud. These applications can then be prioritized for the fraud process.
While EPD losses can have an immediate impact to a lender, fraud is also a significant issue whether the loan is held or sold. It has been determined that the largest impacts of fraud are often felt by originators 6, 12 and even 18 months after the loan is funded through repurchase requests and defaults due to larger scale fraudulent payment manipulation schemes and appraisal inflation schemes. Mitigating future loss and ensuring the stability of reserves can be improved by the use of predictive analytics that address both EPD and fraud.
Fraud misrepresentation of a loan is typically detected through a review of the loan file, with occasional use of external data. Risk of early payment default, on the other hand, requires research into the financial viability of the applicant. Thus, the income stability and accuracy/existence of assets should be confirmed. Total debt should be reviewed to see if there are obvious expenses missing, or indications that debt is rising. Analysis of the credit report can provide insight into the trend of the debt-to-income ratio, and provide an indication that the applicant's financial viability might be worsening.
Thus, additional risk factors can be included in the supervisory models 170 used for EPD detection native to fraud detection. Those factors can broadly be defined as: borrower's risk, geographic risk, borrower's affordability, and property valuation risk.
Borrower's risk can include information such as a credit score, payment history, employment information, tenure in current employment position, debt, income, occupancy, etc. This information can be used to evaluate the risk factors associated with the borrower. For example, if the buyer has a risky credit score or employment, then they may be a higher risk for EPD and the EPD models 932 can take this into account as can the weighting factors applied by, e.g., integrator 936.
Property appraisal information and the geographic location of the property can also be used to determine the EPD risk. For example, the property may be overvalued relative to other properties in the area and/or the area may have a high rate of defaults. Thus, such information can be used in models 932 to determine a geographic risk factor and/or a property valuation risk factor.
These factors can be associated with alerts that can be output by the scores and risk indicators block 960. Table 2 lists example alert codes some of which can be associated with these and other risk factors.
An EPD alert score can be used alone or in combination with a mortgage fraud score to identify loans (or applications) for further review. In one embodiment, the EPD alert score suggested areas to begin a user's loan investigation. By starting with the highest fraud scores, risk managers are provided a way to use a fraud checklist and verifications to confirm if fraud exists. Presence of fraud provides assurance in the decision to not fund or purchase the loan due to the immediate confirmation of the problem. The remaining loans can then be researched if they contain high scoring EPD alerts, and a determination made about whether the applicant shows indications they will not be able to make their payments. An EPD alert model can have some common variables with the mortgage fraud detection system, but each model should have specific variables to predict the targeted outcome. While fraud and EPD can both occur on the same loan, it has been found that other fraud behavior and credit risk-specific EPD mean that the performance is not the same. Each model can contribute uniquely to the total risk assessment.
Embodiments can use a timeframe for the target definition of EPD that is selected to most closely match what lenders typically measure, and that are associated with the most issues for EPD whether the loan is held or sold. In one embodiment, the model targets detecting early payment default in the first few months after funding. But it will be understood that the probability for payment default can be detected for any time period after loan funding or adjustments.
In one embodiment, the EPD model is based on data combining multiple sources of information, e.g., which contain loan application and performance data from lenders that is broader than the mortgage loan data typically available through the credit bureau. An EPD model as described herein can target detection of early payment default in mortgage loans, in contrast to credit models that can have broader targets such as delinquency in 24 months within all credit relationships, or bankruptcy. Given the high impact of early payment defaults on lenders, such an EPD model is better suited to mortgage use.
In particular, an EPD alert system as described herein can be designed to prevent early payment defaults that can result in severe loss scenarios such as foreclosure or repurchase. In one embodiment, the models used target mortgage-related behavior, rather than a broad credit risk model that detects problems such as bankruptcy or charge-off.
Feature Extraction is the process of designing predictive input variables for fraud and EPD detection models. Feature extraction can be performed using other models, alone or with input from human analysts. These predictive features are derived from the raw data fields in the loan application data and are calculated on each loan during model processing. The quality of the predictive features is measured by their ability to separate good from bad loans. The final models make use of such identified features to improve predictive performance.
In one embodiment, EPD model described herein incorporates variables related to the presence of a co-borrower on the loan. In one embodiment, the system outputs risk indicators, which can be used for further analysis of the loan. The risk indicators represent the factors that contribute the most to the level of early payment default risk for each loan. In one embodiment, the risk indicators are statistically derived.
Based on risk level tolerance and operational considerations, cut-offs can be established for the models. In one embodiment, the system can also perform a historical evaluation to help establish the appropriate strategy. A cascading risk management approach can assist in the operational efficiency of implementing the fraud+EPD risk assessment.
The EPD alert system can produce a result in real time or in a report that can be accessed in a batch mode. The model output file can contain a combination of the results of applying loan data to both the fraud detection system and the EPD alert system in a single file.
The scores enable a focused investigation of the risk. In addition, the indicators and suggested actions help tailor the loan review for efficiency, based on the factors contributing to the risk. Lenders can use cascading risk decision criteria to streamline the review for fraud and EPD risk assessment provided by the models.
Lenders can use the EPD score to determine the loans with highest risk of early payment default. Based on the results of an investigation, lender policies and fair lending guidelines, a loan application could have additional conditions placed on it, or be declined. Thus, an EPD alert system, such as system 901 (see FIG. 9) can process mortgage data and provide an EPD risk alert and likely reason for the alert. The alert can, in certain embodiments also be used in the loan processing or to prioritize certain applications for fraud analysis. Example risk alerts can include whether the applicant's patent score falls within a range that correlates with a high level of defaults, whether the income level is in a range that correlates with a high level of defaults, whether the property zip code is in an area with high defaults, etc.
FIG. 9 is a functional block diagram illustrating a system 900 for EPD detection such as for use with a mortgage origination system 906. In other embodiments, the system 900 can be used to analyze applications for use in evaluating applications and/or funded loans by an investment bank or servicer, or as part of due diligence of a loan portfolio. System 900 can comprise a mortgage origination system configured to provide mortgage data related to mortgage applications; a risk detection system 902, which can be configured to detect fraud risk associated with the mortgage applications as described with respect to FIGS. 1 and 2; a EPD alert system 901, which can be configured to assess the EPD risk for the mortgage applications; and a model generator 910 that can generate models for use by risk detection system 902 and EPD alert system 901.
The EPD alert system 901 can receive and store data in a storage 904. The storage 904 can comprise one or more database servers and any suitable configuration of volatile and persistent memory. The system 901 can be configured to receive mortgage application data from the mortgage origination system 906 and provide data indicative of fraud and EPD alerts back to the mortgage origination system 906. In one embodiment, the system 901 uses one or more models to generate the data indicative of fraud and EPD risk. In one embodiment, data indicative of fraud and EPD risk can also be provided to a risk manager system 908 for further processing and/or analysis by a human operator. The analysis system 908 can be provided in conjunction with the system 901 or in conjunction with the mortgage origination system 906. In one embodiment, a fraud or other risk detection system 902 can be used in conjunction with, or share databases and other system components with, the EPD alert system 901.
FIG. 10 is a functional block diagram further illustrating an example of the EPD alert system 901. As can be seen, system 901 is similar to system 100, with EPD models 932 replacing the loan models 132 and the introduction of credit data 925. The system 901 can include an origination system interface 922 providing mortgage application data to a data preprocessing module 924. A credit data system 925 can be configured to receive applicant credit data from one or more credit bureaus or from the lender such as via the loan origination system interface 922 to store and provide that data to the EPD alert system 901. The origination system interface 922 can receive data from the mortgage origination system 906 of FIG. 9. In other embodiments, the origination system interface 922 can be configured to receive data associated with funded mortgages and can be configured to interface with suitable systems other than, or in addition to, mortgage origination systems. For example, in one embodiment, the system interface 922 can be configured to receive “bid tapes” or other collections of data associated with funded mortgages for use in evaluating EPD risk associated with a portfolio of funded loans. In one embodiment the origination system interface 922 can comprise a computer network that communicates with the origination system 906 to receive applications in real time or in batches. In one embodiment, the origination system interface 922 receives batches of applications via a data storage medium. The origination system interface 922 can provide application data to the data preprocessing module 924, which formats application data into data formats used internally in the system 901. For example, the origination system interface 922 can also provide data from additional sources such as the lender or directly from credit bureaus that can be in different formats for conversion by the data preprocessing module 924 into the internal data formats of the system 901. The origination system interface 922 and preprocessing module 924 also allow at least portions of a particular embodiment of the system 901 to be used to score EPD risk in different types of mortgage applications and for different loan originators that have varying data and data formats. Table 1 lists examples of mortgage application data that can be used in various embodiments.
The preprocessing module 924 can be configured to identify missing data values and provide data for those missing values to improve further processing. For example, the preprocessing module 924 can generate application data to fill missing data fields using one or more rules. Different rules can be used depending on the loan data supplier, on the particular data field, and/or on the distribution of data for a particular field. For example, for categorical fields, the most frequent value found in historical applications can be used. For numerical fields, the mean or median value of historical applications can be used.
The preprocessing module 924 can also be configured to identify erroneous data or missing data. In one embodiment, the preprocessing module 924 extrapolates missing data based on data from similar applications, or using default data values. The preprocessing module 924 can perform data quality analysis such as one or more of critical error detection, anomaly detection, and data entry error detection.
The data preprocessing module 924 can provide application data to one or more models for EPD risk scoring and processing. In one embodiment, application data is provided to one or more EPD models 932 that generate data indicative of EPD risk based on application and applicant data. The data indicative of EPD risk generated by the EPD models 932 can be provided to an integrator 936 that combines scores from one or more models into a final score. The data preprocessing module 924 can also provide application data to one or more entity models 940 that are configured to identify EPD risk based on data associated with entities involved in the processing of the application. Entity models can include models of data associated with loan brokers, loan officers or other entities involved in a loan application. More examples of such entity models 940 are illustrated with reference to FIG. 4. Each of the entity models can output data to an entity scoring module 950 that is configured to provide a score and/or one or more risk indicators associated with the application data.
The term “risk indicator” refers to data values identified with respect to one or more data fields that can be indicative of EPD risk.
Optionally, the entity scoring module 950 can provide scores associated with one or more risk indicators associated with the particular entity or application. For example, appraisal value in combination with zip code can be a risk indicator associated with an EPD model. In one embodiment, the entity scoring module 950 provides scores and indicators to the integrator 936 to generate a combined EPD risk score and/or set of risk indicators.
The integrator 936 can be configured to apply weights and/or processing rules to generate one or more scores and risk indicators based on the data indicative of EPD risk provided by one or more of the loan models 932, the entity models 940 and entity scoring modules 960. In one embodiment, the risk indicator 936 can generate a single score indicative of EPD risk along with one or more risk indicators relevant for the particular application. Additional scores can also be provided with reference to each of the risk indicators. The integrator 936 can provide this data to a scores and risk indicators module 960 that logs the scores to an output history database 960. In one embodiment, the scores and risk indicators module 960 can identify applications for further review by the risk manager 908 of FIG. 9. Scores can be real or integer values.
In one embodiment, scores are numbers in the range of 1-999. In one embodiment, thresholds are applied to one or more categories to segment scores into high and low risk categories. In one embodiment, thresholds are applied to identify applications for review by the risk manager 908. In one embodiment, risk indicators are represented as codes that are indicative of certain data fields or certain values for data fields. Risk indicators can provide information on the types of EPD risk and recommended actions. For example, risk indicators might include a credit score that falls within high % of default ranges, a high risk of default geographic area, etc. Risk indicators can also be indicative of entity historical transactions, e.g., a CLTV percentage that is indicative of EPD risk.
A score review report module 962 can generate a report in one or more formats based on scores and risk indicators provided by the scores and risk indicators module 960. In one embodiment, the score review report module 962 identifies loan applications for review by the risk manager 908 of FIG. 9. One embodiment desirably improves the efficiency of the risk manager 908 by identifying applications with the highest EPD risk scores or with particular risk indicators for review thereby reducing the number of applications that need to be reviewed. A billing process 966 can be configured to generate billing information based on the results in the output history.
Score review report module 962 can output a score report in several formats. In certain embodiments, the report can include information related to the fraud score as well as the EPD alert score. In other embodiments, only information related to the EPD alert score can be output. In either case, and depending on the embodiment, only the score results, e.g., including risk codes, likely reason codes, suggested action codes, etc., can be output, while in other embodiments this information can be combined with the input information, e.g., from table 1 as well.
In one embodiment, the model generator 910 receives application data, entity data, and data on EPD and non-EPD applications and generates and updates models such as the entity models 940 either periodically or as new data is received.
It is to be recognized that embodiments can combine the functions identified with various blocks of FIGS. 9 and 10 with those of a mortgage fraud detection system 100. In one embodiment, the score review report generator 962 can output reports that include both EPD risk information and data indicative of fraud.
It is to be recognized that depending on the embodiment, certain acts or events of any of the methods described herein can be performed in a different sequence, can be added, merged, or left out all together (e.g., not all described acts or events are necessary for the practice of the method). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors, rather than sequentially.
Those of skill will recognize that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The steps of a method or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal.
While certain embodiments have been described above, it will be understood that the embodiments described are by way of example only. Accordingly, the systems and methods described herein should not be limited based on the described embodiments. Rather, the systems and methods described herein should only be limited in light of the claims that follow when taken in conjunction with the above description and accompanying drawings.

Claims (20)

1. A method for detecting a risk of payment defaults default, comprising:
receiving mortgage data associated with a mortgage application associated with an applicant, the mortgage data including credit information related to the applicant;
determining a score for the mortgage data based at least partly on:
a first model generated based at least partly on data related to a plurality of historical mortgage transactions in which a payment default outcome is known; and
a second model based at least partly on data related to a plurality of historical mortgage transactions associated with a plurality of entities, the second model including at least one cluster associated with historical mortgage transactions associated with at least one of the plurality of entities; and
generating data indicative of a risk of payment default based at least partly on the score,
wherein the method is performed in its entirety by a computing system that comprises one or more computing devices.
2. The method of claim 1, wherein the mortgage data comprises at least one of mortgage application data, funded mortgage data, or bid tapes.
3. The method of claim 1, wherein the credit information comprises information related to at least one of payment history, credit scores, employment, tenure, income, and debt.
4. The method of claim 2, wherein the mortgage application data comprises property valuation information and geographic information.
5. The method of claim 1, wherein the first model is based additionally on geographic default risk information.
6. The method of claim 1, wherein the first model comprises at least one of neural network, logistic regression, linear regression, decision trees, a classification and regression tree (CART) model, a fuzzy logic technique, a support vector machine (SVM) of one or more classes, a Naïve Bayes technique, a boosting tree, a scorecard or an expert system.
7. The method of claim 1, wherein the first model is configured to generate at least one risk indicator of payment default.
8. The method of claim 1, wherein the entities include at least one of an account executive, a broker, a loan officer, or an appraiser.
9. The method of claim 7, wherein generating data indicative of a risk of payment default comprises generating at least one risk indicator associated with an entity associated with the mortgage application.
10. The method of claim 7, wherein the at least one risk indicator is related to at least one of a borrower's risk, a borrower's affordability risk, a property valuation risk, a geographic risk, or a combination thereof.
11. A system for detecting a risk of payment default, comprising:
storage configured to receive mortgage data associated with a mortgage application associated with an applicant, the mortgage data including credit information related to the applicant; and
a processor coupled with the storage, the processor configured to:
determine a score for the mortgage data based at least partly on:
a first model generated based at least partly on data related to a plurality of historical mortgage transactions in which a payment default outcome is known; and
a second model based at least partly on data related to a plurality of historical mortgage transactions associated with a plurality of entities, the second model including at least one cluster associated with historical mortgage transactions associated with at least one of the plurality of entities; and
generate data indicative of a risk of payment default based at least partly on the score.
12. The system of claim 11, wherein the mortgage data comprises at least one of mortgage application data, funded mortgage data, or bid tapes.
13. The system of claim 11, wherein the credit information comprises information related to at least one of payment history, credit scores, employment, tenure, income, and debt.
14. The system of claim 12, wherein the mortgage application data comprises property valuation information and geographic information.
15. The system of claim 11, wherein the first model is based additionally on geographic default risk information.
16. The system of claim 11, wherein the first model comprises at least one of neural network, logistic regression, linear regression, decision trees, a classification and regression tree (CART) model, a fuzzy logic technique, a support vector machine (SVM) of one or more classes, a Naïve Bayes technique, a boosting tree, a scorecard or an expert system.
17. The system of claim 16, wherein the first model is configured to generate at least one risk indicator of payment default.
18. The system of claim 11, wherein the entities include at least one of an account executive, a broker, a loan officer, or an appraiser.
19. The system of claim 17, wherein generating data indicative of a risk of early payment default comprises generating at least one risk indicator associated with an entity associated with the mortgage application.
20. The system of claim 17, wherein the at least one risk indication is related to at least one of a borrower's risk, a borrower's affordability risk, a property valuation risk, a geographic risk, or a combination thereof.
US12/246,407 2006-03-24 2008-10-06 Methods and systems of predicting mortgage payment risk Active 2027-02-18 US7966256B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/246,407 US7966256B2 (en) 2006-09-22 2008-10-06 Methods and systems of predicting mortgage payment risk
US13/162,517 US8065234B2 (en) 2006-03-24 2011-06-16 Methods and systems of predicting mortgage payment risk

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/526,208 US7587348B2 (en) 2006-03-24 2006-09-22 System and method of detecting mortgage related fraud
US97803307P 2007-10-05 2007-10-05
US12/246,407 US7966256B2 (en) 2006-09-22 2008-10-06 Methods and systems of predicting mortgage payment risk

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
US11/526,208 Continuation-In-Part US7587348B2 (en) 2006-03-24 2006-09-22 System and method of detecting mortgage related fraud
US11/526,208 Continuation US7587348B2 (en) 2006-03-24 2006-09-22 System and method of detecting mortgage related fraud

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/162,517 Continuation US8065234B2 (en) 2006-03-24 2011-06-16 Methods and systems of predicting mortgage payment risk

Publications (2)

Publication Number Publication Date
US20090099959A1 US20090099959A1 (en) 2009-04-16
US7966256B2 true US7966256B2 (en) 2011-06-21

Family

ID=40535147

Family Applications (2)

Application Number Title Priority Date Filing Date
US12/246,407 Active 2027-02-18 US7966256B2 (en) 2006-03-24 2008-10-06 Methods and systems of predicting mortgage payment risk
US13/162,517 Active US8065234B2 (en) 2006-03-24 2011-06-16 Methods and systems of predicting mortgage payment risk

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/162,517 Active US8065234B2 (en) 2006-03-24 2011-06-16 Methods and systems of predicting mortgage payment risk

Country Status (1)

Country Link
US (2) US7966256B2 (en)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090271343A1 (en) * 2008-04-25 2009-10-29 Anthony Vaiciulis Automated entity identification for efficient profiling in an event probability prediction system
US20100299244A1 (en) * 2004-02-12 2010-11-25 Williams Iii Roger Howard Systems and methods for implementing an interest-bearing instrument
US20100306029A1 (en) * 2009-06-01 2010-12-02 Ryan Jolley Cardholder Clusters
US20110173116A1 (en) * 2010-01-13 2011-07-14 First American Corelogic, Inc. System and method of detecting and assessing multiple types of risks related to mortgage lending
US20120215565A1 (en) * 2011-02-17 2012-08-23 Washington Survey and Rating Bureau Systems and methods for gathering and storing physical attributes about a physical structure
US8458074B2 (en) 2010-04-30 2013-06-04 Corelogic Solutions, Llc. Data analytics models for loan treatment
US8515863B1 (en) * 2010-09-01 2013-08-20 Federal Home Loan Mortgage Corporation Systems and methods for measuring data quality over time
US20170262761A1 (en) * 2016-03-14 2017-09-14 Huawei Technologies Co., Ltd. System and method for rule generation using data processed by a binary classifier
US20200134716A1 (en) * 2018-10-29 2020-04-30 Flinks Technology Inc. Systems and methods for determining credit worthiness of a borrower
US20210012418A1 (en) * 2009-11-04 2021-01-14 Fair Isaac Corporation Responsibility analytics
US10956974B2 (en) * 2019-05-08 2021-03-23 Toast, Inc. Dynamic origination of capital pricing determination based on forecasted point-of-sale revenue
US11094135B1 (en) 2021-03-05 2021-08-17 Flyreel, Inc. Automated measurement of interior spaces through guided modeling of dimensions
US11100575B2 (en) 2019-05-08 2021-08-24 Toast, Inc. System for automated origination of capital based on point-of-sale data informed by time of year
US11107159B2 (en) 2019-05-08 2021-08-31 Toast, Inc. System for automated origination of capital client engagement based on default probability derived from point-of-sale data
US11532042B2 (en) 2019-05-08 2022-12-20 Toast, Inc. System for automated origination of capital based on point-of-sale data
US11562425B2 (en) 2019-05-08 2023-01-24 Toast, Inc. System for automated origination of capital based on point-of-sale data informed by location

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8732004B1 (en) 2004-09-22 2014-05-20 Experian Information Solutions, Inc. Automated analysis of data to generate prospect notifications based on trigger events
US7711636B2 (en) 2006-03-10 2010-05-04 Experian Information Solutions, Inc. Systems and methods for analyzing data
US8224745B2 (en) * 2006-06-13 2012-07-17 Corelogic Tax Services, Llc Automatic delinquency item processing with customization for lenders
US8036979B1 (en) 2006-10-05 2011-10-11 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US8606666B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US8606626B1 (en) 2007-01-31 2013-12-10 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US20080294540A1 (en) 2007-05-25 2008-11-27 Celka Christopher J System and method for automated detection of never-pay data sets
US8600870B2 (en) * 2007-10-29 2013-12-03 Fair Isaac Corporation Distributed scoring of data transactions
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US20100293091A1 (en) * 2009-05-18 2010-11-18 Kurczodyna Joseph E Method and system for implementing a fast amortization schedule (fas) index mortgage fund
US10089683B2 (en) 2010-02-08 2018-10-02 Visa International Service Association Fraud reduction system for transactions
US20110238566A1 (en) * 2010-02-16 2011-09-29 Digital Risk, Llc System and methods for determining and reporting risk associated with financial instruments
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US8473431B1 (en) 2010-05-14 2013-06-25 Google Inc. Predictive analytic modeling platform
US8438122B1 (en) 2010-05-14 2013-05-07 Google Inc. Predictive analytic modeling platform
US8688477B1 (en) 2010-09-17 2014-04-01 National Assoc. Of Boards Of Pharmacy Method, system, and computer program product for determining a narcotics use indicator
US20120084196A1 (en) * 2010-10-01 2012-04-05 Dennis Capozza Process and System for Producing Default and Prepayment Risk Indices
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
WO2012094393A1 (en) * 2011-01-04 2012-07-12 The Dun And Bradstreet Corporation Method and system for generating an index of performance using non-transactional trade data
US8595154B2 (en) 2011-01-26 2013-11-26 Google Inc. Dynamic predictive modeling platform
US8533222B2 (en) * 2011-01-26 2013-09-10 Google Inc. Updateable predictive analytical modeling
US8458069B2 (en) * 2011-03-04 2013-06-04 Brighterion, Inc. Systems and methods for adaptive identification of sources of fraud
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US8533224B2 (en) 2011-05-04 2013-09-10 Google Inc. Assessing accuracy of trained predictive models
US9361656B2 (en) 2012-01-09 2016-06-07 W. C. Taylor, III Data mining and logic checking tools
US20130218807A1 (en) * 2012-02-06 2013-08-22 Opera Solutions, Llc System and Method for Valuation and Risk Estimation of Mortgage Backed Securities
US8751378B2 (en) * 2012-02-17 2014-06-10 Fair Isaac Corporation Strategic loan default scoring
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US10157418B1 (en) * 2012-12-07 2018-12-18 Capital One Financial Services Systems and computer-implemented processes for occupational risk assessment
CN103218743A (en) * 2013-02-07 2013-07-24 北京税恒科技有限公司 Enterprise tax risk assessment platform
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US20140279380A1 (en) * 2013-03-14 2014-09-18 Fannie Mae Automated searching credit reports to identify potential defaulters
US20190362354A1 (en) * 2013-09-27 2019-11-28 EMC IP Holding Company LLC Real-time updating of predictive analytics engine
US10102536B1 (en) 2013-11-15 2018-10-16 Experian Information Solutions, Inc. Micro-geographic aggregation system
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US9974512B2 (en) 2014-03-13 2018-05-22 Convergence Medical, Llc Method, system, and computer program product for determining a patient radiation and diagnostic study score
US20150269670A1 (en) * 2014-03-21 2015-09-24 Xerox Corporation Method, system, and apparatus for semi-automatic risk and automatic targeting and action prioritization in loan monitoring applications
US9576030B1 (en) 2014-05-07 2017-02-21 Consumerinfo.Com, Inc. Keeping up with the joneses
US20160012544A1 (en) * 2014-05-28 2016-01-14 Sridevi Ramaswamy Insurance claim validation and anomaly detection based on modus operandi analysis
US9959560B1 (en) 2014-08-26 2018-05-01 Intuit Inc. System and method for customizing a user experience based on automatically weighted criteria
US11354755B2 (en) 2014-09-11 2022-06-07 Intuit Inc. Methods systems and articles of manufacture for using a predictive model to determine tax topics which are relevant to a taxpayer in preparing an electronic tax return
US10096072B1 (en) 2014-10-31 2018-10-09 Intuit Inc. Method and system for reducing the presentation of less-relevant questions to users in an electronic tax return preparation interview process
US10255641B1 (en) 2014-10-31 2019-04-09 Intuit Inc. Predictive model based identification of potential errors in electronic tax return
CN105719181A (en) * 2014-12-05 2016-06-29 航天信息股份有限公司 Risk level assessment method and device
US10242019B1 (en) 2014-12-19 2019-03-26 Experian Information Solutions, Inc. User behavior segmentation using latent topic detection
US10628894B1 (en) 2015-01-28 2020-04-21 Intuit Inc. Method and system for providing personalized responses to questions received from a user of an electronic tax return preparation system
US11263600B2 (en) 2015-03-24 2022-03-01 4 S Technologies, LLC Automated trustee payments system
US10176534B1 (en) 2015-04-20 2019-01-08 Intuit Inc. Method and system for providing an analytics model architecture to reduce abandonment of tax return preparation sessions by potential customers
US10740853B1 (en) 2015-04-28 2020-08-11 Intuit Inc. Systems for allocating resources based on electronic tax return preparation program user characteristics
US10740854B1 (en) 2015-10-28 2020-08-11 Intuit Inc. Web browsing and machine learning systems for acquiring tax data during electronic tax return preparation
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US10937109B1 (en) 2016-01-08 2021-03-02 Intuit Inc. Method and technique to calculate and provide confidence score for predicted tax due/refund
US10410295B1 (en) 2016-05-25 2019-09-10 Intuit Inc. Methods, systems and computer program products for obtaining tax data
US20180053105A1 (en) * 2016-08-18 2018-02-22 Paypal, Inc. Model Training for Multiple Data Spaces for Pattern Classification and Detection
US10678894B2 (en) 2016-08-24 2020-06-09 Experian Information Solutions, Inc. Disambiguation and authentication of device users
WO2018144612A1 (en) 2017-01-31 2018-08-09 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US10789643B1 (en) * 2017-10-30 2020-09-29 Intuit Inc. Accountant account takeover fraud detection
US11042930B1 (en) * 2018-03-20 2021-06-22 Intuit, Inc. Insufficient funds predictor
CN108846520B (en) * 2018-06-22 2021-08-03 京东数字科技控股有限公司 Loan overdue prediction method, loan overdue prediction device and computer-readable storage medium
US11620403B2 (en) 2019-01-11 2023-04-04 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation
CA3132055A1 (en) * 2019-03-01 2020-09-10 Mastercard Technologies Canada ULC Online application origination (oao) service for fraud prevention systems
CN110097452A (en) * 2019-04-01 2019-08-06 北京羽乐创新科技有限公司 Number appraisal procedure and device
CN110349012A (en) * 2019-07-12 2019-10-18 腾讯科技(深圳)有限公司 Data predication method and computer readable storage medium
US20210241279A1 (en) * 2020-02-05 2021-08-05 International Business Machines Corporation Automatic fraud detection
US20220076330A1 (en) * 2020-09-08 2022-03-10 Agora Intelligence, Inc. Method, apparatus, and computer readable medium for generating a real-time risk score associated with financing of an invoice based on real-time transaction data
CN112668886A (en) * 2020-12-29 2021-04-16 深圳前海微众银行股份有限公司 Method, device and equipment for monitoring risks of rental business and readable storage medium
CN112819631B (en) * 2021-02-10 2023-12-08 招联消费金融有限公司 Service data processing method, device, computer equipment and storage medium
US11681966B2 (en) 2021-02-24 2023-06-20 Fannie Mae Systems and methods for enhanced risk identification based on textual analysis

Citations (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1252566A (en) 1985-05-02 1989-04-11 Vincent Boston Transaction system with off-line risk assessment
CA2052033A1 (en) 1990-11-09 1992-05-10 Carl A. Adams Transaction approval system
CA2032126A1 (en) 1990-01-31 1993-08-17 John S. Denker Hierarchical constrained automatic learning network for character recognition
US5819226A (en) 1992-09-08 1998-10-06 Hnc Software Inc. Fraud detection using predictive modeling
US6134532A (en) 1997-11-14 2000-10-17 Aptex Software, Inc. System and method for optimal adaptive matching of users to most relevant entity and information in real-time
US6185543B1 (en) * 1998-05-15 2001-02-06 Marketswitch Corp. Method and apparatus for determining loan prepayment scores
WO2001077959A1 (en) 2000-04-06 2001-10-18 Hnc Software, Inc. Identification and management of fraudulent credit/debit card purchases at merchant ecommerce sites
US20020052836A1 (en) 2000-08-31 2002-05-02 Yuri Galperin Method and apparatus for determining a prepayment score for an individual applicant
WO2002037219A2 (en) 2000-11-02 2002-05-10 Cybersource Corporation Method and apparatus for evaluating fraud risk in an electronic commerce transaction
US6430539B1 (en) 1999-05-06 2002-08-06 Hnc Software Predictive modeling of consumer financial behavior
US20020133721A1 (en) 2001-03-15 2002-09-19 Akli Adjaoute Systems and methods for dynamic detection and prevention of electronic fraud and network intrusion
US20020133371A1 (en) 2001-01-24 2002-09-19 Cole James A. Automated mortgage fraud prevention method and system
WO2002097563A2 (en) 2001-05-30 2002-12-05 Cybersource Corporation Method and apparatus for evaluating fraud risk in an electronic commerce transaction
US20030093366A1 (en) 2001-11-13 2003-05-15 Halper Steven C. Automated loan risk assessment system and method
US20040010443A1 (en) * 2002-05-03 2004-01-15 May Andrew W. Method and financial product for estimating geographic mortgage risk
US6728695B1 (en) 2000-05-26 2004-04-27 Burning Glass Technologies, Llc Method and apparatus for making predictions about entities represented in documents
US20040138993A1 (en) 1995-09-12 2004-07-15 Defrancesco James Computer implemented automated credit application analysis and decision routing system
EP1450321A1 (en) 2003-02-21 2004-08-25 Swisscom Mobile AG Method and system for detecting possible fraud in paying transactions
US20040236696A1 (en) 2003-05-23 2004-11-25 Intelligent Wave, Inc. History information adding program, fraud determining program using history information, and fraud determining system using history information
US20050108025A1 (en) 2003-11-14 2005-05-19 First American Real Estate Solutions, L.P. Method for mortgage fraud detection
US20060059073A1 (en) 2004-09-15 2006-03-16 Walzak Rebecca B System and method for analyzing financial risk
US20060149674A1 (en) 2004-12-30 2006-07-06 Mike Cook System and method for identity-based fraud detection for transactions using a plurality of historical identity records
WO2007002702A2 (en) 2005-06-24 2007-01-04 Fair Isaac Corporation Mass compromise / point of compromise analytic detection and compromised card portfolio management system
US7392216B1 (en) 2000-09-27 2008-06-24 Ge Capital Mortgage Corporation Methods and apparatus for utilizing a proportional hazards model to evaluate loan risk

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6119103A (en) * 1997-05-27 2000-09-12 Visa International Service Association Financial risk prediction systems and methods therefor
CA2565481A1 (en) 2004-05-07 2005-11-17 Etracka Pty Ltd Loan simulation method and system
US7958048B2 (en) 2006-06-30 2011-06-07 Corelogic Information Solutions, Inc. Method and apparatus for predicting outcomes of a home equity line of credit

Patent Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1252566A (en) 1985-05-02 1989-04-11 Vincent Boston Transaction system with off-line risk assessment
CA2032126A1 (en) 1990-01-31 1993-08-17 John S. Denker Hierarchical constrained automatic learning network for character recognition
CA2052033A1 (en) 1990-11-09 1992-05-10 Carl A. Adams Transaction approval system
US5819226A (en) 1992-09-08 1998-10-06 Hnc Software Inc. Fraud detection using predictive modeling
US6330546B1 (en) 1992-09-08 2001-12-11 Hnc Software, Inc. Risk determination and management using predictive modeling and transaction profiles for individual transacting entities
US20040138993A1 (en) 1995-09-12 2004-07-15 Defrancesco James Computer implemented automated credit application analysis and decision routing system
US6134532A (en) 1997-11-14 2000-10-17 Aptex Software, Inc. System and method for optimal adaptive matching of users to most relevant entity and information in real-time
US6185543B1 (en) * 1998-05-15 2001-02-06 Marketswitch Corp. Method and apparatus for determining loan prepayment scores
US6839682B1 (en) 1999-05-06 2005-01-04 Fair Isaac Corporation Predictive modeling of consumer financial behavior using supervised segmentation and nearest-neighbor matching
US6430539B1 (en) 1999-05-06 2002-08-06 Hnc Software Predictive modeling of consumer financial behavior
US7165037B2 (en) 1999-05-06 2007-01-16 Fair Isaac Corporation Predictive modeling of consumer financial behavior using supervised segmentation and nearest-neighbor matching
WO2001077959A1 (en) 2000-04-06 2001-10-18 Hnc Software, Inc. Identification and management of fraudulent credit/debit card purchases at merchant ecommerce sites
US6728695B1 (en) 2000-05-26 2004-04-27 Burning Glass Technologies, Llc Method and apparatus for making predictions about entities represented in documents
US20020052836A1 (en) 2000-08-31 2002-05-02 Yuri Galperin Method and apparatus for determining a prepayment score for an individual applicant
US7392216B1 (en) 2000-09-27 2008-06-24 Ge Capital Mortgage Corporation Methods and apparatus for utilizing a proportional hazards model to evaluate loan risk
WO2002037219A2 (en) 2000-11-02 2002-05-10 Cybersource Corporation Method and apparatus for evaluating fraud risk in an electronic commerce transaction
US20020133371A1 (en) 2001-01-24 2002-09-19 Cole James A. Automated mortgage fraud prevention method and system
US20020133721A1 (en) 2001-03-15 2002-09-19 Akli Adjaoute Systems and methods for dynamic detection and prevention of electronic fraud and network intrusion
US20020194119A1 (en) 2001-05-30 2002-12-19 William Wright Method and apparatus for evaluating fraud risk in an electronic commerce transaction
WO2002097563A2 (en) 2001-05-30 2002-12-05 Cybersource Corporation Method and apparatus for evaluating fraud risk in an electronic commerce transaction
US20030093366A1 (en) 2001-11-13 2003-05-15 Halper Steven C. Automated loan risk assessment system and method
US20040010443A1 (en) * 2002-05-03 2004-01-15 May Andrew W. Method and financial product for estimating geographic mortgage risk
EP1450321A1 (en) 2003-02-21 2004-08-25 Swisscom Mobile AG Method and system for detecting possible fraud in paying transactions
US20040236696A1 (en) 2003-05-23 2004-11-25 Intelligent Wave, Inc. History information adding program, fraud determining program using history information, and fraud determining system using history information
US20050108025A1 (en) 2003-11-14 2005-05-19 First American Real Estate Solutions, L.P. Method for mortgage fraud detection
US20060059073A1 (en) 2004-09-15 2006-03-16 Walzak Rebecca B System and method for analyzing financial risk
US20060149674A1 (en) 2004-12-30 2006-07-06 Mike Cook System and method for identity-based fraud detection for transactions using a plurality of historical identity records
WO2007002702A2 (en) 2005-06-24 2007-01-04 Fair Isaac Corporation Mass compromise / point of compromise analytic detection and compromised card portfolio management system

Non-Patent Citations (17)

* Cited by examiner, † Cited by third party
Title
""Formula by example" software expands analysis power of Lotus 1-2-3 for Windows", dated Nov. 11, 1991, News Release, p. 1, Wes Thomas, Thomas Public Relations. *
"Fraud Detection in the Financial Industry", A SAS Institute Best Practices Paper, 32 pages.
"New Business Uses for Neurocomputing", I/S Analyzer, Feb. 1990, vol. 28, No. 2, 15 pages.
Congressional Testimony of Chris Swecker, Assistant Director, Criminal Investigative Division, Federal Bureau of Investigation, before the House Financial Services Subcommittee on Housing and Community Opportunity, Oct. 7, 2004, 5 pages.
Garavaglia, Susan, "An Application of a Counter-Propagation Neural Network: Simulating the Standard & Poor's Corporate Bond Rating System", IEEE 1991, pp. 278-287.
Ghosh, Sushmito and Reilly, Douglas L., "Credit Card Fraud Detection with a Neural-Network", IEEE 1994, pp. 621-630.
J. Killin. "Combatting credit card fraud with knowledge based systems." In Compsec 90 International. Elsevier Advanced Technology, Oxford, Oct. 1990.
Klimasauskas, Casimir C., "Applying Neural Networks Part 1: An Overview of the Series", PC Al, Jan. Feb. 1991, pp. 30-33.
Klimasauskas, Casimir C., "Applying Neural Networks Part 2: A Walk Through the Application Process", PC Al, Mar./Apr. 1991, pp. 27-34.
Klimasauskas, Casimir C., "Applying Neural Networks Part III: Training a Neural Network", PC Al, May/Jun. 1991, pp. 20-24.
Klimasauskas, Casimir C., "Applying Neural Networks Part IV: Improving Performance", PC Al Jul./Aug. 1991, pp. 34-41.
Klimasauskas, Casimir C., "Applying Neural Networks Part V: Integrating a Trained Network into an Application", PC Al Sep./Oct. 1991, pp. 36-41.
Klimasauskas, Casimir C., "Applying Neural Networks Part VI: Special Topics", PC Al Nov./Dec. 1991, pp. 46-49.
Klimasauskas, Casimir C., "Neural Networks: A Short Course", PC Al, Nov./Dec. 1988, pp. 26-30.
Neal, Mark, Hunt, John and Timmis, Jon, "Augmenting an Artificial Immune Network", IEEE 1998, pp. 3821-3826.
PCT Search Report of PCT/US08/78987.
Search Report for GB0705653.4 dated Jun. 22, 2007, 4 pages.

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299244A1 (en) * 2004-02-12 2010-11-25 Williams Iii Roger Howard Systems and methods for implementing an interest-bearing instrument
US8452700B2 (en) * 2004-02-12 2013-05-28 Roger Howard Williams, III Systems and methods for implementing an interest-bearing instrument
US8121962B2 (en) * 2008-04-25 2012-02-21 Fair Isaac Corporation Automated entity identification for efficient profiling in an event probability prediction system
US20090271343A1 (en) * 2008-04-25 2009-10-29 Anthony Vaiciulis Automated entity identification for efficient profiling in an event probability prediction system
US20100306029A1 (en) * 2009-06-01 2010-12-02 Ryan Jolley Cardholder Clusters
US20210012418A1 (en) * 2009-11-04 2021-01-14 Fair Isaac Corporation Responsibility analytics
US20110173116A1 (en) * 2010-01-13 2011-07-14 First American Corelogic, Inc. System and method of detecting and assessing multiple types of risks related to mortgage lending
US8489499B2 (en) 2010-01-13 2013-07-16 Corelogic Solutions, Llc System and method of detecting and assessing multiple types of risks related to mortgage lending
US8639618B2 (en) 2010-01-13 2014-01-28 Corelogic Solutions, Llc System and method of detecting and assessing multiple types of risks related to mortgage lending
US8775300B2 (en) 2010-04-30 2014-07-08 Corelogic Solutions, Llc Data analytics models for loan treatment
US8458074B2 (en) 2010-04-30 2013-06-04 Corelogic Solutions, Llc. Data analytics models for loan treatment
US9747639B1 (en) * 2010-09-01 2017-08-29 Federal Home Loan Mortgage Corporation (Freddie Mac) Systems and methods for measuring data quality over time
US11556983B1 (en) 2010-09-01 2023-01-17 Federal Home Loan Mortgage Corporation (Freddie Mac) Systems and methods for measuring data quality over time
US11017467B1 (en) 2010-09-01 2021-05-25 Federal Home Loan Mortgage Corporation (Freddie Mac) Systems and methods for measuring data quality over time
US8515863B1 (en) * 2010-09-01 2013-08-20 Federal Home Loan Mortgage Corporation Systems and methods for measuring data quality over time
US20120215565A1 (en) * 2011-02-17 2012-08-23 Washington Survey and Rating Bureau Systems and methods for gathering and storing physical attributes about a physical structure
US10824951B2 (en) * 2016-03-14 2020-11-03 Huawei Technologies Co., Ltd. System and method for rule generation using data processed by a binary classifier
US20170262761A1 (en) * 2016-03-14 2017-09-14 Huawei Technologies Co., Ltd. System and method for rule generation using data processed by a binary classifier
US20200134716A1 (en) * 2018-10-29 2020-04-30 Flinks Technology Inc. Systems and methods for determining credit worthiness of a borrower
US10956974B2 (en) * 2019-05-08 2021-03-23 Toast, Inc. Dynamic origination of capital pricing determination based on forecasted point-of-sale revenue
US11100575B2 (en) 2019-05-08 2021-08-24 Toast, Inc. System for automated origination of capital based on point-of-sale data informed by time of year
US11107159B2 (en) 2019-05-08 2021-08-31 Toast, Inc. System for automated origination of capital client engagement based on default probability derived from point-of-sale data
US11532042B2 (en) 2019-05-08 2022-12-20 Toast, Inc. System for automated origination of capital based on point-of-sale data
US11562425B2 (en) 2019-05-08 2023-01-24 Toast, Inc. System for automated origination of capital based on point-of-sale data informed by location
US11094135B1 (en) 2021-03-05 2021-08-17 Flyreel, Inc. Automated measurement of interior spaces through guided modeling of dimensions
US11682174B1 (en) 2021-03-05 2023-06-20 Flyreel, Inc. Automated measurement of interior spaces through guided modeling of dimensions

Also Published As

Publication number Publication date
US20090099959A1 (en) 2009-04-16
US8065234B2 (en) 2011-11-22
US20110251945A1 (en) 2011-10-13

Similar Documents

Publication Publication Date Title
US7966256B2 (en) Methods and systems of predicting mortgage payment risk
US7587348B2 (en) System and method of detecting mortgage related fraud
US8639618B2 (en) System and method of detecting and assessing multiple types of risks related to mortgage lending
US7974854B1 (en) Systems and methods for retrospective home value scoring
US8799150B2 (en) System and method for predicting consumer credit risk using income risk based credit score
US7987124B1 (en) Method of and system for evaluating an appraisal value associated with a loan
US7693782B1 (en) Method and system for evaluating a loan
US20080059364A1 (en) Systems and methods for performing a financial trustworthiness assessment
Nichols et al. Borrower self-selection, underwriting costs, and subprime mortgage credit supply
US7885892B1 (en) Method and system for assessing repurchase risk
US7739189B1 (en) Method and system for detecting loan fraud
Al-Shakrchy The impact of credit risk managing on bank profitability an empirical study during the pre-and post-subprime mortgage crisis: The case of Swedish commercial banks
AU2008311048A1 (en) Methods and systems of predicting mortgage payment risk
Ambrose et al. Legal restrictions in personal loan markets
Ohlrogge Bank capital and risk taking: A loan level analysis
Lee et al. Credit, equity conversion, and housing endowment: analysis of reverse mortgage markets
Nguyen How is credit scoring used to predict default in China?
AU2014200174A1 (en) Methods and systems of predicting mortgage payment risk
Mwangangi An analysis of the efficacy of borrower credit scores in predicting credit repayment performance: a case study in agricultural finance corporation-AFC
Verma Predicting Default of Indian Corporate Sector
Ntuli Predicting financial distress in South Africa: the role of macroeconomic factors
Γιαννούλη Research topics on credit risk management
Marouani Predicting Default Probability Using Delinquency: The Case of French Small Businesses
Kula Determinants of default in P2P property-backed loans
Dorothea The use of credit scoring systems in measuring credibility: the case of greek companies

Legal Events

Date Code Title Description
AS Assignment

Owner name: BASEPOINT ANALYTICS LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIAO, YUANSONG;YAN, RUI;REEL/FRAME:022022/0064;SIGNING DATES FROM 20081218 TO 20081222

Owner name: BASEPOINT ANALYTICS LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIAO, YUANSONG;YAN, RUI;SIGNING DATES FROM 20081218 TO 20081222;REEL/FRAME:022022/0064

AS Assignment

Owner name: JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT,TEX

Free format text: SECURITY AGREEMENT;ASSIGNOR:FIRST AMERICAN CORELOGIC, INC.;REEL/FRAME:024529/0157

Effective date: 20100602

Owner name: JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT, TE

Free format text: SECURITY AGREEMENT;ASSIGNOR:FIRST AMERICAN CORELOGIC, INC.;REEL/FRAME:024529/0157

Effective date: 20100602

AS Assignment

Owner name: FIRST AMERICAN CORELOGIC, INC., CALIFORNIA

Free format text: MERGER;ASSIGNOR:BASEPOINT ANALYTICS LLC;REEL/FRAME:025318/0632

Effective date: 20090731

Owner name: CORELOGIC INFORMATION SOLUTIONS, INC., CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:FIRST AMERICAN CORELOGIC, INC.;REEL/FRAME:025318/0625

Effective date: 20100820

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH

Free format text: SECURITY AGREEMENT;ASSIGNOR:CORELOGIC INFORMATION SOLUTIONS, INC.;REEL/FRAME:026499/0118

Effective date: 20110523

AS Assignment

Owner name: CORELOGIC SOLUTIONS, LLC, CALIFORNIA

Free format text: MERGER;ASSIGNOR:CORELOGIC INFORMATION SOLUTIONS, INC.;REEL/FRAME:027880/0674

Effective date: 20111216

AS Assignment

Owner name: BANK OF AMERICA, N.A., TEXAS

Free format text: SECURITY INTEREST;ASSIGNOR:CORELOGIC SOLUTIONS, LLC;REEL/FRAME:032798/0047

Effective date: 20140404

AS Assignment

Owner name: CORELOGIC SOLUTIONS, LLC (F/K/A/ FIRST AMERICAN CO

Free format text: NOTICE OF RELEASE OF PATENT SECURITY INTEREST;ASSIGNOR:JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:032815/0317

Effective date: 20140429

AS Assignment

Owner name: CORELOGIC INFORMATION RESOURCES, LLC (F/K/A CORELO

Free format text: RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033034/0292

Effective date: 20140404

Owner name: CORELOGIC REAL ESTATE INFORMATION SERVICES, LLC (F

Free format text: RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033034/0292

Effective date: 20140404

Owner name: CORELOGIC, INC. (F/K/A FIRST AMERICAN CORPORATION)

Free format text: RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033034/0292

Effective date: 20140404

Owner name: CORELOGIC SOLUTIONS, LLC (F/K/A MARKETLINX, INC. A

Free format text: RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033034/0292

Effective date: 20140404

Owner name: CORELOGIC VALUATION SERVICES, LLC (F/K/A EAPPRAISE

Free format text: RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033034/0292

Effective date: 20140404

Owner name: CORELOGIC TAX SERVICES, LLC, CALIFORNIA

Free format text: RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033034/0292

Effective date: 20140404

Owner name: CORELOGIC DORADO, LLC (F/K/A CORELOGIC DORADO CORP

Free format text: RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033034/0292

Effective date: 20140404

AS Assignment

Owner name: CORELOGIC DORADO, LLC (F/K/A CORELOGIC DORADO CORP

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE FROM 04/04/2014 TO 04/09/2014 PREVIOUSLY RECORDED ON REEL 033034 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033198/0553

Effective date: 20140409

Owner name: CORELOGIC, INC. (F/K/A FIRST AMERICAN CORPORATION)

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE FROM 04/04/2014 TO 04/09/2014 PREVIOUSLY RECORDED ON REEL 033034 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033198/0553

Effective date: 20140409

Owner name: CORELOGIC INFORMATION RESOURCES, LLC (F/K/A CORELO

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE FROM 04/04/2014 TO 04/09/2014 PREVIOUSLY RECORDED ON REEL 033034 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033198/0553

Effective date: 20140409

Owner name: CORELOGIC SOLUTIONS, LLC (F/K/A MARKETLINX, INC. A

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE FROM 04/04/2014 TO 04/09/2014 PREVIOUSLY RECORDED ON REEL 033034 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033198/0553

Effective date: 20140409

Owner name: CORELOGIC VALUATION SERVICES, LLC (F/K/A EAPPRAISE

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE FROM 04/04/2014 TO 04/09/2014 PREVIOUSLY RECORDED ON REEL 033034 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033198/0553

Effective date: 20140409

Owner name: CORELOGIC REAL ESTATE INFORMATION SERVICES, LLC (F

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE FROM 04/04/2014 TO 04/09/2014 PREVIOUSLY RECORDED ON REEL 033034 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033198/0553

Effective date: 20140409

Owner name: CORELOGIC TAX SERVICES, LLC, CALIFORNIA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE FROM 04/04/2014 TO 04/09/2014 PREVIOUSLY RECORDED ON REEL 033034 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITY INTERESTS RECORDED PRIOR TO JUNE 25, 2011;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AND COLLATERAL AGENT;REEL/FRAME:033198/0553

Effective date: 20140409

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

AS Assignment

Owner name: CORELOGIC SOLUTIONS, LLC, CALIFORNIA

Free format text: RELEASE OF SECURITY INTEREST RECORDED AT 032798/0047;ASSIGNOR:BANK OF AMERICA, N.A.;REEL/FRAME:056493/0957

Effective date: 20210604

AS Assignment

Owner name: U.S. BANK NATIONAL ASSOCIATION, OREGON

Free format text: SECURITY INTEREST;ASSIGNORS:CDS BUSINESS MAPPING, LLC;CLAREITY SECURITY, LLC;CORELOGIC CREDCO, LLC;AND OTHERS;REEL/FRAME:056539/0146

Effective date: 20210604

Owner name: ARES CAPITAL CORPORATION, NEW YORK

Free format text: SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:CDS BUSINESS MAPPING, LLC;CLAREITY SECURITY, LLC;CORELOGIC CREDCO, LLC;AND OTHERS;REEL/FRAME:056539/0227

Effective date: 20210604

Owner name: JPMORGAN CHASE BANK, N.A., OHIO

Free format text: FIRST LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:CDS BUSINESS MAPPING, LLC;CLAREITY SECURITY, LLC;CORELOGIC CREDCO, LLC;AND OTHERS;REEL/FRAME:056539/0241

Effective date: 20210604

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12