SYSTEM AND METHOD FOR IDENTIFYING COMPROMISED ACCOUNTS

Abstract

Using common points-of-purchase revealed by back trace windows, a merchant risk system provides suspect merchants to a financial institution (such as a card issuer), identifying merchants who may have had account data (such as credit card numbers) compromised. In one embodiment, merchants are ranked based on spikes in fraudulent transactions on cards used at those merchants. Merchants may also be identified based on merchant risk scores that are calculated using data from the back trace windows.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Patent Application No. 62/174,432 filed Jun. 11, 2015 and titled “System and Method for Identifying Compromised Accounts,” the entire disclosure of which is hereby incorporated by reference herein for all purposes.

BACKGROUND OF THE INVENTION

Fraudulent credit card and other financial transactions often result from breached or compromised systems that store account data. As an example, fraudsters may “hack” into a retailer/merchant system and steal credit card information of the merchant's customers, and then subsequently use that credit card information to conduct fraudulent transactions.

Much of the fraudulent activity that is conducted today involves at least two persons or entities, namely, a first entity that unlawfully accesses and steals the account data, and then a second entity that purchases the stolen account data and attempts to conduct a transaction using the data.

Entities that unlawfully gain access to systems to steal data have become sophisticated in their approaches to accessing the data and then turning around and selling the data to other entities. Fraudsters are able to access extensive card data (involving thousands, if not millions, of account holders) by installing malicious software at a system where data is maintained, such as at a retailer system where card data is accumulated during transactions at the retailer. In other cases, a fraudster may attach a “skimmer” to a terminal (such as a point-of-sale terminal or an ATM) where customers may swipe a card and unknowingly provide card data to the fraudster. Where systems are hacked or skimmers are used, the activity may occur over a substantial period of time and result in continuously capturing new card data as it is collected at the compromised system, thereby enabling the fraudster to sometimes accumulate vast amounts of data before being detected.

Because the fraudulent acquisition of data, such as by the use of malicious software, may occur over a period of time (say weeks or even months), it may be difficult for card issuers to identify when and where a breach or compromise occurred (and which card accounts may have been impacted).

Financial institutions have used various approaches to identify a location and time where data may be been compromised. For example, when fraudulent transactions against credit or debit cards are reported, card transactions may be cross checked to identify any retailer or merchant where the cards may have been used in common (a common point-of-purchase). If a meaningful number of fraudulent transactions can all be back traced to a common point-of-purchase, then a financial institution analyzing transaction data can assume that any other account data collected by the merchant at the common point-of-purchase during the same time has likewise been compromised, and can take steps to scrutinize the identified accounts for fraudulent activity, and perhaps close the accounts or reissue account cards.

However, identifying a common point-of-purchase can be difficult, especially when fraudulent transactions are conducted against the compromised accounts in patterns that are difficult to analyze. For example, an entity that has hacked into a retailer system and acquired account data relating to large numbers of accounts across many financial institutions, may “package” the stolen data for subsequent use in ways that make detection difficult. The stolen account data for one financial institution may be sold to a first entity that uses it immediately for fraudulent transactions, and then later in time, account data for a different financial institution may be sold to a second entity. Only one financial institution may be initially aware of the breach, since not all the stolen card data is being used fraudulently at the same time. In other instances, an entity that has hacked into a retailer system may “package” the stolen data according to its value. For example, debit cards and credit cards with lower credit limits may be less valuable and may be sold to one entity, and premium credit cards with higher credit limits may be sold at a different time (and at a higher price) to another entity. With perhaps only portions of the stolen data being used when fraudulent transactions are first detected, back tracing transactions to find a common point-of-purchase can be difficult, leading to extensive losses by financial institutions until the likely location and time of breach has been identified.

Adding to the difficulty in back tracing is the common occurrence of groups of cards being used for authorized transactions at two close merchant locations at nearly the same time. If two merchant locations are located close to each other, many customers visiting one merchant location may immediately thereafter visit the other merchant nearby (e.g., at a multi-merchant retail center, a customer shopping at one merchant may also shop at another merchant next door).

If there has been a suspected breach, it may be difficult to know which of the two merchants has given rise to the suspected breached.

Further, once a potential breach has been identified, large numbers of accounts or credit cards may be potentially implicated and a financial institution may be forced into monitoring all those accounts, even those accounts at lower risk for fraudulent transactions. In some cases, the results of the analysis leading to the common point-of-purchase can be ambiguous, and may indicate (either correctly or not) that there may be more than one potential compromised system. This can make it difficult for a financial institution to properly address a potential breach of data pertaining to its accounts, and can lead to needless expense in trying to contain the risk.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the invention identify accounts that have been compromised at a common point-of-use, such as a common point-of-purchase merchant. In one embodiment, a system for identifying accounts that have been compromised at a common point-of-purchase merchant includes a data aggregating system receiving transaction data from a plurality of financial institutions, and standardizing the transaction data; a transaction data management system receiving and storing the standardized transaction data from the data aggregating system, for subsequent evaluation in connection fraudulent transactions reported against accounts at the plurality of financial transactions; a fraud reporting system that identifies fraudulent transactions against at-risk accounts at the plurality of financial institutions; and a merchant risk system. The merchant risk system receives identified fraudulent transactions from the fraud reporting system and, in response to the identified fraudulent transactions received from the fraud reporting system, (1) accesses transaction data stored at the transaction data management system, (2) analyzes the accessed transaction data for transactions conducted against the at-risk accounts over a period of time prior to the identified fraudulent transactions, and (3) provides, to at least one of the financial institutions, risk data relating to a possible compromise of account data for the at-risk accounts. The risk data includes data identifying a merchant where the at-risk accounts were used to conduct a transaction prior to the identified fraudulent transactions, and data relating to fraudulent transactions against accounts at financial institutions other than the at least one financial institution to which the risk data is provided.

A more complete understanding of the present invention may be derived by referring to the detailed description of the invention and to the claims, when considered in connection with the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a general block diagram illustrating a network in which a plurality of financial institutions contribute data that is used to identify merchants suspected of having compromised customer account data.

FIG. 2 is a flow diagram illustrating a general process for identifying a potential breach of a merchant system and providing risk scores corresponding to the merchant breach.

FIG. 3 is a flow diagram illustrating an overall process for identifying merchants suspected as having compromised account data, and a merchant risk score for one or more of the suspect merchants.

FIG. 4 illustrates data collected for a merchant where cards having fraudulent transactions have been used, the data organized into a back trace window in order to identify a merchant suspected of having a potential breach and to generate corresponding merchant risk scores.

FIG. 5 is a flow diagram illustrating a specific process for identifying suspected merchants based on either spikes in fraudulent transactions or merchant risk scores.

FIG. 6 is a flow diagram illustrating a specific process for calculating merchant risk scores based on MERC values.

FIGS. 7a and 7b illustrate data provided to a financial institution relating to a potential breach of a merchant system.

FIG. 8 is a block diagram illustrating an exemplary computer system upon which embodiments of the present invention may be implemented.

DETAILED DESCRIPTION OF THE INVENTION

There are various embodiments and configurations for implementing the present invention. Generally, disclosed embodiments provide systems and methods for identifying risk associated with account data that may have been compromised, and using back traced data to find a common point-of-purchase. The back traced data is based on the transaction data for accounts from multiple financial institutions. In some embodiments, a merchant that has had a suspected/potential breach of data is identified, based on spikes in fraudulent transactions (for cards used at that merchant). In other embodiments, merchant risk scores are developed for a merchant location that may have been breached, and suspect merchants are identified based on the merchant risk scores. In yet other embodiments, an account risk score may also be developed for accounts that may have been breached at the merchant location.

In one embodiment, a method and system for scoring risk uses transaction data contributed by a plurality of financial institutions, such as banks, that maintain accounts and issue credit, debit or other types of cards. The use of transaction data from more than one financial institution improves the accuracy and timeliness in identifying a breach of data, such as at a retailer/merchant system. The transaction data is back traced to identify common points-of-purchase for cards having fraudulent transactions. Merchants having a system breach may be identified based on spikes in fraudulent activity. Additionally, merchants having a system breach may be identified based on calculated merchant risk scores. In some embodiments, a card issuer (financial institution) may receive risk scores for each of multiple merchants (each score representing a specified level of risk associated with one of the merchants), thus permitting the card issuer to scrutinize transactions conducted against accounts where the risk resulting from a breach or compromise may be, at least initially, ambiguous and the specific merchant involved may be difficult to definitively identify. In some embodiments, a financial institution may also receive both a merchant risk score (reflecting a risk that card data used in transactions conducted at a merchant may have been compromised) and an account risk score (reflecting a risk that an account, if breached, may be used for a fraudulent transaction).

In described embodiments, suspected merchants having a potential/suspected breach are identified (and merchant risk scores generated) based on transaction data that is organized around a back trace window (e.g., the back trace window may include a preceding 180 day period over which the transaction data is collected). Among other things, the data in the window reflects, for a specified merchant, whether there has been a fraudulent transaction reported for a card (a “claim”) on a given day (a “claim date”), if that card has been previously used at the specified merchant at any time during the back trace window (e.g., the preceding 180 day period). Thus, for purposes of constructing the back trace window, a “claim” is a card for which a fraudulent transaction is reported, and a “claim date” is the day that the fraudulent transaction is reported. The data in the window also reflects the total number of cards having reported fraudulent transaction (claims) reported that same day (on the claim date), if those cards were used at that same merchant at any time during the back trace window. The data in the window may further reflect, for purposes of calculating a risk score for a given merchant, a value representing the minimum or lowest number of different merchants at which any of those cards (with fraudulent transactions) have been used (such value referred to as a Minimum Exposed Risk Card or MERC value). As will be fully explained later, a smaller MERC value reflects a smaller number of merchants where a breach may have occurred, and thus a merchant involved in claims giving rise to a smaller MERC value (such as the merchant for which the back trace window was created) has a higher risk of being the source of the breach.

In one described embodiment, a suspect merchant may be identified when there is a single day spike in claims against cards used at the same merchant. Further, a suspect merchant may additionally be identified based on a calculated risk score for that merchant (where the MERC score is used to calculate the risk score).

A compromise period of time (reflecting a likely period of time during which the compromise or hacking has occurred) may be defined by a compromise start date and a compromise end date. The compromise start date can be based on a period of time prior to the first reporting of the compromise, during which a predetermined large majority of the cards having fraudulent transactions (claims) can be back traced to the merchant. In one embodiment, the predetermined large majority of claims for determining the compromise start date is 90%. Thus, on the first reporting date (the date when a compromise is first determined and reported to an issuer), 90% of the claims back traced to the identified merchant are determined to have occurred from a given start date to the first reporting date. That given start date will be the compromise start date. A compromise end date can be viewed as ongoing (not yet established), unless a predetermined large majority (say, 95%) of claims back traced to the identified merchant occurred more than 15 days prior to a given end date, in which case that given end date is the compromise end date. As should be appreciated, the just-stated exemplary values for determining compromise start and end dates (i.e., percentages and number of day prior to a given end date) can be changed in the design of the system to provide wider or narrower compromise periods based on the desires of the affected issuer and/or merchant.

While described embodiments refer to identifying suspect merchants and providing merchant risk scores in connection with fraudulent credit/debit card transactions, it should be appreciated that the invention has application to transactions involving other types of accounts as well, such as (but not limited to) checking accounts, savings accounts, stored value accounts, gift card accounts, and loyalty accounts. Further, while the described embodiments also refer to account data breaches occurring at merchant systems storing customer data, it should likewise be appreciated that other types of breaches are contemplated, such as breaches of devices (e.g., by skimmers attached at ATMs and point-of-sale devices), as well as other data systems that collect and/or store various kinds of account or personal information for any type of business or entity, such as (but not limited to) banks and other financial institutions, health insurance companies, hospitals, utility companies, charitable organizations, and government agencies.

One embodiment for implementing the present invention is shown in FIG. 1, where a plurality of financial institutions (FIs) having transaction systems 110a-110n, are connected for providing transaction data, by way of a data aggregating/standardizing system 114, to a central transaction data management system 120. The financial institutions maintaining the systems 110a-110n may receive transaction data from acquirers or other transaction processing systems that process credit card and debit card transactions from various merchants (not shown). In some cases, the transaction data may be provided to the transaction data management system on behalf of the financial institution by acquirers and transaction processing systems/entities.

In the embodiment illustrated in FIG. 1, the financial institutions have collected transaction data (representing specific transactions conducted against accounts maintained at each financial institution) as part of authorizing and posting a transaction to the account against which it is conducted. The transaction data may include, for example, a transaction ID, an account number, merchant ID, transaction date, a transaction amount and other related transaction data, and may be provided periodically (e.g., in batched form) to the aggregating system 114 and in turn to transaction data management system 120. The transaction data management system 120 has an associated database or data store system 122 that stores the transaction data, with such data then accessed and analyzed in a manner to be described shortly in order to identify merchant or retailer systems that may have been compromised, such as by a malicious software program installed in one of the retailer systems.

Also seen in FIG. 1 is a fraud reporting system 130, which may represent one or more systems maintained by various institutions for reporting fraudulent or likely-fraudulent transactions. The fraud reporting system may be resident at one of the financial institutions operating the systems 110a-110n, or resident at a different financial institution. In some cases, the fraud reporting system may be operated by a third party, such as an acquirer or transaction processing entity, on behalf of a financial institution. When a fraudulent transaction is reported by the system 130, the transaction is identified and reported to a merchant risk system 140. As will be more fully described later, a reported fraudulent transaction may be analyzed in conjunction with other transactions stored at transaction data management system 120/database system 122 by the merchant risk system 140. The merchant risk system 140 may identify suspect merchants, and then provide the identified suspect merchants and, in some embodiments, other risk data (such as merchant risk scores and account risk scores) to a card issuer (financial institution) that maintains any account that is believed to have been compromised (such as, but not necessarily, one of the financial institutions operating the transaction systems 110a-110n).

Turning now to FIG. 2, an overall process is illustrated for identifying a merchant whose systems may have been breached/compromised and providing the identified merchant and a risk score for that merchant (and an account risk score associated with each account that may been compromised) to an affected financial institution.

Initially in this process, transaction data from multiple financial institutions (such as data from transaction systems 110a-110n) is provided from the financial institutions to the data aggregating/standardizing system 114, step 202. In disclosed embodiments, this data is received on an ongoing basis (e.g., daily, in batched form) so that transaction data can be evaluated continuously and information associated with suspect merchants and at-risk accounts frequently updated and provided to financial institutions for monitoring. The system 114 receives the data from the various financial institutions and, at step 204, standardizes the data records and stores them at the transaction data management system 120. The data records are standardized by making the data fields uniform in location and size, and by normalizing the variables in each data field so that they can be conveniently and efficiently accessed and analyzed, even though coming from different financial systems having different data systems and file formats. A more detailed description of the processes performed within the aggregating/standardizing system 114 will be provided later.

Fraud reports (e.g., from fraud reporting system 130) are likewise received on an ongoing basis at step 206 and are used, in a manner to be described shortly, to initiate steps for identifying merchants who are suspected as having had their systems and data compromised. Fraud reports identify specific transactions that are (or likely to be) fraudulent or unauthorized. The transactions may be identified by transaction ID or other identifying data, such as account ID, merchant ID, transaction date and transaction amount associated with a suspected transaction.

At step 208, the merchant risk system 140 evaluates reported fraudulent transactions received at step 204 and determines whether the level of fraudulent transactions has reached an initial threshold before proceeding further. This can be accomplished in a number of ways, such as by monitoring the overall number of fraudulent transactions each day. As examples only, the threshold can be based on the total number of fraudulent transactions reported each day, the total number of fraudulent transactions reported against any one issuer each day, or the total number of fraudulent transactions made against any one account each day. If the threshold has been reached at step 208, then merchant risk system 140 identifies suspected merchants and calculates a risk score for the suspected merchants (based on the fraudulent transactions reported for cards used at those merchants), step 210. As will be described in greater detail later, the merchant risk system 140 may, in some embodiments, identify multiple merchants and their corresponding risk scores (merchant risk data) so that a card issuer (financial institution) can periodically evaluate the merchant risk data, for example, on a daily basis, to observe trends in the merchant data. By receiving, when necessary, identification of multiple merchants (and, in some cases, merchant risk scores), the card issuer is in a better position to act on suspected data early on, when initial analysis may involve ambiguous or uncertain data (arising, for example, because of the way that stolen account data may be packaged and used by fraudsters, as described earlier). Thus, a card issuer receiving risk data may begin steps to notify a specific merchant that it may have been breached (and begin to carefully scrutinize transactions conducted against at-risk accounts affected by the breach) when it observes that a specific merchant risk score begins to increase over a period of time. At step 212, the risk system 140 also identifies a suspected time period during which a potential breach at the merchant may have occurred.

Identifying a possible compromise period of time can be based on the dates that cards having fraudulent transactions can be identified (through back tracing) as having been used at a suspect merchant. In one embodiment (briefly mentioned earlier), the merchant risk system 140 may calculate a likely compromise start date and a likely compromise end date, each based on the period during which the vast majority of those cards having fraudulent transactions (claims) that are back traced to the suspect merchant have been identified. For example, after the dates of all claims have been identified through back tracing and a suspect merchant has been initially identified/reported as suspect at step 210, a likely compromise start date may be a given start date in the back trace window from which 90% of the claims occurred, i.e., have occurred during a period from the given start date to the date the merchant is initially identified. The likely compromise end date is only determined if 95% of the claims back traced to the identified merchant have occurred more than 15 days prior to a given end date in the back trace window, in which case that given end date is the compromise end date. Should large numbers of fraudulent transactions continue during the 15 days prior to the end date of any back trace widow, the breach will be determined as still ongoing (without a current end date). A specific example of an on-going suspected breach having a compromise start date will be provided later in connection with FIG. 4. In described embodiments, once a compromise start date is determined/established for the merchant, it may be subsequently determined to be earlier based on subsequently received back tracing data, but will not be made later than the established compromise start date. A compromise end date may change as additional claims are identified in subsequent back tracing data for the merchant.

At step 214, the system 140 identifies at-risk accounts that have been used at a suspected merchant. This can be done by evaluating any card accounts that were used at the suspect merchant during a period of time when a breach may have occurred. As will be more fully described later, each at-risk account may also be separately evaluated at step 214 for an account risk score, based on various factors to be described later.

At step 220, suspected merchants and merchant risk scores (for at least some of the suspected merchants) are provided to a card issuer. It should be noted that one important feature of the invention is that the card issuer receiving risk scores at step 220 may or may not be the financial institution that maintains an account whose data may have been breached. This is done, for example, because breached data may be used by fraudsters in sophisticated ways to conceal the breach, such as by using (at least initially) only account data pertaining to specific card issuers or types of cards. As a result, initial fraud reports and risk scores may not reflect the entire scope of the breach (e.g., an issuer may be at risk, but its accounts have not yet been used for fraudulent transactions) and, as noted earlier, as identified merchants and risk scores are adjusted and change over time, a card issuer can decide to act on a suspected breach as the risk data and risk scores evolve and reach a threshold that the issuer finds as indicating a likely data compromise/breach.

At step 222, the risk system 140 provides a list of at-risk accounts and corresponding account risk scores that may have been previously generated at step 214. As illustrated in FIG. 2, the process then returns to step 210, reflecting that the illustrated process is performed continuously, e.g., on a daily basis, and that the data provided at step 220 (suspect merchants and scores) and at step 222 (at-risk accounts and scores) is updated and reported to financial institutions and as new suspected merchants are identified (or previously identified merchant drop off), and as risk scores change.

Turning now to FIG. 3, a process is illustrated for identifying suspect merchants and providing merchant risk scores. At step 310, the merchant risk system 140 collects and develops risk data for a back trace window, in response to receiving fraud reports at an initial threshold level indicating a possible data breach (step 208, FIG. 2). An example of data collected for a back trace window is illustrated in FIG. 4 and includes, for a single merchant (as identified by one merchant ID), each fraudulent transaction against a card where that card has been back traced to (previously used at) the merchant. In this embodiment, the data is collected for a window encompassing all transactions over a period of 180 days prior to the first day of data evaluation. The data seen in FIG. 4 relates to only one merchant where a card having a fraudulent transaction has been used, and there would be similar data for each other merchant where the same card having a fraudulent transaction has been used.

In the specific back tracing example seen in FIG. 4, for a single merchant (Merchant ID “8788430112639”), back traced fraudulent activity has begun on “Day 1” and on that date (12/4/2013) there has been a reported claim (a card having a reported fraudulent transaction, where that same card has been used at the identified merchant within the preceding 180 day window). The number of claims reported on Day 1 is “2,” i.e., there are two different cards having reported fraudulent transactions on the claim date (12/4/2013) which were used at that single merchant during the preceding 180 day window. For those two cards, the card used at the smallest number of merchants during the 180 day window was used at 66 merchants (thus providing a MERC value of 66). As illustrated, once the back tracing of data has begun (step 310 in FIG. 3), the back tracing continues every day thereafter. In FIG. 4, each of Day 2 through Day 19 has no reported claims, and thus no claim data for those days is shown in the back tracing window. At “Day 20” (12/23/2013), a claim is reported, the total number of claims that day is “1,” and the MERC score (for that one card) is 58. The data illustrated in FIG. 4 is illustrated through Day 84 (2/26/2014), although the actual back tracing of data may continue thereafter (back tracing would typically continue until a breach has been confirmed, or it is determined that the merchant in question is no longer suspect).

Returning to FIG. 3, the merchants that are reflected in all of the back trace windows (FIG. 4 representing only one such window for one merchant) are then evaluated to identify commonalities in the merchants, step 312. This is done because the merchant ID used in a back trace window may represent a single merchant location that is part of a larger merchant entity. A breach may have occurred at a system at the single merchant location or at a system operated by the larger merchant entity (the latter may result in transactions that can be back traced to multiple merchant locations operated by the larger merchant entity). The merchant risk system 140 will evaluate both single merchant locations and any identified larger merchant entity to determine whether a breach may have occurred at a single merchant location or at a system operated by the larger merchant entity.

As an example, at step 312, commonalities may be recognized by looking at the merchant names associated with merchant IDs (merchant names for multiple merchant IDs may all have a common name or name component, reflecting that they are part of a larger merchant entity). Other data may also be evaluated, such as evaluating common MCCs (merchant classification codes), common acquirers, and common terms in company descriptions (e.g., “pizza” merchants). Alternatively, the merchant risk system may maintain a table of related entities that associates multiple merchant IDs that have been assigned to entities within one larger merchant entity. The table could be developed in advance, e.g., based on common names, MCCs, common acquirers and other factors just discussed. At step 314, merchant IDs that are found to likely be part of a larger merchant entity are combined, so that when back trace window data is subsequently evaluated to identify suspect merchants, it may be evaluated both at a single merchant location level (associated with one merchant ID) and at a larger merchant entity level (associated with combined merchant IDs, where all the back traced data is combined and evaluated together for the larger entity). It should be appreciated that in some cases a single merchant ID may have been assigned to a corporate or larger merchant entity, and that evaluation of that single merchant ID may encompass all transactions performed across all locations of that larger merchant entity.

At step 320, each back trace window is evaluated for spikes in claim activity or for calculation of merchant risk scores (or both), in order to identify a merchant that has had a potential system breach.

A process by which back trace window data is evaluated (including the recognition of “spikes” in claims) will be described in greater detail later in conjunction with FIG. 5. Briefly, referring to the specific back trace example seen in FIG. 4, the risk system 140 is designed to identify a spike in cards having fraudulent transactions (claims) on one date and that can all be back traced to one merchant. In one exemplary embodiment, the spike may be defined by the number of claims on a claim date that meets both of the following requirements:

• • (1) the number of claims is greater than 10 (CLAIMS>10)
  • and
  • (2) the number of claims is greater than the sum of 3 times σ and Avg (CLAIMS>(3σ+Avg)),
  • where “σ” is the standard deviation of claims for all merchants over the previous 30 days and “Avg” is the average daily number of claims for all merchants over the previous 30 days.

In the back trace window example in FIG. 4, the claim activity associated with back tracing Day 79 (referenced by arrow 410) represents a spike in claim activity that meets the above two requirements, and represents the initial date that a merchant is identified (reported to a card issuer) as suspect.

Simultaneously, and as will be further described in connection with FIG. 5 below, each merchant's back trace window is evaluated for a predetermined number of accumulated claims (e.g., 15 or more claims over the previous 30 days) and if there is such number of accumulated claims, a risk score for each such merchant is also calculated at step 320. In the example seen in FIG. 4, the merchant scores would be calculated for the identified merchant beginning on Day 80 (and continuing daily thereafter until the breach is confirmed, or the merchant is no longer suspect).

Finally, for any day where a spike in claim activity is determined or a merchant risk score is calculated (above a threshold value), the merchant associated with that spike or risk score is reported to a card issuer or financial institution, step 322. As will be described shortly, the reports to a card issuer may relate to multiple merchants that each have experienced a spike in claims or have a reportable risk score.

As mentioned earlier, the likely period of compromise may also be provided to the card issuer at step 322. Referring to the specific back tracing example of FIG. 4, in one embodiment described earlier, the start date of the compromise period would be Day 37 and the compromise is ongoing (no specific end date). Day 37 represent the date from which 90% of the claims have been reported up to the first date of suspect merchant identification (Day 79). The compromise is determined to be ongoing since significant numbers of claims continue to be reported (e.g., between the period from the start date to the date of reporting/identification—Day 79, 95% of claims back traced to the identified merchant have not occurred more than 15 days prior to Day 79).

Turning now to FIG. 5, a more detailed process is illustrated for identifying a merchant as suspect (and providing risk scores associated with at least some suspect merchants). At step 510, the daily back traced data for each merchant is accessed (such as the data represented during any one of the back traced days seen in FIG. 4). In the presently described embodiment, there are two methods for identifying suspect merchants as a result of accessing data at step 510, one method illustrated generally on the left side of FIG. 5 (steps 520-526) and the other method illustrated generally on the right side of FIG. 5 (steps 530-534). As to the method illustrated on the left-hand side of FIG. 5, the merchant risk system 140 first determines if the number of claims on the back tracing day is greater than 10, step 520. If it is not, then the process returns to step 510 and waits until the next day to again access back traced data (e.g., data collected over a 180 day period preceding that next day). As should be appreciated from FIG. 4, the return to step 510 (if there are not greater than 10 claims at step 520) is repeated each day. For the specific merchant whose data is illustrated in FIG. 4, at Day 79 (2/21/2014) there are now claims greater than 10, and at that time the process would continue to step 522.

At step 522, the merchant risk system 140 determines whether the number of claims is greater than the sum of three times the standard deviation (for daily claims over the previous 30 days for all merchants) and the daily average of claims (over the previous 30 days for all merchants). If the number of claims on a given date is less than or equal to the sum represented at step 522, then the process returns to step 510. On the other hand, if the number of claims on a given date is greater than the sum represented at step 522, then a spike in claims is determined to be present for that day. Thus, the following formula (briefly mentioned in conjunction with FIG. 3) is used at step 522:

CLAIMS>(3σ+Avg)

In the example seen in FIG. 4, on Day 79 the following values are present:

• • Avg=3 (the average daily number of claims for all merchants for which back trace data has been collected and then accessed at step 510).
  • σ=1.5 (the standard deviation is well known statistical computation based on a given population and is usually computed as the square root of the variation of the population from the mean or average). In this example, a standard deviation of 1.5 means that most merchants over the previous 30 days will have total claims within 1.5 of the mean or average of 3 daily claims).

Thus, the number of claims 47) for the identified merchant (FIG. 4) for Day 79 is greater than 3×1.5+3 or 7.5, and a spike in claims for that merchant is determined to exist and the merchant is identified as a suspect merchant at step 524. Steps 510 through 524 are determined across all merchants having back trace data windows, and all of those merchants are ranked (as will be described shortly).

A ranking of merchants is performed at step 526. In one embodiment, the ranking is done with use of a “Z-score.” A Z-score is particularly useful way of measuring the risk associated with aggregated data, such as fraudulent transactions. In particular, a Z-score is a statistical measure of how much a value is above or below a mean or average in a given population (more specifically, how many standard deviations the value is above or below the mean). A Z-score is calculated using the following formula:

$Z=\frac{-\mu }{\sigma }$

where χ is the value to be standardized (the number of claims on the date in question for a given merchant),

where μ is the mean of the population (e.g., the average number of claims for all merchants on the given date, considering data collected over the previous 30 days), and

where σ is the standard deviation of the claims for all merchants on the given date (e.g., considering data collected over the previous 30 days).

In the particular example just given for Day 79 (FIG. 4), there have been 47 reported claims (χ), the mean (μ) for reported fraud complaints for all merchants is 3, and the standard deviation (σ) for all merchants is 1.5.

Thus, for this example, the Z-score for fraud complaints for the given merchant using the formula is:

$Z=\frac{47-3}{1.5}=29.33$

Thus, on Day 79, the merchant in question has a Z-score of 29.33 and such score is used in conjunction with the risk scores of other merchants on that day (that have claim spikes) to rank those merchants at step 526 (i.e., from highest Z-score to lowest Z-score).

Separately from the Z-score, a merchant risk score (reflecting the risk that a merchant has been compromised, as will be described later in conjunction with FIG. 6) may be calculated for each of the suspect merchants ranked at step 526.

Referring now to the method illustrated on the right-hand side of FIG. 5, and at about the same time as steps 520-526 are performed, the merchant risk system 140 first determines (step 530), for each merchant, whether the number of claims reported for that merchant over the previous 30 days is greater than 15. If not, the process returns to step 510 and waits until the next day to access the back traced data. If the number of claims in the previous 30 days is greater than 15 at step 530, then a merchant risk score calculated at step 532. The merchant risk score is calculated in accordance with the formula to be described below in conjunction with FIG. 6. After the merchant risk score is calculated, those merchants having the highest risk scores are identified at step 534. In one embodiment, of all merchants for whom merchant risk scores are calculated, those merchants having the 200 highest merchant risk scores are identified at step 534.

At step 540 the ranked merchants at step 526 and the highest scoring merchants at step 532 are provided to a card issuer as suspect. In some embodiments, the risk score for each of the merchants identified at step 534 is also provided to the card issuer.

Turning now to FIG. 6, there is illustrated a process for determining a merchant risk score, such as the merchant risk score referenced at step 532 in FIG. 5. At step 610, the daily back traced data for each merchant that is accessed by the merchant risk system 140 (step 510, FIG. 5) is evaluated. The merchant risk system 140 determines the number of claims for that merchant during the previous 30 days, step 622 (such determined number is identified as value “A”). Next, at step 624 the merchant risk system 140 determines the total number of cards (all cards used to develop the data in the back trace window) that have no fraudulent transactions during the 180 day back trace window (such determined number is identified as value “B”).

At step 630 the merchant risk system determines the MERC value for the merchant on that day and at step 632 the merchant risk score R is calculated using the following formula:

$R=\frac{A}{B\times \mathrm{MERC}}$

For convenience, the risk score R can be converted or “normalized” to a useful range , say, 0-1000, where “0” represents no risk and “1000” represents the highest possible risk.

It should be appreciated, as seen in the above formula, that the merchant risk score R for any merchant will increase on any given day as the MERC value decreases. As mentioned earlier, this is due to an enhanced risk for a merchant when any card back traced to that merchant has been used at a relatively small number other merchants. Thus, for example, if a card has been used at very few other merchants, it is more likely that the breach occurred at the merchant in question. If the card has been used at many other merchants, then the probability of the breach having occurred at the merchant in question is less likely.

As mentioned earlier in conjunction with FIG. 2, in some embodiments a card issuer that receives reports on suspect merchants and merchant risk scores might also receive risk scores associated with specific accounts that appear to have been compromised (accounts used for transactions at the suspect merchant during the compromise period). This can be accomplished in a number of different ways using different factors, as described below.

Fraudster Website—Websites are monitored where stolen card numbers are sold to third parties (for subsequent use in conducting fraudulent transactions). When stolen card numbers appear for sale, and then are removed, such card numbers removed are likely to be used shortly thereafter and are deemed to be at higher risk.

Type of Card—As mentioned earlier, certain types of cards have higher value for fraudulent transactions and are thus deemed to be at higher risk (e.g., a debit card has lower risk, a standard credit card has higher risk, and a premium credit card has highest risk; credit cards with higher credit limits have greater risk than credit cards with lower credit limits)

Past experience with issuer's cards—some card issuers identify fraudulent transactions more slowly than others, and cards issued by such issuers are at a higher risk.

ZIP Code of the merchant location—The ZIP code of the merchant location where the stolen card was used (for fraudulent transactions) can have a bearing on risk. For example, third parties purchasing stolen card data may be known to operate in certain areas, and cards typically used by a cardholder in those areas may be at higher risk (among other things, a card issuer is less likely to spot a fraudulent transaction in a location where a cardholder regularly uses the card, and is more likely to spot a fraudulent transaction in an area distant from where the cardholder regularly uses the card). Further, when a fraudster is known to operate in a certain area, and a card has been stolen that is regularly used by the legitimate cardholder in that area, such a card is deemed to be at a higher risk.

The merchant risk system 140 may assign a numerical value to each of the above risk factors (and others). Different risk factors may be weighted differently, depending on the experiences or desires of a card issuer or the entity operating the merchant risk system 140. The risk factors are combined to develop a normalized overall risk score (say, from 0 to 1000) for each card/account number. Such overall risk score for each compromised account is sent to the card issuer (e.g., at step 222, FIG. 2)

Turning now to FIGS. 7a and 7b, there is illustrated an exemplary report that could be sent to a financial institution/issuer identifying a suspected/possible breach of a merchant system, e.g., provided pursuant to steps 220 and 222 in FIG. 2. The suspected breach or compromise is referred to in the illustrated report as an “incident.” In the exemplary report of FIGS. 7a and 7b, a single merchant is identified. As noted earlier, in some cases there may be multiple merchants identified as each having a possible data breach, and in those cases each merchant would be the subject of a report.

The illustrated report has five principal report components, identified as Overall Incident Data, Specific Issuer Data, Merchant Data, PAN Data and Fraud Location Data. Each report component has various illustrated fields, with exemplary data shown in FIGS. 7a and 7b for those illustrated fields.

The Overall Incident Data component of the incident report includes an Incident ID (a unique identifier for the suspected compromise), a Score (reflecting the likelihood that the particular merchant has had a breach at its system), an Incident Window (the suspected time period or window during which a potential breach may have occurred—identified, e.g., at step 212), a Number of Issuers Impacted (in the illustrated report, two issuers have card accounts that may have been impacted/compromised at a merchant system during the incident window), a Number of PANs At Risk (the number of accounts represented by a primary account numbers that were used for transactions at the implicated merchant during the incident window), a Number of PANs with Reported Fraud (of the total number of accounts or PANs at risk, the number of those accounts where fraud has actually been reported, e.g., step 206), and an Overall Fraud Rate. The Overall Fraud Rate provides to the issuer a easily referenced percentage indicator of the number of PANs at risk that have actually had fraud reported, illustrated as 4.9%, reflecting the number of PANs having reported fraud (2,550) as a percentage of the total number of PANs at risk (52,210).

The Specific Issuer Data component of the report has data pertinent to the specific issuer to whom the report is being provided, and includes the Number of Issuer PANs At Risk (the number of accounts of this issuer that are at risk—illustrated as 30,900 PANs out of the 52,210 total PANs at risk in the Overall Incident Data), a Number of Issuer PANs with Reported Fraud (illustrated as 200 at-risk accounts of this issuer that have had actual fraud reported, e.g., at step 206), a Total Amount of Issuer Transactions During Window (illustrated as $6,000,000, reflecting the total amount of transactions for the at-risk accounts of that issuer during the incident window), a Total Amount of Issuer Transactions Reported As Fraud (illustrated as $30,000, reflecting the total amount of fraudulent transactions for the 200 accounts with reported fraud), and an Issuer Fraud Rate. The Issuer Fraud Rate provides the issuer an easily referenced indicator of the number of at-risk accounts of that issuer that have had actual fraud reported as a percentage the number of at-risk accounts of the issuer. The Issuer Fraud Rate illustrated in the incident report is 0.6%, reflecting very little fraud against the at-risk accounts. However, the Overall Fraud Rate (4.9% in the illustrated report) is much higher, and most likely indicates that another issuer has had more of its accounts compromised and sold by fraudsters. While the issuer receiving the illustrated report might not otherwise be concerned with its own low fraud rate (i.e., the 0.6% illustrated as the Issuer Fraud Rate), the higher Overall Fraud Rate (4.9%) may indicate that this specific issuer may expect more fraud in the future, as its accounts are sold by fraudsters, and permits the issuer to act on the fraud much more quickly than it would if it were receiving reports based only on transaction and fraud data for its own accounts.

The Merchant Data component of the report has data pertinent to the specific merchant that has been identified as having had a possible system compromise or data breach, and includes Merchant Information (as illustrated, the name, city, state, ZIP Code and country code of the identified merchant), a Merchant Category Code (a number/code used by credit card companies and transaction processors to identify the primary category of goods or services offered by a merchant), a Merchant ID (sometimes referred to as a Merchant Identification Number, consisting of a unique identifying number assigned by credit card companies and transaction processors in order to identify a merchant), an Acquirer ID (consisting of a unique identifying number assigned to the acquirer/payment processor for the merchant), and a Terminal ID (a unique number identifying a specific one or more merchant terminals where a breach is suspected). It should be noted that the Acquirer ID may be useful when multiple merchants appear to have a suspected breach, and where such merchants have a common acquirer, permitting the common acquirer to be identified and evaluated to make sure that the breach is at the identified merchants rather than at the common acquirer. The Terminal ID is particularly useful identifying a specific merchant terminal (as opposed to a central merchant system) that may be the source of a breach, such as when the breach is the result of a skimmer that has been attached to a particular terminal and where transaction data used in back tracing data (e.g., FIG. 4) to find the source of the breach points to a specific terminal as having given rise to the breach.

The PAN Data component of the report identifies specific PANs of the issuer involved in the suspected data breach and that have had fraud reported. While only three PANs are illustrated, it should be appreciated that there will likely be many such PANs identified (e.g., for the exemplary report, since 200 PANs of the issuer have been identified as having fraud in the Specific Issuer Data, those 200 PANs would be identified in the PAN Data component). The PAN Data report further includes, for each identified PAN, an indication (Y/N) of whether the PAN has been previously identified in an earlier version of the incident report, thus conveniently giving the issuer an indication of whether it may have or should have previously acted on the fraud (such as by closing the identified account). The PAN Data Report also includes an Account Score that provides the degree of risk associated with the specific PAN (e.g., calculated at step 214). Also, it should be appreciated that if the issuer receiving the report has no fraudulent transactions reported against its accounts (i.e., the fraud involves only accounts of other issuers), no PANs (or account scores) would be seen in the report

Finally, the Fraud Location Data component of the report includes information on the geographical location(s) that have had reported fraud (attributable to the suspected breach). Generally, for stolen credit card data, the reported fraud will often be clustered geographically due to multiple/repeated use of the stolen card information (until the fraud is uncovered and a card account is closed). The issuer will be given information on each such geographical location, such as the city, the state, ZIP Code, the country code, the merchant category code (MCC) of the merchants where the fraudulent transactions have been reported (although not shown, there may be multiple MCC's at each geographical location), the percentage of fraudulent card-present transactions at that geographical location, the percentage of fraudulent transactions where an authenticating PIN was used (reflecting breach of PINs as well as associated card information), the highest amount of the fraudulent transactions at each location, the lowest amount of the fraudulent transactions at each location, and the average amount of fraudulent transactions at each geographical location.

It should be noted that the Incident ID is particularly useful in reporting a potential data breach to an issuer. The Incident ID uniquely identifies the potential data breach (incident) associated with a merchant and continues to identify the same incident as it is or may be periodically updated at the merchant risk system 140. While not seen in FIGS. 7a and 7b, the particular data fields may be augmented as more transaction data is evaluated and the circumstances (and scoring) of a potential breach develop over time. For example, while the Incident ID may remain the same, the Score, Incident Window, Number of Issuers and other data reflected in the each updated report may change, for example, reflecting an increasing (or decreasing) risk over time. This could be done by providing the original variables in the initial incident report, but with each updated report showing additional values resulting from additional transaction data. Thus a updated subsequent incident report could, for example, include the original merchant Score (850 in the illustrated report) and then, say, immediately below the original Score, the updated score (for example, highlighted or in a different color) so that the issuer receiving the report could see how the value for the Score (or any other variable in the report) has changed since the last report. As should be apparent, an increasing merchant risk Score (e.g., over several updated reports) reflecting greater risk that the merchant/subject of the report has been breached might prompt greater urgency in addressing the suspected breach. A decreasing score (especially if substantially decreasing) might indicate less urgency is needed. Changes in other variables (compared to the values for the same variables in earlier reports) might also dictate changes in urgency or the scope of remedial actions. As one example, when the number of issuers impacted by fraudulent transactions increases or the number of fraud locations increases (particularly if the increase is sudden or dramatic), the issuer receiving report might conclude that stolen card data is now being more widely sold and that it can expect future fraudulent transactions to increase (particularly if that issuer has not yet experienced significant fraudulent transactions in connection with the suspected breach). In such case, the issuer may provide alerts to merchants that are perceived as being more likely to see such fraudulent transaction activity.

As mentioned earlier, embodiments of the present invention rely on data from many financial institutions rather than just one or a few for purposes of determining a common point-of-purchase merchant and the potential risk to the issuer. While systems have previously been made available to standardize data formats for purposes of processing the data, in present embodiments the standardization may require a more rigorous process because of the complexity and volume of data involved and the potential financial risk (e.g., to issuers) if a data breach is not identified early on when receiving reports of fraudulent transactions. Accordingly, the standardization of data records received from a plurality of financial institutions (e.g., step 204 in FIG. 2) may involve receiving not only the raw transaction data from each of the various financial institutions, but also a file layout defining the structure of the transaction data contributed by each financial institution. The data aggregating/standardizing system 114 uses the file layout to parse the raw transaction data and provide two outputs, including a parsed, standardized format for the data as well as summary of statistics relating to each field of the contributed data. The parsed, standardized data permits the merchant risk system 140 evaluate similar data fields of each contributed data record in order to generate risk data (such as that illustrated in FIGS. 7a and 7b). The standardization is done once up front as data is received at system 114 and is stored at and thereafter accessed from the system 120 as needed, in the standardized format. As an example, data fields from different financial institutions may have different file delimiters that separate the data fields (commas, tabs, brackets, etc.) or use fixed field width/lengths. In one embodiment, all the data fields could be converted from the various different delimiters to fixed width and re-arranged so that the same data appears in the same order in each record.

The summary statistics are used to evaluate the characteristics of each field as the data is parsed and standardized, and to identify anomalies in the data. As examples only, data fields may have transaction amounts, account numbers and dates having a certain number of digits or values within certain ranges. The digits or values can be compared to historical averages or statistical measures such as minimums, maximums or calculated standard deviations. As new data is contributed, if the contributed data deviates significantly from past averages or statistical measures, the issuer can be alerted that data being provided may not be correct. Corrections can be made and corrected up front before the data is stored for processing at the transaction data management system 120.

It should also be noted that the aggregation of transaction data from a plurality of financial institutions may itself present some issues from having all that data collected in one location, and making such data is secure. In order to address security, especially as to account numbers, account numbers can be encrypted using a hashing algorithm when stored at the transaction data management system 120, so that each transaction data record is stored with an encrypted account number rather than the real account number. The encrypted account numbers would be meaningless to anyone accessing the system 120, but would be used to uniquely identify an account when analyzing the data for purposes of determining a common point-of-purchase. There may be located separately a secure system (not shown in FIG. 1) that has functionality to translate the encrypted information back into a format recognized by the issuer when it is returned in a report to the issuer (such as the recognized primary account number in the PAN Data component of the incident report seen in FIGS. 7a and 7b).

FIG. 8 is a block diagram illustrating an exemplary computer system upon which embodiments of the present invention may be implemented. This example illustrates a computer system 800 such as may be used, in whole, in part, or with various modifications, to provide the functions of the data aggregating system 114, the transaction data management system 120, and the merchant risk system 140, as well as other components and functions of the invention described herein.

The computer system 800 is shown comprising hardware elements that can be electrically coupled or otherwise in communication via a bus 805. The hardware elements can include one or more processors 810, including, without limitation, one or more general-purpose processors and/or one or more special-purpose processors (such as digital signal processing chips, graphics acceleration chips, and/or the like); one or more input devices 815, which can include, without limitation, a mouse, a keyboard and/or the like; and one or more output devices 820, which can include, without limitation, a display device, a printer and/or the like.

The computer system 800 may further include one or more storage devices 825, which can comprise, without limitation, local and/or network accessible storage or memory systems having computer or machine readable media. Common forms of physical and/or tangible computer readable media include, as examples, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, an optical medium (such as CD-ROM), a random access memory (RAM), a read only memory (ROM) which can be programmable or flash-updateable or the like, and any other memory chip, cartridge, or medium from which a computer can read data, instructions and/or code. In many embodiments, the computer system 800 will further comprise a working memory 830, which could include (but is not limited to) a RAM or ROM device, as described above.

The computer system 800 also may further include a communications subsystem 835, such as (without limitation) a modem, a network card (wireless or wired), an infra-red communication device, or a wireless communication device and/or chipset, such as a Bluetooth® device, an 802.11 device, a WiFi device, a WiMax device, a near field communications (NFC) device, cellular communication facilities, etc. The communications subsystem 835 may permit data to be exchanged with a network, and/or any other devices described herein. Transmission media used by communications subsystem 835 (and the bus 805) may include copper wire, coaxial cables and fiber optics. Hence, transmission media can also take the form of waves (including, without limitation radio, acoustic and/or light waves, such as those generated during radio-wave and infra-red data communications).

The computer system 800 can also comprise software elements, illustrated within the working memory 830, including an operating system 840 and/or other code, such as one or more application programs 845, which may be designed to implement, as an example, the processes seen in FIGS. 2, 3, 5 and 6, and thus provide specially designed and programmed devices (e.g., the data aggregating system 114, the transaction data management system 120, and the merchant risk system 140) for carrying out the unique elements of those processes and novel features described herein.

As an example, one or more methods discussed earlier might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer). In some cases, a set of these instructions and/or code might be stored on a computer readable storage medium that is part of the system 800, such as the storage device(s) 825. In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium, such as a compact disc, etc.), and/or provided in an installation package with the instructions/code stored thereon. These instructions might take the form of code which is executable by the computer system 800 and/or might take the form of source and/or installable code, which is compiled and/or installed on the computer system 800 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.). The communications subsystem 835 (and/or components thereof) generally will receive the signals (and/or the data, instructions, etc., carried by the signals), and the bus 805 then might carry those signals to the working memory 830, from which the processor(s) 805 retrieves and executes the instructions. The instructions received by the working memory 830 may optionally be stored on storage device 825 either before or after execution by the processor(s) 810.

While various methods and processes described herein may be described with respect to particular structural and/or functional components for ease of description, methods of the invention are not limited to any particular structural and/or functional architecture but instead can be implemented on any suitable hardware, firmware, and/or software configuration. Similarly, while various functionalities are ascribed to certain individual system components, unless the context dictates otherwise, this functionality can be distributed or combined among various other system components in accordance with different embodiments of the invention. As one example, the merchant risk system 140 may be implemented by a single system having one or more storage device and processing elements. As another example, the merchant risk system 140 may be implemented by plural systems, with their respective functions distributed across different systems either in one location or across a plurality of linked locations.

Moreover, while the various flows and processes described herein (e.g., those illustrated in FIGS. 2, 3, 5 and 6) are described in a particular order for ease of description, unless the context dictates otherwise, various procedures may be reordered, added, and/or omitted in accordance with various embodiments of the invention. Moreover, the procedures described with respect to one method or process may be incorporated within other described methods or processes; likewise, system components described according to a particular structural architecture and/or with respect to one system may be organized in alternative structural architectures and/or incorporated within other described systems. Hence, while various embodiments may be described with (or without) certain features for ease of description and to illustrate exemplary features, the various components and/or features described herein with respect to a particular embodiment can be substituted, added, and/or subtracted to provide other embodiments, unless the context dictates otherwise. Consequently, although the invention has been described with respect to exemplary embodiments, it will be appreciated that the invention is intended to cover all modifications and equivalents within the scope of the following claims.

Claims

1. A system for identifying risk associated with accounts compromised at a common point-of-purchase merchant, comprising:

a data aggregating system receiving transaction data from a plurality of financial institutions, and standardizing the transaction data;

a transaction data management system receiving and storing the standardized transaction data from the data aggregating system, for subsequent evaluation in connection fraudulent transactions reported against accounts at the plurality of financial transactions;

a fraud reporting system that identifies fraudulent transactions against at-risk accounts at the plurality of financial institutions; and

a merchant risk system that receives identified fraudulent transactions from the fraud reporting system and, in response to the identified fraudulent transactions received from the fraud reporting system, (1) accesses transaction data stored at the transaction data management system, (2) analyzes the accessed transaction data for transactions conducted against the at-risk accounts over a period of time prior to the identified fraudulent transactions, and (3) provides, to at least one of the financial institutions, risk data relating to a possible compromise of account data for the at-risk accounts, the risk data including: data identifying a merchant where the at-risk accounts were used to conduct a transaction prior to the identified fraudulent transactions; and data relating to fraudulent transactions against accounts at financial institutions other than the at least one financial institution to which the risk data is provided.

2. The system of claim 1, wherein the transaction data received at the data aggregating system identifies transactions conducted at merchants and posted against accounts maintained at each of the plurality of financial institutions.

3. The system of claim 1, wherein the merchant risk system identifies merchants where there has been a spike in fraudulent transactions against the at-risk accounts used at those merchants, and wherein each identified merchant, where there has been a spike in fraudulent transactions, is ranked according to the relative risk that data relating to the at-risk account was compromised at that merchant.

4. The system of claim 1, wherein the merchant risk system calculates a merchant risk score for a merchant where the at-risk accounts used to conduct a transaction prior to the identified fraudulent transactions, and wherein the merchant risk score represents the relative risk that data relating to the at-risk account was compromised at that merchant.

5. The system of claim 4, wherein the merchant risk score is based on a MERC value, the MERC value reflecting the number of merchants where the at-risk account was used to conduct transactions over the period of time prior to the reported fraudulent transactions.

6. The system of claim 1, wherein the period of time prior to the identified fraudulent transactions represents a back trace window of transaction data.

7. The system of claim 6, wherein the period of time prior to the identified fraudulent transactions comprises a 180 day period.

8. The system of claim 1, wherein the analyzed transaction data for transactions conducted against the at-risk accounts over a period of time prior to the identified fraudulent transactions relates to a plurality of merchants, wherein data identifying each of the plurality of merchants is analyzed for common features to identify multiple individual merchants that are part of a larger merchant entity.

9. The system of claim 8, and the merchant risk system analyzes transaction data, for transactions conducted against the at-risk accounts over a period of time prior to the identified fraudulent transactions, separately for both each of the multiple individual merchants and the identified larger merchant entity.

10. The system of claim 8, wherein the common features for which the data identifying the each of the plurality of merchants is analyzed is taken from a group comprising one or more of common name components, common merchant classification codes, common acquirers and common company description terms.

11. The system of claim 1, wherein the risk data further includes an Incident ID uniquely identifying the possible compromise at a merchant.

12. The system of claim 11, wherein the risk data further includes data reflecting a number of financial institutions having at-risk accounts used to conduct a transaction prior to the identified fraudulent transactions.

13. The system of claim 1, wherein the risk data further includes data reflecting a total number of at-risk accounts maintained at the plurality of financial institutions, and data reflecting the number of at-risk accounts at the at least one financial institution to which the risk data is provided.

14. The system of claim 1, wherein the risk data further includes data reflecting a possible period of compromise at the identified merchant, based at least in part on a period of time during which a predetermined large majority of the at-risk accounts have been used at the identified merchant.

15. A method for identifying risk associated with accounts compromised at a common point-of-purchase merchant, comprising:

receiving, at a data aggregating system, transaction data from a plurality of financial institutions;

standardizing the received transaction data at the data aggregating system;

receiving and storing, at a transaction data management system, the standardized transaction data from the data aggregating system, for subsequent evaluation in connection fraudulent transactions reported against accounts at the plurality of financial transactions;

identifying, at a fraud reporting system, fraudulent transactions conducted against at-risk accounts at the plurality of financial institutions; and

receiving, at a merchant risk system, the identified fraudulent transaction from the fraud reporting system;

in response to the identified fraudulent transactions received from the fraud reporting system, (1) accessing, by the merchant risk system, transaction data stored at the transaction data management system, (2) analyzing, by the merchant risk system, the accessed transaction data for transactions conducted against the at-risk accounts over a period of time prior to the identified fraudulent transactions, and (3) providing, by the merchant risk system to at least one of the financial institutions, risk data relating to a possible compromise of account data for the at-risk accounts, the risk data including: data identifying a merchant where the at-risk accounts were used to conduct a transaction prior to the identified fraudulent transactions; and data relating to fraudulent transactions against accounts at financial institutions other than the at least one financial institution to which the risk data is provided.

16. The method of claim 15, wherein the transaction data received at the data aggregating system identifies transactions conducted at merchants and posted against accounts maintained at each of the plurality of financial institutions.

17. The system of claim 15, wherein the merchant risk system identifies merchants where there has been a spike in fraudulent transactions against the at-risk accounts used at those merchants, and wherein each identified merchant, where there has been a spike in fraudulent transactions, is ranked according to the relative risk that data relating to the at-risk account was compromised at that merchant.

18. The method of claim 15, wherein the merchant risk system calculates a merchant risk score for a merchant where the at-risk accounts used to conduct a transaction prior to the identified fraudulent transactions, and wherein the merchant risk score represents the relative risk that data relating to the at-risk account was compromised at that merchant.

19. The method of claim 18, wherein the merchant risk score is based on a MERC value, the MERC value reflecting the number of merchants where the at-risk account was used to conduct transactions over the period of time prior to the reported fraudulent transactions.

20. The method of claim 15, wherein the period of time prior to the identified fraudulent transactions represents a back trace window of transaction data.

21. The method of claim 20, wherein the period of time prior to the identified fraudulent transactions comprises a 180 day period.

22. The method of claim 15, wherein the analyzed transaction data for transactions conducted against the at-risk accounts over a period of time prior to the identified fraudulent transactions relates to a plurality of merchants, wherein data identifying each of the plurality of merchants is analyzed for common features to identify multiple individual merchants that are part of a larger merchant entity.

23. The method of claim 22, and the merchant risk system analyzes transaction data, for transactions conducted against the at-risk accounts over a period of time prior to the identified fraudulent transactions, separately for both each of the multiple individual merchants and the identified larger merchant entity.

24. The method of claim 22, wherein the common features for which the data identifying the each of the plurality of merchants is analyzed is taken from a group comprising one or more of common name components, common merchant classification codes, common acquirers and common company description terms.

25. The method of claim 15, wherein the risk data further includes an Incident ID uniquely identifying the possible compromise at a merchant.

26. The method of claim 25, wherein the risk data further includes data reflecting a number of financial institutions having at-risk accounts used to conduct a transaction prior to the identified fraudulent transactions.

27. The method of claim 15, wherein the risk data further includes data reflecting a total number of at-risk accounts maintained at the plurality of financial institutions, and data reflecting the number of at-risk accounts at the at least one financial institution to which the risk data is provided.

28. The method of claim 15, wherein the risk data further includes data reflecting a possible period of compromise at the identified merchant, based at least in part on a period of time during which a predetermined large majority of the at-risk accounts have been used at the identified merchant.