How Do You Mitigate Risk When It Comes To Friendly Fraud?

Mitigating Friendly Fraud Risks

‍

"Friendly fraud is directly connected to the uptick we've seen in the number of bad actors who actually commit fraud, and this includes friendly fraud also. Friendly fraud is also known as first-party fraud. Obviously, it has many different faces. Originally, friendly fraud started within the e-commerce industry, but we are seeing a great shift pretty much into any different vector of the financial industry and especially Fintechs and crypto companies.

‍

So basically, we'll have bad actors who use their own identities a lot of times. In these situations, there's no stolen identity or compromised identity. The fraudster uses their own identity to pass through onboarding, bypassing your KYC procedures, and then they conduct fraud on your platform. So I think, if you think about mitigation, I would put it into two different pieces.

‍

I think a great way to mitigate first-party fraud would be, first of all, to understand the outcome of the KYC result that you had for the specific applicant and understand how you can manage risk correctly right after the onboarding is finished.

‍

And the second part is to have a strong policy around customer segmentation.

‍

And I think if you combine those two together, you should have the ability to know how to take the risk from the KYC vendor along with your customer segmentation to allow good customers to operate on your platform as freely as they can while also keeping you safe from customers that you might not know well enough, at least in the first few months of tenure. I think this is a good approach to handling friendly fraud."

‍

‍

Create Tiered Rules Using Unit21 to Better Detect Friendly Fraud

Let’s explore how we can create different versions of the same rule to fine-tune risk prevention, specifically in relation to new users.

‍

We’ll start with a simple transaction velocity rule that applies to all customers, and set it to look at any users that have made 5 or more high value transactions in a one week period. To avoid pulling in too many false positives, we’ll set the transaction limit to $500 or more. This will ensure we only pull in high-risk scenarios.

‍

This is ideally suited for existing users where we have other signals to leverage—such as a transaction history and their previous behavior. But new users pose more of a risk, as we haven’t seen their behavior yet, and therefore have less signals to leverage to make a clear decision on their risk level.

‍

To accommodate this, we can develop a different version of this rule that applies to new users. Teams can develop a version of this rule that adds another variable, how long ago the user registered. With this variable, we could set a rule that looks at users that have registered within the last 30 days. And if we want to, we can also change the minimum transaction amount to $100, significantly lowering the threshold that triggers a review. Then we can test this rule and see how it performs, later refining or loosening the rule according to the results we’re seeing.

‍

Now we have two versions of the same rule, that looks at different customer segments differently—which essentially allows teams to factor customer tenure into their workflow. And we can add further layers of rules as well if we wanted to, to further segment customers and analyze specific behavior.

‍

For example, we could add another rule that looks at customers that have been registered 31 to 90 days, and again slightly raise the transaction limit to $200. This further segments users so we can effectively manage risk associated with what we know of users. After 30 days, teams likely have an established transaction history and some idea of the user’s standard behavior. The original risk will be reduced, but these users still aren’t as trustworthy as customers that have been with you for a long time. With this flexibility, rules can drastically be altered to effectively manage risk while still limiting the friction on customers.

‍

Here at Unit21, we understand that data drives all of these decisions. That’s why we encourage—and empower—teams to leverage as much information as they can from their identity verification provider. If teams have a provider that offers an ID verification score, for example, they can ingest that data into Unit21 and build that into their rules, making it another variable that’s considered when the rule makes a decision on a case. In this instance, a risk score could be added as a variable to these rules, allowing teams to automatically reject or approve a transaction according to that additional risk signal.

‍

And since Unit21 is a no code solution, rules can be created extremely quickly without any input from an engineering team. This means teams can create, update, and refine rules within minutes, not days or weeks, so they are always optimized to prevent fraud.

‍

‍

Want to discover how Unit21 can be used to mitigate friendly fraud instances? Check out our first session of Fraud Office Hours on demand for a brief demo of how the platform works.

‍

‍