Systems and methods for aggregated database for cross-issuer fraud detection system

A method for establishing fraud detection system for payment card transactions associated with an individual or a household by analyzing the online or in-store transaction against fraud detection individual profile. Generating the individual profile involves retrieving transaction data and identifying information associated with transaction authorization request, searching for another payment card using the identifying information, aggregating payment cards transaction data, generating profile data for an individual according to identifying information, transaction data, and any reported fraudulent activities under the payment cards, analyzing the transaction against the profile data to determine whether the transaction is a fraudulent activity, and providing a notification to financial institutions reporting any fraudulent activities. The fraud detection system for a household analyzes an online or in-store transaction against a household profile that associates all payment cards in consumer's household to create a complete picture of the buying behavior of the consumer household.

TECHNICAL FIELD

Various embodiments of the present disclosure relate generally to electronic payment fraud detection infrastructure and, more particularly, to an aggregated database for establishing a cross-issuer fraud detection system across multiple payment cards used by consumers.

BACKGROUND

An average consumer in the United States carries about four to six different credit and/or debit cards in their wallet and may use different cards for different types of transactions. Traditionally, financial institutions (e.g., banks) monitor an individual's credit or debit card activity to check for any fraudulent activities. Most transaction fraud systems monitor cardholders' buying behavior at the individual card level. However, monitoring transactions at the card level provides a limited view of the spending patterns of a consumer. Additionally, monitoring buying behavior for fraudulent activities at the individual card level creates problems, since some fraudulent activity may go unnoticed, whereas valid transactions may be inadvertently declined. The most common solution today is to decline suspicious transactions even without confirmation of fraud, which then typically prompts the consumer to use a different credit/debit card to complete the transaction. This practice further results in a poor consumer experience and lost revenue opportunities for the card issuer or other financial institution.

SUMMARY OF THE DISCLOSURE

According to certain aspects of the disclosure, systems and methods are disclosed for establishing an aggregated database for operating a cross-issuer fraud detection system for payment cards used by consumers, at the wallet and/or household level.

In one embodiment, a computer-implemented method is disclosed for establishing an aggregated database for operating a cross-issuer fraud detection system for payment cards used by consumers, at the wallet and/or household level. The method includes: sending, over a computer network, an authorization request to an acquirer processor for an online or brick-and-mortar payment transaction using a first payment card, retrieving, at the acquirer processor, transaction data and identifying information associated with the authorization request before the authorization request is routed to a financial institution, and determining, by the acquirer processor, whether an individual fraud detection profile associated with the retrieved identifying information exists in a profile database.

In the above exemplary embodiment, the method further includes: analyzing, using the acquirer processor, the online or brick-and-mortar payment transaction against the individual fraud detection profile as a result of determining that the individual fraud detection profile exists, determining, using the acquirer processor, whether the online or brick-and-mortar payment transaction is a fraudulent activity, sending, over the computer network, as a result of determining that the online or brick-and-mortar payment transaction is a fraudulent activity, a notification to the financial institution for the fraudulent activity and declining, at the financial institution, the authorization request for the online or brick-and-mortar payment transaction.

In another embodiment, as a result of determining that the individual fraud detection profile does not exist, the method further comprises: storing, at a transaction database, as a result of determining that the individual's fraud detection profile does not exist, transaction data with other transaction data associated with the first payment card, searching, by the acquirer processor, for a second payment card associated using the identifying information at the transaction database, aggregating, by the acquirer processor, transaction data associated with the first and second payment cards from the transaction database, retrieving, from the at least one financial institution, reported fraudulent activities pertaining to the first and the second payment cards, generating profile data for an individual according to the at least one of the identifying information associated with the authorization request, personally identifiable information (PII) of the individual, the aggregated transaction data associated with the first and the second payment cards, and reported fraudulent activities on the first and the second payment cards, generating, by the acquirer processor, a unique hash value for the generated profile data associated with the individual, analyzing, using the acquirer processor, the online or brick-and-mortar payment transaction against the profile data, sending, over the computer network, as a result of determining that the online or brick-and-mortar payment transaction is a fraudulent activity, a notification to the financial institution reporting the fraudulent activity, and declining, at the financial institution, authorization request for the online or brick-and-mortar payment transaction.

Additional objects and advantages of the disclosed embodiments will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosed embodiments. The objects and advantages of the disclosed embodiments will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. As will be apparent from the embodiments below, an advantage to the disclosed systems and methods is that multiple parties may fully utilize their data without allowing others to have direct access to raw data. The disclosed systems and methods discussed below may allow advertisers to understand users' online behaviors through the indirect use of raw data and may maintain privacy of the users and the data.

DETAILED DESCRIPTION OF EMBODIMENTS

As described above, there is a need for a universal fraud detection profile that associates transaction data across multiple credit and debit cards in a consumer's wallet to create a more complete picture of the buying behavior of the consumer. Transaction data may be aggregated in a cross-issuer database and indexed to consumers and/or households using identifying information associated with the transaction, such as personally identifiable information (PII) of an individual associated with the transaction, a device fingerprint, device-specific information, an originating IP address, which may be determined through IP proxy piercing, etc. The personally identifying information (PII) may be leveraged from e-commerce data, such as by e-mail address, mailing address, or other unique identifier (e.g., a hash or alpha-numeric code). This information may then be used to train and execute an aggregated fraud scoring system to better predict and act on fraudulent transactions, regardless of which issuer and/or issuer processor is associated with each card. Thus, various embodiments of the present disclosure relate generally to analyzing online or brick-and-mortar transactions for fraudulent activity across data aggregated from across card issuers according to an individual or a household fraud detection profile.

Turning toFIG. 1, an exemplary system infrastructure is depicted for payment processing within a merchant environment, according to one or more embodiments. In an example embodiment, a consumer102may use one or more payment cards for conducting transactions at one or more merchants110through a payment environment100. As shown inFIG. 1, merchant110may provide infrastructure for processing electronic payment requests. Traditionally, in an electronic payment processing system, a consumer102, during the checkout process with a merchant110, pays for goods or services from a merchant110at a PIN pad terminal112associated with a point-of-sale (“POS”) terminal. Because merchant110can generally use a different bank or financial institution140than consumer102, an acquirer processor that handles financial transactions may transfer payment between the financial institution140of consumer102and that of merchant110. Consumer102submits payment information at the PIN pad112associated with the merchant's POS terminal, such as by swiping his or her payment card, inserting his or her chip-based payment card, through wireless near field communication (NFC), etc., or by any other suitable means. PIN pad112may send a payment request by way of a computer network120to an acquirer processor (e.g., one of financial institutions140). Alternatively, such a request may be sent by a component that controls a flow of a transaction, such as point of sale (POS) engine. The acquirer processor may request, by way of payment network120, an electronic transfer of funds from the received funds to the financial institution140associated with merchant110.

In general, a cross-issuer fraud detection computing system150may be operated by an acquirer processor, issuer processor, card issuer, or any other financial institution140. The cross-issuer fraud detection computing system150may be operated by another entity or operated independently. In any event, cross-issuer fraud detection computing system150may be configured to intercept authorization requests sent across payment network120, or otherwise receive data about payment transactions sent between merchants110and financial institutions140.

In an example embodiment, as shown inFIG. 1, a cross-issuer fraud detection computing system150comprises a processor132, memory134, profile database136, transaction database144, application server138, and web server142. As shown inFIG. 1, the profile database136for an individual further comprises a unique identifier hash recognizing the profile of an individual, primary account numbers (e.g., PANs) or other identifiers of payment vehicles (e.g. debit, credit cards) associated with the individual, personally identifiable information (PII), and/or data/analysis of an individual's spending habits, geographic area, and fraud activities reported on the cards associated with the individual. In an example embodiment, the personally identifiable information (PII) about the individual involves at least one of his/her name, email address, date of birth, social security number, and physical address.

In the above embodiment, the cross-issuer fraud detection computing system150further comprises transaction database144. The transaction database144comprises important transaction data associated with the payment vehicles104and106. The transaction database may comprise tables containing source ID, terminal ID, date and time, IP address, location, and transaction amount for the transactions associated with payment vehicle104and payment vehicle106.

Turning toFIG. 2, a cross-issuer fraud detection computing system for a household involves multiple related individuals (e.g., consumer102and consumer103) using multiple payment vehicles (e.g.,108and109). As shown inFIG. 2, cross-issuer fraud detection computing system150comprises processor132, memory134, profile database136, transaction database144, application server138, and web server142. The profile database136for a household further comprises a unique identifier hash recognizing a household, unique IDs associated with each member of the household, payment vehicles (e.g. debit, credit cards) associated with each member of the household, PII associated with each member of the household, and data/analysis of spending habits, geographic area, and reported fraud activities on the cards associated with each member of the household. In an example embodiment, the PII of each member of the household involves at least one of the member's name, email address, date of birth, and physical address.

According to one or more embodiments, the components of infrastructure100and200may be connected by a computer network120, such as, for example a local area network (LAN) or a wireless network, such as, for example, a Wi-Fi network. However, other network connections among the components of infrastructure100may be used, such as, for example, a wide area network (WAN), the Internet, or the cloud. Methods of establishing fraud detection system for an individual and/or household according to one or more embodiments will be discussed with respect toFIGS. 3-4below. Functions of the components of infrastructure100and200will be described below with respect to exemplary methods for cross-issuer fraud detection computing systems for individuals and households.

FIG. 3illustrates a method300for establishing a cross-issuer (e.g., a so-called “wallet-based”) fraud detection system for an individual. The cross-issuer fraud detection system may be referred to as “wallet-based” because it may enable analysis and synthesizing of transaction and fraud data across all credit/debit cards within a consumer's wallet, regardless of issuer. As described above with respect toFIGS. 1-2, a merchant110may request authorization for a transaction initiated using a payment vehicle or card104-109. In an example embodiment, the transaction may be for purchase of an item or a service, or for a withdrawal of cash. Thus, at step310of method300(FIG. 3), a merchant110may send (or an acquirer processor may receive) an authorization request for an online or brick-and-mortar transaction over a wireless network. Such an authorization request may be intercepted by or otherwise received at processor132of fraud detection computing system150. At step320, the processor132may retrieve identifying information associated with the transaction and transaction data from the authorization request before the authorization request is routed to a financial institution. The identifying information may include, for example, personally identifiable information (PII) of an individual associated with the transaction, a device fingerprint, device-specific information, an originating IP address, which may be determined through IP proxy piercing, etc. Further, at step330, the processor132may search a profile database136for a fraud detection profile associated with the identifying information associated with the transaction.

In an example embodiment, if the processor132finds profile associated with the identifying information associated with the transaction in profile database136, the acquirer processor may further analyze the transaction against the profile to determine whether the online or in-store transaction is fraudulent, as per steps340and342. If the processor132determines, e.g., at step342, that the transaction is fraudulent, then the acquirer processor may further send a notification to the web server142along with the authorization request, at step344, which is sent to a financial institution140. Financial institution140may, based on the fraud message, decline the transaction according to the notification provided by the processor132, at step346. The transaction data may comprise at least one of a merchant's ID, transaction location, terminal information, source IP address, date and time of the transaction, device information, transaction amount of the purchase, and payment card information.

In another embodiment, if the processor132does not find a profile within the profile database136, the processor132may store the transaction in a transaction database144. The processor132may further search for any additional payment cards associated with the retrieved identifying information associated with the transaction from the transaction database144. The processor132may aggregate transaction data associated with payment card(s) from the transaction database144. The processor132may retrieve any reported fraudulent activities from at least one financial institution140associated with the payment cards as per operation356. At step358, the processor132may generate a profile for an individual according to the retrieved identifying information associated with the transaction, aggregated transaction data from the payment cards, and reported fraudulent activities from at least one financial institution140. The acquirer processor132may also generate a unique hash value for the generated profile data for the individual (e.g., consumer102). Once the profile data for the individual is generated, the processor132may analyze the online or brick-and-mortar transaction against the generated profile according to operation340, and further determine whether the transaction is fraudulent as per step342.

In the above-illustrated embodiment, the processor132may notify the financial institution140associated with the transaction if it determines the transaction to be fraudulent. The processor132may attach the notification to the authorization request before sending the authorization request to the web server142communicating with the financial institution140. In another embodiment, the processor132may attach the fraudulent activity analysis to the authorization request before sending the request to the financial institution140.

In an exemplary embodiment, the authorization request may be presented with the fraudulent activity analysis report at the graphical user interface associated with the web server142. In another embodiment, the processor132may determine whether to decline or approve the transaction without involving the financial institution140.

The method of establishing the cross-issuer fraud detection computing system disclosed herein may provide a multidimensional score for one in-store or online transactions for presentation to and use by a variety of different merchants and issuers. For example, the multidimensional fraud score may determine and communicate the likelihood of the transaction being fraudulent according to the cross-issuer analysis of the transaction in operation340.

In one embodiment, the individual profile data are at least one of the individual's spending irregularities and analysis of reported fraudulent activity associated with the payment cards linked to the individual. The spending irregularities of the individual are computed according to the individual's spending habits, geographic area, and type of payment cards used for those payments. Additionally, the personally identifiable information (PII) comprises at least one of a name, physical address, email address, etc. of the individual, wherein the payment cards104and106are debit or credit cards issued by at least one financial institution. In the exemplary embodiment, the microprocessor-enabled payment vehicles are payment cards using computer chips to authenticate transactions according to Europay, MasterCard, and Visa (EMV) global standard. The contactless payment vehicles are either EMV or NFC compatible payment cards.

Turning toFIG. 4, exemplary systems and processes are disclosed for establishing a cross-issuer fraud detection system for a household. One of the members of a household may purchase a good or service at the merchant110, either online or in-store, using one of the payment vehicles (e.g.,106,108). The merchant110may send the authorization request to the processor132over a computer network. The processor132may retrieve transaction data and identifying information associated with the transaction from the authorization request before the authorization request is routed to a financial institution140. The identifying information may include, for example, personally identifiable information (PII) of an individual associated with the transaction, a device fingerprint, device-specific information, an originating IP address, which may be determined through IP proxy piercing, etc.

The processor132may further search whether a household fraud detection profile for the retrieved identifying information associated with the transaction exists in a profile database136. If the processor132determines that no household profile exists for retrieved identifying information associated with the transaction, the acquirer processor stores the transaction data with the rest of the transaction data associated with the payment card at the merchant110.

The processor132further searches a public records database and profile database for individuals associated with the retrieved identifying information associated with the transaction. The processor132also may search for payment cards associated with members of a household using the retrieved identifying information associated with the transaction in the transaction database144. The processor132may aggregate transaction data from the transaction database144for the at least one payment card(s) belonging to the individuals associated with the received identifying information associated with the transaction. The processor132also may retrieve reported fraudulent activities pertaining to the payment cards from the at least one financial institution140.

In the above-explained embodiment, the processor132may generate household profile data involving each member of the household according to the retrieved identifying information associated with the transaction, PII of the individual, the aggregated transaction data associated with the payment cards, and reported fraudulent activities on the payment cards. The processor132further generates the household profile presenting the household member's spending irregularities and suspicious activities associated with the at least one payment cards linked to the household profile. In the above exemplary embodiment, the household member's spending irregularities are calculated based on at least one of the member's spending habits, geographic area, and type of payment cards.

The acquirer processor further generates a unique hash value for generated household profile data and links the members of the household profile with the generated unique hash value. In another embodiment, if only one individual's information is retrieved, the processor132may generate an individual profile over household profile data.

In an alternative embodiment, the processor132may search the profile database136to find individual profiles related to retrieved identifying information associated with the transaction. The processor132may link the unique hash value associated with individual profiles to the household profile hash value for the household members with individual profiles. In the above embodiment, the linking profile data may comprise generating, a rollup identifier identifying the household, wherein the rollup identifier provides a pointer to the unique hash value associated with the profile data of household members, and wherein the rollup identifier is common to a plurality of household members.

In a different exemplary embodiment, the processor132may search for both household profile and an individual profile for the retrieved identifying information associated with the transaction in the prolife database136. The search derives either the household or an individual profile for the retrieved identifying information associated with the transaction in the profile database136.

In an example embodiment, the processor132may analyze the online or in-store transaction against the profile data associated with each member of the household as per operation. The processor132may send a notification to the financial institution reporting any online or in-store transaction is determined to be fraudulent. The financial institution140may decline the online or in-store transaction according to the notification provided from the processor132as per operation446.

In one embodiment, the processor132may generate a multidimensional score for the online or in-store transaction according to the household profile. The acquirer processor may provide score embedded to every transaction to the financial institution140. The multidimensional score may be a score representing the probability that the transaction is fraudulent.

FIG. 5is an example representation of transaction analysis presented to the financial institution140. The presentation further provides transaction data to view to the financial institution, e.g., at step520. The individual fraud analysis (step530) may include determining frequencies of spending habits, irregularities, geographic area and reported fraudulent activities. The fraudulent activity score510may be determined according to the frequencies of spending habits, irregularities, geographic area and reported fraudulent activities, as shown in step530.

The systems and processes described above by the acquirer processor may be performed on or between one or more computing devices.FIG. 6illustrates an example computing device. A computing device600may be a server, a computing device that is integrated with other systems or subsystems, a mobile computing device such as a smart phone, a cloud-based computing ability, and so forth. The computing device600may be any suitable computing device as would be understood in the art, including without limitation, a custom chip, and embedded processing device, a tablet computing device, a POS terminal associated with the merchant110, a back-office system of a merchant110, a personal data assistant (PDA), a desktop, laptop, microcomputer, and minicomputer, a server, a mainframe, or any other suitable programmable device. In various embodiments disclosed herein, a single component may be replaced by multiple components and multiple components may be replaced by a single component to perform a given function or functions. Except where such substitution would not be operative, such substitution is within the intended scope of the embodiments.

The computing device600includes a processor610that may be any suitable type of processing unit, for example a general-purpose central processing unit (CPU), a reduced instruction set computer (RISC), a processor that has a pipeline or multiple processing capability including having multiple cores, a complex instruction set computer (CISC), a digital signal processor (DSP), application specific integrated circuits (ASIC), a programmable logic devices (PLD), and a field programmable gate array (FPGA), among others. The computing resources may also include distributed computing devices, cloud computing resources, and virtual computing resources in general.

The computing device600also includes one or more memories630, for example read-only memory (ROM), random access memory (RAM), cache memory associated with the processor610, or other memory such as dynamic RAM (DRAM), static RAM (SRAM), programmable ROM (PROM), electrically erasable PROM (EEPROM), flash memory, a removable memory card or disc, a solid-state drive, and so forth. The computing device600also includes storage media such as a storage device that may be configured to have multiple modules, such as magnetic disk drives, floppy drives, tape drives, hard drives, optical drives and media, magneto-optical drives and media, compact disk drives, Compact Disc Read Only Memory (CD-ROM), compact disc recordable (CD-R), Compact Disk Rewritable (CD-RW), a suitable type of Digital Versatile Disc (DVD) or BluRay disc, and so forth. Storage media such as flash drives, solid-state hard drives, redundant array of individual discs (RAID), virtual drives, networked drives and other memory means including storage media on the processor610, or memories630are also contemplated as storage devices. It may be appreciated that such memory may be internal or external with respect to operation of the disclosed embodiments. It may be appreciated that certain portions of the processes described herein may be performed using instructions stored on a computer readable medium or media that direct computer system to perform the process steps. Non-transitory computable-readable media, as used herein, comprises all computer-readable media except for transitory, propagating signals.

Networking communication interfaces640may be configured to transmit to, or receive data from, other computing devices600across a network660. The network and communication interfaces640may be an Ethernet interface, a radio interface, a Universal Serial Bus (USB) interface, or any other suitable communications interface and may include receivers, transmitter, and transceivers. For purposes of clarity, a transceiver may be referred to as a receiver or a transmitter when referring to only the input or only the output functionality of the transceiver. Example communication interfaces640may include wire data transmission links such as Ethernet and TCP/IP. The communication interfaces640may include wireless protocols for interfacing with private or public networks660. For example, the network and communication interfaces640and protocols may include interfaces for communicating with private wireless networks such as Wi-Fi network, one of the IEEE 802.11x family of networks, or another suitable wireless network. The network and communication interfaces640may include interfaces and protocols for communicating with public wireless networks660, using for example wireless protocols used by cellular network providers, including Code Division Multiple Access (CDMA) and Global System for Mobile Communications (GSM). A computing device600may use network and communication interfaces640to communicate with hardware modules such as a database or data store, or one or more servers or other networked computing resources. Data may be encrypted or protected from unauthorized access.

In various configurations, the computing device600may include a system bus650for interconnecting the various components of the computing device600, or the computing device600may be integrated into one or more chips such as programmable logic device or application specific integrated circuit (ASIC). The system bus650may include a memory controller, a local bus, or a peripheral bus for supporting input and output devices620, and communication interfaces640. Example input and output devices620include keyboards, keypads, gesture or graphical input devices, motion input devices, touchscreen interfaces, one or more displays, audio units, voice recognition units, vibratory devices, computer mice, and any other suitable user interface.

The processor610and memory630may include nonvolatile memory for storing computable-readable instructions, data, data structures, program modules, code, microcode, and other software components for storing the computer-readable instructions in non-transitory computable-readable mediums in connection with the other hardware components for carrying out the methodologies described herein. Software components may include source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, or any other suitable type of code or computer instructions implemented using any suitable high-level, low-level, object-oriented, visual, compiled, or interpreted programming language.