US20100241558A1 - Mortgage fraud detection systems and methods - Google Patents

Mortgage fraud detection systems and methods Download PDF

Info

Publication number
US20100241558A1
US20100241558A1 US12/481,546 US48154609A US2010241558A1 US 20100241558 A1 US20100241558 A1 US 20100241558A1 US 48154609 A US48154609 A US 48154609A US 2010241558 A1 US2010241558 A1 US 2010241558A1
Authority
US
United States
Prior art keywords
data
records
information
database
loan
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.)
Abandoned
Application number
US12/481,546
Inventor
Thomas Chmielewski
Denise James
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.)
LexisNexis Risk Solutions Inc
LexisNexis Inc
ChoicePoint Asset Co LLC
Original Assignee
LexisNexis 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
Application filed by LexisNexis Inc filed Critical LexisNexis Inc
Priority to US12/481,546 priority Critical patent/US20100241558A1/en
Assigned to CHOICEPOINT ASSET COMPANY reassignment CHOICEPOINT ASSET COMPANY ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHMIELEWSKI, THOMAS, JAMES, DENISE
Publication of US20100241558A1 publication Critical patent/US20100241558A1/en
Assigned to CHOICEPOINT SERVICES, INC. reassignment CHOICEPOINT SERVICES, INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: CHOICEPOINT ASSET COMPANY LLC
Assigned to LEXISNEXIS RISK SOLUTIONS INC. reassignment LEXISNEXIS RISK SOLUTIONS INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: CHOICEPOINT SERVICES INC.
Abandoned legal-status Critical Current

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
    • 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
    • G06Q30/00Commerce
    • G06Q30/018Certifying business or products
    • G06Q30/0185Product, service or business identity fraud
    • 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03Credit; Loans; Processing thereof
    • 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
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/16Real estate
    • 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
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/18Legal services

Definitions

  • the various embodiments of the present invention relate generally to database and information management systems and, more particularly, to fraud detection database systems and methods to assist users to detect mortgage fraud as well as other types of financial fraud that may occur in a financial application process.
  • Mortgage fraud typically occurs in two ways: fraud for profit and fraud for housing or property. Fraud for profit schemes typically result in ill-gotten gains from falsified or fraudulent loan transactions and usually involve industry insiders well versed in the funding process. The insiders that are typically parties to fraudulent schemes make it challenging to uncover fraudulent activities. Financial losses stemming from this type of fraudulent activity can be significant and devastating to industry participants. Examples of insider contributed fraud include, but are not limited to, illegal flipping, straw buyer scams, equity skimming, and fraudulent property investments.
  • Fraud for housing or property generally involves factual misstatements to obtain a property as a primary residence. This type of fraud contributes to the greatest amount of reported fraud. Common misstatements include embellishing salary or income amounts and undisclosed borrowed funds or employment terms. Borrowers are often coached by insiders so that reported data is represented more favorably and appears less risky to lenders.
  • common mortgage application fraud plots include equity skimming/foreclosure bailout schemes, churning, chunking, shot-gunning, silent second, property flipping, double escrow, straw-buying, air loans, identification theft, asset rentals, mortgage elimination schemes, cash-back schemes, and non-arm's length transactions.
  • Mortgage fraud can also occur in ways different from those discussed above. Indeed other types of encountered examples include: misrepresentations on a mortgage application, inflated appraisals, appraisals with inappropriate comparables, employment and/or income misrepresentation (for example, on pay stubs, W-2s, tax returns, or Verifications of Employment), failure to disclose debts and/or other liabilities, failure to disclose correct employment status, use of invalid borrower SSNs, fabricated or misrepresented monthly housing payments (e.g., rent or mortgage payments), falsified bank statements or accounts, falsified gift letters, occupancy misrepresentation (e.g., primary residence vs. investment property), incorrect transaction type (e.g., purchase vs. refinance), borrower and/or seller not properly listed on property title, misrepresented closing costs, or closing funds distributed to unauthorized parties, misrepresented down payments, and unauthorized activity by unlicensed professionals.
  • misrepresentations on a mortgage application inflated appraisals, appraisals with inappropriate comparables, employment and/or income misrepresentation (for example, on
  • various embodiments of the present invention generally comprise a fraud detection database, a fraud detection database system for detecting signs of fraud, and methods for analyzing various data resources to detect fraud.
  • Fraud detection may occur in mortgage loan applications as well as many other financial applications (e.g., auto loan, credit card, and many other personal property loans).
  • System users such as lenders, can submit loan application data to a fraud detection system.
  • Loan application data can include information from a borrower's mortgage loan application, such as information entered on a Uniform Residential Loan Application (Form 1003).
  • Other submitted information may also include additional information from lenders and originator information, information on brokers, realtors, or appraisers involved in the borrower's transaction.
  • Detecting fraud through a database system can generally comprise providing a database for storing and/or maintaining a set of records.
  • the records can include various types of financial information.
  • a database operator can access, receive, and/or utilize financial information records from a plurality of sources including pre-existing databases and/or lending institutions.
  • a database operator can configure a fraud detection system to compare a first data record to a second data record to determine whether the two records are preliminary matches.
  • the first data record may be received from a lending institution and the second data record may include pre-existing stored data. Records can be preliminary matches if they have certain data in common.
  • the data can include any one or more of borrower names, borrower SSNs, and real property addresses for which a mortgage loan is requested.
  • Preliminary matches can also be compared for inconsistent information for fraud detection. If inconsistent information is found, the inconsistent preliminarily matching records may be flagged.
  • the inconsistent information need not be the same category of information examined to determine preliminary matching. For example, two application data sets with the same borrower name or property address but with different appraisal values can be flagged in the database.
  • Embodiments of the present invention also enable report generation so that end users can review results of data analysis.
  • end users may be system subscribers that submitted one or more data records to a fraud detection system. Reports preferably show results of data comparisons in a format easily and readily understood by end users.
  • fraud detection embodiments of the present invention are configured to receive input data records. Such data input can be provided by end users who are using embodiments of the present invention to detect fraud in a financial loan environment. As records are received from end users, received records can be compared with other records. Comparisons can be made initially upon receipt and also conducted at predetermined frequencies to continue monitoring for possible fraudulent activities.
  • records can undergo one or more waiting periods between comparisons. Waiting periods can be many time periods, for example, approximately one day, such that a set of comparisons occurs daily for each record. During waiting periods, additional records can be received. At the end of a waiting period, a first received record can be compared to one or more second records. Based on these new comparisons, reports can be generated for subscribers. Reports can contain analysis of records submitted after a first record and during the course of receiving additional records. This feature of embodiments of the present invention enables continuous monitoring of loan transaction to detect fraudulent activities occurring within close time periods. Comparisons can occur periodically by repeatedly comparing already received records to newly received records.
  • Periodic comparisons can continue until the termination of a predetermined holding period.
  • received records can be retained in a database in an active state, meaning periodic comparisons continue.
  • the holding period can be, for example, approximately 30 days to approximately 90 days in some embodiments.
  • each stored or received record can be compared daily to other stored or received records for 61 days after the record is submitted to a database operator or entered into the database.
  • Other holding period lengths may also be used in accordance with embodiments of the present invention (for example, ranging between 120 days to twelve months).
  • fraud detection system embodiments of the present invention can be configured to receive a plurality of records from a plurality of users (e.g., contributory subscribers). Periodically in bulk, or individually as they are received, records are stored in a database. After a new record is received, it can be compared to records preexisting in the database. A database operator alone or in combination with a reporting program can report comparison results to subscribers submitting records and to subscribers that records submitted records preexisting in the database. The results in such reports can be ordered according to a two-tier weighted algorithm.
  • a database operator need not be a human being.
  • the database operator can be a computer system, a computer program, one or more modules of a computer system, or a combination thereof.
  • a receiving module can receive records submitted from outside sources, including system subscribers or end users.
  • a comparing module can compare records to each other.
  • a reporting module can report results to subscribers.
  • a database operating module can conduct one or more of the tasks performed by the database operator.
  • Operations of the database operator and of the database system can be performed by a computer system. Accordingly, such operations can be stored on a computer-readable medium of expression, and performed by a computer processor.
  • the various modules discussed herein can be implemented as hardware, software, or a combination thereof.
  • a fraud detection system to detect fraud in a financial loan application process by analyzing a plurality of data from multiple sources.
  • the system can generally comprise one or more interfaces (e.g., communication interfaces) to receive data, a database, and a processing module.
  • the interfaces can be configured to receive data from a plurality of unique data sources.
  • the data sources can comprise information received from unique end users and existing unique databases.
  • the data can comprise data records comprising at least one of information related to a financial loan application, parties involved in a loan transaction, and property involved in a financial loan.
  • the database can be configured to receive data from a plurality of unique data sources and to store data with an identifier configured to distinguish data received from unique data sources.
  • the database can include a processing module or may be operatively coupled to a processor configured to implement a processing module.
  • the processing module can be configured to determine if one or more data records contain one or more matching data fields and flag data records containing one or more matching data fields. Matching information can be stored in a match table, which can be a stand alone memory or associated with the database.
  • the processing module can be further configured to determine if one or more of flagged data records contain different information in one or more other data fields contained in the data records. And data records flagged to contain different information can be stored in the match table.
  • matching data fields can comprise information about property involved in a financial loan and at least a party involved in a loan transaction.
  • a system can also include a reporting module configured to report information concerning data records containing one or more matching data fields and information concerning the flagged data records containing different information in the one or more predetermined data fields.
  • a reporting module can be further configured to order information contained in a report at least partially based on different information contained in the one or more data fields and a magnitude of difference.
  • a processing module further can be configured to place received data records in an active state for a predetermined holding period and periodically analyze active-state data records relative to existing data and data received after the active-state data records. Predetermined holding periods can range from approximately one day to approximately one year.
  • a processing module can be configured to determine if one or more of data records contain substantially similar addresses for a real estate property involved in a loan transaction.
  • a fraud detection method can generally comprise providing a database operatively configured to receive data comprising details concerning a financial credit or loan application and to store received data as one or more first data records.
  • a fraud detection method can also include configuring a database to receive data from a plurality of unique data sources and store data with an identifier for distinguishing the unique data sources. The data can comprise at least one of, one or more parties involved in a loan transaction, and property involved in a financial application process.
  • a fraud detection method can also include providing a data comparison module operatively configured to flag the one or more first data records containing similar data in one or more predetermined data fields by storing matching information in a table. Also, a fraud detection method can include configuring a data comparison module to determine if the flagged data records comprising at least one data field with similar data comprise one or more other data fields having inconsistent data by storing inconsistent data in the table.
  • a method can include configuring a database to provide reports comprising details related to flagged data records comprising at least one data field with similar data and details related to flagged data records comprising data fields with inconsistent data.
  • a method can also include configuring a database to receive data from a plurality of end users and the one or more databases via a communications network.
  • a method can also include providing a data comparison module operatively configured to flag data records containing similar data in one or more predetermined data fields by determining if the one or more data records contain data fields having similar property address information or similar borrower information.
  • a method can include configuring a database to provide reports to a user with data ordered based on results of a two-tier weighted algorithm. Also, a method can include holding data records in the database for a predetermined holding period and configuring the data comparison module to compare existing data records to data records received after the existing data records at predefined intervals. A method can also include operatively configuring a database to receive lender originated data and user incident report data. In addition a method can include configuring a data comparison module to receive professional license information from one or more existing databases to determine if a licensed party involved in a loan transaction is properly licensed and has any past professional sanctions.
  • computer-readable media containing code for execution by a processor are provided. These embodiments can include stored computer readable instructions to execute a method for detecting fraud and/or implement a system for detecting fraud.
  • code can include instructions for providing a database configured to receive data from a plurality of unique data sources and associate received data with an identifier to distinguish the unique data sources.
  • the data can comprise data records having data fields.
  • the data records can comprise information related to a financial loan application, parties involved in a loan transaction, and property involved in a financial loan.
  • Another instruction in the code can include determining whether one of the data records has a data field containing common data to at least one other data field contained within at least one of the other data records.
  • And another instruction in the code can include determining whether data records having at least one data field in common have other data fields having disparate data.
  • And still yet another code instruction can include providing a report comprising data records based at least partially on the identifier. The report can include a listing of data records with data fields having common data and data records containing data fields having disparate data.
  • Computer-readable medium embodiments having stored code can also include additional aspects.
  • code instructions can be provided such that at least a portion of data records contain mortgage loan application information submitted by unique users and at least another portion of the data records contain information obtained from pre-existing databases containing borrower information.
  • Such code can enable a dual pipeline feature as discussed herein.
  • Another exemplary aspect includes providing code instructions such that data fields are reviewed for common data, including property address information, to determine if a single property is subject to multiple loan applications.
  • Code instructions can be provided on a medium to repeatedly determine on a pre-determined basis whether data records have data fields containing common data relative to other data fields contained within other data records, and whether data records having data fields in common also have data fields having disparate data.
  • FIG. 1 illustrates a block diagram of a fraud detection system according to some embodiments of the present invention.
  • FIG. 2 illustrates an information flow diagram in a fraud detection system according to some embodiments of the present invention.
  • FIG. 3 illustrates comparing one record to one or more records in a fraud detection system according to some embodiments of the present invention.
  • FIG. 4 illustrates a fraud detection method according to some embodiments of the present invention.
  • FIG. 5 illustrates an information flow diagram for fraud detection system users according to some embodiments of the present invention.
  • FIGS. 6A-6F illustrate exemplary reports provided by a fraud detection system according to some embodiments of the present invention.
  • FIG. 7 illustrates a method of fraud detection according to some embodiments of the present invention.
  • FIG. 8 illustrates a method of an incident submission process according to some fraud detection embodiments of the present invention.
  • FIG. 9 illustrates a method of authenticating and verifying entities and professionals involved in a financial application process according to some embodiments.
  • embodiments of the present invention are described below for detecting signs of fraud in mortgage loan applications. Embodiments of the invention, however, are not so limited. Rather, embodiments of the invention can be used to detect fraud or to track patterns, similarities, or dissimilarities in many fields. For example and not limitation, embodiments of the present invention may be used to detect fraud in credit card applications, employment applications, and personal property loan applications.
  • embodiments of the present invention assist users in detecting fraud.
  • embodiments of the present invention are configured to alert users of potential fraudulent activity so that users can further investigate the circumstances to mitigate fraud.
  • embodiments of the present invention can enable the mortgage lending community to more accurately determine the authenticity of the borrower/applicant wishing to obtain a mortgage for real estate.
  • fraudsters may falsify information related to names, social security numbers, or both in an effort to create false mortgage transaction and escape detection.
  • a fraudster can assume an identity and begin establishing a historical record of credit as a part of the process for stealing the identity.
  • multiple names can be used with a single social security number in an effort to thwart off detection. The alternate names are submitted to multiple lenders to avoid being spotted during the process. Lenders are currently vulnerable to this type of attack because there is no system that enables identity variances across multiple transactions while verifying information provided by borrowers to lenders in a loan transaction.
  • the various embodiments can be used to help mitigate potential fraudulent activities.
  • FIG. 1 illustrates a diagram showing components of a fraud detection database system 100 according to some embodiments of the present invention.
  • the database system 100 can generally comprise at least one database manager 110 , at least one database operator 120 , one or more users 130 , and a database 140 .
  • the database system 100 may also comprise one or more external databases 150 for providing additional information to the database 140 .
  • the database 140 (and/or the database operator 120 or the database manager 110 ) can be configured to access one or more external databases 150 to provide additional data to the system 100 to provide enhanced fraud detection capabilities.
  • the illustrated components of the system 100 can be networked together. Such networking enables the system's 100 components to exchange and share data.
  • users 130 are preferably networked with the database operator 120 via a network, such as network 160 .
  • Network 160 may be a private or public network.
  • the network 160 can include the internet. This configuration enables users 130 to access and utilize fraud detection via an internet, web-based interface. In this manner, users 130 can access an internet portal to query and search data maintained in the database 140 to obtain desired information.
  • the database operator 120 can include various processing modules for automated querying of the database and for reporting results to users. Such reporting can occur based on user defined search queries and user defined search frequencies.
  • the network 160 can also be a private network and also have both public and private features to enable implementation of varying security protocols.
  • one or more of the database manager 110 , the database operator 120 , and the database 140 can be integrated together in a single physical device. In such an embodiment, a single physical device enables a centralized database system 100 at a single location.
  • one or more of the database manager 110 , the database operator 120 , and the database 140 can have various components capable of implementing required functionality.
  • the database 140 may have one or more data storage units located at one location or located at different locations. It should be understood that if one or more of the database manager 110 , the database operator 120 , and the database 140 have several components such components can be networked together to enable system functionality.
  • each system component can have various operation functions.
  • the database manager 110 can initialize and maintain the database 140 .
  • the manager 110 can perform, or cause to be performed, maintenance required by the database 140 .
  • the manager 110 can also ensure that users 130 execute legal and other documentation desirable for participation in the database system 100 .
  • the database operator 120 can be configured to perform database tasks as desired. For example, the database operator 120 can conduct queries on the database 140 , and in response to the queries, the operator 120 can receive data from the database 140 . Based on data received from the database, the operator 120 can output reports to users 130 . The database operator 120 can also accept data submitted by users 130 and can transfer the submitted data to the database 140 . As discussed herein, users 130 can provide data related to or concerning financial loan transaction applications (e.g., mortgage loan information and fraud incident information). The database operator 120 is also preferably configured to enable and accept batches of data from many different users 130 .
  • the system 100 is contemplated, in some embodiments, as a very dynamic system that is on a real time basis receiving information from many different sources and reporting information to users in response to queries. Use of such raw, current data for analysis can help to enable real time detection of fraud.
  • the database operator 120 can also be configured to have numerous operational characteristics.
  • the database operator 120 can include web service functions to enable an internet interface between users 130 and the database. Inclusion of web service functions enables users to access the fraud detection system 100 , to query the database 140 , and obtain data in an effort to learn additional information about parties to a financial application.
  • database operator 120 can include various processing modules configured to search and analyze data according to predetermined data tests. Such data tests can compare data from various sources on a wide-scale basis and provide results of the comparisons to users.
  • the database operator 120 can be, for example, a module of the database 140 capable of executing computer code.
  • the database operator 120 can be a device, a segment of code, a computer system adapted to operate in conjunction with the database 140 , a database operating module of a computer system, and/or a combination thereof.
  • the database operator 120 can comprise a plurality of modules, such as, for example, a receiving module comprising data interfaces for receiving records, a comparing module for comparing records, and a reporting module for reporting results.
  • the database operator 120 can also provide an interface enabling users to submit and obtain data to the database 140 .
  • Users 130 of the system can be various types of people or entities desiring assistance in detecting fraud.
  • users 130 can be subscribers who are entities, such as mortgage lenders, banks, or mortgage brokers, who subscribe to the database system 100 .
  • Users can also include mortgage bankers, financial lending institutions, real estate agents, appraisers, closing agents, mortgage portfolio investors, home builders, title companies, loan servicers, loan consolidators, accountants, attorneys, banks, direct consumers, other mortgage related agencies, and non-mortgage related agencies.
  • Users 130 may also include law enforcement personnel and others involved in investigating and prosecuting fraudsters.
  • users can also provide information to the system 100 .
  • users 130 can submit records to the database operator 120 for submission to the database 140 .
  • Such records can include mortgage loan application information (e.g., Uniform Residential Loan Application—Form 1003) and also fraud incident information.
  • mortgage loan application information e.g., Uniform Residential Loan Application—Form 1003
  • fraud incident information e.g., fraud incident information.
  • the system can advantageously obtain information from users who interact with mortgage-related transactions on a daily basis thereby providing a dynamic system capable of obtaining current and fresh data. This enables users to cross check their data with other users and enables the system 100 to consider data from numerous users in an effort to flag possible fraud conditions.
  • Users 130 can also receive reports of potential fraud from the database operator 120 . Upon receiving such results, users 130 can take steps to investigate one or more flagged loan transactions.
  • the database operator 120 enables users to log in to the system 100 and view transactions in the user's internal pipeline and transactions external to the user's pipeline.
  • lender A may desire to track loan transactions in its pipeline for potential fraud activity and also track loan transactions external to lender A's pipeline. In this manner, lender A can track loans in the pipeline of other lenders to see if any loan transactions in lender A's pipelines contain similar person data to transactions of other lenders.
  • the dual pipeline feature advantageously enables users (such as brokers and lenders) to cross check transactions in their pipeline with transactions in one or more users' pipelines. As a result, this feature can help inform users if their clients are also interacting with other users who have submitted data to the database 140 .
  • the database 140 maintains the records submitted via the database operator 120 .
  • the records can comprise data records (or data sets) with various data fields.
  • the data records have a uniform format with uniform data fields. Such uniformity enables the database operator 120 to compare and contrast data contained in the data records to determine existence of possible fraudulent activity.
  • the database operator 120 and/or the database 140 can validate received data records to ensure appropriate format.
  • the volume of records submitted to the database 140 can be, for example, upwards of approximately one thousand per day per user 130 .
  • the database 140 is scalable to enable receipt of less or more records on a daily basis as desired.
  • the database 140 is preferably configured to maintain this volume of data.
  • the database 140 is preferably also a storage facility capable of storing large amounts of data.
  • FIG. 2 illustrates an information flow diagram in a fraud detection system according to some embodiments of the present invention.
  • FIG. 2 specifically illustrates a flow diagram 200 of information from various system users 130 to a fraud detection system 100 .
  • a first borrower 210 borrower 1
  • borrower 1 210 discloses certain application information to broker 220 .
  • broker 220 discloses this information to a user 130 , lender 1 230 .
  • Lender 1 230 submits to a database operator 120 a record relating to and containing information contained in borrower 1 's loan application.
  • the database operator 120 received this record and enters the record into the database 140 .
  • the provided record may be used to update or refresh an existing record.
  • FIG. 2 also illustrates additional users 130 providing data to the fraud detection system 100 .
  • FIG. 2 shows that a second borrower 240 provides mortgage loan application directly through a second lender 250 .
  • the second lender 250 can submit borrower 2 's 240 application information to the system 100 via the database operator 120 .
  • the database operator 120 can submit the information to the database 140 as a new record (or an updated or refreshed version of an existing record).
  • a plurality of users 130 can provide information to the fraud detection system 100 at varying rates as desired.
  • all users 130 can be configured to communicate with other users through the fraud detection system 100 .
  • users 130 may submit potentially confidential information to the database 140 , it may be desired that involved parties enter into agreements for protection. For example, users 130 can certify that they understand the database system 100 reports tips and leads only, and that decisions of whether to accept or deny loan applications should not be made solely based on such reports. Users 130 can also certify that their use of reports will comply with applicable laws and regulations, including the Fair Credit Reporting Act (“FCRA”). Further, it may desired to have users 130 indemnify the database operator 120 and the database manager 110 . The database manager 110 can ensure that these legal documents are executed.
  • FCRA Fair Credit Reporting Act
  • the corresponding record submitted to the database operator 120 by a subscriber 130 can consist of originator information as well as borrower information from a loan application, such as the Uniform Residential Loan Application.
  • Originator information, or originator data can include data on an entity originating the loan application.
  • originator information can include the name of a mortgage broker and other information related to and unique to the mortgage broker.
  • the following list represents a non-exclusive list of data that may be included in originator information submitted to the database operator 120 in a data record:
  • Borrower information comprises data supplied by the borrower in a loan application. This data can be based on documentation from borrowers.
  • the following list presents a non-exclusive list of borrower information that can submitted by subscribers 130 . Not all listed items need be submitted by every subscriber in every instance, and additional data may be submitted in addition to or in lieu of the listed items.
  • Users 130 can provide data to the system 100 in a variety of manners.
  • data can be provided on a batch basis and in others on a single record basis. Transfer of batch data can occur at random times or in accordance with a predetermined data transfer protocol. For example, some users may desire to transfer loan application information on a daily basis as loan transactions are initiated and as loan transactions move through a lifecycle process.
  • Alternative manners of providing data to the detection system include submitting incidents of fraud data and commenting on existing fraud scenarios.
  • the system 100 can advantageously receive fresh raw data to analyze for potential fraud occurrences and provide reports indicating possible fraud to system users.
  • embodiments of the present invention receive data from users, the data can be analyzed for possible occurrences of fraud.
  • fraud occurrences are determined to exist for one or more transactions (e.g., a mortgage loan application)
  • embodiments of the present invention can flag such occurrences so that users can further investigate flagged transactions.
  • fraud detection systems generally compare received records to each other in an effort to locate possible fraudulent activity.
  • embodiments of the present invention can also be configured to access already existing external databases to obtain additional data for comparison to received records from users. Data comparison of data records can be done on a data field basis to determine if disparate data exists and to determine a magnitude of difference between data fields.
  • FIG. 3 illustrates comparing one record to one or more records in a fraud detection system according to some embodiments of the present invention.
  • FIG. 3 shows a diagram showing how data records 310 are compared to other records in a database according to some embodiments of the present invention.
  • a first exemplary record 312 can be submitted to the database 140 from a user 130 via the database operator 120 . After submission, and periodically for a predetermined period, the first record 312 can be compared to other records 310 in the database 140 (other records are shown as Records 2 , 3 , 4 , through N).
  • fraud detection systems can determine if applicant information differs from existing or other information sources across many numbers of records. By performing such checks, the fraud detection system can flag possible fraud occurrences and report the same to users.
  • comparison of records can include multiple predetermined checks.
  • comparing the first record 312 to another record 310 can generally comprise two checks. These checks can be, but need not be, performed by the database operator 120 or a processing module implemented in one or more components in a fraud detection system.
  • a first check can include determining whether records are matches, or preliminary matches.
  • Preliminarily matching records 310 can comprise similar information in certain data fields. For example, and not limitation, records 310 with the same borrower name, the same property location or address, and/or the same social security number can be deemed matches.
  • other data records can be checked for consistent data in certain data fields (such as those in the above provided lists).
  • Data records having consistent or matching data in one or more predetermined fields can be flagged for subsequent processing. In the event that records do not contain consistent data in one or more predetermined fields, no further comparison may be required. Alternatively, data records having inconsistent data in data fields may be flagged for subsequent processing.
  • a second check can determine if records flagged as having consistent data in one or more data fields have inconsistent data in various other data fields. For example, a second check can determine if records flagged as matches include inconsistent data, such as contradictory data in such fields as appraisal value, loan amount, borrower SSN, and borrower account/income values. If inconsistent data is found in one or more of the records 310 , the records 310 can be flagged. For example, and not limitation, if a first record 312 includes a borrower income of $55,000, and another record 310 includes a borrower income of $155,000, the two records 310 can be flagged. Such disparate data may be a sign of a fraudulent occurrence, and in response, the database operator 120 can return flagged records 310 to subscribers 130 in the form of reports. Similarly, the database operator 120 can also return matches to subscribers 130 in reports.
  • inconsistent data such as contradictory data in such fields as appraisal value, loan amount, borrower SSN, and borrower account/income values.
  • FIG. 3 may suggest that comparisons are implemented through a direct comparison between records 310 , this particular implementation is not required.
  • digital references to the records 310 can be sorted over borrower social security numbers, borrower names, property locations, or any combination of these three (as well as the above-listed data fields). Accordingly, determining matches between records can include examination of records 310 nearby the record with respect to the sorted order.
  • FIG. 4 illustrates a method 400 of detecting fraud according to some embodiments of the present invention.
  • method 400 can be performed in various orders (including differently than illustrated in FIG. 4 ), additional actions can be implemented as part of a method embodiment, and that some actions pictured in FIG. 4 are not necessary.
  • FIG. 4 may be discussed herein as including certain other actions, these certain other actions may be carried out in various orders and/or as parts of the other actions depicted in FIG. 4 .
  • Method embodiments of the present invention such as the one depicted in FIG. 4 , may be implemented with the fraud detection devices and systems discussed herein.
  • the method 400 generally initiates by receiving data from one or more data sources.
  • the received data can be stored in one or more databases.
  • Data sources can include one or more contributory users as well as one or more existing databases. Records may be received on a routine frequent basis (e.g., daily at a set time or bi-weekly) or as desired (e.g., on a random, unscheduled basis). Indeed, users may submit records on a nightly basis and a fraud detection system may access and/or obtain information stored in one or more other databases as needed. It is contemplated by the inventors that many data records (e.g., 1000 or more per day) will be received to enable the various fraud detection methods to assist in fraud detection.
  • the method 400 can also include verifying that a submitted data record is submitted by a valid subscriber by checking a subscriber registry.
  • the method 400 may also include verifying that the received data is compliant with a predetermined data record format. Verification ensures that data originating from various and sometimes disparate sources, is in a data record format to enable data comparison and analysis.
  • the specific format of a data record (which can include any of the data fields listed herein as well as other desired data) is not important. What is important is that data records have the same format or have corresponding data fields. For example, in some embodiments it may be desired to have data records with the same data fields within the data record (e.g., same data record layout). This configuration can readily enable comparison of data fields within data records and accurate, efficient analysis of data fields.
  • the method 400 can also include an initial review of records.
  • the initial review can include iterating through many records as illustrated at 405 .
  • active and inactive records may be reviewed while in other embodiments only active or inactive records may be reviewed. Records may be changed from active to inactive or vice versa depending on a number of factors, including user selection, data threshold, or time stamp threshold.
  • active or inactive status may be used to remove and/or add data records in and out of a user's internal pipeline. Records may also be updated during a lifecycle of an application process.
  • the initial review may also include data record verification as discussed above.
  • the process of initial review preferably yields a grouping or set of records (e.g., all active records) for further analysis.
  • Further analysis can include searching selected records to determine if the records have one or more common data fields. Such data fields may be deemed critical data fields for fraud detection purposes in that the data within these fields holds unique significance relative to other data fields.
  • the method 400 can include a further analysis to determine whether records have similar property address information. To do this, property address fields in each record are compared with other records.
  • the method 400 may also include searching for records with, for example, similar borrower names or borrower social security numbers. Still yet, the method 400 can include searching for any combination of critical data fields, in addition to those discussed above, as desired by a user.
  • the method 400 can also include standardizing records. Standardization of records can occur at any time during implementation of the method 400 . For example, standardization can occur prior to or after record verification and also prior to of after comparison of records. Standardization can assist in ensuring that data is in similar format thereby enabling efficient verification and comparison. Standardization can include converting received data to a standard form. As an example of standardization, address data (e.g., borrower addresses) can be converted to United States Postal Service format. This way, for example, St. and ST are converted to STREET.
  • address data e.g., borrower addresses
  • the method 400 can include determining whether preliminary matches between data fields in various data records are found.
  • a fraud detection system can determine whether one or more matching records are found for a first record as a result of comparing predetermined data fields of various data records.
  • a preliminary match analysis can determine if data records have similar SSNs, borrower names, property addresses, or any combination thereof. If such matching records are found, the method 400 may denote that one or more preliminary matches have occurred. If no matching records are found, the method 400 can proceed to 450 . And if matching records are found, the method can proceed to process 418 to determine any potential secondary matches.
  • process 450 inquires whether any new of unreviewed records exist. If such records exist, the method 400 can initiate again at 405 . If no such records exist, the method 400 may end and await receipt of additional records and/or user instruction. If a preliminary match to other records is not found, the method 400 can then return that a loan application has no corresponding matches. As a result, the method 400 may deem a loan application to be a low risk application. In some embodiments, low risk applications may not be searched again and may also be flagged for reporting or non-reporting low risk applications to users depending on user reporting preferences.
  • process 418 can include several processes to determine potential secondary matches. For example, if a preliminary match is found across property address fields at 415 , the method 400 can compare each field of matching records.
  • the secondary match analysis 418 is advantageously configured to determine if any records having preliminary matches (e.g., have matching property addresses) have data fields with disparate information (e.g., different appraisal values).
  • process 420 can include comparing records to locate data fields with disparate information.
  • a matching table can be provided for storing matching records, or references or pointers to such records. The matching table can also be configured to store information about matches, including whether a matching record was found in an external database.
  • process 425 can provide matching indicators in a matching table. That it, if corresponding fields of records match exactly, an indicator of such exact match can be stored. For example, an “E” (denoting exact match) can be stored corresponding to an applicable field and record in a matching table. As another example, if data fields differ, then this can be indicated by storing an “N” (denoting no match) in an appropriate place in a matching table. And as another example, if data fields vary, a variance indicator can be recorded to indicate a degree of difference.
  • the variance indicator may be used as a multiplier in a two-tier weighted algorithm as discussed below.
  • a larger data variance in the data yields a larger variance value.
  • a variance value may be a zero (0)
  • N no match
  • a variance value can be a three (“3”). If a particular field contains multiple entries, each entry of the field can be compared to each entry of a corresponding field in a matching record.
  • the method 400 can also include applying weights to score loan application data records at 430 . More specifically, one or more data fields in one or more data records can be weighted for importance. For example, in some embodiments, data fields of high importance for detecting fraud can be given higher weights relative to other data fields. Fields containing specific identifying information, such as borrower name or SSN can be provided with high weights, or the highest weights. Only fields with weights greater than zero need be compared for records with matching property addresses. Fields can be afforded a zero weight for strategic reasons or because those fields are not likely to indicate fraud. The weights, in combination with the variance between corresponding fields, can determine a relative significance of fraud (e.g., a score denoting potential fraud possibility). A relative significance of fraud can be used to determine a likelihood of fraud and also enable a user to take steps to further investigate. In some embodiments, weights can be implemented with a multiplier value.
  • the method 400 can also include determining a score for a data record at 430 .
  • Data records as discussed herein can be loan applications so the method 400 can determine a loan application score indicative of possible fraud associated with a loan application.
  • a provided weight value can be multiplied by a variance to determine a field score. For example, an “E” value can be afforded a lowest variance value for a particular field, while an “N” value can be afforded a highest variance value for a field. Other variance values may also be utilized.
  • Data field scores can be summed for a corresponding data record to determine a data record score.
  • the method 400 can also include providing one or more fraud scenario based on variance amounts (e.g., determined “N” and “E” results). Table I below illustrates a triggering index that method 400 can implement as an additional testing feature.
  • the method 400 can also include similar scoring for additional data records by analyzing additional record matches at 435 .
  • process 435 can determine whether one or more additional records with a same property address, for example, as a first record are found in a database. If so, a set of field-by-field comparisons can occur for each such additional record. After all matching records have been found and compared field-by-field to the first record, the match scores can be summed to determine a total loan score at 440 .
  • the loan score can denote a risk of fraud and also be used to determine a recommended level of due diligence. For example, if a loan score is high (meaning it indicates high risk of fraud), a high level of due diligence can be recommended to a user. In a similar fashion of a loan score is low (meaning it indicates a low risk of fraud), a low level of due diligence can be recommended to a user.
  • loan scores and due diligence levels can be provided on a numbered range (e.g., 1 to 10, or 1 to 100) and/or with “HIGH,” “MEDIUM,” or “LOW” labels.
  • loan score and due diligence level information can be provided to a user via a web-based interface enabling varying use of color indicators (e.g., red, yellow, green, etc.).
  • color indicators e.g., red, yellow, green, etc.
  • such information can be provided for each loan application in a user's loan application pipeline and also summarized based loan score and/or diligence level.
  • the method 400 can score loan applications to assist users in detecting mortgage fraud. Based on scoring results, and as shown as 445 , the method 400 can also determine an alert status for a one or more data records (or loan applications) in a lenders pipeline. If the loan score is above, below, or consistent with a predetermined threshold or threshold range, the method 400 can flag one or more loan applications to alert one or more users who submitted a loan application.
  • the flags can be alerts can be in the form of emails, text messages, blog entries, or many other communications.
  • the flags provide analysis information to users so that users can then determine any potential next steps in detecting any fraud associated with a flagged data record.
  • the method 400 may continue processing new or additional records at 450 . If no such records are located, the method 400 can end or await further instruction. It is currently contemplated that fraud detection method embodiments of the present invention, like method 400 , can review numerous data records in very short time frames all while continuing to receive additional, new, and/or updated records. Thus, embodiments of the present invention are contemplated as being dynamic in that record review of raw data continues on numerous records at any one time in addition to records continuously being added or updated with raw data information. Analysis of such raw data in accordance with embodiments of the present invention advantageously enables review of real-time data thereby yielding accurate and timely results to users.
  • the database operator 120 can compare records 310 for differences, as described above, and can alert subscribers 130 of these differences.
  • the fraud detection system 100 can be configured to be primarily concerned with inconsistencies between loans applications, and can also be configured to report multiple similar applications that are not inconsistent. For example, users might desire to be made aware of loan-shopping. Loan shopping can be suggested by multiple consistent loan applications for the same borrower on the same property. If a user is aware of loan-shopping, then the subscriber can be prepared to make a competitive bid for the borrower's business.
  • loan applications having certain fields with consistent data but having certain other fields with inconsistent data can be a fraud warning sign.
  • Fraudulent loan applications typically include different borrower data across multiple loan applications for the same property. For example, and not limitation, records containing the same borrower name but different appraisal values can be deemed inconsistent.
  • the database system 100 can be capable of further analyzing results, but at the least, the system 100 can preferably return reports indicating flagged records. Upon receipt of such flagged records, users 130 should perform due diligence to determine the cause of flagged inconsistencies.
  • Inconsistencies between records 310 need not be the result of fraud. For example, inconsistencies may arise due to human error, such as typographical errors. If requested loan amounts of a preliminarily matching pair are listed as $1,295,340 on one application and $1,295,430 for another, the subscriber 130 might determine that the inconsistency resulted from a typographical error. Thus, embodiments of the present invention can also be configured to determine a magnitude of difference between inconsistent data. Determining magnitudes of difference for certain data fields can also be indicative of possible fraud. Indeed, a user 130 might perform due diligence to determine whether a magnitude difference above a certain threshold comports with possible signs of fraudulent activity. Indeed, embodiments of the present invention can provide data elements triggering the variance.
  • a typographical error or a true misrepresentation is a cause for the variance. For example, if a submitted appraisal amount is $345,700, a first matched loan triggered a variance to display $354,500, and a second match loan displayed $374,500. In this scenario a user can determine that both returned variances could be typographical errors due to transposing of numbers in the returned appraisal amounts.
  • users 130 can monitor records over a lifecycle of a loan.
  • the database operator 120 can continue to monitor records with newer received records to continually monitor for possible fraudulent activity.
  • records 310 can be compared to other records 310 periodically for a predetermined holding period. Indeed, in some embodiments a record 310 can be compared to other records 310 daily for a holding period of approximately 30 to approximately 90 days.
  • additional exemplary holding periods can be 61 days and can range from 1 day to a complete year. Users can modify holding periods per submitted transactions by providing such search query information to the database operator.
  • Embodiments of the present invention also enable users to modify loan transactions provided in their respective pipelines.
  • users can submit information they obtain from applicants to a fraud detection system 100 .
  • the fraud detection system 100 can be configured to maintain various pipelines of applications segregated by users 130 . This advantageously enables users to monitor their borrower-specific applications with an internal pipeline and then applications of other users via an external pipeline.
  • fraud detection system 100 embodiments of the present invention enable users to modify transactions maintained in their pipelines. For example, as loan transactions near the end of a lifecycle or are completed for other reasons, users can provide this information to the database operator. In doing so, users can modify the number of transactions contained within their pipeline.
  • fraud detection system embodiments of the present invention can be configured to provide updated information to users when data in a data record changes or corresponds with another data record maintained in the database.
  • a fraud detection system 100 can perform credential checks on those involved in a loan transaction.
  • a database operator 120 can verify that professionals included in originator information hold valid credentials.
  • a credentialed list can be maintained in the database 140 for each subscriber 130 .
  • the database operator 120 and/or database 140 can be configured to access one or more external databases to obtain credential information.
  • a credentialed list can include, without limitation, a list of known mortgage brokers and licensing information.
  • Originator information can be compared to one or more credentialed lists for one or more users 130 . Additionally or alternatively, originator information can be compared to a system credentialed list, which can be maintained for the benefit of all or a set of the users 130 . If originator information fails to match any item of a relevant credentialed list, users 130 can be alerted.
  • FIG. 5 illustrates a flow diagram of information from the fraud detection database system 100 to users 130 according to some embodiments of the present invention.
  • the database operator 120 can retrieve data from the database 140 , preferably by way of queries to the database 140 .
  • the database operator 120 can send reports to the users 130 .
  • the database operator 120 can also send reports to the database manager 110 , which the manager can use to ensure the database system 100 is running as desired.
  • the database manager 110 can implement administrative checks and processes to ensure that a fraud detection system is operating as desired.
  • Reports to users 130 can list all or a subset of preliminary matches, and can list all or a subset of flagged matches. Summary reports can highlight inconsistent data of flagged matches. As comparisons can be conducted periodically, a user 130 can receive multiple reports on a single loan application. Each report can be cumulative or, alternatively, each report may list only results of comparisons to new records 310 . In addition, a report can include a due diligence level indicating a level of suggested diligence. A report may also include an identification verification score providing a score indicative of whether provided names and biographical information are consistent with various other data records.
  • Fraud detection system embodiments can deliver and/or provide reports in electronic form.
  • reports can be provided in an email format and/or in response to real-time queries. If results are reported via a computer program in which a user 130 logs in to view results, the program can ensure that users 130 have an opportunity to sufficiently view the report. For example and not limitation, results can remain viewable until a user 130 takes an affirmative action, such as closing a window or deleting a report in a web-based interface. Users 130 can choose whether to receive cumulative reports or to receive only new results.
  • a user 130 can notify the database operator 120 when a loan application is removed from the subscriber's pipeline. If such a notification is made, the database operator 120 can remove the associated record 310 from the database 140 so that no further reports to that user 130 include comparisons with one or more associated records 310 . Other users 130 , however, may continue to receive notification in their reports of inconsistent information between their applications and the removed loan application. Reports can list results in a particular order based on preferences of the industry or of individual users 130 .
  • the order can be determined based on a two-tier weighted algorithm for each element of borrower information in the records 310 .
  • a two-tier weighted algorithm may be derived based on feedback from top lenders and the Mortgage Bankers Association.
  • inconsistencies in certain data elements can be more significant than inconsistencies in other data elements in identifying potential fraud.
  • an inconsistency in requested loan amount or appraisal value can be more significant than an inconsistency in current employer address.
  • a borrower's SSN may be a critical data element in determining a valid identity, acquiring credit history, verifying employment and income, etc.
  • SSNs can be weighted as a more important data element (e.g., as a first tier weight). Other data elements can be assigned a different weight (e.g., as a second tier weight).
  • embodiments of the present invention can determine variance severity for each SSN when other loans are found matching the property address of a submitted loan. If a number sequence in the SSN is either transposed (which could be SSN “Tumbling”) or different, a weighted multiplier can be assigned depending on a number of found incidents. In some embodiments, weight values can range from zero to thirty, depending on data's importance to a loan transaction.
  • the first tier in the weighted algorithm can consider the significance of the inconsistent data elements.
  • the second tier can weigh the magnitude of the inconsistency. For example, a requested loan amount difference of $145,000 and $154,000 is less significant than a requested loan amount difference of $145,000 and $300,000.
  • a high risk alert can be assigned regardless of a total loan score.
  • a range of due diligence efforts can be undertaken by users 130 based on the type of inconsistencies shown in reports. For example and not limitation, if a user 130 sees multiple loan applications for the same property with different monthly incomes, the user 130 may implement tools to research and verify the true income of the borrower. For another example, if a user 130 sees multiple loan applications for the same property but with different borrower names, the cause could be a typographical error. If this is the case, the user 130 might perform due diligence in verifying the correct spelling of the name.
  • the database operator 120 can perform preliminary analysis on inconsistent preliminary matches. For example and not limitation, reports to users 130 can categorize inconsistencies to highlight the possibility that certain fraud schemes are underway.
  • FIGS. 6A-6F illustrate exemplary reports provided by a fraud detection system according to some embodiments of the present invention.
  • the first row 610 of the reports in FIGS. 6A-6F lists headings for the items in the second row 620 .
  • the first item of the first row 610 states “Loan ID.” Accordingly, the first item in the second row of the first column gives the Loan ID of the primary record 310 , the record 310 to which the report refers.
  • the second item of the first row 610 states “Property Address,” and the second item of the second row 620 gives the property address on the loan application associated to the primary record.
  • the next item of the first row 610 asks for the Loan ID of the primary record 310 , which is given in the second row 620 below.
  • the remaining items ask for Loan IDs of records 310 preliminarily matching the primary record, and the Loan IDs of those records are given below, on the second row 620 .
  • Column 630 lists titles of data elements of the primary record 310 .
  • Column 640 lists the corresponding data for the primary record. The remaining columns 650 to the right of column 640 give the inconsistent corresponding data elements for the preliminarily matching records for which Loan IDs are listed in the second row 620 .
  • the database operator 120 can return a preliminary fraud analysis in reports.
  • item 660 gives a possible fraud scheme based on a preliminary analysis of the inconsistencies in the records.
  • a possible fraud scheme can be returned based on the results of a number of IF-THEN-ELSE tests corresponding to known fraud schemes. These tests are based on data fields contained with data records.
  • Such returned fraud schemes can include those discussed above and also those discussed below in more detail (for example, see TABLE I and associated text).
  • Item 670 gives the potential risk that the records referenced in the report represent a fraud scheme. Additionally, as shown only in FIG. 6D , the report can list additional useful information 680 , such as non-credentialed and/or sanctioned professionals. So long as report present relevant inconsistencies to subscribers 130 , the reports need not take the same format or report the same set of information as those reports illustrated in FIGS. 6A-6F .
  • the database operator 120 can produce comprehensive aggregated reports from the database 140 for the database operator's own use or for the database manager 110 .
  • comprehensive reports can list a number of mortgage applications processed, the number of different appraisals by a single appraiser, a number of different appraisals for the same property with different appraisers, the number of times a potential shotgun fraud was identified, the number of times a flip fraud scenario was identified, and many other data.
  • Reporting can also be tailored to user's pipeline settings. In this manner, for example, reports can include predetermined formats based on a user's pipeline settings and may only report testing data of a user's pipeline.
  • FIG. 7 illustrates a method 700 of fraud detection according to some embodiments of the present invention.
  • method 700 can be performed in various orders (including differently than illustrated in FIG. 7 ), additional actions can be implemented as part of a method embodiment, and that some actions pictured in FIG. 7 are not necessary.
  • FIG. 7 may be discussed herein as including certain other actions, these certain other actions may be carried out in various orders and/or as parts of the other actions depicted in FIG. 7 .
  • the method 700 may initiate in certain embodiments as shown at 705 by providing an interface for receiving data.
  • the data can be transmitted to and received into a database for processing in an effort to detect fraud.
  • the data may include financial transaction information including, mortgage loan information.
  • the data may also include information concerning borrowers, lenders, and/or entities.
  • Data can be submitted by users or data can be obtained by accessing one or more databases that may be publicly or private databases.
  • the interface can be a web-based interface. Such an interface enables users to submit information (e.g., mortgage loan information) for processing via a web browser.
  • a web-based interface can also enable transmission of information over the internet.
  • the interface may be provided as a software application capable of submitting data over a private network.
  • Data can be received in various forms including and ranging from receipt of a batch of data records to receipt of a single data record.
  • the method 700 can also include receiving and storing data in a fraud detection system database.
  • Data can be stored in various fashions. For example, received data can be stored in various records wherein a single data record corresponds to a single mortgage loan application. Data can also be stored using various key fields to distinguish data records from each other. As an example, data records provided by financial institutions (e.g., lenders in a mortgage transaction) may be stored using a key field identifier to distinguish data records between financial institutions. Such an identifier can be used to implement user pipeline control to one or more users for tracking their own data records.
  • financial institutions e.g., lenders in a mortgage transaction
  • Such an identifier can be used to implement user pipeline control to one or more users for tracking their own data records.
  • the method 700 can also include processing transaction information to determine a due diligence level associated with loan transactions.
  • a fraud detection system can render identity verification results for each primary applicant/borrower on the transaction or the highest risk applicant/borrower on the transaction.
  • Each high risk applicant/borrower can be identified by the system and displayed in the system interface. High risk individuals can then be associated with a high due diligence level indicating that a user should further investigate the applicant/borrower and a respective loan transaction.
  • the method 700 may also include processing transaction information to determine potential fraudulent activity associated with loan transactions.
  • a fraud detection system can process loan data transaction information for each borrower, applicant, lender professional, and/or company involved in a transaction.
  • lenders can view information related to their mortgage applications via an internal pipeline analysis and also view information related to other lenders via an external pipeline analysis. Enabling lenders to view loan applications in their respective pipelines relative to loan applications in other lender pipelines advantageously enables lenders to determine if borrowers and/or brokers are applying or have applied to other lending institutions. Such information may be useful and desired by lenders in managing risk associated with mortgage loans.
  • a fraud detection system can perform data validation checks. For example, a system can process received data to validate information related to the borrower's identity using an identity verification service. Validation can help determine if alternate information can be found associated with the borrower information. Such information can determine if a borrower has various name aliases as well as social security numbers and names.
  • a fraud detection database can cross reference a social security number database to determine if a received name matches the database and also to determine if a received social security number is a valid number (e.g., the social security number is not on a death list).
  • the method 700 can include processing information to determine compliance with existing laws and regulations.
  • lending institutions must comply with federal laws and regulations specific to consumer information and the establishment of relationships with their customers. These regulations are sometimes referred to as “Know Your Customer” regulations. Regulatory requirements associated with USA Patriot Act, Red Flag Rules (effective November 2008), and FACTA regulations require lending institutions to fairly and accurately know who their consumers are when a relationship is established. Such relationships generally include bank account opening, granting of loans, and any other business relationship that can materially affect the institution and/or consumer.
  • Mortgage fraud can often be facilitated by simply stealing a consumer's identity or assuming their identity for the purpose of purchasing property or defrauding a lender for monetary gain.
  • the method 700 can include processing information to determine background information for involved entities.
  • This feature of embodiments of the invention advantageously enables review of loan transaction data related to third parties, industry professionals, and companies facilitating a loan transaction. Indeed, some embodiments can access one or more other databases (e.g., a proprietary and contributory database) that contain containing information related to professional licensing, publicly sourced derogatory incident reports, sanction and administrative action reports, and past or ongoing incidents of alleged fraud and misrepresentation.
  • databases e.g., a proprietary and contributory database
  • fraud detection systems can obtain information to verify a professional's credentials and risk associations by directly searching the contributory database for license validation and status, as well as any inclusion in a reported incident directly, or indirectly.
  • the fraud detection system can provide results to users (as discussed below in more detail). For example, the system can return an “OK” or “ALERT” status based on received background information.
  • embodiments of the present invention can uncovers relationships among transaction parties, identify conflicts in professional credentials, and enable greater visibility to prior adverse business activities or associations that may harm lenders.
  • the method 700 can also include providing information processing results to users in various formats. Formats include, but are not limited to, email alerts and web-page listings. Formats can also include various reports provided by email and or return web-page listings. In addition, exemplary report formats can include line item results as a summary of loan transaction data that includes results from the processing, matching, and scoring algorithms. Also, the system can enable a user to select specific fields with toggle functionality to present more detailed information about the loan transaction data and the processing results. The can also enable interactive user functionality to present loan transaction data in configurable formats through filtering, searching, and sorting capabilities. Still yet, the system can display a report with detailed validation, verification, and credentialing processing results related to the borrower/applicant and transaction professionals and/or companies.
  • a due diligence level associated with a loan transaction can be based partially on an aggregate view of all data and if certain data inconsistencies appear between reviewed data fields a returned due diligence level can be set to “HIGH RISK” or a “RED ALERT” status. Other due diligence levels can include “LOW RISK” or “MEDIUM RISK levels.
  • returned results can include an identification score providing score information indicative of how a borrower's name checked with other checks. For example, if one database contains a name with a different SSN than submitted name, a borrower name identification score may be low indicating that the name issue should be further investigated. In another example, if one or more other database checks are performed and a borrower's name information is consistent among several records a high identification score can be returned indicating that a borrower's name is consistent with other data records.
  • FIG. 8 illustrates a method 800 of an incident submission process according to some fraud detection embodiments of the present invention.
  • method 800 can be performed in various orders (including differently than illustrated in FIG. 8 ), additional actions can be implemented as part of a method embodiment, and that some actions pictured in FIG. 8 are not necessary.
  • FIG. 8 may be discussed herein as including certain other actions, these certain other actions may be carried out in various orders and/or as parts of the other actions depicted in FIG. 8 .
  • the method 800 can initiate at 805 by providing an interface enabling submission of fraud related incidents.
  • users of a fraud detection system can submit information related to fraud for further investigation and possible inclusion in the fraud detection system's database.
  • the interface can be a web-based browser form capable of accepting user data entry related reporting a fraud related incident.
  • data forms can be transmitted (e.g., email, FTP, or SFTP) to a fraud detection system for analysis and review.
  • the method 800 can continue at 810 by populating data into an incident report submission form. Indeed in some embodiments, the system will automatically load data elements from loan transaction data into specified fields. For example, an applicant's name will appear in the corresponding incident submission field. The system also enables interaction with users so that additional information (e.g., from one or more users) can be input into a submission form.
  • the method 800 can continue at 815 by receiving incident report submission data.
  • a fraud detection system can provide the ability to query multiple databases. This enables users to determine whether those suspected of fraud may have been involved in other reported incidents.
  • the databases include real estate and professional license data directly from the Mortgage Industry Data Exchange (“MIDEX”). MIDEX is a repository containing industry-contributed incidents of fraud and material misrepresentation; publicly sourced information specific to administrative and disciplinary actions and sanctions; and professional license information.
  • MIDEX is a repository containing industry-contributed incidents of fraud and material misrepresentation; publicly sourced information specific to administrative and disciplinary actions and sanctions; and professional license information.
  • a fraud detection system according to some embodiments enables users to query databases in an effort to verify and adjudicate the professionals of record associated with the incident.
  • the method 800 can continue at 820 by providing incident report data for review.
  • incident report data for review.
  • some embodiments will provide reported fraud incident information for entry into the MIDEX incident submission processing queue.
  • the system can also associate a reported incident to loan transaction data by using a unique identifier that relates the two entities or the loan transaction data and the incident report.
  • the fraud detection system supports submission of an incident related to loan transactions, transaction parties or information contained in an official suspicious activity report.
  • the review process can include administrative review of the incident information, direct interaction with the submitter, data editing of incident information, formal review and approval of the completed incident report by the submitter and final delivery of the approved incident to a database upload queue for inclusion into the database.
  • the method 800 can also continue at 825 by receiving follow up information related to a reported incident.
  • the system can support a request for information and challenge of an incident submission.
  • the challenge process enables an industry professional and/or company to request incident information naming the requestor.
  • the requestor can submit information to an administrator via the system for verification and for potential future interaction regarding the submitted incident.
  • An administrator can query the database for any incident reports associated with the requestor.
  • the requestor will receive the incident information using an approved delivery method.
  • the requestor is given authorization to respond or rebut information contained in the incident.
  • the response or rebuttal is delivered to the incident submitter for review and response.
  • An administrator acts as the intermediary between both parties during the rebuttal process. During the course of the rebuttal process, it may be determined that the incident will remain in tact with no further modifications or the rebuttal will be approved by the incident submitter resulting in the removal of that incident report.
  • the method 800 can also continue at 830 by providing finalized incident report data into a fraud detection system database for review.
  • the system can support database modifications to the incident report by an administrator. Data modification can include removal of incident text or the addition of a requestor's response to the original incident of record.
  • the system can notify submitting entities with a relationship to the requestor as well as other user of interest with incident activity.
  • the system can also notify all entities with an interest in the named professionals of any new incident activity or updates to an existing incident report.
  • FIG. 9 illustrates a method 900 of authenticating and verifying entities and professionals involved in a financial application process according to some fraud detection embodiments of the present invention.
  • method 900 can be performed in various orders (including differently than illustrated in FIG. 9 ), additional actions can be implemented as part of a method embodiment, and that some actions pictured in FIG. 9 are not necessary.
  • FIG. 9 may be discussed herein as including certain other actions, these certain other actions may be carried out in various orders and/or as parts of the other actions depicted.
  • the method 900 can initiate by receiving names of entities involved in a loan transaction. Entities can include people, names of businesses, and companies. People may include borrowers, lenders, brokers, and realtors. By receiving this information, fraud detection systems according to the present invention can perform background and credential checks on the received information. Indeed, at 910 , the method 900 may include comparing received information with records already existing in the database. The result of such checks can provide information beneficial to users thereby enabling users to obtain background information on those involved in a loan transaction.
  • the method 900 can also include obtaining information from other existing databases at 915 .
  • These databases can include private and publicly available databases.
  • the existing databases can be managed by third parties and they databases can be located distant from a fraud detection system.
  • the existing databases can, for example, be managed by governmental or industry licensing groups and contain entity licensing and/or sanction information. Such features enable users to query a database for authorized and credentialed professionals when a loan transaction is commenced.
  • a fraud detection system enabling such entity checking can also facilitate queries to credentialed professionals list owned by the user of the system.
  • fraud detection systems will upload information about a individual professional, as it is presented to the system user. The system can then engage a workflow of data service calls and return specific information related to, for example, professional license status, incidents, OFAC compliance, criminal background, and a synthetic identity check.
  • users and/or a fraud detection system can compare the received background information to received loan transaction information to perform background checks at 920 .
  • the method 900 can also include reporting entity information to users at 925 .
  • fraud detection system embodiments can be configured to present a return list to users for selection when prompted to input information about a loan transaction professional.
  • the process for professional credentialing may be a workflow of choreographed data services that will perform a series of checks and verifications, resulting in a “PASS/FAIL” score for an entity.
  • the system may require a minimum amount of data criteria to provide results and to assign a “PASS/FAIL” score to be compiled for the overall score.
  • Embodiments can also include providing a credentialed professional list with access to system detail reports and an exception list that contains professionals and/or companies that have been identified as not credentialed to do business. Additional embodiments can also enable uploads of professionals not credentialed to do business with the system user, by the system user.
  • embodiments of the present invention can be used to identify a potential fraud scheme.
  • the identification can be determined by analyzing results of data field analysis and comparison. For example, the inventors have discovered that by analyzing matching characteristics of certain data fields (e.g., data fields have data that matches or does not match), one or more potential fraud schemes can be provided to a user. Matching characteristics can also include analyzing the “N” (no match) and “E” (exact match) processes discussed above.
  • the below provided table (TABLE I) provides a series of test scenarios for implementing a fraud scheme analysis process in accordance with some embodiments.
  • embodiments of the present invention can be configured to review the results of a matching analysis for various data fields. Based on the analysis, a potential fraud scheme can be provided to a user. For example, if a no match result is returned for loan borrower name, appraisal value, application data, and loan seller name in concert with a match for originator company and name and appraiser name information, this information can indicate a possible flipping fraud scheme. As a result, embodiments of the present invention can return this information to a user so that a user can further investigate. Shot-Gunning, double escrow, churning, chunking, and straw-buyer alerts can be similarly returned to users if a matching analysis is in line with the above table entries. Given the dual pipeline features of the present invention, possible fraud scenarios can be returned for both a user's internal pipeline and also for records external to a user's pipeline.
  • a processing module can be configured to separate loan transaction information for review by users into multiple pipelines using an identifier configured to distinguish users.
  • a processing module can be configured to separate loan transaction information into an internal pipeline comprising loan information associated with a first lender and an external pipeline containing loan information associated with lenders other than the first lender.
  • a processing module can be configured to associate at least one of a due diligence level and identification score with one or more data records.
  • a processing module can be configured to determine if one or more data records complies with financial laws and regulations.
  • a processing module can be configured to maintain one or more data records in an active pipeline for a predetermined amount of time, the one or more data records in the active pipeline being associated with a single lender.
  • yet another aspect can include providing users information about one or more data records relating to mortgage applications at predetermined stages of the mortgage applications.
  • data records can have a uniform format such that the processing module can compared a data record to another data record to determine consistencies and inconsistencies.
  • a method can include receiving fraud incident data information and storing such information as a data record.
  • a fraud detection method can also include receiving a query based on or more data fields and to return data records responsive to the query.
  • a processing module can be configured to monitor one or more data records for a predetermined period of time and provide reports detailing any changes in the one or more data records.
  • a processing module can be configured to provide reports comprising information about a mortgage application proximate at least one of a pre-funding application stage, a loan funding stage, an investor servicing stage, and a loan servicing stage.
  • Embodiments of the present invention can still have other features. For example, some embodiments can be configured to validate the one or more data records to ensure that the one or more data records comprise data based on a predetermined data format. Some embodiments can also be configured to receive updated data pertaining to one or more data records and providing administrative operating reports comprising operational information. Such operational information can include database operational status, user interaction information, user submitted information, and other administrative data functions as desired. As discussed herein, embodiments of the present invention can receive information from unique users, which can comprise lenders, brokers, and borrowers. Embodiments can also include at least one webserver operatively configured to provide data interfaces and/or internet portals for use in communication networks. Also, embodiments of the present invention enable users to customize reports provided to them. For example, a reporting module can be operatively configured to receive report format information from a user and to provide report information to a user based at least partially on the received report format information.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Technology Law (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

Mortgage fraud detection systems and methods are provided. A fraud detection system can generally comprise a database operator, a database manager, one or more users, and a database. Database components can be implemented as hardware, software, or a combination of both. A fraud detection method can generally comprise providing a database for maintaining a plurality of records. Data records can be continually received by a database in batchwise or single submission protocols. Records can be compared to determine whether they contain common data in one or more predetermined fields. If records contain common data in one or more predetermined fields, records can be examined for inconsistencies in one or more other data fields. Discovered inconsistencies and magnitudes of inconsistencies can be warning signs of fraud. Results of comparisons can be reported to system users to enable such users to investigate additional circumstances. Other embodiments and features are also claimed and described in the application.

Description

    CROSS-REFERENCE TO RELATED APPLICATION & PRIORITY CLAIM
  • This application is a continuation of U.S. patent application Ser. No. 12/174,591, filed 16 Jul. 2008, which claims priority to and the benefit of U.S. Provisional Patent Application No. 61/015,429, filed 20 Dec. 2007. Both of said applications are incorporated herein by reference in its entirety as if fully set forth below.
  • TECHNICAL FIELD
  • The various embodiments of the present invention relate generally to database and information management systems and, more particularly, to fraud detection database systems and methods to assist users to detect mortgage fraud as well as other types of financial fraud that may occur in a financial application process.
  • BACKGROUND
  • As shown increasingly by recent financial events, the mortgage industry continues to struggle with detecting and managing fraud. Lenders have come under scrutiny due to relaxed lending policies and vulnerable lending processes exposed to fraudsters. As a result, lenders are greatly concerned with the continued rise in mortgage fraud. Recent regulatory and political activities have added a new twist to operational concern—compliance risk. More than 70% of loan originations were facilitated by mortgage brokers in 2005 and 2006. Fraud committed by industry insiders has caused reported financial losses in excess of $1 billion to date. This figure alone illustrates that current fraud detection solutions are minimally impacting risk exposure for mortgage industry participants.
  • Currently, financial industry participants employ a number of systems that aim to detect fraud risks in an effort to prevent and mitigate fraud. Unfortunately, conventional systems, such as information verification tools, have yet to adequately and completely address the various types of mortgage fraudulent events. For example, conventional tools can be used in an attempt to verify information such as property values, names, social security numbers (“SSNs”), assets, and credit history provided during an application process. Despite the existence of existing, conventional automated tools, however, the mortgage industry and other financial industries continue to encounter a significant number of fraud occurrences.
  • Mortgage fraud typically occurs in two ways: fraud for profit and fraud for housing or property. Fraud for profit schemes typically result in ill-gotten gains from falsified or fraudulent loan transactions and usually involve industry insiders well versed in the funding process. The insiders that are typically parties to fraudulent schemes make it challenging to uncover fraudulent activities. Financial losses stemming from this type of fraudulent activity can be significant and devastating to industry participants. Examples of insider contributed fraud include, but are not limited to, illegal flipping, straw buyer scams, equity skimming, and fraudulent property investments.
  • Fraud for housing or property generally involves factual misstatements to obtain a property as a primary residence. This type of fraud contributes to the greatest amount of reported fraud. Common misstatements include embellishing salary or income amounts and undisclosed borrowed funds or employment terms. Borrowers are often coached by insiders so that reported data is represented more favorably and appears less risky to lenders.
  • In addition to the above mentioned mortgage-related fraud schemes, other common schemes are typically perpetuated by those participating in such illegal activities. For example, common mortgage application fraud plots include equity skimming/foreclosure bailout schemes, churning, chunking, shot-gunning, silent second, property flipping, double escrow, straw-buying, air loans, identification theft, asset rentals, mortgage elimination schemes, cash-back schemes, and non-arm's length transactions. These schemes are described below in more detail.
      • Equity Skimming/Foreclosure Bailout Schemes: Using money for reasons other than paying off loans. For example, when a borrower's property is in foreclosure, a seller purchases the property for a fee and promises to let the borrower continue to live on the property if the borrower deeds the property to the seller. The seller never pays the mortgage, the loan defaults, and the borrower is forced off the property. The seller walks away with a fee or with equity. The seller can then choose to re-mortgage or to abandon the property.
      • Churning: Refinancing the same property repeatedly in a short period of time. Interest rates, fees, and costs increase with each refinance. The loan officer can make a lot of money on one property because of the loan commissions associated with the constant refinancing. In contrast, lenders and borrowers pay more for the property than they otherwise would.
      • Chunking: A borrower purchasing multiple properties in a span of a few days. The concurrent debts do not appear on the borrower's credit report before the closings. This scheme is often perpetrated through seminars, or by approaching susceptible groups, such as those in nursing homes or churches. For example, a solicitor offers to sell a potential borrower multiple properties at once, for a fee. The solicitor promises to upkeep the properties, to lease the properties, and to make all payments on the applicable loans. After closing, however, the solicitor disappears with the fees. The borrower is left with mortgages on multiple properties, and the borrower's credit history may be destroyed.
      • Shot-gunning: An individual takes out undisclosed multiple loans on a single property simultaneously and then disappears with the proceeds. This scheme is often associated with foreign investors and organized crime.
      • Silent Second: A hidden second mortgage on a property. For example, a seller gives a borrower a second mortgage that is not disclosed to the borrow or to the lender of the first mortgage. To conceal its existence, the second mortgage is usually not recorded until after the closing. The seller receives the proceeds of the mortgage, and the borrower has to make the mortgage payments.
      • Property Flipping: A property sold a short time after a previous closing on the same property, where the second sale includes a significant, unwarranted increase in value. While it is legal to flip a property if appropriate improvements are made, flipping constitutes fraud when there is a significant value increase despite only minimal improvements to the property. A fraudulent appraisal is almost always involved. Illegal flipping can ruin the value of homes and neighborhoods. Further, lenders can lose money by providing large loans on over-valued properties.
      • Double Escrow: Two closings on the same property at once. For example, a borrower buys a property at one price and immediately sells the property at a higher price. Double escrow is a property flip with a shortened time frame, and is illegal if all terms are not disclosed to the involved parties.
      • Straw-buying: Using someone else's credit to secure a loan. The person whose credit is being used is the “straw buyer.” The perpetrating parties are often related. For example, if an individual's brother cannot secure a loan to buy a house, the individual can offer his own credentials to secure the loan for his brother. For another example, an individual with good credit may be approached and offered money to lend his name and good credit to multiple transactions.
      • Air Loans: All documentation is fabricated to secure a loan. There is no property and no borrower.
      • Identification (“ID”) Theft: Identity of a borrower or a mortgage professional is stolen and misused in a loan transaction.
      • Asset Rentals: Programs where assets, such as bank balances, cash, and strong credit card lines, are “borrowed” from their owners to make perspective borrowers appear financially sound. This scheme appears frequently on the internet. Usually, the asset “lenders” are compensated in some way.
      • Mortgage Debt Elimination Schemes: Fraudsters present faulty legal reasons why a particular mortgage or group of mortgages does not have to be paid. This scheme can be complicated and frequently appears on the internet. The Federal Reserve Board explains the scheme here: http://www.federalreserve.gov/boarddocs/srletters/2004/sr0403.htm.
      • Cash-back Schemes: A lender is deceived by a seller, a buyer, or both, as to the actual sales price of the property. An inflated appraisal is often involved to convince the lender to lend too much on the property. The proceeds are split among the perpetrators.
      • Non Arm's Length Transactions: Transactions where there is an undisclosed familial or professional relationship between a professional in the loan transaction and another involved party.
  • Mortgage fraud can also occur in ways different from those discussed above. Indeed other types of encountered examples include: misrepresentations on a mortgage application, inflated appraisals, appraisals with inappropriate comparables, employment and/or income misrepresentation (for example, on pay stubs, W-2s, tax returns, or Verifications of Employment), failure to disclose debts and/or other liabilities, failure to disclose correct employment status, use of invalid borrower SSNs, fabricated or misrepresented monthly housing payments (e.g., rent or mortgage payments), falsified bank statements or accounts, falsified gift letters, occupancy misrepresentation (e.g., primary residence vs. investment property), incorrect transaction type (e.g., purchase vs. refinance), borrower and/or seller not properly listed on property title, misrepresented closing costs, or closing funds distributed to unauthorized parties, misrepresented down payments, and unauthorized activity by unlicensed professionals.
  • As is readily apparent from the above discussion, mortgage fraud occurs in many different forms. While some fraud schemes are known, new schemes are hatched by fraudsters in an effort to outpace detection efforts. Fraud schemes and fraudulent misrepresentations are financially detrimental not only to those involved, but are also detrimental to communities in which subject properties are located and financial markets as a whole.
  • What is needed, therefore, are mortgage fraud detection devices, systems, and methods enabling users to detect fraudulent activity so that measures can be taken to mitigate fraud risks and stop fraudulent activities before financial losses occur. It is to the provision of such fraud detection systems, devices, and methods that the various embodiments of the present invention are directed.
  • SUMMARY OF SAMPLE EMBODIMENTS
  • Briefly described, various embodiments of the present invention generally comprise a fraud detection database, a fraud detection database system for detecting signs of fraud, and methods for analyzing various data resources to detect fraud. Fraud detection may occur in mortgage loan applications as well as many other financial applications (e.g., auto loan, credit card, and many other personal property loans). System users, such as lenders, can submit loan application data to a fraud detection system. Loan application data can include information from a borrower's mortgage loan application, such as information entered on a Uniform Residential Loan Application (Form 1003). Other submitted information may also include additional information from lenders and originator information, information on brokers, realtors, or appraisers involved in the borrower's transaction.
  • Detecting fraud through a database system can generally comprise providing a database for storing and/or maintaining a set of records. The records can include various types of financial information. A database operator can access, receive, and/or utilize financial information records from a plurality of sources including pre-existing databases and/or lending institutions. For example, a database operator can configure a fraud detection system to compare a first data record to a second data record to determine whether the two records are preliminary matches. The first data record may be received from a lending institution and the second data record may include pre-existing stored data. Records can be preliminary matches if they have certain data in common. When records represent loan applications, for example, the data can include any one or more of borrower names, borrower SSNs, and real property addresses for which a mortgage loan is requested.
  • Preliminary matches can also be compared for inconsistent information for fraud detection. If inconsistent information is found, the inconsistent preliminarily matching records may be flagged. The inconsistent information need not be the same category of information examined to determine preliminary matching. For example, two application data sets with the same borrower name or property address but with different appraisal values can be flagged in the database.
  • Embodiments of the present invention also enable report generation so that end users can review results of data analysis. In some embodiments, end users may be system subscribers that submitted one or more data records to a fraud detection system. Reports preferably show results of data comparisons in a format easily and readily understood by end users. In some embodiments, it may be preferable that a database operator can report whether records were preliminary matches and also whether the two records were flagged as inconsistent as well.
  • Generally, fraud detection embodiments of the present invention are configured to receive input data records. Such data input can be provided by end users who are using embodiments of the present invention to detect fraud in a financial loan environment. As records are received from end users, received records can be compared with other records. Comparisons can be made initially upon receipt and also conducted at predetermined frequencies to continue monitoring for possible fraudulent activities.
  • To implement periodic, frequent comparisons, records can undergo one or more waiting periods between comparisons. Waiting periods can be many time periods, for example, approximately one day, such that a set of comparisons occurs daily for each record. During waiting periods, additional records can be received. At the end of a waiting period, a first received record can be compared to one or more second records. Based on these new comparisons, reports can be generated for subscribers. Reports can contain analysis of records submitted after a first record and during the course of receiving additional records. This feature of embodiments of the present invention enables continuous monitoring of loan transaction to detect fraudulent activities occurring within close time periods. Comparisons can occur periodically by repeatedly comparing already received records to newly received records.
  • Periodic comparisons can continue until the termination of a predetermined holding period. During a holding period, received records can be retained in a database in an active state, meaning periodic comparisons continue. The holding period can be, for example, approximately 30 days to approximately 90 days in some embodiments. For example, each stored or received record can be compared daily to other stored or received records for 61 days after the record is submitted to a database operator or entered into the database. Other holding period lengths may also be used in accordance with embodiments of the present invention (for example, ranging between 120 days to twelve months).
  • On a larger scale, fraud detection system embodiments of the present invention can be configured to receive a plurality of records from a plurality of users (e.g., contributory subscribers). Periodically in bulk, or individually as they are received, records are stored in a database. After a new record is received, it can be compared to records preexisting in the database. A database operator alone or in combination with a reporting program can report comparison results to subscribers submitting records and to subscribers that records submitted records preexisting in the database. The results in such reports can be ordered according to a two-tier weighted algorithm.
  • As used herein, a database operator need not be a human being. For example and not limitation, the database operator can be a computer system, a computer program, one or more modules of a computer system, or a combination thereof. A receiving module can receive records submitted from outside sources, including system subscribers or end users. A comparing module can compare records to each other. A reporting module can report results to subscribers. Additionally or alternatively, a database operating module can conduct one or more of the tasks performed by the database operator.
  • Operations of the database operator and of the database system can be performed by a computer system. Accordingly, such operations can be stored on a computer-readable medium of expression, and performed by a computer processor. In addition, the various modules discussed herein can be implemented as hardware, software, or a combination thereof.
  • In another embodiment of the present invention, a fraud detection system to detect fraud in a financial loan application process by analyzing a plurality of data from multiple sources is provided. The system can generally comprise one or more interfaces (e.g., communication interfaces) to receive data, a database, and a processing module. The interfaces can be configured to receive data from a plurality of unique data sources. The data sources can comprise information received from unique end users and existing unique databases. The data can comprise data records comprising at least one of information related to a financial loan application, parties involved in a loan transaction, and property involved in a financial loan. The database can be configured to receive data from a plurality of unique data sources and to store data with an identifier configured to distinguish data received from unique data sources.
  • The database can include a processing module or may be operatively coupled to a processor configured to implement a processing module. The processing module can be configured to determine if one or more data records contain one or more matching data fields and flag data records containing one or more matching data fields. Matching information can be stored in a match table, which can be a stand alone memory or associated with the database. The processing module can be further configured to determine if one or more of flagged data records contain different information in one or more other data fields contained in the data records. And data records flagged to contain different information can be stored in the match table.
  • Fraud detection systems according to the present invention can also include other features. For example, matching data fields can comprise information about property involved in a financial loan and at least a party involved in a loan transaction. In addition, a system can also include a reporting module configured to report information concerning data records containing one or more matching data fields and information concerning the flagged data records containing different information in the one or more predetermined data fields. A reporting module can be further configured to order information contained in a report at least partially based on different information contained in the one or more data fields and a magnitude of difference. In another aspect, a processing module further can be configured to place received data records in an active state for a predetermined holding period and periodically analyze active-state data records relative to existing data and data received after the active-state data records. Predetermined holding periods can range from approximately one day to approximately one year. In yet another aspect, a processing module can be configured to determine if one or more of data records contain substantially similar addresses for a real estate property involved in a loan transaction.
  • In yet another embodiment of the present invention, a method for detecting fraud in a financial credit or loan application process is provided. A fraud detection method can generally comprise providing a database operatively configured to receive data comprising details concerning a financial credit or loan application and to store received data as one or more first data records. A fraud detection method can also include configuring a database to receive data from a plurality of unique data sources and store data with an identifier for distinguishing the unique data sources. The data can comprise at least one of, one or more parties involved in a loan transaction, and property involved in a financial application process. A fraud detection method can also include providing a data comparison module operatively configured to flag the one or more first data records containing similar data in one or more predetermined data fields by storing matching information in a table. Also, a fraud detection method can include configuring a data comparison module to determine if the flagged data records comprising at least one data field with similar data comprise one or more other data fields having inconsistent data by storing inconsistent data in the table.
  • Fraud detection methods according to the present invention can also include other features. For example, a method can include configuring a database to provide reports comprising details related to flagged data records comprising at least one data field with similar data and details related to flagged data records comprising data fields with inconsistent data. A method can also include configuring a database to receive data from a plurality of end users and the one or more databases via a communications network. A method can also include providing a data comparison module operatively configured to flag data records containing similar data in one or more predetermined data fields by determining if the one or more data records contain data fields having similar property address information or similar borrower information.
  • Fraud detection methods of the present invention can also include additional aspects. As an example, a method can include configuring a database to provide reports to a user with data ordered based on results of a two-tier weighted algorithm. Also, a method can include holding data records in the database for a predetermined holding period and configuring the data comparison module to compare existing data records to data records received after the existing data records at predefined intervals. A method can also include operatively configuring a database to receive lender originated data and user incident report data. In addition a method can include configuring a data comparison module to receive professional license information from one or more existing databases to determine if a licensed party involved in a loan transaction is properly licensed and has any past professional sanctions.
  • In still yet other embodiments of the present invention, computer-readable media containing code for execution by a processor are provided. These embodiments can include stored computer readable instructions to execute a method for detecting fraud and/or implement a system for detecting fraud. Such code can include instructions for providing a database configured to receive data from a plurality of unique data sources and associate received data with an identifier to distinguish the unique data sources. The data can comprise data records having data fields. The data records can comprise information related to a financial loan application, parties involved in a loan transaction, and property involved in a financial loan. Another instruction in the code can include determining whether one of the data records has a data field containing common data to at least one other data field contained within at least one of the other data records. And another instruction in the code can include determining whether data records having at least one data field in common have other data fields having disparate data. And still yet another code instruction can include providing a report comprising data records based at least partially on the identifier. The report can include a listing of data records with data fields having common data and data records containing data fields having disparate data.
  • Computer-readable medium embodiments having stored code can also include additional aspects. For example, within the code instructions can be provided such that at least a portion of data records contain mortgage loan application information submitted by unique users and at least another portion of the data records contain information obtained from pre-existing databases containing borrower information. Such code can enable a dual pipeline feature as discussed herein. Another exemplary aspect includes providing code instructions such that data fields are reviewed for common data, including property address information, to determine if a single property is subject to multiple loan applications. Code instructions can be provided on a medium to repeatedly determine on a pre-determined basis whether data records have data fields containing common data relative to other data fields contained within other data records, and whether data records having data fields in common also have data fields having disparate data.
  • Other aspects and features of embodiments of the present invention will become apparent to those of ordinary skill in the art, upon reviewing the following description of specific, exemplary embodiments of the present invention in conjunction with the accompanying figures. While features of the present invention may be discussed relative to certain embodiments and figures, all embodiments of the present invention can include one or more of the advantageous features discussed herein. In other words, while one or more embodiments may be discussed as having certain advantageous features, one or more of such features may also be used in accordance with the various embodiments of the invention discussed herein. In addition, while discussion contained herein may, at times, focus on mortgages and mortgage application processes, embodiments of the present invention can also be used in other financial and financial application settings. In similar fashion, while exemplary embodiments may be discussed below as device, system, or method embodiments it should be understood that such exemplary embodiments can be implemented in various devices, systems, and methods.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates a block diagram of a fraud detection system according to some embodiments of the present invention.
  • FIG. 2 illustrates an information flow diagram in a fraud detection system according to some embodiments of the present invention.
  • FIG. 3 illustrates comparing one record to one or more records in a fraud detection system according to some embodiments of the present invention.
  • FIG. 4 illustrates a fraud detection method according to some embodiments of the present invention.
  • FIG. 5 illustrates an information flow diagram for fraud detection system users according to some embodiments of the present invention.
  • FIGS. 6A-6F illustrate exemplary reports provided by a fraud detection system according to some embodiments of the present invention.
  • FIG. 7 illustrates a method of fraud detection according to some embodiments of the present invention.
  • FIG. 8 illustrates a method of an incident submission process according to some fraud detection embodiments of the present invention.
  • FIG. 9 illustrates a method of authenticating and verifying entities and professionals involved in a financial application process according to some embodiments.
  • DETAILED DESCRIPTION OF PREFERRED & ALTERNATIVE EMBODIMENTS
  • To facilitate an understanding of the principles and features of the various embodiments of the invention, various illustrative embodiments are explained below. Indeed, embodiments of the present invention are described below for detecting signs of fraud in mortgage loan applications. Embodiments of the invention, however, are not so limited. Rather, embodiments of the invention can be used to detect fraud or to track patterns, similarities, or dissimilarities in many fields. For example and not limitation, embodiments of the present invention may be used to detect fraud in credit card applications, employment applications, and personal property loan applications.
  • The various embodiments of the present invention assist users in detecting fraud. To assist users in detecting fraud, embodiments of the present invention are configured to alert users of potential fraudulent activity so that users can further investigate the circumstances to mitigate fraud. For example, embodiments of the present invention can enable the mortgage lending community to more accurately determine the authenticity of the borrower/applicant wishing to obtain a mortgage for real estate.
  • In a mortgage fraud scenario that utilizes an identity, fraudsters may falsify information related to names, social security numbers, or both in an effort to create false mortgage transaction and escape detection. By simply transposing a few numbers in a social security number a fraudster can assume an identity and begin establishing a historical record of credit as a part of the process for stealing the identity. Additionally, multiple names can be used with a single social security number in an effort to thwart off detection. The alternate names are submitted to multiple lenders to avoid being spotted during the process. Lenders are currently vulnerable to this type of attack because there is no system that enables identity variances across multiple transactions while verifying information provided by borrowers to lenders in a loan transaction.
  • As discussed below with reference to exemplary embodiments of the present invention, the various embodiments can be used to help mitigate potential fraudulent activities. The below discussion, while provided in various sections, should be read as a whole as to applying to this entire disclosure and the various discussed embodiments. Thus, discussion of one or more features in a certain section can also be pertinent to other features and embodiments discussed in one or more other sections.
  • Fraud Detection System & Components Generally
  • Referring now to the figures, wherein like reference numerals represent like parts throughout the views, exemplary embodiments of fraud detection systems and methods are described in detail. FIG. 1 illustrates a diagram showing components of a fraud detection database system 100 according to some embodiments of the present invention. The database system 100 can generally comprise at least one database manager 110, at least one database operator 120, one or more users 130, and a database 140. The database system 100 may also comprise one or more external databases 150 for providing additional information to the database 140. The database 140 (and/or the database operator 120 or the database manager 110) can be configured to access one or more external databases 150 to provide additional data to the system 100 to provide enhanced fraud detection capabilities.
  • As shown by the various arrows in FIG. 1, the illustrated components of the system 100 can be networked together. Such networking enables the system's 100 components to exchange and share data. For example, users 130 are preferably networked with the database operator 120 via a network, such as network 160. Network 160 may be a private or public network. In a currently preferred embodiment, the network 160 can include the internet. This configuration enables users 130 to access and utilize fraud detection via an internet, web-based interface. In this manner, users 130 can access an internet portal to query and search data maintained in the database 140 to obtain desired information. As discussed in more detail below, the database operator 120 can include various processing modules for automated querying of the database and for reporting results to users. Such reporting can occur based on user defined search queries and user defined search frequencies. The network 160 can also be a private network and also have both public and private features to enable implementation of varying security protocols.
  • Although several of the components in the system 100 are shown as stand-alone components, certain of the components may be integrated together. For example, one or more of the database manager 110, the database operator 120, and the database 140 can be integrated together in a single physical device. In such an embodiment, a single physical device enables a centralized database system 100 at a single location. In addition, one or more of the database manager 110, the database operator 120, and the database 140 can have various components capable of implementing required functionality. For example, the database 140 may have one or more data storage units located at one location or located at different locations. It should be understood that if one or more of the database manager 110, the database operator 120, and the database 140 have several components such components can be networked together to enable system functionality.
  • To implement the fraud detection system 100, each system component can have various operation functions. For example, the database manager 110 can initialize and maintain the database 140. The manager 110 can perform, or cause to be performed, maintenance required by the database 140. The manager 110 can also ensure that users 130 execute legal and other documentation desirable for participation in the database system 100.
  • The database operator 120 can be configured to perform database tasks as desired. For example, the database operator 120 can conduct queries on the database 140, and in response to the queries, the operator 120 can receive data from the database 140. Based on data received from the database, the operator 120 can output reports to users 130. The database operator 120 can also accept data submitted by users 130 and can transfer the submitted data to the database 140. As discussed herein, users 130 can provide data related to or concerning financial loan transaction applications (e.g., mortgage loan information and fraud incident information). The database operator 120 is also preferably configured to enable and accept batches of data from many different users 130. The system 100 is contemplated, in some embodiments, as a very dynamic system that is on a real time basis receiving information from many different sources and reporting information to users in response to queries. Use of such raw, current data for analysis can help to enable real time detection of fraud.
  • The database operator 120 can also be configured to have numerous operational characteristics. For example, in some embodiments, the database operator 120 can include web service functions to enable an internet interface between users 130 and the database. Inclusion of web service functions enables users to access the fraud detection system 100, to query the database 140, and obtain data in an effort to learn additional information about parties to a financial application. Thus, database operator 120 can include various processing modules configured to search and analyze data according to predetermined data tests. Such data tests can compare data from various sources on a wide-scale basis and provide results of the comparisons to users. In some embodiments, the database operator 120 can be, for example, a module of the database 140 capable of executing computer code. Additionally, and/or alternatively, the database operator 120 can be a device, a segment of code, a computer system adapted to operate in conjunction with the database 140, a database operating module of a computer system, and/or a combination thereof. In currently preferred embodiments, the database operator 120 can comprise a plurality of modules, such as, for example, a receiving module comprising data interfaces for receiving records, a comparing module for comparing records, and a reporting module for reporting results. The database operator 120 can also provide an interface enabling users to submit and obtain data to the database 140.
  • Users 130 of the system can be various types of people or entities desiring assistance in detecting fraud. For example, users 130 can be subscribers who are entities, such as mortgage lenders, banks, or mortgage brokers, who subscribe to the database system 100. Users can also include mortgage bankers, financial lending institutions, real estate agents, appraisers, closing agents, mortgage portfolio investors, home builders, title companies, loan servicers, loan consolidators, accountants, attorneys, banks, direct consumers, other mortgage related agencies, and non-mortgage related agencies. Users 130 may also include law enforcement personnel and others involved in investigating and prosecuting fraudsters.
  • In addition to using the system 100 to obtain information about those involved in financial application processes, users can also provide information to the system 100. For example, users 130 can submit records to the database operator 120 for submission to the database 140. Such records can include mortgage loan application information (e.g., Uniform Residential Loan Application—Form 1003) and also fraud incident information. By accepting information from users, the system can advantageously obtain information from users who interact with mortgage-related transactions on a daily basis thereby providing a dynamic system capable of obtaining current and fresh data. This enables users to cross check their data with other users and enables the system 100 to consider data from numerous users in an effort to flag possible fraud conditions.
  • Users 130 can also receive reports of potential fraud from the database operator 120. Upon receiving such results, users 130 can take steps to investigate one or more flagged loan transactions. In currently preferred embodiments, the database operator 120 enables users to log in to the system 100 and view transactions in the user's internal pipeline and transactions external to the user's pipeline. For example, lender A may desire to track loan transactions in its pipeline for potential fraud activity and also track loan transactions external to lender A's pipeline. In this manner, lender A can track loans in the pipeline of other lenders to see if any loan transactions in lender A's pipelines contain similar person data to transactions of other lenders. The dual pipeline feature advantageously enables users (such as brokers and lenders) to cross check transactions in their pipeline with transactions in one or more users' pipelines. As a result, this feature can help inform users if their clients are also interacting with other users who have submitted data to the database 140.
  • The database 140 maintains the records submitted via the database operator 120. The records can comprise data records (or data sets) with various data fields. Preferably, the data records have a uniform format with uniform data fields. Such uniformity enables the database operator 120 to compare and contrast data contained in the data records to determine existence of possible fraudulent activity. In some embodiments, the database operator 120 and/or the database 140 can validate received data records to ensure appropriate format. The volume of records submitted to the database 140 can be, for example, upwards of approximately one thousand per day per user 130. Preferably, the database 140 is scalable to enable receipt of less or more records on a daily basis as desired. The database 140 is preferably configured to maintain this volume of data. The database 140 is preferably also a storage facility capable of storing large amounts of data.
  • Provision & Receipt of Data for Investigating Fraud
  • FIG. 2 illustrates an information flow diagram in a fraud detection system according to some embodiments of the present invention. For example, FIG. 2 specifically illustrates a flow diagram 200 of information from various system users 130 to a fraud detection system 100. In one aspect, a first borrower 210, borrower 1, applies for a loan through a mortgage broker 220. In doing so, borrower 1 210 discloses certain application information to broker 220. In turn, broker 220 discloses this information to a user 130, lender 1 230. Lender 1 230 submits to a database operator 120 a record relating to and containing information contained in borrower 1's loan application. The database operator 120 received this record and enters the record into the database 140. In some instances, the provided record may be used to update or refresh an existing record.
  • FIG. 2 also illustrates additional users 130 providing data to the fraud detection system 100. Indeed, FIG. 2 shows that a second borrower 240 provides mortgage loan application directly through a second lender 250. The second lender 250 can submit borrower 2's 240 application information to the system 100 via the database operator 120. The database operator 120 can submit the information to the database 140 as a new record (or an updated or refreshed version of an existing record). While not illustrated, it should be understood that a plurality of users 130 can provide information to the fraud detection system 100 at varying rates as desired. In addition, while certain users shown in FIG. 2 are directly communicating with the fraud detection system 100, all users 130 can be configured to communicate with other users through the fraud detection system 100.
  • As users 130 may submit potentially confidential information to the database 140, it may be desired that involved parties enter into agreements for protection. For example, users 130 can certify that they understand the database system 100 reports tips and leads only, and that decisions of whether to accept or deny loan applications should not be made solely based on such reports. Users 130 can also certify that their use of reports will comply with applicable laws and regulations, including the Fair Credit Reporting Act (“FCRA”). Further, it may desired to have users 130 indemnify the database operator 120 and the database manager 110. The database manager 110 can ensure that these legal documents are executed.
  • For any single loan application, the corresponding record submitted to the database operator 120 by a subscriber 130 can consist of originator information as well as borrower information from a loan application, such as the Uniform Residential Loan Application. Originator information, or originator data, can include data on an entity originating the loan application. For example, originator information can include the name of a mortgage broker and other information related to and unique to the mortgage broker. The following list represents a non-exclusive list of data that may be included in originator information submitted to the database operator 120 in a data record:
      • Contract Date
      • Contract Price
      • Realtor Name
      • Realtor License Number
      • Realtor Company Name
      • Originator Name
      • Originator Company Name
      • Originator License
      • Originator Address
      • Appraiser Name
      • Appraiser License Number
      • Appraiser Company Name
      • Appraisal Value
      • Comparable Property Addresses (×6)
      • Comparable Property Values (×6)
      • Closing Date
      • Closing Agent
      • Title Company
      • Escrow Agent
      • Escrow Company
  • Borrower information, or borrower data, comprises data supplied by the borrower in a loan application. This data can be based on documentation from borrowers. The following list presents a non-exclusive list of borrower information that can submitted by subscribers 130. Not all listed items need be submitted by every subscriber in every instance, and additional data may be submitted in addition to or in lieu of the listed items.
      • Borrower Last Name
      • Borrower First Name
      • Borrower Middle Name/Initial
      • Borrower Suffix (Jr/Sr/II/III—etc.)
      • Borrower SSN
      • Borrower ITIN
      • Borrower Current Address
      • Borrower Prior Address
      • Seller/Owner Last Name
      • Seller/Owner First Name
      • Seller/Owner Address
      • Subject Property Address
      • Subject Property Parcel ID Number
      • Subject Property—Year Lot Acquired
      • Subject Property—Original Cost
      • Subject Property—Amount of Existing Liens
      • Subject Property—Year Acquired
      • Subject Property—Original Cost
      • Subject Property—Amount of Existing Liens
      • Subject Property—Purpose of Refinance
      • Subject Property—Cost of Improvements
      • Subject Property—Status of Improvements
      • Loan Amount
      • Source of Down Payment, Settlement Charges and/or Subordinate Financing
      • Current Employer Name
      • Current Employer Address
      • Current Employer Phone
      • Current Employment—Years on this job
      • Current Employment—Position/Title
      • Current Employment—Self-Employment Flag
      • Prior Employer Name (×2 instances)
      • Prior Employer Address (×2)
      • Prior Employer Phone (×2)
      • Prior Employment—Years on job (×2)
      • Prior Employment—Position/Title (×2)
      • Prior Employment—Monthly Income (×2)
      • Prior Employment—Self-Employment Flag (×2)
      • Asset Account—Company Name (×4 instances)
      • Asset Account—Company Address (×4)
      • Asset Account Number (×4)
      • Asset Account Balance (×4)
      • Asset×(Cash or Mkt. Value of all) Real Estate Owned
      • Liability Account—Company Name (×6 instances)
      • Liability Account—Company Address (×6 instances)
      • Liability Account Number (×6)
      • Liability Account—Monthly Payment (×6)
      • Liability Account—Months Left to Pay (×6)
      • Liability Account—Unpaid Balance (×6)
      • Monthly Income—Base Monthly Income
      • Monthly Income—Overtime
      • Monthly Income—Bonuses
      • Monthly Income—Commissions
      • Monthly Income—Dividends/Interest
      • Monthly Income—Net Rental Income
      • Monthly Income—Other
      • Monthly Housing Expense—Rent
      • Monthly Housing Expense—1st Mortgage (P&I)
      • Monthly Housing Expense—Other Financing. (P&I)
      • Monthly Housing Expense—Hazard Ins.
      • Monthly Housing Expense—RE Taxes
      • Monthly Housing Expense—Mort. Ins.
      • Monthly Housing Expense—HOA Dues
      • Monthly Housing Expense—Other
      • RE Owned—Address (×3)
      • RE Owned—Rent, Sold or Pending Sale (PS) Flag (×3)
      • RE Owned—Present Market Value (×3)
      • RE Owned—Amount of Mortgages/Liens (×3)
      • RE Owned—Net Rental Income (×3)
      • Liens/Judgments
      • Bankruptcies
      • Foreclosure
      • Occupancy Status
      • Application Date
      • Purpose of Loan
      • Loan Type
      • Transaction Details—Purchase Price
      • Transaction Details—Alterations, Improvements, Repairs
      • Transaction Details—Refinance
      • Transaction Details—Estimated Prepaids
      • Transaction Details—Estimated Closing Costs
      • Transaction Details—Subordinate Financing
      • Transaction Details—Borrower CC paid by Seller
      • Transaction Details—Other Credits
      • Transaction Details—Cash from/to Borrower
      • Declarations—Outstanding Judgments (Y/N)
      • Declarations—Declared Bankruptcy in past 7 yrs (Y/N)
      • Declarations—Subject of foreclosures, DIL in past 7 yrs (Y/N)
      • Declarations—Party of a lawsuit (Y/N)
      • Declarations—Obligated on any “problem” loan (Y/N)
      • Declarations—Is any part of down payment borrowed? (Y/N)
      • Declarations—Co-maker or endorser on a note? (Y/N)
      • Declarations—Are you a U.S. citizen (Y/N)
      • Declarations—Do you intend to occupy property (Y/N)
      • Borrower Phone Number
      • Amortization Type
      • Credit bureau scores and other bureau data
      • Occupation information
      • Number of homes purchased
  • Users 130 can provide data to the system 100 in a variety of manners. In some embodiments, data can be provided on a batch basis and in others on a single record basis. Transfer of batch data can occur at random times or in accordance with a predetermined data transfer protocol. For example, some users may desire to transfer loan application information on a daily basis as loan transactions are initiated and as loan transactions move through a lifecycle process. Alternative manners of providing data to the detection system include submitting incidents of fraud data and commenting on existing fraud scenarios. By enabling users to submit transaction data to the system 100, the system 100 can advantageously receive fresh raw data to analyze for potential fraud occurrences and provide reports indicating possible fraud to system users.
  • Analyzing, Testing, & Processing of Received Data
  • As embodiments of the present invention receive data from users, the data can be analyzed for possible occurrences of fraud. When such fraud occurrences are determined to exist for one or more transactions (e.g., a mortgage loan application), embodiments of the present invention can flag such occurrences so that users can further investigate flagged transactions. To investigate possible fraudulent occurrences, fraud detection systems according to embodiments of the present invention generally compare received records to each other in an effort to locate possible fraudulent activity. In addition, embodiments of the present invention can also be configured to access already existing external databases to obtain additional data for comparison to received records from users. Data comparison of data records can be done on a data field basis to determine if disparate data exists and to determine a magnitude of difference between data fields.
  • FIG. 3 illustrates comparing one record to one or more records in a fraud detection system according to some embodiments of the present invention. As illustrated, FIG. 3 shows a diagram showing how data records 310 are compared to other records in a database according to some embodiments of the present invention. For example, a first exemplary record 312 can be submitted to the database 140 from a user 130 via the database operator 120. After submission, and periodically for a predetermined period, the first record 312 can be compared to other records 310 in the database 140 (other records are shown as Records 2, 3, 4, through N). By comparing records to each other, fraud detection systems according to embodiments of the present invention can determine if applicant information differs from existing or other information sources across many numbers of records. By performing such checks, the fraud detection system can flag possible fraud occurrences and report the same to users.
  • In currently preferred embodiments, comparison of records can include multiple predetermined checks. For example, comparing the first record 312 to another record 310 can generally comprise two checks. These checks can be, but need not be, performed by the database operator 120 or a processing module implemented in one or more components in a fraud detection system.
  • A first check can include determining whether records are matches, or preliminary matches. Preliminarily matching records 310 can comprise similar information in certain data fields. For example, and not limitation, records 310 with the same borrower name, the same property location or address, and/or the same social security number can be deemed matches. In alternative embodiments, other data records can be checked for consistent data in certain data fields (such as those in the above provided lists). Data records having consistent or matching data in one or more predetermined fields can be flagged for subsequent processing. In the event that records do not contain consistent data in one or more predetermined fields, no further comparison may be required. Alternatively, data records having inconsistent data in data fields may be flagged for subsequent processing.
  • A second check can determine if records flagged as having consistent data in one or more data fields have inconsistent data in various other data fields. For example, a second check can determine if records flagged as matches include inconsistent data, such as contradictory data in such fields as appraisal value, loan amount, borrower SSN, and borrower account/income values. If inconsistent data is found in one or more of the records 310, the records 310 can be flagged. For example, and not limitation, if a first record 312 includes a borrower income of $55,000, and another record 310 includes a borrower income of $155,000, the two records 310 can be flagged. Such disparate data may be a sign of a fraudulent occurrence, and in response, the database operator 120 can return flagged records 310 to subscribers 130 in the form of reports. Similarly, the database operator 120 can also return matches to subscribers 130 in reports.
  • While FIG. 3 may suggest that comparisons are implemented through a direct comparison between records 310, this particular implementation is not required. For example, and not limitation, digital references to the records 310 can be sorted over borrower social security numbers, borrower names, property locations, or any combination of these three (as well as the above-listed data fields). Accordingly, determining matches between records can include examination of records 310 nearby the record with respect to the sorted order.
  • FIG. 4 illustrates a method 400 of detecting fraud according to some embodiments of the present invention. Those skilled in the art will understand that method 400 can be performed in various orders (including differently than illustrated in FIG. 4), additional actions can be implemented as part of a method embodiment, and that some actions pictured in FIG. 4 are not necessary. In addition, it should be understood that while certain actions illustrated in FIG. 4 may be discussed herein as including certain other actions, these certain other actions may be carried out in various orders and/or as parts of the other actions depicted in FIG. 4. Method embodiments of the present invention, such as the one depicted in FIG. 4, may be implemented with the fraud detection devices and systems discussed herein.
  • The method 400 generally initiates by receiving data from one or more data sources. The received data can be stored in one or more databases. Data sources can include one or more contributory users as well as one or more existing databases. Records may be received on a routine frequent basis (e.g., daily at a set time or bi-weekly) or as desired (e.g., on a random, unscheduled basis). Indeed, users may submit records on a nightly basis and a fraud detection system may access and/or obtain information stored in one or more other databases as needed. It is contemplated by the inventors that many data records (e.g., 1000 or more per day) will be received to enable the various fraud detection methods to assist in fraud detection. The method 400 can also include verifying that a submitted data record is submitted by a valid subscriber by checking a subscriber registry.
  • Upon receiving data, the method 400 may also include verifying that the received data is compliant with a predetermined data record format. Verification ensures that data originating from various and sometimes disparate sources, is in a data record format to enable data comparison and analysis. The specific format of a data record (which can include any of the data fields listed herein as well as other desired data) is not important. What is important is that data records have the same format or have corresponding data fields. For example, in some embodiments it may be desired to have data records with the same data fields within the data record (e.g., same data record layout). This configuration can readily enable comparison of data fields within data records and accurate, efficient analysis of data fields.
  • The method 400 can also include an initial review of records. The initial review can include iterating through many records as illustrated at 405. In some embodiments active and inactive records may be reviewed while in other embodiments only active or inactive records may be reviewed. Records may be changed from active to inactive or vice versa depending on a number of factors, including user selection, data threshold, or time stamp threshold. In addition, active or inactive status may be used to remove and/or add data records in and out of a user's internal pipeline. Records may also be updated during a lifecycle of an application process. The initial review may also include data record verification as discussed above. The process of initial review preferably yields a grouping or set of records (e.g., all active records) for further analysis.
  • Further analysis can include searching selected records to determine if the records have one or more common data fields. Such data fields may be deemed critical data fields for fraud detection purposes in that the data within these fields holds unique significance relative to other data fields. As illustrated at 410, the method 400 can include a further analysis to determine whether records have similar property address information. To do this, property address fields in each record are compared with other records. The method 400 may also include searching for records with, for example, similar borrower names or borrower social security numbers. Still yet, the method 400 can include searching for any combination of critical data fields, in addition to those discussed above, as desired by a user.
  • The method 400 can also include standardizing records. Standardization of records can occur at any time during implementation of the method 400. For example, standardization can occur prior to or after record verification and also prior to of after comparison of records. Standardization can assist in ensuring that data is in similar format thereby enabling efficient verification and comparison. Standardization can include converting received data to a standard form. As an example of standardization, address data (e.g., borrower addresses) can be converted to United States Postal Service format. This way, for example, St. and ST are converted to STREET. As another example, name prefixes (e.g., Mr., Ms., Mrs., etc.) and suffixes (e.g., Sr., Jr., III, etc.) can also be standardized such that common abbreviations and/or spellings are the same. A used standard for data is not important; rather, ensuring that data is standardized for ease of comparison is important for embodiments utilizing data standardization. In some embodiments, data standardization may only occur on some data fields while in others, data standardization may occur on all received data fields. Standardized data elements will, preferably, render the data in the same format.
  • As shown in FIG. 4, the method 400 can include determining whether preliminary matches between data fields in various data records are found. As an example, a fraud detection system can determine whether one or more matching records are found for a first record as a result of comparing predetermined data fields of various data records. As discussed herein, a preliminary match analysis can determine if data records have similar SSNs, borrower names, property addresses, or any combination thereof. If such matching records are found, the method 400 may denote that one or more preliminary matches have occurred. If no matching records are found, the method 400 can proceed to 450. And if matching records are found, the method can proceed to process 418 to determine any potential secondary matches.
  • As shown, process 450 inquires whether any new of unreviewed records exist. If such records exist, the method 400 can initiate again at 405. If no such records exist, the method 400 may end and await receipt of additional records and/or user instruction. If a preliminary match to other records is not found, the method 400 can then return that a loan application has no corresponding matches. As a result, the method 400 may deem a loan application to be a low risk application. In some embodiments, low risk applications may not be searched again and may also be flagged for reporting or non-reporting low risk applications to users depending on user reporting preferences.
  • As mentioned above, if a preliminary match is found by process 415, the method 400 can proceed to process 418 to determine potential secondary matches. As shown, process 418 can include several processes to determine potential secondary matches. For example, if a preliminary match is found across property address fields at 415, the method 400 can compare each field of matching records. The secondary match analysis 418, in some embodiments, is advantageously configured to determine if any records having preliminary matches (e.g., have matching property addresses) have data fields with disparate information (e.g., different appraisal values). Thus, process 420 can include comparing records to locate data fields with disparate information. A matching table can be provided for storing matching records, or references or pointers to such records. The matching table can also be configured to store information about matches, including whether a matching record was found in an external database.
  • After a matching record is found, the method 400 can perform a field-by-field comparison to determine matching records at 425. To assist in determining matching fields, process 425 can provide matching indicators in a matching table. That it, if corresponding fields of records match exactly, an indicator of such exact match can be stored. For example, an “E” (denoting exact match) can be stored corresponding to an applicable field and record in a matching table. As another example, if data fields differ, then this can be indicated by storing an “N” (denoting no match) in an appropriate place in a matching table. And as another example, if data fields vary, a variance indicator can be recorded to indicate a degree of difference. The variance indicator may be used as a multiplier in a two-tier weighted algorithm as discussed below. Typically, a larger data variance in the data yields a larger variance value. For example, for an exact match (“E”), a variance value may be a zero (0), and for no match (“N”), a variance value can be a three (“3”). If a particular field contains multiple entries, each entry of the field can be compared to each entry of a corresponding field in a matching record.
  • The method 400 can also include applying weights to score loan application data records at 430. More specifically, one or more data fields in one or more data records can be weighted for importance. For example, in some embodiments, data fields of high importance for detecting fraud can be given higher weights relative to other data fields. Fields containing specific identifying information, such as borrower name or SSN can be provided with high weights, or the highest weights. Only fields with weights greater than zero need be compared for records with matching property addresses. Fields can be afforded a zero weight for strategic reasons or because those fields are not likely to indicate fraud. The weights, in combination with the variance between corresponding fields, can determine a relative significance of fraud (e.g., a score denoting potential fraud possibility). A relative significance of fraud can be used to determine a likelihood of fraud and also enable a user to take steps to further investigate. In some embodiments, weights can be implemented with a multiplier value.
  • As shown in FIG. 4, the method 400 can also include determining a score for a data record at 430. Data records as discussed herein can be loan applications so the method 400 can determine a loan application score indicative of possible fraud associated with a loan application. To determine a score for particular data records, for each data field in a data record matching a first record, a provided weight value can be multiplied by a variance to determine a field score. For example, an “E” value can be afforded a lowest variance value for a particular field, while an “N” value can be afforded a highest variance value for a field. Other variance values may also be utilized. Data field scores can be summed for a corresponding data record to determine a data record score. The method 400 can also include providing one or more fraud scenario based on variance amounts (e.g., determined “N” and “E” results). Table I below illustrates a triggering index that method 400 can implement as an additional testing feature.
  • The method 400 can also include similar scoring for additional data records by analyzing additional record matches at 435. As shown, process 435 can determine whether one or more additional records with a same property address, for example, as a first record are found in a database. If so, a set of field-by-field comparisons can occur for each such additional record. After all matching records have been found and compared field-by-field to the first record, the match scores can be summed to determine a total loan score at 440.
  • The loan score can denote a risk of fraud and also be used to determine a recommended level of due diligence. For example, if a loan score is high (meaning it indicates high risk of fraud), a high level of due diligence can be recommended to a user. In a similar fashion of a loan score is low (meaning it indicates a low risk of fraud), a low level of due diligence can be recommended to a user. In some embodiments, loan scores and due diligence levels can be provided on a numbered range (e.g., 1 to 10, or 1 to 100) and/or with “HIGH,” “MEDIUM,” or “LOW” labels. In currently preferred embodiments, loan score and due diligence level information can be provided to a user via a web-based interface enabling varying use of color indicators (e.g., red, yellow, green, etc.). In addition, in currently preferred embodiments, such information can be provided for each loan application in a user's loan application pipeline and also summarized based loan score and/or diligence level. Such grouping enables users to focus resources as needed on desired loan application groupings in an efficient manner.
  • As mentioned above, the method 400 can score loan applications to assist users in detecting mortgage fraud. Based on scoring results, and as shown as 445, the method 400 can also determine an alert status for a one or more data records (or loan applications) in a lenders pipeline. If the loan score is above, below, or consistent with a predetermined threshold or threshold range, the method 400 can flag one or more loan applications to alert one or more users who submitted a loan application. The flags can be alerts can be in the form of emails, text messages, blog entries, or many other communications. Preferably, the flags provide analysis information to users so that users can then determine any potential next steps in detecting any fraud associated with a flagged data record.
  • Upon issuing possible alerts for flagged data records, the method 400 may continue processing new or additional records at 450. If no such records are located, the method 400 can end or await further instruction. It is currently contemplated that fraud detection method embodiments of the present invention, like method 400, can review numerous data records in very short time frames all while continuing to receive additional, new, and/or updated records. Thus, embodiments of the present invention are contemplated as being dynamic in that record review of raw data continues on numerous records at any one time in addition to records continuously being added or updated with raw data information. Analysis of such raw data in accordance with embodiments of the present invention advantageously enables review of real-time data thereby yielding accurate and timely results to users.
  • Referring back to FIG. 3, the database operator 120 can compare records 310 for differences, as described above, and can alert subscribers 130 of these differences. The fraud detection system 100 can be configured to be primarily concerned with inconsistencies between loans applications, and can also be configured to report multiple similar applications that are not inconsistent. For example, users might desire to be made aware of loan-shopping. Loan shopping can be suggested by multiple consistent loan applications for the same borrower on the same property. If a user is aware of loan-shopping, then the subscriber can be prepared to make a competitive bid for the borrower's business.
  • As mentioned above, loan applications having certain fields with consistent data but having certain other fields with inconsistent data can be a fraud warning sign. Fraudulent loan applications typically include different borrower data across multiple loan applications for the same property. For example, and not limitation, records containing the same borrower name but different appraisal values can be deemed inconsistent. The database system 100 can be capable of further analyzing results, but at the least, the system 100 can preferably return reports indicating flagged records. Upon receipt of such flagged records, users 130 should perform due diligence to determine the cause of flagged inconsistencies.
  • Inconsistencies between records 310 need not be the result of fraud. For example, inconsistencies may arise due to human error, such as typographical errors. If requested loan amounts of a preliminarily matching pair are listed as $1,295,340 on one application and $1,295,430 for another, the subscriber 130 might determine that the inconsistency resulted from a typographical error. Thus, embodiments of the present invention can also be configured to determine a magnitude of difference between inconsistent data. Determining magnitudes of difference for certain data fields can also be indicative of possible fraud. Indeed, a user 130 might perform due diligence to determine whether a magnitude difference above a certain threshold comports with possible signs of fraudulent activity. Indeed, embodiments of the present invention can provide data elements triggering the variance. This enables users to determine if a typographical error or a true misrepresentation is a cause for the variance. For example, if a submitted appraisal amount is $345,700, a first matched loan triggered a variance to display $354,500, and a second match loan displayed $374,500. In this scenario a user can determine that both returned variances could be typographical errors due to transposing of numbers in the returned appraisal amounts.
  • Even if no typographical error occurred, there may be a plausible, legal explanation for the variance. For example, suppose preliminarily matching records 310 include requested loan amounts of $1,295,340 in one record 310 and $1,900,000 in the other. While this may be the result of fraud, the applications might also have been submitted at different times. The borrower's knowledge with respect to his own funds might have differed greatly between the submission times. A user 130 can be informed of this and then perform due diligence to verify the correct requested loan amount.
  • In some embodiments of the present invention, users 130 can monitor records over a lifecycle of a loan. For example, the database operator 120 can continue to monitor records with newer received records to continually monitor for possible fraudulent activity. As another example, records 310 can be compared to other records 310 periodically for a predetermined holding period. Indeed, in some embodiments a record 310 can be compared to other records 310 daily for a holding period of approximately 30 to approximately 90 days. Alternatively, additional exemplary holding periods can be 61 days and can range from 1 day to a complete year. Users can modify holding periods per submitted transactions by providing such search query information to the database operator.
  • Embodiments of the present invention also enable users to modify loan transactions provided in their respective pipelines. As mentioned above, users can submit information they obtain from applicants to a fraud detection system 100. The fraud detection system 100 can be configured to maintain various pipelines of applications segregated by users 130. This advantageously enables users to monitor their borrower-specific applications with an internal pipeline and then applications of other users via an external pipeline. In addition, fraud detection system 100 embodiments of the present invention enable users to modify transactions maintained in their pipelines. For example, as loan transactions near the end of a lifecycle or are completed for other reasons, users can provide this information to the database operator. In doing so, users can modify the number of transactions contained within their pipeline. And in similar fashion, fraud detection system embodiments of the present invention can be configured to provide updated information to users when data in a data record changes or corresponds with another data record maintained in the database. These features of embodiments of the present invention enable users to maintain records in their pipeline as desired and also control how reports are provided to them by the system 100.
  • In other embodiments, and as discussed in more detail below, a fraud detection system 100 can perform credential checks on those involved in a loan transaction. For example, a database operator 120 can verify that professionals included in originator information hold valid credentials. A credentialed list can be maintained in the database 140 for each subscriber 130. Alternatively, the database operator 120 and/or database 140 can be configured to access one or more external databases to obtain credential information. A credentialed list can include, without limitation, a list of known mortgage brokers and licensing information. Originator information can be compared to one or more credentialed lists for one or more users 130. Additionally or alternatively, originator information can be compared to a system credentialed list, which can be maintained for the benefit of all or a set of the users 130. If originator information fails to match any item of a relevant credentialed list, users 130 can be alerted.
  • Reporting Potential Fraudulent Activities for Further User Investigation
  • FIG. 5 illustrates a flow diagram of information from the fraud detection database system 100 to users 130 according to some embodiments of the present invention. The database operator 120 can retrieve data from the database 140, preferably by way of queries to the database 140. The database operator 120 can send reports to the users 130. The database operator 120 can also send reports to the database manager 110, which the manager can use to ensure the database system 100 is running as desired. For example, the database manager 110 can implement administrative checks and processes to ensure that a fraud detection system is operating as desired.
  • Reports to users 130 can list all or a subset of preliminary matches, and can list all or a subset of flagged matches. Summary reports can highlight inconsistent data of flagged matches. As comparisons can be conducted periodically, a user 130 can receive multiple reports on a single loan application. Each report can be cumulative or, alternatively, each report may list only results of comparisons to new records 310. In addition, a report can include a due diligence level indicating a level of suggested diligence. A report may also include an identification verification score providing a score indicative of whether provided names and biographical information are consistent with various other data records.
  • Fraud detection system embodiments according to present invention can deliver and/or provide reports in electronic form. For example, reports can be provided in an email format and/or in response to real-time queries. If results are reported via a computer program in which a user 130 logs in to view results, the program can ensure that users 130 have an opportunity to sufficiently view the report. For example and not limitation, results can remain viewable until a user 130 takes an affirmative action, such as closing a window or deleting a report in a web-based interface. Users 130 can choose whether to receive cumulative reports or to receive only new results.
  • As mentioned above a user 130 can notify the database operator 120 when a loan application is removed from the subscriber's pipeline. If such a notification is made, the database operator 120 can remove the associated record 310 from the database 140 so that no further reports to that user 130 include comparisons with one or more associated records 310. Other users 130, however, may continue to receive notification in their reports of inconsistent information between their applications and the removed loan application. Reports can list results in a particular order based on preferences of the industry or of individual users 130.
  • The order can be determined based on a two-tier weighted algorithm for each element of borrower information in the records 310. Such an industry-generated algorithm may be derived based on feedback from top lenders and the Mortgage Bankers Association. In a two-tier weighted algorithm, inconsistencies in certain data elements can be more significant than inconsistencies in other data elements in identifying potential fraud. For example, an inconsistency in requested loan amount or appraisal value can be more significant than an inconsistency in current employer address. Also, a borrower's SSN may be a critical data element in determining a valid identity, acquiring credit history, verifying employment and income, etc. Because identity fraud and/or theft generally requires some level of falsification of an SSNs, SSNs can be weighted as a more important data element (e.g., as a first tier weight). Other data elements can be assigned a different weight (e.g., as a second tier weight). In reviewing SSNs, for example, embodiments of the present invention can determine variance severity for each SSN when other loans are found matching the property address of a submitted loan. If a number sequence in the SSN is either transposed (which could be SSN “Tumbling”) or different, a weighted multiplier can be assigned depending on a number of found incidents. In some embodiments, weight values can range from zero to thirty, depending on data's importance to a loan transaction.
  • In some embodiments, it is preferred that significant inconsistencies appear first in results lists of reports. As such the first tier in the weighted algorithm can consider the significance of the inconsistent data elements. The second tier can weigh the magnitude of the inconsistency. For example, a requested loan amount difference of $145,000 and $154,000 is less significant than a requested loan amount difference of $145,000 and $300,000. In some embodiments, when a variance is found for fields assigned a maximum field weight (or a weight above a certain threshold), a high risk alert can be assigned regardless of a total loan score.
  • A range of due diligence efforts can be undertaken by users 130 based on the type of inconsistencies shown in reports. For example and not limitation, if a user 130 sees multiple loan applications for the same property with different monthly incomes, the user 130 may implement tools to research and verify the true income of the borrower. For another example, if a user 130 sees multiple loan applications for the same property but with different borrower names, the cause could be a typographical error. If this is the case, the user 130 might perform due diligence in verifying the correct spelling of the name.
  • If a user 130 sees multiple loan applications across different lenders for the same property but with different names, the user 130 might suspect a shot-gunning scheme. In that case, the user 130 might verify the authenticity of the loan application. The database operator 120 can perform preliminary analysis on inconsistent preliminary matches. For example and not limitation, reports to users 130 can categorize inconsistencies to highlight the possibility that certain fraud schemes are underway.
  • FIGS. 6A-6F illustrate exemplary reports provided by a fraud detection system according to some embodiments of the present invention. The first row 610 of the reports in FIGS. 6A-6F lists headings for the items in the second row 620. The first item of the first row 610 states “Loan ID.” Accordingly, the first item in the second row of the first column gives the Loan ID of the primary record 310, the record 310 to which the report refers. The second item of the first row 610 states “Property Address,” and the second item of the second row 620 gives the property address on the loan application associated to the primary record. The next item of the first row 610 asks for the Loan ID of the primary record 310, which is given in the second row 620 below. The remaining items ask for Loan IDs of records 310 preliminarily matching the primary record, and the Loan IDs of those records are given below, on the second row 620.
  • Column 630 lists titles of data elements of the primary record 310. Column 640 lists the corresponding data for the primary record. The remaining columns 650 to the right of column 640 give the inconsistent corresponding data elements for the preliminarily matching records for which Loan IDs are listed in the second row 620.
  • The database operator 120 can return a preliminary fraud analysis in reports. For example, item 660 gives a possible fraud scheme based on a preliminary analysis of the inconsistencies in the records. For example, a possible fraud scheme can be returned based on the results of a number of IF-THEN-ELSE tests corresponding to known fraud schemes. These tests are based on data fields contained with data records. Such returned fraud schemes can include those discussed above and also those discussed below in more detail (for example, see TABLE I and associated text). Item 670 gives the potential risk that the records referenced in the report represent a fraud scheme. Additionally, as shown only in FIG. 6D, the report can list additional useful information 680, such as non-credentialed and/or sanctioned professionals. So long as report present relevant inconsistencies to subscribers 130, the reports need not take the same format or report the same set of information as those reports illustrated in FIGS. 6A-6F.
  • In addition to the above, the database operator 120 can produce comprehensive aggregated reports from the database 140 for the database operator's own use or for the database manager 110. For example, comprehensive reports can list a number of mortgage applications processed, the number of different appraisals by a single appraiser, a number of different appraisals for the same property with different appraisers, the number of times a potential shotgun fraud was identified, the number of times a flip fraud scenario was identified, and many other data. Reporting can also be tailored to user's pipeline settings. In this manner, for example, reports can include predetermined formats based on a user's pipeline settings and may only report testing data of a user's pipeline.
  • Additional Fraud Detection & Reporting Features
  • FIG. 7 illustrates a method 700 of fraud detection according to some embodiments of the present invention. Those skilled in the art will understand that method 700 can be performed in various orders (including differently than illustrated in FIG. 7), additional actions can be implemented as part of a method embodiment, and that some actions pictured in FIG. 7 are not necessary. In addition, it should be understood that while certain actions illustrated in FIG. 7 may be discussed herein as including certain other actions, these certain other actions may be carried out in various orders and/or as parts of the other actions depicted in FIG. 7.
  • The method 700 may initiate in certain embodiments as shown at 705 by providing an interface for receiving data. The data can be transmitted to and received into a database for processing in an effort to detect fraud. The data may include financial transaction information including, mortgage loan information. The data may also include information concerning borrowers, lenders, and/or entities. Data can be submitted by users or data can be obtained by accessing one or more databases that may be publicly or private databases. In some embodiments, the interface can be a web-based interface. Such an interface enables users to submit information (e.g., mortgage loan information) for processing via a web browser. A web-based interface can also enable transmission of information over the internet. In addition, the interface may be provided as a software application capable of submitting data over a private network. Data can be received in various forms including and ranging from receipt of a batch of data records to receipt of a single data record.
  • At 705, the method 700 can also include receiving and storing data in a fraud detection system database. Data can be stored in various fashions. For example, received data can be stored in various records wherein a single data record corresponds to a single mortgage loan application. Data can also be stored using various key fields to distinguish data records from each other. As an example, data records provided by financial institutions (e.g., lenders in a mortgage transaction) may be stored using a key field identifier to distinguish data records between financial institutions. Such an identifier can be used to implement user pipeline control to one or more users for tracking their own data records.
  • As shown at 715, the method 700 can also include processing transaction information to determine a due diligence level associated with loan transactions. For example, a fraud detection system can render identity verification results for each primary applicant/borrower on the transaction or the highest risk applicant/borrower on the transaction. Each high risk applicant/borrower can be identified by the system and displayed in the system interface. High risk individuals can then be associated with a high due diligence level indicating that a user should further investigate the applicant/borrower and a respective loan transaction.
  • As shown at 720, the method 700 may also include processing transaction information to determine potential fraudulent activity associated with loan transactions. For example, a fraud detection system can process loan data transaction information for each borrower, applicant, lender professional, and/or company involved in a transaction. In some currently preferred embodiments, lenders can view information related to their mortgage applications via an internal pipeline analysis and also view information related to other lenders via an external pipeline analysis. Enabling lenders to view loan applications in their respective pipelines relative to loan applications in other lender pipelines advantageously enables lenders to determine if borrowers and/or brokers are applying or have applied to other lending institutions. Such information may be useful and desired by lenders in managing risk associated with mortgage loans.
  • In addition, a fraud detection system according to embodiments of the present invention can perform data validation checks. For example, a system can process received data to validate information related to the borrower's identity using an identity verification service. Validation can help determine if alternate information can be found associated with the borrower information. Such information can determine if a borrower has various name aliases as well as social security numbers and names. In a currently preferred embodiment, for example, a fraud detection database can cross reference a social security number database to determine if a received name matches the database and also to determine if a received social security number is a valid number (e.g., the social security number is not on a death list).
  • As shown at 725, the method 700 can include processing information to determine compliance with existing laws and regulations. For example, in a mortgage transaction, lending institutions must comply with federal laws and regulations specific to consumer information and the establishment of relationships with their customers. These regulations are sometimes referred to as “Know Your Customer” regulations. Regulatory requirements associated with USA Patriot Act, Red Flag Rules (effective November 2008), and FACTA regulations require lending institutions to fairly and accurately know who their consumers are when a relationship is established. Such relationships generally include bank account opening, granting of loans, and any other business relationship that can materially affect the institution and/or consumer. Mortgage fraud can often be facilitated by simply stealing a consumer's identity or assuming their identity for the purpose of purchasing property or defrauding a lender for monetary gain. Identity theft is a common fraud incidence reported to local, state and federal agencies. Embodiments of the present invention advantageously enable an integrated utility to perform required compliance checks as well as manage the threat of fraudsters attempting to use false or stolen identities. To accomplish such checks a fraud detection system can access and obtain information from other databases (e.g., the Federal Government's Watch List) and cross check received mortgage loan information with data from these other databases.
  • As shown at 730, the method 700 can include processing information to determine background information for involved entities. This feature of embodiments of the invention advantageously enables review of loan transaction data related to third parties, industry professionals, and companies facilitating a loan transaction. Indeed, some embodiments can access one or more other databases (e.g., a proprietary and contributory database) that contain containing information related to professional licensing, publicly sourced derogatory incident reports, sanction and administrative action reports, and past or ongoing incidents of alleged fraud and misrepresentation.
  • As an example, fraud detection systems according to some embodiments can obtain information to verify a professional's credentials and risk associations by directly searching the contributory database for license validation and status, as well as any inclusion in a reported incident directly, or indirectly. After obtaining and analyzing background information for involved entities, the fraud detection system can provide results to users (as discussed below in more detail). For example, the system can return an “OK” or “ALERT” status based on received background information. By obtaining and analyzing background information, embodiments of the present invention can uncovers relationships among transaction parties, identify conflicts in professional credentials, and enable greater visibility to prior adverse business activities or associations that may harm lenders.
  • As shown at 735, the method 700 can also include providing information processing results to users in various formats. Formats include, but are not limited to, email alerts and web-page listings. Formats can also include various reports provided by email and or return web-page listings. In addition, exemplary report formats can include line item results as a summary of loan transaction data that includes results from the processing, matching, and scoring algorithms. Also, the system can enable a user to select specific fields with toggle functionality to present more detailed information about the loan transaction data and the processing results. The can also enable interactive user functionality to present loan transaction data in configurable formats through filtering, searching, and sorting capabilities. Still yet, the system can display a report with detailed validation, verification, and credentialing processing results related to the borrower/applicant and transaction professionals and/or companies.
  • Other reporting capabilities include providing a due diligence level associated with a loan transaction and also an identification score. The due diligence level can be based partially on an aggregate view of all data and if certain data inconsistencies appear between reviewed data fields a returned due diligence level can be set to “HIGH RISK” or a “RED ALERT” status. Other due diligence levels can include “LOW RISK” or “MEDIUM RISK levels. Similarly, returned results can include an identification score providing score information indicative of how a borrower's name checked with other checks. For example, if one database contains a name with a different SSN than submitted name, a borrower name identification score may be low indicating that the name issue should be further investigated. In another example, if one or more other database checks are performed and a borrower's name information is consistent among several records a high identification score can be returned indicating that a borrower's name is consistent with other data records.
  • Fraud Incident Submission Features
  • FIG. 8 illustrates a method 800 of an incident submission process according to some fraud detection embodiments of the present invention. Those skilled in the art will understand that method 800 can be performed in various orders (including differently than illustrated in FIG. 8), additional actions can be implemented as part of a method embodiment, and that some actions pictured in FIG. 8 are not necessary. In addition, it should be understood that while certain actions illustrated in FIG. 8 may be discussed herein as including certain other actions, these certain other actions may be carried out in various orders and/or as parts of the other actions depicted in FIG. 8.
  • The method 800 can initiate at 805 by providing an interface enabling submission of fraud related incidents. Indeed, users of a fraud detection system according to some embodiments of the present invention can submit information related to fraud for further investigation and possible inclusion in the fraud detection system's database. In currently preferred embodiments, the interface can be a web-based browser form capable of accepting user data entry related reporting a fraud related incident. In other embodiments, data forms can be transmitted (e.g., email, FTP, or SFTP) to a fraud detection system for analysis and review.
  • The method 800 can continue at 810 by populating data into an incident report submission form. Indeed in some embodiments, the system will automatically load data elements from loan transaction data into specified fields. For example, an applicant's name will appear in the corresponding incident submission field. The system also enables interaction with users so that additional information (e.g., from one or more users) can be input into a submission form.
  • The method 800 can continue at 815 by receiving incident report submission data. Upon receipt, embodiments of a fraud detection system can provide the ability to query multiple databases. This enables users to determine whether those suspected of fraud may have been involved in other reported incidents. For example, the databases include real estate and professional license data directly from the Mortgage Industry Data Exchange (“MIDEX”). MIDEX is a repository containing industry-contributed incidents of fraud and material misrepresentation; publicly sourced information specific to administrative and disciplinary actions and sanctions; and professional license information. As mentioned above, a fraud detection system according to some embodiments enables users to query databases in an effort to verify and adjudicate the professionals of record associated with the incident.
  • The method 800 can continue at 820 by providing incident report data for review. As an example, some embodiments will provide reported fraud incident information for entry into the MIDEX incident submission processing queue. The system can also associate a reported incident to loan transaction data by using a unique identifier that relates the two entities or the loan transaction data and the incident report. Thus the fraud detection system supports submission of an incident related to loan transactions, transaction parties or information contained in an official suspicious activity report. The review process can include administrative review of the incident information, direct interaction with the submitter, data editing of incident information, formal review and approval of the completed incident report by the submitter and final delivery of the approved incident to a database upload queue for inclusion into the database.
  • The method 800 can also continue at 825 by receiving follow up information related to a reported incident. For example, the system can support a request for information and challenge of an incident submission. The challenge process enables an industry professional and/or company to request incident information naming the requestor. The requestor can submit information to an administrator via the system for verification and for potential future interaction regarding the submitted incident. An administrator can query the database for any incident reports associated with the requestor. The requestor will receive the incident information using an approved delivery method. The requestor is given authorization to respond or rebut information contained in the incident. The response or rebuttal is delivered to the incident submitter for review and response. An administrator acts as the intermediary between both parties during the rebuttal process. During the course of the rebuttal process, it may be determined that the incident will remain in tact with no further modifications or the rebuttal will be approved by the incident submitter resulting in the removal of that incident report.
  • The method 800 can also continue at 830 by providing finalized incident report data into a fraud detection system database for review. For example, the system can support database modifications to the incident report by an administrator. Data modification can include removal of incident text or the addition of a requestor's response to the original incident of record. The system can notify submitting entities with a relationship to the requestor as well as other user of interest with incident activity. The system can also notify all entities with an interest in the named professionals of any new incident activity or updates to an existing incident report.
  • Entity & Credential Verification Features
  • FIG. 9 illustrates a method 900 of authenticating and verifying entities and professionals involved in a financial application process according to some fraud detection embodiments of the present invention. Those skilled in the art will understand that method 900 can be performed in various orders (including differently than illustrated in FIG. 9), additional actions can be implemented as part of a method embodiment, and that some actions pictured in FIG. 9 are not necessary. In addition, it should be understood that while certain actions illustrated in FIG. 9 may be discussed herein as including certain other actions, these certain other actions may be carried out in various orders and/or as parts of the other actions depicted.
  • As shown, the method 900 can initiate by receiving names of entities involved in a loan transaction. Entities can include people, names of businesses, and companies. People may include borrowers, lenders, brokers, and realtors. By receiving this information, fraud detection systems according to the present invention can perform background and credential checks on the received information. Indeed, at 910, the method 900 may include comparing received information with records already existing in the database. The result of such checks can provide information beneficial to users thereby enabling users to obtain background information on those involved in a loan transaction.
  • The method 900 can also include obtaining information from other existing databases at 915. These databases can include private and publicly available databases. The existing databases can be managed by third parties and they databases can be located distant from a fraud detection system. The existing databases can, for example, be managed by governmental or industry licensing groups and contain entity licensing and/or sanction information. Such features enable users to query a database for authorized and credentialed professionals when a loan transaction is commenced. In addition, a fraud detection system enabling such entity checking can also facilitate queries to credentialed professionals list owned by the user of the system. In some embodiments, fraud detection systems will upload information about a individual professional, as it is presented to the system user. The system can then engage a workflow of data service calls and return specific information related to, for example, professional license status, incidents, OFAC compliance, criminal background, and a synthetic identity check.
  • After obtaining entity background information from existing databases, users and/or a fraud detection system can compare the received background information to received loan transaction information to perform background checks at 920.
  • The method 900 can also include reporting entity information to users at 925. For example, fraud detection system embodiments can be configured to present a return list to users for selection when prompted to input information about a loan transaction professional. The process for professional credentialing may be a workflow of choreographed data services that will perform a series of checks and verifications, resulting in a “PASS/FAIL” score for an entity. For each professional credential, the system may require a minimum amount of data criteria to provide results and to assign a “PASS/FAIL” score to be compiled for the overall score. Embodiments can also include providing a credentialed professional list with access to system detail reports and an exception list that contains professionals and/or companies that have been identified as not credentialed to do business. Additional embodiments can also enable uploads of professionals not credentialed to do business with the system user, by the system user.
  • Fraud Scheme Analysis & Determination
  • As mentioned above, embodiments of the present invention can be used to identify a potential fraud scheme. The identification can be determined by analyzing results of data field analysis and comparison. For example, the inventors have discovered that by analyzing matching characteristics of certain data fields (e.g., data fields have data that matches or does not match), one or more potential fraud schemes can be provided to a user. Matching characteristics can also include analyzing the “N” (no match) and “E” (exact match) processes discussed above. The below provided table (TABLE I) provides a series of test scenarios for implementing a fraud scheme analysis process in accordance with some embodiments.
  • TABLE I
    Fraud Scheme
    Shot- Double Straw
    Data Fields Analysis Multiple Flipping Gunning escrow Churning Chunking buyer
    LOAN_BORROWER.CLN_NAME_LAST * N E E E E N
    LOAN_BORROWER.CLN_NAME_FIRST * N E E E E N
    LOAN_BORROWER.SSN * E
    ORIGINATOR_COMPANY E E N E E
    LASTNAME_ORIGINATOR E E N E E
    FIRSTNAME_ORIGINATOR E E N E E
    APPRAISAL_VALUE N N N N N
    LASTNAME_APPRAISER E E E E E
    FIRSTNAME_APPRAISER E E E E E
    APP_DATE N N N N N N
    LOAN_SELLER.LASTNAME * N E N E E
    LOAN_SELLER.FIRSTNAME * N E N E E
    CLOSE_DT 30 30 5 30 5 60
    Additional cross-field comparisons borrower == borrower == originator ==
    seller seller seller
  • As shown in TABLE I, embodiments of the present invention can be configured to review the results of a matching analysis for various data fields. Based on the analysis, a potential fraud scheme can be provided to a user. For example, if a no match result is returned for loan borrower name, appraisal value, application data, and loan seller name in concert with a match for originator company and name and appraiser name information, this information can indicate a possible flipping fraud scheme. As a result, embodiments of the present invention can return this information to a user so that a user can further investigate. Shot-Gunning, double escrow, churning, chunking, and straw-buyer alerts can be similarly returned to users if a matching analysis is in line with the above table entries. Given the dual pipeline features of the present invention, possible fraud scenarios can be returned for both a user's internal pipeline and also for records external to a user's pipeline.
  • The embodiments of the present invention are not limited to the particular formulations, process steps, and materials disclosed herein as such formulations, process steps, and materials may vary somewhat. Moreover, the terminology employed herein is used for the purpose of describing exemplary embodiments only and the terminology is not intended to be limiting since the scope of the various embodiments of the present invention will be limited only by the appended claims and equivalents thereof.
  • For example, embodiments of the present invention can include additional features as described below. For example, a processing module can be configured to separate loan transaction information for review by users into multiple pipelines using an identifier configured to distinguish users. Also, a processing module can be configured to separate loan transaction information into an internal pipeline comprising loan information associated with a first lender and an external pipeline containing loan information associated with lenders other than the first lender. In addition, a processing module can be configured to associate at least one of a due diligence level and identification score with one or more data records. Also, a processing module can be configured to determine if one or more data records complies with financial laws and regulations. Still yet, a processing module can be configured to maintain one or more data records in an active pipeline for a predetermined amount of time, the one or more data records in the active pipeline being associated with a single lender. And yet another aspect can include providing users information about one or more data records relating to mortgage applications at predetermined stages of the mortgage applications. Also, in accordance with some embodiments, data records can have a uniform format such that the processing module can compared a data record to another data record to determine consistencies and inconsistencies.
  • Other aspects of embodiments of the present invention can include additional features as described below. For example, a method can include receiving fraud incident data information and storing such information as a data record. A fraud detection method can also include receiving a query based on or more data fields and to return data records responsive to the query. Still yet, a processing module can be configured to monitor one or more data records for a predetermined period of time and provide reports detailing any changes in the one or more data records. A processing module can be configured to provide reports comprising information about a mortgage application proximate at least one of a pre-funding application stage, a loan funding stage, an investor servicing stage, and a loan servicing stage.
  • Embodiments of the present invention can still have other features. For example, some embodiments can be configured to validate the one or more data records to ensure that the one or more data records comprise data based on a predetermined data format. Some embodiments can also be configured to receive updated data pertaining to one or more data records and providing administrative operating reports comprising operational information. Such operational information can include database operational status, user interaction information, user submitted information, and other administrative data functions as desired. As discussed herein, embodiments of the present invention can receive information from unique users, which can comprise lenders, brokers, and borrowers. Embodiments can also include at least one webserver operatively configured to provide data interfaces and/or internet portals for use in communication networks. Also, embodiments of the present invention enable users to customize reports provided to them. For example, a reporting module can be operatively configured to receive report format information from a user and to provide report information to a user based at least partially on the received report format information.
  • Therefore, while embodiments of the invention are described with reference to exemplary embodiments, those skilled in the art will understand that variations and modifications can be effected within the scope of the invention as defined in the appended claims. Accordingly, the scope of the various embodiments of the present invention should not be limited to the above discussed embodiments, and should only be defined by the following claims and all equivalents.

Claims (21)

1. A fraud detection system to detect fraud in a financial loan application process by analyzing a plurality of data from multiple sources, the system comprising:
one or more interfaces configured to receive data from a plurality of unique data sources, the data comprising data records comprising at least one of information related to a financial loan application, parties involved in a loan transaction, and property involved in a financial loan;
a database configured to receive data from the plurality of unique data sources and to store the data with an identifier configured to distinguish data received from the plurality of unique data sources;
a processing module configured to determine if one or more of the data records contain one or more matching data fields and to flag data records containing the one or more matching data fields by storing match information in a table; and
the processing module further configured to determine if one or more of the flagged data records contain different information in one or more other data fields contained in the data records and storing information corresponding to differences in the table.
2. The fraud detection system of claim 1, the one or more matching data fields comprising at least one of information about property involved in a financial loan and at least a party involved in a loan transaction.
3. The fraud detection system of claim 1, further comprising a reporting module configured to report at least one of information concerning the data records containing the one or more matching data fields and information concerning the flagged data records containing different information in the one or more predetermined data fields.
4. The fraud detection system of claim 3, the reporting module further configured to order information contained in a report at least partially based on different information contained in the one or more data fields and a magnitude of difference.
5. The fraud detection system of claim 1, the processing module further configured to place one or more received data records in an active state for a predetermined holding period and periodically analyze active-state data records relative existing data and data received after the active-state data records.
6. The fraud detection system of claim 5, wherein the predetermined holding period ranges from approximately one day to approximately one year.
7. The fraud detection system of claim 1, wherein the one or more data sources comprise at least one of information received from unique end users providing data to the one or more data interfaces and information received from existing unique databases operatively coupled to the one or more data interfaces.
8. The fraud detection system of claim 1, wherein the processing module is configured to determine if one or more of the data records contain substantially similar addresses for a real estate property involved in a loan transaction.
9. A method for detecting fraud in a financial credit or loan application process, the fraud detection method comprising:
providing a database operatively configured to receive data comprising details concerning a financial credit or loan application and to store received data as one or more first data records;
configuring the database to receive data from a plurality of unique data sources and store the data with an identifier for distinguishing the unique data sources, the data comprising at least one of, one or more parties involved in a loan transaction, and property involved in a financial application process;
providing a data comparison module operatively configured to flag the one or more first data records containing similar data in one or more predetermined data fields by storing matching information in a table; and
configuring the data comparison module to determine if the flagged data records comprising at least one data field with similar data comprise one or more other data fields having inconsistent data by storing inconsistent data in the table.
10. The fraud detection method of claim 9, further comprising configuring the database to provide reports comprising at least one of details related to the flagged data records comprising at least one data field with similar data and details related to the flagged data records comprising data fields with inconsistent data.
11. The fraud detection method of claim 9, further comprising configuring the database to receive data from a plurality of end users and the one or more databases via a communications network.
12. The fraud detection method of claim 9, wherein providing a data comparison module operatively configured to flag the one or more data records containing similar data in one or more predetermined data fields comprises determining if the one or more data records contain data fields having similar property address information or similar borrower information.
13. The fraud detection method of claim 9, further comprising configuring the database to provide reports to a user with data ordered based on results a two-tier weighted algorithm.
14. The fraud detection method of claim 9, further comprising holding one or more of the data records in the database for a predetermined holding period and configuring the data comparison module to compare existing data records to data records received after the existing data records at predefined intervals.
15. The fraud detection method of claim 9, further comprising operatively configuring the database to receive lender originated data and user incident report data.
16. The fraud detection method of claim 9, further comprising operatively configuring the data comparison module to receive professional license information from one or more existing databases to determine if a licensed party involved in a loan transaction is properly licensed and has any past professional sanctions.
17. A computer-readable medium having computer readable instructions stored thereon for execution by a processor to execute a method for detecting fraud, the fraud detection method comprising:
providing a database configured to receive data from a plurality of unique data sources and associate received data with an identifier to distinguish the unique data sources, the data comprising data records having data fields, the data records comprising at least one of information related to a financial loan application, parties involved in a loan transaction, and property involved in a financial loan;
determining whether one of the data records has a data field containing common data to at least one other data field contained within at least one of the other data records;
determining whether data records having at least one data field in common have other data fields having disparate data; and
providing a report comprising data records based at least partially on the identifier, the report further comprising a listing of data records with data fields having common data and data records containing data fields having disparate data.
18. The computer-readable medium of claim 17, wherein at least a portion of the data records contain mortgage loan application information submitted by unique users and at least another portion of the data records contain information obtained from pre-existing databases containing borrower information.
19. The computer-readable medium of claim 17, wherein the data field reviewed for common data comprises property address information to determine if a single property is subject to multiple loan applications.
20. The computer-readable medium of claim 17, further comprising repeatedly determining on a pre-determined basis whether one of the data records has a data field containing common data to at least one other data field contained within at least one of the other data records and whether data records having at least one data field in common have other data fields having disparate data.
21-45. (canceled)
US12/481,546 2007-12-20 2009-06-09 Mortgage fraud detection systems and methods Abandoned US20100241558A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/481,546 US20100241558A1 (en) 2007-12-20 2009-06-09 Mortgage fraud detection systems and methods

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US1542907P 2007-12-20 2007-12-20
US12/174,591 US7546271B1 (en) 2007-12-20 2008-07-16 Mortgage fraud detection systems and methods
US12/481,546 US20100241558A1 (en) 2007-12-20 2009-06-09 Mortgage fraud detection systems and methods

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/174,591 Continuation US7546271B1 (en) 2007-12-20 2008-07-16 Mortgage fraud detection systems and methods

Publications (1)

Publication Number Publication Date
US20100241558A1 true US20100241558A1 (en) 2010-09-23

Family

ID=40688786

Family Applications (2)

Application Number Title Priority Date Filing Date
US12/174,591 Expired - Fee Related US7546271B1 (en) 2007-12-20 2008-07-16 Mortgage fraud detection systems and methods
US12/481,546 Abandoned US20100241558A1 (en) 2007-12-20 2009-06-09 Mortgage fraud detection systems and methods

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US12/174,591 Expired - Fee Related US7546271B1 (en) 2007-12-20 2008-07-16 Mortgage fraud detection systems and methods

Country Status (4)

Country Link
US (2) US7546271B1 (en)
CA (1) CA2710466A1 (en)
GB (1) GB2469948A (en)
WO (1) WO2009086143A2 (en)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100268696A1 (en) * 2009-04-16 2010-10-21 Brad Nightengale Advanced Warning
US20110238566A1 (en) * 2010-02-16 2011-09-29 Digital Risk, Llc System and methods for determining and reporting risk associated with financial instruments
US20120078778A1 (en) * 2010-09-15 2012-03-29 Corelogic Information Solutions, Inc. System, method and computer program storage device for detecting short sale fraud
US20120215658A1 (en) * 2011-02-23 2012-08-23 dBay Inc. Pin-based payment confirmation
WO2012177786A1 (en) * 2011-06-21 2012-12-27 Early Warning Services, Llc System and method for locating and accessing account data
US8515863B1 (en) * 2010-09-01 2013-08-20 Federal Home Loan Mortgage Corporation Systems and methods for measuring data quality over time
US8682755B2 (en) * 2012-07-03 2014-03-25 Lexisnexis Risk Solutions Fl Inc. Systems and methods for detecting tax refund fraud
US20140279380A1 (en) * 2013-03-14 2014-09-18 Fannie Mae Automated searching credit reports to identify potential defaulters
US20150066738A1 (en) * 2013-08-30 2015-03-05 Corelogic Solutions, Llc System amd method for detecting short sale fraud
US9361656B2 (en) 2012-01-09 2016-06-07 W. C. Taylor, III Data mining and logic checking tools
US10043213B2 (en) * 2012-07-03 2018-08-07 Lexisnexis Risk Solutions Fl Inc. Systems and methods for improving computation efficiency in the detection of fraud indicators for loans with multiple applicants
US10089686B2 (en) 2012-07-03 2018-10-02 Lexisnexis Risk Solutions Fl Inc. Systems and methods for increasing efficiency in the detection of identity-based fraud indicators
US10504174B2 (en) 2011-06-21 2019-12-10 Early Warning Services, Llc System and method to search and verify borrower information using banking and investment account data and process to systematically share information with lenders and government sponsored agencies for underwriting and securitization phases of the lending cycle
US11263600B2 (en) 2015-03-24 2022-03-01 4 S Technologies, LLC Automated trustee payments system
US11816747B1 (en) * 2018-12-12 2023-11-14 United Services Automobile Association (Usaa) Systems and methods for mining data for property usage

Families Citing this family (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9710852B1 (en) 2002-05-30 2017-07-18 Consumerinfo.Com, Inc. Credit report timeline user interface
US9400589B1 (en) 2002-05-30 2016-07-26 Consumerinfo.Com, Inc. Circular rotational interface for display of consumer credit information
US7937319B2 (en) * 2005-03-21 2011-05-03 Oversight Technologies, Inc. Methods and systems for compliance monitoring knowledge base
US20060271454A1 (en) * 2005-05-25 2006-11-30 Strom Steven R Method of analyzing a sale process for a company
US8635138B2 (en) 2009-07-16 2014-01-21 Steven R. Strom Method of analyzing a sale process for an entity
US8285656B1 (en) 2007-03-30 2012-10-09 Consumerinfo.Com, Inc. Systems and methods for data verification
US20140244510A1 (en) * 2007-05-23 2014-08-28 Raymond de Beasley Privacy protection system and method
WO2008147918A2 (en) 2007-05-25 2008-12-04 Experian Information Solutions, Inc. System and method for automated detection of never-pay data sets
US20090204521A1 (en) * 2007-12-13 2009-08-13 De Sena Francis E Method of and system for web-based managing and reporting mortgage transactions
US8127986B1 (en) 2007-12-14 2012-03-06 Consumerinfo.Com, Inc. Card registry systems and methods
US9990674B1 (en) 2007-12-14 2018-06-05 Consumerinfo.Com, Inc. Card registry systems and methods
US7546271B1 (en) * 2007-12-20 2009-06-09 Choicepoint Asset Company Mortgage fraud detection systems and methods
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US8060424B2 (en) 2008-11-05 2011-11-15 Consumerinfo.Com, Inc. On-line method and system for monitoring and reporting unused available credit
US8700522B2 (en) * 2009-10-30 2014-04-15 Accenture Global Services Limited Loan portfolio management tool
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US8725613B1 (en) * 2010-04-27 2014-05-13 Experian Information Solutions, Inc. Systems and methods for early account score and notification
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
US20120143649A1 (en) * 2010-12-01 2012-06-07 9133 1280 Quebec Inc. Method and system for dynamically detecting illegal activity
US9349115B2 (en) * 2011-01-11 2016-05-24 International Business Machines Corporation Data management and control using data importance levels
WO2012112781A1 (en) 2011-02-18 2012-08-23 Csidentity Corporation System and methods for identifying compromised personally identifiable information on the internet
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US9607336B1 (en) 2011-06-16 2017-03-28 Consumerinfo.Com, Inc. Providing credit inquiry alerts
US8396877B2 (en) * 2011-06-27 2013-03-12 Raytheon Company Method and apparatus for generating a fused view of one or more people
US9483606B1 (en) 2011-07-08 2016-11-01 Consumerinfo.Com, Inc. Lifescore
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US11030562B1 (en) 2011-10-31 2021-06-08 Consumerinfo.Com, Inc. Pre-data breach monitoring
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US20130332374A1 (en) * 2012-06-09 2013-12-12 Scott Hartnett Fraud prevention for real estate transactions
US8918891B2 (en) * 2012-06-12 2014-12-23 Id Analytics, Inc. Identity manipulation detection system and method
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US9117186B2 (en) * 2012-11-21 2015-08-25 Cellco Partnership Joint marketed customer hub
US9916621B1 (en) 2012-11-30 2018-03-13 Consumerinfo.Com, Inc. Presentation of credit score factors
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US9870589B1 (en) 2013-03-14 2018-01-16 Consumerinfo.Com, Inc. Credit utilization tracking and reporting
US8812387B1 (en) 2013-03-14 2014-08-19 Csidentity Corporation System and method for identifying related credit inquiries
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US9230101B2 (en) * 2013-03-15 2016-01-05 Pinkerton Consulting And Investigations, Inc. Providing alerts based on unstructured information methods and apparatus
US10685398B1 (en) 2013-04-23 2020-06-16 Consumerinfo.Com, Inc. Presenting credit score information
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US20160328794A1 (en) * 2013-07-24 2016-11-10 Pitch Point Solutions, Inc. Methods and systems for improved application submissions
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US10410282B2 (en) * 2013-09-12 2019-09-10 Capital One Services, Llc Systems and methods for a refinancing savings widget
US10102536B1 (en) 2013-11-15 2018-10-16 Experian Information Solutions, Inc. Micro-geographic aggregation system
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US20150142629A1 (en) * 2013-11-20 2015-05-21 Bank Of America Corporation Detecting unusual activity in cash vault transactions
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US9529851B1 (en) 2013-12-02 2016-12-27 Experian Information Solutions, Inc. Server architecture for electronic data quality processing
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US20150235334A1 (en) * 2014-02-20 2015-08-20 Palantir Technologies Inc. Healthcare fraud sharing system
US9009827B1 (en) 2014-02-20 2015-04-14 Palantir Technologies Inc. Security sharing system
USD759690S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759689S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD760256S1 (en) 2014-03-25 2016-06-28 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
US9892457B1 (en) 2014-04-16 2018-02-13 Consumerinfo.Com, Inc. Providing credit data in search results
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US9509705B2 (en) * 2014-08-07 2016-11-29 Wells Fargo Bank, N.A. Automated secondary linking for fraud detection systems
US10339527B1 (en) 2014-10-31 2019-07-02 Experian Information Solutions, Inc. System and architecture for electronic fraud detection
US20160171564A1 (en) * 2014-12-11 2016-06-16 Fannie Mae Subject appraisal discrepancy analysis
US11151468B1 (en) 2015-07-02 2021-10-19 Experian Information Solutions, Inc. Behavior analysis using distributed representations of event data
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
CN110383319B (en) 2017-01-31 2023-05-26 益百利信息解决方案公司 Large 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
US10699028B1 (en) 2017-09-28 2020-06-30 Csidentity Corporation Identity security architecture systems and methods
US10896472B1 (en) 2017-11-14 2021-01-19 Csidentity Corporation Security and identity verification system and architecture
US20190333175A1 (en) * 2018-04-30 2019-10-31 Deckard Technologies, Inc. Detecting and validating real estate transfer events through data mining, natural language processing, and machine learning
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US11265324B2 (en) 2018-09-05 2022-03-01 Consumerinfo.Com, Inc. User permissions for access to secure data at third-party
US10963434B1 (en) 2018-09-07 2021-03-30 Experian Information Solutions, Inc. Data architecture for supporting multiple search models
US11315179B1 (en) 2018-11-16 2022-04-26 Consumerinfo.Com, Inc. Methods and apparatuses for customized card recommendations
US11178179B2 (en) 2018-12-10 2021-11-16 Capital One Services, Llc Synthetic identity signal network
WO2020146667A1 (en) 2019-01-11 2020-07-16 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation
US11238656B1 (en) 2019-02-22 2022-02-01 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data
CN111429268B (en) * 2020-03-30 2023-11-24 上海德易车信息科技有限公司 Vehicle credit risk detection method, terminal equipment and storage medium
US20220207630A1 (en) * 2020-12-29 2022-06-30 Toby Michael Cohen System and method for authorizing transfer requests of physical locations
US11880377B1 (en) 2021-03-26 2024-01-23 Experian Information Solutions, Inc. Systems and methods for entity resolution
CN114581219A (en) * 2022-04-29 2022-06-03 弘沣智安科技(北京)有限公司 Anti-telecommunication network fraud early warning method and system

Citations (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6029154A (en) * 1997-07-28 2000-02-22 Internet Commerce Services Corporation Method and system for detecting fraud in a credit card transaction over the internet
US6418436B1 (en) * 1999-12-20 2002-07-09 First Data Corporation Scoring methodology for purchasing card fraud detection
US20020133371A1 (en) * 2001-01-24 2002-09-19 Cole James A. Automated mortgage fraud prevention method and system
US20030009418A1 (en) * 2000-12-08 2003-01-09 Green Gerald M. Systems and methods for electronically verifying and processing information
US20030036996A1 (en) * 2001-08-16 2003-02-20 Lazerson Jeffrey M. Credit/financing process
US20030093365A1 (en) * 2001-11-13 2003-05-15 Halper Steven C. Predatory lending detection system and method therefor
US20030093366A1 (en) * 2001-11-13 2003-05-15 Halper Steven C. Automated loan risk assessment system and method
US20030097342A1 (en) * 2000-01-24 2003-05-22 Whittingtom Barry R. Method for verifying employment data
US6581039B2 (en) * 1999-11-23 2003-06-17 Accenture Llp Report searching in a merger and acquisition environment
US20030182151A1 (en) * 2002-02-26 2003-09-25 Neal Taslitz Method of using biometric measurements as a legal seal for authenticating real estate deeds and mortgages
US20030187783A1 (en) * 2002-03-27 2003-10-02 First Data Corporation Systems and methods to monitor credit fraud
US20040030649A1 (en) * 2002-05-06 2004-02-12 Chris Nelson System and method of application processing
US20040064401A1 (en) * 2002-09-27 2004-04-01 Capital One Financial Corporation Systems and methods for detecting fraudulent information
US6715672B1 (en) * 2002-10-23 2004-04-06 Donald Tetro System and method for enhanced fraud detection in automated electronic credit card processing
US20040138912A1 (en) * 2002-11-04 2004-07-15 Loan Recapture Services, Llc Multiple listing services (MLS) data redistribution
US6766322B1 (en) * 2000-06-23 2004-07-20 G. Randall Bell Real estate disclosure reporting method
US20050108025A1 (en) * 2003-11-14 2005-05-19 First American Real Estate Solutions, L.P. Method for mortgage fraud detection
US20050154665A1 (en) * 2002-11-22 2005-07-14 Florida Bankers Association, Inc. Fraud prevention system
US20050187863A1 (en) * 2004-02-20 2005-08-25 Whinery Christopher S. Method and system for protecting real estate from fraudulent transactions
US20050203830A1 (en) * 2004-03-15 2005-09-15 Prieston Arthur J. Method for handling claims arising under representation and warranty insurance for mortgage loans
US20060136330A1 (en) * 2004-10-22 2006-06-22 Deroy Craig I Product, system and method for certification of closing and mortgage loan fulfillment
US20060218079A1 (en) * 2005-02-08 2006-09-28 Goldblatt Joel N Web-based consumer loan database with automated controls for preventing predatory lending practices
US20060224499A1 (en) * 2005-03-29 2006-10-05 First American Real Estate Solutions, L.P. Method and apparatus for computing a loan quality score
US20070016522A1 (en) * 2005-07-15 2007-01-18 Zhiping Wang Data processing system for a billing address-based credit watch
US20070067234A1 (en) * 2005-09-21 2007-03-22 Beech James J Mortgage loan system and method
US20070073519A1 (en) * 2005-05-31 2007-03-29 Long Kurt J System and Method of Fraud and Misuse Detection Using Event Logs
US20070174214A1 (en) * 2005-04-13 2007-07-26 Robert Welsh Integrated fraud management systems and methods
US7254559B2 (en) * 2000-02-25 2007-08-07 Costar Group, Inc. System and method for collection, distribution, and use of information in connection with commercial real estate
US20070192240A1 (en) * 2005-09-02 2007-08-16 Crooks Theodore J Systems and methods for detecting fraud
US20070208641A1 (en) * 2006-03-03 2007-09-06 Bayview Lending Group Llc Automated loan processing system and method for processing loans
US20070219819A1 (en) * 2006-03-14 2007-09-20 Title Insurance National Information Exchange Llc Method and system for detecting title fraud
US20070226129A1 (en) * 2006-03-24 2007-09-27 Yuansong Liao System and method of detecting mortgage related fraud
US7311248B1 (en) * 2004-08-12 2007-12-25 Prairie Systems, Inc. Method and system for automatically detecting fraudulent applications
US20080021801A1 (en) * 2005-05-31 2008-01-24 Yuh-Shen Song Dynamic multidimensional risk-weighted suspicious activities detector
US20080109349A1 (en) * 2006-11-08 2008-05-08 George Jenich System and method of processing loan applications
US7373669B2 (en) * 2003-08-13 2008-05-13 The 41St Parameter, Inc. Method and system for determining presence of probable error or fraud in a data set by linking common data values or elements
US20080147454A1 (en) * 2006-12-14 2008-06-19 Walker Robert L Method and apparatus for detecting fraudulent loans
US20080167883A1 (en) * 2007-01-05 2008-07-10 Ramin Thavildar Khazaneh Method and System for Monitoring and Protecting Real Estate Title (Ownership) Against Fraudulent Transaction (Title Theft) and Mortgage Fraud
US7427016B2 (en) * 2006-04-12 2008-09-23 Chimento Marc A System and method for screening for fraud in commercial transactions
US7458508B1 (en) * 2003-05-12 2008-12-02 Id Analytics, Inc. System and method for identity-based fraud detection
US7472089B2 (en) * 2002-08-15 2008-12-30 Ellie Mae, Inc. Loan origination system interface for online loan application processing
US7546271B1 (en) * 2007-12-20 2009-06-09 Choicepoint Asset Company Mortgage fraud detection systems and methods

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006105576A1 (en) 2004-10-13 2006-10-12 Ares Capital Management Pty Ltd Data processing system supporting decisions to accept or reject applications for financial accommodation

Patent Citations (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6029154A (en) * 1997-07-28 2000-02-22 Internet Commerce Services Corporation Method and system for detecting fraud in a credit card transaction over the internet
US6581039B2 (en) * 1999-11-23 2003-06-17 Accenture Llp Report searching in a merger and acquisition environment
US6418436B1 (en) * 1999-12-20 2002-07-09 First Data Corporation Scoring methodology for purchasing card fraud detection
US20030097342A1 (en) * 2000-01-24 2003-05-22 Whittingtom Barry R. Method for verifying employment data
US7254559B2 (en) * 2000-02-25 2007-08-07 Costar Group, Inc. System and method for collection, distribution, and use of information in connection with commercial real estate
US6766322B1 (en) * 2000-06-23 2004-07-20 G. Randall Bell Real estate disclosure reporting method
US20030009418A1 (en) * 2000-12-08 2003-01-09 Green Gerald M. Systems and methods for electronically verifying and processing information
US20020133371A1 (en) * 2001-01-24 2002-09-19 Cole James A. Automated mortgage fraud prevention method and system
US20030036996A1 (en) * 2001-08-16 2003-02-20 Lazerson Jeffrey M. Credit/financing process
US20030093366A1 (en) * 2001-11-13 2003-05-15 Halper Steven C. Automated loan risk assessment system and method
US20030093365A1 (en) * 2001-11-13 2003-05-15 Halper Steven C. Predatory lending detection system and method therefor
US20030182151A1 (en) * 2002-02-26 2003-09-25 Neal Taslitz Method of using biometric measurements as a legal seal for authenticating real estate deeds and mortgages
US20030187783A1 (en) * 2002-03-27 2003-10-02 First Data Corporation Systems and methods to monitor credit fraud
US20040030649A1 (en) * 2002-05-06 2004-02-12 Chris Nelson System and method of application processing
US7472089B2 (en) * 2002-08-15 2008-12-30 Ellie Mae, Inc. Loan origination system interface for online loan application processing
US20040064401A1 (en) * 2002-09-27 2004-04-01 Capital One Financial Corporation Systems and methods for detecting fraudulent information
US6715672B1 (en) * 2002-10-23 2004-04-06 Donald Tetro System and method for enhanced fraud detection in automated electronic credit card processing
US20040138912A1 (en) * 2002-11-04 2004-07-15 Loan Recapture Services, Llc Multiple listing services (MLS) data redistribution
US20050154665A1 (en) * 2002-11-22 2005-07-14 Florida Bankers Association, Inc. Fraud prevention system
US7458508B1 (en) * 2003-05-12 2008-12-02 Id Analytics, Inc. System and method for identity-based fraud detection
US7373669B2 (en) * 2003-08-13 2008-05-13 The 41St Parameter, Inc. Method and system for determining presence of probable error or fraud in a data set by linking common data values or elements
US20050108025A1 (en) * 2003-11-14 2005-05-19 First American Real Estate Solutions, L.P. Method for mortgage fraud detection
US20050187863A1 (en) * 2004-02-20 2005-08-25 Whinery Christopher S. Method and system for protecting real estate from fraudulent transactions
US20050203830A1 (en) * 2004-03-15 2005-09-15 Prieston Arthur J. Method for handling claims arising under representation and warranty insurance for mortgage loans
US7311248B1 (en) * 2004-08-12 2007-12-25 Prairie Systems, Inc. Method and system for automatically detecting fraudulent applications
US20060136330A1 (en) * 2004-10-22 2006-06-22 Deroy Craig I Product, system and method for certification of closing and mortgage loan fulfillment
US20060218079A1 (en) * 2005-02-08 2006-09-28 Goldblatt Joel N Web-based consumer loan database with automated controls for preventing predatory lending practices
US20060224499A1 (en) * 2005-03-29 2006-10-05 First American Real Estate Solutions, L.P. Method and apparatus for computing a loan quality score
US20070174214A1 (en) * 2005-04-13 2007-07-26 Robert Welsh Integrated fraud management systems and methods
US20070073519A1 (en) * 2005-05-31 2007-03-29 Long Kurt J System and Method of Fraud and Misuse Detection Using Event Logs
US20080021801A1 (en) * 2005-05-31 2008-01-24 Yuh-Shen Song Dynamic multidimensional risk-weighted suspicious activities detector
US20070016522A1 (en) * 2005-07-15 2007-01-18 Zhiping Wang Data processing system for a billing address-based credit watch
US20070192240A1 (en) * 2005-09-02 2007-08-16 Crooks Theodore J Systems and methods for detecting fraud
US20070067234A1 (en) * 2005-09-21 2007-03-22 Beech James J Mortgage loan system and method
US20070208641A1 (en) * 2006-03-03 2007-09-06 Bayview Lending Group Llc Automated loan processing system and method for processing loans
US20070219819A1 (en) * 2006-03-14 2007-09-20 Title Insurance National Information Exchange Llc Method and system for detecting title fraud
US20070226129A1 (en) * 2006-03-24 2007-09-27 Yuansong Liao System and method of detecting mortgage related fraud
US7427016B2 (en) * 2006-04-12 2008-09-23 Chimento Marc A System and method for screening for fraud in commercial transactions
US20080109349A1 (en) * 2006-11-08 2008-05-08 George Jenich System and method of processing loan applications
US20080147454A1 (en) * 2006-12-14 2008-06-19 Walker Robert L Method and apparatus for detecting fraudulent loans
US20080167883A1 (en) * 2007-01-05 2008-07-10 Ramin Thavildar Khazaneh Method and System for Monitoring and Protecting Real Estate Title (Ownership) Against Fraudulent Transaction (Title Theft) and Mortgage Fraud
US7546271B1 (en) * 2007-12-20 2009-06-09 Choicepoint Asset Company Mortgage fraud detection systems and methods

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8380569B2 (en) * 2009-04-16 2013-02-19 Visa International Service Association, Inc. Method and system for advanced warning alerts using advanced identification system for identifying fraud detection and reporting
US20100268696A1 (en) * 2009-04-16 2010-10-21 Brad Nightengale Advanced Warning
US8903735B2 (en) 2009-04-16 2014-12-02 Visa International Service Association System and method for pushing advanced warning alerts
US20110238566A1 (en) * 2010-02-16 2011-09-29 Digital Risk, Llc System and methods for determining and reporting risk associated with financial instruments
US9747639B1 (en) * 2010-09-01 2017-08-29 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
US12039597B1 (en) 2010-09-01 2024-07-16 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
US8498929B2 (en) * 2010-09-15 2013-07-30 Corelogic Solutions, Llc System, method and computer program storage device for detecting short sale fraud
US20120078778A1 (en) * 2010-09-15 2012-03-29 Corelogic Information Solutions, Inc. System, method and computer program storage device for detecting short sale fraud
US20120215658A1 (en) * 2011-02-23 2012-08-23 dBay Inc. Pin-based payment confirmation
US10504174B2 (en) 2011-06-21 2019-12-10 Early Warning Services, Llc System and method to search and verify borrower information using banking and investment account data and process to systematically share information with lenders and government sponsored agencies for underwriting and securitization phases of the lending cycle
US8676611B2 (en) 2011-06-21 2014-03-18 Early Warning Services, Llc System and methods for fraud detection/prevention for a benefits program
WO2012177786A1 (en) * 2011-06-21 2012-12-27 Early Warning Services, Llc System and method for locating and accessing account data
US10607284B2 (en) 2011-06-21 2020-03-31 Early Warning Services, Llc System and method to search and verify borrower information using banking and investment account data and process to systematically share information with lenders and government sponsored agencies for underwriting and securitization phases of the lending cycle
US10885067B2 (en) 2012-01-09 2021-01-05 W. C. Taylor, III Data gathering and data re-presentation tools
US10078685B1 (en) * 2012-01-09 2018-09-18 W. C. Taylor, III Data gathering and data re-presentation tools
US9361656B2 (en) 2012-01-09 2016-06-07 W. C. Taylor, III Data mining and logic checking tools
US10089686B2 (en) 2012-07-03 2018-10-02 Lexisnexis Risk Solutions Fl Inc. Systems and methods for increasing efficiency in the detection of identity-based fraud indicators
US20180322572A1 (en) * 2012-07-03 2018-11-08 Lexisnexis Risk Solutions Fl Inc. Systems and Methods for Improving Computation Efficiency in the Detection of Fraud Indicators for Loans
US10217163B2 (en) 2012-07-03 2019-02-26 Lexisnexis Risk Solutions Fl Inc. Systems and methods for increasing efficiency in the detection of identity-based fraud indicators
US10043213B2 (en) * 2012-07-03 2018-08-07 Lexisnexis Risk Solutions Fl Inc. Systems and methods for improving computation efficiency in the detection of fraud indicators for loans with multiple applicants
US10762561B2 (en) * 2012-07-03 2020-09-01 Lexisnexis Risk Solutions Fl Inc. Systems and methods for improving computation efficiency in the detection of fraud indicators for loans
US8682755B2 (en) * 2012-07-03 2014-03-25 Lexisnexis Risk Solutions Fl Inc. Systems and methods for detecting tax refund fraud
US20140279380A1 (en) * 2013-03-14 2014-09-18 Fannie Mae Automated searching credit reports to identify potential defaulters
US20150066738A1 (en) * 2013-08-30 2015-03-05 Corelogic Solutions, Llc System amd method for detecting short sale fraud
US11263600B2 (en) 2015-03-24 2022-03-01 4 S Technologies, LLC Automated trustee payments system
US11816747B1 (en) * 2018-12-12 2023-11-14 United Services Automobile Association (Usaa) Systems and methods for mining data for property usage

Also Published As

Publication number Publication date
WO2009086143A2 (en) 2009-07-09
US7546271B1 (en) 2009-06-09
CA2710466A1 (en) 2009-07-09
WO2009086143A3 (en) 2009-10-08
GB2469948A (en) 2010-11-03
GB201012091D0 (en) 2010-09-01
US20090164232A1 (en) 2009-06-25

Similar Documents

Publication Publication Date Title
US7546271B1 (en) Mortgage fraud detection systems and methods
JP6549183B2 (en) Transaction monitoring system
US10657590B2 (en) System and method for an electronic lending system
US8732084B2 (en) Identification and risk evaluation
US8468088B2 (en) Automated mining and processing of data associated with real estate
JP2022520824A (en) Intelligent warning system
US20040078323A1 (en) Quality control for loan processing
US20110112960A1 (en) System for analyzing loan data
US20160196605A1 (en) System And Method To Search And Verify Borrower Information Using Banking And Investment Account Data And Process To Systematically Share Information With Lenders and Government Sponsored Agencies For Underwriting And Securitization Phases Of The Lending Cycle
US20140058910A1 (en) Method for detecting identity misrepresentation in fraudulent tax returns
JP2005503597A (en) Automated political risk management
US20070219819A1 (en) Method and system for detecting title fraud
US20140108232A1 (en) Method and system for compliance hosting
US20140279386A1 (en) Methods and system for mining and analyzing real estate information
US20100070407A1 (en) System and method for on-line lending with early warning system
KR20090001940A (en) System and method for preliminarily selecting insolvent credit transaction company and program recording medium
Yezer Personal Privacy of HMDA in a World of Big Data
Sharma Forensic Audit (Financial Institutions & IBC, 2016)
Sharma et al. Guide to investigating business fraud
Drani Epalu Analysis of the legal framework for combating bank fraud in Uganda
KR20090057194A (en) Method for preliminarily selecting insolvent credit transaction company
Booth Public record and other information on hidden assets
Network Mortgage Loan Fraud:.
ES Mortgage Loan Fraud Connections with Other Financial Crime
Dreyer et al. The Detection and Deterrence of Mortgage Fraud Against Financial Institutions: A White Paper

Legal Events

Date Code Title Description
AS Assignment

Owner name: CHOICEPOINT ASSET COMPANY, GEORGIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHMIELEWSKI, THOMAS;JAMES, DENISE;SIGNING DATES FROM 20090330 TO 20090717;REEL/FRAME:024396/0928

AS Assignment

Owner name: CHOICEPOINT SERVICES, INC., GEORGIA

Free format text: MERGER;ASSIGNOR:CHOICEPOINT ASSET COMPANY LLC;REEL/FRAME:026262/0530

Effective date: 20081231

AS Assignment

Owner name: LEXISNEXIS RISK SOLUTIONS INC., GEORGIA

Free format text: MERGER;ASSIGNOR:CHOICEPOINT SERVICES INC.;REEL/FRAME:026268/0061

Effective date: 20091201

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION