Collusion fraud happens when two or more actors within an ecosystem work together to commit fraud against a merchant or other business. This is a big problem, and it continues to grow. In a recent report from the ACFE (Association of Certified Fraud Examiners), collusion fraud grew 150% in 2017. The report focuses on internal collusion and is defined as: “Fraud also may be concealed through collusion among management, employees, or third parties.” The cost of fraud grows significantly as more actors are involved in the collusion going from an average $74,000 for one perpetrator, to $339,000 with three or more perpetrators, the same report found. Little has been properly documented about collusion fraud in the online world, but it happens, and it happens a lot. Especially now with peer-to-peer digital marketplaces and the shared economy. There are many flavors of collusion, and, in this post we’ll discuss a few examples that we have encountered in our client base.
One of our first experiences was with risk-bearing ISOs. These basically enable merchants to process credit cards. Risk-bearing ISOs are actually far more complicated in their functions – but let’s keep it simple for now. We noticed that there was an unusual volume of transactions that came from cards within the same BIN (Bank Identification Number – basically the first 6 digits of a credit card). These transactions were similar in dollar amount, and were all in a small geolocation radius. All of these were rather unusual, and moreover on a newly onboarded merchant. We found out that the merchant was actually colluding with the supposed cardholders. The money would have been funded into the merchant account, then the cardholders would have charged back the transactions, and the merchant would disappear, leaving the risk-bearing ISO responsible for the bill.
Imagine a digital marketplace with a multitude of buyers and sellers. A very similar scenario to the one above was used. In this scenario, bunch of credit cards were stolen to get cash. They created an account as a seller and listed an item that well call “Purple Dinosaur”. Then they posed as a buyer, and lined up some friends to pose as buyers. They used the stolen credit cards to purchase the non-existant Purple Dinosaurs. The money went into the seller’s account, and later on, the actual cardholders charged back the transactions. Ultimately, it was the marketplace that was on the hook for the charges.
Now, imagine signing up as small merchant to sell cookies. But you let a “friend” use your merchant account to sell “nice spiked brownies”. Your merchant contract doesn’t allow you to sell those brownies, but you let a friend list them on your website on a special page that only the people that know can get to. Then you get paid for lending the payment rails to a friend. While the platform is not incurring into a specific liability at that moment, there is a much more complex risk of being penalized for violation of contracts, money laundering, etc. All of these can damage a business.
Leveraging relationships between buyers and sellers
There are multiple ways to detect these scenarios, but the fundamental one we use is to draw from the relationships between actors. In our platform each of these actors are identities, and the platform tracks the relationships across these identities.
When you are able to characterize the relationships across identities, and they start behaving abnormally, it is easy to spot the problems.
We’ve have been working with marketplaces to deepen our coverage of collusion cases. As part of this effort, we recently release a new set of security tests aimed at addressing fraud, and, in particular, collusion fraud.
Collusion between seller and buyer through common attributes
Security tests: ed:149 through ed:151
First off we created security tests that looked for attribute commonality between the two ends of a transaction. In particular the name of these tests refer to buyers and sellers in a marketplace. From the API perspective the IP, device, billing and shipping addresses refer to the buyer. So there are strong assumptions on the marketplace use case.
Security tests ed:149 – ed:151 only count when the payments were successful, meaning a bank authorized them.
These tests look at any IP address, device, or address (either shipping or billing) that has been shared at any given point in time. So the test looks at the data of the transaction being evaluated (buyer) and look to see whether these attributes have been associated with the other entity (seller). For example if the transaction is a payment between a buyer and a seller (represented as a transfer transaction in the system), then the IP address of the transaction refers to the buyer. The system (ed:137 or ed:149) would look to see if that IP address has ever been associated with the seller. Note that in the transaction there is no IP address associated with the seller, so it is comparing it to whichever IP addresses that seller may have used in the past. Similarly for device (ed:138 or ed:150).
In the case of the address, a transfer may contain two addresses, and depending on the use case, these addresses may have different semantics. For a marketplace (and thus the name of buyer/seller in the test) the addresses (billing and shipping) refer to the buyer, so these tests (ed:139, and ed:151) take either of these addresses and look for them associated to the seller.
You may ask if you never have information about the seller, how are these tests useful. Well, that is the important part. If at any point that seller was a buyer, or wanted to pose as a buyer, the system would collect its information. At the time the seller created its account, we were able to collect IP, Device, and Address, and so on. Since sellers are also users of the ecosystem, the platform can gather the data and use it for comparison on these tests.
In some instances the system may already detect that the buyer and the seller are in fact the same identity. We will be working on a security test to highlight this situation. In the mean time when this occurs you can see it by looking at the identity graph. The user account will be labeled with multiple identifiers separated by commas.
In all likelihood that these situations occur, any of the collusion security tests would have already fired.
Rate of growth of users to a shipping and billing addresses
Security tests: ed:152 through ed:157
These security tests count the number of users that are associated with a given address (either shipping or billing) over a period of time. They only count users when the payments were successful, meaning the bank authorized them.
The idea is to count how many users and how quickly they were associated with a given address. In general, you wouldn’t expect multiple users with a common address, especially in a short period of time. It may be normal, for a corporate address, to receive packages for multiple users. However unless you are Amazon, it is unlikely that you’ll receive multiple users within the same corporation in a very short period of time.
A simple rule would be to highlight when a given shipping address is associated with three different users in 24 hours. In this example you would use ed:154.
Aside from its applicability as a collusion indicator, this security test can also be very useful in an account takeover scenario. Imagine that a fraudster steals multiple accounts, then logs into each account and purchases products that are supposed to be shipped to an address where the fraudster can retrieve the goods. All of these accounts, otherwise disjoint, would now be associated with the same shipping address.
We will continue to work on security tests that are focused on Collusion scenarios. There is a whole set of behaviors that correlate account creations with activities and the longevity of the relationships between sellers and buyers. So stay tuned.