US20050108063A1 - Systems and methods for assessing the potential for fraud in business transactions - Google Patents

Systems and methods for assessing the potential for fraud in business transactions Download PDF

Info

Publication number
US20050108063A1
US20050108063A1 US10/702,088 US70208803A US2005108063A1 US 20050108063 A1 US20050108063 A1 US 20050108063A1 US 70208803 A US70208803 A US 70208803A US 2005108063 A1 US2005108063 A1 US 2005108063A1
Authority
US
United States
Prior art keywords
fraud
request
fraud potential
data element
request data
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
US10/702,088
Inventor
Robert Madill
Thomas Barger
James Rogers
Progress Thabani Mtshali
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.)
Computer Sciences Corp
Original Assignee
Computer Sciences Corp
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 Computer Sciences Corp filed Critical Computer Sciences Corp
Priority to US10/702,088 priority Critical patent/US20050108063A1/en
Assigned to COMPUTER SCIENCES CORPORATION reassignment COMPUTER SCIENCES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BARGER, THOMAS GLENN, MADILL, ROBERT P., JR., ROGERS, JAMES LEWIS, MTSHALI, PROGRESS QHAQHI THABANI
Priority to PCT/US2004/036794 priority patent/WO2005048046A2/en
Priority to US11/068,503 priority patent/US7827045B2/en
Publication of US20050108063A1 publication Critical patent/US20050108063A1/en
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/08Insurance

Definitions

  • the present invention generally relates to detecting the potential for fraud.
  • embodiments relate to systems and methods of assessing fraud potential in multiple industries.
  • Some methods for detecting the potential for fraud have focused on identifying a subset of requests for investigation that have a high potential for fraud. Such methods may make use of insurance industry databases that have been developed to assist in detecting the potential for fraud.
  • NICB National Insurance Crime Bureau
  • the NICB database includes suspicious requests that have been submitted to all participating insurance companies.
  • ISO International Insurance Crime Bureau
  • ISO International Jersey City, N.J. provides a product, ISO requestSearchTM, that includes databases for insurance claim data.
  • ISO requestSearchTM provides a product, ISO requestSearchTM, that includes databases for insurance claim data.
  • a potential for fraud may be assessed (e.g., in insurance claims, mortgage loans, banking transactions, and health care billing) using a computer system to which data is provided. While the embodiments described below describe assessing a probability for fraud in insurance claims, it is to be understood that these embodiments may also be adjusted to detect the potential of fraud in requests in other industries such as, but not limited to, banking, mortgage loans, and health care.
  • the potential for fraud may be assessed using multiple fraud potential detection techniques including, but not limited to, identity searches, identity validation, model comparisons, and business rule evaluations.
  • a relative probability of potential for fraud in a claim may be determined and a respective fraud potential indicator assigned, using a fraud potential detection technique.
  • at least one fraud potential indicator may be assessed based on at least one comparison of at least one request data element (e.g., a data element in a request to the company) to data in a database or watch list for matches and near matches.
  • at least one first fraud potential indicator may be assessed from at least one comparison of at least one request data element to at least one fraud model.
  • various request data elements may be verified to confirm the probable existence of the data (e.g., confirming that a person listed on a claim exists and actually lives at a listed address).
  • a fraud model may be created using historical fraud patterns in claims that have been proven fraudulent. Other fraud models are also contemplated.
  • at least one fraud potential indicator may be assessed using business rules designed to detect potentially fraudulent requests.
  • two or more fraud potential detection techniques may be used together (e.g., using a combined or averaged score from each technique) to give an indication of the potential for fraud in a request.
  • action may be taken on the request to further investigate the potential for fraud.
  • Some embodiments may include modifying the threshold to obtain a desired quantity of request referrals for further review.
  • a method of assessing the potential for fraud in a request may include assessing at least one first fraud potential indicator for request data from at least one comparison of at least one request data element to other data. For example, a database of suspicious names, places, cars, etc. may be maintained and compared against data from current requests. In some embodiments, a “watch-list” of data elements to look for may also be maintained (e.g., by an adjustor) and compared to current request data. In some embodiments, matches and near matches may be used to assign a “score” or fraud potential indicator for a request. In some embodiments, types of matches, frequency of matches, and frequency of near-matches may indicate a higher or lower potential of fraud. In some embodiments, the types and frequency of matches may be weighted to assign a score relative to the potential for fraud in the request.
  • the potential for fraud in a request may be assessed using an identity verification engine to verify the identification of various individuals and businesses involved in the request.
  • the insured, the claimant, doctors, lawyers, and/or other individuals may be verified by using sources such as, but not limited to, public records and bills (e.g., phone bills) to verify that the information provided for each of these individuals and businesses in the request is consistent with an actual individual or business.
  • sources such as, but not limited to, public records and bills (e.g., phone bills) to verify that the information provided for each of these individuals and businesses in the request is consistent with an actual individual or business.
  • request data may be compared to models created based on past historical fraud patterns.
  • predictive modeling, analytical modeling, and data mining techniques may be used to determine potential for fraud in a request based on how closely the request resembles the model.
  • business rules may be used to detect issues related to the potential for fraud in a claim such as, but not limited to, injury types, date of loss compared to date of report, policy expiration compared to the date of the report, existence of a police report, and the number of vehicles involved.
  • the business rules may be modified to accommodate for regional differences and changing trends in fraud.
  • an administrative component may be added to allow a user to load information, values, thresholds, and/or other data for using the system.
  • the system may include links to relevant websites (e.g., with investigative tools).
  • references may be included for use by people such as, but not limited to, adjustors and investigators. For example, a link to the state of New York Insurance Manual may be included.
  • Other components are also contemplated.
  • FIG. 1 illustrates a network diagram of a wide area network suitable for implementing various embodiments.
  • FIG. 2 illustrates a computer system suitable for implementing various embodiments.
  • FIG. 3 illustrates a flowchart of a method for assessing the potential for fraud in a request, according to an embodiment.
  • FIG. 4 a illustrates a flowchart of a method for detecting a potential for fraud in a request using an identity search, according to an embodiment.
  • FIG. 4 b illustrates a flowchart of a method for detecting a potential for fraud in a request using an identity verification, according to an embodiment
  • FIG. 5 illustrates a flowchart of a method for detecting a potential for fraud in a request using predictive modeling, according to an embodiment.
  • FIG. 6 illustrates a flowchart of a method for detecting a potential for fraud in a request using business rules, according to an embodiment.
  • FIG. 7 illustrates a system using an identity search engine, a rules engine, and a predictive modeling engine, according to an embodiment.
  • FIG. 8 illustrates a flowchart for assigning and referring requests, according to an embodiment.
  • FIG. 9 illustrates a flowchart of a method for using request data to assess the potential for fraud in a request and report the potential, according to an embodiment.
  • FIG. 10 illustrates a flowchart of a method for loading request data into a database accessible by a fraud assessment system, according to an embodiment.
  • FIG. 11 illustrates a screenshot of an insurance claim summary, according to an embodiment.
  • FIG. 12 illustrates a screenshot of a watch list, according to an embodiment.
  • FIG. 13 illustrates a screenshot of a watch list update, according to an embodiment.
  • FIG. 14 illustrates a screenshot of a manager notebook with the referred tab selected, according to an embodiment.
  • FIG. 15 illustrates a screenshot of a manager notebook with the assigned tab selected, according to an embodiment.
  • FIG. 16 illustrates a screenshot of a manager notebook with the rejected tab selected, according to an embodiment.
  • FIG. 17 illustrates a screenshot of an identity search engine summary, according to an embodiment.
  • FIG. 18 illustrates a screenshot of identity search engine results, according to an embodiment.
  • FIG. 19 illustrates a screenshot of predictive modeling engine summary results, according to an embodiment.
  • FIG. 20 illustrates a screenshot of a business rules summary, according to an embodiment.
  • FIG. 21 illustrates a screenshot of business rules details, according to an embodiment.
  • FIG. 22 shows a flowchart of a method for displaying summary information related to the various engines, according to an embodiment.
  • FIG. 23 illustrates a flowchart of a method for displaying summary information related to involved entities, according to an embodiment.
  • FIG. 24 illustrates a flowchart of a method for configuring administrative information for a fraud potential detection system, according to an embodiment.
  • FIG. 25 illustrates a flowchart of a method for displaying assessment results, according to an embodiment.
  • FIG. 26 illustrates a flowchart of a method for displaying information about requests using tabs, according to an embodiment.
  • FIG. 1 illustrates an embodiment of a wide area network (“WAN”).
  • WAN 102 may be a network that spans a relatively large geographical area.
  • the Internet is an example of WAN 102 .
  • WAN 102 typically includes a plurality of computer systems that may be interconnected through one or more networks. Although one particular configuration is shown in FIG. 1 , WAN 102 may include a variety of heterogeneous computer systems and networks that may be interconnected in a variety of ways and that may run a variety of software applications.
  • LAN 104 may be coupled to WAN 102 .
  • LAN 104 may be a network that spans a relatively small area. Typically, LAN 104 may be confined to a single building or group of buildings.
  • Each node (i.e., individual computer system or device) on LAN 104 may have its own CPU with which it may execute programs, and each node may also be able to access data and devices anywhere on LAN 104 .
  • LAN 104 thus, may allow many users to share devices (e.g., printers) and data stored on file servers.
  • LAN 104 may be characterized by a variety of types of topology (i.e., the geometric arrangement of devices on the network), of protocols (i.e., the rules and encoding specifications for sending data, and whether the network uses a peer-to-peer or client/server architecture), and of media (e.g., twisted-pair wire, coaxial cables, fiber optic cables, and/or radio waves).
  • topology i.e., the geometric arrangement of devices on the network
  • protocols i.e., the rules and encoding specifications for sending data, and whether the network uses a peer-to-peer or client/server architecture
  • media e.g., twisted-pair wire, coaxial cables, fiber optic cables, and/or radio waves.
  • Each LAN 104 may include a plurality of interconnected computer systems and optionally one or more other devices such as one or more workstations 110 a, one or more personal computers 112 a, one or more laptop or notebook computer systems 114 , one or more server computer systems 116 , and one or more network printers 118 . As illustrated in FIG. 1 , an example LAN 104 may include one of each computer systems 110 a, 112 a, 114 , and 116 , and one printer 118 . LAN 104 may be coupled to other computer systems and/or other devices and/or other LANs 104 through WAN 102 .
  • mainframe computer systems 120 may be coupled to WAN 102 .
  • mainframe 120 may be coupled to a storage device or file server 124 and mainframe terminals 122 a, 122 b, and 122 c.
  • Mainframe terminals 122 a, 122 b, and 122 c may access data stored in the storage device or file server 124 coupled to or included in mainframe computer system 120 .
  • WAN 102 may also include computer systems connected to WAN 102 individually and not through LAN 104 for purposes of example, workstation 110 b and personal computer 112 b.
  • WAN 102 may include computer systems that may be geographically remote and connected to each other through the Internet.
  • FIG. 2 illustrates an embodiment of computer system 250 that may be suitable for implementing various embodiments of a system and method for assessing the potential for fraud in requests (e.g., insurance claims, bank checks, loan requests, and health care bills).
  • Each computer system 250 typically includes components such as CPU 252 with an associated memory medium such as floppy disks 260 .
  • the memory medium may store program instructions for computer programs.
  • the program instructions may be executable by CPU 252 .
  • Computer system 250 may further include a display device such as monitor 254 , an alphanumeric input device such as keyboard 256 , and a directional input device such as mouse 258 .
  • Computer system 250 may be operable to execute the computer programs to implement computer-implemented systems and methods for assessing the potential for fraud in insurance claims.
  • Computer system 250 may include a memory medium on which computer programs according to various embodiments may be stored.
  • the term “memory medium” is intended to include an installation medium, e.g., a CD-ROM or floppy disks 260 , a computer system memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a non-volatile memory such as a magnetic media, e.g., a hard drive or optical storage.
  • the memory medium may also include other types of memory or combinations thereof.
  • the memory medium may be located in a first computer, which executes the programs or may be located in a second different computer, which connects to the first computer over a network. In the latter instance, the second computer may provide the program instructions to the first computer for execution.
  • Computer system 250 may take various forms such as a personal computer system, mainframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (“PDA”), television system or other device.
  • PDA personal digital assistant
  • computer system may refer to any device having a processor that executes instructions from a memory medium.
  • the memory medium may store a software program or programs operable to implement a method for assessing the potential for fraud in insurance claims.
  • the software program(s) may be implemented in various ways, including, but not limited to, procedure-based techniques, component-based techniques, and/or object-oriented techniques, among others.
  • the software programs may be implemented using ActiveX controls, C++ objects, JavaBeans, Microsoft Foundation Classes (“MFC”), browser-based applications (e.g., Java applets), traditional programs, or other technologies or methodologies, as desired.
  • a CPU such as host CPU 252 executing code and data from the memory medium may include a means for creating and executing the software program or programs according to the embodiments described herein.
  • Suitable carrier media may include storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, as well as signals such as electrical, electromagnetic, or digital signals, may be conveyed via a communication medium such as a network and/or a wireless link.
  • Various embodiments include assessing the potential for fraud in requests. While various embodiments for assessing the potential for fraud are discussed below with respect to insurance claims, it is to be understood that these embodiments may also be applied to detecting other kinds of fraud including, but not limited to, check fraud, mortgage or other loan application fraud, and health billing fraud.
  • a “claim” may refer to a demand for compensation for a loss, such as, but not limited to, medical treatment due to bodily injury, death of an insured, property damage, etc.
  • the systems and methods disclosed herein may be used to detect the potential for various kinds of fraud in insurance claims such as, but not limited to, health, property and casualty, and/or life.
  • request data may include information related to any parties related to the request.
  • parties related to the request may include, but are not limited to, claimants, witnesses, insureds, medical providers, and/or individuals and/or businesses providing repair services.
  • request data is used in the following descriptions to refer to data related to requests (e.g., checks, insurance claims, mortgage or other loan applications, and health care billing).
  • request data related to an insurance claim may include, but is not limited to, date of the claim and/or date of loss, inception date of a policy, expiration date of a policy, addresses of parties related to the claim, and details of the loss or the accident leading to the loss.
  • a characteristic of an accident may also include a set of two or more individual characteristics. For example, a set of characteristics may describe a type of accident that is commonly staged to perpetrate insurance fraud.
  • request data may include check data.
  • check data may include information on a drawer (person who writes the check), a payee (the person to whom the check is payable to), a date, an account number, a routing number, and information on involved banks including, but not limited to, a drawee bank and a depository bank.
  • request data may include loan application data.
  • loan application data may include, but is not limited to, information about the loan applicant, loan applicant's credit history, other debts of the loan applicant, income level of the loan applicant, criminal history of the loan applicant, social security number, address, other obligations (e.g., child support), information on the item to be purchased with the loan money (e.g., title search), and information about other parties involved in the loan.
  • request data may include health care billing data (e.g., name of person receiving care, name of the doctor, type of treatment, and extent of stay in a hospital). Other types of data may also be analyzed as request data.
  • the potential for fraud may be detected using multiple fraud potential detection techniques including, but not limited to, identity searches, identity verifications, model comparisons, and business rule evaluations.
  • an overall relative level of potential for fraud i.e., overall fraud potential indicator
  • at least one fraud potential indicator may be assessed based on at least one comparison of at least one request data element to data in a database or watch list for matches and near matches.
  • a fraud potential indicator may be assessed from at least one comparison of at least one request data element to at least one fraud model.
  • a fraud potential indicator may be assessed from attempting to verify a request data element.
  • a fraud potential indicator may be assessed by comparing request data elements to a fraud model created using historical fraud patterns in past requests proven fraudulent. Other fraud models are also contemplated. In some embodiments, at least one fraud potential indicator may be assessed using business rules designed to detect the potential for fraud in a request.
  • two or more fraud potential detection techniques may be used together (e.g., using a combined or averaged score from each technique) to give an indication of whether fraud may exist in a request.
  • action may be taken on the request to further investigate the potential of fraud.
  • Some embodiments may include modifying the threshold to obtain a desired quantity of request referrals for further review. For example, if the threshold is set too low, a large number of requests may be referred for review including requests with a low potential for fraud.
  • FIG. 3 illustrates a flowchart of an embodiment of a process for assessing the potential for fraud in requests.
  • request data for a request may be provided (e.g., imported from an insurance claims processing system of an insurance carrier) to a computer system for assessing the potential for fraud in the request.
  • the request data may include first notice of loss (FNOL) data taken at the time of loss from the claimant and other policy data, information on a check to be cashed, or information about a requested loan.
  • FNOL first notice of loss
  • Request data may be extensive and may include, but is not limited to, information about an insured, a claimant, and other involved parties. Information about other involved parties may include information about involved businesses, doctors, and lawyers.
  • Other request data may include the date of the request, the type of loss, how many people were involved, and information about vehicles or property involved. Other types of request data are also contemplated.
  • request data (e.g., claim data, check data, and loan data) on a processing system (e.g., insurance claim processing system, check processing system, and loan processing system) may be updated as new information is obtained.
  • the request data may be transmitted on a periodic basis (e.g., every 24 hours) to the computer system for assessing fraud potential.
  • a computer system may both collect and process data without having to transmit the data to another computer system.
  • the data may be analyzed in real-time (e.g., as the data is being entered or processed, for example, by an adjuster).
  • a relevant profile (e.g., claim data profile, check data profile, and loan data profile) may be created.
  • a request data profile may be created by extracting information relevant to assessing the potential for fraud in a request to form a condensed version of the request data.
  • the request data may not be extracted (i.e., a request data profile may not be created), but, instead, the request data may be used as needed by the computer system.
  • a fraud potential detection technique may be used to detect the potential for fraud in a request (e.g., an insurance claim).
  • search engines, model comparisons, and business rules may be used to detect the potential for fraud in a request.
  • an assessment of fraud potential (i.e., a fraud potential indicator) in a request may be represented by a numerical indicator (e.g., a “score”), a ranking (e.g., using letters), or a pass/fail indicator. Other assessment representations are also contemplated.
  • the fraud potential indicator may indicate a relative potential for fraud.
  • a fraud potential indicator may be on a scale of one to ten with one indicating a very low potential for fraud and ten indicating a very high potential for fraud.
  • fraud potential detection techniques may include identity searches, identity verifications, predictive modeling, and business rules. Other techniques are also contemplated.
  • the identity searches may compare request data to internal and external databases (e.g., an internal “watch list” or a National Insurance Crime Bureau (NICB) database) to find matches between the databases and the request data.
  • request data may be verified.
  • predictive modeling may compare request data to historical fraudulent patterns (e.g., request data from past proven fraudulent requests).
  • the identity searches may compare check data and loan data to internal and external databases to find matches that may indicate a potential for fraud.
  • business rules may be used to find issues in the request data that may indicate the potential for fraud.
  • identity searches, identity verification, predictive modeling, and business rules may be used to detect an absence of potential for fraud (e.g., request data that indicates the request probably is not fraudulent).
  • Various embodiments may include one or more of the fraud potential detection techniques to assign one or more fraud potential indicators.
  • the fraud potential indicators may be combined (e.g., by adding and/or weighting) to provide a single fraud potential indicator for a request. In some embodiments, the fraud potential indicators may be used separately.
  • a request's fraud potential indicators may be analyzed.
  • the fraud potential indicators may be manually analyzed (e.g., by an adjuster) to determine if further investigation is needed.
  • the fraud potential indicators may be compared to a threshold.
  • the fraud potential indicators may be combined and the combined fraud potential indicator may be compared to a threshold to determine if further action is needed.
  • multiple requests may be ranked in order, according to their fraud potential indicators (e.g., highest probable fraudulent request may be listed first). In certain embodiments, only requests with fraud potential indicators above a threshold may be ranked.
  • the request may be further investigated.
  • the requests may be assigned to an adjuster, investigator, and/or Special Investigative Unit (SIU) based on the level of potential for fraud in the request (e.g., based on the request's fraud potential indicators). For example, a request with relatively low fraud potential indicators may be assigned to an adjuster, while a request with fraud potential indicators above a certain threshold may be assigned to investigators. In some embodiments, if the fraud potential indicators are above a certain threshold, the request may be referred to an SIU.
  • SIU Special Investigative Unit
  • the request may be processed normally. In some embodiments, if fraud potential indicators are low enough (e.g., negative), payment of the request may be expedited. In some embodiments, as additional request data becomes available, the request may be reassessed. In addition, requests may be reassessed for other reasons (e.g., if new predictive models are developed).
  • FIG. 4 a illustrates a flowchart of an embodiment of a method for assessing potential for fraud in a request using an identity engine.
  • the request data may be compared to various databases.
  • request data may be searched for people, addresses, vehicles, businesses, and other data elements that may indicate a potential for fraud in the request.
  • people, vehicles, and businesses involved in the request may be compared to people, vehicles, and businesses listed in databases, such as, but not limited to, the National Insurance Crime Bureau (NICB) database, an insurance companies historical claims database, a commercial mailbox database, a “watch list” database, and an SIU database for a match.
  • NICB National Insurance Crime Bureau
  • people involved in the request may be searched by their first name, last name, social security number, address, city, home phone, and work phone.
  • vehicles may be searched by vehicle type, VIN number, and license tag number. For example, if a vehicle involved in the current request was also involved in a past claim that was proven fraudulent and therefore the vehicle was listed in the NICB database, the current request may be assigned a high fraud potential indicator.
  • Other external databases may also be searched.
  • a high frequency of previous requests e.g., insurance claims
  • involving the same person or vehicle may indicate a higher potential for fraud.
  • a commercial mailbox database may have addresses that belong to commercial mail receiving agencies (CMRAs) (organizations that rent out commercial mailboxes).
  • CMSRAs commercial mail receiving agencies
  • the use of a commercial mailbox may be indicate that a person is trying to disguise themselves for fraud purposes.
  • Various levels of fraud potential indicators may be assigned depending on whether the commercial mailbox is used by a person or a business involved in the request.
  • a “watch list” database may be established to find requests with certain people, vehicles, businesses, and other data elements that indicate the possibility of fraud.
  • an organization may be added to the watch list.
  • Information about the organization on the watch list may include, but is not limited to, the business name, the DBA name, the address, the phone numbers, the role of the organization respective to the claim, and the tax identification number of the organization.
  • Other information that may be included on the watch list may include the source of the information for an entry on the watch list, the author of the entry on the watch list, the author's region, and other comments.
  • the watch list may be set up by an adjustor or SIU. Other entities may also create a watch list. If a match is detected, the author of the particular watch list involved may be notified and a corresponding fraud potential indicator may be assigned.
  • a sanctioned medical providers database may be searched for businesses that have been disciplined for questionable business practices.
  • Other databases maintained by industry groups and commercial entities may also be searched.
  • industry databases may be searched.
  • an “industry database” may refer to a centralized database that includes request data contributed by more than one insurance company to assist other insurance companies in detecting fraud.
  • databases may be searched that do not indicate a possibility of fraud but instead are searched for other reasons such as, but not limited to, compliance with state and federal laws.
  • OFAC Office of Foreign Assets Control
  • databases may be searched for request data elements to indicate the involvement of possible terrorists (in compliance with the requirements set forth in the Patriot Act).
  • a fraud potential indicator may be assigned to the request based on matches between the request data and entries in at least one of the databases.
  • the identity fraud potential indicator may be weighted based on the frequency of matches, frequency of near matches, type of match (e.g., type of database matched), number of databases matched, and other factors. For example, a higher fraud potential indicator may be assigned to a request in which the name of the claimant matches a listed name in the NICB's database and the insurance company's internal database than if a claimant had only matched an entry on the insurance company's internal database.
  • the request may be given a higher fraud potential indicator if multiple request data elements match entries in one or more searched databases.
  • a request may be given a higher fraud potential indicator if the name of the claimant and the claimant's listed physician match names on the NICB's database than if only the claimant's name was found in the NICB's database.
  • a request may receive a higher fraud potential indicator if a request element matches a data element in a database than if the request element was a near-match to a data element in the database.
  • near matches may be weighted differently depending on the degree of match (e.g., the number of letters that match compared to the number of letters that do not match).
  • the fraud potential indicator may be based on other expert knowledge of insurance claims and/or fraud assessment.
  • a fraud potential indicator may be assigned to each request data element that matches and a total identity fraud potential indicator may be assigned based on the fraud potential indicators for the various request data elements (e.g., by adding or averaging the fraud potential indicators for multiple request data elements).
  • multiple elements of the claims may logically match and therefore be weighted as only one match for assigning an identity fraud potential indicator. For example, if the same person appears in two claims, the person's name, address, and phone number may all match, however, it may be misleading to indicate multiple matches with the searched database. Therefore, logical matches may be accounted for and the identity fraud potential indicator may be appropriately adjusted. TABLE 1 Search rules for Identity Searching.
  • search rules may be created and used with requests when performing searches.
  • Table 1 provides a summary of an embodiment of search rules that may be used to search request data elements. Different search rules may also be used.
  • the “Matching Item in Request Data” refers to a request data element that may match or approximately match a database of insurance data.
  • An “Involved Person” is a particular person related to the request, for example, a claimant.
  • a “Vehicle” refers to a particular vehicle related to a request, for example, a vehicle involved in an accident.
  • An “Involved Business” refers to a particular business related to a request, for example, a medical provider or vehicle repair shop. An involved vehicle or business may also be referred to as an “involved object.”
  • the fraud potential indicator assessed for a match of a request data element to a database may be different for an involved party, an involved business, or an involved object.
  • search rules may be provided to search data from a check.
  • the drawer may be compared to people listed in a hot check database.
  • Other check data may also be searched for suspicious circumstances.
  • data related to a loan may be searched.
  • the loan applicant's name may be searched for in established databases of past fraudulent loan applications.
  • Other data related to a loan may also be searched for indications of the possibility of fraud.
  • a formula may be used to determine the fraud potential indicator for a request.
  • a formula may be based on several factors, such as, but not limited to, the number of matches of request data to a database. Additional factors may include a loss type, ranking, point weight, and/or adjustment numbers.
  • a loss type may take into account the fact that certain types of requests tend to be associated with a higher rate of fraud. Request types that are unusual or are difficult to verify are examples of such requests. For example, stolen vehicle requests may tend to have a higher incidence of fraud than certain types of collisions.
  • the fraud potential indicator for a rule may be calculated by multiplying the number of matches by a ranking, point weight, an adjustment number and/or a numerical value associated with a loss type.
  • a search for an involved party in a database may involve a search for the involved parties' names, addresses, home phone numbers, work phone numbers, etc.
  • a search for an involved vehicle may include search for a Vehicle Identification Number (VIN#) and/or a license tag number.
  • a search for an involved business may include a search for a business name, a “doing business as” name, an address, business phone number, etc.
  • Search rules S-1 and S-10 (from Table 1) both involve comparisons of request data to a company historical requests database.
  • the frequency of previous requests by an involved person or a particular vehicle may be indicative of fraud, even if the prior requests were not suspicious.
  • Search rules S-2, S-5, and S-7 involve comparisons of request data to an industry database such as the NICB database.
  • a new request may be suspicious if it involves an individual or business that has been investigated previously by an industry organization such as the NICB.
  • a request may be suspicious if it involves a vehicle involved in a prior suspicious request. In these cases, the potential for fraud increases if such matches exist. Additionally, there may be a connection between the owner or prior owner of the vehicle involved in an accident and a new claim.
  • Search rules S-3 and S-4 both involve comparisons of request data to an SIU database.
  • a new request may be suspicious if it involves an individual or vehicle that has been investigated previously by an SIU. The potential for fraud in a new request may be increased in these cases.
  • Search rules S-6 and S-8 both involve matches of request data to a commercial mailbox database.
  • CMRA commercial mail receiving agencies
  • CMRAs offer some degree of anonymity and distance from their true place of residence.
  • CMRAs are also used to prevent insurance companies from attributing previous accident history to their real address in order to lower insurance premiums. If a person uses a CMRA address with respect to an insurance claim, especially if the address is written as if it is a suite or apartment, it may be important to ascertain the true address of the person.
  • Search rules S-9 and S-12 both involve comparisons of request data to a watch list database.
  • SIU investigators and/or insurance company management may gather intelligence data from law enforcement, other carriers, and/or from personal experience concerning individuals or business that may be involved in fraud.
  • Search rules S-9 and S-12 allow suspicious entities to be entered directly into a watch list database for comparison to new requests data.
  • the author of an item on the watch list may be notified of any matches.
  • Search rule S-11 involves comparisons of request data to a sanctioned medical provider database. Medical providers or medical businesses that have been disciplined for questionable business practices may be entered in this database. Matches from a new request to a medical provider in a sanctioned medical providers database may indicate a potential for fraud in the new request.
  • the potential for fraud in a request may be assessed using an identity verification technique, as seen in FIG. 4 b, to verify the identification of various individuals and businesses involved in the request.
  • a request data element may be verified against various databases.
  • the insured, claimant, doctors, lawyers, and other individuals may be verified by searching public records and bills (e.g., phone bills) to verify that the information provided for each of these individuals and businesses in the request corresponds to an actual individual or business's name.
  • a fraud potential indicator may be assigned based on whether the verification was successful. In some embodiments, the level of the fraud potential indicator assigned may depend on the number of request data elements that could be verified.
  • identity verification may also be used to meet compliance requirements in various state and federal laws.
  • FIG. 5 illustrates a flowchart of an embodiment of a method for assessing a fraud potential indicator for a request by predictive modeling.
  • request data may be compared to at least one fraud pattern (also called a fraud model) to search for similarities between the request data and fraud patterns.
  • a fraud potential indicator may be assigned to a request based on similarities between request data and a fraud model.
  • the fraud potential indicator may be a numerical value associated with a type of fraud pattern.
  • the fraud potential indicator may be based on expert knowledge of insurance claims and/or fraud assessment.
  • At least one fraud pattern may be associated with an indication of fraud.
  • a fraud potential indicator may be assigned based on a match between the request data and at least one characteristic of a fraud pattern.
  • a fraud potential indicator may be weighted according to the nearness of a match or approximate match. In some embodiments, an exact match may indicate a higher potential for fraud than an approximate match.
  • a fraud pattern used in predictive modeling may be established using historical data obtained from requests in which fraud was previously identified.
  • a fraud model may include relationships between parties relating to the request and/or request data.
  • a fraud model may include the characteristics of a suspicious accident such as a staged rear-end collision.
  • a worker's compensation claim is filed for an accident that took place at work on a Monday morning without any witnesses, the claim may be assigned a relative fraud potential indicator.
  • a request may be compared to a predictive model using these request elements:
  • circumstances may indicate a “swoop and stop” type fraud.
  • a request for a rear end collision with a match for a sanctioned doctor for the claimant may be assigned a relative fraud potential indicator.
  • Other circumstances may also be detected.
  • one or more predictive modeling fraud potential indicators may be combined and/or weighted if appropriate to obtain a total predictive modeling fraud potential indicator for the request.
  • one or more predictive modeling fraud potential indicators may be assigned a weighting.
  • the weighted fraud potential indicators may be combined to obtain a total predictive modeling fraud potential indicator for the request.
  • FIG. 6 shows a flowchart of an embodiment of a method of assessing a fraud potential indicator for request data using business rules.
  • a business rule may be used to detect suspicious conditions in a request.
  • business rules may be used to analyze the injury type, the loss type, the existence of a police report, who reported the request, and the number of vehicles involved.
  • business rules may be used to compare the date of loss to the date of the report of the request, the policy inception date to the date of loss, and the policy expiration date to the date of the report.
  • Business rules may also be used to search for other conditions in a request that may indicate fraud.
  • the type of injury involved and the number of injuries may indicate whether the request is likely to be fraudulent.
  • serious or visible signs of injury in the request may be contra-indicative of fraud, but soft-tissue or other non-visible complaints of injuries (especially by numerous passengers) may be indicative of possible fraud.
  • a business rule may apply a multiplier to a fraud potential indicator based on the injury type.
  • the injury type multipliers may be applied for the corresponding injury types (multiple injury types may be added together). For example:
  • multiplier may be a user supplied number based on different aspects of the request.
  • negative injury type multipliers may be assigned to injury types (e.g., fatality) that are contra-indicative of fraud.
  • higher values may be assigned to injury types more indicative of fraud (e.g., soft tissue injuries).
  • the loss type may indicate fraud. For example, request types that are unusual or difficult to verify may indicate more potential for fraud.
  • a loss type multiplier may be applied (multiple loss types may be added). For example:
  • the date of loss (e.g., accident) versus the date of the report of a claim may be used to detect potential for fraud. Claims tend to be reported by parties involved in an accident shortly after the date of loss. A delay in reporting may be an indication that facts relating to an accident may be fabricated. In some embodiments, the longer the delay between date of loss (DOL) and the date of report (DOR) to a requests organization, the greater the potential for fraud in a request.
  • the fraud potential indicator of the DOL vs. DOR business rule may be combined with a loss type value. For example, DOL vs. DOR fraud potential indicator may be multiplied by a loss type value. The fraud potential indicator may also be weighted by a ranking factor.
  • the policy effective date versus the date of loss may indicate fraud. There may be a significant correlation between the likelihood of fraud and a short time frame between the policy inception date and the DOL. Fictitious circumstances tend to accompany such requests since the true date of loss may be just prior to a decision to purchase insurance. In some embodiments, as the number of days increases between policy inception date and DOL the chance of the request being false decreases. The trend may be reflected in a fraud potential indicator.
  • the fraud potential indicator associated with policy effective date vs. DOR fraud potential indicator may be combined with a fraud potential indicator of the loss type value.
  • the fraud potential indicators may be multiplied together.
  • the fraud potential indicator may be combined with a ranking factor.
  • the time period between policy inception date and DOL may be divided into a set of ranges.
  • a fraud potential indicator may be associated with one or more of such ranges.
  • the fraud potential indicator for the policy inception date vs. DOL fraud potential indicator may be set to approximately zero if there was policy renewal.
  • the policy expiration date versus the date of report of loss may be a fraud potential indicator. There tends to be a significant correlation between the likelihood of fraud and a report of a request occurring after the policy expiration date. Typically, requests tend to be reported within the policy period and as close to the DOL as possible. In some embodiments, requests reported on or near the policy expiration date or within weeks afterward are suspicious and may have an increased potential for fraud.
  • the absence of a police report may be an indication of fraud.
  • police reports often accompany insurance claims, except for very minor issues.
  • a fraud potential indicator from a no police report business rule may be combined with (e.g., multiplied by) a ranking factor if other indications of fraud are present.
  • a fraud potential indicator may be multiplied by 0 if a police report was filed and 2 if the police report was not filed. Other multipliers may also be used.
  • the identity of the person who made the request may be an indication of fraud.
  • a fraud potential indicator may be assigned based on who and how the request was initially made. For example, if an attorney or public adjustor reports a property damage only claim, there may be an increased potential for fraud. In some embodiments, it may be less suspicious when an insured person reports the request.
  • the number of vehicles involved in an accident may be an indication of fraud for an insurance claim. In some embodiments, the number of vehicles involved in an accident may be both an indication of fraud and a counter-indicator of fraud depending on the circumstances. For example, accidents involving more than two vehicles tend to be more difficult to stage, and therefore, may be less likely to be fraudulent. In some embodiments, a multi-vehicle accident may have a negative contribution to the fraud potential indicator for a request. However, single vehicle accidents may have a greater potential of being fraudulent. In some embodiments, the fraud potential indicator associated with the number of vehicles involved may be combined with (e.g., multiplied by) a ranking factor if other indications of fraud are present. In some embodiments, if using formulas, multiple vehicle accidents may be assigned negative multipliers.
  • the length of time between the date a check was written and the date that the check is cashed may be an indication of fraud.
  • inconsistent loan data may be an indication of fraud.
  • an application that indicates a person has a low salary, but very high liquid assets value may have a higher potential for fraud.
  • other circumstances about a request may be analyzed using business rules. For example, loan data may be used to determine the amount of money an applicant may be loaned under the “28/36” rule for mortgages. In some embodiments, a loan applicant's income may be compared to his assets. Other circumstances may also be investigated.
  • a user may be allowed to create one or more user-defined (i.e., custom) business rules.
  • a custom business rule may include information from the user for assessing a fraud potential indicator for a request.
  • a business rule may be used to assign a fraud potential indicator to at least one request.
  • a business rule may be designed to detect suspicious circumstances reported in a request and used to assign an appropriate fraud potential indicator to the request.
  • business rule fraud potential indicators may be combined to obtain a total business rule fraud potential indicator for the request. For example, if circumstances match two different business rules, a higher fraud potential indicator may be assigned. In some embodiments, at least one business rule fraud potential indicator may be weighted. In various embodiments, weighted business rule fraud potential indicators may be combined to obtain a total business rule fraud potential indicator for the request.
  • FIG. 7 illustrates an embodiment of software components for performing fraud analysis.
  • An embodiment of a system for assessing the potential for fraud in an insurance claim may include a plurality of software components.
  • a software component may perform at least a portion of a method for assessing the potential for fraud in an insurance claim.
  • Request data 701 may be stored in at least one database.
  • the request data 701 may be obtained from a variety of sources. The sources may include, but are not limited to, an insurance policy, accident reports, parties related to the request, insurance adjusters, insurance fraud investigators, etc.
  • request data 701 may be processed for assessment of the potential for fraud by at least one software component.
  • Data transformer component 703 may extract information from the request data 701 that may be relevant to assessing the potential for fraud in an insurance claim. Data transformer component 703 may then create a request data file in a desired format using the extracted data.
  • identity engine component 705 may be used to assign at least one fraud potential indicator 717 for request data 701 .
  • Identity engine component 705 may compare at least one request data element to various databases.
  • various databases may include, but are not limited to, insurance industry data 725 , commercial mailbox data 727 , SIU data 729 , sanctioned medical providers data 731 , company requests data 733 and/or custom watch list data 735 .
  • Identity engine component 705 may assess similarities between (e.g., matches or approximate matches of characteristics) request data 701 and the various databases.
  • a fraud potential indicator 717 for the request data 701 may be evaluated from the similarities by evaluation component 711 .
  • identity engine component 705 may evaluate a fraud potential indicator 717 directly.
  • Identity Systems from Search Software America (SSA) of Old Greenwich, Conn. may be used with the identity engine component 705 .
  • SSA IDS performs searching, matching, and duplicate discovery for many forms of identification data.
  • SSA IDS transparently maintains its own high performance “fuzzy”indexes, and de-normalized tables.
  • SSA IDS also compensates for variation, spelling, keying, and word sequence errors in names, addresses and identity data regardless of country, language or character set.
  • SSA IDS also supports searches of aliases, former names, compound names, prior addresses, multiple dates of birth, identity, phone numbers, etc.
  • rules engine component 707 may assess at least one fraud potential indicator 719 for request data 701 .
  • Rules engine component 707 may compare at least one request data element to at least one business rule 737 .
  • a “rules engine” may include an expert system, which is operable to produce an output as a function of a plurality of rules.
  • a rules engine component 707 in some embodiments, may include an expert computer system that utilizes and/or builds a knowledge base in the form of business rules and/or formulas 737 to assist the user in decision-making.
  • rules engine component 737 may include rules based on expert knowledge for assessing the potential for fraud in an insurance claim.
  • the Visual Product Modeling System from Computer Sciences Corporation in El Segundo, Calif. may be used in rules engine component 707 .
  • the fraud potential indicator 717 for a request may be assessed by rules engine component 707 or evaluation component 713 .
  • predictive modeling engine component 709 may assess a fraud potential indicator 721 for request data 701 .
  • predictive modeling component 709 may develop fraud patterns (or “fraud models 723”) from historical request data associated with fraudulent requests.
  • predictive modeling component 709 may compare at least one request data element to at least one fraud model 723 .
  • predictive modeling engine component 709 may assess similarities (e.g., matches or approximate matches) of at least one request data 701 to at least one fraud model 723 .
  • a fraud potential indicator 721 for the request may be evaluated by evaluation component 715 based on identified similarities.
  • predictive modeling engine component 709 may evaluate a fraud potential indicator 721 directly.
  • a predictive modeling engine component 709 may be operable to search for patterns in a group of historical data as a means of assessing future behavior.
  • a predictive modeling engine 709 may discover previously unknown relationships among data.
  • predictive modeling component 709 may be used to detect suspicious relationships or fraud patterns among claimants, witnesses, medical providers, attorneys, repair facilities, etc.
  • predictive modeling engine component 709 may create and store a list of such fraud patterns 723 evaluated from past fraudulent request data.
  • Predictive Targeting System from Magnify of Chicago, Ill. may be used in predictive modeling engine component 709 .
  • an administrative component may be added to allow a user to load information, values, thresholds, and other data for using the system.
  • the system may include links to relevant tools (e.g., websites with investigative tools).
  • links to information relevant to a user's usage of the system or workload may also be included.
  • references may be included for use by people such as, but not limited to, adjustors and investigators.
  • links to references may be included on a menu bar. For example, a link to the state of New York Insurance Manual may be included for access by an investigator who is investigating a claim in New York. As another example, a company's standard operating procedures could be linked.
  • Other components are also contemplated.
  • FIG. 8 shows an embodiment of software components for assigning requests (e.g., claims) to investigators. While FIGS. 8-21 show embodiments in which the request is an insurance claim, FIGS. 8-21 may also be applied to other requests (e.g., checks and loans).
  • rules 803 may be used to analyze fraud potential indicators ( 717 , 719 , 721 ) assigned to a claim. In some embodiments, the fraud potential indicators may also be combined (e.g., by adding) and/or weighted according to rules 803 . In some embodiments, rules 803 may be used by an assignment and referral component 801 to assign a claim to an SIU 805 .
  • rules may analyze whether one or more fraud potential indicators (or the combined and/or weighted fraud potential indicator) are above a certain threshold to assign the claim to the SIU.
  • the rules 803 may be used to assign a claim to an investigator (e.g., if the fraud potential indicator(s) indicate a smaller likelihood of the claim being fraudulent than claims to be assigned to the SIU).
  • the claim may be assigned to an adjuster 809 for review.
  • the fraud potential indicator(s) are not above a certain threshold (or are below a defined threshold)
  • the claim may be assigned to routine claim handling.
  • the fraud potential indicator(s) are low enough (e.g. negative) the claim may be paid 813 without further handling.
  • assignment and referral component 801 may notify at least one claims adjustor or an SIU investigator by e-mail of the status of the claim.
  • a user that has defined a custom profile relevant to a claim may be notified by e-mail.
  • relative rankings for claims may be assigned based on a fraud potential indicator for the claim obtained from one or more of the fraud potential detection techniques.
  • the status of a claim may be associated with a range of fraud potential indicators. For example, at least two ranges of fraud potential indicators may be defined. The ranges may provide a method of ranking claims in terms of relative fraud potential indicators. In certain embodiments, at least one of the ranges may be associated with an action regarding a claim. For example, a claims organization may consider a claim with a fraud potential indicator below a certain value to have a low probability of being fraudulent. Therefore, the claims organization may associate the range below a certain value with automatic or express payment of the claim.
  • a claim with a fraud potential indicator in a certain range may be associated with routine claim handling.
  • a claims adjuster may be notified of the increased fraud potential indicator for a claim with a fraud potential indicator above a certain threshold.
  • a claim with a fraud potential indicator greater than a threshold value (referred to herein as a minimum referral threshold) may be automatically referred for an investigation with a high level of scrutiny such as that performed by a special investigative unit (SIU) of a claims organization.
  • SIU special investigative unit
  • Some embodiments of a method for assessing the potential for fraud for claim data may include modifying at least one threshold value to obtain a selected volume of claims to investigate. For example, a minimum referral threshold may be modified or tuned to obtain a selected volume of referrals for further review.
  • the claims may be ranked in order of likelihood of being fraudulent. An investigator may then investigate the claims in order with the most likely fraudulent claim first.
  • a system for assessing the potential for fraud in insurance claim data may allow adjusters and investigators to track and review referrals from any computer with Internet or company Intranet access.
  • An adjuster or investigator may be allowed to display a summary list of all claims referred to that individual.
  • the list of claims may be arranged in order of highest fraud potential indicator first. In other embodiments, the list may be sorted other ways, such as by referred date, by insured, by claim number, etc.
  • users of a system may also display claims that meet certain selected criteria.
  • the selected criteria may include, but are not limited to, a range of dates, a range of fraud potential indicators, claims referred to other investigators, or open claims.
  • a system may allow a specific claim in a summary list to be reviewed in more detail by selecting the claim. A more detailed description of a selected claim may be displayed, including information regarding parties involved.
  • information that triggered the referral may be “flagged” with an icon. The icon may be selected to display a detailed description of reasons the information triggered the referral.
  • an investigator may pursue the claim further through standard investigation procedures of a claims organization.
  • the fraud potential indicator for the claim may be assessed again. If a new fraud potential indicator is higher than the previous fraud potential indicator, the claim may be reactivated (if inactive) and an investigator may be notified.
  • FIG. 9 illustrates an embodiment of system 900 for assessing the potential for fraud in insurance claims.
  • Claim data 901 may be imported or loaded 903 from an insurance company's claim data database to customer database 905 .
  • the claim data may be imported in batches (e.g., claim data may be analyzed each night).
  • claim data may be imported in real-time. For example, as a claim is being made, the data may be analyzed and a potential for fraud may be assessed and communicated to the person taking the claim in real-time.
  • claim data 901 on customer database 905 may be accessed by a computer system that includes fraud assessment 907 software components. Results of fraud assessment 907 may be loaded onto reporting database 909 . In some embodiments, report 913 of the fraud assessment results may be created 911 .
  • FIG. 10 illustrates an embodiment of system 1000 for loading claim data from an insurance company database to a customer database.
  • system 1000 may receive periodic updates (e.g., nightly) of claim data from an insurance company's claim data database.
  • Original claim data extract files 1003 may be loaded into FTP directory 1001 of system 1000 from an insurance company's claim data database.
  • File receiver 1005 may monitor FTP directory 1001 for new extract files 1007 .
  • file receiver 1005 may transfer new extract files 1007 to staging directory 1009 to minimize disk usage on the FTP server.
  • database loader 1011 may load copies of new extract files 1007 to customer database 1013 .
  • data transformer 1015 may translate claim data into a format suitable for fraud potential assessment.
  • information about requests may be displayed in a browser format.
  • a user may login to a system to access information about a request.
  • FIG. 11 illustrates an embodiment of a screen shot of claim summary window 1101 that displays claim information.
  • Claim summary window 1101 may display information regarding involved vehicles 1103 and 1107 , involved parties 1105 and 1109 , and related parties 1111 .
  • Other information that may be displayed includes, but is not limited to, claim number, claim status, claim office, loss date, loss report date, type of report filed, who reported the claim, the claim type, an accident description, a location description, a policy number, a policy state, an inception date, number of renewals on the policy, effective date of the policy, and/or an expiration date of the policy.
  • a prior screen button 1113 may be provided to allow a user to navigate quickly between claim summaries.
  • FIG. 12 illustrates an embodiment of a screen shot of watch list display window 1201 that displays data from a watch list database.
  • Watch list display window 1201 may include header row 1205 that describes various types of data relating to watch list entries in rows 1203 .
  • the types of data relating to watch list entries may include, but are not limited to author 1211 of the watch list item, DBA name 1213 , business name 1215 , and identity information 1217 .
  • a user may select “Add” push button 1207 to add a new entry to the watch list display.
  • a user may select “Update” push button 1209 to update an existing entry.
  • the watch list screen may include tabs (not shown). For example, a tab may be presented for an individual and a tab may be presented for an organization. In some embodiments, selecting a tab may present information about respective individuals or organizations.
  • FIG. 13 illustrates an embodiment of a screen shot of watch list add/update window 1301 .
  • Watch list add/update window 1301 may display text boxes 1315 for adding or updating entries in a watch list database.
  • a user may enter business information 1311 , personal information 1309 , and/or other information 1307 in watch list add/update window 1301 .
  • a user may select “Submit” push button 1303 to save the information entered.
  • a user may select “Cancel” push button 1305 to disregard changes in information entered.
  • a method may display at least two fraud potential indicators in a graphical user interface.
  • FIG. 14 illustrates an embodiment of a screen shot of manager notebook window 1401 for displaying fraud assessment results.
  • manager notebook window 1401 may include referred tab 1407 , assigned tab 1409 , and rejected tab 1411 .
  • manager notebook window 1401 may display claims 1403 with fraud potential indicators that exceed a minimum referral threshold for at least one fraud potential detection technique.
  • the assigned tab 1409 is selected, the user may be allowed to assign selected claims.
  • the claim information shown may include selection 1405 , field claim office (FCO) 1413 , claim number 1415 , loss date 1417 , score date 1419 (date claim was scored by the fraud potential detection system), PME Score 1421 (e.g., predictive modeling fraud potential indicator), ISE Score 1423 (e.g., identity search fraud potential indicator), and ORE Score 1425 (e.g., business rules fraud potential indicator).
  • FCO field claim office
  • the selection check boxes 1405 may allow multiple claims to be selected at once.
  • clicking on claim number 1415 may bring up a claim summary screen.
  • clicking on a score in PME Score 1421 column, ISE Score 1423 column, or ORE Score 1425 column may bring up a summary screen displaying why the particular score was assigned (e.g., a list of matches may be displayed if an ISE Score in ISE Score 1423 column is selected).
  • manager notebook window 1401 may display claims assigned to fraud investigators.
  • manager notebook window 1401 may display claims that have been rejected due to a high potential for fraud.
  • manager notebook window 1401 may include column 1405 with checkboxes that allow a user to select a particular claim. Manager notebook window 1401 may further display column 1413 that includes the field claim office of a claims organization with which a claim is associated.
  • a fraud potential indicator for a claim in columns 1421 , 1423 , and 1425
  • a summary screen of the related fraud assessment may be displayed. For example, when a user selects fraud potential indicator 1427 , a business rules fraud potential indicator summary screen may be displayed.
  • selecting an “assign” graphical component 1429 may navigate a user to an assignment screen that allows the user to assign selected (checked) claims to an investigator.
  • selecting a “reject” graphical component 1431 may allow a user to reject selected (checked) claims that have been referred.
  • a navigation menu 1453 may be included. The navigation menu 1453 may be used to quickly shift between different components (e.g., Home, Manager Notebook, Investigator Notebook, Watch List, Administration, Links, and References).
  • FIG. 15 illustrates an embodiment of a screen shot of a manager notebook window with the assigned tab 1409 selected.
  • the user may be allowed to see the claimant's last name 1501 , claimant's first name 1503 , field claim office 1505 , claim number 1507 , loss date 1509 , score date 1511 , number of days the claim has been assigned 1513 , investigation status 1515 (e.g., an SIU investigation), and status of the claim 1517 listed with other claim data for each claim.
  • the claims may be organized respective to the information in a column by selecting the column (e.g., by clicking a label at the top of the column). In some embodiments, multiple claim categories may be selected.
  • claims may be selected using the selection column 1527 .
  • other claim data may include the various scores assigned to the claim (e.g., PME Score 1519 , ISE Score 1521 , and BRE Score 1523 ).
  • a flag indicator may be displayed next to each score with a respective color depending on the severity of the score (e.g., a red flag for high, yellow flag for medium, and green flag for low).
  • a column may be provided to indicate whether the claim is closed.
  • a display of investigators and their corresponding regions may be displayed. The claim may be assigned to an investigator in the same region the claim occurred in.
  • claims may be assigned to a region.
  • a claim assigned to a region may be assigned to a supervisory investigator for the region to be further assigned by that supervisory investigator.
  • a claim may not be reassigned or an error message may appear when a user attempts to assign the claim to alert the user that an investigator has already started investigating the claim.
  • a filter graphical component 1525 may be selected to change the criteria of the displayed claims. For example, a particular investigator may be selected and only the claims assigned to the selected investigator may be displayed.
  • FIG. 16 illustrates an embodiment of a screen shot of a manager notebook window with rejected tab 1411 selected.
  • the user may reject a claim.
  • a Reject Reason dialog box may appear to allow the user to enter a reason why the claim was rejected.
  • a user may select from preformed reasons (e.g., Invalid BRE Score, Invalid ISE Score, Invalid PME Score, Low Score, Insufficient data, lack of evidence, manpower, no fraud, and liability).
  • pressing rejected tab 1411 may bring up a screen with rejected claims.
  • claims may be rejected manually by a claims adjuster, an investigator, or rejected automatically (e.g., if the score for the claim exceeds a threshold). Other reasons for rejecting a claim are also contemplated.
  • a rejected claim may be activated and assigned.
  • claims may be selected using the check boxes in Selection column 1633 .
  • settings may be adjusted to adjust the number of days of rejected claims shown.
  • a rejected by column may display who rejected a claim.
  • FCO 1605 , claim number 1607 , loss date 1609 , score date 1611 , PME score 1619 , ISE score 1621 , and BRE score 1623 may be shown for each claim.
  • rejected reason 1625 may be displayed for each claim.
  • the reason may be system generated or person generated.
  • the investigation status and whether the claim has been closed may also be displayed.
  • assign graphical component 1631 may be pressed to assign selected claims (e.g., using selection column 1633 to assign rejected claims).
  • Other information may also be displayed (e.g., name of the regional manager 1635 and total number of claims displayed).
  • a New tab may be used to access information on claims that have not been assigned.
  • a user may use a New tab to access information on claims to be opened or reassigned back to a supervisor.
  • an Open tab may allow access to all open claims assigned to a particular investigator.
  • a Pending tab may be used to display claims in which the investigation is complete, but the claim is still pending.
  • FIG. 17 illustrates an embodiment of a screen shot of identity search fraud potential indicator summary window 1701 .
  • Identity search fraud potential indicator summary window 1701 may display fraud potential indicators for at least one party and/or object involved in a claim. In some embodiments, the fraud potential indicator due to at least one database for at least one party and/or object may be displayed.
  • Identity search fraud potential indicator summary window 1701 may display fraud potential indicators for involved people 1707 , involved organizations 1705 , involved vehicles 1703 , etc. In column 1709 , fraud potential indicators assessed for involved parties may be displayed individually.
  • Columns 1711 may include identifying information for at least one involved person.
  • Columns 1715 may display a total fraud potential indicator from each searched database for an involved person.
  • fraud potential indicator 1713 may be the total fraud potential indicator for John Rowan based on an SIU database.
  • selecting a fraud potential indicator may navigate a user to an identity search results window, which may display matches of an involved person or object with at least one database.
  • fraud potential indicators assessed for involved organizations may be displayed individually.
  • Columns 1719 may include identifying information for involved organizations.
  • Columns 1721 may display a fraud potential indicator for each searched database for an involved organization.
  • fraud potential indicators assessed for involved vehicles may be displayed individually.
  • Columns 1725 and 1727 may include identifying information of involved vehicles.
  • Columns 1729 may display a total fraud potential indicator from each search database.
  • FIG. 18 illustrates an embodiment of a screen shot of identity search results window 1801 .
  • identity search results window 1801 may display the fraud potential indicators and associated search matches of at least one involved person and/or object associated with a fraud potential indicator.
  • identity search results window 1801 may display the fraud potential indicators and search matches associated with at least one fraud potential indicator in Table 1.
  • Summary 1805 may be displayed, for example, for the S-1 fraud potential indicator.
  • Summary 1805 may display fraud potential indicator 1817 , involved person 1815 , and matches 1809 of involved person 1815 with a company historical database.
  • Summary 1803 may be displayed, for example, for the S-2 fraud potential indicator.
  • Summary 1803 may display fraud potential indicator 1813 , involved person 1811 , and matches 1807 of involved person 1811 with an industry database (e.g., NICB).
  • industry database e.g., NICB
  • tables may be presented in the identity search engine results screen to access information on which elements matched particular databases.
  • tables may be available for SIU, NICB, Sanctioned Doctors, Commercial Mailboxes, and Watch lists.
  • an indicator on a table may be selected to expand a selection on the table. For example, a “+” sign may be selected on a table to expand the information shown for an involved person, involved organization, and involved vehicle.
  • information shown for a person may include points from matches of the person to a database, the name of the person, the address of the person (including city, state, and zip code), the number of matches for this person in the claims database, the SIU database, the NCIB database, the Commercial Mailbox database, and the watch list database.
  • information shown for an involved organization may include points for matches the organization received, the name of the organization (including a DBA name), the address of the organization (including city, state, and zip code), and matches the organization received in the SIU database, the NICB database, the Commercial Mailbox database, and the Watch list database.
  • information shown for an involved vehicle may include points the vehicle received for matches in the database, the VIN number of the vehicle, the license information for the vehicle, and the number of matches for the vehicle in the claims database, the SIU database, and the NICB database.
  • Other information, including other databases, may also be presented for other entities involved in a request.
  • FIG. 19 illustrates an embodiment of a screen shot of predictive modeling fraud potential indicator summary window 1901 .
  • Predictive modeling fraud potential indicator summary window 1901 may be displayed, for example, when a user selects a fraud potential indicator in column 1421 in FIG. 14 .
  • Predictive modeling fraud potential indicator summary window 1901 may display total predictive modeling fraud potential indicator 1905 from a predictive modeling engine. In some embodiments, window 1901 may display factors 1903 that were considered in determining total fraud potential indicator 1905 .
  • FIG. 20 illustrates an embodiment of a screen shot of business rules fraud potential indicator window 2001 .
  • the screen shot may be displayed when the BRE score is selected in the claim summary screen.
  • business rules fraud potential indicator summary window 2001 may display at least one individual business rule fraud potential indicator used by the business rules engine to determine the total business rule fraud potential indicator.
  • Column 2007 may include the fraud potential indicators for individual business rules.
  • Column 2009 may include a description of business rules.
  • Total business rules fraud potential indicator 2005 may include the overall fraud potential indicator determined by the business rules engine.
  • selecting an individual fraud potential indicator in column 2007 and/or a business rule description in column 2009 may display a business rule detail window.
  • accident description dialog box 2003 may be displayed in window 2001 .
  • FIG. 21 illustrates an embodiment of a screen shot of business rules detail window 2101 .
  • business rules detail window 2101 may be displayed, for example, by selecting an individual fraud potential indicator in column 2007 and/or a business rule description in column 2009 in window 2001 shown in FIG. 20 .
  • Business rules detail window 2101 may display the individual business rule fraud potential indicators for at least one business rule.
  • Rows 2105 may each pertain to at least one involved person or object involved in the claim.
  • Column 2111 may include a description of loss sustained by an involved person or object.
  • Columns 2109 and 2107 may include identifying information of an involved person or object and the fraud potential indicator assessed due to the loss.
  • Business rules fraud potential indicator 2103 for the business rule may be displayed in business rules detail window 2101 .
  • FIG. 22 shows a flowchart of an embodiment of a method for displaying summary information related to the various engines.
  • at least two fraud potential indicators for an insurance claim may be assessed using at least two of an identity search engine, a predictive model engine, and a business rule engine.
  • information about an insurance claim may be displayed including identifying information for the claim and the at least two fraud potential indicators for the insurance claim.
  • engine summary information related to at least one engine used to assign at least one of the at least two fraud potential indicators may be displayed.
  • an involved people summary screen may show a summary of involved people in a claim.
  • an involved people summary screen may be presented when a user selects an individual score on an identity search engine results screen.
  • tabs may be displayed for each involved person and accessing a tab may bring up information regarding how the involved person matched information related to the tab. For example, tabs may be presented for the SIU, NICB, commercial mailbox, watch list, and historical claims databases.
  • a name of a person associated with the selected individual score may be displayed as an anchor record of a tab.
  • selecting the SIU tab may present matches for the selected individual against the SIU database (e.g., the percentage of similarity between the matches, the claim number in the SIU database matched, the name, address, and phone numbers of the person matched). Other information may also be displayed depending on which database tab is selected (e.g., the NICB number for the matching NICB claim, the store name of the holder of the commercial mailbox, the identifier in the Watch list, and the claim number for the claim in the claims database matched).
  • summary screens may be shown for involved organizations, vehicles, and other entities.
  • FIG. 23 illustrates a flowchart of an embodiment of a method for displaying summary information related to involved entities.
  • at least two fraud potential indicators for an insurance claim may be assessed using at least two of an identity search engine, a predictive model engine, and a business rule engine.
  • information about an insurance claim may be displayed including identifying information for the claim and the at least two fraud potential indicators for the insurance claim.
  • summary information related to an involved entity related to at least one assigned fraud potential indicator may be displayed. For example, an involved organization summary screen may be displayed if the score for the involved organization is selected in the identity search engine summary screen.
  • tabs may be presented in the involved organization summary screen for different databases searched. For example, tabs may be available for the sanctioned doctors database, the NICB database, and the commercial mailbox database.
  • information shown if a tab is selected may include the score for the percentage of similarity of the match, the name, address, and phone number of the match, and other information dependent on which database has been selected (e.g., identifier for the sanctioned doctor, NICB number, and store name for the commercial mail box).
  • involved vehicle summary screens may be displayed by selecting the individual score for the involved vehicle in the identity search engine summary screen.
  • the involved vehicle summary screen may include tabs for various databases searched (e.g, the SIU database, the NICB database, the claims database, and the watch list database).
  • information about the match in the various databases e.g., percentage of similarity of match, the VIN, the year, the make, the model, the license number, and the state may be displayed
  • database specific information e.g., SIU claim number, NICB reference number, the claim number, and the watch list identifier.
  • watch list summary screens may be provided for entities being tracked by a watch list.
  • users may keep track of where individuals and organizations are showing up in claims.
  • watch list individual summary and watch list organization summary screens may be used.
  • support screens may also be used to show data about the system.
  • a support data screen may be used to modify data in an administrative file.
  • a user setup screen may be used to maintain and modify user information for users of the system (e.g., user's office, email address, and user group).
  • a company setup screen may be used to maintain information about a company using the system.
  • FIG. 24 illustrates a flowchart of an embodiment of a method for configuring administrative information for a fraud potential detection system.
  • at 2401 at least two fraud potential indicators for an insurance claim may be assessed using at least two of an identity search engine, a predictive model engine, and a business rule engine.
  • administrative information for a system may assess at least two fraud potential indicators for an insurance claim.
  • country information e.g., a country code and country name
  • state information e.g., state abbreviations, name of state, region associated with the state, and country the state is a part of
  • region information e.g., region identifier, region name, and additional region information
  • information about a company e.g., company name, company address, additional addresses, company city, company state, company zip code, and company country
  • office information e.g., office name, office address, office city, office state, office zip code, office country, office email address, and office region
  • office information e.g., office name, office address, office city, office state, office zip code, office country, office email address, and office region
  • information for investigation status e.g., a status code and respective investigation status description
  • closure reasons e.g., closure identifier and respective closure reason
  • reason rejected e.g., a reason identifier and respective reason the claim was rejected
  • codes and identifiers used by the system For example, after a closure identifier is set-up, a user may select a code for a closure reason instead of typing out a reason for each claim.
  • Other information may also be updated, deleted, and/or maintained.
  • information about a role description e.g., a role identifier and a description for the role identifier
  • information about a user group e.g., a user group identifier and respective user group information
  • information for a user set-up e.g., user first name, user last name, user identifier, user phone number, user email address, user region, user office, number of days of claims displayed for the user, and user group associated with the user.
  • the information may be accessed using a navigation bar with directory trees for the information titles.
  • “+” signs next to a respective information title may be pressed to access corresponding directory information.
  • Other selection methods may also be used.
  • FIG. 25 illustrates a flowchart of an embodiment of a method for displaying assessment results.
  • at least one fraud potential indicator for a plurality of insurance claims may be assessed using at least one fraud potential detection technique.
  • a minimum referral fraud potential indicator may be defined such that a desired quantity of requests are referred for further investigation.
  • a fraud potential indicator may be displayed in a graphical user interface.
  • at least two fraud potential indicators may be assessed for a request and displayed in a graphical user interface.
  • a ranking may be assigned to at least one request relative to a probability of fraud.
  • multiple requests may be listed according to their ranking.
  • an investigator may investigate the requests in order of ranking (e.g., a request with a high probability of fraud may be assigned a higher ranking, and thus be considered before, a request with a lower probability of fraud).
  • FIG. 26 illustrates a flowchart of an embodiment of a method for displaying information about requests using tabs.
  • at least two fraud potential indicators for an insurance claim may be assessed using at least two of an identity search engine, a predictive model engine, and a business rule engine.
  • information about an insurance claim may be displayed including identifying information for the claim and the at least two fraud potential indicators for the insurance claim.
  • a tab may be displayed. In some embodiments, selecting the tab may display information related to the claims associated with a reference on the tab selected (e.g., a tab may have the name of a searched database and link a user to matches detected between an insurance claim and the database).

Abstract

Methods and systems are provided for assessing the potential for fraud of an insurance claim. In some embodiments, request data may be provided to a computer system. In some embodiments, at least one fraud potential indicator may be assessed to the request data from at least one comparison of at least one request data element to at least one fraud model. In some embodiments, a fraud potential indicator may be an estimate of the potential for fraud in an insurance claim. In some embodiments, at least one fraud potential indicator for request data may be assessed based on at least one comparison of at least one request data element to additional insurance data. Some embodiments may include assessing at least one fraud potential indicator for request data based on at least one fraud potential indicator.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention generally relates to detecting the potential for fraud. In particular, embodiments relate to systems and methods of assessing fraud potential in multiple industries.
  • 2. Description of the Related Art
  • While fraud affects many companies, it may be difficult to detect. For example, insurance fraud may be difficult to detect because insurance criminals may not be easily identifiable. Insurance criminals may range from organized fraud rings to dishonest individuals. Other types of fraud may include mortgage loan fraud, banking fraud, and health care fraud.
  • Furthermore, property and casualty insurers typically rely on adjustors and special investigation units (SIUs) within their companies to investigate potentially fraudulent requests (e.g., insurance claims, bank checks, loan applications, and health care billing—i.e., “requests” for financial transactions from customers of a financial institution). Insurance companies, banks, and mortgage lenders, however, may have a limited number of adjusters and investigators. Therefore, it may not be feasible to manually investigate every request filed for fraudulent activity.
  • Some methods for detecting the potential for fraud have focused on identifying a subset of requests for investigation that have a high potential for fraud. Such methods may make use of insurance industry databases that have been developed to assist in detecting the potential for fraud. For example, the National Insurance Crime Bureau (NICB) of Palos Hills, Ill. compiles a database of insurance claim data from member property and casualty insurance companies that insurance companies can access to determine if one of their current claims is potentially fraudulent. The NICB database includes suspicious requests that have been submitted to all participating insurance companies. In addition, ISO of Jersey City, N.J. provides a product, ISO requestSearch™, that includes databases for insurance claim data. There is generally incentive to identify only requests with the greatest potential of fraud to reduce the “false-positive” rate. Such a system may reduce time spent on human analysis while also reducing the costs to the company of fraudulent requests.
  • SUMMARY OF THE INVENTION
  • In various embodiments, a potential for fraud may be assessed (e.g., in insurance claims, mortgage loans, banking transactions, and health care billing) using a computer system to which data is provided. While the embodiments described below describe assessing a probability for fraud in insurance claims, it is to be understood that these embodiments may also be adjusted to detect the potential of fraud in requests in other industries such as, but not limited to, banking, mortgage loans, and health care. In some embodiments, the potential for fraud may be assessed using multiple fraud potential detection techniques including, but not limited to, identity searches, identity validation, model comparisons, and business rule evaluations.
  • In some embodiments, a relative probability of potential for fraud in a claim may be determined and a respective fraud potential indicator assigned, using a fraud potential detection technique. For example, at least one fraud potential indicator may be assessed based on at least one comparison of at least one request data element (e.g., a data element in a request to the company) to data in a database or watch list for matches and near matches. In some embodiments, at least one first fraud potential indicator may be assessed from at least one comparison of at least one request data element to at least one fraud model. In some embodiments, various request data elements may be verified to confirm the probable existence of the data (e.g., confirming that a person listed on a claim exists and actually lives at a listed address). In various embodiments, a fraud model may be created using historical fraud patterns in claims that have been proven fraudulent. Other fraud models are also contemplated. In some embodiments, at least one fraud potential indicator may be assessed using business rules designed to detect potentially fraudulent requests.
  • In various embodiments, two or more fraud potential detection techniques may be used together (e.g., using a combined or averaged score from each technique) to give an indication of the potential for fraud in a request. In some embodiments, if the score is greater than a predetermined threshold, action may be taken on the request to further investigate the potential for fraud. Some embodiments may include modifying the threshold to obtain a desired quantity of request referrals for further review.
  • In some embodiments, a method of assessing the potential for fraud in a request may include assessing at least one first fraud potential indicator for request data from at least one comparison of at least one request data element to other data. For example, a database of suspicious names, places, cars, etc. may be maintained and compared against data from current requests. In some embodiments, a “watch-list” of data elements to look for may also be maintained (e.g., by an adjustor) and compared to current request data. In some embodiments, matches and near matches may be used to assign a “score” or fraud potential indicator for a request. In some embodiments, types of matches, frequency of matches, and frequency of near-matches may indicate a higher or lower potential of fraud. In some embodiments, the types and frequency of matches may be weighted to assign a score relative to the potential for fraud in the request.
  • In various embodiments, the potential for fraud in a request may be assessed using an identity verification engine to verify the identification of various individuals and businesses involved in the request. For example, the insured, the claimant, doctors, lawyers, and/or other individuals may be verified by using sources such as, but not limited to, public records and bills (e.g., phone bills) to verify that the information provided for each of these individuals and businesses in the request is consistent with an actual individual or business.
  • In various embodiments, request data may be compared to models created based on past historical fraud patterns. In some embodiments, predictive modeling, analytical modeling, and data mining techniques may be used to determine potential for fraud in a request based on how closely the request resembles the model.
  • In various embodiments, business rules may be used to detect issues related to the potential for fraud in a claim such as, but not limited to, injury types, date of loss compared to date of report, policy expiration compared to the date of the report, existence of a police report, and the number of vehicles involved. In some embodiments, the business rules may be modified to accommodate for regional differences and changing trends in fraud.
  • In various embodiments, other components may be added. For example, an administrative component may be added to allow a user to load information, values, thresholds, and/or other data for using the system. In some embodiments, the system may include links to relevant websites (e.g., with investigative tools). In some embodiments, references may be included for use by people such as, but not limited to, adjustors and investigators. For example, a link to the state of New York Insurance Manual may be included. Other components are also contemplated.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A better understanding of the present invention may be obtained when the following detailed description of preferred embodiments is considered in conjunction with the following drawings, in which:
  • FIG. 1 illustrates a network diagram of a wide area network suitable for implementing various embodiments.
  • FIG. 2 illustrates a computer system suitable for implementing various embodiments.
  • FIG. 3 illustrates a flowchart of a method for assessing the potential for fraud in a request, according to an embodiment.
  • FIG. 4 a illustrates a flowchart of a method for detecting a potential for fraud in a request using an identity search, according to an embodiment.
  • FIG. 4 b illustrates a flowchart of a method for detecting a potential for fraud in a request using an identity verification, according to an embodiment
  • FIG. 5 illustrates a flowchart of a method for detecting a potential for fraud in a request using predictive modeling, according to an embodiment.
  • FIG. 6 illustrates a flowchart of a method for detecting a potential for fraud in a request using business rules, according to an embodiment.
  • FIG. 7 illustrates a system using an identity search engine, a rules engine, and a predictive modeling engine, according to an embodiment.
  • FIG. 8 illustrates a flowchart for assigning and referring requests, according to an embodiment.
  • FIG. 9 illustrates a flowchart of a method for using request data to assess the potential for fraud in a request and report the potential, according to an embodiment.
  • FIG. 10 illustrates a flowchart of a method for loading request data into a database accessible by a fraud assessment system, according to an embodiment.
  • FIG. 11 illustrates a screenshot of an insurance claim summary, according to an embodiment.
  • FIG. 12 illustrates a screenshot of a watch list, according to an embodiment.
  • FIG. 13 illustrates a screenshot of a watch list update, according to an embodiment.
  • FIG. 14 illustrates a screenshot of a manager notebook with the referred tab selected, according to an embodiment.
  • FIG. 15 illustrates a screenshot of a manager notebook with the assigned tab selected, according to an embodiment.
  • FIG. 16 illustrates a screenshot of a manager notebook with the rejected tab selected, according to an embodiment.
  • FIG. 17 illustrates a screenshot of an identity search engine summary, according to an embodiment.
  • FIG. 18 illustrates a screenshot of identity search engine results, according to an embodiment.
  • FIG. 19 illustrates a screenshot of predictive modeling engine summary results, according to an embodiment.
  • FIG. 20 illustrates a screenshot of a business rules summary, according to an embodiment.
  • FIG. 21 illustrates a screenshot of business rules details, according to an embodiment.
  • FIG. 22 shows a flowchart of a method for displaying summary information related to the various engines, according to an embodiment.
  • FIG. 23 illustrates a flowchart of a method for displaying summary information related to involved entities, according to an embodiment.
  • FIG. 24 illustrates a flowchart of a method for configuring administrative information for a fraud potential detection system, according to an embodiment.
  • FIG. 25 illustrates a flowchart of a method for displaying assessment results, according to an embodiment.
  • FIG. 26 illustrates a flowchart of a method for displaying information about requests using tabs, according to an embodiment.
  • While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended requests.
  • DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS
  • FIG. 1 illustrates an embodiment of a wide area network (“WAN”). WAN 102 may be a network that spans a relatively large geographical area. The Internet is an example of WAN 102. WAN 102 typically includes a plurality of computer systems that may be interconnected through one or more networks. Although one particular configuration is shown in FIG. 1, WAN 102 may include a variety of heterogeneous computer systems and networks that may be interconnected in a variety of ways and that may run a variety of software applications.
  • One or more local area networks (“LANs”) 104 may be coupled to WAN 102. LAN 104 may be a network that spans a relatively small area. Typically, LAN 104 may be confined to a single building or group of buildings. Each node (i.e., individual computer system or device) on LAN 104 may have its own CPU with which it may execute programs, and each node may also be able to access data and devices anywhere on LAN 104. LAN 104, thus, may allow many users to share devices (e.g., printers) and data stored on file servers. LAN 104 may be characterized by a variety of types of topology (i.e., the geometric arrangement of devices on the network), of protocols (i.e., the rules and encoding specifications for sending data, and whether the network uses a peer-to-peer or client/server architecture), and of media (e.g., twisted-pair wire, coaxial cables, fiber optic cables, and/or radio waves).
  • Each LAN 104 may include a plurality of interconnected computer systems and optionally one or more other devices such as one or more workstations 110 a, one or more personal computers 112 a, one or more laptop or notebook computer systems 114, one or more server computer systems 116, and one or more network printers 118. As illustrated in FIG. 1, an example LAN 104 may include one of each computer systems 110 a, 112 a, 114, and 116, and one printer 118. LAN 104 may be coupled to other computer systems and/or other devices and/or other LANs 104 through WAN 102.
  • One or more mainframe computer systems 120 may be coupled to WAN 102. As shown, mainframe 120 may be coupled to a storage device or file server 124 and mainframe terminals 122 a, 122 b, and 122 c. Mainframe terminals 122 a, 122 b, and 122 c may access data stored in the storage device or file server 124 coupled to or included in mainframe computer system 120.
  • WAN 102 may also include computer systems connected to WAN 102 individually and not through LAN 104 for purposes of example, workstation 110 b and personal computer 112 b. For example, WAN 102 may include computer systems that may be geographically remote and connected to each other through the Internet.
  • FIG. 2 illustrates an embodiment of computer system 250 that may be suitable for implementing various embodiments of a system and method for assessing the potential for fraud in requests (e.g., insurance claims, bank checks, loan requests, and health care bills). Each computer system 250 typically includes components such as CPU 252 with an associated memory medium such as floppy disks 260. The memory medium may store program instructions for computer programs. The program instructions may be executable by CPU 252. Computer system 250 may further include a display device such as monitor 254, an alphanumeric input device such as keyboard 256, and a directional input device such as mouse 258. Computer system 250 may be operable to execute the computer programs to implement computer-implemented systems and methods for assessing the potential for fraud in insurance claims.
  • Computer system 250 may include a memory medium on which computer programs according to various embodiments may be stored. The term “memory medium” is intended to include an installation medium, e.g., a CD-ROM or floppy disks 260, a computer system memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a non-volatile memory such as a magnetic media, e.g., a hard drive or optical storage. The memory medium may also include other types of memory or combinations thereof. In addition, the memory medium may be located in a first computer, which executes the programs or may be located in a second different computer, which connects to the first computer over a network. In the latter instance, the second computer may provide the program instructions to the first computer for execution. Computer system 250 may take various forms such as a personal computer system, mainframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (“PDA”), television system or other device. In general, the term “computer system” may refer to any device having a processor that executes instructions from a memory medium.
  • The memory medium may store a software program or programs operable to implement a method for assessing the potential for fraud in insurance claims. The software program(s) may be implemented in various ways, including, but not limited to, procedure-based techniques, component-based techniques, and/or object-oriented techniques, among others. For example, the software programs may be implemented using ActiveX controls, C++ objects, JavaBeans, Microsoft Foundation Classes (“MFC”), browser-based applications (e.g., Java applets), traditional programs, or other technologies or methodologies, as desired. A CPU such as host CPU 252 executing code and data from the memory medium may include a means for creating and executing the software program or programs according to the embodiments described herein.
  • Various embodiments may also include receiving or storing instructions and/or data implemented in accordance with the foregoing description upon a carrier medium. Suitable carrier media may include storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, as well as signals such as electrical, electromagnetic, or digital signals, may be conveyed via a communication medium such as a network and/or a wireless link.
  • Various embodiments include assessing the potential for fraud in requests. While various embodiments for assessing the potential for fraud are discussed below with respect to insurance claims, it is to be understood that these embodiments may also be applied to detecting other kinds of fraud including, but not limited to, check fraud, mortgage or other loan application fraud, and health billing fraud. As used herein a “claim” may refer to a demand for compensation for a loss, such as, but not limited to, medical treatment due to bodily injury, death of an insured, property damage, etc. In addition, the systems and methods disclosed herein may be used to detect the potential for various kinds of fraud in insurance claims such as, but not limited to, health, property and casualty, and/or life.
  • In various embodiments, request data may include information related to any parties related to the request. For example, parties related to the request may include, but are not limited to, claimants, witnesses, insureds, medical providers, and/or individuals and/or businesses providing repair services. The term “request data” is used in the following descriptions to refer to data related to requests (e.g., checks, insurance claims, mortgage or other loan applications, and health care billing). In some embodiments, request data related to an insurance claim may include, but is not limited to, date of the claim and/or date of loss, inception date of a policy, expiration date of a policy, addresses of parties related to the claim, and details of the loss or the accident leading to the loss. Details of an accident may include, but are not limited to, the type of accident (e.g., a rear-end collision), the number of parties involved, type and degree of property damage, type and degree of injuries, trajectory of vehicles in a vehicle accident, and/or location of the accident. In some embodiments, a characteristic of an accident may also include a set of two or more individual characteristics. For example, a set of characteristics may describe a type of accident that is commonly staged to perpetrate insurance fraud.
  • In some embodiments, request data may include check data. For example, check data may include information on a drawer (person who writes the check), a payee (the person to whom the check is payable to), a date, an account number, a routing number, and information on involved banks including, but not limited to, a drawee bank and a depository bank. In some embodiments, request data may include loan application data. For example, loan application data may include, but is not limited to, information about the loan applicant, loan applicant's credit history, other debts of the loan applicant, income level of the loan applicant, criminal history of the loan applicant, social security number, address, other obligations (e.g., child support), information on the item to be purchased with the loan money (e.g., title search), and information about other parties involved in the loan. In some embodiments, request data may include health care billing data (e.g., name of person receiving care, name of the doctor, type of treatment, and extent of stay in a hospital). Other types of data may also be analyzed as request data.
  • In various embodiments, the potential for fraud may be detected using multiple fraud potential detection techniques including, but not limited to, identity searches, identity verifications, model comparisons, and business rule evaluations. In some embodiments, an overall relative level of potential for fraud (i.e., overall fraud potential indicator) may be assigned using multiple fraud potential indicators from one or more fraud potential detection techniques. For example, in some embodiments, at least one fraud potential indicator may be assessed based on at least one comparison of at least one request data element to data in a database or watch list for matches and near matches. In some embodiments, a fraud potential indicator may be assessed from at least one comparison of at least one request data element to at least one fraud model. In some embodiments, a fraud potential indicator may be assessed from attempting to verify a request data element. In various embodiments, a fraud potential indicator may be assessed by comparing request data elements to a fraud model created using historical fraud patterns in past requests proven fraudulent. Other fraud models are also contemplated. In some embodiments, at least one fraud potential indicator may be assessed using business rules designed to detect the potential for fraud in a request.
  • In various embodiments, two or more fraud potential detection techniques may be used together (e.g., using a combined or averaged score from each technique) to give an indication of whether fraud may exist in a request. In some embodiments, if the score is greater than a predetermined threshold, action may be taken on the request to further investigate the potential of fraud. Some embodiments may include modifying the threshold to obtain a desired quantity of request referrals for further review. For example, if the threshold is set too low, a large number of requests may be referred for review including requests with a low potential for fraud.
  • FIG. 3 illustrates a flowchart of an embodiment of a process for assessing the potential for fraud in requests. At 301, request data for a request may be provided (e.g., imported from an insurance claims processing system of an insurance carrier) to a computer system for assessing the potential for fraud in the request. In some embodiments, the request data may include first notice of loss (FNOL) data taken at the time of loss from the claimant and other policy data, information on a check to be cashed, or information about a requested loan. Other request data is also contemplated. Request data may be extensive and may include, but is not limited to, information about an insured, a claimant, and other involved parties. Information about other involved parties may include information about involved businesses, doctors, and lawyers. Other request data may include the date of the request, the type of loss, how many people were involved, and information about vehicles or property involved. Other types of request data are also contemplated.
  • In certain embodiments, request data (e.g., claim data, check data, and loan data) on a processing system (e.g., insurance claim processing system, check processing system, and loan processing system) may be updated as new information is obtained. In some embodiments, the request data may be transmitted on a periodic basis (e.g., every 24 hours) to the computer system for assessing fraud potential. In some embodiments, a computer system may both collect and process data without having to transmit the data to another computer system. In some embodiments, the data may be analyzed in real-time (e.g., as the data is being entered or processed, for example, by an adjuster).
  • In various embodiments, a relevant profile (e.g., claim data profile, check data profile, and loan data profile) may be created. For example, a request data profile may be created by extracting information relevant to assessing the potential for fraud in a request to form a condensed version of the request data. In some embodiments, the request data may not be extracted (i.e., a request data profile may not be created), but, instead, the request data may be used as needed by the computer system.
  • At 303, a fraud potential detection technique may be used to detect the potential for fraud in a request (e.g., an insurance claim). For example, search engines, model comparisons, and business rules may be used to detect the potential for fraud in a request. In some embodiments, an assessment of fraud potential (i.e., a fraud potential indicator) in a request may be represented by a numerical indicator (e.g., a “score”), a ranking (e.g., using letters), or a pass/fail indicator. Other assessment representations are also contemplated. The fraud potential indicator may indicate a relative potential for fraud. For example, a fraud potential indicator may be on a scale of one to ten with one indicating a very low potential for fraud and ten indicating a very high potential for fraud.
  • In various embodiments, fraud potential detection techniques may include identity searches, identity verifications, predictive modeling, and business rules. Other techniques are also contemplated. In some embodiments, the identity searches may compare request data to internal and external databases (e.g., an internal “watch list” or a National Insurance Crime Bureau (NICB) database) to find matches between the databases and the request data. In certain embodiments, request data may be verified. In some embodiments, predictive modeling may compare request data to historical fraudulent patterns (e.g., request data from past proven fraudulent requests). In some embodiments, the identity searches may compare check data and loan data to internal and external databases to find matches that may indicate a potential for fraud. In various embodiments, business rules may be used to find issues in the request data that may indicate the potential for fraud. In some embodiments, identity searches, identity verification, predictive modeling, and business rules may be used to detect an absence of potential for fraud (e.g., request data that indicates the request probably is not fraudulent). Various embodiments may include one or more of the fraud potential detection techniques to assign one or more fraud potential indicators. In embodiments with multiple fraud potential indicators, the fraud potential indicators may be combined (e.g., by adding and/or weighting) to provide a single fraud potential indicator for a request. In some embodiments, the fraud potential indicators may be used separately.
  • At 305, a request's fraud potential indicators may be analyzed. In some embodiments, the fraud potential indicators may be manually analyzed (e.g., by an adjuster) to determine if further investigation is needed. In some embodiments, the fraud potential indicators may be compared to a threshold. In various embodiments, if there are multiple fraud potential indicators for a request, the fraud potential indicators may be combined and the combined fraud potential indicator may be compared to a threshold to determine if further action is needed. In some embodiments, multiple requests may be ranked in order, according to their fraud potential indicators (e.g., highest probable fraudulent request may be listed first). In certain embodiments, only requests with fraud potential indicators above a threshold may be ranked.
  • At 307, a determination may be made whether to take additional investigative action on a request. At 309, if a determination is made to take further investigative action on the request, the request may be further investigated. In some embodiments, the requests may be assigned to an adjuster, investigator, and/or Special Investigative Unit (SIU) based on the level of potential for fraud in the request (e.g., based on the request's fraud potential indicators). For example, a request with relatively low fraud potential indicators may be assigned to an adjuster, while a request with fraud potential indicators above a certain threshold may be assigned to investigators. In some embodiments, if the fraud potential indicators are above a certain threshold, the request may be referred to an SIU.
  • At 311, if a determination is made not to take further investigative action on the request, the request may be processed normally. In some embodiments, if fraud potential indicators are low enough (e.g., negative), payment of the request may be expedited. In some embodiments, as additional request data becomes available, the request may be reassessed. In addition, requests may be reassessed for other reasons (e.g., if new predictive models are developed).
  • FIG. 4 a illustrates a flowchart of an embodiment of a method for assessing potential for fraud in a request using an identity engine. At 401, the request data may be compared to various databases. In various embodiments, request data may be searched for people, addresses, vehicles, businesses, and other data elements that may indicate a potential for fraud in the request. In some embodiments, people, vehicles, and businesses involved in the request may be compared to people, vehicles, and businesses listed in databases, such as, but not limited to, the National Insurance Crime Bureau (NICB) database, an insurance companies historical claims database, a commercial mailbox database, a “watch list” database, and an SIU database for a match. For example, people involved in the request (e.g., claimant, insured, drawer, payee, and loan applicant) may be searched by their first name, last name, social security number, address, city, home phone, and work phone. In some embodiments, vehicles may be searched by vehicle type, VIN number, and license tag number. For example, if a vehicle involved in the current request was also involved in a past claim that was proven fraudulent and therefore the vehicle was listed in the NICB database, the current request may be assigned a high fraud potential indicator. Other external databases may also be searched. In some embodiments, a high frequency of previous requests (e.g., insurance claims), involving the same person or vehicle may indicate a higher potential for fraud. In some embodiments, businesses that may not be suspicious even though they appear in multiple claims (e.g., a rental car company) may not be searched. A commercial mailbox database may have addresses that belong to commercial mail receiving agencies (CMRAs) (organizations that rent out commercial mailboxes). The use of a commercial mailbox may be indicate that a person is trying to disguise themselves for fraud purposes. Various levels of fraud potential indicators may be assigned depending on whether the commercial mailbox is used by a person or a business involved in the request.
  • In some embodiments, a “watch list” database (i.e., a custom database) may be established to find requests with certain people, vehicles, businesses, and other data elements that indicate the possibility of fraud. In some embodiments, an organization may be added to the watch list. Information about the organization on the watch list may include, but is not limited to, the business name, the DBA name, the address, the phone numbers, the role of the organization respective to the claim, and the tax identification number of the organization. Other information that may be included on the watch list may include the source of the information for an entry on the watch list, the author of the entry on the watch list, the author's region, and other comments.
  • In various embodiments, the watch list may be set up by an adjustor or SIU. Other entities may also create a watch list. If a match is detected, the author of the particular watch list involved may be notified and a corresponding fraud potential indicator may be assigned.
  • In various embodiments, other types of databases may also be searched. For example, a sanctioned medical providers database may be searched for businesses that have been disciplined for questionable business practices. Other databases maintained by industry groups and commercial entities may also be searched. In some embodiments, industry databases may be searched. For example, an “industry database” may refer to a centralized database that includes request data contributed by more than one insurance company to assist other insurance companies in detecting fraud.
  • In some embodiments, databases may be searched that do not indicate a possibility of fraud but instead are searched for other reasons such as, but not limited to, compliance with state and federal laws. For example, the Office of Foreign Assets Control (OFAC) database may be searched for request data elements to indicate the involvement of possible terrorists (in compliance with the requirements set forth in the Patriot Act).
  • At 403, a fraud potential indicator may be assigned to the request based on matches between the request data and entries in at least one of the databases. In some embodiments, the identity fraud potential indicator may be weighted based on the frequency of matches, frequency of near matches, type of match (e.g., type of database matched), number of databases matched, and other factors. For example, a higher fraud potential indicator may be assigned to a request in which the name of the claimant matches a listed name in the NICB's database and the insurance company's internal database than if a claimant had only matched an entry on the insurance company's internal database. In some embodiments, the request may be given a higher fraud potential indicator if multiple request data elements match entries in one or more searched databases. For example, a request may be given a higher fraud potential indicator if the name of the claimant and the claimant's listed physician match names on the NICB's database than if only the claimant's name was found in the NICB's database. In some embodiments, a request may receive a higher fraud potential indicator if a request element matches a data element in a database than if the request element was a near-match to a data element in the database. In addition, near matches may be weighted differently depending on the degree of match (e.g., the number of letters that match compared to the number of letters that do not match). In some embodiments, the fraud potential indicator may be based on other expert knowledge of insurance claims and/or fraud assessment. In some embodiments, a fraud potential indicator may be assigned to each request data element that matches and a total identity fraud potential indicator may be assigned based on the fraud potential indicators for the various request data elements (e.g., by adding or averaging the fraud potential indicators for multiple request data elements).
  • In various embodiments, if a person appears in another claim in the insurance company's historical claims database, multiple elements of the claims may logically match and therefore be weighted as only one match for assigning an identity fraud potential indicator. For example, if the same person appears in two claims, the person's name, address, and phone number may all match, however, it may be misleading to indicate multiple matches with the searched database. Therefore, logical matches may be accounted for and the identity fraud potential indicator may be appropriately adjusted.
    TABLE 1
    Search rules for Identity Searching.
    Search
    Rule Matching Item in
    Identifier Request Data Database
    S-1 Involved person Company historical requests
    S-2 Involved person Industry database
    S-3 Involved person SIU
    S-4 Involved vehicle(s) SIU
    S-5 Involved vehicle(s) Industry database
    S-6 Address of involved business Commercial mailbox
    S-7 Involved business Industry database
    S-8 Address of involved person Commercial mailbox
    S-9 Address of involved business Watch List
    S-10 Vehicle Company historical requests
    S-11 Involved business Sanctioned medical
    providers
    S-12 Address of involved person Watch List
  • In various embodiments, search rules may be created and used with requests when performing searches. For example, Table 1 provides a summary of an embodiment of search rules that may be used to search request data elements. Different search rules may also be used. The “Matching Item in Request Data” refers to a request data element that may match or approximately match a database of insurance data. An “Involved Person” is a particular person related to the request, for example, a claimant. A “Vehicle” refers to a particular vehicle related to a request, for example, a vehicle involved in an accident. An “Involved Business” refers to a particular business related to a request, for example, a medical provider or vehicle repair shop. An involved vehicle or business may also be referred to as an “involved object.” In some embodiments, the fraud potential indicator assessed for a match of a request data element to a database may be different for an involved party, an involved business, or an involved object.
  • In some embodiments, search rules may be provided to search data from a check. For example, the drawer may be compared to people listed in a hot check database. Other check data may also be searched for suspicious circumstances. In some embodiments, data related to a loan may be searched. For example, the loan applicant's name may be searched for in established databases of past fraudulent loan applications. Other data related to a loan may also be searched for indications of the possibility of fraud.
  • In some embodiments, for a given search rule a formula may be used to determine the fraud potential indicator for a request. A formula may be based on several factors, such as, but not limited to, the number of matches of request data to a database. Additional factors may include a loss type, ranking, point weight, and/or adjustment numbers. A loss type may take into account the fact that certain types of requests tend to be associated with a higher rate of fraud. Request types that are unusual or are difficult to verify are examples of such requests. For example, stolen vehicle requests may tend to have a higher incidence of fraud than certain types of collisions. In some embodiments, the fraud potential indicator for a rule may be calculated by multiplying the number of matches by a ranking, point weight, an adjustment number and/or a numerical value associated with a loss type. For example, a fraud potential indicator may be assigned based on a formula such as, but not limited to:
    Fraud potential indicator=Ranking*Point Weight*Loss Type Value*number of matches found in the database*adjustment number
  • Other formulas may also be used. In some embodiments, fraud potential indicators may be scored differently depending on whether the person, vehicle, or business matched a database. In various embodiments, the following corresponding formulas may be used. Other formulas are also contemplated.
    TABLE 2
    Search Rule Corresponding Formulas.
    Search
    Rule
    Identi-
    fier Formula
    S-1 4 * 2.5 * loss type value * No. of matches in database * .15
    S-2 5 * 13.5 * loss type value * No. of matches in NICB * .15
    S-3 5 * 11.5 * loss type value * No. of matches in SIU * .15
    S-4 5 * 12.5 * loss type value * No. of matches in SIU * .15
    S-5 5 * 13.5 * loss type value * No. of matches in NICB * .15
    S-6 4 * 14 * loss type value * No. of matches in database * .15
    S-7 4 * 13.5 * loss type value * No. of matches in NICB * .15
    S-8 5 * 13.5 * loss type value * No. of matches in database * .15
    S-9 5 * 13.5 * loss type value * No. of matches in Watch List * .15
    S-10 2 * 3 * loss type value * No. of matches in database * .15
    S-11 5 * 13.5 * loss type value * No. of matches in database * .15
    S-12 5 * 13.5 * loss type value * No. of matches in Watch List * .15
  • In some embodiments, a search for an involved party in a database may involve a search for the involved parties' names, addresses, home phone numbers, work phone numbers, etc. In some embodiments, a search for an involved vehicle may include search for a Vehicle Identification Number (VIN#) and/or a license tag number. In other embodiments, a search for an involved business may include a search for a business name, a “doing business as” name, an address, business phone number, etc.
  • Search rules S-1 and S-10 (from Table 1) both involve comparisons of request data to a company historical requests database. In some embodiments, the frequency of previous requests by an involved person or a particular vehicle may be indicative of fraud, even if the prior requests were not suspicious.
  • Search rules S-2, S-5, and S-7 (from Table 1) involve comparisons of request data to an industry database such as the NICB database. A new request may be suspicious if it involves an individual or business that has been investigated previously by an industry organization such as the NICB. Similarly, a request may be suspicious if it involves a vehicle involved in a prior suspicious request. In these cases, the potential for fraud increases if such matches exist. Additionally, there may be a connection between the owner or prior owner of the vehicle involved in an accident and a new claim.
  • Search rules S-3 and S-4 both involve comparisons of request data to an SIU database. A new request may be suspicious if it involves an individual or vehicle that has been investigated previously by an SIU. The potential for fraud in a new request may be increased in these cases.
  • Search rules S-6 and S-8 both involve matches of request data to a commercial mailbox database. There may be legitimate reasons for people to use commercial mail receiving agencies (CMRA) as their private mailbox. However, it is not uncommon for people or businesses to use CMRAs to disguise themselves for various reasons. CMRAs offer some degree of anonymity and distance from their true place of residence. CMRAs are also used to prevent insurance companies from attributing previous accident history to their real address in order to lower insurance premiums. If a person uses a CMRA address with respect to an insurance claim, especially if the address is written as if it is a suite or apartment, it may be important to ascertain the true address of the person.
  • Search rules S-9 and S-12 both involve comparisons of request data to a watch list database. SIU investigators and/or insurance company management may gather intelligence data from law enforcement, other carriers, and/or from personal experience concerning individuals or business that may be involved in fraud. Search rules S-9 and S-12 allow suspicious entities to be entered directly into a watch list database for comparison to new requests data. In some embodiments, the author of an item on the watch list may be notified of any matches.
  • Search rule S-11 involves comparisons of request data to a sanctioned medical provider database. Medical providers or medical businesses that have been disciplined for questionable business practices may be entered in this database. Matches from a new request to a medical provider in a sanctioned medical providers database may indicate a potential for fraud in the new request.
  • In various embodiments, the potential for fraud in a request may be assessed using an identity verification technique, as seen in FIG. 4 b, to verify the identification of various individuals and businesses involved in the request. At 405, a request data element may be verified against various databases. For example, the insured, claimant, doctors, lawyers, and other individuals may be verified by searching public records and bills (e.g., phone bills) to verify that the information provided for each of these individuals and businesses in the request corresponds to an actual individual or business's name. At 407, a fraud potential indicator may be assigned based on whether the verification was successful. In some embodiments, the level of the fraud potential indicator assigned may depend on the number of request data elements that could be verified. In some embodiments, identity verification may also be used to meet compliance requirements in various state and federal laws.
  • FIG. 5 illustrates a flowchart of an embodiment of a method for assessing a fraud potential indicator for a request by predictive modeling. At 501, request data may be compared to at least one fraud pattern (also called a fraud model) to search for similarities between the request data and fraud patterns. At 503, a fraud potential indicator may be assigned to a request based on similarities between request data and a fraud model. In some embodiments, the fraud potential indicator may be a numerical value associated with a type of fraud pattern. The fraud potential indicator may be based on expert knowledge of insurance claims and/or fraud assessment. At least one fraud pattern may be associated with an indication of fraud. In certain embodiments, a fraud potential indicator may be assigned based on a match between the request data and at least one characteristic of a fraud pattern. In some embodiments, a fraud potential indicator may be weighted according to the nearness of a match or approximate match. In some embodiments, an exact match may indicate a higher potential for fraud than an approximate match.
  • In some embodiments, a fraud pattern used in predictive modeling may be established using historical data obtained from requests in which fraud was previously identified. In some embodiments, a fraud model may include relationships between parties relating to the request and/or request data. For example, a fraud model may include the characteristics of a suspicious accident such as a staged rear-end collision.
  • As another example, if a worker's compensation claim is filed for an accident that took place at work on a Monday morning without any witnesses, the claim may be assigned a relative fraud potential indicator. In this example, a request may be compared to a predictive model using these request elements:
      • a) Accident occurred in the morning; and
      • b) No witness present.
  • As another example, circumstances may indicate a “swoop and stop” type fraud. In this case, a request for a rear end collision with a match for a sanctioned doctor for the claimant may be assigned a relative fraud potential indicator. Other circumstances may also be detected.
  • At 505, one or more predictive modeling fraud potential indicators may be combined and/or weighted if appropriate to obtain a total predictive modeling fraud potential indicator for the request. In some embodiments, one or more predictive modeling fraud potential indicators may be assigned a weighting. In such an embodiment, the weighted fraud potential indicators may be combined to obtain a total predictive modeling fraud potential indicator for the request.
  • FIG. 6 shows a flowchart of an embodiment of a method of assessing a fraud potential indicator for request data using business rules.
  • At 601, a business rule may be used to detect suspicious conditions in a request. For example, in various embodiments, business rules may be used to analyze the injury type, the loss type, the existence of a police report, who reported the request, and the number of vehicles involved. In some embodiments, business rules may be used to compare the date of loss to the date of the report of the request, the policy inception date to the date of loss, and the policy expiration date to the date of the report. Business rules may also be used to search for other conditions in a request that may indicate fraud.
  • For example, the type of injury involved and the number of injuries may indicate whether the request is likely to be fraudulent. In some embodiments, serious or visible signs of injury in the request may be contra-indicative of fraud, but soft-tissue or other non-visible complaints of injuries (especially by numerous passengers) may be indicative of possible fraud. In various embodiments, a business rule may apply a multiplier to a fraud potential indicator based on the injury type. In an embodiment, the injury type multipliers may be applied for the corresponding injury types (multiple injury types may be added together). For example:
      • Minor Injury (superficial/abrasion/contusion)=1.8
      • Fractures/Dislocations=0
      • Puncture Wounds/laceration=0
      • Fatality=−15
      • Neck and/or back soft tissue injury=2.2
      • Neck Only Sprain/Strain=2.2
      • Permanent Brain Damage=−10
      • Loss of Body Part=−10
      • Paralysis/Paresis=−15
      • Loss of Sense=3
      • Dental=1.6
      • Psychological Condition=3
      • No Visible Injury=1.8
      • Burns=0
  • In some embodiments, a formula such as, but not limited to, fraud potential indicator=(multiplier)*(cumulative injury type multipliers) may be used to assign the fraud potential indicator. In some embodiments, multiplier may be a user supplied number based on different aspects of the request. In some embodiments, negative injury type multipliers may be assigned to injury types (e.g., fatality) that are contra-indicative of fraud. In some embodiments, higher values may be assigned to injury types more indicative of fraud (e.g., soft tissue injuries).
  • In some embodiments, the loss type may indicate fraud. For example, request types that are unusual or difficult to verify may indicate more potential for fraud. In various embodiments, a loss type multiplier may be applied (multiple loss types may be added). For example:
      • Failure to Yield=7
      • Hit and Run=12
      • Over Center/Head on/Side Swipe=5
      • Single Vehicle Collision=7
      • Insured Failed to Obey Rules and Regulations=5
      • claimant's Unattended Vehicle Rolled Causing Collision=5
        Other multipliers may also be used.
  • In some embodiments, the date of loss (e.g., accident) versus the date of the report of a claim may be used to detect potential for fraud. Claims tend to be reported by parties involved in an accident shortly after the date of loss. A delay in reporting may be an indication that facts relating to an accident may be fabricated. In some embodiments, the longer the delay between date of loss (DOL) and the date of report (DOR) to a requests organization, the greater the potential for fraud in a request. In some embodiments, the fraud potential indicator of the DOL vs. DOR business rule may be combined with a loss type value. For example, DOL vs. DOR fraud potential indicator may be multiplied by a loss type value. The fraud potential indicator may also be weighted by a ranking factor.
  • In some embodiments, the policy effective date versus the date of loss may indicate fraud. There may be a significant correlation between the likelihood of fraud and a short time frame between the policy inception date and the DOL. Fictitious circumstances tend to accompany such requests since the true date of loss may be just prior to a decision to purchase insurance. In some embodiments, as the number of days increases between policy inception date and DOL the chance of the request being false decreases. The trend may be reflected in a fraud potential indicator.
  • In some embodiments, the fraud potential indicator associated with policy effective date vs. DOR fraud potential indicator may be combined with a fraud potential indicator of the loss type value. For example, the fraud potential indicators may be multiplied together. In certain embodiments, the fraud potential indicator may be combined with a ranking factor. In some embodiments, the time period between policy inception date and DOL may be divided into a set of ranges. In some embodiments, a fraud potential indicator may be associated with one or more of such ranges. In some embodiments, the fraud potential indicator for the policy inception date vs. DOL fraud potential indicator may be set to approximately zero if there was policy renewal.
  • In some embodiments, the policy expiration date versus the date of report of loss may be a fraud potential indicator. There tends to be a significant correlation between the likelihood of fraud and a report of a request occurring after the policy expiration date. Typically, requests tend to be reported within the policy period and as close to the DOL as possible. In some embodiments, requests reported on or near the policy expiration date or within weeks afterward are suspicious and may have an increased potential for fraud.
  • In some embodiments, the absence of a police report may be an indication of fraud. Police reports often accompany insurance claims, except for very minor issues. When an accident or theft occurs and the police are not called, there may be an increased potential for fraud. In some embodiments, a fraud potential indicator from a no police report business rule may be combined with (e.g., multiplied by) a ranking factor if other indications of fraud are present. In some embodiments, a fraud potential indicator may be multiplied by 0 if a police report was filed and 2 if the police report was not filed. Other multipliers may also be used.
  • In some embodiments, the identity of the person who made the request may be an indication of fraud. In some embodiments, a fraud potential indicator may be assigned based on who and how the request was initially made. For example, if an attorney or public adjustor reports a property damage only claim, there may be an increased potential for fraud. In some embodiments, it may be less suspicious when an insured person reports the request.
  • In some embodiments, the number of vehicles involved in an accident may be an indication of fraud for an insurance claim. In some embodiments, the number of vehicles involved in an accident may be both an indication of fraud and a counter-indicator of fraud depending on the circumstances. For example, accidents involving more than two vehicles tend to be more difficult to stage, and therefore, may be less likely to be fraudulent. In some embodiments, a multi-vehicle accident may have a negative contribution to the fraud potential indicator for a request. However, single vehicle accidents may have a greater potential of being fraudulent. In some embodiments, the fraud potential indicator associated with the number of vehicles involved may be combined with (e.g., multiplied by) a ranking factor if other indications of fraud are present. In some embodiments, if using formulas, multiple vehicle accidents may be assigned negative multipliers.
  • In some embodiments, the length of time between the date a check was written and the date that the check is cashed may be an indication of fraud. In some embodiments, inconsistent loan data may be an indication of fraud. For example, an application that indicates a person has a low salary, but very high liquid assets value may have a higher potential for fraud. In addition, other circumstances about a request may be analyzed using business rules. For example, loan data may be used to determine the amount of money an applicant may be loaned under the “28/36” rule for mortgages. In some embodiments, a loan applicant's income may be compared to his assets. Other circumstances may also be investigated.
  • In various embodiments, a user may be allowed to create one or more user-defined (i.e., custom) business rules. A custom business rule may include information from the user for assessing a fraud potential indicator for a request.
  • At 603, a business rule may be used to assign a fraud potential indicator to at least one request. In some embodiments, a business rule may be designed to detect suspicious circumstances reported in a request and used to assign an appropriate fraud potential indicator to the request.
  • In various embodiments, business rule fraud potential indicators may be combined to obtain a total business rule fraud potential indicator for the request. For example, if circumstances match two different business rules, a higher fraud potential indicator may be assigned. In some embodiments, at least one business rule fraud potential indicator may be weighted. In various embodiments, weighted business rule fraud potential indicators may be combined to obtain a total business rule fraud potential indicator for the request.
  • FIG. 7 illustrates an embodiment of software components for performing fraud analysis. An embodiment of a system for assessing the potential for fraud in an insurance claim may include a plurality of software components. A software component may perform at least a portion of a method for assessing the potential for fraud in an insurance claim. Request data 701 may be stored in at least one database. The request data 701 may be obtained from a variety of sources. The sources may include, but are not limited to, an insurance policy, accident reports, parties related to the request, insurance adjusters, insurance fraud investigators, etc. In some embodiments, request data 701 may be processed for assessment of the potential for fraud by at least one software component. Data transformer component 703 may extract information from the request data 701 that may be relevant to assessing the potential for fraud in an insurance claim. Data transformer component 703 may then create a request data file in a desired format using the extracted data.
  • In some embodiments, identity engine component 705 may be used to assign at least one fraud potential indicator 717 for request data 701. Identity engine component 705 may compare at least one request data element to various databases. In some embodiments, various databases may include, but are not limited to, insurance industry data 725, commercial mailbox data 727, SIU data 729, sanctioned medical providers data 731, company requests data 733 and/or custom watch list data 735. Identity engine component 705 may assess similarities between (e.g., matches or approximate matches of characteristics) request data 701 and the various databases. A fraud potential indicator 717 for the request data 701 may be evaluated from the similarities by evaluation component 711. In some embodiments, identity engine component 705 may evaluate a fraud potential indicator 717 directly.
  • In some embodiments, Identity Systems (IDS) from Search Software America (SSA) of Old Greenwich, Conn. may be used with the identity engine component 705. SSA IDS performs searching, matching, and duplicate discovery for many forms of identification data. SSA IDS transparently maintains its own high performance “fuzzy”indexes, and de-normalized tables. SSA IDS also compensates for variation, spelling, keying, and word sequence errors in names, addresses and identity data regardless of country, language or character set. SSA IDS also supports searches of aliases, former names, compound names, prior addresses, multiple dates of birth, identity, phone numbers, etc.
  • In some embodiments, rules engine component 707 may assess at least one fraud potential indicator 719 for request data 701. Rules engine component 707 may compare at least one request data element to at least one business rule 737. As used herein, a “rules engine” may include an expert system, which is operable to produce an output as a function of a plurality of rules. A rules engine component 707, in some embodiments, may include an expert computer system that utilizes and/or builds a knowledge base in the form of business rules and/or formulas 737 to assist the user in decision-making. In some embodiments, rules engine component 737 may include rules based on expert knowledge for assessing the potential for fraud in an insurance claim. In some embodiments, the Visual Product Modeling System (VP/MS) from Computer Sciences Corporation in El Segundo, Calif. may be used in rules engine component 707. In some embodiments, the fraud potential indicator 717 for a request may be assessed by rules engine component 707 or evaluation component 713.
  • In some embodiments, predictive modeling engine component 709 may assess a fraud potential indicator 721 for request data 701. In some embodiments, predictive modeling component 709 may develop fraud patterns (or “fraud models 723”) from historical request data associated with fraudulent requests. In some embodiments, predictive modeling component 709 may compare at least one request data element to at least one fraud model 723. In some embodiments, predictive modeling engine component 709 may assess similarities (e.g., matches or approximate matches) of at least one request data 701 to at least one fraud model 723. In certain embodiments, a fraud potential indicator 721 for the request may be evaluated by evaluation component 715 based on identified similarities. In an alternative embodiment, predictive modeling engine component 709 may evaluate a fraud potential indicator 721 directly.
  • As used herein, a predictive modeling engine component 709 may be operable to search for patterns in a group of historical data as a means of assessing future behavior. A predictive modeling engine 709 may discover previously unknown relationships among data. In some embodiments, predictive modeling component 709 may be used to detect suspicious relationships or fraud patterns among claimants, witnesses, medical providers, attorneys, repair facilities, etc. In some embodiments, predictive modeling engine component 709 may create and store a list of such fraud patterns 723 evaluated from past fraudulent request data. In some embodiments, Predictive Targeting System from Magnify of Chicago, Ill. may be used in predictive modeling engine component 709.
  • In various embodiments, other components may be used. For example, an administrative component may be added to allow a user to load information, values, thresholds, and other data for using the system. In some embodiments, the system may include links to relevant tools (e.g., websites with investigative tools). In some embodiments, links to information relevant to a user's usage of the system or workload may also be included. In some embodiments, references may be included for use by people such as, but not limited to, adjustors and investigators. In some embodiments, links to references may be included on a menu bar. For example, a link to the state of New York Insurance Manual may be included for access by an investigator who is investigating a claim in New York. As another example, a company's standard operating procedures could be linked. Other components are also contemplated.
  • FIG. 8. shows an embodiment of software components for assigning requests (e.g., claims) to investigators. While FIGS. 8-21 show embodiments in which the request is an insurance claim, FIGS. 8-21 may also be applied to other requests (e.g., checks and loans). In various embodiments, rules 803 may be used to analyze fraud potential indicators (717, 719, 721) assigned to a claim. In some embodiments, the fraud potential indicators may also be combined (e.g., by adding) and/or weighted according to rules 803. In some embodiments, rules 803 may be used by an assignment and referral component 801 to assign a claim to an SIU 805. For example, rules may analyze whether one or more fraud potential indicators (or the combined and/or weighted fraud potential indicator) are above a certain threshold to assign the claim to the SIU. In some embodiments, the rules 803 may be used to assign a claim to an investigator (e.g., if the fraud potential indicator(s) indicate a smaller likelihood of the claim being fraudulent than claims to be assigned to the SIU). In some embodiments, the claim may be assigned to an adjuster 809 for review. In various embodiments, if the fraud potential indicator(s) are not above a certain threshold (or are below a defined threshold), the claim may be assigned to routine claim handling. In some embodiments, if the fraud potential indicator(s) are low enough (e.g. negative) the claim may be paid 813 without further handling. In some embodiments, when a claim is referred for review, as in actions 805, 807, and 809, assignment and referral component 801 may notify at least one claims adjustor or an SIU investigator by e-mail of the status of the claim. In some embodiments, a user that has defined a custom profile relevant to a claim may be notified by e-mail.
  • In some embodiments, relative rankings for claims (also called a “status” of the claims) may be assigned based on a fraud potential indicator for the claim obtained from one or more of the fraud potential detection techniques. The status of a claim may be associated with a range of fraud potential indicators. For example, at least two ranges of fraud potential indicators may be defined. The ranges may provide a method of ranking claims in terms of relative fraud potential indicators. In certain embodiments, at least one of the ranges may be associated with an action regarding a claim. For example, a claims organization may consider a claim with a fraud potential indicator below a certain value to have a low probability of being fraudulent. Therefore, the claims organization may associate the range below a certain value with automatic or express payment of the claim. In a similar manner, a claim with a fraud potential indicator in a certain range may be associated with routine claim handling. A claims adjuster may be notified of the increased fraud potential indicator for a claim with a fraud potential indicator above a certain threshold. A claim with a fraud potential indicator greater than a threshold value (referred to herein as a minimum referral threshold) may be automatically referred for an investigation with a high level of scrutiny such as that performed by a special investigative unit (SIU) of a claims organization.
  • Some embodiments of a method for assessing the potential for fraud for claim data may include modifying at least one threshold value to obtain a selected volume of claims to investigate. For example, a minimum referral threshold may be modified or tuned to obtain a selected volume of referrals for further review.
  • In various embodiments, the claims may be ranked in order of likelihood of being fraudulent. An investigator may then investigate the claims in order with the most likely fraudulent claim first.
  • In certain embodiments, a system for assessing the potential for fraud in insurance claim data may allow adjusters and investigators to track and review referrals from any computer with Internet or company Intranet access. An adjuster or investigator may be allowed to display a summary list of all claims referred to that individual. The list of claims may be arranged in order of highest fraud potential indicator first. In other embodiments, the list may be sorted other ways, such as by referred date, by insured, by claim number, etc. In some embodiments, users of a system may also display claims that meet certain selected criteria. For example, the selected criteria may include, but are not limited to, a range of dates, a range of fraud potential indicators, claims referred to other investigators, or open claims.
  • In some embodiments, a system may allow a specific claim in a summary list to be reviewed in more detail by selecting the claim. A more detailed description of a selected claim may be displayed, including information regarding parties involved. In some embodiments, information that triggered the referral may be “flagged” with an icon. The icon may be selected to display a detailed description of reasons the information triggered the referral. In some embodiments, an investigator may pursue the claim further through standard investigation procedures of a claims organization.
  • In some embodiments, when claim data for a claim is updated the fraud potential indicator for the claim may be assessed again. If a new fraud potential indicator is higher than the previous fraud potential indicator, the claim may be reactivated (if inactive) and an investigator may be notified.
  • FIG. 9 illustrates an embodiment of system 900 for assessing the potential for fraud in insurance claims. Claim data 901 may be imported or loaded 903 from an insurance company's claim data database to customer database 905. In various embodiments, the claim data may be imported in batches (e.g., claim data may be analyzed each night). In some embodiments, claim data may be imported in real-time. For example, as a claim is being made, the data may be analyzed and a potential for fraud may be assessed and communicated to the person taking the claim in real-time. In some embodiments, claim data 901 on customer database 905 may be accessed by a computer system that includes fraud assessment 907 software components. Results of fraud assessment 907 may be loaded onto reporting database 909. In some embodiments, report 913 of the fraud assessment results may be created 911.
  • FIG. 10 illustrates an embodiment of system 1000 for loading claim data from an insurance company database to a customer database. In some embodiments, system 1000 may receive periodic updates (e.g., nightly) of claim data from an insurance company's claim data database. Original claim data extract files 1003 may be loaded into FTP directory 1001 of system 1000 from an insurance company's claim data database. File receiver 1005 may monitor FTP directory 1001 for new extract files 1007. In some embodiments, file receiver 1005 may transfer new extract files 1007 to staging directory 1009 to minimize disk usage on the FTP server. In some embodiments, database loader 1011 may load copies of new extract files 1007 to customer database 1013. In certain embodiments, data transformer 1015 may translate claim data into a format suitable for fraud potential assessment.
  • In various embodiments, information about requests may be displayed in a browser format. In some embodiments, a user may login to a system to access information about a request. FIG. 11 illustrates an embodiment of a screen shot of claim summary window 1101 that displays claim information. Claim summary window 1101 may display information regarding involved vehicles 1103 and 1107, involved parties 1105 and 1109, and related parties 1111. Other information that may be displayed includes, but is not limited to, claim number, claim status, claim office, loss date, loss report date, type of report filed, who reported the claim, the claim type, an accident description, a location description, a policy number, a policy state, an inception date, number of renewals on the policy, effective date of the policy, and/or an expiration date of the policy. In some embodiments, a prior screen button 1113 may be provided to allow a user to navigate quickly between claim summaries.
  • FIG. 12 illustrates an embodiment of a screen shot of watch list display window 1201 that displays data from a watch list database. Watch list display window 1201 may include header row 1205 that describes various types of data relating to watch list entries in rows 1203. The types of data relating to watch list entries may include, but are not limited to author 1211 of the watch list item, DBA name 1213, business name 1215, and identity information 1217. In some embodiments, a user may select “Add” push button 1207 to add a new entry to the watch list display. In another embodiment, a user may select “Update” push button 1209 to update an existing entry. In some embodiments, the watch list screen may include tabs (not shown). For example, a tab may be presented for an individual and a tab may be presented for an organization. In some embodiments, selecting a tab may present information about respective individuals or organizations.
  • FIG. 13 illustrates an embodiment of a screen shot of watch list add/update window 1301. Watch list add/update window 1301 may display text boxes 1315 for adding or updating entries in a watch list database. A user may enter business information 1311, personal information 1309, and/or other information 1307 in watch list add/update window 1301. A user may select “Submit” push button 1303 to save the information entered. Alternatively, a user may select “Cancel” push button 1305 to disregard changes in information entered.
  • In some embodiments, a method may display at least two fraud potential indicators in a graphical user interface.
  • FIG. 14 illustrates an embodiment of a screen shot of manager notebook window 1401 for displaying fraud assessment results. In some embodiments, manager notebook window 1401 may include referred tab 1407, assigned tab 1409, and rejected tab 1411. In some embodiments, when referred tab 1407 is selected, manager notebook window 1401 may display claims 1403 with fraud potential indicators that exceed a minimum referral threshold for at least one fraud potential detection technique. In some embodiments, if the assigned tab 1409 is selected, the user may be allowed to assign selected claims.
  • In an embodiment, the claim information shown may include selection 1405, field claim office (FCO) 1413, claim number 1415, loss date 1417, score date 1419 (date claim was scored by the fraud potential detection system), PME Score 1421 (e.g., predictive modeling fraud potential indicator), ISE Score 1423 (e.g., identity search fraud potential indicator), and ORE Score 1425 (e.g., business rules fraud potential indicator). In some embodiments, the selection check boxes 1405 may allow multiple claims to be selected at once. In some embodiments, clicking on claim number 1415 may bring up a claim summary screen. In some embodiments, clicking on a score in PME Score 1421 column, ISE Score 1423 column, or ORE Score 1425 column may bring up a summary screen displaying why the particular score was assigned (e.g., a list of matches may be displayed if an ISE Score in ISE Score 1423 column is selected).
  • In FIG. 14, referred tab 1407 is selected. In some embodiments, when assigned tab 1409 is selected, manager notebook window 1401 may display claims assigned to fraud investigators. In some embodiments, when rejected tab 1411 is selected, manager notebook window 1401 may display claims that have been rejected due to a high potential for fraud.
  • In some embodiments, manager notebook window 1401 may include column 1405 with checkboxes that allow a user to select a particular claim. Manager notebook window 1401 may further display column 1413 that includes the field claim office of a claims organization with which a claim is associated. In certain embodiments, when a user selects a fraud potential indicator for a claim in columns 1421, 1423, and 1425, a summary screen of the related fraud assessment may be displayed. For example, when a user selects fraud potential indicator 1427, a business rules fraud potential indicator summary screen may be displayed. In some embodiments, selecting an “assign” graphical component 1429 may navigate a user to an assignment screen that allows the user to assign selected (checked) claims to an investigator. In another embodiment, selecting a “reject” graphical component 1431 may allow a user to reject selected (checked) claims that have been referred. In some embodiments, a navigation menu 1453 may be included. The navigation menu 1453 may be used to quickly shift between different components (e.g., Home, Manager Notebook, Investigator Notebook, Watch List, Administration, Links, and References).
  • FIG. 15 illustrates an embodiment of a screen shot of a manager notebook window with the assigned tab 1409 selected. In some embodiments, with the assigned tab 1409 selected, the user may be allowed to see the claimant's last name 1501, claimant's first name 1503, field claim office 1505, claim number 1507, loss date 1509, score date 1511, number of days the claim has been assigned 1513, investigation status 1515 (e.g., an SIU investigation), and status of the claim 1517 listed with other claim data for each claim. In some embodiments, the claims may be organized respective to the information in a column by selecting the column (e.g., by clicking a label at the top of the column). In some embodiments, multiple claim categories may be selected. In some embodiments, claims may be selected using the selection column 1527. In various embodiments, other claim data may include the various scores assigned to the claim (e.g., PME Score 1519, ISE Score 1521, and BRE Score 1523). In some embodiments, a flag indicator may be displayed next to each score with a respective color depending on the severity of the score (e.g., a red flag for high, yellow flag for medium, and green flag for low). In addition, a column may be provided to indicate whether the claim is closed. In some embodiments, when assigning a claim, a display of investigators and their corresponding regions may be displayed. The claim may be assigned to an investigator in the same region the claim occurred in. In addition, in some embodiments, claims may be assigned to a region. For example, a claim assigned to a region may be assigned to a supervisory investigator for the region to be further assigned by that supervisory investigator. In some embodiments, if a claim has been examined by an investigator, it may not be reassigned or an error message may appear when a user attempts to assign the claim to alert the user that an investigator has already started investigating the claim. In some embodiments, a filter graphical component 1525 may be selected to change the criteria of the displayed claims. For example, a particular investigator may be selected and only the claims assigned to the selected investigator may be displayed.
  • FIG. 16 illustrates an embodiment of a screen shot of a manager notebook window with rejected tab 1411 selected. In some embodiments, if rejected tab 1411 is selected, the user may reject a claim. In certain embodiments, a Reject Reason dialog box may appear to allow the user to enter a reason why the claim was rejected. In some embodiments, a user may select from preformed reasons (e.g., Invalid BRE Score, Invalid ISE Score, Invalid PME Score, Low Score, Insufficient data, lack of evidence, manpower, no fraud, and liability). In some embodiments, pressing rejected tab 1411 may bring up a screen with rejected claims. For example, claims may be rejected manually by a claims adjuster, an investigator, or rejected automatically (e.g., if the score for the claim exceeds a threshold). Other reasons for rejecting a claim are also contemplated. In some embodiments, a rejected claim may be activated and assigned. In various embodiments, claims may be selected using the check boxes in Selection column 1633. In some embodiments, settings may be adjusted to adjust the number of days of rejected claims shown. In some embodiments, a rejected by column may display who rejected a claim. In some embodiments, FCO 1605, claim number 1607, loss date 1609, score date 1611, PME score 1619, ISE score 1621, and BRE score 1623 may be shown for each claim. In addition, in some embodiments, rejected reason 1625 may be displayed for each claim. In certain embodiments, the reason may be system generated or person generated. In various embodiments, the investigation status and whether the claim has been closed may also be displayed. In some embodiments, assign graphical component 1631 may be pressed to assign selected claims (e.g., using selection column 1633 to assign rejected claims). Other information may also be displayed (e.g., name of the regional manager 1635 and total number of claims displayed).
  • In various embodiments, other tabs may be used. For example, a New tab may be used to access information on claims that have not been assigned. In some embodiments, a user may use a New tab to access information on claims to be opened or reassigned back to a supervisor. In some embodiments, an Open tab may allow access to all open claims assigned to a particular investigator. In some embodiments, a Pending tab may be used to display claims in which the investigation is complete, but the claim is still pending.
  • FIG. 17 illustrates an embodiment of a screen shot of identity search fraud potential indicator summary window 1701. Identity search fraud potential indicator summary window 1701 may display fraud potential indicators for at least one party and/or object involved in a claim. In some embodiments, the fraud potential indicator due to at least one database for at least one party and/or object may be displayed. Identity search fraud potential indicator summary window 1701 may display fraud potential indicators for involved people 1707, involved organizations 1705, involved vehicles 1703, etc. In column 1709, fraud potential indicators assessed for involved parties may be displayed individually. Columns 1711 may include identifying information for at least one involved person. Columns 1715 may display a total fraud potential indicator from each searched database for an involved person. For example, fraud potential indicator 1713 may be the total fraud potential indicator for John Rowan based on an SIU database. In some embodiments, selecting a fraud potential indicator may navigate a user to an identity search results window, which may display matches of an involved person or object with at least one database. In column 1717, fraud potential indicators assessed for involved organizations may be displayed individually. Columns 1719 may include identifying information for involved organizations. Columns 1721 may display a fraud potential indicator for each searched database for an involved organization. In column 1723, fraud potential indicators assessed for involved vehicles may be displayed individually. Columns 1725 and 1727 may include identifying information of involved vehicles. Columns 1729 may display a total fraud potential indicator from each search database.
  • FIG. 18 illustrates an embodiment of a screen shot of identity search results window 1801. In some embodiments, identity search results window 1801 may display the fraud potential indicators and associated search matches of at least one involved person and/or object associated with a fraud potential indicator. For example, identity search results window 1801 may display the fraud potential indicators and search matches associated with at least one fraud potential indicator in Table 1. Summary 1805 may be displayed, for example, for the S-1 fraud potential indicator. Summary 1805 may display fraud potential indicator 1817, involved person 1815, and matches 1809 of involved person 1815 with a company historical database. Summary 1803 may be displayed, for example, for the S-2 fraud potential indicator. Summary 1803 may display fraud potential indicator 1813, involved person 1811, and matches 1807 of involved person 1811 with an industry database (e.g., NICB).
  • In various embodiments, tables may be presented in the identity search engine results screen to access information on which elements matched particular databases. For example, tables may be available for SIU, NICB, Sanctioned Doctors, Commercial Mailboxes, and Watch lists. In some embodiments, an indicator on a table may be selected to expand a selection on the table. For example, a “+” sign may be selected on a table to expand the information shown for an involved person, involved organization, and involved vehicle. In some embodiments, information shown for a person may include points from matches of the person to a database, the name of the person, the address of the person (including city, state, and zip code), the number of matches for this person in the claims database, the SIU database, the NCIB database, the Commercial Mailbox database, and the watch list database. In some embodiments, information shown for an involved organization may include points for matches the organization received, the name of the organization (including a DBA name), the address of the organization (including city, state, and zip code), and matches the organization received in the SIU database, the NICB database, the Commercial Mailbox database, and the Watch list database. In some embodiments, information shown for an involved vehicle may include points the vehicle received for matches in the database, the VIN number of the vehicle, the license information for the vehicle, and the number of matches for the vehicle in the claims database, the SIU database, and the NICB database. Other information, including other databases, may also be presented for other entities involved in a request.
  • FIG. 19 illustrates an embodiment of a screen shot of predictive modeling fraud potential indicator summary window 1901. Predictive modeling fraud potential indicator summary window 1901 may be displayed, for example, when a user selects a fraud potential indicator in column 1421 in FIG. 14. Predictive modeling fraud potential indicator summary window 1901 may display total predictive modeling fraud potential indicator 1905 from a predictive modeling engine. In some embodiments, window 1901 may display factors 1903 that were considered in determining total fraud potential indicator 1905.
  • FIG. 20 illustrates an embodiment of a screen shot of business rules fraud potential indicator window 2001. In some embodiments, the screen shot may be displayed when the BRE score is selected in the claim summary screen. In some embodiments, business rules fraud potential indicator summary window 2001 may display at least one individual business rule fraud potential indicator used by the business rules engine to determine the total business rule fraud potential indicator. Column 2007 may include the fraud potential indicators for individual business rules. Column 2009 may include a description of business rules. Total business rules fraud potential indicator 2005 may include the overall fraud potential indicator determined by the business rules engine. In some embodiments, selecting an individual fraud potential indicator in column 2007 and/or a business rule description in column 2009 may display a business rule detail window. In some embodiments, accident description dialog box 2003 may be displayed in window 2001.
  • FIG. 21 illustrates an embodiment of a screen shot of business rules detail window 2101. In some embodiments, business rules detail window 2101 may be displayed, for example, by selecting an individual fraud potential indicator in column 2007 and/or a business rule description in column 2009 in window 2001 shown in FIG. 20. Business rules detail window 2101 may display the individual business rule fraud potential indicators for at least one business rule. Rows 2105 may each pertain to at least one involved person or object involved in the claim. Column 2111 may include a description of loss sustained by an involved person or object. Columns 2109 and 2107 may include identifying information of an involved person or object and the fraud potential indicator assessed due to the loss. Business rules fraud potential indicator 2103 for the business rule may be displayed in business rules detail window 2101.
  • FIG. 22 shows a flowchart of an embodiment of a method for displaying summary information related to the various engines. At 2201, at least two fraud potential indicators for an insurance claim may be assessed using at least two of an identity search engine, a predictive model engine, and a business rule engine. At 2203, information about an insurance claim may be displayed including identifying information for the claim and the at least two fraud potential indicators for the insurance claim. At 2205, engine summary information related to at least one engine used to assign at least one of the at least two fraud potential indicators may be displayed.
  • In various embodiments, other summary screens may also be used. In some embodiments, an involved people summary screen may show a summary of involved people in a claim. In some embodiments, an involved people summary screen may be presented when a user selects an individual score on an identity search engine results screen. In some embodiments, tabs may be displayed for each involved person and accessing a tab may bring up information regarding how the involved person matched information related to the tab. For example, tabs may be presented for the SIU, NICB, commercial mailbox, watch list, and historical claims databases. In some embodiments, a name of a person associated with the selected individual score may be displayed as an anchor record of a tab. For example, selecting the SIU tab may present matches for the selected individual against the SIU database (e.g., the percentage of similarity between the matches, the claim number in the SIU database matched, the name, address, and phone numbers of the person matched). Other information may also be displayed depending on which database tab is selected (e.g., the NICB number for the matching NICB claim, the store name of the holder of the commercial mailbox, the identifier in the Watch list, and the claim number for the claim in the claims database matched).
  • In some embodiments, summary screens may be shown for involved organizations, vehicles, and other entities. FIG. 23 illustrates a flowchart of an embodiment of a method for displaying summary information related to involved entities. At 2301, at least two fraud potential indicators for an insurance claim may be assessed using at least two of an identity search engine, a predictive model engine, and a business rule engine. At 2303, information about an insurance claim may be displayed including identifying information for the claim and the at least two fraud potential indicators for the insurance claim. At 2305, summary information related to an involved entity related to at least one assigned fraud potential indicator may be displayed. For example, an involved organization summary screen may be displayed if the score for the involved organization is selected in the identity search engine summary screen. In some embodiments, tabs may be presented in the involved organization summary screen for different databases searched. For example, tabs may be available for the sanctioned doctors database, the NICB database, and the commercial mailbox database. In some embodiments, information shown if a tab is selected may include the score for the percentage of similarity of the match, the name, address, and phone number of the match, and other information dependent on which database has been selected (e.g., identifier for the sanctioned doctor, NICB number, and store name for the commercial mail box).
  • In some embodiments, involved vehicle summary screens may be displayed by selecting the individual score for the involved vehicle in the identity search engine summary screen. In some embodiments, the involved vehicle summary screen may include tabs for various databases searched (e.g, the SIU database, the NICB database, the claims database, and the watch list database). In some embodiments, information about the match in the various databases (e.g., percentage of similarity of match, the VIN, the year, the make, the model, the license number, and the state may be displayed) may be presented along with database specific information (e.g., SIU claim number, NICB reference number, the claim number, and the watch list identifier).
  • In some embodiments, watch list summary screens may be provided for entities being tracked by a watch list. In some embodiments, users may keep track of where individuals and organizations are showing up in claims. For example, watch list individual summary and watch list organization summary screens may be used.
  • In various embodiments, support screens may also be used to show data about the system. For example, a support data screen may used to modify data in an administrative file. A user setup screen may be used to maintain and modify user information for users of the system (e.g., user's office, email address, and user group). A company setup screen may be used to maintain information about a company using the system.
  • In various embodiments, information used by the system may be maintained through an administrative interface. FIG. 24 illustrates a flowchart of an embodiment of a method for configuring administrative information for a fraud potential detection system. At 2401, at least two fraud potential indicators for an insurance claim may be assessed using at least two of an identity search engine, a predictive model engine, and a business rule engine. At 2403, administrative information for a system may assess at least two fraud potential indicators for an insurance claim. In some embodiments, country information (e.g., a country code and country name), state information (e.g., state abbreviations, name of state, region associated with the state, and country the state is a part of), and region information (e.g., region identifier, region name, and additional region information) may be updated, deleted, and/or maintained for countries, states, and regions used by the system. In some embodiments, information about a company (e.g., company name, company address, additional addresses, company city, company state, company zip code, and company country), office information (e.g., office name, office address, office city, office state, office zip code, office country, office email address, and office region) may be updated, deleted, and/or maintained for companies and offices used by the system. In certain embodiments, information for investigation status (e.g., a status code and respective investigation status description), closure reasons (e.g., closure identifier and respective closure reason), and reason rejected (e.g., a reason identifier and respective reason the claim was rejected) may be updated, deleted, and/or maintained for codes and identifiers used by the system. For example, after a closure identifier is set-up, a user may select a code for a closure reason instead of typing out a reason for each claim. Other information may also be updated, deleted, and/or maintained. For example, information about a role description (e.g., a role identifier and a description for the role identifier), information about a user group (e.g., a user group identifier and respective user group information), and information for a user set-up (e.g., user first name, user last name, user identifier, user phone number, user email address, user region, user office, number of days of claims displayed for the user, and user group associated with the user). In various embodiments, the information may be accessed using a navigation bar with directory trees for the information titles. In some embodiments, “+” signs next to a respective information title may be pressed to access corresponding directory information. Other selection methods may also be used.
  • In some embodiments, the system for assessing the potential of fraud in requests may present results of the assessment in several ways. FIG. 25 illustrates a flowchart of an embodiment of a method for displaying assessment results. At 2501, at least one fraud potential indicator for a plurality of insurance claims may be assessed using at least one fraud potential detection technique. At 2503, a minimum referral fraud potential indicator may be defined such that a desired quantity of requests are referred for further investigation. At 2505, a fraud potential indicator may be displayed in a graphical user interface. In some embodiments, at least two fraud potential indicators may be assessed for a request and displayed in a graphical user interface. At 2507, a ranking may be assigned to at least one request relative to a probability of fraud. In some embodiments, multiple requests may be listed according to their ranking. In some embodiments, an investigator may investigate the requests in order of ranking (e.g., a request with a high probability of fraud may be assigned a higher ranking, and thus be considered before, a request with a lower probability of fraud).
  • FIG. 26 illustrates a flowchart of an embodiment of a method for displaying information about requests using tabs. At 2601, at least two fraud potential indicators for an insurance claim may be assessed using at least two of an identity search engine, a predictive model engine, and a business rule engine. At 2603, information about an insurance claim may be displayed including identifying information for the claim and the at least two fraud potential indicators for the insurance claim. At 2605, a tab may be displayed. In some embodiments, selecting the tab may display information related to the claims associated with a reference on the tab selected (e.g., a tab may have the name of a searched database and link a user to matches detected between an insurance claim and the database).
  • Further modifications and alternative embodiments of various aspects of the invention may be apparent to those skilled in the art in view of this description. Accordingly, this description is to be construed as illustrative only and is for the purpose of teaching those skilled in the art the general manner of carrying out the invention. It is to be understood that the forms of the invention shown and described herein are to be taken as the presently preferred embodiments. Elements and materials may be substituted for those illustrated and described herein, parts and processes may be reversed, and certain features of the invention may be utilized independently, all as would be apparent to one skilled in the art after having the benefit of this description of the invention. Changes may be made in the elements described herein without departing from the spirit and scope of the invention as described in the following requests.

Claims (66)

1. A method, comprising:
providing at least one request data element for at least one request to a computer system;
assessing at least one fraud potential indicator for the at least one request based on at least two of:
a) at least one comparison of the at least one request data element to a datum in a database;
b) at least one comparison of the at least one request data element to at least one fraud model; and
c) at least one business rule applied to the at least one request data element;
wherein the at least one fraud potential indicator comprises an estimate of a probability of fraud in the at least one request.
2. The method of claim 1, wherein at least one request comprises at least one of: a check; an insurance claim; and a loan.
3. The method of claim 1, further comprising assigning a total fraud potential indicator from at least two fraud potential indicators.
4. The method of claim 2, wherein the total fraud potential indicator is assigned by adding together the at least two fraud potential indicators.
5. The method of claim 2, wherein the total fraud potential indicator is assigned by averaging the at least two fraud potential indicators.
6. The method of claim 1, wherein at least one request data element comprises at least one of: a claimant's name; a witness's name; an insured's name; a medical provider's name; an involved business's name; an involved business's address; a date of the at least one request; a date of loss; identification of an involved vehicle; an inception date of a policy; an expiration date of a policy; an address of a party related to the at least one request; a detail of the loss or an accident leading to the loss; a detail of an accident; a type of accident; a number of parties involved; a type or degree of property damage; a type or degree of injuries; a trajectory of vehicles in a vehicle accident; and a location of an accident.
7. The method of claim 1, wherein the at least one request data element comprises at least one of: information on a drawer; a payee; a date; an account number; a routing number; and involved banks.
8. The method of claim 1, wherein the at least one request data element comprises at least one of: information about a loan applicant; a loan applicant's credit history; another debt of the loan applicant; an income level of the loan applicant; a criminal history of the loan applicant; a social security number; an address; other obligations; information on an item to be purchased with loan proceeds; and information about another party involved in the loan.
9. The method of claim 1, wherein the at least one comparison of at least one request data element to at least one fraud model comprises determining if at least one request data element approximately matches at least one fraud model.
10. The method of claim 1, wherein the at least one comparison of at least one request data element to at least one fraud model comprises assigning a fraud potential indicator based on the nearness of an approximate match of a fraud model to at least one request data element.
11. The method of claim 1, wherein assessing at least one fraud potential indicator comprises determining if at least one request data element approximately matches at least one fraud model, and assessing at least one fraud potential indicator based on which request data element is approximately matched.
12. The method of claim 1, wherein assessing at least one fraud potential indicator comprises determining if at least one request data element approximately matches at least a portion of a data element in a database.
13. The method of claim 1, further comprising referring the at least one request for review if at least one fraud potential indicator exceeds a threshold value.
14. The method of claim 13, wherein the threshold value is adjusted to control the number of requests with at least one fraud potential indicator exceeding the threshold value.
15. The method of claim 1, further comprising:
assigning a total fraud potential indicator based on at least one fraud potential indicator; and
referring at least one request for review if the total fraud potential indicator exceeds a threshold value.
16. The method of claim 1, wherein at least one fraud model is based on at least one historical fraud pattern.
17. The method of claim 1, wherein at least one fraud potential indicator comprises at least one of: a numerical indicator; a ranking; and a pass/fail indicator.
18. The method of claim 1, wherein assessing the at least one fraud potential indicator includes determining an absence of fraud in a request.
19. The method of claim 1, further comprising assessing the probability of fraud in at least two requests, wherein the at least two requests are ranked in order of potential for fraud in each request.
20. The method of claim 1, wherein the at least one comparison of at least one request data element to a datum in a database comprises comparing at least one request data element to a watch list database, wherein the watch list database comprises at least one specified data element specified by an entity.
21. The method of claim 20, wherein the entity is notified if at least one request data element matches at least one specified element in the watch list.
22. The method of claim 1, wherein at least one fraud potential indicator is assessed for the at least one request using a predetermined formula.
23. The method of claim 22, wherein at least one fraud potential indicator is assessed using at least one comparison of at least one request data element to a datum in a database, wherein at least one fraud potential indicator is set approximately equal to a multiplier value multiplied by a loss type value multiplied by a number of matches between the at least one request data element to the datum found in a database searched.
24. The method of claim 22, wherein the multiplier value equals a ranking multiplied by a point weight multiplied by an adjustment number.
25. The method of claim 1, further comprising:
reassessing the at least one request data element for the at least one request; and
updating the at least one fraud potential indicator for the at least one request based on the reassessment.
26. The method of claim 1, wherein the database comprises at least one of: an insurance industry database; a commercial mailbox database; a company historical request database; a special investigation unit database; a sanctioned medical providers database; and a custom watch list database.
27. The method of claim 1, wherein the at least one fraud model comprises a suspicious relationship between parties involved in an accident.
28. The method of claim 1, wherein at least one business rule is used to assess a probability of fraud based on the details of an accident.
29. The method of claim 1, wherein at least one business rule compares a date of report of a loss and a date of the loss.
30. The method of claim 1, wherein at least one business rule compares a date of a reported loss and a date of inception of an insurance policy.
31. The method of claim 1, wherein at least one business rule compares a date of a reported loss and a date of expiration of an insurance policy.
32. The method of claim 1, wherein at least one business rule assesses a probability of fraud in the at least one request based on an injury type.
33. The method of claim 1, wherein at least one business rule assesses a probability of fraud in the at least one request based on a loss type.
34. The method of claim 1, wherein at least one business rule assesses a probability of fraud in the at least one request based on an existence of a police report.
35. The method of claim 1, wherein at least one business rule assesses a probability of fraud in the at least one request based on who reported the at least one request.
36. The method of claim 1, wherein at least one business rule assesses a probability of fraud in the at least one request based on the number of vehicles involved.
37. The method of claim 1, wherein at least one business rule assesses a probability of fraud in the at least one request based on time difference between the date of a check and the date the check is cashed.
38. The method of claim 1, wherein at least one business rule assesses a probability of fraud in the at least one request based a comparison of a loan applicant's income to the loan applicant's assets.
39. The method of claim 1, wherein assessing at least one fraud potential indicator for at least one insurance claim is based on an identity verification engine to verify the identification of at least one data request element.
40. The method of claim 39, wherein at least one data request element verified includes an insured, a claimant, a doctor, a lawyer, or an involved business.
41. The method of claim 39, wherein at least one of a public record and a bill is used to verify the identification of at least one request data element.
42. A computer system, comprising:
a CPU; and
a memory coupled to the CPU, wherein the memory is configured to store at least one computer program executable by the CPU, and wherein at least one computer program is executable to:
provide at least one request data element for at least one request to the computer system;
assess at least one fraud potential indicator for the at least one request based on at least two of:
a) at least one comparison of the at least one request data element to data in a database;
b) at least one comparison of the at least one request data element to at least one fraud model; and
c) at least one business rule applied to the at least one request data element;
wherein the at least one fraud potential indicator comprises an estimate of a probability of fraud in a request.
43. The system of claim 42, wherein the at least one request comprises at least one of: a check; an insurance claim; and a loan.
44. The system of claim 42, wherein the computer program is further executable to assess a total fraud potential indicator of the at least one request from at least two fraud potential indicators.
45. The system of claim 42, wherein at least one comparison of the at least one request data element to the at least one fraud model comprises determining if the at least one request data element approximately matches the at least one fraud model.
46. The system of claim 42, wherein assessing at least one second fraud potential indicator comprises determining if the at least one request data element approximately matches at least a portion of a data element in a database.
47. The system of claim 42, wherein the computer program is further executable to refer the at least one request for review if at least one fraud potential indicator exceeds a threshold value.
48. A carrier medium comprising program instructions, wherein the program instructions are computer-executable to implement a method comprising:
providing at least one request data element for at least one request to a computer system;
assessing at least one fraud potential indicator for the at least one request based on at least two of:
a) at least one comparison of the at least one request data element to data in a database;
b) at least one comparison of the at least one request data element to at least one fraud model; and
c) at least one business rule applied to the at least one request data element;
wherein the at least one fraud potential indicator comprises an estimate of a probability of fraud in the at least one request.
49. The carrier medium of claim 48, wherein the at least one request comprises at least one of: a check; an insurance claim; and a loan.
50. The carrier medium of claim 48, further comprising assessing a total fraud potential indicator of at least one request from at least two fraud potential indicators.
51. The carrier medium of claim 48, wherein at least one comparison of the at least one request data element to the at least one fraud model comprises determining if the at least one request data element approximately matches the at least one fraud model.
52. The carrier medium of claim 48, wherein assessing at least one second fraud potential indicator comprises determining if the at least one request data element approximately matches at least a portion of a data element in a database.
53. The carrier medium of claim 48, further comprising referring the at least one request for further review if at least one fraud potential indicator exceeds a threshold value.
54. A method, comprising:
assessing at least one fraud potential indicator for a plurality of insurance claims using at least one fraud potential detection technique; and
defining a minimum referral fraud potential indicator such that a desired quantity of requests are referred.
55. The method of claim 54, further comprising modifying a minimum referral fraud potential indicator for at least two fraud potential detection techniques using at least two fraud potential indicators from at least one fraud potential detection technique to obtain a selected quantity of referrals for further review.
56. The method of claim 54, wherein the minimum referral fraud potential indicator comprises a fraud potential indicator that results in a referral of at least one request for further review.
57. The method of claim 54, wherein at least one fraud potential detection technique comprises predictive modeling.
58. The method of claim 54, wherein at least one fraud potential detection technique comprises predictive modeling, and wherein assessing a probability of fraud using predictive modeling comprises assessing at least one fraud potential indicator based on at least one comparison of at least one request data element to at least one fraud model.
59. The method of claim 54, wherein at least one fraud potential detection technique comprises identity searching.
60. The method of claim 54, wherein at least one fraud potential detection technique comprises identity searching of insurance data, and wherein assessing the probability of fraud using identity search of insurance data comprises assessing at least one fraud potential indicator based on at least one comparison of at least one request data element to additional insurance data.
61. The method of claim 54, wherein at least one fraud potential detection technique comprises assessing request data for fraud from at least one business rule.
62. A system configured to estimate liability, comprising:
a CPU; and
a memory coupled to the CPU, wherein the memory is configured to store at least one computer program executable by the CPU, and wherein at least one computer program is executable to:
assess fraud potential indicators for a plurality of requests using at least one fraud potential detection technique; and
establish a minimum referral fraud potential indicator such that a desired quantity of requests are referred.
63. The system of claim 62, wherein the computer program is further executable to modify a minimum referral fraud potential indicator for at least two fraud potential detection techniques using at least two fraud potential indicators from at least one fraud potential detection technique to obtain a selected quantity of referral of requests for further review.
64. A carrier medium comprising program instructions, wherein the program instructions are computer-executable to implement a method comprising:
assessing a fraud potential indicator for a plurality of requests using at least one fraud potential detection technique; and
establishing a minimum referral fraud potential indicator such that a desired quantity of requests are referred.
65. The carrier medium of claim 64, further comprising modifying a minimum referral fraud potential indicator for at least two fraud potential detection techniques using at least two fraud potential indicators from at least one fraud potential detection technique to obtain a selected quantity of referral of requests for further review.
66-157. (canceled)
US10/702,088 2003-11-05 2003-11-05 Systems and methods for assessing the potential for fraud in business transactions Abandoned US20050108063A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US10/702,088 US20050108063A1 (en) 2003-11-05 2003-11-05 Systems and methods for assessing the potential for fraud in business transactions
PCT/US2004/036794 WO2005048046A2 (en) 2003-11-05 2004-11-05 Systems and methods for assessing the potential for fraud in business transactions
US11/068,503 US7827045B2 (en) 2003-11-05 2005-02-28 Systems and methods for assessing the potential for fraud in business transactions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/702,088 US20050108063A1 (en) 2003-11-05 2003-11-05 Systems and methods for assessing the potential for fraud in business transactions

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/068,503 Continuation-In-Part US7827045B2 (en) 2003-11-05 2005-02-28 Systems and methods for assessing the potential for fraud in business transactions

Publications (1)

Publication Number Publication Date
US20050108063A1 true US20050108063A1 (en) 2005-05-19

Family

ID=34573322

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/702,088 Abandoned US20050108063A1 (en) 2003-11-05 2003-11-05 Systems and methods for assessing the potential for fraud in business transactions
US11/068,503 Active 2027-11-16 US7827045B2 (en) 2003-11-05 2005-02-28 Systems and methods for assessing the potential for fraud in business transactions

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11/068,503 Active 2027-11-16 US7827045B2 (en) 2003-11-05 2005-02-28 Systems and methods for assessing the potential for fraud in business transactions

Country Status (2)

Country Link
US (2) US20050108063A1 (en)
WO (1) WO2005048046A2 (en)

Cited By (114)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040215554A1 (en) * 2002-12-30 2004-10-28 Fannie Mae System and method for verifying loan data at delivery
US20050055249A1 (en) * 2003-09-04 2005-03-10 Jonathon Helitzer System for reducing the risk associated with an insured building structure through the incorporation of selected technologies
US20050097051A1 (en) * 2003-11-05 2005-05-05 Madill Robert P.Jr. Fraud potential indicator graphical interface
US20050108065A1 (en) * 2003-11-18 2005-05-19 Dorfstatter Walter A. Method and system of estimating vehicle damage
US20050276401A1 (en) * 2003-11-05 2005-12-15 Madill Robert P Jr Systems and methods for assessing the potential for fraud in business transactions
US20060004612A1 (en) * 2004-07-01 2006-01-05 Chewning Timothy W Systems and methods for configuring and processing insurance information
US20060149674A1 (en) * 2004-12-30 2006-07-06 Mike Cook System and method for identity-based fraud detection for transactions using a plurality of historical identity records
US20060200407A1 (en) * 2005-03-02 2006-09-07 Accenture Global Services Gmbh Advanced payment integrity
WO2006099674A1 (en) * 2005-03-24 2006-09-28 Accenture Global Services Gmbh Risk based data assessment
EP1830290A1 (en) * 2006-03-03 2007-09-05 Health Insurance Review Agency Method for electronic examination of medical fees
US7311248B1 (en) * 2004-08-12 2007-12-25 Prairie Systems, Inc. Method and system for automatically detecting fraudulent applications
US20080077451A1 (en) * 2006-09-22 2008-03-27 Hartford Fire Insurance Company System for synergistic data processing
US20080147448A1 (en) * 2006-12-19 2008-06-19 Hartford Fire Insurance Company System and method for predicting and responding to likelihood of volatility
US20080154651A1 (en) * 2006-12-22 2008-06-26 Hartford Fire Insurance Company System and method for utilizing interrelated computerized predictive models
US20080235062A1 (en) * 2006-12-29 2008-09-25 American International Group, Inc. Method and system for initially projecting an insurance company's net loss from a major loss event
US20080256523A1 (en) * 2007-04-12 2008-10-16 Nancy Grimaldi Computerized Data Warehousing
US7444331B1 (en) * 2005-03-02 2008-10-28 Symantec Corporation Detecting code injection attacks against databases
US7458508B1 (en) 2003-05-12 2008-12-02 Id Analytics, Inc. System and method for identity-based fraud detection
US20090043615A1 (en) * 2007-08-07 2009-02-12 Hartford Fire Insurance Company Systems and methods for predictive data analysis
WO2009073151A1 (en) * 2007-11-28 2009-06-11 Assurant, Inc. Automated claims processing system
US7562814B1 (en) 2003-05-12 2009-07-21 Id Analytics, Inc. System and method for identity-based fraud detection through graph anomaly detection
US20090210257A1 (en) * 2008-02-20 2009-08-20 Hartford Fire Insurance Company System and method for providing customized safety feedback
US20090222290A1 (en) * 2008-02-29 2009-09-03 Crowe Michael K Methods and Systems for Automated, Predictive Modeling of the Outcome of Benefits Claims
US7686214B1 (en) * 2003-05-12 2010-03-30 Id Analytics, Inc. System and method for identity-based fraud detection using a plurality of historical identity records
US20100174566A1 (en) * 2003-09-04 2010-07-08 Hartford Fire Insurance Company Systems and methods for analyzing sensor data
US20100185466A1 (en) * 2009-01-20 2010-07-22 Kenneth Paradis Systems and methods for tracking health-related spending for validation of disability benefits claims
US20100274720A1 (en) * 2009-04-28 2010-10-28 Mark Carlson Fraud and reputation protection using advanced authorization and rules engine
US20110054925A1 (en) * 2009-08-25 2011-03-03 Rayid Ghani Claims analytics engine
US20110077977A1 (en) * 2009-07-28 2011-03-31 Collins Dean Methods and systems for data mining using state reported worker's compensation data
US20110184766A1 (en) * 2010-01-25 2011-07-28 Hartford Fire Insurance Company Systems and methods for prospecting and rounding business insurance customers
US20110238593A1 (en) * 2010-03-23 2011-09-29 United Parcel Service Of America, Inc. Systems and Methods for Identifying Suspicious Orders
US8386377B1 (en) 2003-05-12 2013-02-26 Id Analytics, Inc. System and method for credit scoring using an identity network connectivity
US20130173309A1 (en) * 2010-12-01 2013-07-04 Cedars-Sinai Medical Center Privacy awareness tool
US20130226623A1 (en) * 2012-02-24 2013-08-29 Tata Consultancy Services Limited Insurance claims processing
WO2013159178A1 (en) * 2012-04-22 2013-10-31 Automated Benefits, Inc. Online claims submission and adjudication system
US8612262B1 (en) 2003-11-19 2013-12-17 Allstate Insurance Company Market relationship management
WO2014056101A1 (en) * 2012-10-09 2014-04-17 Communitylend Holdings Inc. Method for processing loan applications
US20140244528A1 (en) * 2013-02-22 2014-08-28 Palo Alto Research Center Incorporated Method and apparatus for combining multi-dimensional fraud measurements for anomaly detection
US20140303993A1 (en) * 2013-04-08 2014-10-09 Unisys Corporation Systems and methods for identifying fraud in transactions committed by a cohort of fraudsters
US8918891B2 (en) 2012-06-12 2014-12-23 Id Analytics, Inc. Identity manipulation detection system and method
US20150032482A1 (en) * 2013-07-29 2015-01-29 Independent Mitigation and Cleaning/Conservation Network, Inc. Claim summary and claim watch system and method
WO2015002630A3 (en) * 2012-07-24 2015-04-09 Deloitte Development Llc Fraud detection methods and systems
US9081975B2 (en) 2012-10-22 2015-07-14 Palantir Technologies, Inc. Sharing information between nexuses that use different classification schemes for information access control
US9100428B1 (en) 2014-01-03 2015-08-04 Palantir Technologies Inc. System and method for evaluating network threats
US20150235334A1 (en) * 2014-02-20 2015-08-20 Palantir Technologies Inc. Healthcare fraud sharing system
US9189492B2 (en) 2012-01-23 2015-11-17 Palatir Technoogies, Inc. Cross-ACL multi-master replication
US9330157B2 (en) 2006-11-20 2016-05-03 Palantir Technologies, Inc. Cross-ontology multi-master replication
US9367872B1 (en) 2014-12-22 2016-06-14 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive investigation of bad actor behavior based on automatic clustering of related data in various data structures
US20160171616A1 (en) * 2014-12-15 2016-06-16 Hartford Fire Insurance Company System to administer insurance knowledge management tool
US20160210829A1 (en) * 2013-09-06 2016-07-21 Nec Corporation Security system, security method, and non-transitory computer readable medium
US9418337B1 (en) 2015-07-21 2016-08-16 Palantir Technologies Inc. Systems and models for data analytics
US9454785B1 (en) 2015-07-30 2016-09-27 Palantir Technologies Inc. Systems and user interfaces for holistic, data-driven investigation of bad actor behavior based on clustering and scoring of related data
US9460471B2 (en) 2010-07-16 2016-10-04 Hartford Fire Insurance Company System and method for an automated validation system
US9501202B2 (en) 2013-03-15 2016-11-22 Palantir Technologies, Inc. Computer graphical user interface with genomic workflow
US9535974B1 (en) 2014-06-30 2017-01-03 Palantir Technologies Inc. Systems and methods for identifying key phrase clusters within documents
US9552615B2 (en) 2013-12-20 2017-01-24 Palantir Technologies Inc. Automated database analysis to detect malfeasance
US9558352B1 (en) 2014-11-06 2017-01-31 Palantir Technologies Inc. Malicious software detection in a computing system
US9569070B1 (en) 2013-11-11 2017-02-14 Palantir Technologies, Inc. Assisting in deconflicting concurrency conflicts
US9635046B2 (en) 2015-08-06 2017-04-25 Palantir Technologies Inc. Systems, methods, user interfaces, and computer-readable media for investigating potential malicious communications
US9817563B1 (en) 2014-12-29 2017-11-14 Palantir Technologies Inc. System and method of generating data points from one or more data stores of data items for chart creation and manipulation
US9866673B2 (en) 2013-12-18 2018-01-09 Medlegal Network, Inc. Methods and systems of managing accident communications over a network
US9875293B2 (en) 2014-07-03 2018-01-23 Palanter Technologies Inc. System and method for news events detection and visualization
US9898528B2 (en) 2014-12-22 2018-02-20 Palantir Technologies Inc. Concept indexing among database of documents using machine learning techniques
US9898509B2 (en) 2015-08-28 2018-02-20 Palantir Technologies Inc. Malicious activity detection system capable of efficiently processing data accessed from databases and generating alerts for display in interactive user interfaces
US9923925B2 (en) 2014-02-20 2018-03-20 Palantir Technologies Inc. Cyber security sharing and identification system
US9965937B2 (en) 2013-03-15 2018-05-08 Palantir Technologies Inc. External malware data item clustering and analysis
US20180130135A1 (en) * 2016-11-09 2018-05-10 Melissa Norwicke System and method for obtaining information about a deceased person's life insurance policy and submitting a claim thereunder
US9998485B2 (en) 2014-07-03 2018-06-12 Palantir Technologies, Inc. Network intrusion data item clustering and analysis
US10068002B1 (en) 2017-04-25 2018-09-04 Palantir Technologies Inc. Systems and methods for adaptive data replication
US10103953B1 (en) 2015-05-12 2018-10-16 Palantir Technologies Inc. Methods and systems for analyzing entity performance
US10162887B2 (en) 2014-06-30 2018-12-25 Palantir Technologies Inc. Systems and methods for key phrase characterization of documents
US10210576B2 (en) 2015-10-23 2019-02-19 Mastercard International Incorporated Processing payment card transaction records to determine insurance fraud risk
US10216801B2 (en) 2013-03-15 2019-02-26 Palantir Technologies Inc. Generating data clusters
US10235461B2 (en) 2017-05-02 2019-03-19 Palantir Technologies Inc. Automated assistance for generating relevant and valuable search results for an entity of interest
US10262053B2 (en) 2016-12-22 2019-04-16 Palantir Technologies Inc. Systems and methods for data replication synchronization
US10275778B1 (en) 2013-03-15 2019-04-30 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive investigation based on automatic malfeasance clustering of related data in various data structures
CN109829728A (en) * 2019-01-18 2019-05-31 南京邮电大学 A kind of system and method towards service security of calling a taxi
US10311081B2 (en) 2012-11-05 2019-06-04 Palantir Technologies Inc. System and method for sharing investigation results
US10318630B1 (en) 2016-11-21 2019-06-11 Palantir Technologies Inc. Analysis of large bodies of textual data
US10325224B1 (en) 2017-03-23 2019-06-18 Palantir Technologies Inc. Systems and methods for selecting machine learning training data
US10356032B2 (en) 2013-12-26 2019-07-16 Palantir Technologies Inc. System and method for detecting confidential information emails
US10362133B1 (en) 2014-12-22 2019-07-23 Palantir Technologies Inc. Communication data processing architecture
US10373260B1 (en) 2014-03-18 2019-08-06 Ccc Information Services Inc. Imaging processing system for identifying parts for repairing a vehicle
US10373262B1 (en) 2014-03-18 2019-08-06 Ccc Information Services Inc. Image processing system for vehicle damage
US10372879B2 (en) 2014-12-31 2019-08-06 Palantir Technologies Inc. Medical claims lead summary report generation
US10380696B1 (en) 2014-03-18 2019-08-13 Ccc Information Services Inc. Image processing system for vehicle damage
US10380196B2 (en) 2017-12-08 2019-08-13 Palantir Technologies Inc. Systems and methods for using linked documents
US10394871B2 (en) 2016-10-18 2019-08-27 Hartford Fire Insurance Company System to predict future performance characteristic for an electronic record
US10430062B2 (en) 2017-05-30 2019-10-01 Palantir Technologies Inc. Systems and methods for geo-fenced dynamic dissemination
US10482382B2 (en) 2017-05-09 2019-11-19 Palantir Technologies Inc. Systems and methods for reducing manufacturing failure rates
US10489391B1 (en) 2015-08-17 2019-11-26 Palantir Technologies Inc. Systems and methods for grouping and enriching data items accessed from one or more databases for presentation in a user interface
US10521857B1 (en) 2003-05-12 2019-12-31 Symantec Corporation System and method for identity-based fraud detection
US20200035077A1 (en) * 2017-03-15 2020-01-30 Nec Corporation Information processing apparatus, control method, and program
US10552994B2 (en) 2014-12-22 2020-02-04 Palantir Technologies Inc. Systems and interactive user interfaces for dynamic retrieval, analysis, and triage of data items
US10572496B1 (en) 2014-07-03 2020-02-25 Palantir Technologies Inc. Distributed workflow system and database with access controls for city resiliency
US10572487B1 (en) 2015-10-30 2020-02-25 Palantir Technologies Inc. Periodic database search manager for multiple data sources
US10579647B1 (en) 2013-12-16 2020-03-03 Palantir Technologies Inc. Methods and systems for analyzing entity performance
US10606866B1 (en) 2017-03-30 2020-03-31 Palantir Technologies Inc. Framework for exposing network activities
US10621198B1 (en) 2015-12-30 2020-04-14 Palantir Technologies Inc. System and method for secure database replication
US10620618B2 (en) 2016-12-20 2020-04-14 Palantir Technologies Inc. Systems and methods for determining relationships between defects
US10628834B1 (en) 2015-06-16 2020-04-21 Palantir Technologies Inc. Fraud lead detection system for efficiently processing database-stored data and automatically generating natural language explanatory information of system results for display in interactive user interfaces
US10628002B1 (en) 2017-07-10 2020-04-21 Palantir Technologies Inc. Integrated data authentication system with an interactive user interface
US10719527B2 (en) 2013-10-18 2020-07-21 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive simultaneous querying of multiple data stores
US10762102B2 (en) 2013-06-20 2020-09-01 Palantir Technologies Inc. System and method for incremental replication
US10853454B2 (en) 2014-03-21 2020-12-01 Palantir Technologies Inc. Provider portal
US10915542B1 (en) 2017-12-19 2021-02-09 Palantir Technologies Inc. Contextual modification of data sharing constraints in a distributed database system that uses a multi-master replication scheme
USRE48589E1 (en) 2010-07-15 2021-06-08 Palantir Technologies Inc. Sharing and deconflicting data changes in a multimaster database system
US11030494B1 (en) 2017-06-15 2021-06-08 Palantir Technologies Inc. Systems and methods for managing data spills
US11119630B1 (en) 2018-06-19 2021-09-14 Palantir Technologies Inc. Artificial intelligence assisted evaluations and user interface for same
US11210349B1 (en) 2018-08-02 2021-12-28 Palantir Technologies Inc. Multi-database document search system architecture
US11302426B1 (en) 2015-01-02 2022-04-12 Palantir Technologies Inc. Unified data interface and system
US11373752B2 (en) 2016-12-22 2022-06-28 Palantir Technologies Inc. Detection of misuse of a benefit system
US20230056462A1 (en) * 2021-08-19 2023-02-23 Marc R. Deschenaux Cascading initial public offerings or special purpose acquisitions companies for corporate capitalization
US11594334B2 (en) * 2020-04-15 2023-02-28 Hartford Fire Insurance Company System and method providing risk relationship transaction automation in accordance with medical condition code

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7668769B2 (en) * 2005-10-04 2010-02-23 Basepoint Analytics, LLC System and method of detecting fraud
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
US20080235186A1 (en) * 2007-03-23 2008-09-25 Antti Laurila Lawful Interception of Search Functionalities
US20100094664A1 (en) * 2007-04-20 2010-04-15 Carfax, Inc. Insurance claims and rate evasion fraud system based upon vehicle history
US20080312969A1 (en) * 2007-04-20 2008-12-18 Richard Raines System and method for insurance underwriting and rating
US20090099884A1 (en) * 2007-10-15 2009-04-16 Mci Communications Services, Inc. Method and system for detecting fraud based on financial records
US8799122B1 (en) * 2008-03-31 2014-08-05 Intuit Inc. Method and system for user contributed aggregated fraud identification
US9378527B2 (en) * 2008-04-08 2016-06-28 Hartford Fire Insurance Company Computer system for applying predictive model to determine and indeterminate data
US9256904B1 (en) * 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US7925559B2 (en) * 2008-08-22 2011-04-12 Hartford Fire Insurance Company Computer system for applying proactive referral model to long term disability claims
US20110015948A1 (en) * 2009-07-20 2011-01-20 Jonathan Kaleb Adams Computer system for analyzing claims files to identify premium fraud
US9171306B1 (en) 2010-03-29 2015-10-27 Bank Of America Corporation Risk-based transaction authentication
US20130085769A1 (en) * 2010-03-31 2013-04-04 Risk Management Solutions Llc Characterizing healthcare provider, claim, beneficiary and healthcare merchant normal behavior using non-parametric statistical outlier detection scoring techniques
US20120173289A1 (en) * 2010-09-16 2012-07-05 Thomson Reuters (Sientific) Llc System and method for detecting and identifying patterns in insurance claims
US9947050B1 (en) 2011-03-21 2018-04-17 Allstate Insurance Company Claims adjuster allocation
US10372878B2 (en) 2011-06-30 2019-08-06 Verizon Patent And Licensing Inc. Secure communications
US10509890B2 (en) 2011-06-30 2019-12-17 Verizon Patent And Licensing Inc. Predictive modeling processes for healthcare fraud detection
US10467379B2 (en) 2011-06-30 2019-11-05 Verizon Patent And Licensing Inc. Near real-time detection of information
US20130006656A1 (en) * 2011-06-30 2013-01-03 Verizon Patent And Licensing Inc. Case management of healthcare fraud detection information
US8856923B1 (en) * 2012-06-29 2014-10-07 Emc Corporation Similarity-based fraud detection in adaptive authentication systems
US9002719B2 (en) 2012-10-08 2015-04-07 State Farm Mutual Automobile Insurance Company Device and method for building claim assessment
US9082015B2 (en) 2013-03-15 2015-07-14 State Farm Mutual Automobile Insurance Company Automatic building assessment
US8872818B2 (en) 2013-03-15 2014-10-28 State Farm Mutual Automobile Insurance Company Methods and systems for capturing the condition of a physical structure
US8756085B1 (en) 2013-03-15 2014-06-17 State Farm Mutual Automobile Insurance Company Systems and methods for assessing property damage
US8818572B1 (en) 2013-03-15 2014-08-26 State Farm Mutual Automobile Insurance Company System and method for controlling a remote aerial device for up-close inspection
US10269074B1 (en) 2013-10-23 2019-04-23 Allstate Insurance Company Communication schemes for property claims adjustments
US9824397B1 (en) 2013-10-23 2017-11-21 Allstate Insurance Company Creating a scene for property claims adjustment
US10552911B1 (en) * 2014-01-10 2020-02-04 United Services Automobile Association (Usaa) Determining status of building modifications using informatics sensor data
US11176475B1 (en) 2014-03-11 2021-11-16 Applied Underwriters, Inc. Artificial intelligence system for training a classifier
US11809434B1 (en) 2014-03-11 2023-11-07 Applied Underwriters, Inc. Semantic analysis system for ranking search results
US10846295B1 (en) * 2019-08-08 2020-11-24 Applied Underwriters, Inc. Semantic analysis system for ranking search results
US9361735B1 (en) 2014-07-11 2016-06-07 State Farm Mutual Automobile Insurance Company Method and system of using spatial sensors on vehicle frame to determine crash information
US9509705B2 (en) * 2014-08-07 2016-11-29 Wells Fargo Bank, N.A. Automated secondary linking for fraud detection systems
US10726489B1 (en) * 2015-03-26 2020-07-28 Guidewire Software, Inc. Signals-based data syndication and collaboration
WO2016210122A1 (en) * 2015-06-24 2016-12-29 IGATE Global Solutions Ltd. Insurance fraud detection and prevention system
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US10176526B2 (en) * 2015-11-30 2019-01-08 Hartford Fire Insurance Company Processing system for data elements received via source inputs
US10176527B1 (en) 2016-04-27 2019-01-08 State Farm Mutual Automobile Insurance Company Providing shade for optical detection of structural features
US11017477B1 (en) * 2016-09-07 2021-05-25 United Services Automobile Association (Usaa) Digital imagery, audio, and meta-data
US11451043B1 (en) 2016-10-27 2022-09-20 State Farm Mutual Automobile Insurance Company Systems and methods for utilizing electricity monitoring devices to mitigate or prevent structural damage
US11227001B2 (en) 2017-01-31 2022-01-18 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
CN107657536B (en) * 2017-02-20 2018-07-31 平安科技(深圳)有限公司 The recognition methods of social security fraud and device
US20210264527A1 (en) 2017-05-02 2021-08-26 State Farm Mutual Automobile Insurance Company Distributed Ledger System for Managing Smart Home Data
CN107230154A (en) * 2017-05-22 2017-10-03 中国平安人寿保险股份有限公司 The recognition methods of life insurance Claims Resolution case with clique's risk of fraud and device
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
US11227287B2 (en) 2018-06-28 2022-01-18 International Business Machines Corporation Collaborative analytics for fraud detection through a shared public ledger
US11354669B2 (en) 2018-06-28 2022-06-07 International Business Machines Corporation Collaborative analytics for fraud detection through a shared public ledger
US11257018B2 (en) * 2018-12-24 2022-02-22 Hartford Fire Insurance Company Interactive user interface for insurance claim handlers including identifying insurance claim risks and health scores
EP3866087A1 (en) 2020-02-12 2021-08-18 KBC Groep NV Method, use thereoff, computer program product and system for fraud detection
US11915320B2 (en) 2021-10-13 2024-02-27 Assured Insurance Technologies, Inc. Corroborative claim view interface
US20230113815A1 (en) * 2021-10-13 2023-04-13 Assured Insurance Technologies, Inc. Predictive fraud detection system

Citations (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US1688498A (en) * 1926-09-13 1928-10-23 Jacobsen Karl Oscar Fredrick Swimming shoe
US2980926A (en) * 1958-09-05 1961-04-25 Stanley Axelrod Fin shoe
US3178738A (en) * 1961-11-16 1965-04-20 Everett A Brunner Convertible swim fin
US4599071A (en) * 1984-11-19 1986-07-08 Juang Ruey T Adjustable beach-shoes
US5292272A (en) * 1993-06-28 1994-03-08 Grim Roger W Dual mode swim fin
US5746631A (en) * 1996-01-11 1998-05-05 Mccarthy; Peter T. High efficiency hydrofoil and swim fin designs
US5924902A (en) * 1998-01-06 1999-07-20 Hollywood Hopefuls Production, Inc. Amphibious swimming and walking shoe
US6155898A (en) * 1999-04-16 2000-12-05 Hollywood Hopeful Productions L.L.C. Convertible amphibious shoes for swimming and walking
US6253186B1 (en) * 1996-08-14 2001-06-26 Blue Cross Blue Shield Of South Carolina Method and apparatus for detecting fraud
US20010027388A1 (en) * 1999-12-03 2001-10-04 Anthony Beverina Method and apparatus for risk management
US20020002475A1 (en) * 2000-04-13 2002-01-03 Joel Freedman Automated insurance system and method
US20020049619A1 (en) * 2000-10-02 2002-04-25 Steven Wahlbin Computerized method and system of identifying a credible witness statement relating to an accident
US20020091550A1 (en) * 2000-06-29 2002-07-11 White Mitchell Franklin System and method for real-time rating, underwriting and policy issuance
US20020088140A1 (en) * 1970-03-10 2002-07-11 Jui-Te Wang Water drainable sole for footwear
US6540574B2 (en) * 2000-09-07 2003-04-01 Hideya Hashizume Foldable diving flippers
US20030069820A1 (en) * 2000-03-24 2003-04-10 Amway Corporation System and method for detecting fraudulent transactions
US20030093672A1 (en) * 2001-06-29 2003-05-15 Bruce Cichowlas System for and methods of administration of access control to numerous resources and objects
US20030191703A1 (en) * 2002-02-01 2003-10-09 Ubs Painewebber Inc. Method and system for providing interested party access to aggregated accounts information
US20040003347A1 (en) * 2002-06-28 2004-01-01 Ubs Painewebber Inc. System and method for providing on-line services for multiple entities
US20040044895A1 (en) * 2002-08-27 2004-03-04 Reasons John D. Connected support entitlement system and method of operation
US20040049409A1 (en) * 2002-09-09 2004-03-11 Stefan Wahlbin Computerized method and system for determining breach of duty in premises liability for an accident
US20040054557A1 (en) * 2002-09-09 2004-03-18 Stefan Wahlbin Computerized method and system for estimating premises liability for an accident
US20040054559A1 (en) * 2002-09-09 2004-03-18 Stefan Wahlbin Computerized method and system for determining the contribution of defenses to premises liability for an accident
US20040054556A1 (en) * 2002-09-09 2004-03-18 Stephan Wahlbin Computerized method and system for determining causation in premises liability for an accident
US20040054558A1 (en) * 2002-09-09 2004-03-18 Stefan Wahlbin Computerized method and system for determining claimant status in premises liability for an accident
US20040083140A1 (en) * 2002-10-15 2004-04-29 Custom Direct, Inc. System and method for providing recovery for victims of check fraud
US20040088199A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Method of forming a business rule
US20040088198A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Method of modifying a business rule while tracking the modifications
US20040088196A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Graphical display of business rules
US20040088195A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Method of modifying a business rule
US20040102984A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating liability using recorded vehicle data
US20040103006A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating an effect on liability using a comparison of the actual speed of vehicles with a specified speed
US20040103005A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating monetary damages due to injuries in an accident from liability estimated using a computer system
US20040103007A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating an effect on liability using claim data accessed from claim reporting software
US20040103010A1 (en) * 2002-11-27 2004-05-27 Stephan Wahlbin Computerized method and system for estimating an effect on liability of the speed of vehicles in an accident and time and distance traveled by the vehicles
US20040103004A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating an effect on liability using a comparison of the actual speed of a vehicle in an accident and time and distance traveled by the vehicles in a merging vehicle accident
US20040103008A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating liability for an accident from an investigation of the accident
US20040102985A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating an effect on liability based on the stopping distance of vehicles
US20040103009A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for creating pre-configured claim reports including liability in an accident estimated using a computer system
US20040111301A1 (en) * 2002-11-27 2004-06-10 Stefan Wahlbin Computerized method and system for estimating liability for an accident using dynamic generation of questions
US20040215494A1 (en) * 2003-04-24 2004-10-28 Wahlbin Stefan L. Method and system for determining monetary amounts in an insurance processing system
US6826536B1 (en) * 2000-07-22 2004-11-30 Bert Forman Health care billing monitor system for detecting health care provider fraud
US20050043961A1 (en) * 2002-09-30 2005-02-24 Michael Torres System and method for identification, detection and investigation of maleficent acts
US20050060184A1 (en) * 2003-09-02 2005-03-17 Stefan Wahlbin Graphical input display in an insurance processing system
US20050060205A1 (en) * 2003-09-02 2005-03-17 Woods Randall K. Systems and methods for a graphical input display in an insurance processing system
US20050097051A1 (en) * 2003-11-05 2005-05-05 Madill Robert P.Jr. Fraud potential indicator graphical interface
US20050192850A1 (en) * 2004-03-01 2005-09-01 Lorenz Scott K. Systems and methods for using data structure language in web services
US20050276401A1 (en) * 2003-11-05 2005-12-15 Madill Robert P Jr Systems and methods for assessing the potential for fraud in business transactions
US20060047540A1 (en) * 2004-09-01 2006-03-02 Hutten Bruce V System and method for underwriting
US7024418B1 (en) * 2000-06-23 2006-04-04 Computer Sciences Corporation Relevance calculation for a reference system in an insurance claims processing system
US7095426B1 (en) * 2000-06-23 2006-08-22 Computer Sciences Corporation Graphical user interface with a hide/show feature for a reference system in an insurance claims processing system
US7159336B2 (en) * 2002-12-09 2007-01-09 Aquaped, Llc Amphibious shoe
US7263492B1 (en) * 2002-02-15 2007-08-28 Fair Isaac Corporation Sequencing models of healthcare related states
US7398218B1 (en) * 1999-08-27 2008-07-08 Accenture Llp Insurance pattern analysis
US20080172904A1 (en) * 2007-01-22 2008-07-24 David Pelsue Interchangeable midsole system for footwear

Family Cites Families (133)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US625186A (en) * 1899-05-16 Magazine heating-stove
DE3405757A1 (en) 1983-02-26 1984-10-04 Edmund 7016 Gerlingen Zottnik ACCIDENT RECORDER
US4606002A (en) * 1983-05-02 1986-08-12 Wang Laboratories, Inc. B-tree structured data base using sparse array bit maps to store inverted lists
US4656585A (en) 1984-02-03 1987-04-07 Sundstrand Data Control Inc. Aircraft flight data recorder data acquisition system
US5099422A (en) * 1986-04-10 1992-03-24 Datavision Technologies Corporation (Formerly Excnet Corporation) Compiling system and method of producing individually customized recording media
US4878167A (en) * 1986-06-30 1989-10-31 International Business Machines Corporation Method for managing reuse of hard log space by mapping log data during state changes and discarding the log data
EP0280773A3 (en) 1987-01-09 1989-12-20 International Business Machines Corporation Method for recovery enhancement in a transaction-oriented data processing system
JP2718031B2 (en) * 1987-07-17 1998-02-25 株式会社日立製作所 History information acquisition method
US4931793A (en) 1988-07-01 1990-06-05 Solitron Devices, Inc. System for providing a warning when vehicles approach a common collision point
US5434963A (en) * 1988-09-03 1995-07-18 Hitachi, Ltd. Method and system of help-information control method and system
US5253164A (en) * 1988-09-30 1993-10-12 Hpr, Inc. System and method for detecting fraudulent medical claims via examination of service codes
JPH03130874A (en) * 1989-10-17 1991-06-04 Fujitsu Ltd Retrieval processing system for relational data base
US5233513A (en) * 1989-12-28 1993-08-03 Doyle William P Business modeling, software engineering and prototyping method and apparatus
US5191522A (en) * 1990-01-18 1993-03-02 Itt Corporation Integrated group insurance information processing and reporting system based upon an enterprise-wide data structure
US5257366A (en) * 1990-03-27 1993-10-26 International Business Machines Corporation Query language execution on heterogeneous database servers using a bind-file bridge between application and database languages
US5201044A (en) * 1990-04-16 1993-04-06 International Business Machines Corporation Data processing method for file status recovery includes providing a log file of atomic transactions that may span both volatile and non volatile memory
EP0465018B1 (en) 1990-06-29 1997-05-14 Oracle Corporation Method and apparatus for optimizing undo log usage
CA2025201C (en) 1990-09-12 1992-09-01 Dominic Carbone Electronic accident estimating system
US5615309A (en) * 1990-11-13 1997-03-25 International Business Machines Corporation Inferencing production control computer system
US5180309A (en) 1990-12-04 1993-01-19 United States Of America As Represented By The Secretary Of The Navy Automated answer evaluation and scoring system and method
US5504674A (en) * 1991-02-19 1996-04-02 Ccc Information Services, Inc. Insurance claims estimate, text, and graphics network and method
US5386566A (en) * 1991-03-20 1995-01-31 Hitachi, Ltd. Inter-processor communication method for transmitting data and processor dependent information predetermined for a receiving process of another processor
US5566330A (en) * 1991-08-20 1996-10-15 Powersoft Corporation Method for forming a reusable and modifiable database interface object
US5421011A (en) * 1991-12-20 1995-05-30 International Business Machines Corporation Method and system for access and accounting control in a data processing system by using a single resource account for a user or a group of users
US6003033A (en) 1992-02-28 1999-12-14 International Business Machines Corporation System and method for describing and creating a user defined arbitrary data structure corresponding to a tree in a computer memory
US5732397A (en) * 1992-03-16 1998-03-24 Lincoln National Risk Management, Inc. Automated decision-making arrangement
US5317503A (en) 1992-03-27 1994-05-31 Isao Inoue Apparatus for calculating a repair cost of a damaged car
JP2758311B2 (en) * 1992-05-28 1998-05-28 富士通株式会社 Log file control method in complex system
CA2100893A1 (en) 1992-08-06 1994-02-07 Michael E. Stickney Interactive computerized witness interrogation recording tool
US5819226A (en) 1992-09-08 1998-10-06 Hnc Software Inc. Fraud detection using predictive modeling
GB2273183A (en) 1992-12-04 1994-06-08 Ibm Replicated distributed databases.
US5550976A (en) * 1992-12-08 1996-08-27 Sun Hydraulics Corporation Decentralized distributed asynchronous object oriented system and method for electronic data management, storage, and communication
US5394555A (en) * 1992-12-23 1995-02-28 Bull Hn Information Systems Inc. Multi-node cluster computer system incorporating an external coherency unit at each node to insure integrity of information stored in a shared, distributed memory
US5794229A (en) * 1993-04-16 1998-08-11 Sybase, Inc. Database system with methodology for storing a database table by vertically partitioning all columns of the table
JP2521024B2 (en) 1993-04-20 1996-07-31 淡路フェリーボート株式会社 Traffic accident data recorder and traffic accident reproduction system
US5950169A (en) * 1993-05-19 1999-09-07 Ccc Information Services, Inc. System and method for managing insurance claim processing
US5689706A (en) * 1993-06-18 1997-11-18 Lucent Technologies Inc. Distributed systems with replicated files
US5940811A (en) * 1993-08-27 1999-08-17 Affinity Technology Group, Inc. Closed loop financial transaction method and apparatus
US5864679A (en) * 1993-09-06 1999-01-26 Kabushiki Kaisha Toshiba Transaction routing in a multiple processor system using an extracted transaction feature parameter and transaction historical data
US5499330A (en) * 1993-09-17 1996-03-12 Digital Equipment Corp. Document display system for organizing and displaying documents as screen objects organized along strand paths
FR2712101B1 (en) * 1993-11-05 1996-01-05 Socs Holding System for controlling a relational database according to an object-oriented access logic limiting the number of accesses to the database, and corresponding method.
US5524489A (en) 1994-02-18 1996-06-11 Plan B Enterprises, Inc. Floating mass accelerometer
US5523942A (en) * 1994-03-31 1996-06-04 New England Mutual Life Insurance Company Design grid for inputting insurance and investment product information in a computer system
US5619693A (en) * 1994-05-02 1997-04-08 Tandem Computers Incorporated Method for sorting and storing data employing dynamic sort tree reconfiguration in volatile memory
US5434994A (en) * 1994-05-23 1995-07-18 International Business Machines Corporation System and method for maintaining replicated data coherency in a data processing system
US5483442A (en) 1994-07-12 1996-01-09 Investigator Marketing Inc. Accident documentation system
US5577239A (en) * 1994-08-10 1996-11-19 Moore; Jeffrey Chemical structure storage, searching and retrieval system
US5768506A (en) * 1994-09-30 1998-06-16 Hewlett-Packard Co. Method and apparatus for distributed workflow building blocks of process definition, initialization and execution
US5745901A (en) * 1994-11-08 1998-04-28 Kodak Limited Workflow initiated by graphical symbols
US5839112A (en) * 1994-12-28 1998-11-17 Automatic Data Processing Method and apparatus for displaying and selecting vehicle parts
US5721915A (en) * 1994-12-30 1998-02-24 International Business Machines Corporation Interaction between application of a log and maintenance of a table that maps record identifiers during online reorganization of a database
US5798949A (en) 1995-01-13 1998-08-25 Kaub; Alan Richard Traffic safety prediction model
US6092049A (en) * 1995-06-30 2000-07-18 Microsoft Corporation Method and apparatus for efficiently recommending items using automated collaborative filtering and feature-guided automated collaborative filtering
US5742820A (en) * 1995-07-06 1998-04-21 Novell, Inc. Mechanism for efficiently synchronizing information over a network
US5870725A (en) * 1995-08-11 1999-02-09 Wachovia Corporation High volume financial image media creation and display system and method
US5870746A (en) * 1995-10-12 1999-02-09 Ncr Corporation System and method for segmenting a database based upon data attributes
US5870711A (en) * 1995-12-11 1999-02-09 Sabre Properties, Inc. Method and system for management of cargo claims
US5768505A (en) * 1995-12-19 1998-06-16 International Business Machines Corporation Object oriented mail server framework mechanism
US5710915A (en) * 1995-12-21 1998-01-20 Electronic Data Systems Corporation Method for accelerating access to a database clustered partitioning
US5797134A (en) * 1996-01-29 1998-08-18 Progressive Casualty Insurance Company Motor vehicle monitoring system for determining a cost of insurance
GB2311188B (en) * 1996-03-11 2000-02-16 Mitel Corp Call routing in a communication system
US5991733A (en) * 1996-03-22 1999-11-23 Hartford Fire Insurance Company Method and computerized system for managing insurance receivable accounts
JP3451415B2 (en) * 1996-03-29 2003-09-29 富士通株式会社 How to synchronize a database in a network management system
US5862500A (en) 1996-04-16 1999-01-19 Tera Tech Incorporated Apparatus and method for recording motor vehicle travel information
US5930759A (en) * 1996-04-30 1999-07-27 Symbol Technologies, Inc. Method and system for processing health care electronic data transactions
US5881379A (en) * 1996-05-20 1999-03-09 International Business Machines Corporation System, method, and program for using duplicated direct pointer sets in keyed database records to enhance data recoverability without logging
CA2254944A1 (en) * 1996-05-23 1997-11-27 Citibank, N.A. Global financial services integration system and process
US5987434A (en) * 1996-06-10 1999-11-16 Libman; Richard Marc Apparatus and method for transacting marketing and sales of financial products
US6557752B1 (en) * 1996-06-12 2003-05-06 Q-International, Inc. Smart card for recording identification, and operational, service and maintenance transactions
US5815093A (en) 1996-07-26 1998-09-29 Lextron Systems, Inc. Computerized vehicle log
US5940809A (en) * 1996-08-19 1999-08-17 Merrill Lynch & Co. Securities brokerage-asset management system
US6104874A (en) * 1996-10-15 2000-08-15 International Business Machines Corporation Object oriented framework mechanism for order processing including pre-defined extensible classes for defining an order processing environment
US5933816A (en) * 1996-10-31 1999-08-03 Citicorp Development Center, Inc. System and method for delivering financial services
US5937189A (en) * 1996-11-12 1999-08-10 International Business Machines Corporation Object oriented framework mechanism for determining configuration relations
US5867494A (en) * 1996-11-18 1999-02-02 Mci Communication Corporation System, method and article of manufacture with integrated video conferencing billing in a communication system architecture
US5892905A (en) * 1996-12-23 1999-04-06 International Business Machines Corporation Computer apparatus and method for providing a common user interface for software applications accessed via the world-wide web
US5877707A (en) 1997-01-17 1999-03-02 Kowalick; Thomas M. GPS based seat belt monitoring system & method for using same
US5873066A (en) * 1997-02-10 1999-02-16 Insurance Company Of North America System for electronically managing and documenting the underwriting of an excess casualty insurance policy
US5717391A (en) 1997-02-13 1998-02-10 Rodriguez; Otto M. Traffic event recording method and apparatus
US5907848A (en) * 1997-03-14 1999-05-25 Lakeview Technology, Inc. Method and system for defining transactions from a database log
US6064983A (en) * 1997-03-21 2000-05-16 Koehler Consulting, Inc. System for performing tax computations
US5956687A (en) 1997-04-04 1999-09-21 Wamsley; Vaughn A. Personal injury claim management system
US6173284B1 (en) 1997-05-20 2001-01-09 University Of Charlotte City Of Charlotte Systems, methods and computer program products for automatically monitoring police records for a crime profile
US5995971A (en) * 1997-09-18 1999-11-30 Micdrosoft Corporation Apparatus and accompanying methods, using a trie-indexed hierarchy forest, for storing wildcard-based patterns and, given an input key, retrieving, from the forest, a stored pattern that is identical to or more general than the key
US6038393A (en) * 1997-09-22 2000-03-14 Unisys Corp. Software development tool to accept object modeling data from a wide variety of other vendors and filter the format into a format that is able to be stored in OMG compliant UML representation
US6076026A (en) 1997-09-30 2000-06-13 Motorola, Inc. Method and device for vehicle control events data recording and securing
US6442533B1 (en) * 1997-10-29 2002-08-27 William H. Hinkle Multi-processing financial transaction processing system
US5991756A (en) * 1997-11-03 1999-11-23 Yahoo, Inc. Information retrieval from hierarchical compound documents
US6115690A (en) * 1997-12-22 2000-09-05 Wong; Charles Integrated business-to-business Web commerce and business automation system
EP0926608B1 (en) 1997-12-24 2004-03-10 Nortel Networks Limited Distributed persistent storage for intermittently connected clients
US6202070B1 (en) * 1997-12-31 2001-03-13 Compaq Computer Corporation Computer manufacturing system architecture with enhanced software distribution functions
US6470303B2 (en) 1998-02-04 2002-10-22 Injury Sciences Llc System and method for acquiring and quantifying vehicular damage information
US6308187B1 (en) 1998-02-09 2001-10-23 International Business Machines Corporation Computer system and method for abstracting and accessing a chronologically-arranged collection of information
US6393386B1 (en) * 1998-03-26 2002-05-21 Visual Networks Technologies, Inc. Dynamic modeling of complex networks and prediction of impacts of faults therein
WO1999056495A1 (en) * 1998-04-27 1999-11-04 Aurora Wireless Technologies, Ltd. System and method for detecting high credit risk customers
US6662164B1 (en) 1998-05-19 2003-12-09 Trilogy Development Group, Inc. Method and apparatus for determining commission
US6134582A (en) * 1998-05-26 2000-10-17 Microsoft Corporation System and method for managing electronic mail messages using a client-based database
US6112209A (en) * 1998-06-17 2000-08-29 Gusack; Mark David Associative database model for electronic-based informational assemblies
US6272482B1 (en) * 1998-08-14 2001-08-07 International Business Machines Corporation Managing business rules using jurisdictions
US6163770A (en) 1998-08-25 2000-12-19 Financial Growth Resources, Inc. Computer apparatus and method for generating documentation using a computed value for a claims cost affected by at least one concurrent, different insurance policy for the same insured
US6236975B1 (en) * 1998-09-29 2001-05-22 Ignite Sales, Inc. System and method for profiling customers for targeted marketing
US6336096B1 (en) * 1998-10-09 2002-01-01 Donald V. Jernberg System and method for evaluating liability
US6141611A (en) 1998-12-01 2000-10-31 John J. Mackey Mobile vehicle accident data system
JP2000163344A (en) * 1998-11-27 2000-06-16 Nec Corp Data base recovery system for network management system
US6473740B2 (en) * 1998-11-29 2002-10-29 Qpass, Inc. Electronic commerce using a transaction network
US6532459B1 (en) 1998-12-15 2003-03-11 Berson Research Corp. System for finding, identifying, tracking, and correcting personal information in diverse databases
US6397334B1 (en) 1998-12-17 2002-05-28 International Business Machines Corporation Method and system for authenticating objects and object data
US6341287B1 (en) * 1998-12-18 2002-01-22 Alternative Systems, Inc. Integrated change management unit
US6223125B1 (en) 1999-02-05 2001-04-24 Brett O. Hall Collision avoidance system
US6289339B1 (en) * 1999-02-19 2001-09-11 Nortel Networks Limited Method and apparatus for filtering a notification message from a database
US6185490B1 (en) 1999-03-15 2001-02-06 Thomas W. Ferguson Vehicle crash data recorder
US6938029B1 (en) 1999-03-31 2005-08-30 Allan Y. Tien System and method for indexing recordings of observed and assessed phenomena using pre-defined measurement items
US6570609B1 (en) 1999-04-22 2003-05-27 Troy A. Heien Method and apparatus for monitoring operation of a motor vehicle
US7013284B2 (en) 1999-05-04 2006-03-14 Accenture Llp Component based interface to handle tasks during claim processing
US6952741B1 (en) 1999-06-30 2005-10-04 Computer Sciences Corporation System and method for synchronizing copies of data in a computer system
US6446086B1 (en) * 1999-06-30 2002-09-03 Computer Sciences Corporation System and method for logging transaction records in a computer system
US6970844B1 (en) 1999-08-27 2005-11-29 Computer Sciences Corporation Flow designer for establishing and maintaining assignment and strategy process maps
US6961708B1 (en) 1999-08-27 2005-11-01 Computer Sciences Corporation External interface for requesting data from remote systems in a generic fashion
US6363360B1 (en) 1999-09-27 2002-03-26 Martin P. Madden System and method for analyzing and originating a contractual option arrangement for a bank deposits liabilities base
US6925468B1 (en) 1999-10-29 2005-08-02 Computer Sciences Corporation Configuring systems for generating business transaction reports using processing relationships among entities of an organization
US6246933B1 (en) 1999-11-04 2001-06-12 BAGUé ADOLFO VAEZA Traffic accident data recorder and traffic accident reproduction system and method
US6351893B1 (en) 1999-12-07 2002-03-05 Garrick St. Pierre Self squaring accident diagramming template
US6408304B1 (en) 1999-12-17 2002-06-18 International Business Machines Corporation Method and apparatus for implementing an object oriented police patrol multifunction system
US6493650B1 (en) 2000-01-27 2002-12-10 Optimus Corporation Device for automatic documentation of crash scenes
US7953615B2 (en) * 2000-04-03 2011-05-31 Mitchell International, Inc. System and method of administering, tracking and managing of claims processing
US6832205B1 (en) 2000-06-30 2004-12-14 General Electric Company System and method for automatically predicting the timing and costs of service events in a life cycle of a product
US6736250B2 (en) * 2001-09-28 2004-05-18 Harold E. Mattice Method and apparatus for fraud detection
US20030172367A1 (en) * 2002-01-24 2003-09-11 Robert Kannenberg Method of modifying software via a network
US7631299B2 (en) * 2002-01-24 2009-12-08 Computer Sciences Corporation System for modifying software using reusable software components
US20030158759A1 (en) * 2002-01-24 2003-08-21 Robert Kannenberg Method of modifying software by defining business rules
DE60311904D1 (en) * 2002-03-15 2007-04-05 Computer Sciences Corp Methods and apparatus for analyzing writing in documents
US20040085357A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Method of generating a graphical display of a business rule and associated business rule elements
US7689442B2 (en) * 2002-10-31 2010-03-30 Computer Science Corporation Method of generating a graphical display of a business rule with a translation

Patent Citations (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US1688498A (en) * 1926-09-13 1928-10-23 Jacobsen Karl Oscar Fredrick Swimming shoe
US2980926A (en) * 1958-09-05 1961-04-25 Stanley Axelrod Fin shoe
US3178738A (en) * 1961-11-16 1965-04-20 Everett A Brunner Convertible swim fin
US20020088140A1 (en) * 1970-03-10 2002-07-11 Jui-Te Wang Water drainable sole for footwear
US4599071A (en) * 1984-11-19 1986-07-08 Juang Ruey T Adjustable beach-shoes
US5292272A (en) * 1993-06-28 1994-03-08 Grim Roger W Dual mode swim fin
US5746631A (en) * 1996-01-11 1998-05-05 Mccarthy; Peter T. High efficiency hydrofoil and swim fin designs
US6253186B1 (en) * 1996-08-14 2001-06-26 Blue Cross Blue Shield Of South Carolina Method and apparatus for detecting fraud
US5924902A (en) * 1998-01-06 1999-07-20 Hollywood Hopefuls Production, Inc. Amphibious swimming and walking shoe
US6155898A (en) * 1999-04-16 2000-12-05 Hollywood Hopeful Productions L.L.C. Convertible amphibious shoes for swimming and walking
US7398218B1 (en) * 1999-08-27 2008-07-08 Accenture Llp Insurance pattern analysis
US20010027388A1 (en) * 1999-12-03 2001-10-04 Anthony Beverina Method and apparatus for risk management
US20030069820A1 (en) * 2000-03-24 2003-04-10 Amway Corporation System and method for detecting fraudulent transactions
US20020002475A1 (en) * 2000-04-13 2002-01-03 Joel Freedman Automated insurance system and method
US7024418B1 (en) * 2000-06-23 2006-04-04 Computer Sciences Corporation Relevance calculation for a reference system in an insurance claims processing system
US7095426B1 (en) * 2000-06-23 2006-08-22 Computer Sciences Corporation Graphical user interface with a hide/show feature for a reference system in an insurance claims processing system
US20020091550A1 (en) * 2000-06-29 2002-07-11 White Mitchell Franklin System and method for real-time rating, underwriting and policy issuance
US6826536B1 (en) * 2000-07-22 2004-11-30 Bert Forman Health care billing monitor system for detecting health care provider fraud
US6540574B2 (en) * 2000-09-07 2003-04-01 Hideya Hashizume Foldable diving flippers
US20020059083A1 (en) * 2000-10-02 2002-05-16 Steven Wahlbin Computerized method and system of determining inconsistencies in witness statements relating to an accident
US20020087363A1 (en) * 2000-10-02 2002-07-04 Steven Wahlbin Computerized method and system of liability assessment for an accident using environmental, vehicle, and driver conditions and driver actions
US20020059086A1 (en) * 2000-10-02 2002-05-16 Steven Wahlbin Computerized method and system of displaying a roadway configuration relating to an accident
US20020059087A1 (en) * 2000-10-02 2002-05-16 Steven Wahlbin Computerized method and system of displaying an impact point relating to an accident
US20020062233A1 (en) * 2000-10-02 2002-05-23 Steven Wahlbin Computerized method and system of assessing liability for an accident using impact groups
US20020062235A1 (en) * 2000-10-02 2002-05-23 Steven Wahlbin Computerized method and system for providing claims data to an accident liability assessment program
US20020062234A1 (en) * 2000-10-02 2002-05-23 Steven Wahlbin Computerized method and system of estimating liability and range of liability for an accident
US20020062232A1 (en) * 2000-10-02 2002-05-23 Steven Wahlbin Computerized method and system for adjusting liability estimation factors in an accident liability assessment program
US20020069092A1 (en) * 2000-10-02 2002-06-06 Steven Wahlbin Computerized method and system of assessing and adjusting liability for an accident
US20020069091A1 (en) * 2000-10-02 2002-06-06 Steven Wahlbin Computerized method and system of liability assessment for an accident
US20020082873A1 (en) * 2000-10-02 2002-06-27 Steven Wahlbin Computerized method and system of determining right of way and liability for an accident
US20020059097A1 (en) * 2000-10-02 2002-05-16 Steven Wahlbin Computerized method and system of assigning an absolute liability value for an accident
US20020091504A1 (en) * 2000-10-02 2002-07-11 Steven Wahlbin Computerized method and system for accumulating liability estimates
US20020128881A1 (en) * 2000-10-02 2002-09-12 Steven Wahlbin Computerized method and system for adjusting liability estimates in an accident liability assessment program
US20020049619A1 (en) * 2000-10-02 2002-04-25 Steven Wahlbin Computerized method and system of identifying a credible witness statement relating to an accident
US20020055860A1 (en) * 2000-10-02 2002-05-09 Steven Wahlbin Computerized method and system of determining right of way in an accident
US20020059085A1 (en) * 2000-10-02 2002-05-16 Steven Wahlbin Computerized method and system of determining a credible real set of characteristics for an accident
US20020059084A1 (en) * 2000-10-02 2002-05-16 Steven Wahlbin Computerized method and system of displaying an accident type
US20030093672A1 (en) * 2001-06-29 2003-05-15 Bruce Cichowlas System for and methods of administration of access control to numerous resources and objects
US20030191703A1 (en) * 2002-02-01 2003-10-09 Ubs Painewebber Inc. Method and system for providing interested party access to aggregated accounts information
US7263492B1 (en) * 2002-02-15 2007-08-28 Fair Isaac Corporation Sequencing models of healthcare related states
US20040003347A1 (en) * 2002-06-28 2004-01-01 Ubs Painewebber Inc. System and method for providing on-line services for multiple entities
US20040044895A1 (en) * 2002-08-27 2004-03-04 Reasons John D. Connected support entitlement system and method of operation
US20040049409A1 (en) * 2002-09-09 2004-03-11 Stefan Wahlbin Computerized method and system for determining breach of duty in premises liability for an accident
US20040054557A1 (en) * 2002-09-09 2004-03-18 Stefan Wahlbin Computerized method and system for estimating premises liability for an accident
US20040054559A1 (en) * 2002-09-09 2004-03-18 Stefan Wahlbin Computerized method and system for determining the contribution of defenses to premises liability for an accident
US20040054556A1 (en) * 2002-09-09 2004-03-18 Stephan Wahlbin Computerized method and system for determining causation in premises liability for an accident
US20040054558A1 (en) * 2002-09-09 2004-03-18 Stefan Wahlbin Computerized method and system for determining claimant status in premises liability for an accident
US20050043961A1 (en) * 2002-09-30 2005-02-24 Michael Torres System and method for identification, detection and investigation of maleficent acts
US20040083140A1 (en) * 2002-10-15 2004-04-29 Custom Direct, Inc. System and method for providing recovery for victims of check fraud
US20040088199A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Method of forming a business rule
US20040088198A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Method of modifying a business rule while tracking the modifications
US20040088196A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Graphical display of business rules
US20040088195A1 (en) * 2002-10-31 2004-05-06 Childress Allen B. Method of modifying a business rule
US20040111301A1 (en) * 2002-11-27 2004-06-10 Stefan Wahlbin Computerized method and system for estimating liability for an accident using dynamic generation of questions
US20040103007A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating an effect on liability using claim data accessed from claim reporting software
US20040103009A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for creating pre-configured claim reports including liability in an accident estimated using a computer system
US20040103008A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating liability for an accident from an investigation of the accident
US20040102984A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating liability using recorded vehicle data
US20040103004A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating an effect on liability using a comparison of the actual speed of a vehicle in an accident and time and distance traveled by the vehicles in a merging vehicle accident
US20040103010A1 (en) * 2002-11-27 2004-05-27 Stephan Wahlbin Computerized method and system for estimating an effect on liability of the speed of vehicles in an accident and time and distance traveled by the vehicles
US20040103006A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating an effect on liability using a comparison of the actual speed of vehicles with a specified speed
US20040103005A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating monetary damages due to injuries in an accident from liability estimated using a computer system
US20040102985A1 (en) * 2002-11-27 2004-05-27 Stefan Wahlbin Computerized method and system for estimating an effect on liability based on the stopping distance of vehicles
US7159336B2 (en) * 2002-12-09 2007-01-09 Aquaped, Llc Amphibious shoe
US20040215494A1 (en) * 2003-04-24 2004-10-28 Wahlbin Stefan L. Method and system for determining monetary amounts in an insurance processing system
US20050060205A1 (en) * 2003-09-02 2005-03-17 Woods Randall K. Systems and methods for a graphical input display in an insurance processing system
US20050060184A1 (en) * 2003-09-02 2005-03-17 Stefan Wahlbin Graphical input display in an insurance processing system
US20050276401A1 (en) * 2003-11-05 2005-12-15 Madill Robert P Jr Systems and methods for assessing the potential for fraud in business transactions
US20050097051A1 (en) * 2003-11-05 2005-05-05 Madill Robert P.Jr. Fraud potential indicator graphical interface
US20050192850A1 (en) * 2004-03-01 2005-09-01 Lorenz Scott K. Systems and methods for using data structure language in web services
US20060047540A1 (en) * 2004-09-01 2006-03-02 Hutten Bruce V System and method for underwriting
US20080172904A1 (en) * 2007-01-22 2008-07-24 David Pelsue Interchangeable midsole system for footwear

Cited By (215)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8024265B2 (en) 2002-12-30 2011-09-20 Fannie Mae System and method for verifying loan data at delivery
US20100268641A1 (en) * 2002-12-30 2010-10-21 Fannie Mae System and method for verifying loan data at delivery
US7747519B2 (en) 2002-12-30 2010-06-29 Fannie Mae System and method for verifying loan data at delivery
US20040215554A1 (en) * 2002-12-30 2004-10-28 Fannie Mae System and method for verifying loan data at delivery
US7458508B1 (en) 2003-05-12 2008-12-02 Id Analytics, Inc. System and method for identity-based fraud detection
US7562814B1 (en) 2003-05-12 2009-07-21 Id Analytics, Inc. System and method for identity-based fraud detection through graph anomaly detection
US7686214B1 (en) * 2003-05-12 2010-03-30 Id Analytics, Inc. System and method for identity-based fraud detection using a plurality of historical identity records
US7793835B1 (en) 2003-05-12 2010-09-14 Id Analytics, Inc. System and method for identity-based fraud detection for transactions using a plurality of historical identity records
US10521857B1 (en) 2003-05-12 2019-12-31 Symantec Corporation System and method for identity-based fraud detection
US8386377B1 (en) 2003-05-12 2013-02-26 Id Analytics, Inc. System and method for credit scoring using an identity network connectivity
US9311676B2 (en) 2003-09-04 2016-04-12 Hartford Fire Insurance Company Systems and methods for analyzing sensor data
US10817952B2 (en) 2003-09-04 2020-10-27 Hartford Fire Insurance Company Remote sensor systems
US20050055249A1 (en) * 2003-09-04 2005-03-10 Jonathon Helitzer System for reducing the risk associated with an insured building structure through the incorporation of selected technologies
US11182861B2 (en) 2003-09-04 2021-11-23 Hartford Fire Insurance Company Structure condition sensor and remediation system
US10032224B2 (en) 2003-09-04 2018-07-24 Hartford Fire Insurance Company Systems and methods for analyzing sensor data
US10354328B2 (en) 2003-09-04 2019-07-16 Hartford Fire Insurance Company System for processing remote sensor data
US8676612B2 (en) 2003-09-04 2014-03-18 Hartford Fire Insurance Company System for adjusting insurance for a building structure through the incorporation of selected technologies
US7711584B2 (en) 2003-09-04 2010-05-04 Hartford Fire Insurance Company System for reducing the risk associated with an insured building structure through the incorporation of selected technologies
US20100174566A1 (en) * 2003-09-04 2010-07-08 Hartford Fire Insurance Company Systems and methods for analyzing sensor data
US9881342B2 (en) 2003-09-04 2018-01-30 Hartford Fire Insurance Company Remote sensor data systems
US8271303B2 (en) 2003-09-04 2012-09-18 Hartford Fire Insurance Company System for reducing the risk associated with an insured building structure through the incorporation of selected technologies
US20050276401A1 (en) * 2003-11-05 2005-12-15 Madill Robert P Jr Systems and methods for assessing the potential for fraud in business transactions
US7827045B2 (en) 2003-11-05 2010-11-02 Computer Sciences Corporation Systems and methods for assessing the potential for fraud in business transactions
US20050097051A1 (en) * 2003-11-05 2005-05-05 Madill Robert P.Jr. Fraud potential indicator graphical interface
US20050108065A1 (en) * 2003-11-18 2005-05-19 Dorfstatter Walter A. Method and system of estimating vehicle damage
US8612262B1 (en) 2003-11-19 2013-12-17 Allstate Insurance Company Market relationship management
US20060004612A1 (en) * 2004-07-01 2006-01-05 Chewning Timothy W Systems and methods for configuring and processing insurance information
US7311248B1 (en) * 2004-08-12 2007-12-25 Prairie Systems, Inc. Method and system for automatically detecting fraudulent applications
US20060149674A1 (en) * 2004-12-30 2006-07-06 Mike Cook System and method for identity-based fraud detection for transactions using a plurality of historical identity records
US7444331B1 (en) * 2005-03-02 2008-10-28 Symantec Corporation Detecting code injection attacks against databases
US20060200407A1 (en) * 2005-03-02 2006-09-07 Accenture Global Services Gmbh Advanced payment integrity
WO2006093681A3 (en) * 2005-03-02 2007-04-12 Accenture Global Services Gmbh Advanced payment integrity
US7860812B2 (en) 2005-03-02 2010-12-28 Accenture Global Services Limited Advanced insurance record audit and payment integrity
US20090234684A1 (en) * 2005-03-24 2009-09-17 Mark Peter Stoke Risk Based Data Assessment
WO2006099674A1 (en) * 2005-03-24 2006-09-28 Accenture Global Services Gmbh Risk based data assessment
EP1830290A1 (en) * 2006-03-03 2007-09-05 Health Insurance Review Agency Method for electronic examination of medical fees
US20080077451A1 (en) * 2006-09-22 2008-03-27 Hartford Fire Insurance Company System for synergistic data processing
US10061828B2 (en) 2006-11-20 2018-08-28 Palantir Technologies, Inc. Cross-ontology multi-master replication
US9330157B2 (en) 2006-11-20 2016-05-03 Palantir Technologies, Inc. Cross-ontology multi-master replication
US8571900B2 (en) 2006-12-19 2013-10-29 Hartford Fire Insurance Company System and method for processing data relating to insurance claim stability indicator
US8359209B2 (en) 2006-12-19 2013-01-22 Hartford Fire Insurance Company System and method for predicting and responding to likelihood of volatility
US20080147448A1 (en) * 2006-12-19 2008-06-19 Hartford Fire Insurance Company System and method for predicting and responding to likelihood of volatility
US8798987B2 (en) 2006-12-19 2014-08-05 Hartford Fire Insurance Company System and method for processing data relating to insurance claim volatility
US20110218827A1 (en) * 2006-12-22 2011-09-08 Hartford Fire Insurance Company System and method for utilizing interrelated computerized predictive models
US20080154651A1 (en) * 2006-12-22 2008-06-26 Hartford Fire Insurance Company System and method for utilizing interrelated computerized predictive models
US7945497B2 (en) 2006-12-22 2011-05-17 Hartford Fire Insurance Company System and method for utilizing interrelated computerized predictive models
US9881340B2 (en) * 2006-12-22 2018-01-30 Hartford Fire Insurance Company Feedback loop linked models for interface generation
US20080235062A1 (en) * 2006-12-29 2008-09-25 American International Group, Inc. Method and system for initially projecting an insurance company's net loss from a major loss event
US20080256523A1 (en) * 2007-04-12 2008-10-16 Nancy Grimaldi Computerized Data Warehousing
US8191053B2 (en) 2007-04-12 2012-05-29 Ingenix, Inc. Computerized data warehousing
US20090043615A1 (en) * 2007-08-07 2009-02-12 Hartford Fire Insurance Company Systems and methods for predictive data analysis
JP2011505047A (en) * 2007-11-28 2011-02-17 アシュラント,インコーポレーテッド Automatic billing system
WO2009073151A1 (en) * 2007-11-28 2009-06-11 Assurant, Inc. Automated claims processing system
CN101925919A (en) * 2007-11-28 2010-12-22 安信龙股份公司 Automated claims processing system
US9665910B2 (en) 2008-02-20 2017-05-30 Hartford Fire Insurance Company System and method for providing customized safety feedback
US20090210257A1 (en) * 2008-02-20 2009-08-20 Hartford Fire Insurance Company System and method for providing customized safety feedback
US20120059677A1 (en) * 2008-02-29 2012-03-08 The Advocator Group, Llc Methods and systems for automated, predictive modeling of the outcome of benefits claims
US20090222290A1 (en) * 2008-02-29 2009-09-03 Crowe Michael K Methods and Systems for Automated, Predictive Modeling of the Outcome of Benefits Claims
US20100185466A1 (en) * 2009-01-20 2010-07-22 Kenneth Paradis Systems and methods for tracking health-related spending for validation of disability benefits claims
US8224678B2 (en) 2009-01-20 2012-07-17 Ametros Financial Corporation Systems and methods for tracking health-related spending for validation of disability benefits claims
US20100274720A1 (en) * 2009-04-28 2010-10-28 Mark Carlson Fraud and reputation protection using advanced authorization and rules engine
US20110077977A1 (en) * 2009-07-28 2011-03-31 Collins Dean Methods and systems for data mining using state reported worker's compensation data
CN101996385A (en) * 2009-08-25 2011-03-30 埃森哲环球服务有限公司 Claims analytics engine
US8762180B2 (en) * 2009-08-25 2014-06-24 Accenture Global Services Limited Claims analytics engine
US20110054925A1 (en) * 2009-08-25 2011-03-03 Rayid Ghani Claims analytics engine
AU2010212343B2 (en) * 2009-08-25 2012-04-12 Accenture Global Services Limited Claims analytics engine
US20110184766A1 (en) * 2010-01-25 2011-07-28 Hartford Fire Insurance Company Systems and methods for prospecting and rounding business insurance customers
US8355934B2 (en) 2010-01-25 2013-01-15 Hartford Fire Insurance Company Systems and methods for prospecting business insurance customers
US8892452B2 (en) * 2010-01-25 2014-11-18 Hartford Fire Insurance Company Systems and methods for adjusting insurance workflow
US8386277B2 (en) * 2010-03-23 2013-02-26 United Parcel Service Of America, Inc. Systems and methods for identifying suspicious orders
US10325300B2 (en) * 2010-03-23 2019-06-18 United Parcel Service Of America, Inc. Systems and methods for identifying suspicious orders
US11393004B2 (en) 2010-03-23 2022-07-19 United Parcel Service Of America, Inc. Systems and methods for identifying suspicious orders
US20110238593A1 (en) * 2010-03-23 2011-09-29 United Parcel Service Of America, Inc. Systems and Methods for Identifying Suspicious Orders
US20130124363A1 (en) * 2010-03-23 2013-05-16 United Parcel Service Of America, Inc. Systems and methods for identifying suspicious orders
USRE48589E1 (en) 2010-07-15 2021-06-08 Palantir Technologies Inc. Sharing and deconflicting data changes in a multimaster database system
US10740848B2 (en) 2010-07-16 2020-08-11 Hartford Fire Insurance Company Secure remote monitoring data validation
US9824399B2 (en) 2010-07-16 2017-11-21 Hartford Fire Insurance Company Secure data validation system
US9460471B2 (en) 2010-07-16 2016-10-04 Hartford Fire Insurance Company System and method for an automated validation system
US20130173309A1 (en) * 2010-12-01 2013-07-04 Cedars-Sinai Medical Center Privacy awareness tool
US20160342749A1 (en) * 2010-12-01 2016-11-24 Cedars-Sinai Medical Center Privacy awareness tool
US11693877B2 (en) 2011-03-31 2023-07-04 Palantir Technologies Inc. Cross-ontology multi-master replication
US9715518B2 (en) 2012-01-23 2017-07-25 Palantir Technologies, Inc. Cross-ACL multi-master replication
US9189492B2 (en) 2012-01-23 2015-11-17 Palatir Technoogies, Inc. Cross-ACL multi-master replication
US9299108B2 (en) * 2012-02-24 2016-03-29 Tata Consultancy Services Limited Insurance claims processing
US20130226623A1 (en) * 2012-02-24 2013-08-29 Tata Consultancy Services Limited Insurance claims processing
WO2013159178A1 (en) * 2012-04-22 2013-10-31 Automated Benefits, Inc. Online claims submission and adjudication system
US8918891B2 (en) 2012-06-12 2014-12-23 Id Analytics, Inc. Identity manipulation detection system and method
WO2015002630A3 (en) * 2012-07-24 2015-04-09 Deloitte Development Llc Fraud detection methods and systems
US20150269671A1 (en) * 2012-10-09 2015-09-24 CommunityLend Holding Inc. System and Method for Processing Loan Applications
WO2014056101A1 (en) * 2012-10-09 2014-04-17 Communitylend Holdings Inc. Method for processing loan applications
US10453128B2 (en) * 2012-10-09 2019-10-22 Communitylend Holdings Inc. System and method for processing loan applications
US10891312B2 (en) 2012-10-22 2021-01-12 Palantir Technologies Inc. Sharing information between nexuses that use different classification schemes for information access control
US9836523B2 (en) 2012-10-22 2017-12-05 Palantir Technologies Inc. Sharing information between nexuses that use different classification schemes for information access control
US9081975B2 (en) 2012-10-22 2015-07-14 Palantir Technologies, Inc. Sharing information between nexuses that use different classification schemes for information access control
US10846300B2 (en) 2012-11-05 2020-11-24 Palantir Technologies Inc. System and method for sharing investigation results
US10311081B2 (en) 2012-11-05 2019-06-04 Palantir Technologies Inc. System and method for sharing investigation results
JP2014164753A (en) * 2013-02-22 2014-09-08 Palo Alto Research Center Inc Method and apparatus for combining multi-dimensional fraud measurements for anomaly detection
US20140244528A1 (en) * 2013-02-22 2014-08-28 Palo Alto Research Center Incorporated Method and apparatus for combining multi-dimensional fraud measurements for anomaly detection
US9965937B2 (en) 2013-03-15 2018-05-08 Palantir Technologies Inc. External malware data item clustering and analysis
US10431327B2 (en) 2013-03-15 2019-10-01 Palantir Technologies Inc. Computer graphical user interface with genomic workflow
US10216801B2 (en) 2013-03-15 2019-02-26 Palantir Technologies Inc. Generating data clusters
US10264014B2 (en) 2013-03-15 2019-04-16 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive investigation based on automatic clustering of related data in various data structures
US10275778B1 (en) 2013-03-15 2019-04-30 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive investigation based on automatic malfeasance clustering of related data in various data structures
US9501202B2 (en) 2013-03-15 2016-11-22 Palantir Technologies, Inc. Computer graphical user interface with genomic workflow
US11074993B2 (en) 2013-03-15 2021-07-27 Palantir Technologies Inc. Computer graphical user interface with genomic workflow
US20140303993A1 (en) * 2013-04-08 2014-10-09 Unisys Corporation Systems and methods for identifying fraud in transactions committed by a cohort of fraudsters
US10762102B2 (en) 2013-06-20 2020-09-01 Palantir Technologies Inc. System and method for incremental replication
US20150032482A1 (en) * 2013-07-29 2015-01-29 Independent Mitigation and Cleaning/Conservation Network, Inc. Claim summary and claim watch system and method
US20160275621A1 (en) * 2013-07-29 2016-09-22 Independent Mitigation and Cleaning/Conservation Network, Inc. Claim summary and claim watch system and method
US11688256B2 (en) * 2013-09-06 2023-06-27 Nec Corporation Security system, security method, and non-transitory computer readable medium
US20220270455A1 (en) * 2013-09-06 2022-08-25 Nec Corporation Security system, security method, and non-transitory computer readable medium
US20160210829A1 (en) * 2013-09-06 2016-07-21 Nec Corporation Security system, security method, and non-transitory computer readable medium
US10573141B2 (en) * 2013-09-06 2020-02-25 Nec Corporation Security system, security method, and non-transitory computer readable medium
US11354991B2 (en) * 2013-09-06 2022-06-07 Nec Corporation Security system, security method, and non-transitory computer readable medium
US20190005785A1 (en) * 2013-09-06 2019-01-03 Nec Corporation Security system, security method, and non-transitory computer readable medium
US20190005787A1 (en) * 2013-09-06 2019-01-03 Nec Corporation Security system, security method, and non-transitory computer readable medium
US20190005786A1 (en) * 2013-09-06 2019-01-03 Nec Corporation Security system, security method, and non-transitory computer readable medium
US10719527B2 (en) 2013-10-18 2020-07-21 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive simultaneous querying of multiple data stores
US9569070B1 (en) 2013-11-11 2017-02-14 Palantir Technologies, Inc. Assisting in deconflicting concurrency conflicts
US10579647B1 (en) 2013-12-16 2020-03-03 Palantir Technologies Inc. Methods and systems for analyzing entity performance
US9866673B2 (en) 2013-12-18 2018-01-09 Medlegal Network, Inc. Methods and systems of managing accident communications over a network
US9552615B2 (en) 2013-12-20 2017-01-24 Palantir Technologies Inc. Automated database analysis to detect malfeasance
US10356032B2 (en) 2013-12-26 2019-07-16 Palantir Technologies Inc. System and method for detecting confidential information emails
US9100428B1 (en) 2014-01-03 2015-08-04 Palantir Technologies Inc. System and method for evaluating network threats
US10805321B2 (en) 2014-01-03 2020-10-13 Palantir Technologies Inc. System and method for evaluating network threats and usage
US10230746B2 (en) 2014-01-03 2019-03-12 Palantir Technologies Inc. System and method for evaluating network threats and usage
US20180005331A1 (en) * 2014-02-20 2018-01-04 Palantir Technologies Inc. Database sharing system
US10873603B2 (en) 2014-02-20 2020-12-22 Palantir Technologies Inc. Cyber security sharing and identification system
US20150235334A1 (en) * 2014-02-20 2015-08-20 Palantir Technologies Inc. Healthcare fraud sharing system
US9923925B2 (en) 2014-02-20 2018-03-20 Palantir Technologies Inc. Cyber security sharing and identification system
US10380696B1 (en) 2014-03-18 2019-08-13 Ccc Information Services Inc. Image processing system for vehicle damage
US10373262B1 (en) 2014-03-18 2019-08-06 Ccc Information Services Inc. Image processing system for vehicle damage
US10373260B1 (en) 2014-03-18 2019-08-06 Ccc Information Services Inc. Imaging processing system for identifying parts for repairing a vehicle
US10853454B2 (en) 2014-03-21 2020-12-01 Palantir Technologies Inc. Provider portal
US9535974B1 (en) 2014-06-30 2017-01-03 Palantir Technologies Inc. Systems and methods for identifying key phrase clusters within documents
US10180929B1 (en) 2014-06-30 2019-01-15 Palantir Technologies, Inc. Systems and methods for identifying key phrase clusters within documents
US10162887B2 (en) 2014-06-30 2018-12-25 Palantir Technologies Inc. Systems and methods for key phrase characterization of documents
US11341178B2 (en) 2014-06-30 2022-05-24 Palantir Technologies Inc. Systems and methods for key phrase characterization of documents
US10572496B1 (en) 2014-07-03 2020-02-25 Palantir Technologies Inc. Distributed workflow system and database with access controls for city resiliency
US9875293B2 (en) 2014-07-03 2018-01-23 Palanter Technologies Inc. System and method for news events detection and visualization
US9881074B2 (en) 2014-07-03 2018-01-30 Palantir Technologies Inc. System and method for news events detection and visualization
US10929436B2 (en) 2014-07-03 2021-02-23 Palantir Technologies Inc. System and method for news events detection and visualization
US9998485B2 (en) 2014-07-03 2018-06-12 Palantir Technologies, Inc. Network intrusion data item clustering and analysis
US10798116B2 (en) 2014-07-03 2020-10-06 Palantir Technologies Inc. External malware data item clustering and analysis
US10135863B2 (en) 2014-11-06 2018-11-20 Palantir Technologies Inc. Malicious software detection in a computing system
US9558352B1 (en) 2014-11-06 2017-01-31 Palantir Technologies Inc. Malicious software detection in a computing system
US10728277B2 (en) 2014-11-06 2020-07-28 Palantir Technologies Inc. Malicious software detection in a computing system
US10217171B2 (en) * 2014-12-15 2019-02-26 Hartford Fire Insurance Company System to administer insurance knowledge management tool
US20160171616A1 (en) * 2014-12-15 2016-06-16 Hartford Fire Insurance Company System to administer insurance knowledge management tool
US10643286B2 (en) * 2014-12-15 2020-05-05 Hartford Fire Insurance Company Knowledge management tool interface
US9898528B2 (en) 2014-12-22 2018-02-20 Palantir Technologies Inc. Concept indexing among database of documents using machine learning techniques
US9367872B1 (en) 2014-12-22 2016-06-14 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive investigation of bad actor behavior based on automatic clustering of related data in various data structures
US10447712B2 (en) 2014-12-22 2019-10-15 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive investigation of bad actor behavior based on automatic clustering of related data in various data structures
US10362133B1 (en) 2014-12-22 2019-07-23 Palantir Technologies Inc. Communication data processing architecture
US11252248B2 (en) 2014-12-22 2022-02-15 Palantir Technologies Inc. Communication data processing architecture
US10552994B2 (en) 2014-12-22 2020-02-04 Palantir Technologies Inc. Systems and interactive user interfaces for dynamic retrieval, analysis, and triage of data items
US9589299B2 (en) 2014-12-22 2017-03-07 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive investigation of bad actor behavior based on automatic clustering of related data in various data structures
US9817563B1 (en) 2014-12-29 2017-11-14 Palantir Technologies Inc. System and method of generating data points from one or more data stores of data items for chart creation and manipulation
US10552998B2 (en) 2014-12-29 2020-02-04 Palantir Technologies Inc. System and method of generating data points from one or more data stores of data items for chart creation and manipulation
US10372879B2 (en) 2014-12-31 2019-08-06 Palantir Technologies Inc. Medical claims lead summary report generation
US11030581B2 (en) 2014-12-31 2021-06-08 Palantir Technologies Inc. Medical claims lead summary report generation
US11302426B1 (en) 2015-01-02 2022-04-12 Palantir Technologies Inc. Unified data interface and system
US10103953B1 (en) 2015-05-12 2018-10-16 Palantir Technologies Inc. Methods and systems for analyzing entity performance
US10628834B1 (en) 2015-06-16 2020-04-21 Palantir Technologies Inc. Fraud lead detection system for efficiently processing database-stored data and automatically generating natural language explanatory information of system results for display in interactive user interfaces
US9418337B1 (en) 2015-07-21 2016-08-16 Palantir Technologies Inc. Systems and models for data analytics
US10636097B2 (en) 2015-07-21 2020-04-28 Palantir Technologies Inc. Systems and models for data analytics
US10223748B2 (en) 2015-07-30 2019-03-05 Palantir Technologies Inc. Systems and user interfaces for holistic, data-driven investigation of bad actor behavior based on clustering and scoring of related data
US11501369B2 (en) 2015-07-30 2022-11-15 Palantir Technologies Inc. Systems and user interfaces for holistic, data-driven investigation of bad actor behavior based on clustering and scoring of related data
US9454785B1 (en) 2015-07-30 2016-09-27 Palantir Technologies Inc. Systems and user interfaces for holistic, data-driven investigation of bad actor behavior based on clustering and scoring of related data
US9635046B2 (en) 2015-08-06 2017-04-25 Palantir Technologies Inc. Systems, methods, user interfaces, and computer-readable media for investigating potential malicious communications
US10484407B2 (en) 2015-08-06 2019-11-19 Palantir Technologies Inc. Systems, methods, user interfaces, and computer-readable media for investigating potential malicious communications
US10489391B1 (en) 2015-08-17 2019-11-26 Palantir Technologies Inc. Systems and methods for grouping and enriching data items accessed from one or more databases for presentation in a user interface
US10346410B2 (en) 2015-08-28 2019-07-09 Palantir Technologies Inc. Malicious activity detection system capable of efficiently processing data accessed from databases and generating alerts for display in interactive user interfaces
US9898509B2 (en) 2015-08-28 2018-02-20 Palantir Technologies Inc. Malicious activity detection system capable of efficiently processing data accessed from databases and generating alerts for display in interactive user interfaces
US11048706B2 (en) 2015-08-28 2021-06-29 Palantir Technologies Inc. Malicious activity detection system capable of efficiently processing data accessed from databases and generating alerts for display in interactive user interfaces
US10210576B2 (en) 2015-10-23 2019-02-19 Mastercard International Incorporated Processing payment card transaction records to determine insurance fraud risk
US10572487B1 (en) 2015-10-30 2020-02-25 Palantir Technologies Inc. Periodic database search manager for multiple data sources
US10621198B1 (en) 2015-12-30 2020-04-14 Palantir Technologies Inc. System and method for secure database replication
US10394871B2 (en) 2016-10-18 2019-08-27 Hartford Fire Insurance Company System to predict future performance characteristic for an electronic record
US20180130135A1 (en) * 2016-11-09 2018-05-10 Melissa Norwicke System and method for obtaining information about a deceased person's life insurance policy and submitting a claim thereunder
US10318630B1 (en) 2016-11-21 2019-06-11 Palantir Technologies Inc. Analysis of large bodies of textual data
US11681282B2 (en) 2016-12-20 2023-06-20 Palantir Technologies Inc. Systems and methods for determining relationships between defects
US10620618B2 (en) 2016-12-20 2020-04-14 Palantir Technologies Inc. Systems and methods for determining relationships between defects
US11163795B2 (en) 2016-12-22 2021-11-02 Palantir Technologies Inc. Systems and methods for data replication synchronization
US11829383B2 (en) 2016-12-22 2023-11-28 Palantir Technologies Inc. Systems and methods for data replication synchronization
US10262053B2 (en) 2016-12-22 2019-04-16 Palantir Technologies Inc. Systems and methods for data replication synchronization
US11373752B2 (en) 2016-12-22 2022-06-28 Palantir Technologies Inc. Detection of misuse of a benefit system
US20200035077A1 (en) * 2017-03-15 2020-01-30 Nec Corporation Information processing apparatus, control method, and program
US11600158B2 (en) * 2017-03-15 2023-03-07 Nec Corporation Information processing apparatus, control method, and program
US10325224B1 (en) 2017-03-23 2019-06-18 Palantir Technologies Inc. Systems and methods for selecting machine learning training data
US11481410B1 (en) 2017-03-30 2022-10-25 Palantir Technologies Inc. Framework for exposing network activities
US10606866B1 (en) 2017-03-30 2020-03-31 Palantir Technologies Inc. Framework for exposing network activities
US10068002B1 (en) 2017-04-25 2018-09-04 Palantir Technologies Inc. Systems and methods for adaptive data replication
US11604811B2 (en) 2017-04-25 2023-03-14 Palantir Technologies Inc. Systems and methods for adaptive data replication
US10915555B2 (en) 2017-04-25 2021-02-09 Palantir Technologies Inc. Systems and methods for adaptive data replication
US11210350B2 (en) 2017-05-02 2021-12-28 Palantir Technologies Inc. Automated assistance for generating relevant and valuable search results for an entity of interest
US10235461B2 (en) 2017-05-02 2019-03-19 Palantir Technologies Inc. Automated assistance for generating relevant and valuable search results for an entity of interest
US11714869B2 (en) 2017-05-02 2023-08-01 Palantir Technologies Inc. Automated assistance for generating relevant and valuable search results for an entity of interest
US10482382B2 (en) 2017-05-09 2019-11-19 Palantir Technologies Inc. Systems and methods for reducing manufacturing failure rates
US11537903B2 (en) 2017-05-09 2022-12-27 Palantir Technologies Inc. Systems and methods for reducing manufacturing failure rates
US10430062B2 (en) 2017-05-30 2019-10-01 Palantir Technologies Inc. Systems and methods for geo-fenced dynamic dissemination
US11775161B2 (en) 2017-05-30 2023-10-03 Palantir Technologies Inc. Systems and methods for geo-fenced dynamic dissemination
US11099727B2 (en) 2017-05-30 2021-08-24 Palantir Technologies Inc. Systems and methods for geo-fenced dynamic dissemination
US11030494B1 (en) 2017-06-15 2021-06-08 Palantir Technologies Inc. Systems and methods for managing data spills
US10628002B1 (en) 2017-07-10 2020-04-21 Palantir Technologies Inc. Integrated data authentication system with an interactive user interface
US11580173B2 (en) 2017-12-08 2023-02-14 Palantir Technologies Inc. Systems and methods for using linked documents
US11921796B2 (en) 2017-12-08 2024-03-05 Palantir Technologies Inc. Systems and methods for using linked documents
US10380196B2 (en) 2017-12-08 2019-08-13 Palantir Technologies Inc. Systems and methods for using linked documents
US10915542B1 (en) 2017-12-19 2021-02-09 Palantir Technologies Inc. Contextual modification of data sharing constraints in a distributed database system that uses a multi-master replication scheme
US11119630B1 (en) 2018-06-19 2021-09-14 Palantir Technologies Inc. Artificial intelligence assisted evaluations and user interface for same
US11210349B1 (en) 2018-08-02 2021-12-28 Palantir Technologies Inc. Multi-database document search system architecture
CN109829728A (en) * 2019-01-18 2019-05-31 南京邮电大学 A kind of system and method towards service security of calling a taxi
US20230154622A1 (en) * 2020-04-15 2023-05-18 Hartford Fire Insurance Company System and method providing risk relationship transaction automation in accordance with medical condition code
US11594334B2 (en) * 2020-04-15 2023-02-28 Hartford Fire Insurance Company System and method providing risk relationship transaction automation in accordance with medical condition code
US20230056462A1 (en) * 2021-08-19 2023-02-23 Marc R. Deschenaux Cascading initial public offerings or special purpose acquisitions companies for corporate capitalization

Also Published As

Publication number Publication date
US20050276401A1 (en) 2005-12-15
WO2005048046A3 (en) 2005-12-22
US7827045B2 (en) 2010-11-02
WO2005048046A2 (en) 2005-05-26

Similar Documents

Publication Publication Date Title
US7827045B2 (en) Systems and methods for assessing the potential for fraud in business transactions
US20050097051A1 (en) Fraud potential indicator graphical interface
Bierstaker et al. Accountants' perceptions regarding fraud detection and prevention methods
Özkul et al. Fraud detection and forensic accounting
US7676426B2 (en) Biometric risk management
Viaene et al. Insurance fraud: Issues and challenges
US10504174B2 (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
US8209246B2 (en) Proprietary risk management clearinghouse
Deem Notes from the field: Observations in working with the forgotten victims of personal financial crimes
JP5378400B2 (en) Automatic billing system
US20140058763A1 (en) Fraud detection methods and systems
US20090106846A1 (en) System and method for detection and mitigation of identity theft
Morley et al. How the detection of insurance fraud succeeds and fails
US20020138417A1 (en) Risk management clearinghouse
US20120143649A1 (en) Method and system for dynamically detecting illegal activity
US20050043961A1 (en) System and method for identification, detection and investigation of maleficent acts
US20040064401A1 (en) Systems and methods for detecting fraudulent information
TW202036442A (en) Intelligent alert system
US20140303993A1 (en) Systems and methods for identifying fraud in transactions committed by a cohort of fraudsters
US20140108232A1 (en) Method and system for compliance hosting
Johnson et al. An investigation into fraud prevention and detection of small businesses in the United States: Responsibilities of auditors, managers, and business owners
Younus The rising trend of fraud and forgery in Pakistan’s banking industry and precautions taken against
WO2004003811A1 (en) Risk management customer registry
WO2004001544A2 (en) Biometric risk management
JP6718552B1 (en) Information processing device for sales support

Legal Events

Date Code Title Description
AS Assignment

Owner name: COMPUTER SCIENCES CORPORATION, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MADILL, ROBERT P., JR.;BARGER, THOMAS GLENN;ROGERS, JAMES LEWIS;AND OTHERS;REEL/FRAME:015043/0570;SIGNING DATES FROM 20031201 TO 20040108

STCB Information on status: application discontinuation

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