Patent Application
20160364727
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.
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.
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
In the embodiment illustrated in
Also seen in
Turning now to
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
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
Turning now to
In the specific back tracing example seen in
Returning to
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
In the back trace window example in
Simultaneously, and as will be further described in connection with
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
Turning now to
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
CLAIMS>(3σ+Avg)
In the example seen in
Thus, the number of claims 47) for the identified merchant (
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:
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 (
Thus, for this example, the Z-score for fraud complaints for the given merchant using the formula is:
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
Referring now to the method illustrated on the right-hand side of
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
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:
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
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,
Turning now to
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
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.,
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
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
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
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
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
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.
| Number | Date | Country | |
|---|---|---|---|
| 62174432 | Jun 2015 | US |
