The Data

You can create custom fraud rules through your payment processors and fraud service providers that automatically reject transaction attempts based on defining characteristics. To determine the characteristics most commonly associated with fraud attacks on your business, you need reliable transaction and decline data. In this use case example, we’ll show how you can use Peacock to identify patterns in your transaction decline data and define custom fraud rule characteristics.

Exploring the Data in Peacock

In the Declines dashboard, the Decline Code Transaction Count sub-chart under Decline Code Transactions is a stacked bar chart showing the breakdown by decline code of your total declined transaction count over the selected time period. Using the absolute/distribution switcher, you can view this decline code breakdown as a percentage distribution and identify your typical distribution of declines across codes such as decline_gateway, do_not_honor, expired_card, and more. More importantly, this chart provides you with an explicit visualization of any sudden changes in your decline code distribution that might indicate a problem for your business. Instead of waiting to spot decline issues until after they’ve already impacted your bottom line, you can identify them in near real time by monitoring your Peacock dashboards.

Should you notice a sudden increase in one such decline code, you can then dig further into the data to better understand what might have caused the declines. Use the Transaction Response Code filter option to filter other charts or dashboards in Peacock for only the data associated with transactions that received the problematic decline code; this can help you identify trends among these transactions. For example, filtering the Issuers Dashboard to only show transactions with a transaction response code of not_sufficient_funds could highlight which issuing bank country or BIN sees the most transactions lost to NSF declines.

Drawing Conclusions

To demonstrate the types of conclusions you might draw from the analysis described above, we’ll use hypothetical transaction data:

As a part of your typical payments system health check, you review your Decline Code Transaction Count sub-chart under Decline Code Transactions and notice something out of the ordinary happened last week: the percentage of all declined transactions with the decline code suspected_fraud jumped from a daily average of 10% to 35% last Wednesday. Next, you navigate to the Payment Methods Dashboard and pull up the Payment Method Transaction Count sub-chart under Payment Method Transactions. With this chart, you confirm that you didn’t see a corresponding jump in the overall number of transactions attempted that day. In other words, the overall number of transactions didn’t change much, but the percentage of those transactions identified as suspected fraud jumped. Armed with this information, you can start to dig in further to identify the source of the attempted fraud.

The next place you look in Peacock is the Issuers Dashboard. Using the Transaction Response Code filter, you filter this dashboard to only show data for transactions made in the last week that received the suspected_fraud decline code. The first thing that jumps out at you is the Issuing Country Transaction Count sub-chart under Issuing Country Transactions; this chart shows the number of transactions made in the selected time frame, broken down by the countries where the cards used in those transactions were issued. Given the filter you’ve applied to this dashboard, the chart goes one step further in this instance to show you the issuing country breakdown of cards that were ultimately declined last week due to suspected fraud. You immediately note the number of suspected_fraud transactions last week for cards issued in the US was significantly higher than that for any other issuing country.

Now that you know one specific card-issuing country is to blame for the fraud spike last Wednesday, you can dig even deeper to see if perhaps one or more specific BINs are to blame. To do so, you filter the Issuers Dashboard dashboard to only show suspected_fraud transactions and look specifically at the Top 25 BINs by Transaction Count chart. With the applied filter, this chart shows the BINs (and their issuing bank and country) in descending order of the number of transactions declined as suspected fraud. Suddenly you know exactly what BINs are to blame for the fraud attack last week. Just to double check that these BINs really are to blame, you review the Top Issuing Banks chart and confirm the issuing banks associated with those BINs also experienced a high decline rate.

Armed with this information, you can establish fraud rules with your payment processors and fraud service providers aimed specifically at these BINs. If you also subscribe to Canary, you could even configure triggers to get alerts regarding transactions attempted with these BINs. Regardless, you now have more information than ever before to resolve the issue and prevent it from recurring.