Subscribe to our blog
Get ahead with our award-winning insights on the latest developments in the fraud and compliance landscape. Enter your email below to receive our blog posts directly to your inbox.

Post Written by

CHIEF PRODUCT & MARKETING OFFICER Jose Caldera has been developing and marketing products for the last 20 years. An entrepreneur at heart, his focus has always been on the Enterprise, developing products and services for Information and Payments Security, Risk Mitigation and Compliance. He started in application and network security, later moving on to payments, virtual currencies, anti-fraud, and anti-money laundering. He has developed and marketed products for a number of silicon valley companies including Securify, McAfee and now IdentityMind Global. Jose earned a Masters of Science in Information Networking from Carnegie Mellon University.

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.

Merchant Fraud

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.

A Marketplace

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.

Transaction Laundering

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.

Link Analysis

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.


Security Tests

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.

Coming Soon

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.