US20210158355A1 - Preempting or resolving fraud disputes relating to billing aliases - Google Patents

Abstract

In a computer-implemented method of pre-empting fraud disputes caused by billing aliases or unrecognized merchant billing names, an indication that a credit card financial transaction is unrecognizable by the card owner may be received. A billing alias for a merchant associated with the unrecognizable transaction may be determined, where the billing alias is named on a credit card statement as billing merchant. A brick and mortar name that the merchant associated with the billing alias is doing business as may be determined, and an electronic notification indicating the brick and mortar name of the merchant may be generated. The electronic notification may be transmitted to a mobile device of the card owner over a wireless communication channel for card owner review or approval to facilitate preventing financial disputes caused by unrecognized or unfamiliar billing aliases on credit card or other financial statements.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This claims the benefit of U.S. Patent Application No. 62/313,196, filed on Mar. 25, 2016 and entitled “Reducing Financial Fraud Using Machine Learning and Other Techniques,” U.S. Patent Application No. 62/318,423, filed on Apr. 5, 2016 and entitled “Reducing Financial Fraud Using Machine Learning and Other Techniques,” U.S. Patent Application No. 62/331,530, filed on May 4, 2016 and entitled “Reducing Financial Fraud Using Machine Learning and Other Techniques,” and U.S. Patent Application No. 62/365,699, filed on Jul. 22, 2016 and entitled “Detecting and/or Preventing Financial Fraud Using Geolocation Data,” the disclosures of which are hereby incorporated herein by reference in their entireties.
FIELD OF THE DISCLOSURE
• The present disclosure generally relates to financial fraud and, more specifically, to processing techniques that use machine learning to facilitate the resolution or prevention of fraud-related disputes.
BACKGROUND
• Financial fraud, in its many forms, is a problem of enormous magnitude and scope, causing billions of dollars in economic losses and impacting many millions of people. Types of financial fraud include use of a lost or stolen card, account takeover, skimming, chargeback (“friendly”) fraud, counterfeiting, forgeries and application (e.g., loan application) fraud, to name just a few. The problem only continues to grow as various technological advances, intended to improve convenience and efficiency in the marketplace, provide new opportunities for bad actors. For example, an ever-increasing amount of fraud may be linked to online transactions made via the Internet.
• Various software applications have been developed to detect potentially fraudulent transactions. For example, dollar amounts and geographic locations have generally been used to flag particular credit or debit card transactions, with cardholders then being contacted by employees of the card issuer to determine whether the transactions were indeed fraudulent. To ensure that most instances of fraud are captured, however, such techniques generally have a low threshold for triggering a fraud alert. As a result, numerous fraud alerts are false positives. The prevalence of false positives leads to a large cost in terms of the drain on human resources (e.g., calling customers to discuss each suspect transaction, and/or other manual investigation techniques), and considerable distraction or annoyance for cardholders. To provide a solution to these shortcomings in the field of automated fraud detection, innovative processing techniques capable of reducing false positives are needed.
• Other conventional processes relating to financial fraud are likewise resource-intensive. For example, fraud dispute resolution (e.g., after a cardholder has reported a fraudulent or unrecognized transaction) typically may involve a back-and-forth communication with an employee of the card issuer to try to ascertain whether a transaction was valid. This process may be time-consuming for both the cardholder and the employee, and might fail to identify whether a charge was fraudulent.
BRIEF SUMMARY
• The present embodiments may, inter alia, use new processing techniques to facilitate the dispute resolution process (e.g., after a cardholder has reported a fraudulent or unrecognized transaction), and/or to prevent disputes that may arise due to various factors (e.g., customer confusion regarding billing aliases and/or expiration of introductory offers).
• In one embodiment, a computer-implemented method of pre-empting fraud disputes caused by billing aliases or unrecognized merchant billing names may include: (1) receiving, by one or more processors, an indication that a credit card financial transaction is unrecognizable by the card owner; (2) determining, by the one or more processors, a billing alias for a merchant associated with the unrecognizable credit card financial transaction, the billing alias being named on a credit card statement as billing merchant; (3) determining, by the one or more processors, a brick and mortar name that the merchant associated with the billing alias is doing business as; (4) generating, by the one or more processors, an electronic notification indicating the brick and mortar name of the merchant associated with the credit card financial transaction; and/or (5) transmitting, by the one or more processors, the electronic notification indicating the brick and mortar name of the merchant to a mobile device of the card owner over a wireless communication channel for card owner review or approval to facilitate preventing financial disputes caused by unrecognized or unfamiliar billing aliases on credit card or other financial statements. The method may include additional, less, or alternate actions, including those discussed elsewhere herein.
• In another embodiment, a computer system configured to pre-empt fraud disputes includes one or more processors configured to: (1) receive an indication that a credit card financial transaction is unrecognizable by the card owner; (2) determine a billing alias for a merchant associated with the unrecognizable credit card financial transaction, the billing alias being named on a credit card statement as billing merchant; (3) determine a brick and mortar name that the merchant associated with the billing alias is doing business as; (4) generate an electronic notification indicating the brick and mortar name that the merchant associated with the billing alias is doing business as; and/or (5) transmit the electronic notification indicating the brick and mortar name of the merchant to a mobile device of the card owner over a wireless communication channel for card owner review or approval to facilitate preventing financial disputes caused by unrecognized or unfamiliar billing aliases on credit card or other financial statements. The computer system may include additional, less, or alternate functionality, including that discussed elsewhere herein.
• In another embodiment, a non-transitory, computer-readable medium stores instructions that, when executed by one or more processors, cause the one or more processors to: (1) receive an indication that a credit card financial transaction is unrecognizable by the card owner; (2) determine a billing alias for a merchant associated with the unrecognizable credit card financial transaction, the billing alias being named on a credit card statement as billing merchant; (3) determine a brick and mortar name that the merchant associated with the billing alias is doing business as; (4) generate an electronic notification indicating the brick and mortar name that the merchant associated with the billing alias is doing business as; and/or (5) transmit the electronic notification indicating the brick and mortar name of the merchant to a mobile device of the card owner over a wireless communication channel for card owner review or approval to facilitate preventing financial disputes caused by unrecognized or unfamiliar billing aliases on credit card or other financial statements.
BRIEF DESCRIPTION OF THE DRAWINGS
• The Figures described below depict various aspects of the systems and methods disclosed herein. It should be understood that each Figure depicts an embodiment of a particular aspect of the disclosed systems and methods, and that each of the Figures is intended to accord with a possible embodiment thereof.
• FIG. 1 depicts an exemplary environment in which techniques for fraud detection, verification and/or classification may be implemented, according to one embodiment.
• FIG. 2 depicts an exemplary process flow for machine learning of fraud detection, verification and/or classification rules, according to one embodiment.
• FIGS. 3A-3F depict exemplary process flows for machine learning of particular types of fraud detection, verification and/or classification rules, according to different embodiments.
• FIGS. 4A-4F depict exemplary factors and algorithms that may be used in connection with various fraud detection, verification and/or classification rule sets, according to different embodiments.
• FIG. 5 depicts a flow diagram of an exemplary method for facilitating a fraud dispute resolution process involving a customer associated with a financial account, according to one embodiment.
• FIG. 6 illustrates an exemplary computer-implemented method of resolving potential disputes caused by customer confusion originating from unrecognizable billing aliases on credit card or other billing statements.
• FIG. 7 illustrates an exemplary computer-implemented method of pre-emptively resolving potential customer complaints caused by increased charges for goods or services that are incurred after a low price, introductory offer expires.
• FIG. 8 depicts an exemplary computer system in which the techniques described herein may be implemented, according to one embodiment.
DETAILED DESCRIPTIONI. Exemplary Fraud Detection and/or Classification
• The embodiments described herein relate to, inter alia, wholly or partially automated detection, verification and/or classification of financial fraud. For ease of explanation, and unless otherwise clearly indicated by the context of usage, “detecting” or “determining” fraud may be used herein to refer to initially flagging fraudulent (or potentially fraudulent) activity, to verifying/confirming that suspect/flagged activity was indeed fraudulent, or generally to both. The systems and techniques described herein may be used, for example, to identify, prevent and/or quantify/measure instances of lost or stolen card use, account takeover, counterfeiting, skimming, chargeback (“friendly”) fraud, collusive merchant fraud, application (e.g., loan application) fraud, mortgage fraud, and/or one or more other types of fraud relating to existing and/or potential financial transactions and/or accounts. Moreover, those skilled in the art will appreciate that at least some of the technical advancements described below (and/or shown in the accompanying figures) are not necessarily restricted to the financial field.
• In some embodiments, a fraud detection and/or classification system may analyze data relating to a number of existing or potential financial accounts. The analysis/processing may be performed in batch processing operations, or substantially in real-time (e.g., as the data is generated and/or as financial transactions occur, etc.), and the data may be obtained from a variety of sources based upon the particular embodiment and/or scenario. In one embodiment, for example, data from financial account records may be analyzed, along with data indicating online activity of an account holder, location data (e.g., global positioning satellite (GPS) data from a smartphone or vehicle of the account holder) and/or other data, to determine whether a particular financial transaction was fraudulent or likely fraudulent. The analysis may be performed automatically after the transaction has been made, or may be performed in response to a person or algorithm flagging the transaction as a potentially fraudulent one, for example.
• The analysis may include determining whether the account holder has expressed interest in the object (e.g., product or service) of the transaction or the merchant, and/or determining whether the transaction is consistent with spending patterns associated with the account holder (e.g., spending patterns identified using the account holder's transaction records), for example. In the case of multiple account holders (e.g. multiple credit or debit card holders), accuracy may be improved by identifying spending patterns at the individual level rather than, or in addition to, at the aggregate account level. For example, a maximum amount of money typically spent in a single transaction (e.g., over the course of a one-month window, etc.) may be determined for each of two cardholders listed on a single account, and the maximum amount for the cardholder who purportedly made a particular purchase may be compared to the purchase amount to determine whether fraud is suspected.
• In another exemplary embodiment, financial transaction data may be analyzed to determine whether a chargeback payment from the merchant or acquiring bank to a card issuer may be appropriate in connection with a particular fraudulent transaction. For example, the card information entry mode (e.g., collecting card information by inserting the card in a chip reader, swiping the card, manually entering the card information, etc.), the transaction amount, the similarity to other transaction(s), and/or other information may be used to identify which fraudulent transactions are relatively strong chargeback candidates. The analysis may be performed in response to a cardholder reporting the transaction as fraudulent, or after a card issuer has confirmed that the transaction was fraudulent, for example. For the subset of instances where a fraudulent transaction has been identified as a chargeback candidate, a full set of chargeback rules (e.g., devised by a card network entity such as VISA®, Mastercard®, American Express®, Discover®, etc.) may be manually or automatically applied to determine whether a chargeback process should be initiated (or continued).
• In another exemplary embodiment, application data (e.g., information entered in fields of an online application) may be analyzed in conjunction with search terms entered by a user at a computing device (e.g., the device from which the user submitted the application information) to determine whether the person proffering the application is not the person that he or she purports to be. For example, if the person submitting an application had previously used an Internet-based search engine to search for results associated with the purported applicant's name (e.g., by using the name as a search term, possibly in addition to other terms such as “address” and/or “employer,” etc.), the application may be flagged for suspected fraud, and subjected to additional steps of manual and/or automated review.
• In another exemplary embodiment, a fraud dispute resolution process (e.g., after a customer has reported a fraudulent or unrecognized transaction associated with his or her account) may be facilitated using machine learning techniques. For example, a machine learning program may be trained, using past dispute resolution interactions with customers and the associated outcomes (fraud determinations), to identify various types of information that, if elicited from customers, tend to be indicative of fraud or the absence thereof. When fraud is suspected for a particular transaction, one or more queries for the individual purportedly making the transaction may be automatically generated using the types of information identified by the machine learning program, as well as information about the suspect transaction and/or related transactions (e.g., dates, locations, amounts, etc.). In some embodiments and/or scenarios, responses to the queries may be collected and analyzed to automatically generate additional queries, with the end goal of discerning whether the transaction was authorized. For example, queries may include asking whether a cardholder recalls particular other transactions that appear on the cardholder's account and were made around the same time as the suspect transaction (and/or from the same merchant), asking whether the cardholder recalls being in a particular location at a particular time (e.g., a location associated with another transaction appearing on the cardholder's account), whether the cardholder is aware of a particular billing alias used by a merchant, and so on.
• In another exemplary embodiment, image data corresponding to a particular physical document (e.g., a personal or cashier's check, a driver's license or other identification card, etc.) may be analyzed, using rules generated by a machine learning program, to determine whether the document is, or may be, fraudulent (e.g., a counterfeit document, and/or a document that includes forged contents). For example, the machine learning program may be trained using images of multiple other documents, and fraud determinations made in connection with those other documents. The machine learning program may learn which ranges and/or tolerances for dimensions, fonts, colors, patterns, etc., tend to be most indicative of counterfeiting, for example. A forgery may be detected based upon factors relating to the contents of various fields in a document, such as whether handwriting, a signature, and/or a date format (e.g., “Jan. 1, 2016,” “1/1/16,” etc.) matches that used for other personal checks from a particular account holder, for example. The fraud determination may be made substantially in real-time to provide a warning, if needed, to a merchant making a sale, for example, or may be used to flag a relatively small number of documents for physical review at a later time, etc.
• In another exemplary embodiment, machine learning techniques may be used to analyze financial transactions for purposes of classifying potentially fraudulent behavior (e.g., “counterfeiting,” “skimming,” “lost or stolen card,” etc.). For example, the machine learning program may be trained using fraud classifications made in connection with multiple other financial accounts. The machine learning program may learn which types of data tend to be indicative of different classifications (e.g., transaction amount, credit card information entry mode, particular types of online activity data, etc.), and/or which data values tend to be indicative of different classifications (e.g., transactions over $10,000, manual card number entry, etc.), for example. Once a class of potential fraud has been identified for a particular transaction, the classification may be used to facilitate or guide a further, more in-depth analysis or investigation. Alternatively, or in addition, the classification may be used to calculate one or more metrics indicating the prevalence of that type of fraud.
• By replacing conventional processing techniques with one or more of the processing techniques described herein, problems that have beset the field of fraud detection, classification and/or prevention in the past may be greatly mitigated or eliminated. For example, information that has conventionally been overlooked or ignored may be used to more accurately detect, prevent and/or classify fraud, and/or to reduce false positive fraud alerts. As another example, a significant amount of time may be saved by removing the need for manual investigations, or by reducing the number of instances where manual investigations are required.
II. Exemplary Environment for Implementing Fraud Detection and/or Classification Processing Techniques
• FIG. 1 depicts anexemplary environment10 in which techniques for fraud detection and/or classification may be implemented, according to one embodiment. Theenvironment10 may include an anti-fraud services system (AFSS)12, a financial account management system (FAMS)14, a cardnetwork computing system16, a number ofcardholder computing devices20, a number ofmerchant computing systems22, a number ofother sources24, and anetwork26. It is noted that, in other embodiments and/or scenarios, theenvironment10 may include more, fewer and/or different components than those shown inFIG. 1, such as any of those discussed elsewhere herein. For example, theenvironment10 may include one or more additional financial account management systems and/or card network computing systems, and/or one or more of thecardholder computing devices20 may instead be a computing device of a holder of a non-card account (e.g., a checking, savings or loan account) or an applicant for a new account (e.g., a new loan account). As another example, theenvironment10 may include a computing system of one or more acquiring/merchant banks, and some or all of the communications withmerchant computing systems22 described below may instead be with the acquiring bank(s).
• FAMS14 may be associated with (e.g., owned and/or maintained by) a bank or other financial entity. For example,FAMS14 may be a bank that acts as a card issuer associated with a particular type of card network (e.g., VISA®, Mastercard®, etc.), and/or an entity that provides loans (e.g., mortgage, home equity, vehicle, etc.), saving/checking account services, and/or other financial services to customers.FAMS14 may maintain anaccount records database30 that stores various kinds of account information, including account holder information (e.g., names, addresses, etc.) and data indicative of financial transactions made in connection with each account (e.g., dates, amounts and merchants for credit or debit card transactions, dates and amounts for customer deposits and withdrawals, etc.).Account records database30 may store account information for some or all of the cardholders associated withcardholder computing devices20, for example. While shown inFIG. 1 as a single entity withinFAMS14, it is understood thataccount records database30 may, in some embodiments, be distributed across multiple databases and/or multiple physical/hardware memories, and/or may be wholly or partially external to (e.g., remote from)FAMS14.
• AFSS12 may generally provide services that help to detect and/or classify fraudulent activity in connection with existing and/or potential (e.g., applied for) financial accounts, such as the accounts managed byFAMS14. In some embodiments,AFSS12 is included withinFAMS14. As seen inFIG. 1,AFSS12 may include anetwork interface32, amemory34, and a fraud detection/classification unit36.
• Network interface32 may include hardware, firmware and/or software configured to enableAFSS12 to wirelessly exchange electronic data with one or more other components ofenvironment10 vianetwork26. For example,network interface32 may include an Ethernet port, a modem, a router, and/or one or more other ports and/or transceivers for one or more other wired and/or wireless communication technologies.
• Memory34 may be a computer-readable, non-transitory storage unit or device, or collection of units/devices, and may include persistent (e.g., hard disk) and/or non-persistent memory components.Memory34 may store instructions that are executable on one or more processors of AFSS12 (not shown inFIG. 1) to perform various operations, including the instructions of various software applications and data generated and/or used by such applications.
• Cardnetwork computing system16 may be a computing system (e.g., one or more servers) of a credit and/or debit card network entity, such as VISA® or Mastercard®, for example. In some embodiments and/or scenarios where the card network entity also acts as the issuer (e.g., American Express® or Discover®), cardnetwork computing system16 may includeFAMS14. Cardnetwork computing system16 may provide various services toFAMS14 and/orAFSS12. For example, cardnetwork computing system16 may provide electronic updates to chargeback rules, fraud scores for particular customers and/or transactions, and so on.
• Each ofcardholder computing devices20 may be a computing device of a respective holder of a credit or debit card account managed byFAMS14. For example, one or more ofcardholder computing devices20 may be desktop computers, laptop computers, tablet computers, smartphones, smart watches, and so on. The cardholders (e.g., credit or debit card account holders) may usecardholder computing devices20 to access (e.g., view, modify, etc.) their account information stored inaccount records database30 online vianetwork26. In some embodiments whereAFSS12 detects and/or classifies activity not related to credit or debit card fraud (e.g., a fraudulent application for a home equity loan, etc.),cardholder computing devices20 may instead be computing devices of other types of customers or potential customers, such as holders of non-card-based accounts, or individuals who have submitted an online application for a loan, etc., as discussed further below. In some of these embodiments, theenvironment10 may omit cardnetwork computing system16.
• Each ofmerchant computing systems22 may include one or more computing devices associated with a particular provider of products and/or services. For example, some or all ofmerchant computing systems22 may include servers associated with online retailers. Alternatively, or additionally, some or all ofmerchant computing systems22 may include point-of-sale terminal devices providing credit and/or debit card payment processing features for “card present” transactions. In some embodiments whereAFSS12 detects and/or classifies activity not related to customer purchases (e.g., ifAFSS12 only detects loan application fraud, etc.), theenvironment10 may omitmerchant computing systems22.
• Theother sources24 may include computing devices and/or systems associated with sources of one or more other types of information. For example,other sources24 may include vehicle telematics systems (e.g., installed in vehicles of cardholders associated with cardholder computing devices20), one or more Internet service providers (ISPs) (e.g., ISPs providing Internet access to some or all cardholders), “smart home” system devices (e.g., installed in homes of some or all cardholders), and/or other systems/devices. In some embodiments, theenvironment10 does not include theother sources24.
• Network26 may communicatively couple some or all of the components shown inFIG. 1. For example,FAMS14 may usenetwork26 to communicate withAFSS12, cardnetwork computing system16,cardholder computing devices20 and/ormerchant computing systems22. As another example,AFSS12 may usenetwork26 to communicate withFAMS14, cardnetwork computing system16,cardholder computing devices20,merchant computing systems22 and/or one or more of theother sources24. While shown as a single entity inFIG. 1,network26 may include multiple communication networks of one or more types (e.g., one or more wired and/or wireless local area networks (LANs), and/or one or more wired and/or wireless wide area networks (WANs) such as the Internet). Moreover,network26 may use partially or entirely distinct network components to support communications between different endpoints or computing devices, such as wireless communication or data transmission over one or more radio frequency links and/or wireless communication channels. For example, the portion(s) ofnetwork26 used for communications betweenFAMS14 andAFSS12 may be the same as, or different than, the portion(s) ofnetwork26 used for communications betweenFAMS14 and one or more ofcardholder computing devices20 over one or more radio links or wireless communication channels, or betweenAFSS12 and one or more of theother sources24, etc. Those skilled in the art will appreciate different types of networks that are appropriate fornetwork26, depending upon, for example, howAFSS12,FAMS14 and/or other components ofenvironment10 are localized or distributed across a relatively large geographic area.
• Generally, fraud detection/classification unit36 ofAFSS12 may detect fraudulent activity, confirm whether suspected or reported fraudulent activity is truly fraudulent, and/or classify fraudulent or suspected fraudulent activity. For example, fraud detection/classification unit36 may analyze each transaction stored inaccount records database30 to determine whether that transaction is, or potentially is, fraudulent. Alternatively, fraud detection/classification unit36 may analyze only those transactions that were flagged as possibly being fraudulent (e.g., by a cardholder calling in to report an unauthorized and/or unrecognized transaction, or byFAMS14 orAFSS12 generating a preliminary fraud alert after applying an initial set of rules to a transaction, etc.). Fraud detection/classification unit36 may also, or instead, support additional functionality, such as that described below in connection with the various components of fraud detection/classification unit36 shown inFIG. 1.
• As seen inFIG. 1, fraud detection/classification unit36 may include a machine learning (ML)rule generator40, an externaldata collection unit42, abehavior analysis unit44, adispute resolution unit46, achargeback analysis unit50, animage analysis unit52, aclassification unit54, and/or anotification unit56. In other embodiments, fraud detection/classification unit36 may include more, fewer and/or different components/units than those shown inFIG. 1. In some embodiments, each ofML rule generator40, externaldata collection unit42,behavior analysis unit44,dispute resolution unit46,chargeback analysis unit50,image analysis unit52,classification unit54,notification unit56, and/or other units or components of fraud detection/classification unit36 may be a software component stored inmemory34 and implemented by one or more processors of one or more computing devices (e.g., servers) included inAFSS12.
• ML rule generator40 may generally analyze various types of data to generate and/or update fraud detection and/or classification rules to be applied by fraud detection/classification unit36 and stored in an ML rulesdatabase58. As discussed in further detail below, the rules may be used to detect and/or classify a single type or category of fraudulent activity, or may be used broadly in connection with multiple types or categories of fraudulent activity.ML rule generator40 may implement any suitable type or types of machine learning. For example,ML rule generator40 may implement supervised learning techniques, such as decision trees, regression-based models, support vector machines (SVMs) and/or neural networks, and/or unsupervised learning techniques such as Dirichlet process mixture models and/or k-means clustering. Other machine learning techniques are also possible, such as techniques utilizing Bayesian networks, “deep learning” techniques, and so on. While shown inFIG. 1 as a single entity withinAFSS12, it is understood that ML rulesdatabase58 may, in some embodiments, be distributed across multiple databases and/or multiple physical/hardware memories, and/or may be wholly or partially external to (e.g., remote from)AFSS12.
• Externaldata collection unit42 may generally collect, vianetwork interface32 and/or from sources internal toAFSS12, information from various sources (e.g.,FAMS14,cardholder computing devices20,other sources24, etc.), and provide that data to other portions ofAFSS12 as needed (e.g., toML rule generator40 to generate and/or update rules, and/or tobehavior analysis unit44,dispute resolution unit46,chargeback analysis unit50,image analysis unit52 and/orclassification unit54 to detect and/or classify fraudulent activity). Some data may be collected indirectly. For example,FAMS14 may collect transaction data from merchant computing systems22 (and/or from acquiring banks associated with one or more of merchant computing systems22), and externaldata collection unit42 may then collect that data from theaccount records database30 ofFAMS14.
• Once an initial set of rules has been generated and stored inML rules database58, those rules may dictate some or all of the types of data gathered by externaldata collection unit42. In some embodiments, however, externaldata collection unit42 collects a broad set of data types that may or may not be relevant to fraud determination or classification, andML rule generator40 continually analyzes that data to determine which data types are most predictive of fraud and/or fraud type/class.
• Behavior analysis unit44 may generally analyze cardholder-related (or other customer-related) information to identify patterns of behavior, which may then be used by fraud detection/classification unit36 to detect and/or classify fraudulent activity. For example,behavior analysis unit44 may analyze information obtained fromaccount records database30 to identify spending patterns associated with different cardholders. The operation ofbehavior analysis unit44, including the types of information analyzed and the ways in which that information is used to arrive at a result (e.g., a pattern of behavior), may be dictated by the rules stored inML rules database58.
• Data indicative of the behavior patterns identified bybehavior analysis unit44 may be stored in an accountholder behaviors database60, for example. While shown inFIG. 1 as a single entity withinAFSS12, it is understood that accountholder behaviors database60 may, in some embodiments, be distributed across multiple databases and/or multiple physical/hardware memories, and/or may be wholly or partially external to (e.g., remote from)AFSS12. In one embodiment, for example, accountholder behaviors database60 may be included withinaccount records database30. In still other embodiments, theenvironment10 may not include accountholder behaviors database60, and behavior patterns may be only identified bybehavior analysis unit44 “on the fly” as needed by fraud detection/classification unit36 (e.g., when needed to analyze a transaction in view of past spending patterns of a particular cardholder, etc.).
• In some embodiments,behavior analysis unit44 may separately analyze the transactions associated with each account holder, even if more than one account holder exists for a particular account. For example,behavior analysis unit44 may independently analyze the transactions of each cardholder for a credit or debit card account in which each spouse has been issued a credit or debit card in his or her name. Fraud detection/classification unit36 may then utilize the individual spending patterns when detecting and/or classifying fraud. In one embodiment where fraud detection/classification unit36 utilizes a dollar amount threshold to detect likely fraudulent transactions, for example, a first threshold may be used for transactions made by a first cardholder listed on an account, and a higher, second threshold may be used for transactions made by a second cardholder listed on the account. Further examples are provided below in connection withFIG. 6, according to various embodiments. In this manner, fraud detection and/or classification may be made more precise than would be the case if spending patterns were only identified at the aggregate level (e.g., using a single dollar amount threshold, regardless of which cardholder made a particular transaction).
• Dispute resolution unit46 may generally analyze financial transaction data and/or other information to automatically generate queries for cardholders or other customers. For example,dispute resolution unit46 may analyze information obtained fromaccount records database30. The generated queries may be designed to help fraud detection/classification unit36 determine whether a particular transaction was fraudulent, or estimate a probability that the transaction was fraudulent, etc.Dispute resolution unit46 may also process responses from cardholders/customers, and automatically generate additional queries based upon those responses. Examples of the operation ofdispute resolution unit46 are provided below in connection withFIGS. 4E and 9, according to various embodiments.
• Chargeback analysis unit50 may generally analyze financial transaction and/or other information to identify transactions that are good candidates for chargeback payments. For example,chargeback analysis unit50 may analyze information obtained fromaccount records database30 to determine whether there is a relatively high probability that the merchant (or an acquiring bank) should be responsible for a chargeback payment to a card issuer associated withFAMS14. The operation ofchargeback analysis unit50, including the types of information analyzed and the ways in which that information is used to arrive at a result (e.g., flagging a transaction as a chargeback candidate), may be dictated by the rules stored inML rules database58.ML rule generator40 may make use of chargeback rules obtained from a card network entity (e.g., from card network computing system16), and stored inchargeback rules database62, to generate and/or update the rules applied bychargeback analysis unit50. Examples of the operation ofchargeback analysis unit50 are provided below in connection withFIGS. 4B and 7, according to various embodiments.
• In some embodiments, transactions flagged bychargeback analysis unit50 are subject to further, manual review using the chargeback rules stored inchargeback rules database62. In other embodiments, chargeback analysis unit50 (or another component of fraud detection/classification unit not shown inFIG. 1) automatically, with little or no manual input/assistance, applies the chargeback rules fromchargeback rules database62 for each flagged transaction. While shown inFIG. 1 as a single entity withinAFSS12, it is understood thatchargeback rules database62 may, in some embodiments, be distributed across multiple databases and/or multiple physical/hardware memories, and/or may be wholly or partially external to (e.g., remote from)AFSS12.
• Image analysis unit52 may generally analyze image data corresponding to physical documents to identify fraudulent (e.g., counterfeit and/or forged) documents, and/or to flag potentially fraudulent documents for further (e.g., manual) review. For example,image analysis unit52 may analyze information obtained frommerchant computing systems22 to determine whether there is a relatively high probability that documents presented to the merchants (e.g., personal checks, identification cards, etc.) are fraudulent.Image analysis unit52 may be configured to analyze only a single type of document, or multiple types of documents. The operation ofimage analysis unit52, including the image characteristics analyzed and the ways in which the characteristics may be used to arrive at a result (e.g., flagging a document as potentially fraudulent), may be dictated by the rules stored inML rules database58. Examples of the operation ofimage analysis unit52 are provided below in connection withFIGS. 4F and 10, according to various embodiments.
• Classification unit54 may generally analyze broad categories of data from various sources (e.g.,account records database30,cardholder computing devices20,merchant computing systems22, and/or other sources24) to categorize/classify types of suspected fraudulent financial activity.Classification unit54 may classify fraudulent activity only within a particular subset of fraudulent financial activity (e.g., classifying debit and/or credit card transactions as involving a potential case of counterfeiting, skimming, lost/stolen card use, chargeback fraud, etc.), or may classify fraudulent financial activity across a broader spectrum (e.g., including types of identity theft not necessarily tied to a single financial transaction, such as application fraud). In some embodiments,classification unit54 classifies suspected fraudulent activity in connection with a particular account or transaction in response to being notified of suspect activity (e.g., notified by another component of fraud detection/classification unit36, or by a manual user input, etc.). In other embodiments,classification unit54 itself (or another component of fraud detection/classification unit36) identifies suspect activity beforeclassification unit54 classifies that activity. Examples of the operation ofclassification unit54 are provided below in connection withFIGS. 4C and 11, according to various embodiments.
• Notification unit56 may generally provide alerts, confirmations, and/or other notifications to various individuals (e.g., customers, bank employees associated withFAMS14, third party employees associated withAFSS12, etc.). For example,notification unit56 may generate a notification message stating that a fraud alert associated with a particular transaction is a false positive, andcause network interface32 to send the message to a computer terminal or toFAMS14 for display to a system user. As another example,notification unit56 may causenetwork interface32 to send other flagged transactions and/or documents (e.g., chargeback candidates identified bychargeback analysis unit50, documents thatimage analysis unit52 has identified as potentially fraudulent, etc.) to a computer terminal orFAMS14 for display to a system user. As yet another example,notification unit56 may causenetwork interface32 to send queries generated bydispute resolution unit46 to various ones ofcardholder computing devices20 for display to cardholders.
• The operation of various components of theenvironment10 shown inFIG. 1, according to different embodiments and/or scenarios, will be described further below in connection with the remaining figures.
III. Exemplary Process Flows for Machine Learning of Fraud Detection and/or Classification Rules
• As discussed above,ML rule generator40 may generate and/or update rules that are used for one or more of a variety of different purposes relating to fraud detection and/or classification.FIG. 2 depicts one generalized, example process flow80 for machine learning that may be implemented byML rule generator40, and possibly one or more other components of fraud detection/classification unit36.
• In theprocess flow80,multi-account data82 may represent data associated with multiple financial accounts, each with one or more account holders. The financial accounts may be existing or potential accounts, and the account holders may include holders of accounts and/or potential holders of potential accounts. For example, themulti-account data82 may include existing and/or applied-for credit card accounts, debit card accounts, savings accounts, checking accounts, investment accounts, loan accounts, etc.
• Depending upon the embodiment, themulti-account data82 may include one or more different types of information obtained (e.g., by externaldata collection unit42 ofFIG. 1) from one or more ofFAMS14,cardholder computing devices20,merchant computing systems22, and/orother sources24. For example, themulti-account data82 may include transaction data (e.g., transaction dates, amounts, locations, etc.) fromaccount records database30 ofFAMS14, data indicative of Internet Protocol (IP) addresses ofcardholder computing devices20 and/or devices inmerchant computing systems22, Internet browsing and/or search history data from cardholder computing devices20 (or from an ISP computer system included inother sources24, etc.), vehicle telematics data from telematics systems of cardholder vehicles, home occupancy and/or usage data (e.g., smart appliance data) from smart home systems of cardholders, autonomous or smart vehicle data, vehicle navigation system data, mobile device data, mobile device and/or vehicle GPS data, and/or one or more other types of data. In some embodiments, themulti-account data82 only includes data that account holders or potential account holders have expressly consented to share with an entity associated withFAMS14 and/or AFSS12 (e.g., in exchange for fraud protection services). In certain other embodiments, however, express consent is only needed for certain types of information, such as browsing history information, vehicle telematics data, etc.
• Themulti-account data82 may be associated with multiple fraud determination labels. The labels may simply reflect whether or not fraud existed (e.g., “fraud” or “no fraud”), or may also indicate a type or class of fraud (e.g., “counterfeiting,” “lost or stolen card use,” etc.), for example. In one embodiment, each of a number of data sets in themulti-account data82 is associated with such a label, and includes data relating to a particular financial transaction, financial account, loan application, etc., for which the fraud determination was made (e.g., after a manual and/or automated fraud investigation). The labels may include final fraud determinations that were made via earlier iterations of theprocess flow80, and/or external to theprocess flow80.
• To provide a more detailed example, a first data set associated with a “card present” credit card transaction may include data describing that transaction (e.g., from account records database30) and data indicative of the cardholder's online browsing activity (e.g., from one of cardholder computing devices20) for the 15 days immediately preceding the transaction, and be labeled “confirmed fraud.” A second data set, associated with another “card present” transaction (for the same account, or for a different account), may include the same general types of data but be labeled “no fraud,” and so on. In some embodiments and/or scenarios, the same data may appear in, or be used by, two or more of the data sets. If the two “card present” transactions described above are both associated with the same account, for example, and if the second transaction occurred less than 15 days after the first transaction, some of the same online activity data may be shared by the first and second data sets.
• At aprocess stage84, themulti-account data82 may be analyzed to generate fraud detection and/or classification rules (e.g., to be stored in ML rules database58). Any suitable type of supervised machine learning program/technique(s) may be used, such as SVMs, neural networks, logistic regression, etc. Generally,process stage84 may serve to identify which type(s) of data is/are probative of whether fraud has occurred (and/or the type/category of fraud that may have occurred), and to determine the data values and/or combinations that are probative of whether fraud has occurred (and/or the type/category of fraud that may have occurred). By analyzing many (e.g., thousands) of positively and negatively labeled data sets in themulti-account data82, for example,process stage84 may learn that certain spending patterns within a threshold time of a transaction tend to indicate that the cardholder made the transaction (e.g., thereby indicating that fraud has not occurred, or that a fraud report is itself fraudulent or mistaken, etc.), that certain types of online searches by a cardholder (e.g., including a descriptor of a product purchased in the transaction, or a name of the merchant, etc.) tend to indicate that the cardholder made the transaction, that the cardholder's distance from the site of a “card present” transaction (e.g., as determined from GPS information provided by the cardholder's smartphone, wearable electronics, or vehicle) relates to the probability of fraudulent activity according to a particular equation, and so on. Other specific examples of such rules, and how those rules may be generated, are discussed below in connection withFIGS. 3A-3F and 4A-4F, according to various embodiments.
• Atprocess stage86, the rules generated or updated atprocess stage84 may be applied tofirst account data90 associated with a particular account and customer(s) (e.g., a customer associated with a particular one of computing devices20). The types of data included infirst account data90 may depend upon which types of data were determined, byprocess stage84, to be relevant to a fraud determination. For example, if the rules give weight to the amount and date of a financial transaction when determining whether the transaction is fraudulent, and also give weight to whether the account holder visits a particular type of website, then thefirst account data90 may include the amount and date of one or more transactions, as well as data indicative of visited web sites (e.g., Uniform Resource Locators (URLs) and/or content of visited websites, etc.). Thefirst account data90 may include information obtained (e.g., by external data collection unit42) from one or more ofFAMS14, one ofcardholder computing devices20 associated with the customer holding the first account, one or more ofmerchant computing systems22, and/or one or more ofother sources24, for example.
• Process stage86 may output various different types of information, depending upon the embodiment and/or scenario. For example, depending upon the content offirst account data90 and the rules generated or updated atprocess stage84,process stage86 may generate data indicating that a particular financial transaction associated withfirst account data90 is, or is not, fraudulent or potentially fraudulent. Alternatively, or additionally,process stage86 may generate data indicating a particular classification for fraudulent or suspected fraudulent activity (e.g., a fraudulent transaction) associated withfirst account data90.
• In some embodiments, further analysis (e.g., a manual review, or further automated review using additional data sources, etc.) may be performed at an additional stage, shown in dashed lines inFIG. 2 asprocess stage92. The additional analysis may then be used to make a final fraud determination (e.g., a final decision on whether fraud occurred, and/or on the type of fraud that occurred) atprocess stage94. In other embodiments,process stage92 is omitted fromprocess flow80, andprocess stage94 merely represents the output ofprocess stage86. The final determination made atprocess stage94, along with thefirst account data90 used to make that determination, may be fed back intoprocess stage84 to provide additional labeled data for purposes of updating the rules.
• In some embodiments, theprocess flow80 includes more, fewer and/or different stages, such as any of those discussed elsewhere herein (e.g., in connection withFIGS. 3A-3F). In one alternative embodiment, process stages84 and86 may be combined. For example, themulti-account data82 may be unlabeled rather than labeled (or the labels may be ignored), and the combinedprocess stage84,86 may use unsupervised learning techniques (e.g., clustering techniques) to classify anomalous/outlier financial transactions, accounts, applications, etc., as “suspect” and needing further analysis.
• More specific, machine learning-based process flows generally corresponding to processflow80 ofFIG. 2 will now be described with reference toFIGS. 3A-3F. It is noted, however, that other process flows are also within the scope of the invention described herein. Moreover, whileFIGS. 3A-3F generally correspond to embodiments in which supervised machine learning techniques are used, other embodiments may instead use unsupervised machine learning techniques, as noted above. In various different embodiments, fraud detection/classification unit36 may be configured to implement only one of the process flows ofFIGS. 3A-3F, or may be configured to implement two or more (e.g., all) of the process flows shown inFIGS. 3A-3F.
A. Exemplary Process Flow for Machine Learning of Fraud Detection Rules Using Online Activity Data
• Referring first toFIG. 3A, anexemplary process flow100 may generally be used to detect fraud using customer online activity data. In theprocess flow100, multi-customeronline activity data102 may represent data associated with the online activities of a number (e.g., thousands) of customers (e.g., credit or debit cardholders, checking or saving account holders, etc.). The multi-customeronline activity data102 may include data indicating actions that the customers took, and/or web sites visited by the customers, while the customers were connected to the Internet via web browsers (e.g., executing on respective ones of cardholder computing devices20). For example, the multi-customeronline activity data102 may include URLs of, and/or content (e.g., text) within, web sites visited by customers, search terms entered by customers using search engine tools, search results presented to customers by search engine tools, indications of interactive controls (e.g., virtual buttons) selected by customers on various web pages, and so on.
• The multi-customeronline activity data102 may include data obtained (e.g., by externaldata collection unit42 ofFIG. 1) fromcardholder computing devices20, from one or more ISPs ofother sources24, and/or from a third party aggregator of such information, for example. In some embodiments, the multi-customeronline activity data102 may only include data that customers have expressly consented to share with an entity associated withFAMS14 and/or AFSS12 (e.g., in exchange for fraud protection services or other benefits, such as discounts).
• As described above in connection withmulti-account data82 ofprocess flow80, the multi-customeronline account data102 may be associated with multiple fraud determination labels. In some embodiments, each label may be associated with a data set that includes not only the corresponding portion of multi-customeronline activity data102, but also one or more other types of data, such as transaction data (e.g., transaction dates, amounts, locations, etc.) for each customer fromaccount records database30 ofFAMS14, data indicative of IP addresses ofcardholder computing devices20 and/or devices inmerchant computing systems22, Internet browsing and/or search history data from cardholder computing devices20 (or from an ISP computer system included inother sources24, etc.), vehicle telematics data from telematics systems ofother sources24, home occupancy and/or usage data (e.g., smart appliance data) from smart home systems ofother sources24, and so on. The labels may include final fraud determinations that were made via earlier iterations of theprocess flow100, and/or external to theprocess flow100. Multi-customeronline account data102 may include many (e.g., thousands) of positively and negatively labeled data sets.
• At aprocess stage104, the multi-customeronline activity data102 may be analyzed to generate fraud detection rules (e.g., to be stored in ML rules database58). As described above in connection withprocess stage84 ofprocess flow80, any suitable type of supervised machine learning program/technique(s) may be used. Generally,process stage104 may serve to identify which type(s) of online activity data is/are probative of whether fraud has occurred, and to determine the data values and/or combinations that are probative of whether fraud has occurred. While not shown inFIG. 3A, the fraud detection rules may not only detect fraud, but also classify fraud (e.g., as described below in connection withFIG. 3C), in some embodiments.
• Atprocess stage106, the rules generated or updated atprocess stage104 may be applied to first customeronline activity data110. The first customeronline activity data110 may be associated with a particular customer, such as a customer associated with a particular one ofcomputing devices20, for example. The types of data included in first customeronline activity data110 may depend upon which types of online activity data were determined, byprocess stage104, to be relevant to a fraud determination. For example, the first customeronline activity data110 may include information obtained (e.g., by external data collection unit42) from one of cardholder computing devices20 (i.e., the device associated with the first customer), and/or from an ISP ofother sources24. Some specific examples of rules that may be generated byprocess stage104, and applied atprocess stage106, are described below in connection withFIG. 4A.
• Process stage106 may output various different types of information, depending upon the embodiment and/or scenario. For example, depending upon the content of first customeronline activity data110 and the rules,process stage106 may generate data indicating that a particular financial transaction associated with the first customer is, or is not, fraudulent or potentially fraudulent. Alternatively, or additionally,process stage106 may generate data indicating a particular classification of fraudulent or potentially fraudulent activity associated with first customeronline activity data110.
• In some embodiments, further analysis (e.g., a manual review, or further automated review using additional data sources, etc.) is performed at an additional stage, shown in dashed lines inFIG. 3A asprocess stage112. The additional analysis may then be used to make a final fraud determination (e.g., a final decision on whether fraud occurred, and/or on the type of fraud that occurred) atprocess stage114. In other embodiments,process stage112 is omitted fromprocess flow100, andprocess stage114 merely represents the output ofprocess stage106.
• The final determination made atprocess stage114, along with the first customer online activity data110 (and any other data) used to make that determination, may be fed back intoprocess stage104 to provide additional labeled data for purposes of updating the rules. In some embodiments, a preliminary fraud determination made atprocess stage106 is also fed back intoprocess stage104, to allow the machine learning program to determine and improve upon past performance/accuracy.
B. Exemplary Process Flow for Machine Learning of Chargeback Candidate Detection Rules
• Referring next toFIG. 3B, anexemplary process flow120 may generally be used to identify the financial transactions for which chargebacks (e.g., post-transaction payments from merchants, or acquiring/merchant banks, back to the issuer to return proceeds from transactions) are appropriate. In theprocess flow120,multi-account transaction data122 may represent data associated with the financial transactions involving the accounts of a number (e.g., thousands) of credit or debit cardholders. Themulti-account transaction data122 may include information such as transaction dates, transaction amounts, merchant names (and/or aliases) associated with the transaction, information relating to how the card information was collected by the merchant (e.g., by swiping, an EMV chip reader, manual entry of the card number, etc.), geographic locations of “card present” transactions, and so on. Themulti-account transaction data122 may include data obtained (e.g., by externaldata collection unit42 ofFIG. 1) frommerchant computing systems22 and/or from acquiring/merchant banks associated with those merchants, for example.
• Similar to the labels described above in connection withmulti-account data82 ofprocess flow80, themulti-account transaction data122 may be associated with multiple chargeback outcome labels. For example, each label may be associated with a data set that includes the corresponding portion ofmulti-account transaction data122. The outcome labels may include final chargeback determinations that were made (in connection with the transactions represented in multi-account transaction data122) via earlier iterations of theprocess flow120, and/or external to theprocess flow120.Multi-account transaction data122 may include many (e.g., thousands) of positively and negatively labeled data sets.
• At aprocess stage124, themulti-account transaction data122 may be analyzed to generate chargeback candidate detection rules (e.g., to be stored in ML rules database58). As described above in connection withprocess stage84 ofprocess flow80, any suitable type of supervised machine learning program/technique(s) may be used. Generally,process stage124 may serve to identify which type(s) of transaction data is/are probative of whether, under the full chargeback rules of the card network entity, a chargeback is appropriate for a given transaction.Process stage124 may also determine the transaction data values and/or combinations that are probative of whether a chargeback is appropriate for the transaction.
• At aprocess stage126, the rules generated or updated atprocess stage124 may be applied to firstaccount transaction data130 to determine whether a transaction associated with the first account is a “good” chargeback candidate. Put differently,process stage126 may, instead of applying the full chargeback rules of the card network entity (which may be quite lengthy and complex) to the facts surrounding the transaction, use various factors and algorithms developed atprocess stage124 to determine whether there exists a relatively high probability that a chargeback would be appropriate for the transaction if the full chargeback rules were applied. Theprocess stage126 may calculate a percentage probability that the transaction is one in which a chargeback is appropriate, for example.
• The firstaccount transaction data130 may be associated with the account of a particular cardholder or cardholders, such as a cardholder associated with a particular one ofcardholder computing devices20, for example. The types of data included in firstaccount transaction data130 may depend upon which types of transaction-related data were determined, byprocess stage124, to be relevant to a chargeback candidate determination. For example, the firstaccount transaction data130 may include information obtained (e.g., by external data collection unit42) from one of merchant computing systems22 (e.g., the computing system of the merchant involved in the transaction being analyzed) and/or from an acquiring/merchant bank associated with that merchant. The firstaccount transaction data130 may also include information about one or more other transactions associated with the first account (e.g., data pertaining to other transactions occurring shortly before and/or after the transaction at issue). Some specific examples of rules that may be generated byprocess stage124, and applied atprocess stage126, are described below in connection withFIG. 4B.
• Process stage126 may output information indicating whether the particular transaction represented by firstaccount transaction data130 is a “good” candidate for chargeback detection. For example,process stage126 may output a percentage probability, calculated according to the rules generated or updated atprocess stage124, that the transaction is one in which a chargeback is appropriate. As another example,process stage126 may output a binary indicator of whether the transaction is, or is not, a strong/likely chargeback candidate (e.g., by comparing the percentage probability to a threshold probability).
• If the transaction is identified as a chargeback candidate atprocess stage126, the full chargeback rules of the card network entity may be applied at aprocess stage132.Process stage132 may include manual application of the full chargeback rules, and/or automated application of the full chargeback rules, in various different embodiments. Based upon the analysis atprocess stage132, a final chargeback determination may be made at aprocess stage134. The final determination made atprocess stage134, along with the first account transaction data130 (and any other data) used to make that determination, may be fed back intoprocess stage124 to provide additional labeled data for purposes of updating the rules. In some embodiments, the indication of whether the transaction is a good chargeback candidate generated atprocess stage126 may also be fed back intoprocess stage124, to allow the machine learning program to determine and improve upon past performance/accuracy.
C. Exemplary Process Flow for Machine Learning of Fraud Classification Rules
• Referring now toFIG. 3C, anexemplary process flow140 may generally be used to classify instances of suspected or potential fraud. For example, theprocess flow140 may represent ongoing, real-time or batch processing of a large amount of data associated with a large number of potential and/or existing financial accounts (e.g., all accounts associated with a particular bank, or all accounts opting in to a fraud protection program, etc.). In this manner, theprocess flow140 may be used to initially flag situations for closer investigation, and provide one or more classifications of the type(s) of fraud potentially at issue in order to narrow or otherwise facilitate the investigation. In other embodiments, theprocess flow140 may be used to provide a narrower classification (e.g., “skimming”) when a broader class of fraud (e.g., credit card fraud) is already suspected.
• In theprocess flow140,multi-account data142 may represent data associated with financial accounts of a number (e.g., thousands) of account holders. The financial accounts may be existing or potential accounts, and the account holders may include holders of accounts and/or potential holders of potential accounts. For example, themulti-account data142 may include existing and/or applied-for credit card accounts, debit card accounts, savings accounts, checking accounts, investment accounts, loan accounts, etc.
• Depending upon the embodiment, themulti-account data142 may include one or more different types of information obtained (e.g., by externaldata collection unit42 ofFIG. 1) from one or more ofFAMS14,cardholder computing devices20,merchant computing systems22, and/orother sources24. For example, themulti-account data142 may include transaction data (e.g., transaction dates, amounts, locations, etc.) fromaccount records database30 ofFAMS14, data indicative of IP addresses ofcardholder computing devices20 and/or devices inmerchant computing systems22, Internet browsing and/or search history data from cardholder computing devices20 (or from an ISP computer system included inother sources24, etc.), vehicle telematics data from telematics systems of cardholder vehicles, home occupancy and/or usage data (e.g., smart appliance data) from smart home systems of cardholders, and/or one or more other types of data. Some or all data withinmulti-account data142 may be information that account holders or potential account holders have expressly consented to share with an entity associated withFAMS14 and/or AFSS12 (e.g., in exchange for fraud protection services).
• Themulti-account data142 may be associated with multiple fraud determination labels, each indicating a type or class of fraud (e.g., “counterfeiting,” “lost or stolen card use,” “skimming,” “chargeback fraud,” “application fraud,” etc.), or indicating a lack of fraud, for example. In one embodiment, each of a number of data sets in themulti-account data142 is associated with at least one such classification/label, and includes data relating to a particular financial transaction, financial account, loan application, etc., for which the fraud classification or classifications was/were made (e.g., after a previous iteration ofprocess flow140, or after another manual and/or automated fraud investigation).Multi-account data142 may include many (e.g., thousands) of data sets labeled with various known fraud classifications.
• At aprocess stage144, themulti-account data142 may be analyzed to generate fraud classification rules (e.g., to be stored in ML rules database58). As described above in connection withprocess stage84 ofprocess flow80, any suitable type of supervised machine learning program/technique(s) may be used. Generally,process stage144 may serve to identify which type(s) of transaction data is/are probative of the particular type of fraud (if any) that has occurred.Process stage144 may also determine the data values and/or combinations that are probative of the particular type of fraud (if any) that has occurred.
• At aprocess stage146, the rules generated or updated atprocess stage144 may be applied tofirst account data150. Thefirst account data150 may be associated with a particular account and a particular customer (e.g., a cardholder associated with a particular one of computing devices20). The types of data included infirst account data150 may depend upon which types of data were determined, byprocess stage144, to be relevant to fraud classification. For example, thefirst account data150 may include information obtained (e.g., by external data collection unit42) from one or more ofFAMS14, one of cardholder computing devices20 (i.e., the device associated with the customer holding or applying for the first account), one or more ofmerchant computing systems22, and/or one or more ofother sources24. Some specific examples of rules that may be generated byprocess stage144, and applied atprocess stage146, are described below in connection withFIG. 4C.
• Process stage146 may output data (e.g., a message or code) that is used to classify suspected fraudulent activity (in connection with the account associated with first account data150) at aprocess stage152. For example,process stage152 may assign a classification of “counterfeiting” ifprocess stage146 determined that thefirst account data150 indicated a number of circumstances that, according to the rules generated atprocess stage144, are known to be correlated with counterfeiting activity (e.g., two “card present” transactions occurring in different states within the same one-hour time period, etc.). In some embodiments and/or scenarios, two or more classifications may concurrently be assigned tofirst account data150. For example,process stage146 may determine a set of probabilities for a set of two or more potential types of fraud, andprocess stage152 may assign each classification, with each respective probability, tofirst account data150. Moreover, in some embodiments and scenarios,process stage152 may assign a classification that corresponds to an absence of any suspected fraud (e.g., “no fraud”).
• At aprocess stage154, ifprocess stage152 assigned a classification other than one indicating the absence of suspected fraud, thefirst account data150, and/or other information associated with the account and the suspected class of fraud, may be analyzed in depth to make a final fraud determination at aprocess stage156. Generally, the fraud classification may be used to facilitate the analysis atprocess stage154, withprocess stage154 including manual and/or automated fraud detection techniques. For example, personnel associated withAFSS12 may use the fraud classification(s) to inform their strategy and/or focus with respect to conducting an in-depth fraud investigation.
• The additional analysis atprocess stage154 may then result in a final fraud determination atprocess stage156. The final determination may indicate both whether fraud occurred and, if so, the class(es)/type(s) of fraud that occurred. The final determination made atprocess stage156, and information used to make that determination (e.g., thefirst account data150 and potentially other data), may be fed back intoprocess stage144 to provide additional labeled data for purposes of updating the rules. In some embodiments, the (preliminary) fraud classification made atprocess stage152 may also be fed back intoprocess stage144 to help the machine learning program identify instances in which the preliminary classifications atprocess stage152 were incorrect.Process stage144 may then update the fraud classification rules in ways that seek to prevent or reduce such instances in the future.
D. Exemplary Process Flow for Machine Learning of Application Fraud Detection Rules
• Referring now toFIG. 3D, anexemplary process flow160 may generally be used to detect application fraud. “Application fraud” may generally refer to fraud in connection with the application for any type of financial account, loan and/or line of credit (e.g., mortgage loan, vehicle loan, small business loan, payday loan, home equity line of credit, credit card account, debit card account, checking account, savings account, investment account, etc.). In some embodiments and/or scenarios, however, the application may be for non-financial purposes, such as an application for membership in a particular group or institution, for example.
• In theprocess flow160, multi-applicantsearch history data162 may represent data associated with the Internet search history of a number (e.g., thousands) of applicants. The multi-applicantsearch history data162 may include search terms entered by the applicants using online search engine tools, for example, and/or the results of such searches (e.g., URLs, titles and/or contents of search results), for example.
• The multi-applicantsearch history data162 may include data obtained (e.g., by externaldata collection unit42 ofFIG. 1) fromcardholder computing devices20, from one or more ISPs ofother sources24, and/or from a third party aggregator of such information, for example. In some embodiments, the multi-applicantsearch history data162 only includes data that the applicants have expressly consented to share with an entity associated withFAMS14 and/or AFSS12 (e.g., in exchange for consideration of their applications).
• As described above in connection withmulti-account data82 ofprocess flow80, the multi-applicantsearch history data162 may be associated with multiple fraud determination labels. In some embodiments, each label may be associated with a data set that corresponds to an application submitted by a particular applicant, where the data set includes the corresponding portion of multi-applicant search history data162 (e.g., the search terms and/or results associated with the particular application). The labels may include final fraud determinations that were made via earlier iterations of theprocess flow160, and/or external to theprocess flow160. Multi-applicantsearch history data162 may include many (e.g., thousands) of positively and negatively labeled data sets.
• At aprocess stage164, the multi-applicantsearch history data162 may be analyzed to generate application fraud detection rules (e.g., to be stored in ML rules database58). As described above in connection withprocess stage84 ofprocess flow80, any suitable type of supervised machine learning program/technique(s) may be used. Generally,process stage164 may serve to identify which type(s) of Internet search-related data is/are probative of whether application fraud has occurred, and to determine the data values and/or combinations that are probative of whether application fraud has occurred.
• Atprocess stage166, the rules generated or updated atprocess stage164 may be applied to first applicantsearch history data170. The first applicantsearch history data170 may be associated with a particular application and a particular applicant (e.g., a person associated with a particular one of computing devices20), for example. The types of data included in first applicantsearch history data170 may depend upon which types of Internet search-related data were determined, byprocess stage164, to be relevant to a fraud determination. The first applicantsearch history data170 may include information obtained (e.g., by external data collection unit42) from one of computing devices20 (i.e., the device associated with the first applicant), and/or from an ISP ofother sources24, for example. Some specific examples of rules that may be generated byprocess stage164, and applied atprocess stage166, are described below in connection withFIG. 4D.
• Process stage166 may output information indicating whether fraud is suspected in connection with the application corresponding to first applicantsearch history data170. For example,process stage166 may output a percentage probability, calculated according to the rules generated or updated atprocess stage164, that the application was fraudulently made (e.g., by someone other than the purported applicant or an authorized representative thereof). As another example,process stage166 may output a binary indicator of whether the application likely was, or likely was not, fraudulently made (e.g., by comparing a percentage probability to a threshold probability).
• In some embodiments, further analysis (e.g., a manual review, or further automated review using additional data sources, etc.) is performed at an additional stage, shown in dashed lines inFIG. 3D asprocess stage172. The additional analysis may then be used to make a final fraud determination (e.g., a final decision on whether application fraud occurred) at process stage174. In other embodiments,process stage172 is omitted fromprocess flow160, and process stage174 merely represents the output ofprocess stage166. The final determination made at process stage174, along with the first applicant search history data170 (and any other data) used to make that determination, may be fed back intoprocess stage164 to provide additional labeled data for purposes of updating the rules. In some embodiments, a preliminary fraud determination made atprocess stage166 is also fed back intoprocess stage164, to allow the machine learning program to determine and improve upon past performance/accuracy.
E. Exemplary Process Flow for Machine Learning of Fraud Dispute Resolution Rules
• Referring now toFIG. 3E, anexemplary process flow180 may generally be used to facilitate the resolution of fraud disputes (or potential disputes) with customers/account holders. For example, theprocess flow180 may be used to determine whether a reportedly unauthorized or fraudulent transaction (e.g., one that the account holder reported as such when looking at his or her account statement) was indeed unauthorized or fraudulent. In some embodiments, theprocess flow180 may also, or instead, be used to determine whether an “unrecognized” transaction (i.e., one that the account holder does not recall, but does not necessarily report as fraudulent) was unauthorized or fraudulent.
• In theprocess flow180,multi-account data182 may represent data associated with financial accounts of a number (e.g., thousands) of account holders. For example, themulti-account data182 may include data associated with financial transactions relating to credit card accounts, debit card accounts, savings accounts, checking accounts, etc. For ease of explanation,FIG. 3E will be described with reference to an embodiment in which the accounts are credit card accounts.
• In one embodiment, themulti-account data182 may include transaction data (e.g., transaction dates, amounts, locations, etc.) obtained from FAMS14 (e.g., by externaldata collection unit42 ofFIG. 1). In some embodiments, however, themulti-account data182 also includes information obtained fromcardholder computing devices20,merchant computing systems22, and/orother sources24. For example, themulti-account data182 may include, in addition to transaction data fromaccount records database30 ofFAMS14, data indicative of IP addresses ofcardholder computing devices20 and/or devices inmerchant computing systems22, Internet browsing and/or search history data from cardholder computing devices20 (or from an ISP computer system included inother sources24, etc.), vehicle telematics data from telematics systems of cardholder vehicles, home occupancy and/or usage data (e.g., smart appliance data) from smart home systems of cardholders, autonomous vehicle data, smart vehicle data, mobile device data, vehicle or mobile device GPS data, and/or one or more other types of data. Some or all data withinmulti-account data182 may be information that account holders or potential account holders have expressly consented to share with an entity associated withFAMS14 and/or AFSS12 (e.g., in exchange for fraud protection services).
• As described above in connection withmulti-account data82 ofprocess flow80, themulti-account data182 may be associated with multiple fraud determination labels (e.g., “fraud” and “no fraud,” and/or more complex labels that indicate type/class, such as “lost/stolen card use,” etc.). In some embodiments, each label may be associated with a data set that includes the corresponding portion ofmulti-account data182. The labels may include final fraud determinations that were made via earlier iterations of theprocess flow180, and/or external to theprocess flow180.Multi-account data182 may include many (e.g., thousands) of positively and negatively labeled data sets.
• At aprocess stage184, themulti-account data182 may be analyzed to generate query generation rules (e.g., to be stored in ML rules database58). As described above in connection withprocess stage84 ofprocess flow80, any suitable type of supervised machine learning program/technique(s) may be used. Generally,process stage184 may serve to identify which types of information are probative of whether fraud has occurred, and to craft rules that formulate queries to ascertain such information based upon account data.
• For example,process stage184 may determine that, for a suspect “card present” transaction, a verified, non-fraudulent “card present” transaction within 10 miles and 3 hours of the suspect transaction is probative of whether the suspect transaction was fraudulent. Based upon this finding,process stage184 may also generate a rule specifying that a cardholder should be queried as to whether he/she can confirm making each “card present” transaction within 10 miles and 3 hours of the suspect transaction. As another example,process stage184 may determine that a merchant using a billing alias different from its legal and/or commonly-known name (e.g., by at least some threshold level of similarity, as measured by number of similar characters, order of characters, etc.) is probative of whether the cardholder authorized a transaction associated with that billing alias. Based upon this finding,process stage184 may generate a rule specifying that a cardholder should be queried as to whether he/she is aware of a billing alias used for a suspect transaction if that billing alias is sufficiently different from the legal/common name of the merchant.
• Atprocess stage186, the rules generated or updated atprocess stage184 may be applied tofirst account data190. Thefirst account data190 may be associated with a particular cardholder, such as a cardholder associated with a particular one ofcardholder computing devices20, for example. The types of data included infirst account data190 may depend upon which types of data were determined, byprocess stage184, to be relevant to developing dispute resolution queries.Process stage186 may generate a set of one or more queries in accordance with the rules and the contents of first account data. Some specific examples of rules that may be generated byprocess stage184 and applied atprocess stage186, and the queries that may be generated as a result, are described below in connection withFIG. 4E.
• At aprocess stage192, the generated queries may be sent to the cardholder in one or more of various ways, such as sending the queries via SMS text message and/or email, and/or via a web browser or dedicated application executing on the one ofcardholder computing devices20 that is associated with the cardholder, for example. At aprocess stage194, responses to the queries are received from the cardholder (e.g., via inputs made by the cardholder via the web browser or application, or a responsive SMS text message or email, etc.). In some embodiments, the rules generated or updated atprocess stage184 specify the manner in which follow-up queries should be generated based upon the responses received atprocess stage194, and process stages192 and194 may be repeated multiple times.
• In some embodiments, further analysis (e.g., a manual review, or further automated review using additional data sources, etc.) that makes use of the received responses is performed at an additional stage, shown in dashed lines inFIG. 3E asprocess stage196. The additional analysis may then be used to make a final fraud determination (e.g., a final decision on whether fraud occurred, and/or on the type of fraud that occurred) atprocess stage198. In other embodiments,process stage196 is omitted fromprocess flow180, andprocess stage198 is based upon information from the cardholder. For example, the questions generated atprocess stage192 may “jog” the cardholder's memory, and cause him or her to indicate that the transaction at issue was authorized. The final determination made atprocess stage198, along with the first account data110 (and any other data used at process stage196), the queries generated atprocess stage186 and/or the responses received atprocess stage194, may be fed back intoprocess stage184 to provide additional labeled data for purposes of updating the rules.
F. Exemplary Process Flow for Machine Learning of Document Fraud Detection Rules
• Referring now toFIG. 3F, anexemplary process flow200 may generally be used to detect fraud relating to documents, such as counterfeit and/or forged documents. Theprocess flow200 may be used in connection with various kinds of documents, such as checks (e.g., personal checks, cashier's checks, etc.), money orders, treasury bills, identification documents (e.g., social security cards, driver's licenses, passports, birth certificates, etc.), certification documents, and so on.
• In theprocess flow200,multi-document image data202 may represent digital images of a number (e.g., thousands) of physical documents of one or more types. Themulti-document image data202 may include images in one or more formats, such as raster formats (e.g., JPEG, TIFF, GIF, BMP, PNG, etc.) and/or vector formats (e.g., CGM, SVG, etc.), for example. Themulti-document image data202 may include data obtained (e.g., by externaldata collection unit42 ofFIG. 1) from merchant computing systems22 (e.g., point-of-sale devices with cameras for document identification) and/or from FAMS14 (e.g., images of personal checks), for example. In some embodiments, themulti-document image data202 may only include data representing images that customers (or other individuals associated with the documents) have expressly consented to share (e.g., as a prerequisite to making a purchase, or in exchange for fraud protection services, etc.).
• As described above in connection withmulti-account data82 ofprocess flow80, themulti-document image data202 may be associated with multiple fraud determination labels. In some embodiments, each label may be associated with data representing a digital image of a particular document. The labels may include final fraud determinations (e.g., “fraud” or “no fraud,” or more complex labels such as “forgery,” “counterfeit,” “forgery-signature,” “counterfeit-angular line offset(s) outside tolerance,” etc.) that were made via earlier iterations of theprocess flow200, and/or external to theprocess flow200.Multi-document image data202 may include many (e.g., thousands) of positively and negatively labeled data sets.
• At aprocess stage204, themulti-document image data202 may be analyzed to generate document fraud detection rules (e.g., to be stored in ML rules database58). As described above in connection withprocess stage84 ofprocess flow80, any suitable type of supervised machine learning program/technique(s) may be used. Generally,process stage204 may serve to identify which characteristics of a document are probative of whether the document is counterfeit, and to determine the ranges, tolerances, etc., that are probative of whether the document is counterfeit. In some embodiments,process stage204 also, or instead, identifies which characteristics of information entered in document fields are probative of whether the document was forged (e.g., drafted or populated by someone other than the person purported to have drafted or populated the document).
• Atprocess stage206, the rules generated or updated atprocess stage204 may be applied to firstdocument image data210. The firstdocument image data210 may be digital image data corresponding to a particular, physical document. The firstdocument image data210 may include information obtained (e.g., by external data collection unit42) from one of merchant computing systems22 (e.g., for real-time verification of an identification or other document presented during or prior to a sale), or from FAMS14 (e.g., for real-time or batch-processing verification of a personal check prior to clearing the check), for example. Some specific examples of rules that may be generated byprocess stage204, and applied atprocess stage206, are described below in connection withFIG. 4F.
• Process stage206 may output information indicating whether fraud is suspected in connection with the document corresponding to firstdocument image data210. For example,process stage206 may output two percentage probabilities calculated according to the rules generated or updated atprocess stage204, with the first indicating the likelihood that the document is counterfeit and the second indicating the likelihood that the document includes forged content. As another example,process stage206 may output binary indicators of whether the document likely is, or likely is not, counterfeit and/or includes forged content (e.g., by comparing percentage probabilities to threshold probabilities).
• In some embodiments, further analysis (e.g., a manual review, or further automated review using additional data sources, etc.) may be performed at aprocess stage212. The additional analysis may then be used to make a final fraud determination (e.g., a final decision on whether the document is fraudulent) at process stage214. For example, theprocess stage206 may act as a filter, and flag only those documents having a relatively high probability of being fraudulent. In this manner, a considerably smaller amount of human and/or processing resources may be consumed atprocess stage212.
• The final determination made at process stage214, along with the firstdocument image data210 used to make that determination, may be fed back intoprocess stage204 to provide additional labeled data for purposes of updating the rules. In some embodiments, a preliminary fraud determination made atprocess stage206 may also be fed back intoprocess stage204, to allow the machine learning program to determine and improve upon past performance/accuracy.
IV. Exemplary Rules for Fraud Detection and/or Classification
• FIGS. 4A-4F depict exemplary factors and algorithms that may be used in connection with various fraud detection and/or classification rules, according to different embodiments. It is noted that the rule sets corresponding toFIGS. 4A-4F are purely for purposes of illustration and are not limiting. Particularly in embodiments where machine learning is utilized, for example, the algorithms and/or factors may be far more complex, and/or less intuitive, than some or all of the examples shown inFIGS. 4A-4F.
A. Exemplary Fraud Detection Rule Set Using Online Activity
• Referring first toFIG. 4A, an exemplary rule set220 (e.g., generated atprocess stage104 ofFIG. 3A) may use various factors relating to online activity of a cardholder to detect fraud in connection with a particular credit or debit card transaction. The rule set220 may correspond to a particular embodiment and scenario in which the transaction at issue is a “card present” transaction, and in which the rule set220 seeks to determine whether the cardholder made or otherwise authorized the transaction. The rule set220 may be incorporated into a review process that is generally applied to all transactions, a review process applied only to those transactions that were flagged by a preliminary fraud alert, or a review process applied only after a cardholder reports the transaction as unauthorized, for example.
• The factors considered under the rule set220 may include a number of interest-basedfactors222 and a number of location-basedfactors224. The interest-basedfactors222 may relate to the cardholder's interest (or non-interest) in a product or service purchased via the transaction, and/or the merchant providing the product or service, while the location-basedfactors224 may relate to the cardholder's location or probable location.
• As seen inFIG. 4A, the interest-based factors222 may include: (1) whether the cardholder searched online for the specific product or service purchased via the transaction at issue (e.g., by determining whether search terms entered by the cardholder included the name of the product or service involved in the transaction, or included a description of the product or service, etc.); (2) whether the cardholder visited a website associated with the merchant (e.g., by comparing URLs of web sites visited by the cardholder to a known URL of the merchant's website, or by searching the contents of websites visited by the cardholder for the merchant's name, etc.); (3) whether the cardholder endorsed the merchant, or the product or service provided by the merchant, via a social media account of the cardholder (e.g., by determining whether the cardholder “liked” the merchant, product or service via his or her Facebook® account, etc.); (4) whether the cardholder visited a website associated with a competitor of the merchant (e.g., by comparing URLs of web sites visited by the cardholder to known URLs of known competitors' websites, or by searching the contents of websites visited by the cardholder for the competitors' names, etc.); (5) whether the cardholder searched online for a different product or service in the same price range as the transaction amount (e.g., by analyzing search terms and/or results, and/or by analyzing URLs or contents of websites visited by the cardholder and comparing prices of products/services, etc.); and/or (6) whether the cardholder entered search terms indicative of the cardholder's need for the product or service (e.g., by determining that the cardholder entered search terms including “pipe leak” prior to the purchase of new plumbing hardware, or “computer repair” prior to the purchase of a new hard drive, etc.). In other embodiments, the interest-basedfactors222 may include more, fewer and/or different factors than those shown inFIG. 4A.
• As is also seen inFIG. 4A, the location-basedfactors224 may include: (1) whether the cardholder “checked in” to a flight having a destination near the location where the transaction was initiated (e.g., by determining whether the cardholder checked in to a flight having a destination at the city in which the transaction occurred, or within a threshold number of miles of the city in which the transaction occurred, etc.); (2) whether the cardholder visited a website associated with a place near (or in) which the transaction was initiated (e.g., by comparing URLs of web sites visited by the cardholder to URLs of websites known to be associated with particular areas, and/or by searching the contents of websites visited by the cardholder for location or area names, etc.); and/or (3) whether the cardholder endorsed a place near (or in) which the transaction was initiated via a social media account of the cardholder (e.g., by determining whether the cardholder “liked” the geographic area, attraction or other place via his or her Facebook® account, etc.). In other embodiments, the location-basedfactors224 may include more, fewer and/or different factors than those shown inFIG. 4A.
• Generally, the data indicative of whether the circumstance corresponding to each of interest-basedfactors222 and/or location-basedfactors224 is present/true for a particular cardholder may be included in the first customeronline activity data110 described above in connection withFIG. 3A. For example, externaldata collection unit42 ofFIG. 1 may obtain the search terms, URLs, user online selections, etc., needed to determine whether the various factors exist, from the cardholder's computing device (e.g., one of cardholder computing devices20) and/or from an ISP ofother sources24.
• As is also seen inFIG. 4A, each of the interest-basedfactors222 and location-basedfactors224 may be associated with a particular score or weighting value. In the rule set220 shown inFIG. 4A, a total score may be calculated based upon which factors are, or are not, present (e.g., add 94 points if it is determined that the cardholder searched for the particular lawnmower model that was purchased, add another 80 points if the transaction was a “card present” transaction in the Chicago suburb of Joliet and the cardholder checked in to a flight to Chicago just prior to the transaction, etc.).
• In some embodiments, certain factors may instead be associated with negative scores (e.g., minus 80 if the cardholder checked in to a flight with a destination at least 200 miles from the site of the transaction and within one day of the transaction, etc.). Moreover, certain factors may be associated with metrics or algorithms that determine how heavily those factors are weighed. As indicated inFIG. 4A, for example, search terms entered by the cardholder may be used to calculate a “need score” X (e.g., where X is based upon frequency of certain search terms being used, the amount of time spent clicking through search results, the magnitude and/or urgency of a problem indicated by the search terms, etc.), with X then being used to calculate a score equal to 0.2X.
• The rule set220 may then output the total score (e.g., 94+80=+174), a normalized total score, an indication of whether the total score exceeded a threshold (e.g., a threshold of +100), a probability calculated based upon the total score, and/or some other indicator or measure of the existence or likelihood of fraud. In the example shown inFIG. 4A, it can be seen that larger scores generally correspond to a greater probability that the transaction was made or authorized by the cardholder. If the transaction is being automatically reviewed (e.g., to determine whether a fraud alert is appropriate, without any initial input from the cardholder), this may mean that a lower score corresponds to a higher probability of fraud. Conversely, if the cardholder had reported the transaction as being fraudulent, a higher score may correspond to a higher probability of fraud (i.e., fraud on the part of the cardholder).
• In some embodiments, the rule set220 may also include one or more other types of factors not necessarily based upon online activities of the cardholder (e.g., whether GPS of the cardholder's smartphone or vehicle indicates that he or she was in that area shortly before or after the transaction, etc.), and/or may omit either interest-basedfactors222 or location-basedfactors224.
B. Exemplary Chargeback Candidate Detection Rule Set
• Referring next toFIG. 4B, an exemplary rule set230 (e.g., generated atprocess stage124 ofFIG. 3B) may use various factors relating to a transaction between a cardholder and a merchant to determine whether the transaction should be flagged as a candidate for a chargeback (e.g., to determine whether the transaction should be reviewed under a full set of chargeback rules associated with the appropriate card network entity). The rule set230 may correspond to a particular embodiment and scenario in which the transaction at issue is a “card present” transaction.
• As seen inFIG. 4B, the factors considered under the rule set230 may include: (1) whether an EMV chip card was not inserted in a point-of-sale EMV chip reader device of the merchant; (2) whether a non-EMV card was not swiped in a point-of-sale device of the merchant; (3) whether the card is past its expiration date; (4) whether the transaction is for the same amount and/or date as another transaction involving the same card and merchant (e.g., by analyzing other transactions involving the same account and merchant within a particular time span); and/or (2) whether the transaction is for greater than a threshold amount. For example, one ofmerchant computing systems22 ofFIG. 1 (or an acquiring/merchant bank) may provide transaction details that include the amounts, dates, etc., toFAMS14 for storage inaccount records database30, and externaldata collection unit42 may then retrieve that information fromaccount records database30. Generally, the data indicative of whether the circumstance corresponding to each of the factors is present/true for a particular transaction may be included in the firstaccount transaction data130 described above in connection withFIG. 3B. In other embodiments, the factors considered under rule set230 may include more, fewer and/or different factors than those shown inFIG. 4B. It is noted that, in some embodiments, one or more factors may simply relate to the desirability (e.g., from a card issuer perspective) of further reviewing whether a chargeback is appropriate, without necessarily relating to the likelihood that a chargeback is appropriate.
• As is also seen inFIG. 4B, each of the factors may be associated with a particular score or weighting value. A total score may be calculated based upon which factors are, or are not, present (e.g., add 62 points if it is determined that the transaction has the same amount and date as another transaction occurring close in time and involving the same card and merchant). In some embodiments, certain factors may instead be associated with negative scores, and/or certain factors may be associated with metrics or algorithms that determine how heavily those factors are weighed.
• The rule set230 may then output the total score, a normalized total score, an indication of whether the total score exceeded a threshold, a probability calculated based upon the total score, and/or some other indicator or measure of the likelihood that a chargeback is appropriate for the transaction. In the example shown inFIG. 4B, it can be seen that larger scores generally correspond to a greater probability that a chargeback is appropriate.
C. Exemplary Fraud Classification Rule Set
• Referring now toFIG. 4C, an exemplary rule set240 (e.g., generated atprocess stage144 ofFIG. 3C) may use a diverse array of factors to classify the type(s) of fraudulent activity, if any, that is/are suspected to be associated with an event or series of events. The rule set240 may correspond to a particular embodiment and scenario in which the event at issue is a financial transaction involving a debit or credit card. In other embodiments and/or scenarios, however, the rule set240 may classify fraudulent activity with respect to specific other types of events (e.g., loan applications), or may detect a variety of different event types (e.g., various types of financial transactions, loan or credit applications, etc.) and broadly classify fraudulent activity in connection with the detected event types (e.g., lost/stolen card use, application fraud, etc.).
• In one embodiment, each potential classification (with the possible exception of “no fraud”) may be associated with a number of factors probative of whether that type/class of fraud has occurred. As seen inFIG. 4C, for example, the rule set240 may include counterfeit factors242 (e.g., factors indicating that a counterfeit card was used for the transaction), account takeover factors244 (e.g., factors indicating that the transaction resulted from an unauthorized person gaining online access to the credit or debit card account itself, via phishing, malware or other means), chargeback fraud factors246 (e.g., factors indicating that the cardholder made or otherwise authorized a purchase that the cardholder later contested) and skimming factors248 (e.g., factors indicating that the card information used for the transaction was obtained via a skimming card reader device illegally installed in an ATM, gas station pump or other location). In other embodiments, the rule set240 may also, or instead, include factors corresponding to one or more other fraud classifications (e.g., forgery, lost/stolen card use, etc.).
• As seen inFIG. 4C, the counterfeit factors242 may include: (1) whether the suspect transaction and another, contemporaneous transaction (e.g., occurring within one hour, etc.) in another state are both “card present” transactions; and/or (2) if the suspect transaction is a “card present” transaction, whether the card (if an EMV chip card) was not inserted in an EMV chip card reader. For example, one or more ofmerchant computing systems22 ofFIG. 1 (or one or more acquiring/merchant banks) may provide transaction details that include whether the transaction was “card present,” whether the card was inserted in an EMV chip card reader, etc., toFAMS14 for storage inaccount records database30, and externaldata collection unit42 may then retrieve that information fromaccount records database30. In other embodiments, the counterfeit factors242 may include more, fewer and/or different factors than those shown inFIG. 4C.
• Theaccount takeover factors244 may include: (1) whether the debit or credit card account password was changed within the 10 days prior to the transaction; and/or (2) whether the transaction was originated from an IP address not associated with the cardholder. For example, externaldata collection unit42 may retrieve password change information fromaccount records database30 ofFIG. 1, which may log all password update activity, and/or may retrieve IP address information from one of merchant computing systems22 (e.g., the computing system of the merchant involved in the transaction). In other embodiments, theaccount takeover factors244 may include more, fewer and/or different factors than those shown inFIG. 4C.
• Thechargeback fraud factors246 may include: (1) whether the cardholder had searched online for the product or service purchased via the transaction; and/or (2) whether the cardholder had visited a website associated with the merchant involved in the transaction. For example, externaldata collection unit42 ofFIG. 1 may retrieve online search information (e.g., search terms and/or results) and/or URLs from the one ofcardholder computing devices20 that is associated with the cardholder, and/or from an ISP (of other sources24) used by the cardholder. In other embodiments, thechargeback fraud factors246 may include more, fewer and/or different factors than those shown inFIG. 4C.
• The skimming factors248 may include: (1) the number (X) of earlier transactions in which the card used for the transaction at issue was used at an ATM machine or a gas station pump within the 10 days prior to the transaction at issue; and/or (2) whether the transaction at issue originated from an IP address not associated with the cardholder. For example, externaldata collection unit42 ofFIG. 1 may retrieve transaction data indicating that certain past purchases were made using gas station pump card readers, and/or indicating that the card was used for one or more ATM withdrawals, fromaccount records database30, and/or may retrieve the originating IP address from the one ofmerchant computing systems22 associated with the merchant involved in the transaction at issue. In other embodiments, the skimming factors248 may include more, fewer and/or different factors than those shown inFIG. 4C.
• Generally, the data indicative of whether the circumstance corresponding to each ofcounterfeit factors242,account takeover factors244,chargeback fraud factors246 and/or skimmingfactors248 is present/true for a particular transaction may be included in thefirst account data150 described above in connection withFIG. 3C, for example.
• As is also seen inFIG. 4C, each of the counterfeit factors242,account takeover factors244,chargeback fraud factors246 and skimmingfactors248 may be associated with a particular score or weighting value. The factors for each classification (counterfeit, account takeover, chargeback fraud, skimming) may be used to calculate a total score specific to that classification. In the rule set240 shown inFIG. 4C, for example, a counterfeit score may be calculated based upon which offactors242 are, or are not, present, an account takeover score may be calculated based upon which offactors244 are, or are not, present, and so on. In some embodiments, certain factors may instead be associated with negative scores, and/or certain factors (e.g., the first of skimmingfactors248 shown inFIG. 4C) may be associated with metrics or algorithms that determine how heavily those factors are weighed.
• For each classification/category, the rule set240 may output the total score, a normalized total score, an indication of whether the total score exceeded a threshold, a probability calculated based upon the total score, and/or some other indicator or measure of the likelihood that fraud of that particular type/class occurred in connection with the transaction. In the example shown inFIG. 4C, it can be seen that larger scores generally correspond to a greater probability that the respective classification is accurate. Referring back toFIG. 3C, the classification atprocess stage152 may be the classification having the highest score and/or probability under rule set240, or may include the score and/or probability for each classification, the top three classifications, etc.
D. Exemplary Application Fraud Detection Rule Set
• Referring now toFIG. 4D, an exemplary rule set260 may use online search information (e.g., search terms, search results, clicked/selected search results, etc.) to detect whether an application was fraudulent (e.g., not populated and/or submitted by the purported applicant). The rule set260 may have been generated atprocess stage164 ofFIG. 3D, for example. The rule set260 may be incorporated into a review process that is generally applied to all applications received by a particular entity or anti-fraud service, or a review process applied only to those applications that were flagged by a preliminary fraud alert, for example.
• The factors considered under the rule set260 may generally be probative of whether the person that submitted the application (e.g., via a web browser, a dedicated application, as an email attachment, by snail mail, etc.) had performed one or more online searches indicating that he or she was trying to learn more about the purported applicant in order to populate particular fields of the application (e.g., a “home address” field, “employment history” fields, etc.). The “purported applicant” may be a person whose name appears in a name and/or signature field of the application, for example.
• As seen inFIG. 4D, the factors of exemplary rule set260 may include: (1) whether the applicant used search terms that included the name of the purported applicant; (2) whether the search terms also included the words “address” or “residence” (and possibly other synonyms or near-synonyms); and/or (3) whether the search terms also included the words “employer,” “job” and/or “career” (and possibly other synonyms or near-synonyms). In other embodiments, the rule set260 may include more, fewer and/or different factors than those shown inFIG. 4D. For example, the rule set260 may include one or more factors relating to which search results appeared and/or were selected (e.g., “clicked” on after appearing on a user interface) by the applicant.
• Generally, the data indicative of whether the circumstances corresponding to the factors of rule set260 are present/true for a particular applicant may be included in the first applicantsearch history data170 described above in connection withFIG. 3D. For example, externaldata collection unit42 ofFIG. 1 may obtain the search terms, search results, search result user selections, etc., needed to determine whether the various factors exist, from the applicant's computing device (e.g., similar to one of cardholder computing devices20) and/or from an ISP ofother sources24. Access to such information may be made a condition of having the application be considered, for example.
• As is also seen inFIG. 4D, each of the factors of rule set260 may be associated with a particular score or weighting value. A total score may then be calculated based upon which factors are, or are not, present. In some embodiments, certain factors may instead be associated with negative scores, and/or certain factors may be associated with metrics or algorithms that determine how heavily those factors are weighed.
• The rule set260 may then output the total score, a normalized total score, an indication of whether the total score exceeded a threshold, a probability calculated based upon the total score, and/or some other indicator or measure of the existence or likelihood of application fraud. In the example shown inFIG. 4D, it can be seen that larger scores may generally correspond to a greater probability that the application was not populated and/or submitted by the purported applicant.
E. Exemplary Fraud Dispute Resolution Rule Set
• Referring now toFIG. 4E, a flow diagram illustrates at least a portion of aprocess flow270 implementing an exemplary rule set for fraud dispute, or potential fraud dispute, resolution (e.g., a rule set generated atprocess stage184 ofFIG. 3E). Theprocess flow270 may be used to help resolve a dispute over a contested transaction, or to help a customer recall an unrecognized transaction, for example.FIG. 4E illustrates a process flow, rather than just a set of factors, in order to better illustrate an example process for generating queries based upon the generated rules, according to one embodiment. Theprocess flow270 may correspond to a particular embodiment and scenario in which the transaction subject to dispute or potential dispute is a credit or debit card transaction.
• In theexemplary process flow270, the rule set may specify that aprocess stage272 determines whether the transaction was a “card present” transaction. If not, the rule set may specify that the flow proceed directly to aprocess stage280. If so, however, the rule set may specify that the flow instead proceeds to aprocess stage274.
• The rule set may also specify thatprocess stage274 determines whether at least one other transaction associated with the cardholder's account occurred within some threshold number of hours (X) of the transaction at issue. If not, the rule set may specify that the flow proceeds directly to processstage280. If so, however, the rule set may specify that the flow instead proceeds to aprocess stage276.
• Process stage276 may generate one or more location-related queries using transaction data associated with the cardholder's account. The queries may ask, for example, whether the cardholder was in (or near) one or more particular geographic areas or locations at various times. If the transaction at issue occurred in San Francisco, for example, with a first other “card present” transaction occurring in Santa Rosa four hours earlier and a second other “card present” transaction occurring in San Jose two hours later,process stage276 may generate one or more queries asking whether the cardholder made or authorized the earlier and/or later transactions, and/or whether the cardholder traveled on a route from Santa Rosa to San Jose that passed through San Francisco, etc.
• In some embodiments, the location-related queries are generated based upon data associated with events or circumstances other than transactions. For example, if the transaction at issue occurred in Sarasota, Fla., and the data considered under the rule set indicates that the cardholder checked in to a flight to Tampa,process stage276 may generate one or more queries asking whether the cardholder completed the flight, where the cardholder went after landing in Tampa, etc.
• The rule set may also specify thatprocess stage280 determines whether the transaction at issue is associated with a billing alias that is dissimilar to the name of the merchant involved in the transaction. For example, the computing system of the merchant (e.g., one ofmerchant computing systems22 ofFIG. 1) may have sent to FAMS14 a transaction record that identified the merchant by the alias, and was presented to the cardholder as an online or paper account statement. The determination atprocess stage280 may use the billing alias to identify a legal and/or common name of the merchant (e.g., using a relational database stored inAFSS12 or FAMS14), and determine that there is at least some threshold level of dissimilarity (e.g., based upon difference of characters, character ordering, etc.) between the billing alias and the merchant name.
• If the billing alias and merchant name are not sufficiently dissimilar, the rule set may specify that the flow proceeds directly to aprocess stage284. If sufficiently dissimilar, however, the rule set may specify that the flow instead proceeds to aprocess stage282.Process stage282 may generate a query relating to the billing alias that was presented to the cardholder. For example, the query may ask whether the cardholder is aware that the billing alias is used by that particular merchant. In some embodiments,process stage282 may instead generate a message that simply informs the cardholder that the billing alias corresponds to the merchant, without posing a question.
• The rule set may specify thatprocess stage284 generates one or more default queries. For example, one default query may ask whether the cardholder lent his or her card to a friend or family member around the time of the transaction. In some embodiments and/or scenarios,process stage284 may be omitted fromprocess flow270. Generally, the queries (and possibly non-query messages) generated inprocess flow270 may serve to help the cardholder recall whether the transaction was made or authorized, and/orprocess flow270 may prompt the cardholder for responses that are considered by others (e.g., personnel of an entity associated withFAMS14 ofFIG. 1) to determine whether the transaction was likely fraudulent.
• Although not shown inFIG. 4E, in someembodiments process flow270 may include a number of iterative stages in which responses are received from the cardholder (e.g., from the respective one ofcardholder computing devices20 inFIG. 1) and used to generate additional, more detailed questions for the cardholder. For example, if a first query asks whether the cardholder recalls personally making another “card present” transaction that occurred at a nearby time and place, and the cardholder responds “no,” a new query may be generated asking whether the cardholder recalls personally making the next closest transaction (in terms of time and/or location).
F. Exemplary Document Fraud Detection Rule Set
• Referring next toFIG. 4F, an exemplary rule set290 (e.g., generated atprocess stage204 ofFIG. 3F) may use various factors relating to an imaged (e.g., photographed or scanned) physical document to determine whether the document should be flagged as a candidate for a more in-depth (e.g., manual) analysis/review for fraud purposes. The rule set290 may correspond to a particular embodiment and scenario in which the document is one that includes at least a signature field (e.g., a personal check, a driver's license, etc.).
• The factors considered under the rule set290 may include a number ofcounterfeit factors292 and a number offorgery factors294, each of which may be evaluated byimage analysis unit52 ofFIG. 1 using one or more image processing techniques. The counterfeit factors292 may relate to the look, presentation, format and/or structure of the document, while the forgery factors294 may relate to the substance, style or format of information entered in one or more fields of the document.
• As seen inFIG. 4F, the counterfeit factors292 may include: (1) whether one or more absolute or relative dimensions and/or angles of the document, or of lines, illustrations, patterns, etc. shown on the document (excluding user-entered contents in fields such as the signature line), are outside one or more predetermined tolerances; (2) whether one or more colors on the document are outside a predetermined tolerance (e.g., color/frequency range); (3) whether one or more line thicknesses of the document (excluding user-entered field contents) are outside one or more predetermined tolerances; and/or (4) whether one or more fonts on the document (excluding user-entered field contents) are outside one or more predetermined tolerances. For example,image analysis unit52 may determine whether the ratio of the document length to the document width is within 0.1% of an expected value. As another example,image analysis unit52 may determine whether horizontal and vertical lines on the document are within 0.3 degrees of the horizontal and vertical edges of the document, respectively. As yet another example,image analysis unit52 may determine whether a font used for a field descriptor or other text on the document matches an expected font (e.g., by meeting a similarity threshold measured in any suitable manner). In other embodiments, the counterfeit factors292 may include more, fewer and/or different factors than those shown inFIG. 4F.
• The forgery factors294 may include: (1) whether a signature entered in a signature field of the document match is outside a predetermined tolerance (e.g., using any suitable signature recognition technique); (2) whether handwriting entered in one or more fields of the document is outside a predetermined tolerance (e.g., by applying a suitable handwriting recognition technique); and/or (3) whether the format of information entered by a user in one or more fields does not match an expected format (e.g., using “9.12.16” rather than the expected “9/12/2016,” as established based upon other documents known to have been populated and/or submitted by the purported applicant). In other embodiments, the forgery factors294 may include more, fewer and/or different factors than those shown inFIG. 4F.
• Generally, the data indicative of whether the circumstances corresponding to counterfeitfactors292 and/orforgery factors294 are present/true for a particular document may be included in the firstdocument image data210 described above in connection withFIG. 3F.
• As is also seen inFIG. 4F, each of the counterfeit factors292 andforgery factors294 may be associated with a particular score or weighting value. In the rule set290 shown inFIG. 4F, a total score may be calculated based upon which factors are, or are not, present. In some embodiments, certain factors may instead be associated with negative scores, and/or certain factors may be associated with metrics or algorithms that determine how heavily those factors are weighed.
• The rule set290 may then output the total score, a normalized total score, an indication of whether the total score exceeded a threshold, a probability calculated based upon the total score, and/or some other indicator or measure of the likelihood that the document is fraudulent. Alternatively, the rule set290 may output a separate total score, normalized score, probability, or other metric, for each ofcounterfeit factors292 andforgery factors294, with the counterfeit metric indicating the likelihood that the document is a counterfeit and the forgery metric indicating the likelihood that the document was fraudulently populated by someone other than the purported person (e.g., by someone other than the person corresponding to the name, signature, address, etc. on the document). In the example shown inFIG. 4F, it can be seen that larger scores generally correspond to a greater probability that the document is fraudulent. In some embodiments, the rule set290 also includes one or more other types of factors not shown inFIG. 4F, and/or omits eithercounterfeit factors292 or forgery factors294.
V. Exemplary Methods for Fraud Detection & Classification
• FIGS. 5-7 depict flow diagrams of various exemplary computer-implemented methods that may be implemented by one or more components ofAFSS12 ofFIG. 1. In one embodiment,AFSS12 implements all of the methods corresponding toFIGS. 5-7. In other embodiments,AFSS12 implements only a subset (e.g., one, two, etc.) of the methods corresponding toFIGS. 5-7. Each of the methods described below may be implemented by fraud detection/classification unit36 ofFIG. 1, for example.
A. Exemplary Methods for Facilitating Fraud Dispute Resolution
• Referring first toFIG. 5, an exemplary computer-implementedmethod300 may be used to facilitate a fraud dispute resolution process involving a customer associated with a financial account. In themethod300, types of information historically indicative of fraud (or an absence of fraud) may be identified (block302). The information types may be identified at least in part by training a machine learning program, such as any of the types of machine learning programs discussed above in connection withML rule generator40 ofFIG. 1 orprocess stage84 ofFIG. 2, for example. The machine learning program may be trained using transaction data associated with a plurality of financial transactions, and fraud determinations/labels each corresponding to a respective one of the plurality of financial transactions.
• An indication that fraud is suspected for a particular financial transaction, associated with a particular financial account, may be received (block304). For example, an automated investigation (e.g., using any suitable process, method or technique described herein), and/or a manual investigation, may have been performed to determine that the financial transaction was potentially fraudulent in some way, and a user input or other data indicative of that outcome may be received atblock304.
• Transaction data, associated with the financial transaction, may be retrieved (block306). For example, a database containing account records (e.g.,account records database30 ofFIG. 1) may contain a list of transactions associated with multiple accounts, and the transaction of interest may be retrieved atblock306 by accessing the information stored in the database.
• A first set of one or more queries may be generated (block308) based upon at least one of the types of information identified atblock302 and the transaction data retrieved atblock306. The query or queries may be designed to ascertain whether the financial transaction was indeed fraudulent. For example, one or more queries may be designed to ascertain whether the customer was proximate to a location (e.g., establishment, geographic area, etc.) where the financial transaction occurred at the time the financial transaction occurred. As another example, one or more queries may be designed to ascertain whether the customer recalls a different, second financial transaction associated with the financial account. As yet another example, one or more queries may be designed to ascertain whether the customer is aware of a billing alias associated with the financial transaction.
• The first set of queries may be transmitted to a remote computing device (e.g., to one ofcardholder computing devices20 ofFIG. 1) to cause the remote computing device to display the first set of queries to the customer (block310). The remote computing device may display the queries via a web browser, an email application, a text message application, or a dedicated application, for example.
• A first set of one or more customer responses may be received from the remote computing device (block312). The response(s) may have been entered by the customer using the same interface and/or application (e.g., email, text, web browser, etc.) via which the query or queries was/were displayed, for example.
• It may be determined, based upon the first set of customer responses, whether the financial transaction of interest was fraudulent (block314). In some embodiments and/or scenarios, the determination is not made without one or more further iterations of queries and responses. For example, block314 may include determining, based upon the customer responses, a second set of one or more queries designed to ascertain whether the financial transaction was fraudulent, transmitting the second set of queries to the remote computing device for display to the customer, receiving a second set of one or more customer responses from the remote computing device, and determining whether the financial transaction was fraudulent based upon the second set of customer responses.
• In some embodiments, themethod300 may include one or more additional blocks not shown inFIG. 5. For example, themethod300 may include a block in which an indication of whether the financial transaction was fraudulent (as determined at block314) is caused to be displayed to one or more people via one or more respective computing device user interfaces. The indication may also specify the transaction at issue, the merchant, and possibly other information such as the transaction date, dollar amount, etc. The indication may be sent to the remote computing device of the customer, for example, or to a computing device of a card issuer or other entity, etc. The indication may be generated bynotification unit56 ofFIG. 1, for example.
• FIG. 6 illustrates a computer-implementedmethod320 of fraud dispute resolution and/or reducing customer confusion caused by billing aliases on credit card or other financial statements. Themethod320 may include, via one or more processors and/or transceivers (such as via wireless communication or data transmission over one or more radio frequency links and/or wireless communication channels), (1) receiving an indication that a credit card financial transaction is being disputed by the card owner, and/or that the card owner does not recognize a financial transaction, such as not recognizing a billing alias on a credit card or other financial activity statement (block322); (2) determining or retrieving a billing merchant or billing alias associated with the disputed credit card transaction (and named on a credit card statement or other financial statement), such as via Optical Character Recognition (OCR) or Object Recognition (OR) techniques performed on the financial statement (block324); (3) inputting the billing alias into a machine learning program trained to identify a real world or brick-and-mortar merchant name associated with the billing alias (or otherwise determining a billing merchant associated with the disputed credit card transaction) (block326); and (4) generating and transmitting an electronic notification indicating the real world merchant name to the customer's mobile device for customer review and verification to resolve or pre-empt any potential dispute (block328).
• Themethod320 may further include, prior to transmission of a notification, (5) determining if the real world merchant has a brick-and-mortar location in the vicinity of the customer's home address on file (block330); and (6) if so, retrieving or accessing customer mobile device or vehicle GPS (Global Positioning System) coordinate history (block332). Themethod320 may include (7) determining whether the card owner was at the GPS location of the real world merchant on the day of the transaction, such as by using the customer mobile device or vehicle GPS coordinate history (block334); and (8) if so, generating an electronic notification notifying the card owner (i) of the real world merchant's name or identification, (ii) location of the merchant associated with the financial transaction, and/or (iii) that customer data indicates that the customer was at the location of the merchant on the day that financial transaction occurred (or that customer data indicates that the financial transaction was correct or valid) (block336); and/or (8) transmitting the electronic notification to customer mobile device for their review and/or verification (block338) to facilitate resolving or pre-empting erroneous disputes caused by unrecognized financial transactions or billing aliases.
• In one embodiment, a computer-implemented method of pre-empting fraud disputes caused by billing alias or unrecognized merchant billing names may be provided. The method may include (1) receiving, via one or more processors and/or transceivers, an indication that a credit card financial transaction is unrecognizable by the card owner; (2) determining or retrieving, via the one or more processors, a billing alias for a merchant associated with the unrecognizable credit card transaction, the billing alias being named on a credit card statement as the billing merchant; (3) determining, via the one or more processors, a brick and mortar name that the merchant associated with the billing alias is doing business as; (4) generating, via the one or more processors, an electronic notification indicating the brick and mortar name of the merchant associated with the credit card financial transaction; and/or (5) transmitting, via the one or more processors and/or transceivers, the electronic notification indicating the brick and mortar name of the merchant to a mobile device of the customer via wireless communication or data transmission over one or more radio links or wireless communication channels for customer review or approval to facilitate preventing financial disputes caused by billing aliases on credit card or other financial statements.
• Determining, via the one or more processors, the brick and mortar name that the merchant associated with the billing alias is doing business as may be performed by inputting the billing alias into a machine learning program trained to determine a real world name for the merchant using the billing alias. Determining or retrieving, via the one or more processors, a billing alias for a merchant associated with the unrecognizable credit card transaction may include applying an OCR technique onto a digital or hardcopy billing statement to retrieve or determine the billing alias, or retrieving the billing alias from a digital or virtual billing statement via processor analysis.
• The method may also include, prior to transmission of the electronic notification, determining, via the one or more processors, if the real world merchant has a (GPS) location in a vicinity of the customer home address; and if so, receiving, via the one or more processors and/or transceivers, customer mobile device or vehicle GPS coordinate history. The method may also include (i) determining, via the one or more processors, whether the card owner was at the (GPS) location of the real world merchant on the day (and time) of the transaction based upon the customer mobile device or vehicle GPS coordinate history; (ii) if so, then generating, via the one or more processors, an electronic notification notifying the card owner of the real world merchant's name or identification, location of the merchant associated with the financial transaction, and/or that customer GPS data indicates that the customer was at the location of the merchant on the day (and/or time) that the financial transaction occurred; and/or (iii) transmitting, via the one or more processors and/or transceivers, the electronic notification to customer mobile device for their review and/or verification to facilitate resolving erroneous disputes caused by unrecognized financial transactions.
• Additionally or alternatively, the method may include (i) comparing, via the one or more processors, a GPS location of the real world merchant associated with the transaction with a customer location at the time of the transaction to verify that the customer was at the merchant location at the time of the transaction; (ii) if so, then generating, via the one or more processors, an electronic notification notifying the card owner of the real world merchant's name or identification, location of the merchant associated with the financial transaction, and/or that customer data indicates that the customer was at the location of the merchant on the day (and time) that the financial transaction occurred; and/or (iii) transmitting, via the one or more processors and/or transceivers, the electronic notification to a customer mobile device for customer review and/or verification to facilitate resolving erroneous disputes caused by unrecognized financial transactions.
• In another embodiment, a computer system configured to pre-empt fraud or transaction disputes may be provided. The computer system may include one or more processors and/or transceivers configured to: (1) receive, via wireless communication or data transmission over one or more radio links or wireless communication channels, an indication that a credit card financial transaction is unrecognizable by the card owner; (2) determine or retrieve a billing alias for a merchant associated with the unrecognizable credit card transaction, the billing alias being named or printed on a hardcopy, or contained within a digital, credit card statement; (3) determine a brick and mortar name that the merchant associated with the billing alias is doing business as; (4) generate an electronic notification indicating the brick and mortar name of the merchant associated with the credit card financial transaction; and/or (5) transmit, via wireless communication or data transmission over one or more radio links or wireless communication channels, the electronic notification indicating the brick and mortar name of the merchant to a mobile device of the customer for customer review or approval to facilitate preventing financial disputes caused by unrecognized or unfamiliar billing aliases on credit card or other financial statements. For instance, a brick and mortar merchant chain named Ten Guys Pizza & Shakes may have an unfamiliar billing company name or billing alias of ABC Corp.
• Determining, via the one or more processors, the brick and mortar name that the merchant associated with the billing alias is doing business as may be performed by inputting the billing alias into a machine learning program trained to determine a real world name for the merchant using the billing alias. Determining or retrieving, via the one or more processors, a billing alias for a merchant associated with the unrecognizable credit card transaction may include applying an OCR technique onto a billing statement to retrieve or determine the billing alias, or retrieving or determining the billing alias using digital processor analysis on a digital billing or financial statement.
• The one or more processors and/or transceivers may be further configured to, prior to transmission of the electronic notification, determine if the real world merchant has a (GPS) location in a vicinity of the customer home address; and if so, receive customer mobile device or vehicle GPS coordinate history. The one or more processors and/or transceivers may be configured to: (i) determine whether the card owner was at the (GPS) location of the real world merchant on the day (and/or time) of the transaction based upon the customer mobile device or vehicle GPS coordinate history; (ii) if so, then generating, via the one or more processors, an electronic notification notifying the card owner of the real world merchant's name or identification, location of the merchant associated with the financial transaction, and/or that customer data indicates that the customer was at the location of the merchant on the day (and/or time) that the financial transaction occurred; and/or (iii) transmitting, via the one or more processors and/or transceivers, the electronic notification to customer mobile device for their review and/or verification to facilitate resolving erroneous disputes caused by unrecognized financial transactions.
• The one or more processors and/or transceivers may be further configured to: (i) compare a GPS location of the real world merchant associated with the transaction with customer location at the time of the transaction to verify that the customer was at the merchant location at the time of the transaction; (ii) if so, then generating, via the one or more processors, an electronic notification notifying the card owner of the real world merchant's name or identification, location of the merchant associated with the financial transaction, and/or that customer data indicates that they were at the location of the merchant on the day that financial transaction occurred; and/or (iii) transmitting, via the one or more processors and/or transceivers, the electronic notification to customer mobile device for their review and/or verification to facilitate resolving erroneous disputes caused by unrecognized financial transactions.
• FIG. 7 illustrates a computer-implementedmethod340 of reducing financial transaction disputes associated with introductory offers expiring. Themethod340 may include, via one or more processors and/or transceivers (such as via wireless communication or data transmission over one or more radio frequency links and/or wireless communication channels), (1) identifying an introductory offer offered by a company that is associated with one or more customer disputes or complaints after the introductory offer has expired and after which an increased amount is periodically charged to the customer (block342); (2) receiving financial transaction activity associated with customers (block344); and/or (3) identifying customers having financial transaction activity associated with the introductory offer that is generating customer disputes or complaints (block346). For instance, an offending introductory offer and customer financial activity may be input into a machine learning program that is trained to identify customers currently using the offending introductory offer. Themethod340 may include (4) generating and transmitting an electronic notification indicating that the customer is currently using an introductory offer that is associated with, or that has generated, customer complaints to the customer's mobile device for customer review (block348).
• Themethod340 may include, (5) prior to notification transmission, determining when the introductory offer will expire for each customer and/or estimating a new or non-introductory cost of the underlying product or service (block350). For instance, the machine learning program may also be trained to identify expiration dates of the introductory offer; estimate a regular cost of the underlying product or service offered by the merchant from data indicating or describing the offending introductory offer; and/or an average cost of the product or service that is offered from multiple merchants. Themethod340 may include (6) generating an electronic notification detailing the introductory offer, explaining when the introductory offer will expire, and/or what the customer will be, or will likely be, charged at that time if they don't cancel the product or service associated with the introductory offer beforehand (block352); and/or (7) transmitting the electronic notification (block354) to facilitate the customer cancelling the service before inflated charges are incurred, and reducing future financial disputes or customer dissatisfaction.
• In one embodiment, a computer-implemented method of reducing financial transaction disputes caused by introductory offers expiring may be provided. The method may include (1) identifying, via one or more processors, an introductory offer offered by a company that is associated with, or generating, one or more customer disputes or complaints after the introductory offer has expired and an increased amount (e.g., regular price) is periodically charged to the customer; (2) retrieving or receiving, via the one or more processors and/or transceivers, financial transaction activity associated with customers; (3) identifying, via the one or more processors, customers having financial transaction activity associated with the introductory offer generating the one or more customer disputes or complaints; (4) generating, via the one or more processors, an electronic notification indicating that the customers have accepted or are using an introductory offer that is generating customer complaints; and/or (5) transmitting, via the one or more processors and/or transceivers, the electronic notification to customer mobile devices to facilitate customer review and cancellation of the introductory offer prior to expiration.
• The method may further include, prior to electronic notification transmission, (i) determining, via the one or more processors, when the introductory offer will expire for each customer; (ii) generating, via the one or more processors, an electronic notification detailing the introductory offer, and explaining when the introductory offer will expire; and/or (iii) transmitting, via the one or more processors and/or transceivers, the electronic notification to facilitate the customer cancelling the service before inflated charges are incurred, and reducing future financial disputes.
• The method may further include, prior to electronic notification transmission, (i) determining, via the one or more processors, what the customer will be charged after introductory offer expiration for a product or service; (ii) generating, via the one or more processors, an electronic notification detailing the introductory offer, and explaining what the customer will be charged at that time if they don't cancel the product or service associated with the introductory offer beforehand; and/or (iii) transmitting, via the one or more processors and/or transceivers, the electronic notification to a customer mobile device to facilitate the customer cancelling the service before introductory offer expiration and increased charges are incurred, and reducing future financial disputes.
• Determining, via the one or more processors, what the customer will be charged after introductory offer expiration may include an actual periodic price charged by a merchant that produced the introductory offer; an average or estimated periodic price charged by a merchant that produced the introductory offer; and/or an average periodic price charged by merchants offering similar products or services than those of the introductory offer.
• The method may include receiving, via the one or more processors and/or transceivers, an authorization from a customer to cancel the introductory for them from a customer mobile device; and/or transmitting, via the one or more processors and/or transceivers, a cancellation request to a merchant from which the introductory offer originates to cancel the introductory offer.
• In another embodiment, a computer system configured to reduce financial transaction disputes caused by introductory offers expiring may be provided. The computer system may include one or more processors and/or transceivers configured to: (1) identify an introductory offer offered by a company that is associated with one or more customer disputes or complaints after the introductory offer has expired and an increased amount is periodically charged to the customer; (2) retrieve or receive financial transaction activity associated with customers via wireless communication or data transmission over one or more radio links or wireless communication channels from customer mobile devices or merchant computing devices; (3) identify customers having financial transaction activity associated with the introductory offer generating the one or more customer disputes or complaints; (4) generate an electronic notification indicating that the customers have accepted, or are using, an introductory offer that is generating customer complaints; and/or (5) transmit the electronic notification to customer mobile devices via wireless communication or data transmission over one or more radio links or wireless communication channels to facilitate customer review and cancellation of the introductory offer.
• The one or more processors and/or transceivers may be further configured to, prior to electronic notification transmission, (i) determine when the introductory offer will expire for each customer; (ii) generate an electronic notification detailing the introductory offer, and explaining when the introductory offer will expire; and/or (iii) transmit the electronic notification to a customer mobile device via wireless communication or data transmission over one or more radio links or wireless communication channels to facilitate the customer cancelling the service before introductory offer expiration and increased charges are incurred, and reducing future financial disputes.
• The one or more processors and/or transceivers may be further configured to, prior to electronic notification transmission, (i) determine what the customer will be charged after introductory offer expiration; (ii) generate an electronic notification detailing the introductory offer, and explaining what the customer will be charged at that time if they don't cancel the product or service associated with the introductory offer beforehand; and/or (iii) transmit the electronic notification to a customer mobile device via wireless communication or data transmission over one or more radio links or wireless communication channels to facilitate the customer cancelling the product or service before introductory offer expiration and increased charges are incurred, and reducing future financial disputes.
• Determining, via the one or more processors, what the customer will be charged after introductory offer expiration may include an actual periodic price charged by a merchant that produced the introductory offer, or an average or estimated price. Additionally or alternatively, determining, via the one or more processors, what the customer will be charged after introductory offer expiration may include an average or estimated periodic price charged by merchants offering similar products or services than those of the introductory offer.
• The one or more processors and/or transceivers may be further configured to: (i) receive an authorization from a customer to cancel the introductory for them from a customer mobile device via wireless communication or data transmission over one or more radio links or wireless communication channels; and/or (ii) transmit, via wireless communication or data transmission over one or more radio links or wireless communication channels, a cancellation request to a computing device or terminal associated with a merchant from which the introductory offer originates to cancel the introductory offer.
VI. Exemplary System for Fraud Detection & Classification
• FIG. 8 depicts anexemplary computer system500 in which the techniques described herein may be implemented, according to one embodiment. Thecomputer system500 ofFIG. 8 may include a computing device in the form of acomputer510. Components of thecomputer510 may include, but are not limited to, aprocessing unit520, asystem memory530, and asystem bus521 that couples various system components including thesystem memory530 to theprocessing unit520. Thesystem bus521 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, or a local bus, and may use any suitable bus architecture. By way of example, and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus (also known as Mezzanine bus).
• Computer510 may include a variety of computer-readable media. Computer-readable media may be any available media that can be accessed bycomputer510 and may include both volatile and nonvolatile media, and both removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media may include, but is not limited to, RAM, ROM, EEPROM, FLASH memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed bycomputer510.
• Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared and other wireless media. Combinations of any of the above are also included within the scope of computer-readable media.
• Thesystem memory530 may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM)531 and random access memory (RAM)532. A basic input/output system533 (BIOS), containing the basic routines that help to transfer information between elements withincomputer510, such as during start-up, is typically stored inROM531.RAM532 typically contains data and/or program modules that are immediately accessible to, and/or presently being operated on, by processingunit520. By way of example, and not limitation,FIG. 8 illustratesoperating system534,application programs535, other program modules536, andprogram data537.
• Thecomputer510 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,FIG. 8 illustrates a hard disk drive541 that reads from or writes to non-removable, nonvolatile magnetic media, amagnetic disk drive551 that reads from or writes to a removable, nonvolatilemagnetic disk552, and anoptical disk drive555 that reads from or writes to a removable, nonvolatileoptical disk556 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive541 may be connected to thesystem bus521 through a non-removable memory interface such asinterface540, andmagnetic disk drive551 andoptical disk drive555 may be connected to thesystem bus521 by a removable memory interface, such asinterface550.
• The drives and their associated computer storage media discussed above and illustrated inFIG. 8 provide storage of computer-readable instructions, data structures, program modules and other data for thecomputer510. InFIG. 8, for example, hard disk drive541 is illustrated as storingoperating system544,application programs545,other program modules546, andprogram data547. Note that these components can either be the same as or different fromoperating system534,application programs535, other program modules536, andprogram data537.Operating system544,application programs545,other program modules546, andprogram data547 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into thecomputer510 through input devices such as cursor control device561 (e.g., a mouse, trackball, touch pad, etc.) andkeyboard562. Amonitor591 or other type of display device is also connected to thesystem bus521 via an interface, such as avideo interface590. In addition to the monitor, computers may also include other peripheral output devices such asprinter596, which may be connected through an outputperipheral interface595.
• Thecomputer510 may operate in a networked environment using logical connections to one or more remote computers, such as aremote computer580. Theremote computer580 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and may include many or all of the elements described above relative to thecomputer510, although only amemory storage device581 has been illustrated inFIG. 8. The logical connections depicted inFIG. 8 include a local area network (LAN)571 and a wide area network (WAN)573, but may also include other networks. Such networking environments are commonplace in hospitals, offices, enterprise-wide computer networks, intranets and the Internet.
• When used in a LAN networking environment, thecomputer510 is connected to theLAN571 through a network interface oradapter570. When used in a WAN networking environment, thecomputer510 may include amodem572 or other means for establishing communications over theWAN573, such as the Internet. Themodem572, which may be internal or external, may be connected to thesystem bus521 via theinput interface560, or other appropriate mechanism. Thecommunications connections570,572, which allow the device to communicate with other devices, are an example of communication media, as discussed above. In a networked environment, program modules depicted relative to thecomputer510, or portions thereof, may be stored in the remotememory storage device581. By way of example, and not limitation,FIG. 8 illustrates remote application programs585 as residing onmemory device581.
• The techniques for detecting and/or classifying fraud described above may be implemented in part or in their entirety within a computer system such as thecomputer system500 illustrated inFIG. 8. Thecomputer510 may be included inAFSS12 ofFIG. 1, for example, and/or the remote application programs585 may include one or more applications of eitherFAMS14, one ofcardholder computing device20, one ofmerchant computing systems22, or a computing device ofother sources24. Moreover, the functionality of fraud detection/classification unit36 ofFIG. 1 may be implemented by one or more ofapplication programs535 and/or other program modules536. As another example, ML rulesdatabase58, accountholder behaviors database60 and/orchargeback rules database62 ofFIG. 1 may be stored in hard disk drive541 (e.g., as program data547),magnetic disk552 and/oroptical disk drive555, and/or the data retrieved by fraud detection/classification unit36 ofFIG. 1 may be stored in hard disk drive541 (e.g., as program data547) and/or RAM532 (e.g., as program data537).
VII. Exemplary Method Embodiments
• In one aspect, a computer-implemented method, implemented in one or more servers or other computing devices, of facilitating a fraud dispute resolution process involving a customer associated with a financial account may include (1) identifying, by one or more processors of the one or more servers, types of information historically indicative of fraud or an absence of fraud, at least in part by training a machine learning program using at least (i) transaction data associated with a plurality of financial transactions, and (ii) fraud determinations each corresponding to a respective one of the plurality of financial transactions; (2) receiving, by the one or more processors, an indication that fraud is suspected for a first financial transaction associated with the financial account; (3) retrieving, by the one or more processors and from an account records database, transaction data associated with the financial account; (4) generating, by the one or more processors and based upon (i) at least one of the identified types of information and (ii) the transaction data, a first set of one or more queries designed to ascertain whether the first financial transaction was fraudulent; (5) transmitting the first set of queries to a remote computing device to cause the first set of queries to be displayed to the customer; (6) receiving, from the remote computing device, a first set of one or more customer responses; and/or (7) determining, by the one or more processors and based upon the first set of customer responses, whether the first financial transaction was fraudulent. The method may include additional, fewer or alternative actions, such as any of those discussed elsewhere herein.
• For instance, determining whether the first financial transaction was fraudulent may include determining, by the one or more processors and based upon the first set of customer responses, a second set of one or more queries designed to ascertain whether the first financial transaction was fraudulent. Additionally or alternatively, determining whether the first financial transaction was fraudulent may further include (1) transmitting the second set of queries to the remote computing device to cause the second set of queries to be displayed to the customer; (2) receiving, from the remote computing device, a second set of one or more customer responses; and/or (3) determining, by the one or more processors and based upon the second set of customer responses, whether the first financial transaction was fraudulent.
• Additionally or alternatively, generating the first set of one or more queries may include generating at least one query designed to ascertain whether (i) the customer was likely proximate to a location where the first financial transaction occurred at the time the first financial transaction occurred; (ii) the customer recalls a second financial transaction associated with the financial account; and/or (iii) the customer is aware of a billing alias associated with the first financial transaction.
• Additionally or alternatively, the method may further includes causing, by the one or more processors, an indication of whether the first financial transaction was fraudulent to be displayed to one or more people via one or more respective computing device user interfaces.
VIII. Exemplary System Embodiments
• In one aspect, a computer system for facilitating a fraud dispute resolution process involving a customer associated with a financial account may include (1) an account records database storing data associated with a plurality of financial accounts; (2) one or more processors; and/or (3) a non-transitory memory. The memory stores instructions that, when executed by the one or more processors, may cause the one or more processors to (1) identify types of information historically indicative of fraud or an absence of fraud, at least in part by training a machine learning program using at least (i) transaction data associated with a plurality of financial transactions, and (ii) fraud determinations each corresponding to a respective one of the plurality of financial transactions; (2) receive an indication that fraud is suspected for a first financial transaction associated with the financial account; (3) retrieve, from the account records database, transaction data associated with the financial account; (4) generate, based upon (i) at least one of the identified types of information and (ii) the transaction data, a first set of one or more queries designed to ascertain whether the first financial transaction was fraudulent; (5) transmit the first set of queries to a remote computing device to cause the first set of queries to be displayed to the customer; (6) receive, from the remote computing device, a first set of one or more customer responses; and/or (7) determine, based upon the first set of customer responses, whether the first financial transaction was fraudulent. The system may include additional, fewer or alternative components, features and/or functionality, such as any of those discussed elsewhere herein.
• For instance, the instructions may cause the one or more processors to determine whether the first financial transaction was fraudulent at least by determining, based upon the first set of customer responses, a second set of one or more queries designed to ascertain whether the first financial transaction was fraudulent. Additionally or alternatively, the instructions may cause the one or more processors to determine whether the first financial transaction was fraudulent further by (1) transmitting the second set of queries to the remote computing device to cause the second set of queries to be displayed to the customer; (2) receiving, from the remote computing device, a second set of one or more customer responses; and/or (3) determining, by the one or more processors and based upon the second set of customer responses, whether the first financial transaction was fraudulent.
• The first set of one or more queries may include at least one query designed to ascertain whether the customer was likely proximate to a location where the first financial transaction occurred at the time the first financial transaction occurred. Additionally or alternatively, the first set of one or more queries may include at least one query designed to ascertain whether the customer recalls a second financial transaction associated with the financial account. Additionally or alternatively, the first set of one or more queries may include at least one query designed to ascertain whether the customer is aware of a billing alias associated with the first financial transaction. Additionally or alternatively, the instructions may further cause the one or more processors to cause an indication of whether the first financial transaction was fraudulent to be displayed to one or more people via one or more respective computing device user interfaces.
IX. Exemplary Computer-Readable Medium Embodiments
• In one aspect, a non-transitory, computer-readable medium stores instructions that, when executed by one or more processors, may cause the one or more processors to: (1) identify types of information historically indicative of fraud or an absence of fraud, at least in part by training a machine learning program using at least (i) transaction data associated with a plurality of financial transactions, and (ii) fraud determinations each corresponding to a respective one of the plurality of financial transactions; (2) receive an indication that fraud is suspected for a first financial transaction associated with the financial account; (3) retrieve, from an account records database, transaction data associated with the financial account; (4) generate, based upon (i) at least one of the identified types of information and (ii) the transaction data, a first set of one or more queries designed to ascertain whether the first financial transaction was fraudulent; (5) transmit the first set of queries to a remote computing device to cause the first set of queries to be displayed to the customer; (6) receive, from the remote computing device, a first set of one or more customer responses; and/or (7) determine, based upon the first set of customer responses, whether the first financial transaction was fraudulent. The computer-readable medium may store instructions that include additional, fewer or alternative actions, such as any of those discussed elsewhere herein.
• For instance, the instructions may cause the one or more processors to determine whether the first financial transaction was fraudulent at least by (1) determining, based upon the first set of customer responses, a second set of one or more queries designed to ascertain whether the first financial transaction was fraudulent; (2) transmitting the second set of queries to the remote computing device to cause the second set of queries to be displayed to the customer; (3) receiving, from the remote computing device, a second set of one or more customer responses; and/or (4) determining, by the one or more processors and based upon the second set of customer responses, whether the first financial transaction was fraudulent.
• Additionally or alternatively, the first set of one or more queries may include at least one query designed to ascertain whether the customer was likely proximate to a location where the first financial transaction occurred at the time the first financial transaction occurred. Additionally or alternatively, the first set of one or more queries may include at least one query designed to ascertain whether the customer recalls a second financial transaction associated with the financial account. Additionally or alternatively, the first set of one or more queries may include at least one query designed to ascertain whether the customer is aware of a billing alias associated with the first financial transaction. Additionally or alternatively, the instructions may further cause the one or more processors to cause an indication of whether the first financial transaction was fraudulent to be displayed to one or more people via one or more respective computing device user interfaces.
X. Additional Considerations
• The following additional considerations apply to the foregoing discussion. Throughout this specification, plural instances may implement operations or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

Claims (23)

1. A computer-implemented method of pre-empting fraud disputes caused by billing aliases or unrecognized merchant billing names, the method comprising:

receiving historical data associated with a plurality of account holders, the historical data comprising first information about a plurality of historical financial transactions and second information including historical vehicle telematics data;

receiving fraud determination labels associated with the historical data;

inputting the historical data and the fraud determination labels into a machine learning model;

receiving, as an output from the machine learning model, a plurality of query generation rules;

receiving, by one or more processors, an indication that a credit card financial transaction is unrecognizable by a card owner;

applying, based at least in part on the indication, one or more of the query generation rules, by the one or more processors, to:

determine a billing alias for a merchant associated with the credit card financial transaction, the billing alias being named on a credit card statement as a billing merchant,

determine a brick and mortar name that the merchant associated with the billing alias is doing business as,

determine a Global Positioning System (GPS) location of the merchant,

receive a GPS coordinate history of a mobile device or a vehicle of the card owner, owner;

determine that the card owner was within a threshold distance of the GPS location of the merchant on a day of the credit card financial transaction based on the GPS coordinate history, the threshold distance being determined from the one or more of the query generation rules, and

based on determining that the card owner was within the threshold distance, generate an electronic notification notifying the card owner of one or more of (i) the brick and mortar name of the merchant, (ii) the GPS location of the merchant, or (iii) that the card owner was at the GPS location of the merchant on the day of the credit card financial transaction;

transmitting, by the one or more processors, the electronic notification to the mobile device of the card owner for card owner review or verification to facilitate resolving erroneous disputes caused by unrecognized financial transactions; and

training the machine learning model based at least in part on a response of the card owner to the electronic notification.

2. The computer-implemented method ofclaim 1, wherein determining the brick and mortar name is performed by inputting the billing alias into a machine learning program trained to determine a real world name for the merchant associated with the billing alias.

3. The computer-implemented method ofclaim 1, wherein the determining the billing alias for the merchant includes applying an Optical Character Recognition (OCR) technique to a digital or hardcopy billing statement to determine the billing alias.

4.-6. (canceled)

7. The computer-implemented method ofclaim 1, wherein receiving the indication that the credit card financial transaction is unrecognizable occurs over one or more radio frequency links.

8. A computer system configured to pre-empt fraud disputes, the computer system comprising one or more processors configured to:

receive historical data associated with a plurality of account holders, the historical data comprising first information about a plurality of historical financial transactions and second information including historical vehicle telematics data;

receive fraud determination labels associated with the historical data;

input the historical data and the fraud determination labels into a machine learning model;

receive, as an output from the machine learning model, a plurality of query generation rules;

receive an indication that a credit card financial transaction is unrecognizable by a card owner;

apply, based at least in part on the indication, one or more of the query generation rules, by the one or more processors, to:

determine a billing alias for a merchant associated with the credit card financial transaction, the billing alias being named on a credit card statement as a billing merchant,

determine a brick and mortar name that the merchant associated with the billing alias is doing business as,

determine a GPS location of the merchant,

receive a GPS coordinate history of a mobile device or a vehicle of the card owner;

determine that the card owner was within a threshold distance of the GPS location of the merchant on a day of the credit card financial transaction based on the GPS coordinate history, the threshold distance being determined from the one or more of the query generation rules, and

based on determining that the card owner was within the threshold distance, generate an electronic notification notifying the card owner of one or more of (i) the brick and mortar name of the merchant, (ii) the GPS location of the merchant, or (iii) that the card owner was at the GPS location of the merchant on the day of the credit card financial transaction;

transmit the electronic notification to the mobile device of the card owner for card owner review or verification to facilitate resolving erroneous disputes caused by unrecognized financial transactions; and

train the machine learning model based at least in part on a response of the card owner to the electronic notification.

9. The computer system ofclaim 8, wherein the determining the brick and mortar name that the merchant associated with the billing alias is doing business as is performed by inputting the billing alias into a machine learning program trained to determine a real world name for the merchant associated with the billing alias.

10. The computer system ofclaim 8, wherein determining the billing alias for the merchant includes applying an Optical Character Recognition (OCR) technique to a digital or hardcopy billing statement.

11. The computer system ofclaim 8, wherein the determining the billing alias for the merchant includes retrieving the billing alias using digital processor analysis on a digital billing or financial statement.

12.-14. (canceled)

15. A non-transitory, computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to:

receive historical data associated with a plurality of account holders, the historical data comprising first information about a plurality of historical financial transactions and second information including historical vehicle telematics data;

receive fraud determination labels associated with the historical data;

input the historical data and the fraud determination labels into a machine learning model;

receive, as an output from the machine learning model, a plurality of query generation rules;

receive an indication that a credit card financial transaction is unrecognizable by a card owner;

apply, based at least in part on the indication, one or more of the query generation rules, by the one or more processors, to:

determine a billing alias for a merchant associated with the credit card financial transaction, the billing alias being named on a credit card statement as a billing merchant,

determine a brick and mortar name that the merchant associated with the billing alias is doing business as,

determine that the merchant has a GPS location in a vicinity of a home address of the card owner;

determine a GPS location of the merchant,

receive a GPS coordinate history of a mobile device or a vehicle of the card owner;

determine that the card owner was within a threshold distance of the GPS location of the merchant on a day of the credit card financial transaction based on the GPS coordinate history, the threshold distance being determined from the one or more of the query generation rules, and

based on determining that the card owner was within the threshold distance, generate an electronic notification notifying the card owner of one or more of (i) the brick and mortar name of the merchant, (ii) the GPS location of the merchant, or (iii) that the card owner was at the GPS location of the merchant on the day of the credit card financial transaction;

transmit the electronic notification to the mobile device of the card owner for card owner review or verification to facilitate resolving erroneous disputes caused by unrecognized financial transactions; and

train the machine learning model based at least in part on a response of the card owner to the electronic notification.

16. The non-transitory, computer-readable medium ofclaim 15, wherein the one or more processors are configured to determine the brick and mortar name that the merchant associated with the billing alias is doing business as at least by inputting the billing alias into a machine learning program trained to determine a real world name for the merchant associated with the billing alias.

17. The non-transitory, computer-readable medium ofclaim 15, wherein the one or more processors are configured to determine the billing alias for the merchant at least in part by applying an OCR technique to a digital or hardcopy billing statement.

18. The non-transitory, computer-readable medium ofclaim 15, wherein the one or more processors are configured to determine the billing alias for the merchant at least in part by retrieving the billing alias using digital processor analysis on a digital billing or financial statement.

19.-20. (canceled)

21. The computer-implemented method ofclaim 1, further comprising:

receiving, by the one or more processors from the mobile device of the card holder, a response indicating that the credit card financial transaction is unverified by the card holder; and

based on the response, determining, by the one or more processors, that the credit card financial transaction is fraudulent.

22. The computer-implemented method ofclaim 1, further comprising:

receiving, by the one or more processors from the mobile device of the card holder, a response indicating that the credit card financial transaction is verified by the card holder; and

based on the response, determining, by the one or more processors, that the credit card financial transaction is approved.

23. The computer-implemented method ofclaim 1, wherein the electronic notification indicates (i) the brick and mortar name of the merchant, (ii) the GPS location of the merchant, and (iii) that the card owner was at the GPS location of the merchant on the day of the credit card financial transaction.

24. The computer system ofclaim 8, wherein the one or more processors are further configured to:

receive, from the mobile device of the card holder, a response indicating that the credit card financial transaction is unverified by the card holder; and

based on the response, determine that the credit card financial transaction is fraudulent.

25. The computer system ofclaim 8, wherein the one or more processors are further configured to:

receive, from the mobile device of the card holder, a response indicating that the credit card financial transaction is verified by the card holder; and

based on the response, determine that the credit card financial transaction is approved.

26. The computer system ofclaim 8, wherein the electronic notification indicates (i) the brick and mortar name of the merchant, (ii) the GPS location of the merchant, and (iii) that the card owner was at the GPS location of the merchant on the day of the credit card financial transaction.

27. The non-transitory, computer-readable medium ofclaim 15, wherein the instructions, when executed by one or more processors, further cause the one or more processors to:

receive, from the mobile device of the card holder, a response indicating that the credit card financial transaction is verified by the card holder; and

based on the response, determine that the credit card financial transaction is approved.

28. The non-transitory, computer-readable medium ofclaim 15, wherein the electronic notification indicates (i) the brick and mortar name of the merchant, (ii) the GPS location of the merchant, and (iii) that the card owner was at the GPS location of the merchant on the day of the credit card financial transaction.

Images